Thank you again, Tobias.

I'm trying to keep this program relatively small and simple. I'm basically trying to learn how to do these things which I'll need to do in the real game. I'm just about to fix the toggle_engine() function in a minute. But I agree, simply overlooking a problem and ignoring it is never good. All I did was re-do the Panzer and its tracks as separate entities, and the Panzer now creates its tracks when it "spawns" in to the level. I also fixed the skins, which had a funny alpha property that made them semi-transparent. Oh, and I need to find a way to dim the lighting on the terrain. I've got a few different terrains for this project. The one I call "Das Sandbox" is just a 5km X 5km desert terrain for testing vehicles, weapons, and other things. The "real" terrain is several hundreds of km in size, and covers the better portion of Libya (and yes, it's extremely accurate... I made it with space shuttle radar mapping). I've got excellent high-res textures for them, but they appear far too bright under the sun.

But anyway, what do you feel would be the best way of going about animating the track skins? As far as placement, should they go in the tracks' actions, in the Panzer's action, or maybe in main()? I want them to precisely follow the movement of the tank, on time. They've also got to move differentially, for turning the tank, going in reverse, and "spinning" the hull. The Panzer IV G could *almost* turn in place, but it did have to move a little bit forward or backward. It couldn't turn on a dime like a modern American M1 Abrams or German Leopard II, lol.

And one offtopic question if anyone knows:

Is the Lite-C language capable of making a truly realistic and convincing flight model for aircraft, or should one stick to C++ or Java for that sort of thing?

I would animate tracks by shifting the u or v values directly in the track entity action, getting the animation speed from the parent entity. For easier code, design the track entities so that they have the same origin as the main tank entity. This makes it easier to rotate them with the parent entity.

I've fixed a few things. I was having a weird problem where the tank actually floated 2meters above the ground. I changed the model's origin, and it started working correctly.

Also, I was being silly when I was frustrated to death earlier, and changed the tank to a sphere to... uh... kick it around and vent some anger, lol. And I noticed the tracks didn't stay mounted to the tank. So I added:

my.pan = panzer.pan;
my.x = panzer.x;
my.y = panzer.y;
my.tilt = panzer.tilt;
my.roll = panzer.roll;

...and now the tracks stay mounted to the tank no matter which way it goes, rolls, turns, etc. I've also modified the tank model by adding some invisible, unconnected vertices at each corner, where I want the collision hull be. Then I used vec_for_vertex to get the position of each one, and use set_min/max to create a properly scaled bounding box. I guess I'm not quite as stupid as I appear! LOL!


However, the method you mentioned for animating skins is problematic for me. It's done this way in the dozer demo everyone suggested. When I try to compile his source code, it crashes, due to the dozer's track action, right at the line where the u and v values are shifted. For some reason, my engine doesn't like those instructions. Plus, I can't find any examples of how to do things like this that actually work. The manuals are pretty vague on such topics...

Hmmm... Does it require you to include mtlfx.wdl to use the u and v shifting instruction?

No. I use the same effect for a waterfall and it works fine. mtlfx.wdl is for old A6 WDL only and can't be used in a lite-C file anyway. When you attempt to include that, you'll probably get tons of errors because you cant use different languages at the same time.

Maybe your version is too old? But then it would not crash but give an error message. Use the debugger to find the line where it crashes.

The u,v parameters are not in the manual, but they are in the atypes.h file with the remark "texture offsets", and thats what they do, at least in my game.

So whats the code you are "trying" to use with the tracks for the texture movement?
Can you post it? Say, the whole, current, tank action, or the track actions if its in there.

Sorry, I said "crash" again when I meant it won't compile and gives an error message. I tried including atypes.h at the top of the dozer demo code, and it still won't compile. And that's a program I KNOW is coded correctly.

It says:

"... 'u' is not a member of ENTITY..."

I think that's line 142.

It had some other errors at the first few lines when I first tried to compile it myself. I added default.c and acknex.h, and then it started getting errors at that line. So including atypes.h in the dozer demo still won't compile.

Well, I'm not even trying to animate the track skins anymore at the moment. I deleted the "junk" code I was using earlier. I figured I needed to get the tank moving around properly first, then figure out how to animate the track skin and make it match the movement of the tank.

The tank now is properly acting as a physics object though, which is much better than before, and the tracks stay on at the right place. Oh, I also fixed the problem where toggling the engine made the camera unlock from the tank. I needed to include the camera update code in the while(engine_state ==1) loop in the tank's action. But here's the thing bugging me now:

How to get the camera to "chase" the tank, and pan with it, staying directly behind it at all times. In addition to this, the vector of the forces I'm applying need to be linear, and in the same direction the tank is pointing. Right now, the force just pushes the tank in the +x direction, even though I've tried vec_rotate. The camera is also screwed up. It does follow the tank, but when the tank pans, the camera pans behind it, and you lose visual on the tank. I haven't figured out how to make the camera pan while keeping the tank in view.

This made the chase cam concept work better. It's still not quite how I want it though:

// Update camera positions
camera.x = panzer.x - 50 * cos(player.pan);
camera.y = player.y - 15 * sin(player.pan);
camera.z = panzer.z + 25; // Position relative to tank's z position
// Set camera tilt and pan in order to look at the tank.
camera.tilt = panzer.tilt -15;
camera.pan = panzer.pan;

Now I've got to figure out how to ensure force is only applied in the direction the tank is facing for forward/backward movement...

EDIT: Silly me, once again. Changing "...player.y - 15..." to "...player.y - 50..." has fixed the camera. Ok, camera problem solved.

But I still can't get the vector for forward movement working right.... It pushes the tank in the direct +/-x direction of the world, not the tank, or it just does nothing if I change things...

Ok, I've fixed this so that the force now pushes in the tank's facing, rather than just the world's x axis. Major improvement!

Only thing now is I get a little "slip n' slide", or "yaw/pan" as the force pushes the tank around now (probably due to the friction/collisions with ground as it moves). As you know, tanks can't move sideways, not even slightly, lol. So I wonder how to fix that? I've been giving it some deep thought, but haven't even had an idea worth trying yet.