Spring RTS Engine

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.

Interesting dilema, it is very annoying. Maybe lower the brake rate>?

And then what happens when you want it to stop? :/

I agree, this is somewhat annoying.

How about lowering the Brake Rate first, and if they really want or have to break - give them the Chance to drive against there own Inertia Backwards..
THis is of Use only if Units are selected. If they are Ordered in Queus - the need a Patch to drive Curves.

Just making vehicles turn at full speed rather than stop and turn in place would be an improvement. Aircraft already do that.

PS. Picasso, could you please stop capitalizing every noun? It's kinda Annoying. (Yes I know that German is like this, but English ain't German :))

BITTE DANKE! Actually german is entirely spoken in caps. And I agree to Caydr's post.

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'm for the "hitting waypoints tolerance" solution, especially if we could define that... that'd take care of a whole bunch of possible cases. Good idea

Wow Weaver, this is off topic, but HOW the HELL can you stand that font???

LOrDo wrote:Wow Weaver, this is off topic, but HOW the HELL can you stand that font???

ugh, that was my first thought too... but i didn't make a completely off-topic post!

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...

Maybe this could be fixed with a loopish movement, and multiple areas where it would just keep going.. Never mind, we would need 5 GHz processors for it..

or some sort of tag, it forces them to make a turn, and maintain the highest speed...

Was this ever fixed?

I don't think 5GHz processors are necessary for a simple angular velocity solution. You can plot a simple curve at maximum turn rate and pathfind from there to avoid collisions.

Well my idea was very complex, something that could never pass in a game, professional or not.

I would still like this to be fixed, too.

Someone still needs to write a patch.

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?

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.

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.

Perhaps the problem is simply that it applies brakes whenever it reaches its waypoints. If land-based vehicles were allowed to circle around like air units, would that make any difference? I'd think in big turns with poor turn rates the stop and turn is more efficient.