In OTA, if you told a vehicle to go to location A, then a couple seconds later decided location B (50 units away from loc A) was better, the tank would not lose all of its built-up speed.
In Spring, if you repeatedly order a vehicle or any unit with low acceleration to change destinations, something that's very common in micromanagement, with every order it will lose its speed and have to start over. The problem happens with all units, but it's not so noticable since generally kbots go from zero to full speed almost instantly.
I wouldn't say that this is a critical issue, but it certainly puts vehicles at an artificial disadvantage that doesn't make sense from a gameplay or real-world physics standpoint.
To compensate, I would have to increase vehicle acceleration and braking dramatically, and this makes them no longer vehicles in the TA sense.
Momentum problem (clearly visible in vehicles)
Moderator: Moderators
I was looking at what might be causing this, I think its the pathfinding.
I used waypoints here it seems to have the same effect.
The tank will follow the thick red line between the waypoints calculating the path between each individually and taking no account of the direction it needs to be facing for the next leg.
This causes big slowdowns on some tanks, there are a couple of things that might help.
Considering an entire route and avoiding sharp turns where possible. Allowing a little tolerance on hitting the way points might help too.
======
Edit following font queries. I was just playing with them this one scores well for artisic purposes but very poorly on legibility.
I used waypoints here it seems to have the same effect.
The tank will follow the thick red line between the waypoints calculating the path between each individually and taking no account of the direction it needs to be facing for the next leg.
This causes big slowdowns on some tanks, there are a couple of things that might help.
Considering an entire route and avoiding sharp turns where possible. Allowing a little tolerance on hitting the way points might help too.
======
Edit following font queries. I was just playing with them this one scores well for artisic purposes but very poorly on legibility.
Last edited by Weaver on 30 Sep 2006, 09:41, edited 1 time in total.
-
esteroth12
- Posts: 501
- Joined: 18 May 2006, 21:19
ugh, that was my first thought too... but i didn't make a completely off-topic post!LOrDo wrote:Wow Weaver, this is off topic, but HOW the HELL can you stand that font???
yeah, but why would it stop, turn, then go if you give it a move order somewhere, then you give a move order at a 45* angle or something...
Is there a pre-existing stop command before any new (non-ai) order?
It does make sense that there would be a break/pause inbetween any give order command or else you would have an infinite loop.
So could it be changed to not effect the unit's current speed at the time of the command, or at least not a return to 0 before it changes?
It does make sense that there would be a break/pause inbetween any give order command or else you would have an infinite loop.
So could it be changed to not effect the unit's current speed at the time of the command, or at least not a return to 0 before it changes?
There are probably some race car games out there with code available to figure out what is pertinent and not pertinent when it comes to steering. Perhaps diehard AI writers could just enact cfg files with globalized waypoint systems that could be pre-mapped for the AI's in order to speed up their pathfinding decision making.
Technically, if everything is going right then you could make weasels and jeffies slide into turns.
Technically, if everything is going right then you could make weasels and jeffies slide into turns.
Last edited by MadRat on 09 Nov 2006, 13:59, edited 1 time in total.
A finishing command will start the next command in the queue if it is the first command to finish in that frame.
I've looked into this problem once before and couldn't find the cause. More recently, however I have run into the code I think may possibly be the culprit. I may know more in a week or so.
In short, I don't think it's the pathfinding. I think it's the fact that movement updates much faster than slow update (I think) for the command AI, so the unit reaches its waypoint and slows down for several frames before CommandAI SlowUpdate tells it to move somewhere else. In addition, I believe calling SetGoal on a unit will cause it to slow down if its deceleration is greater than its acceleration (thanks to two calls to SetDeltaSpeed in Start and StopEngine I don't think need to be there), which could be why it is most prevalent in vehicles.
I've looked into this problem once before and couldn't find the cause. More recently, however I have run into the code I think may possibly be the culprit. I may know more in a week or so.
In short, I don't think it's the pathfinding. I think it's the fact that movement updates much faster than slow update (I think) for the command AI, so the unit reaches its waypoint and slows down for several frames before CommandAI SlowUpdate tells it to move somewhere else. In addition, I believe calling SetGoal on a unit will cause it to slow down if its deceleration is greater than its acceleration (thanks to two calls to SetDeltaSpeed in Start and StopEngine I don't think need to be there), which could be why it is most prevalent in vehicles.