Rick

Yep, that's why I'm asking Josh to do this since in this feature request (I take this forum for official requests to make it into the engine and supported) it shouldn't take much for him to officially support it. The thing with "work arounds" (if you can call it that) is that if it's not officially supported it rarely gets used. Also, I know I use world:CountEntities() and world:GetEntity() but I believe Josh has stated those aren't officially supported so they could change. I wish they would be official though honestly.Believe me, I do tons of "work arounds" for things but I always want things to be official so they are part of the engine and documented/supported for newer users to use as well.

If easy is what you want then just reload the map by setting the changemapname variable to the map name you want to reload anywhere in your code.

I know I could do this. The request was mainly asking for it to be built into the engine as a useful feature for users without requiring them to do anything extra. This request wasn't for me but just a general request that would help people of the engine.

Might be nice to have a Reset() function on the world which would cycle through each entity and call a Reset() script function in the case where it would take longer to reload a map than to just reset some information. The details of resetting would be up to the user. I guess if you took this to a more generic approach it might be handy to be able to call any function ALL scripts might have defined from the world. Something like: World:CallEvent("Reset", extra) There might be other uses to do something with this. Like "Save" to let entities save their information when we need to save the game.

In the scripts that are attached to the things that matter in the game, in the Start() function you could save off the position/rotation. Then make your own Reset() function that resets it's position/rotation and any other state you care about. Then you just need a way to callthis Reset() function on entities that have it defined. You could do this a various number of ways. I guess the easiest would be to just loop over every entity in the world and if it has a script attached and that script has a Reset function then call it. You could obviously reload the map if you like as well but that'll take longer for the player to wait depending on how large your maps are. It would be kind of nice if this reset function method is something that could be in the engine itself. Call something like World:Reset() which would trigger a Reset() function for every script.

This would be handy for others. You should share the code for others!

As Ma-Shell is saying you have your 2D array grid and from there you can figure out the width and depth (the size) of your "tiles". They can be any size you want. Once you pick that information you can then look at your mouse pick position on the terrain and figure out what "tile" it was done in and then place the turret's position (assuming it's teh bottom center anchor) to the center of that "tile:. This is actually very common in 2D tile map systems so you can look at those examples online (for any language/engine) and see how that works. Here's a drawing to go from. This is how your 2D array "looks". The width of each tile in this example is 4 units wide and 4 units depth. The 0,0 at the top left would be the origin of the 3D world (in this example). So this would be the bottom right coord so going right is in the positive direction and z is the negative direction. You can obvious pick whatever coordinates you want to start with but this makes it easy to understand at first. https://www.dropbox.com/s/1wwhg961c5xzl8c/grid.png?dl=0 No let's say you mouse pick at position x = 3 z = 2. To find out what "tile" you clicked in you do the simple math equation: col = x / width row = z / depth You then ONLY take the whole number part and ignore any decimals. This will tell you the 2D array position you clicked. So in our example it's: col = 4 / 3 col = 0 (remember we want to ignore the decimal part) row = 2 / 4 row = 0 (remember we want to ignore the decimal part) So this is row = 0, col = 0 or (0,0) or the first tile position. Once we get the tile position we can calculate it's center point since we know the width and depth of each tile. Simply multiply the row by the depth and the col by the width and that'll give you the top/left position of that tile. So then to get the center you add (or subtract depending on the quadrant) half of the width or depth (2 in this example). So now you can convert from both tile position to world position and world position to tile position. To have your grid placed anywhere you just apply x and z offset values and add/subtract that offset value to every value you get and that lets you place your grid anywhere in the 3D world.

Your best bet in terms of simplicity is probably to use decals and an emitter of snow to hide the decal being placed on the terrain. A lot of what you find in games isn't really how you'd expect things to be in the real world.Decals would mimic the look or treads and then it's about placing them correctly and hiding the "snap" feel of placing them with an emitter that clouds up the area by the snowmobile's back end.

Show us the full code in question and if it's a function give us some test parameters to pass to it.

Are you calling Follow() every frame? Not sure but if that could cause an issue but might want to check that out.

Did you see the flag in the veg layer for collision on that layer?

