Rick

I have others on that channel you can check out that help with various other things. Glad you liked it.

I did a tutorial on a weapon pickup that does this. http://www.youtube.com/watch?v=VWBGtJ7NQ4Y

@Dude, yeah you could make an AABB (bounding box) and do collisions or you can do what NA was saying, which is faster and can be more accurate. I think the differences are probably pretty small but it is technically faster and more accurate the way NA has mentioned.

I seem to recall the radius parameter of the pick doesn't work right now? Maybe I'm wrong, but I seem to recall that being an issue. @beo6 I'll test this out when I get home. Try not sending an extra parameter once to see if that helps with the error. I assume that script is attached to a camera object so that self.entity is the camera object? I'm sure the example was just copied and pasted from the AABB function.

How do we set the value of the currenttime uniform again from the game or is that a special variable that all shaders have access to?

All that does is run code behind the scene. Baby steps YouGroove If this works out then we can get to a point where a UI can be made around it.

Is there a way to do this for like lava/water in a river/waterfall or something where we move the UV mapping to make the texture look like it's moving?

You can do it via code in Leadwerks. I'm working on a framework using coroutines that allow you do define cutscenes in your game in a fashion like: -- any function name with Async will do it's thing and return right away -- any function name without Async will wait to return until a condition is met. however it does return the entire program each frame so everything else runs and it's not blocking. this is the magic of coroutines in lua function MyCutScene() PlaySoundAsync("Sounds/speech.wav") PlayAnimationAsync("player", seq.Walk) MoveTo("player", "marker1") end I have some of these working, but working out some details still. Oddly enough the Async functions cause more trouble and make this harder because they require tracking things still, but need to return from it's function call right away. For example MoveToAsync() needs to start the movement for an entity to a certain location, but return right away. Well, I have to check somehow if the entity got to the location and stop it from moving when it does. Why would you want a MoveToAsync()? Imagine you want to start 2 actors walking down a hall and having a conversation. MoveTo() alone doesn't come back until the actor (1 actor) has reached it's destination. With MoveToAsync() it'll start the process but then return right away so you can start another MoveToAsync() and make both actors move. Then you can PlaySound() to play the conversation.

