Road Kill Kenny

I'll sit this one out. Good luck

You don't need to use timing at all. You simply need to store the value of the last rotation and then compare it to the current rotation. Then if the difference is enough to warrant a turning animation then you tell it to animate. //In class declaration float lastRotY; //In the your update function or whatever you call it if(lastRotY-EntityRotation(player).X>= [a value here]){ //Play Turning Right Animation } else if(lastRotY-EntityRotation(player).X<= [a different value]){ //Play Turning Left Animation } Do something like the above. Though you will have to make up for the fact that when you get to 360 degrees it loops back to 0 but I'll let you figure that out.

Can't wait for winter (my winter your summer) all is looking pretty darn cool.

This is true. Go with C++ or bMax or anything that is actually a coding language and not a scripting language. Many people have gone through the motions with coding entirely using LUA and they all come to the same conclusion: - Keep Lua as a scripting language as it is intended. It is true that LUA is much easier and simpler than C++ and other languages. However, will lose the benefits of C++ or other coding languages if you only use LUA.

1. Pretty sure it does but I'll let someone else answer for certainty sake 2. No. Not in the way he explains it though pixel. What he means (or at least my interpretation) is say you have like 5 barrels standing there as separate objects. Then when you zoom out to LOD level. Those 5 barrels are linked to an LOD of 1 object that is 5 barrels. So the 5 objects become one object at the LOD distance. 3. No. 4. No you don't have to use it with the editor only. You can use whatever you want to create terrain models and then load them into your scene with code. Note that these above answers only relate to LE2.X. I have no idea for LE3D as we don't know still exactly all the features as it's still in development.

Yeh that could work I guess. Might look a bit odd tho. Not sure. Player probably won't notice Either way judging by the picture you probably only need to increase it by a tiny bit to maybe 0.45. Alternatively you could just make his arm a tiny bit further back. Does seem like its sticking out a fair way further than it needs to be.

If you are using the LE controller. Simply increase the radius of your controller so that it collides with walls before ur weapon goes through them. The default is only 0.4m. TController CreateController( flt height, flt radius, flt stepheight=0.5f, flt maxslope=45, flt crouchheight=0 )

It would work. However, as you say it wouldn't be ideal as you'll have a bunch of bones that don't do anything. I had a lot of trouble with this myself and unfortunately I never came up with a solution that was as ideal as I would have liked it to be. Apparently the best way to do this kind of thing is to actually weld vertices using code and apply bone weights using code as well to the added parts. However, I'm pretty sure you can't do that with LE itself. Perhaps there is a way to do it through OpenGL. However, I wouldn't know where to start there.

Ok I fixed it. I think my problem was loading a texture before the graphics window was created or something like that. I'm not really sure but I just reverted to putting all my Initializing code etc. close together again and it worked. Phew...

Having a rather odd issue here. Loading textures seems to be failing even though they are located in the correct location. Here is the output of the console for the failed load: Here is the file path being shown below: C:UsersPublicScarlet Thread Games01 Game ProjectsHome WarsHome WarsAssetsMenuBackgrounds As you can see, it is searching for the files in the correct location and the images are indeed there but they fail to load. I have loaded these before in a different project so I know that the file is fine. Anyone have any idea why? Anyone had a similar issue before? Please don't tell me that I've set my abstract path wrong because I haven't. The output in the console shows that its looking in the correct spot.

This all looks great. Can't wait.

You could possibly use HideEntity() on just the mesh instead of the whole model. I'm pretty sure this would leave the physics box alone and allow it to continue doing its thing. However, I've never had the need to do that so I haven't tested it out. You'll need to use FindChild("mesh"); to get just the mesh. This is also possible. However, alpha = more processing = slower.

Can't wait to give it a try

Everytime someone votes on one of these poll threads it gets bumped... whether that person posted or not

