nick.ace

It's in the meta file that is autogenerated, so you open them just like any other file (like you did with your save files for HFF). It looks like each color channel is one byte in this case, so you would just use ReadUChar() for that: http://www.leadwerks.com/werkspace/page/api-reference/_/stream/streamreaduchar-r272 Basically follow this order of commands: --This sequence avoids all error checking, so implement that if you want file=FileSystem:ReadFile(path_to_file) file:ReadString(4) file:ReadInt() keycount=ReadInt() for x=0,keycount-1 do file:ReadLine() end thumbcount=file:ReadInt() for x=0, thumbcount-1 do size=file:ReadInt() width=2^size for x1=0,width-1 do for y1=0,width-1 do red=file:ReadUChar() green=file:ReadUChar() blue=file:ReadUChar() alpha=file:ReadUChar() --Do something with these colors end end end

I really liked your poll gamecreator, and it seemed to influence a lot of development. I also understand damvcoool's suggestion though because it adds more urgency for some features. I think more user input with each release would help as well. The reason being is that when designing a game, there are sometimes features you might need, and some sort of timeline would be good. Right now I honestly don't know what will happen next with the engine. I understand why Josh is hesitant to reveal features, but it also makes it difficult to plan accordingly. If Josh set up a poll, we would at least get a sense of his general direction better. Then, he could also gauge the community's interest more. Right now, I'm not sure I can continue at least one of my LE projects because of limitations I've hit and there being too much ambivalence with possible future features. Yes, it's my fault for not figuring out the design more carefully, but sometimes designs change a little, and you end up hitting walls. For example, what happened to networking, roads, MacOS support, etc.? For all I know, they could be rolled out next week, in a few years, or possibly never.

I mean, I just recompiled the interpreter project that is included with each new project. What I'm saying is I think there may be a missing global configuration settings that were not included in the project. Visual Studio seems to have a ton of settings, and I wonder if something was left out of it. Either that or a different version of the VS compiler was used.

One thing that is really annoying is when you open a map and everything is expanded. It makes it difficult to navigate especially if a lot of entities have a lot of children (like characters). Some can be said about code folding as well, but that's less of an issue.

I think you need to be more specific with what you want. Do you want the wheel to be attached to a car or just free moving? Do you want it to be physics-based or just an animation? What is this wheel for? These are important questions because there are a lot of different ways to approach this depending on what you need.

Any luck on this? I feel like it definitely has to be a difference in settings. Otherwise, the .exe would be the exact same size. I feel like a start to finish C++ compiling tutorial for Leadwerks would be beneficial.

I'm experiencing this as well. I have no clue on what is causing it, as it seemed like any asset I saved in the model editor within my map (without the dialogue mentioned above) will crash Leadwerks (but the model does get successfully saved) in my current project. Interestingly, my the advanced FPS default project didn't have these issues. This happens when I: Recalculate normals Apply textures I've had issues with models with and without animations.

I feel like it's some sort of memory issue, possibly from different project configuration settings. I had similar problems and am still unable to solve it (after spending days looking at this, I kind of gave up): http://www.leadwerks.com/werkspace/topic/12572-compiled-c-vs-default-lua-exe/page__hl__exe Are you experiencing any of this? Like your game, my game was pretty demanding (you use a lot of lights while I use a lot of assets).

There should be a tutorial in the Advanced FPS template if I'm not mistaken. Anyway, there are a few errors with that method so far: name != levelname, so you are loading a nonexistent string You are creating a world when one already exists. Clear() does not delete the world You are releasing a world when you just made one (if your code made it this far, you would be deleting the most recent one presumably) Here is a cleaned up version that should work (untested though): function App:SwitchLevel(levelname) self.world:Clear() self.mapFile = levelname end ... function App:Loop() self:ShouldSwitchLevel() --If window has been closed, end the program if self.window:Closed() or self.window:KeyDown(Key.Escape) then return false end if (self.window:KeyHit(Key.C)) then self:SwitchLevel("Maps/Level01.map") end end

Well, I know crouch works because I've been using it in my project right now (I used it yesterday) to get under smaller regions. I haven't used GetCrouched() to be honest, so maybe that's broken, but the SetInput() works for me (I'm on the beta). Every time you call SetInput(), the crouch reverts back to true by default unless you specify otherwise. Maybe this is what is causing it to not work properly on your end?

To the OP, this code should work in FPSPlayer.lua (untested, put in UpdatePhysics()): local window=Window:GetCurrent() --youi may not need this line, check to see if it already exists if window:KeyDown(Key.Control) then self.entity:SetInput(self.entity:GetRotation(true).y,0,0,0,false) end if self.entity:GetCrouched() then self.camera:SetPosition(self.entity:GetPosition()+Vec3(0,2,0)) else self.camera:SetPosition(self.entity:GetPosition()+Vec3(0,1,0)) end Crouching is not disabled, it's just that some people, including me, wanted control over how much the character can crouch. It gets frustrating when you can only crouch to about 2/3 the total height (so vents are impossible and going prone is also impossible).

Could you give a link to the tutorial? Also, what is happening right now with the AI? Is it just standing there, is it turning, etc.?

