Rick

Ok thanks for the recommendation. That was my workaround. It also required setting a flag on the entity and checking that flag as well since collision can be called multiple times for the same entity per loop. I noticed just hiding resulted in my counter increasing more than just once. I guess I could have checked for hiddden instead of making a flag too (just thought about that). What I did Then is inside that entity script in UpdateWorld, check if this flag is set and if so release self.entity and that seems safer.

I guess I would think/expect if I release an entity inside here, LE wouldn't call this function again with a released entity. Perhaps that assumption is incorrect? I know the call to entity:Release() inside does execute and comes back as a system print shows execution reaches the end of the Collision() function even on a crash. I guess in this post I was more looking for the guidelines to releasing a passed in entity in the Collision function. Should it be avoided, is there a recommended way to handle that idea or should it work and it's something I'm doing and can dig into myself? I (what I consider) worked around the issue currently so I think it's good. Was just curious if there were any recommendations around the idea of releasing an entity during a collision.

In my game I call Release() on an entity from inside the player script Collision function. So when the player collides with this entity it gets released. Sometimes this seems to cause a crash of the game (no error message just Assert failed). If I just Hide() the entity I don't seem to get a crash (tried like 20 times and no crash). I thought it was sounds I would play in this collision function at first but it doesn't seem to be that. With some system prints I see it makes it all the way to the end of the collision function just fine so it goes over the Play() functions for the sounds. It's almost like in some situations LE is trying to do something with the passed in entity and since I've released it it would cause a crash since it's trying to access something where the object in memory doesn't exist anymore. Does LE do anything with the passed in entity variable to the collision function after the function is called? Are these entities in a list and me deleting it causes that iterator to get messed up or something?

My entry: Wanted to get it out early to see if there were issues for people. Wan

Is there a shader that allows you to have a mask texture? Not a diffuse that has alpha but a separate texture from the diffuse that is b&w that shows where the alpha should be?

I would say do both! Some people like out of the box solutions and others like to get under the hood and modify things. You did this with the animations API (although it took you a year or so to decide on making an official API method for it) so same idea here.

Josh is saying team speak not TeamSpeak. Nothing to do with the application TeamSpeak. It's just a phrase where teams speak to each other.

I'm personally not a fan but I guess it comes down to if you think you are losing sales or that is stopping people from making games with LE or you can get to market faster with that style.

Yeah, the joys of scripting languages

Got it figured out. I had a variable self.world for current world but I named another variable that which wasn't an LE world.

No, I'm not in Beta. OK, thanks I'll keep digging to see how I broke this.

Just checking if anyone else if having an issue calling ForEachEntityInAABBDo() on the world object? I haven't changed this part of my code but today when I run I get the following error: 'attempt to call method 'ForEachEntityInAABBDo' (a nil value)' Just want to rule out some update messing this up while I keep pounding my head on why I'm getting this.

Leadwerks doesn't really allow "true" file streaming of maps. You'd have to mock this behavior. Main key would be to preload all assets once at the start otherwise an asset loaded for the first time will cause a delay but an already loaded asset "loaded" again will be almost instant since an instance is created vs going back to disk again. However loading map files will still cause a delay because of the amount of assets loaded in 1 iteration. You'd probably have to make your own map file and load the entities a few at a time per iteration to give a smooth loading experience that seems like it's multithreaded.

