Rick

If you look at this trigger setup it has an OnEnter which is only fired once so you can use that to have any size and avoid having the collision keep getting called. http://leadwerks.wikidot.com/wiki:collision-enter-exit

I have too much going on at this time. I just don't have the time right now. What I did in the past was to make a C++ DLL where you include the Lua and RakNet source into. Then make some global vars for the RakPeerInterface and such and make C functions that you expose to Lua. Then in lua you load the DLL and start using the functions you made. Sure, but the lack of a textbox in LE means you'd have to make that GUI element first. Can't run in Lua Sandbox mode which I believe is what the Leadwerks game player users.

From my memory I can in the scene tab. Can you select in the 2D views? Not at home atm. Either way, any selection of an object should put the editor in entity mode vs terrain mode from my perspective.

This has gotten me a few times as well. I feel like if you select an entity in anyway, scene tab or perspective view, then it should take you out of terrain edit mode. If I'm in terrain edit mode and select an entity I expect to be able to move/rotate that entity, but that's not the case. I think that's what these guys are saying.

Nice on the encryption!

Here is the script I attach to the lights to flicker. Just copied it from the old LE 2 firepit. function Script:Start() self.color = self.entity:GetColor() self.fluctuation = 1.0 self.smoothedFluctuation = 1.0 end function Script:Draw() self.fluctuation = self.fluctuation + Math:Random(-100, 100) / 500.0 * Time:GetSpeed() self.fluctuation = Math:Min(1.8, self.fluctuation) self.fluctuation = Math:Max(0.75, self.fluctuation) self.smoothedFluctuation = Math:Curve(self.fluctuation, self.smoothedFluctuation, 5.0 / Time:GetSpeed()) self.entity:SetColor(1.0 * self.smoothedFluctuation, 0.6 * self.smoothedFluctuation, 0.25 * self.smoothedFluctuation, 1) end

static Entity* Load(const std::string& path, int flags=LoadScripts, const uint64_t fileid=0) Isn't that the default value already?

I still trawl the forums and read the docs plenty. Don't feel bad

I think you can call world:FindEntity("ParticleEmitter2")

So they would have 2 entries. The input one would show on the left and the output one would show on the right making a clear distinction. They are after all 2 different things. I'd say if the design was done for the exception (input/output same function) that would seem odd. If you look at Rolands flowgraph he doesn't share. In my designs I've rarely shared. I think the OnXXX for outputs and no OnXXX for inputs is a more clear. I guess it's all preference. Not a huge deal in my mind just a nice to have.

+1 for dynamic navmesh

Does this mean you fixed it or that when you run build navemesh this is what you get? How did gamecreator get the mesh he got which looks drastically different?

I see this same problem. It seems our ability to interact with recast in LE is limited though. Just 2 parameters in the generate navmesh.

Note that models by default (when placed with the editor (code gives options)) are instanced. So you will want a modular approach that uses models over and over again to reduce loading time. If you place 2 or more of the same model in your scene the first one will get loaded from disk, but all others will share the geometry and materials from the first making it basically instant to load those. Taking this to the extreme would be building your buildings with walls and other segments in the LE editor and saving them as prefabs. That way maybe you only really load 50 unique models but from those 50 models you've made 200 prefabs of different buildings. When that level loads it'll be pretty quick compared to having 200 unique models of buildings.

They get named, I think you don't like them, which is why I think you are just comfortable with BMax because it seems like one of the first UI frameworks you've used for a long time. I'm more comfortable with .NET so Mono is my choice if I need to do this (which is rare). I named 2 in my first post in this topic. I would love to see an online/offline HTML5 Leadwerks though. How cool would that be! This would give the best options for UI honestly. Just would have to get WebGL working for the 3D perspective. http://www.tidesdk.org/ http://code.tutsplus.com/tutorials/introduction-to-html5-desktop-apps-with-node-webkit--net-36296 https://github.com/rogerwang/node-webkit This looks to be the best in this space. I might play with this a little to see how this runs. Very neat to be using HTML5, CSS, WebGL, & Javascript to make desktop apps! https://github.com/zcbenz/nw-sample-apps/tree/master/webgl Guess you'd have to deem if the differences between WebGL and normal OpenGL are editor breaking: https://www.khronos.org/webgl/wiki/WebGL_and_OpenGL_Differences

There are frameworks that support cross platform UI most likely better than BMax. You are probably just more used to BMax than those frameworks. However, at some point learning those other frameworks will be better in the long run. Many companies bigger than Leadwerks take advantage of these frameworks to do their UI. Maybe you should make LE all using offline/online HTML 5/javascript/WebGL for the context. That would be pretty neat and give you some nice UI options

Should just pull that last plug on BMax and find something else (for some future release of the editor). Either Mono/Xamarin (so you have a company to yell at) or Qt or something. Would probably set you up better for the future.

I think it would be cooler to have inputs on the left hand side and outputs on the right hand side and somewhere else for the args? I guess for right now to get what you want you can prefix everything accordingly.

Any ideas why not? I change to Meters and have to do it every time. If I forget it's a pain to line csg up. Seems like a thing that should save shouldn't it? I would think everything in Options should save as it's our preferences.

It doesn't seem like the grid units in options gets saved when you change it.

So FFI is working in LE's Lua version?

So I assume you want to use the navmesh. I'm not sure if you can regenerate the navmesh and even if you can if it would be slow. What you can do is have your walls not be navmesh obstacles. Then attach scripts to them to ID them as walls. So now your navmesh goes through the walls. However, when zombies collide with "walls" (you can ID walls using self.entity:SetKeyValue("type", "wall") inside the wall script that you attach to them), you can call self.entity:Stop() (so they stop moving) and start having them play their attack animation to hit the walls. From there you can give your walls health and you could either swap out slowly broken wall models based on % of health and then at the end do what nick says where you swap out a solid wall with a prefab wall that has many separate pieces that all have physics and then give them all mass and watch them fall to the ground.

I'm in beta and I don't have this issue.

I personally would prefer LE force unique names in a map. I hate that you can have the same names in a given map. Just seems to go against reason to me

Give the name of the entities in the map unique names and use that. If they are run-time entities then you would need to save them off yourself anyway since you can't save them in the LE map.