Is it a child/parent thing where the entire veg layer is an entity but it has children entities that are the trees? I'm just trying to think of possible ways where we could treat each vegetation as separate entities, even if that method is a little trickery like hiding that one in the veg system and swapping it with a real entity or something like that. Otherwise, right now the veg system doesn't handle dynamic situations like chopping down a tree, unless you have some other method in mind for that.

I thought we couldn't read/write files, even from FileSystem, in sandbox mode? I though all IO was disabled in that mode? I hear you on the lua packages not being loaded but I thought the LE FileSystem stuff was also effected. I guess if I find time I could test.

Will that FileSystem command work in sandbox mode? Guessing no but haven't tested. If not that might be something for the OP to consider since they are new to LE. Might not be able to use the game launcher with that command if that's the intention of the OP.

I didn't think CSG came back as an entity that you could call GetMaterial() on unless it has mass or a script attached to it which turns it into an entity.

Pick downward from the player position every few ms with http://www.leadwerks.com/werkspace/page/api-reference/_/world/worldpick-r502 When you get the entity picked I think you can try the following to tell if it's the terrain or not if entity:GetClass()==Object.TerrainClass then If it's just a model (I don't think csg will work for this idea) then you can get the material attached to it and tell what it is and change footstep sounds based on that with: http://www.leadwerks.com/werkspace/page/api-reference/_/entity/entitygetmaterial-r127 I don't have time to show you the exact code on all of this but this should get you started. Note that you'll need to play around with the collision type parameter used in the picking to avoid picking the player itself. Your starting pick should be a little above the players y position and then down a certain range in hope to collide with whatever the player is on. You can make this picking collision something that won't collide with the players collision type but will with other collision types (essentially passing thru the player since you don't want to pick them). There is a chart that shows these collision types and their responses here: http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/collision-r778 The collision type you specify will be checked against the entities in the world's collision type and the responses in the link above is what happens. So if in the chart the collision is None, then it'll pass thru it and won't register. I'm not 100% sure what the terrain collision type is. Maybe Scene? Play around with those settings and experiment. Use System:Print() to help you debug things (it'll show up in the console window). If you are new to the engine or new to programming expect this to have some pain points while you figure it out. Don't get frustrated. That's just the nature of game development. Try these things and keep the things you are trying to do isolated so if you have issues you can ask specific questions about that small chunk of code that you may have problems with. Good luck

raycast would be easier on your map creation stream but on the terrain I don't think there is a way to determine different types of materials (grass, gravel, blacktop, leaves,etc). you could make a grassy gravel footprint if just on "terrain" (which you can tell) to try and cover ALL terrain noises under 1 sound, and then switching to models of floors which you can get the material on and be more precise. Triggers would give you much more control over this but more work by making all these triggers all over the place. It would clutter up your map. But, yes you would raycast down, maybe once every few ms (not every frame as it's not needed and raycasts have a higher cost in processing I believe).

OK, so step 2 is to figure out what part is taking the most time in your script, by commenting areas out and see what it is. I often do things inside UpdateWorld() vs UpdatePhysics() and when in UpdateWorld() for AI stuff I often don't do it every frame as it's generally overkill. Generally I make a timer and only do AI type stuff every x ms. Try 50ms and play around with what may work. This can help increase FPS, but first figure out what part of the code is taking time by commenting things out and rerunning. Rinse repeat. That's how I generally do about it anyway. If I had to guess I would maybe think the ForEachEntityInAABBDo() callback, again, doesn't normally need to be called every frame as it generally changes less often as things move slower than each frame is running.

Step 1, have you tried just adding 30+ turret models without scripts attached to see what kind of FPS you get? Try that first.

Also, are we doing to get access to some of these vegetation layer properties in code? I can see the density property being useful in performance parameters for the given users PC.

I think you talked about this before but I'm trying to remember what you said with what if we want to "chop" down a tree?

Are these treated like normal entities in our code?

I have a feeling LE is going to get a boost in sales after this release. I mean that is amazing stuff!

I have entities release themselves all the time. I think it's how it should be in this environment. For example when the player shoots an enemy the play shouldn't release the enemy as the enemy still has to run its death animation which takes time after the player has shot it. No sense in the player holding onto a ref to that enemy to release it later.

You should load fonts on startup because they take time to load. Then you switch to those fonts during runtime which is more instant.