I suppose I should give usage :). Often times before a level you may want to do a small something, then give control to the player, then at the end of the level do a little something else. This would work perfect for that situation. You'd have 3 states, PreGame, PlayGame, & PostGame. Each one has an Enter/Update/Leave for you to do things in and because Enter/Leave are coroutine enabled you can show progress while staying inside that function. You can wait 1 second, increase a number over time that's tied to the UI so it shows it going up over time, then wait then do whatever. function Script:Start() self.stateMgr = StateManager:Create(self) -- when you change states the state manager looks for functions with that state name and _Enter() _Leave() _Update() and if found will call them. self.stateMgr:changeState("PreGame") self.text = "" end function Script:PreGame_Enter() WaitForSeconds(2) -- these functions have yield in them self.text = "Ready" self:PlayBeepSound() WaitForSeconds(1) self.text = "Set" self:PlayBeepSound() WaitForSeconds(1) self.text = "Go!!" self:PlayBeepSound() self.stateMgr:changeState("PlayGame") end function Script:PreGame_Leave() -- not doing anything here but showing you can have it end function Script:PreGame_Update() -- don't need this but showing it anyway end function Script:PlayGame_Enter() end function Script:PlayGame_Update() -- do your game code here and when finsihed call self.stateMgr:changeState("PostGame") end function Script:PlayGame_Leave() -- maybe remove control? end function Script:PostGame_Enter() -- tween in your end game UI here and do some counting that updates the UI -- changing states could happen from a button click event function perhaps to continue end -- don't need to define Update()/Leave() for a function if you don't want to function Script:PostRender(ctx) ctx:DrawText(self.text, 0, 0) end function Script:UpdateWorld() self.stateMgr:update() end function WaitForSeconds(interval) local tm = Time:GetCurrent() while Time:GetCurrent() < tm + (interval * 1000) do coroutine.yield() end end

[EDIT] Added better error checking. If an error happens in a coroutine Leadwerks doesn't report on it and the game doesn't stop, but I checked for an error and get the message and write it to console/log and fail the app saying to check out the console so it acts more like a normal error instead of it just not working. I'm using this for the competition so thought others might find it handy. Coroutines can be handy to allow you to do tasks over time but do them sequentially in 1 function. For example I could code something like the below where each function is done sequentially and we'd see/hear the results on the screen. If you did the below inside UpdateWorld() you'd only see the end result after that 1 iteration. function MyFunction() MoveToPoint() PlaySound() TypeText() end A state machine is a way to control flow between different states (or ideas). When you combine the 2 (coroutines and state machine) you can get some pretty powerful functionality. With this, each state has 3 functions. Enter/Leave/Update. Enter and Leave are coroutine enabled and Update() is like UpdateWorld() where it runs each frame. If you want more ideas on how to use feel free to ask. if StateManager ~= nil then return end StateManager = {} function StateManager:Create(container) local obj = {} obj.container = container obj.currentState = "" obj.nextState = "" obj.coLeave = nil obj.coEnter = nil for k,v in pairs(StateManager) do obj[k] = v end return obj end function StateManager:changeState(state) self.nextState = state -- if this is the first state then don't call a leave state if self.currentState ~= "" then local onLeaveMethod = self.container[self.currentState.."_Leave"] if onLeaveMethod ~= nil then self.coLeave = coroutine.create(onLeaveMethod) end end local onEnterMethod = self.container[self.nextState.."_Enter"] if onEnterMethod ~= nil then self.coEnter = coroutine.create(onEnterMethod) end self.currentState = self.nextState end function StateManager:update() if self.coLeave ~= nil then if coroutine.status(self.coLeave) ~= "dead" then local ret, err = coroutine.resume(self.coLeave, self.container) if ret == false then System:Print("Error: "..err) error("Check console/log for error") end return else self.coLeave = nil end end if self.coEnter ~= nil then if coroutine.status(self.coEnter) ~= "dead" then local ret, err = coroutine.resume(self.coEnter, self.container) if ret == false then System:Print("Error: "..err) error("Check console/log for error") end return else self.coEnter = nil end end -- call the update if we have one defined and aren't doing an enter/leave local onUpdateMethod = self.container[self.currentState.."_Update"] if onUpdateMethod ~= nil then onUpdateMethod(self.container) end end