The naming convention is correct. I think your problem may be that you are setting the LOD distance of your base model (LOD0) to 5m. Meaning that you'll only see LOD0 base model in 5m distance which your screen shot is actually closer. Try replacing object.model:SetLODDistance(5,0) //with object.model:SetLODDistance(0,0) //or just delete the line all together Not sure if this is the actual problem. I have never set the LOD distance of the base mesh (LOD0) so I wouldn't know what happens. This is just my hunch.

It sure is a tricky one and there is no function to simply reduce traction. You have to make it yourself by applying the correct forces to the vehicle to fake momentum and also to stop the tyres turning. Its pretty difficult to get right. But yeh no single function will fix it

Yeh you need a solid understanding on the LE vehicle setup. I wouldn't recommend making your own from scratch at least not at this point. Once you have the standard LE vehicle down and you're happy with it, start experimenting with adding artificial external forces. I would recommend: 1. Determine the major 'real forces' that happen on cars in real life, (i.e. drag(most important), momentum, friction etc. etc.) 2. Decide which ones are the most important. 3. Calculate approximations of these forces (or rather make ur code approximately calculate these values). I can't stress enough how you must not try to get exact figures.. You will only get frustrated with that and 99.999% of players won't know the difference between a slight approximation and a perfect calculation of a force. The external forces are rather tough to get right I found, so prepare to play around with them a lot. Oh one more step 4. Determine when the forces are applied and how you want to trigger them in game. For example I made my car loose traction when a function of its speed and turn angle was greater than a fixed amount. Good luck.

and maybe you should turn on the Godrays as well

Don't you think Josh looks a but like Robin Williams in that last shot. Oh and what was Robert's response to Josh's question? I'm interested

Look I'm not mad I'm just applying logic to the situation. Maybe you read my post with an angry face on. I don't know... You're not wrong Cassius and perhaps my last line could have been written better. Yes its valid information, in its entirety its not a waste of space but it didn't need to get bumped and everything new pushed back.

Are you high or something? Cuz nothing you're saying is making any sense... you just bumped a 2 year old post where the original poster is long gone and his question was answered. No he is not still asking for an answer... He's gone... nothing funny about it. Unless you are the original poster from 2 years ago in which case this makes even less sense...... I didn't really want to bump this thread because it is a waste of space on the forum but I just can't take this anymore.

Carefully..... I'm serious..... That's the only way I can describe it in a single post. Go to http://www.sqlite.com/ and try figure it out. Personally I think you're jumping the gun. You need to do something simpler first. The kind of stuff that I'm talking about is not particularly easy to implement, In the short term it is a longer path and more difficult that simply adding in some XYZ's. The SQLite method is... yes really good because it makes things easier in the long run.... but takes a while to set it up and to figure out how you want your code to flow around it. And not to mention there is not step by step way of doing this. you have to do it in the way that works best for your game..... now if you don't have much experience with this kind of thing then chances are you're going to re-code it a number of times to work nicely. Although, it's not rocket science either... its definitely not a starting point. I would suggest for now... just place objects in the editor... look at their XYZ's and then hard code those XYZ's into your C++... just for simplicity sake that is. Yes it may be annoying to do that but seriously just do it or risk bear trapping yourself.

Much like lights etc., that you can place in the editor, you could create a (pretty much) null entity that you can place in the editor and set its keys etc. You would have to code your own 'Load Scene' function so that when it comes across one of these objects it simple creates an instance of your ammo class and places it there... However, the above would work, I wouldn't do that myself... The way I do it is to make the game and have all positions in a database (SQlite) then while im in game (Debug Build only) I can press a button that makes the game go into dev mode which allows me to move things around. Then when I'm done it re-saves all the new positions into the database so next time it will be right. Its sort of an editor but more like a visual database editor. My UI system works like this too.

Don't wait for this. If it ever gets finished it will be a while. No offence to the creator of weaponwerks intended. He is busy studying or something I think. Smash has it right. Do it like that, make a weapons class with a base class which holds everything common to every weapon. Then make sub classes which inherit from the base class that have more detail specific to weapon types.

Hmmm, I'm having some problems with it. I see some of the images but a lot of the time the screenshot viewer shrinks and doesn't display an image. I'm using google chrome so maybe that's a factor.