So I think you are talking about split animation. Basically where you play different animations on different bones. The way you would do this today would be in code not in any setup of the model. I've done this with my own animation code but I think you should be able to do it with the current AnimationManager class that the enemy AI script uses. You can find a bone by it's name with: self.spine = self.entity:FindChild("bonename") Then you should be able to make 2 instances of the AnimationManager class. One will be for the entire model and the other will be for the upper 1/2 (which you'll find some kind of spine bone for). So now you always play the "base" animation manager first and the "spine" one second. So then you can play the "run" animation on the entire base, and in the same frame play the "shoot" animation on just the spine (or whatever bone would control the top part of the body). This "top" part will overwrite the values that the base did for the top part only and so you've now split the animation. You can also, in the Script:Draw() AFTER calling animation managers Update() method, rotate bones around to make the character lean if turning and so on. You could also play for only the top 1/2 and bottom 1/2 instead of the base (total body) and top 1/2. This should save you calculations as playing for the entire body then overwriting for the top 1/2 wasted some calcs that never got seen. How you transition back to entire body though can be a little trickier as you would want them to, say, go back to animation after reloading on the top 1/2, but if they are separate you'd want to sync them so they are both on the same frame to look normal. If you play the entire base, then you don't have to sync them, but just stop playing the reload and the base will blend back in for the entire animation ensuring everything is in sync.

I did, but it was just more of a question on what he was meaning with his description.

So beo if you were to go NA's route, which sounds faster, and the entity script route I think you would need the following. 1) Whenever an entity moves you project it's 3D position to 2D position and store that in it's entity script. Ideally you'd have a way to tell if it's visible at all by the camera, but I don't think there is a great way to do that. There is this function: http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/world/worldforeachvisibleentitydo-r506 but you'd have to figure out a way to do this that isn't expensive. Instead of using that you might just project all entities when they move no matter what because you probably wouldn't want to call that inside all actor scripts. You could maybe do this inside the camera script and set some flag for that entity or something. 2) Now that all entities/actors have a 2D position in your camera script where you do the selecting, you just cycle through all visible entities (using the function I posted above) and check that it's x value is > the left of the rect and < the right of the rect, and that y is > the top of the rect and < the bottom of the rect and now it's selected. It's an extra step of tracking the 2D position for each entity, than the AABB method, but like NA says it's faster (with a memory trade off to store the 2D space, which is small anyway).

What do you mean project entity pivot points into 2D space? Do you mean to project ALL possible entities position in the scene to 2D space each frame, or at request time of selection, and to use that to check against the 2D rect? Why would that be considered faster than using AABB? I mean he could possibly have hundreds of entities on screen depending on his game. I would think that would be slower to project every entity to 2D space than just project the 2D rectangle to an AABB variable. The looping of entities checking against some area still has to happen either way so that would be the same for both, but with the AABB at least you are only having to project 1 thing vs possible hundreds, so I would think using AABB would be faster, but I'm interested to hear why you think otherwise.

If you know the AABB dimensions of the shape you want to make, then you can easily do some basic math to see if it would fit.

What Christian said. Then use http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/world/worldforeachentityinaabbdo-r66 The bummer about the callback is that it's global, but it has an 'extra' parameter which you can pass 'self' to if you are using entity scripts for this, so that you could add the entities to a table that 'self' has.

http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/context/contextsync-r48 It's done in App.lua in the Loop() method.

If I understand correctly, you could put the same named textures in different folders maybe? Then make the different materials in different folders also.

Oh wow, that's pretty specific. I wonder if creating that on the fly in real-time would be FPS friendly. In that example I would think those would be smaller model segments that get loaded (instances loaded) and displayed right away. However, because the bike looks like it could cover the segment up it looks like it's coming from the back of the bike when it moves. It's like the bike is dropping the model segments as it moves and it's position is inside itself so as you move it looks like it's coming out the back.

Yeah, I think this is a bug. Go to your project directory where you are creating these and see what's in there. You can manually delete things if you need. I have issues with this for scripts and other things as well.

You mean trails from bullets? Tracers? http://static.fjcdn.com/pictures/Tracer_fff352_43964.jpg

It auto updates for me (like games do). The main difference between the steam version and other versions coming is that the Steam version uses Lua and Windows only. Other versions will support C++ and other OS's, but 100% of the editor functionality is the same, and about 99% of the API is the same. I say 99% because the engine is written in C++ originally and so things have to be exposed to Lua, and something might have been missed or overlooked. The C++ versions actually exposes a lot of class variables that you can use, but isn't technically supported and not all of those are exposed to Lua because it's not technically supported for us to use.

np SeaHorse. It was probably my favorite one to do so far since it was a little more involved and interesting! Everyone, please list out anything you'd like to see that isn't already on the front page and is programming related and isn't a huge system that would take hours to explain in a tutorial.

?? When you create a new project it gets it's own project folder. File->Project Manager and create a new project and it won't have anything to do with MyGame.

I once had this happen as well. The child bones of a model somehow broke apart of being a child of the model and it screwed things up for my map.

If you want a 2D line to look like it's in 3D spce (but it's still 2D) then you can use DrawLine() along with the Project()/UnProject() functions (check camera or world in docs) to translate a 3D point to 2D point and back. A 3D line really doesn't exist though. At that point you are using a 3D model to represent a line and scaling it to get the length. If you want to do that you can make a csg cylinder, attach a script to it, save as prefab, and use that.

DrawText() will only be seen on screen if done from the PostRender() function. Lua doesn't have any idea of private. You can still make getters/setters of course but the language itself won't force any rules of private. Games aren't real-life . You are correct that you could do exactly what you are saying and be more real-life like, but there are a million ways to skin a cat in the video game world you know