TA3D 0.4.2 TEST 2

[zuzuf]

Many fixes, and above all a working pathfinding (NB: the path simplifier might produce imperfect path that can lock units on some maps, because of some simplification I didn't change yet, but it'll be fixed shortly, I just discovered I forgot it ).

There is a new quick restart mechanism when you change options that need restarting, but currently it works only on Linux since it uses a script that hasn't been created for win32 version.

the configure script doesn't accept Allegro 4.2.0 any more since it has bugs known to crash TA3D, update to 4.2.2.

A new texture cache!! Yes there is a new texture cache to speed up loading on slow machines, but the first time it'll be slower (it has to build the cache). Texture cache system is disabled on ATI cards as well as mipmapping for non power of two textures (still on ATI cards only) because textures were corrupts.

Get it there:
TA3D 0.4.2 TEST 2

[Balthazar]

Got it Time to do whole amount of testing, since this version should be ready for it.

[zuzuf]

beware that you shouldn't notice two of the main improvements since you have an ATI card (the texture cache) and you run windows (quick restart system not working), sorry about that I've been very busy fixing things and I couldn't find the time to write the ta3d.bat file to monitor a ta3d-bin.exe binary like on Linux.

Also you should notice the ATI workaround and there shouldn't be any corrupted texture.

[zuzuf]

Oups, I've just discovered a bug that made texture cache unavailable for win32 ... it didn't create the cache directory so opening cache files failed silently (it doesn't crash the program )

[sieistganzfett]

pathfinding is a lot better than before. at least the units have a chance to get out of trees, such as on "great divide." however units still like to walk off cliffs, which doesn't work to well since the slope is to deep for a unit to just walk off of a cliff on "shore to shore" units still get stuck on trees with no other solution but to destroy the tree the unit is locked on.

does the pathfinding know about hills, cliffs, etc? it seems to get past trees better than before. i dont understand why they just lock up on a blockage and refuse to even move backwards.

pathfinding ideas..

when a unit hits a dead end, have it turn right, walk 10 pixel, head in direction it wants to go, try again. if fail, try heading right again 10 more pixel and retry.

have the unit when stuck on something just stop there and give up.

[zuzuf]

hm, I'll see what is going wrong with hills and all, should be path simplification code, I've made some tweaks to it since TEST 2, maybe it was that, maybe not, if it's something else then I'll debug it .

your idea about unit unlocking is great, I'll implement it when I have time.

[Balthazar]

Dead end may be just another unit heading the same way... I don`t think that using the same method ilke the one is above is a good idea. There should be different methods of avoiding, considering blocking object. If it is map terrain - do 1 (like rotate 90 deg and move); if it is a map feature (tree, rock and so on) - do 2; if it is a unit - do 3 (like wait 4 sec and try again); Anyway, if pathfinding works fine all this things are unnecesary.

They are usefull only whe pathfinding doesn`t work as it should.

[zuzuf]

you can also run into unexpected situations:
a unit dies just on your path a few msec before you get there ... pathfinding can be as good as you want if it's not updating in real time you can't avoid this (and real time update isn't possible for pathfinding, it's just too slow).

We have to handle unexpected things here (and we've to do this before pathfinding becomes too good otherwise we won't be able to test it )

[Balthazar]

Well, in this case pathfinding should update path ONLY when unit can`t continue it`s way. So if unit runs into wrecage - pathfinding should return new path to the destination, so unit could continue to move.

There is no need for super-see-unit, that is aware about all the things that MAY happen, or updates it`s path every 1 sec, where is some kind of realism? While unit don`t see obstacle (see not with eyes, but around for some number of squares) - it shouldn`t use it in pathfinding process. Unit just must be able to find a NEW path if current is blocked and moving, while new obstacle appears.

[zuzuf]

yes, it's how I see things too. But the point here is that a unit can get locked if it cannot move anymore (because of an obstacle). It already updating its path when it runs into an obstacle ...

I think it should behave like this:
_find a path
_follow the path:
1) can go forward then go forward
2) can't go forward, then it's locked into something,
refresh the path, then start following the path without locking (very important because the obstacle might prevent it from moving, and currently it's not working that way)
3) once the path is clear, start monitoring obstacles again

[Balthazar]

Yes, it seems to mee the same way. The only problem here is locking of the unit, that shouldn`t happens. At least if unit is locked it should be able to move a little backwards after rotation...or...TURN ON THE BACK SPEED!!! Yeah, wow! I`ve got an Idea! Why units should always turn to move back, let them sometimes move backwards!!!! In times, when unit should cross a small distance after reaching the obstacle - let it move BACKWARDS!!! And then forward!! This can also greatly speed up moviend in a group and make units looks more intelligent!

[Balthazar]

Looks like my new uberidea will die unnoticed Also, thinking about it more deep - absence of back speed creates enormous difference between tanks, because when tank with slow turning speed gets to an obstacle or another tank and begin to rotate to 180 deg to move a little, then rotate again - it is enotmouse of losed time!!! That is shouldn`t be!!! Imagine the same situation, where tank can easilly ride backwards and turn 10 deg to avoid obstacle and continue to move forward!

[zuzuf]

indeed it's a huge waste of time.

Maybe we can do a basic check to see if the unit can come in the bloc which is just in front of it (or maybe a few blocs) so if it's blocked, then refresh path, maybe slow down a bit and avoid it .

Also going backward implies changing lots of code in the path following code, but we might be able to make units bounce against obstacles easily.

now, I have an install party, so I'll be a bit busy tonight

[Balthazar]

Have a good time!!!