Ok thanks, I'll try again tomorrow. Edit: figured it out, there was another SetPosition() somewhere else

I was reading that bug report, and the ordering I can confirm makes a difference. I started testing stuff out and the ordering matters, but there are other problems I see as well. My test: I opened up tutorial map 7, which is the big industrial map with the crawlers and stuff. I placed the firepit right in front of the big door under the stairs. I started the game, but the sound gets softer the closer you move towards the pit (which shouldn't happen since the listener is parented to the camera, and the source is positioned at the global position of what it is attached to). This also happens in a map I'm working on for a game right now. The volume is inverted. After digging in the code for the FPS template, it seems that the listener gets attached to the camera, not really sure why there ever would be a need for a listener away from the camera (maybe more clarification on this design decision would help).

What does it do though? btw, I saw that example. That example doesn't help or explain anything at all for listeners!

Yeah but that's so vague. How is it different than a source and what is it supposed to be used for? Only one argument and no examples doesn't really help.

I have two questions regarding sound: 1. What are listeners? I can't find any documentation on what they actually are or are supposed to do. 2. Has anyone tried the firepit workshop item? It uses a source object in the code, but the farther you get away from it the volume stays the same and sounds the same no matter your position towards it (and there is no stereo effect, like if one ear is closer to the sound than the other, although this might not be implemented). I checked that it's a mono sound, so this behavior seems odd to me since the sound gets positioned at a certain point (so it should be 3D sound). Basically, it sounds like an ambient sound. What are 3D positioned sounds supposed to do?

What is the "direcction" variable (it doesn't get assigned anything)? Here is the direction you generally want to take to create levels like this to ensure that everything is interconnected: //starting at (0,0) grid={} gridsize_x=10 gridsize_y=10 start_x=5 start_y=5 //initialize for x=0,gridsize_x do for y=0,gridsize_y do grid[x][y]=1 end end grid[start_x][start_y]=0 for z=0,10 do //you can use the keypress instead if you want, this is just to show multiple iterations //initialize randnum=Math:Floor(Math:Random(0,3.9)) if randnum==0 then if start_x>0 and grid[start_x-1][start_y]<1 then start_x=start_x-1 end elseif randnum==1 then if start_x<gridsize_x-1 and grid[start_x+1][start_y]<1 then start_x=start_x+1 end elseif randnum==2 then if start_y>0 and grid[start_x][start_y-1]<1 then start_y=start_y-1 end elseif randnum==3 then if start_y<gridsize_y-1 and grid[start_x][start_y+1]<1 then start_y=start_y+1 end end grid[start_x][start_y]=0 end //fill in with models, boxes, etc. for x=0,gridsize_x do for y=0,gridsize_y do if grid[x][y]==1 then //Place box or wall or whatever here end end end I didn't test this code, but you should be able to just plug it in (and of course replace the box comment at the end) Right now it is basically one long path that DOESN'T cross over itself. You also won't have walls duplicate in the same spot because you are doing a boolean subtraction operation effectively (carving). You'll probably find it easier to carve out a map that to just build one from scratch, and this algorithm will help you with that. If you decide later to use modular pieces instead of blocks, then you just reverse the condition of the last nested for-loops. Some ways to improve this: Add recursion so that the path can break off into multiple paths (medium) Go with the totally random approach to start and create a minimum spanning tree (hard) Add better ending conditions instead of expecting z to terminate after 10 iterations (easy) Allow for overlapping paths to add more variety (easy) Add affinity towards certain directions: basically make some directions more common than others based on location or other factors (easy)

I think he's using Linux though.

That's the point of the 2D array. Like Rick said, every time you place a piece down you put a 1 (or a non-zero number) in the corresponding grid cell. Everytime you think you might place down a piece, you check to see if a number !=0 is in that corresponding grid cell. For example, if your grid looks like this and you are at the underlined position, you check randomly up, down, right, or left. Let's say you get left. Since if this case you can't go left because a 1 is there, you either pick up, down, or right (or you could optionally terminate): 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 You are not placing the array on coordinates of the map. The array IS the map.

Josh, would this be against the license? I guess I haven't heard of anyone making a software application with Leadwerks, but are those allowed? And what do you mean by game creation software?

The problem is that the character controller stays the same radius and then navmeshes get inaccurate (so AI could bust their way through cracks, etc., although you could work around this by enabling and disabling physics, but it's kind of a hassle). These would be nice options (I get why Josh removed them, but it would be nice for users to have them): http://www.leadwerks.com/werkspace/page/Documentation/le2/_/command-reference/controllers/createcontroller-r101

That would only change the camera height. The problem is that when you put the controller into crouched mode, the controller actually gets shorter (the physics mesh or whatever it is built of). So that means that you can't go under regions where the ceiling is too low. My problem is that I want to be able to control the height of the controller so that I can go under shorter regions. The default crouch height is like someone kneeling, which makes it impossible to have a character go through vents and stuff like that without massively changing the level's physics.

Thanks, I have it working, but I would like control over the crouch height (so you can go through shorter spaces or even crawl). Currently, the character controller doesn't allow that.

Actually, I just tested it out. Paths that the controller can go through while crouched are not created in the navmesh, so this shouldn't have an effect with navigation.