I do the same thing in my UI system. I don't give a real font number in my UI. Instead I just do ex_small, small, medium, large, ex_large, and fill. Each "label" is a ui widget that is basically a rectangle area and I load the font for all various sizes and then I use the text functions to figure out which size is best given the ui widget area which scales by screen resolution. This way the font always "scales" as well. Yes, it's a pain, and yes you have to load various sizes (I go by 2's) but I couldn't find any way around it to get scaling fonts that don't look all stretched if you wrote to a texture and scaled the texture.

Not sure if you've kept LE open each time and just deleting the files to keep retrying but restart LE after deleting files and try maybe even importing into a different folder as a test. I've had LE do funny things when I delete a file and try to reimport it where it wouldn't see the new file change. Deleting the file then restarting LE and then reimporting seems to clear some in memory stuff LE must be doing. Just an idea to try.

We are saying it should do that automatically for you with some correct settings and we are just trying to figure out why it’s not. I thought you got the mat to auto generate? Are you saying you didn’t get the mat to autogenetate because that’ll be step one to figure out first. Without that the textures won’t be auto assigned

Full names have the file extension right? Like .png at the end and you’re saying it still doesn’t auto map them to the mat?

Are you naming your texture files with _diff for diffuse, _dot3 for bump, and _spec for spec textures? If the filenames of your textures have those suffixes then Leadwerks should assign them automatically. It’s the only way Leadwerks can know what texture should go where.

I haven't done much game dev the last few months as life has been busy. However, we are building a new house and I get an office and I want that poster for it! So for the game tourney:

Are you sure it’s the names causing the crash vs the children coming back as null? So trying to call a function on a null object would cause the crash.

I think he's saying he really doesn't want an extra handle. He really just wants something to know if something else still exists in the world or not. From his perspective it's perfectly fine if 5 entities know about entity 'A' and 1 of those 5 entities releases entity 'A'. The other 4 just need to know entity 'A' no longer exists somehow. If all 5 entities called AddRef() when they assigned entity 'A' internally, then when the 1 entity that reached entity 'A' first got it and called Release() on it entity 'A' would still exist, which he doesn't want. He wants it gone, and to somehow tell the other 4 entities it's gone. Perhaps one way would be to have entity 'A' store a list of other entities that "have" it in their sights. I believe there is a script function called when Release is called. When that's called it can go through this list and inform the other entities it will no longer exist and they should set their internal pointer to it to null? Kind of looking at it from a reverse perspective where the object being released tells all other objects that have a reference to it that it's being deleted and they should handle that accordingly. https://gamedev.stackexchange.com/questions/115580/how-to-handle-gameobjects-that-have-been-destroyed-but-are-still-held-by-others Tower defense is probably the most common situation. 3 towers all pointing to 1 enemy and 1 tower kills that enemy. The other 2 need to know so they know not to use that pointer to the dead enemy.

Yeah it would be interesting to see the results of the test. I would assume there are efficiency techniques to help speed up the navmesh generation. Probably use invisible csg around models instead of detailed models for obstructions as maybe that reduces complexity in generation? Be able to walk through some props if it’s not vital for gameplay. Stuff like that. Rust takes about 3 mins to load the map and a lot of ppl play that game ?

With that comment, for me, the solution is then to build the 1 map on the host from prefab rooms and then the host gens the final navmesh via code for itself. Tell the clients what prefab rooms go where and have the clients load those room prefabs and build the navmesh as well via code locally (they should match since LE built both). This is all done once at startup so once it's built you don't have to worry about it anymore. This is part of the loading screen so even if it takes 20 seconds it's not a big deal. This should be much easier than messing around with dynamic loading/unloading during run-time of rooms and navmeshes. This all assumes you don't care if the client gets the entire map info at startup. If you simply don't want them to see other rooms you can hide them, but if somehow knowing the design of the entire dungeon right away gives them an unfair advantage then this wouldn't work as they'll have that data and a hacker could figure the entire design out even though they only see 1 room on the screen at a time. So this is a question in requirements. They obviously wouldn't see where the other players are because your server wouldn't tell them where they are until they need to know (it should work that way anyway), so it's simply the design/layout that is in question here. When you're developing the rooms you make 1 room at a time in a map and test the navmesh generation there. Save that map with a name of just that room and that's your development map for that room. You'll then have a ton of these which is fine, but they aren't used for the game. After updating a map room you always save out the top level entity of the room as prefab (make a top level pivot for the room entities).