Spring RTS Engine

I just find it ironic that the tanks couldn't go backwards during the game, so what gives?

Try reading one of the other 9 threads on this exact topic.

Hint:

It's hardcoded. If you want to try and code in reversing yourself, good luck, as you will probably need to code a new pathfinder from scratch.
Someone else bought it up before, that was the answer.

HeavyLancer wrote:good luck, as you will probably need to code a new pathfinder from scratch.

What? How does that path finding work then? It doesnt work by making sub-waypoints without obstacles?(In which case you just do it, and hope it doesnt bump into stuff.) Edit: i mean pathfinding produces waypoints which unit follows.

uh... you could make it initially work by allowing the unit to turn toward the path of least resistance then doing normal pathing from there?

Yeah, there's no practical reason why they can't reverse. On the initial step, if it involves greater than a 90-degree turn, backpedal. Only real issue is then sending that state to COB, for reversed animation of walk-cycles, etc., and then simply reverse the sign of all turning movements that result, until a future order arrives that would cause forward movement to be most efficient.

I would be totally in support of fixing this.

Here's the problem - if reverse is slower than forwards, then pathing is going to be a pain to decide whether it's faster to reverse or forwards. If reverse is the same speed as forwards, then it would be ugly to see half the units driving around backwards all the time, blissfully unaware that they're crossing the whole map in reverse gear.

Personally, I'd add engine-support for reverse gear for the sake of FPS-mode and similarly manually-controlled units, but I'd leave it out of the unit AI. Actually, thinking it over, if you need that it's probably time to use MoveCtrl.

Even if it's FPS-only it has to be restricted to opt-in for mod designers, it would suck when you have a limited arc unit that was intended to be unable to fire backwards being moved backwards so the gun points at the units chasing it.

KDR_11k wrote:Even if it's FPS-only it has to be restricted to opt-in for mod designers, it would suck when you have a limited arc unit that was intended to be unable to fire backwards being moved backwards so the gun points at the units chasing it.

I think it would be opt-in no matter what, since you'd need whole new COB scripts for it wouldn't you?

I could see people hack something together that would rape the COB in a way that looks fine with OTA COBs and nothing else...

when i was playing OTA, i noticed that the construction vehicle could go backwards, if only to get out of the way of other units. so it should not be that hard to code

It's not. It's the stupid people who are obsessed with units having to move more slowly when going backwards

Seriously... first make it possible to go backwards, full speed. Then worry about optimal speed management. This is not a problem that must be solved all at once.

The problem with your plan, Argh, is that if the units are told to move backwards whenever it is expedient, they will move backwards half of the time. Now, imagine a swarm of tanks, with half of them moving in reverse. Absurd, isn't it?

That's the problem - figuring out when is the "right" time to go backwards.

Ok... then limit the arc at which backwards movement is chosen to less than 180 degrees? Have a tag that says that they're not allowed to go backwards at all, and set it as the default behavior?

You'd still have a percentage of units go backward when traveling, on average. To be more specific, if we call the arc used to decide to move backward 'backward_arc', then backward_arc/360*100 % units will move backward, on average.

Maybe some hack with limiting the arc based on distance to first waypoint could work, ie. backward_arc = 180 - f(distance(unit.pos, waypoint.pos)), where f is some properly engineered function to make units behave just right. (may just be step function..., disabling backward movement for distances over a certain value entirely)

Shouldn't reverse be a seperate command? Leave it to the player to decide when he wants his troops to use reverse.

Code to determine when to use reverse automatically need not be a requirement but could be created seperately.

I would like both of these things. something like tobis forumla plus a command to force units to move only backwards.
plus (though it is not directly related) a command to make units turn to a certain direction (for those who can). or does this exist already?

One way I could see this working well would be to give units a hacky little "reverse-fishtail" command available only when moving in reverse, where they rotate 180 while moving, totally ignoring the physics of the movement. Then you could have units back-out for a second or three and then "reverse-fishtail". But the "reverse-fishtail" would look kinda silly.

momfreeek wrote:Shouldn't reverse be a seperate command? Leave it to the player to decide when he wants his troops to use reverse.

If it's completely manual you can just as well gadget it, either use COB to turn the visual unit 180° (while also turning the unit 180° so it looks the same but internally faces the other way) or use movectrl.

Pxtl wrote:Here's the problem - if reverse is slower than forwards, then pathing is going to be a pain to decide whether it's faster to reverse or forwards.

You do not necessarily have to solve the pathing for going backwards/forwards globally. Actual control can be based off waypoints pathing creates. I am working on a common lisp rts, and made 2d units that have multiple thrusters. If the angle of a thruster is within a small enough range of the direction the hovertank wants to go, it fires, else not. The tank as a whole rotates to the desired direction in the shortest way. (Using angular acceleration, friction limits speed.)
This has the desired effect of if facing wrong way -> backward thrusters on. Then the direction is for a while that no thruster points right way (unless it has sideward ones.) and then the forward thrusters fire. (To the normal cruising mode.)

Of course it can not be ruled out that there are problems when there are obstacles in a nasty way, but then again, i wouldn't know of a method of fixing that with a hundred percent security and reasonable cpu costs. And current spring units get stuck too, or sometimes start bumping a slower unit. Maybe a solution to 'rowing up' might be to repath to the next (sub)waypoint, but making the blocking unit a obstacle.(Then again, it is fine as it is, and it might produce bugs/other negative unit movement.)

I would know something pathing would be difficult for, cars that can't take slopes, but they can when they enter at speed. (And have to figure it out themselves)Suddenly pathing needs to be done in 4d space.(Not counting z position/speed.) Don't think it is worth the effort, though. Even if you would allow for that, let the player figure out how to get them in at speed :p