BluHornet

well there is a problem that you call stop once then use the stop function for the count. Unless you are calling stop more than once you will never "count". if you do call stop more than once you are setting local bb every count. try something like this. add a Script.stop to the variables at the top. change the stop function to this function Script:Stop() --in self.stop = true end then in UpdateWorld add something like if self.stop == true and self.volume > 0 then self.volume = self.volume -1 self.source:SetVolume(self.volume) end so in this example the stop only changes a bool that triggers the UpdateWorld passes to start counting and lower the volume. UpdateWorld is looped constantly so this will now count as opposed to the stop function which only runs through once when called.

What you could do is make the crate and then add invisible csg cubes around the crate and make them a child of the crate. Make a short script for each that when the crate is moved a set distance in a set direction from the player when used. you would need to set the direction and distance. something like when used take the crates position and add a set amount to the x and z coordinates of the crate then save that as a set position. then if the set position is not the current position move the current position closer. If I wanted to move "South" then I would change the set position to the current position's x value to the value -2. This is a good application for lerp (linear interpolation). Also some smoothing could make this better. One last thing if this is not done in update physics you will need a time factor for reliability.

It has been a minute since I used c++ but if I remember right there are no line breaks in a sting. If you need to break lines you need to use 2 strings. the newline character is used in cout if you are making a console program. I could remember wrong though.

I notice you are not using a time variable. This could be the answer. Using UpdateWorld is ok but you need to be careful because this is more costly. UpdateWorld runs constantly in a loop as fast as it can. The number of times a second will very heavily based on size of UpdateWorld, Computer Specs, and how many other programs are running. Update Physics only runs a set amount of times a second regardless of speed. By adding to UpdateWorld you could be eating resources that could be used for other tasks. Another problem is that the game could run differently on different PCs. A better machine would allow the player to move faster because the faster computer can loop UpdateWorld faster and receive more movement updates. This is fixed by using a time variable to the movement of the player. All computers will move the player x distance a second regardless of how many UpdateWorld passes there are.

If you do not declare an entity's velocity it is set to 0,0,0 but the physics engine could change that every update physics. To find out the current velocity is you can use GetVelocity().

to check velocity you would need something like in C++ Vec3 playerVelocity = player->GetVelocity(); if(player->GetAirborne() && playerVelocity.y > 5.0) { player.alive = false; } in Lua local playerVelocity = self.entity:GetVelocity() if playerVelocity.y > 5 then self.alive = false end I would probably make the velocity more than 5 but it is a good start for testing. If you feel it needs raised then you can do so. I would also print a system message when you kill the player so you know why you died. This can greatly help troubleshooting later. It can help find the why am I randomly dying question. You don't even have to remove it really. The player should not die tens of thousands of times so it will not bulk the log too bad. Just add a line to the check. in C++ System::Print("Player fell to his/her death!") in Lua System:Print("Player fell to his/her death!")

The easier and less costly way is to make a table of prefabs, ie. PreFab{}, and then place a dummy of each in a distant place on the map with the editor to preload them at start. when you want one to be called (copied) just use the PreFab:Load(). this also lets you randomize spawns. If you have 5 zombie models you can call a math:random(1,5) and pass that as the table position and randomly pick the prefab to add some coolness. I have done this for mobs as well as items for drops before. It looks like this assuming you have populated a PreFab table with paths to the entities you want to spawn. local random = math(1,5) local spawn = PreFab:Load(PreFab[random]) spawn.SetPosition(whateverPos) spawn.SetRotation(whateverRot) spawn.script:Start() you could copy the entity but if something happens to your master the copy will be messed up. with the preload you don't have that issue because you are making a fresh one when you need it but all the assets are already in memory because of the dummies.

there are several ways of doing this one 1. you can compare your players y velocity to a constant pros - fast and cheap, simple code cons - could kill the player in appropriately (fast elevators) 2. you could do a pick and compare the distance to a constant pros - accurate cons - harder to code, more costly calculation 3. you could do a bounding box from the player down and if the box does not return a terrain or scene entity kill the player. pros - a mid level cost, accurate enough, easy coding with minimal bug potential cons - is done on update physics and not update world due to being a collision test. 4. you could do a collision timer on the player. if the time since the last collision with a scene entity exceeds the timer the player dies. pros - cheap, easy code cons - I can't really think of any. This does not mean there isn't any I just can't think of any right now. in short without any other information I would probably just use number 4 but there are other considerations. I am also sure there are many other ways to do this, these are just a few I could think of in the past few minutes.

