Rick

Maybe a generic message system could help with some of this C++/Lua communication people are asking for. It wouldn't require glue code and messing with the Lua stack that much really and would be more streamlined. Basically in either C++ or Lua you can register to a ReceiveMessage() hook (don't forget passing extra param like some others do) and then you can call SendMessage() from C++ or Lua to trigger the hook. --from lua (all msg data is wrapped as a lua table) SendMessage("update.health", { self.health }) --from C++ (receive msg hook) ReceiveMessageHook(RECEIVE_MSG, &OnReceiveMessage, (void*)extra); // the LuaTable part would be the part needed to make this work. needs to be an easy interface to get data // from the table void OnReceiveMessage(const string msg, const LuaTable& tbl, void* extra) { }

window.

Did you assign it's physics correctly under the physics tab. Is it set to character? Your enemy needs to have a character controller to be able to move. I think it may need a mass too, but don't recall and not at PC that has LE atm.

auto just picks the type for you. You don't have to worry about knowing the type (like int, float, string, or if it's a class instance). It can just make it easier to type because you are telling the compiler to work that out for you while it compiles. You can think of it as just being lazy . The main idea with the for loop is doing the : list part because it saves you from having to worry about the stl stuff (.begin(), .end(), iterator stuff which makes teh code look more confusing.

Could use new C++ features to make it easier too: This should work: for(auto e : world->entities) { }

Looping over the world entities and checking names. I think world->entities is the list you want to loop over.

https://github.com/kikito/tween.lua This is a lua tween library (I didn't make it). Honestly something like that built-in would be ideal. Would be nice to just be able to say move from here to here over x seconds using this kind of easing.

self.entity.world That part looks strange. Are you getting an error? I've never checked to see if self.entity had a world variable in it. I would think it wouldn't. Usually you could get the current world at the top of your function or store it in a variable in start. function Script:UpdateWorld() local world = World:GetCurrent() -- now use world:Pick() end

self.entity:Move() self.entity refers to whatever entity the script is attached to. It could be a model, camera, pivot, csg, light, etc. it's a special variable that Leadwerks creates and assigns for you.

player in your script is just a vector (it's just a 3d point in space). It's not a cube. It has no visual to it.

In Dead Anyway we have a bunch of stats that are all 0 - 100 like thirst, hunger, sleep, temp, etc and we use a weighted average from those to make the overall health value. Thirst is the highest weighted followed by sleep/rest, hunger, temp etc. This tries to mimic real life in terms of how long you can survive in real life converted to game days.

Bah nvm. Forgot to call GetStackSize() before doing this.

I've exposed C functions inside DLL's just fine to lua, but now I'm trying to expose C functions from the LE exe to lua and getting an access violation error when I call lua_pushcfunction(). I can call the C function just fine in the same place so not sure why the access violation is happening. bool App::Start() { // calling the function I"m trying to register works so the function is valid UpdateStat(Interpreter::L); // register lua to c++ functions lua_pushcfunction(Interpreter::L, UpdateStat); // this fails with access violation error lua_setglobal(Interpreter::L, "UpdateStat"); } static int UpdateStat(lua_State* L) { return 0; }

I agree. My posts weren't to try and make people do otherwise but to just show the benefits so maybe more people put more pressure on Josh to officially change the style with that script and maybe other bigger ones like it Josh does listen to the community but if only 1 person is voicing his opinions it's harder to get any traction for change. I think the fps script is starting to get to a tipping point the more people want to add functionality around it. 721 lines. That's a lot of code in 1 file. I remember going through HL's code and was amazed at how small and modular it was in it's class design. Each function was 1 screen or less, often times less and from what I recall there weren't a ton of functions to a class. They separated things out nicely.

I understand the purpose of this post and I don't have an issue with it and think it's great you provided your time to help but it highlighted the overall script design philosophy that Josh holds that I don't agree with (completely) and the fps script is a prime example as to why I don't agree with it and how we see users follow in that idea even if it's to just get the basic idea of something. If Josh took a more modular approach and broke that script out more you would have been less likely to go "inline" with your example and instead follow the pattern. The flashlight would have already had it's own script so you would have just modified that script and it would have been much easier to get the idea across and for Firebal to implement and potentially understand and play around with modifying it without worrying about screwing up the rest of the fps script. So really this was less of an issue with what you did and more with the "One object, one script, zero ambiguity" idea when scripts start getting rather large which is very common in all games. I generally avoid that script for anything but a quick test, but I might take another look given this recent topic and split it out. Don't want to get too sidetracked from Dead Anyway (saying that in case tj is reading this ) but shouldn't take that long as an exercise. The flashlight is an interesting and perfect example of all of this though. The idea of a flashlight can be pretty broad as we've seen in recent games. Cameras, cell phones, lamps, etc have acted as "flashlights" in games. Given a common interface for a "flashlight" it can really help people implement their own and separate out their logic to it's own script for easy distribution/maintenance/extensibility/etc. Really it comes down to what josk alludes to. Big scripts end up more complicated and fragile when modified than breaking out logical parts into multiple scripts. 1 script is great when you give it to someone who just accepts it and plugs it into the game, but this ends at the very basic beginner level in users. They soon want to start customizing their game and I feel it's easier and more friendly to do that (for everyone) with smaller logically broken out scripts that do their specific job without bleeding responsibility into other areas.

Not in this specific case of a flashlight. You provided a basic flashlight. It wasn't indecisiveness on your part it was just providing basic functionality. You provided a basic template and he wants to extend it, but you didn't give a very good environment for extending it. Even so though, indecisiveness is a human trait. We don't know everything. You've changed many things over time. We aren't perfect so making this process easier seems like a good idea. That's part of the idea. We aren't perfect and we may want to try many different things. This would also make people like the OP's job easier to provide such functionality if the environment promoted this. Right now he's following in the footsteps of your idea and that script just got bigger and messier (but it was kind of him to help for sure). If your template broke these things out, he'd be more inclined to follow that design pattern. This isn't all life or death stuff obviously, but it makes script writing better in my experience.

Yeah, we've had this convo many times and don't agree My time is short but would be interesting to see a clearly broken out fps script to see the difference in readability/maintainability/extensibility. I'm not talking component design to an insane level here, just classes that you manually include into the script to break out logical functionality. Movement & animation still makes sense for FPS script. Flashlight and all that goes with it seems to make sense to break out. Firebal could have taken the small and easy flightlight.lua file and adapted it easily enough to add his functionality I think. At least the task wouldn't seem so large and overwhelming as it does when he looks at the fps script today.

I think some of these features would be best to be broken out into their own classes. Flashlight seems like a prime candidate for this. The FPS player script is already a big mess. Plus integration/distribution/understanding/modification will be much easier. I think a great deal of things in the FPS player script could benefit from this and be much easier to manage and read.

It's a very noble thought and I hope people have the time to help. It just generally doesn't work out that way very well and so knowing how to turn these higher level ideas into code yourself is a huge benefit. I understand though.

I vote color. I like color.

I do provide starting Lua training for people. It's $10 for 1 hour and I've worked with people that have zero programming skills before. I'm very patient and understanding and easy to get along with and have about 15+ years programming experience in total. You seem to be a person who would benefit from 1 on 1 training as you have the desire to learn but probably learn better from a person than some textbooks. Hit me up in a PM if you are interested and we can work out a time. It'll go a long way with you I think.

Is this more about sound than visual? A decent way to handle this could be using http://www.leadwerks.com/werkspace/page/api-reference/_/world/worldforeachentityinaabbdo-r66 Use the players AABB which there should be a function in the Entity part of the documentation and then just add to it's values to make it larger when running/walking and smaller when sneaking. The function itself will return all entities in the bounding box you provide it. You can then loop over all entities and if one of them is a monster alert it. The thing is we are giving you basic ideas and not typing the code for you. Are the basic ideas all you need or do you need actual code typed because you find it hard to translate a design we tell you to actual code?

If you mean some AI characters there must be some variables in the script to deactivate it that you might have to do.

Can you just make a folder for precached assets and put them in there?

Perfect thanks!