Rick

We have a lot of explosions so hoping the bug of making instances of prefab emitters can get resolved fairly soon as it makes our workaround fairly cumbersome.

I don't fully understand your question. Do you mean from 1 script how to get the position of another entity? You can link them with script variables like: Script.player = nil --entity Then in the editor draw the player to this field in the script tab of your other entity and now inside that you can use self.player to refer to the player entity. You can do this with any and all entities.

I would do it the way you are doing it. I was just pointing out if you aren't sure what 'self' means then it's why you are having the issues you are and makes it harder for you to fully understand how to design something. world:ForEachEntityInAABBDo(aabb,"Callback",self.entity) function Callback(entity,extra) --We only want to execute this on models. If we don't check the class we will change the color of the light, too. if entity:GetKeyValue("type")=="enemy" then extra.script:AddEnemy(entity) end end Then make a function called AddEnemy() in your script. So you see what you are doing is making a global function and then you are passing that to ForEachEntityInAABBDo() along with the entity itself as the extra parameter. The engine will call this function and pass the entity around with it so you can get access to your function inside your callback.

I think Cassius is saying the trend is away from what you are asking for so it's unlikely. All the updating Josh does to the engine it's just easier I'm sure for him to use Steam to do that. Put on top of that the idea that when Josh moved to Steam he got so many more users I wouldn't hold your breathe on this. Basically, "everyone" uses Steam so not much reason to change.

It seems like the Callback function is not made to acces self variables This is just a fundamental misunderstanding of how Lua is working from you. Until you fully get the 'self' idea you will find things not making sense or difficult to implement. This is all about variable scope and understanding what 'self' means.

yeah, I would just swap those if statements. check for the KeyHit() first so it gets called each frame. that should prevent the queuing that you are seeing.

I believe the callback has to be a normal function not a script function. That means it would know about the self variable so you can't use that. Instead if you wanted access to that script you would pass self.entity as the extra param to the callback

My guess is your KeyHit() check is done inside some other if statement. Generally if you have it as a top level check where it's always checked each frame you won't run into this issue. I would have thought flushing would have worked too though. On another node I've for the most part stopped using the Hit() methods and make my own with a boolean flag to avoid the issues it has. if window:KeyDown(Key.A) and aKey == false then aKey = true --- do key hit stuff elseif window:KeyDown(Key.A) == false and aKey then aKey = false end

Using the example of the API as reference something like the below should do that local stream = FileSystem:ReadFile(path) if (stream==nil)then Debug:Error("Failed to read file.") end local json = nil while (not stream:EOF()) do json = json..stream:ReadLine end stream:Release()

My question would be why JSON? Is there a specific reason to pick that format?

http://www.leadwerks.com/werkspace/page/api-reference/_/stream/ http://www.leadwerks.com/werkspace/page/api-reference/_/filesystem/ http://www.leadwerks.com/werkspace/page/api-reference/_/filesystem/filesystemgetappdatapath-r801 Note that file i/o will not work with the game launcher if you care about that. Also you might have to pay attention of where you are reading/writing the file. I don't think it can be part of the zip file as you won't know the pw to open it. So normally these files need to be somewhere else.

If you are using Prefab:Load() and passing in a relative path it should be fine. One thing we run into is when publishing make sure to do ALL files not just used files. If your prefab is NOT in the editor and ONLY loaded in code then the publish won't include it in the build because I don't think the publisher goes through the code to see what's used, but instead just looks at the map file to see what's used and what to include in the zip files. Your other way around this is to place the prefab in the scene somewhere as a precache. Just disable it.

I assume there will be a rework of the game launcher to better meet the console requirements?

I wouldn't put money on it. There is really no need for Josh to do that since LE 3 combines the best of both worlds. It's just not a complete set yet.

Yes, OK I see now. We are using the word "grouping" in 2 different senses here. There is grouping for project organization and then there is grouping for parent/child relationship. Those are 2 different things in LE.

OK, I think I read this wrong. To me the grouping I thought he was talking about was just putting entities together for project organization.

Using pivots comes at a cost. You are now making a parent/child relationship. You are affecting functionality to get organization. Am I missing something with you not wanting to use folders/filters in the scene tab for organization? That's why it exists.

I'm not following here. In the scene tab you can make folders/filters and group things however you want.

I'm confused on the grouping part. You can make folders/filters and group things until your heart is content.

Those are interesting links. Says I don't have permission to view them Thx.

Is there a way to get the Terrain height in Lua? I don't see any Terrain specific stuff on the API Reference page.

It would be pretty cool to be able to see values as the app runs. I can see it useful when debugging ai stuff.

My main concern would be that it'll be volatile pausing in time based on how many entities and things you are doing per room. Right now it's a couple seconds but I'm only trying project outward when you have more things going on. You aren't loading any characters but they generally take longer to load with all the bones and such vs basic static models. The more complicated your rooms the longer and more volatile (less predictable for you) it'll become. Just throwing out ideas on this, not like I hold the key to everything . Just food for thought.

You can still do that without loading a new map. Nothing says inside your map the house has to be all in order. You can literally have pieces of your map laid out all over the place in the 3D world. Just place starting pivots to each room and teleport the player there between transitions. This would avoid any noticeable pauses in the game while the map is loading since LE doesn't handle loading maps in the background on another thread. There are for sure pauses I notice when going from room to room and the more complex the rooms become the longer the pauses will be. To have a smoother transition you might want to consider having all these rooms just laying around wherever in your 1 map and put that loading time of the map up front on game start. Just an idea to make smoother transitions without much pause in them.

ok, the biggest thing you were missing is checking if the neighbor was actually a valid neighbor given the 2D grid layout you have. This means you have to see if neighbor and node's row/col are actually 1 value from either other. If they are > 1 value then it's not a valid neighbor because it's too far away to be a valid neighbor in a 2D grid. Below is how I setup the is valid function and it worked. It also gave me each node from start to end like you were expecting. local valid_node_func = function (node, neighbor) -- not a valid neighbor if we can't walk on this "tile" if neighbor.walkable == false then return false end -- only neighbors that are right next to the node are valid neighbors in our 2d grid setup if math.abs(neighbor.row - node.row) > 1 then return false end if math.abs(neighbor.col - node.col) > 1 then return false end -- don't allow diagonal movement if neighbor.x ~= node.x then if neighbor.y ~=node.y then return false end end if neighbor.y ~= node.y then if neighbor.x ~=node.x then return false end end -- we made it passed all the checks, yay! we are a valid neighbor! return true end