Ok so the FPSPlayer script passes "self" to the used object's script by base. You can verify this in yours by checking for --Use the object, whatever it may be usableentity.script:Use(self) The self in the () is the key here. It should be in the basic FPSPlayer script. Also you must have a weapon on you before you can pick up ammo. I wrote the scripts very simply to focus on the core of how they worked so I did not add checks to see if you have a weapon yet. The FPSPlayer script holds a weapons table. The table is populated from the FPSGun script when a weapon is given to the player. If the player does not have a gun yet then the table is nil and there cannot be a clipammo variable in it. That is more than likely the error from the ammo box. If that does not work then let me know.

The KillScore variable is made in Part 2 of the HUD tutorial. It isn't done as clear as it could be but it is a global value. To fix the nil error when you have no guns you have to do a check around the AmmoText portion in UpdateWorld(). you want it to check if the player has a weapon and if he does then do the text like the tutorial and if not then make a blank text. If i get time later i will post a video to fix that issue. There are three basic scopes of variables. there are global and local. there are two different scopes to local variables. that confused me for a while. Global variables are accessible and modifiable in all scripts in the program. Global variables are made by adding them to the top of the App.lua file. and you do not have to say Script.variableName = whateverValue you can just say variableName = whateverValue It is a good practice to avoid global variables as they can become confusing and lost in the shuffle. Local variables come in two scopes. The easiest way to explain this is probably one is local to a script and one is local to a function. A local variable to a script is the ones that are at the top of a script and have the Script.variableName = whateverValue they are only in the scope of that script and are not usable outside of the script they are in without calling that script with the entity.script.variableName A local variable to a function is they type you see the line "local variableName" and they are only in the scope of the function they are in and are not accessable outside that function unless they are passed through the return of the function. This is probably alot of confusing due to my poor explanation. I am planning on doing a basic Lua tutorial to explain alot of the things done in Lua and how they work. I have been reading Programming in Lua (PiL) a book written by the architect of Lua script. I have learned alot.

Also tip for the guy that spent a lot of time trying to fix issues. When you set the blend mode to alpha at the end of that function set the blend mode back to solid. I have had other rendering issues due to not setting the blend modes properly, typically when more than one script is using context.

Actually I though of a another idea. In the collide function of the ground script add if entity.script.groundCollision ~= nil then entity.script.groundCollision = true end Add a variable to the objects in the array groundCollision = false. Then when you use that variable for what ever you are doing reset the groundCollision to false.

Oh I missed the issue sorry. Have you resolved this problem yet? If not what entity needs to know which entity collided with the ground? If it is the ground itself then that is easy. That data is the entity parameter of the collide function. I would just set a self.lastCollidedEntity and then in the collide function have a line like .. self.lastCollidedEntity = entity If another entity needs to know I would do the above to the ground and then in the function that needs to know you can retrieve that variable from the ground.

so could you try this? Add to the ground script that a collision calls a function in the script of the colliding object. That function could iterate through the array and call to the parts that need told that the character is on the ground. Another way is to use GetVelocity (http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/entity/entitygetvelocity-r73) to check if the y velocity is above a set Dead zone. The dead zone is to detect walking up and down stairs from being airborne. A third way is to check the distance from whatever member of the array to the ground and if it is greater than the normal +/- a dead zone value then you are not on the ground.

you can access the key values of the colliding entity with GetKeyValue and then check if the name is the same name as your floor / ground. The colliding entity and collision position is passed into the method by parameter.

I am confortable with Lua scripting but I could do things easier with a C language than can be done in Lua. A few years back I dabbled in C# so I grabbed a C++ book and started leaning. I find pointers, references, and other memory manipulation confusing. I realize that I will grow accustom but why if an easier system was available. I will just have to get use to it. I do plan on using both in the future. Right now I am working on a Lua only game while I learn C++. Thanks for your responses!

I know that Lua and C++ are the advertised languages. Can I use other languages like C# or visual C# to edit my .sln file? I would like to use C# if possible. If I cannot is this something being considered for future development?

I don't know if it will help at all but have you tried increasing the friction value with Entity::SetFriction? I know this effects AddForce but I have no idea if it will do anything for Move.

Would using collision type debris instead of prop for the corpse work. I assume your hit box is a collision character? Debris will collide with scene and prop only. I had to do this for items dropped by enemies due to the one following "tripping" over the drop.

Well if you don't have a lot of game stats you could just use global variables. Those variables are accessible to all scripts.

Thank you for your excellent videos. I knew nothing of scripting a month ago! Now I feel comfortable with Lua and have begun C++!

Video is up for the sway and scatter modifications when aiming down the sights

I have an ADS video on youtube. I have on my list of videos to do a scatter and sway mod. I will bump them up on the priority. I should have them done in a day or two

Attached is a link to the videos I made showing how to script respawns.

I think the noise in the video is from poor routing when I built my computer. I will try to see if I can filter it out or may have to adjust the wires.