Units turning without stoping request.

[smoth]

Ok, if we could have an fbi tag for this it would be great. Right now when a unit wants to turn it has to stop moving, rotate to that direction and then move. This makes no sense on bipedals or hovers.

Would someone consider making this patch happen?

[ILMTitan]

It took me a few minutes to understand your full meaning. I assume what you want is for units to be able to face some way other than the direction that they are currently moving? To do so, we would have to create separate unitTurnRate and steeringTurnRate variables. Isn't there a cob solution, like the KP byte? Or is it a matter of the default pointing direction not being controllable?

[smoth]

if I have a mech order it to point A and I tell it turn 90 degrees head to point b, it will stop where it is at, turn in place and then head to location b. Can it just move and make a gradual curve? we already have a turn speed.

[yuritch]

I support that request, it will be immensely useful for ships (IMO even more so than for ground units). Currently large ships behave completely unlike a ship, they turn in place. What needs to happen is units should turn taking their inertia into account - a moving unit cannot stop in place and immediately start to accelerate in another direction, a turn should look like an arc somehow with the speed vector gradually changing its direction.
This may bork the pathfinder however, it doesn't seem to take turn radius into account at all.

[KDR_11k]

ILM: The KP byte moves normally, it just has a turret that consists of all visible parts. What you might mean is gunships which move into one direction instantly but take some time to align their body to their movement.

Driving curves causes trouble with the pathfinding I think since the pather treats units like chess pieces that move to any adjacent square, a curve doesn't follow the square route the pather has calculated.

[Warlord Zsinj]

I'd also like to see this be resolved.

A problem we have with our droideka is that they are coded to open up and scuttle when they are either coming to a stop, potentially entering combat, or starting to move. Once they have been travelling for a certain time (assuming no enemies are in range), they will roll up again. Droidekas move much faster rolled up, but have no shield.

The issue is, if you give more then one move order, as the droid moves to that location, it will move, stop, rotate, then start again (the same happens if you give an order on the fly). The result being that the droideka will open up, lose all of it's speed, scuttle a little, then roll up again. All in all it makes them very frustrating to use.

Could it be possible, perhaps, that you force a unit to turn wide of it's mark if given a certain tag, and then ask the pathfinder to recalculate every few seconds to see if the unit has gotten itself into any trouble during it's turn (but not so much as to be heavily costly in terms of processing). It'd certainly be more inefficient then the current system, but designers would just need to be aware not to stick it on every single unit. Maybe put in a backup behaviour so that when the unit has failed to get to it's location after x attempts it will come to a stop and turn on a dime to face it's location.

The actual turning circle of a unit could probably be determined as a combination of velocity and turning speed...

[yuritch]

There is a workaround for StopMoving in the middle of the way, which can be usable to solve the Droideka problem (though I'm not sure if it's compatible with your Droideka script):

Code: Select all

StartMoving()
{
signal SIG_MOVE;
... (folding into mobile state script)
}

StopMoving()
{
signal SIG_MOVE;
set-signal-mask SIG_MOVE;
sleep 100; // a short time enough for a new StartMoving() to occur it move order changed
... (unfolding script)
}

This will prevent it unfolding on very short stops, like when it's changing to a new move order (as StopMoving() will get signal-killed by a new StartMoving() before sleep 100; completes). A slight delay of 100ms shouldn't be noticeable to the user at all (maybe even 1 frame delay is enough).
However an engine-side feature to allow curved turns will be way better (ship turning can be fixed with script too, but it will be a much more complex problem).

[Zpock]

This also makes grous of units look retarded as they keep stopping and turning to try and not bump into each other (which happens even if they move at the same speed due to pathfinding).

[KDR_11k]

yuritch: Signals fail if you get start and stop moving on the same frame (e.g. when force firing on the ground), not a good idea.

[Warlord Zsinj]

If this isn't being resolved engine side, I'd be very much interested to hear other ideas for solving our droideka problems...

[yuritch]

yuritch: Signals fail if you get start and stop moving on the same frame (e.g. when force firing on the ground), not a good idea.

StopMoving() fails anyway, it isn't triggered if the stop was caused by unit entering weapon range while executing an attack order. Very noticeable with ships that emit wakes - they constantly emit those wakes while firing, even if stationary. Workaround for that is to use an infinite COB loop that checks for unit XZ coord every n ms and 'manually' starts/kills wake script. Probably the same can be done for abovementioned Droideka, too.
All of that (including the original thread topic) just means Spring pathfinder and unit movement needs more work. I seem to remember OTA ships and even vehicles turning in arcs, maybe just 'false memory' though.

[Andrej]

my c++ skills suck cock but so do yours etc

if i get it correctly spring pathfinder just gives a unit
a list of map squares it should move through
which is just like suggestion/tip where it should move
the actual movement = not really pathfinders business
it even checks if the unit got too far away from the assigned path
and recalculates if it did automatically
so turn radius = no problems with pathing?

[Pxtl]

I have dim memories of OTA hovers travelling with long, graceful curves instead of sudden stops/starts.

[Pendrokar]

kloot added:
kloot - 3 hours - fix the stop-turn-move-stop-turn behavior for ground units (new udef tag, turnInPlace)

[Das Bruce]

Is that in the main or release branch?

[yuritch]

Looks like it's the main svn branch. The tag seems to default to true, so old units are unaffected.

[smoth]

AWESOME!

[Warlord Zsinj]

Pleased to see this in :)

Could we get a little more information on how this works?

Is there any backup in case the unit tries repeatedly to get out of a position but can't because it can't turn sharply enough?

[Forboding Angel]

Kloot is quite quickly approaching godhood, sitting at the right hand of Tobi.

THANK YOU!!!

[Kloot]

@WZ

In your droideka's FBI, add

Code: Select all

turnInPlace=0;

As for safety backups, the in-place turning still kicks in at very small
speeds (< 1.5 units per frame) even if you have it disabled, so that
a unit stuck in a tight spot where it cannot move forward will still be
able to rescue itself.