Backwards Movement

[Argh]

I think that this is what? The third request? Anyhow, sorry for adding to MTR, but since Jazcash brought that up again... how's about it?

Automation of backwards movement could be a simple check, I think. If next move distance < some amount in unitDef and requires a turn > some amount in unitDef, then move backwards, and send COB a callin, so that scripts can adjust.

If going backwards previously and same conditions, then go forwards, and run through the COB callin again.

Simple, really. Default to 0 for the value of the backwards distance, and present behavior is kept. The only problem is, I don't think that the movement code takes turning into account when designing paths. That's just some simple trig, though, between where the Unit is when it's given a Move order / hits the next waypoint and the next waypoint.

[Strategia]

I've seen some units (I think it was in NOTA and S44) move backwards.

[Argh]

They don't, not really. They just appear to.

[Das Bruce]

They don't, not really. They just appear to.

... what?
It's a game, if they appear to be moving backwards, they're moving backwards.

[Argh]

No.

If you use limited firing arcs, you'd see.

[imbaczek]

play dow2 and you'll see that automatic reverse is made of fail. a better solution IMHO is a new command, like CMD_MOVE_REVERSE.

note: not saying anything about potential implementations.

[Super Mario]

We could give the units ability to move right turns while staying at the same spot.

[Argh]

a better solution IMHO is a new command, like CMD_MOVE_REVERSE

I'd go for that, too. That's a solution, and it leaves Lua'd versions of auto-reverse as a viable option.

We could give the units ability to move right turns while staying at the same spot.

I think that's already possible via LuaMoveCtrl and a bit of finagling. Haven't built it yet, so I'm just thinking out loud on that.

[Strategia]

They don't, not really. They just appear to.

I'm pretty certain they were turreted units with full coverage, moving backwards to make a turn. I think I even did it in FPS mode once or twice.

[Pressure Line]

impossible. currently the ONLY units that can move backwards are gunships (ie brawlers/rapiers) and transports (since they share a movetype with gunships iirc)

so, if you saw them moving backwards, you saw some cob or lua trickery to give the appearance of moving backwards. (and Bruce, there *is* a difference from a game development standpoint.)

[Das Bruce]

so, if you saw them moving backwards, you saw some cob or lua trickery to give the appearance of moving backwards. (and Bruce, there *is* a difference from a game development standpoint.)

Of course there's a difference from a development standpoint, but from a gameplay standpoint if those units behaved as though they were moving backwards then they were moving backwards in the only sense in which it matters.
Argh pointed out that it doesn't work with limited fire arcs so it's not a perfect solution but to flat out deny it as "trickery" sounds awefully fucking condescending to whoever coded it. Prick.

[smoth]

my doms move teh backwards.

[KDR_11k]

play dow2 and you'll see that automatic reverse is made of fail. a better solution IMHO is a new command, like CMD_MOVE_REVERSE.

note: not saying anything about potential implementations.

Then it could just as well be done by a lua-COB thing that turns the unit by 180┬░, applies a speed reduction and turns the visible model by 180┬░ too...

[yuritch]

That causes lots of trouble when:
- the unit has firearc-restricted weapon;
- the unit uses directional armor system (as all the vehs in current S44 do).
Firearc would need to be emulated using COB (probably possible with set CHANGE_TARGET), directional armor system would need to be adjusted as well.

[Pxtl]

Morph it.

[aegis]

Morph it.

actually, works really well...
we used an instant unit replacing script in E&E for the submersible battleship, and it was really slick (cob animation for surfacing/submerging happened right when the unit was created)

[FLOZi]

Morph it.

I was going to say the same thing, then thought I must be missing some really obvious flaw with the really obvious solution.

[Argh]

If you morph, you'll be using CreateUnit, and therefore the Unit will be reset back to the default state.

Sounds like a recipe for a complete lack of visual polish to me. Same deal with KDR's suggestion- forcing it through MoveCtrl isn't a real solution, if you want the feature to work in a polished way.

This is really something where it's either done right, which means engine-level, or it's just a hack and will have problems. It's one thing when it's nearly insta-turn infantry, but I want this to work for things that don't move that fast, like Giant Robots, and none of these hack-arounds will actually accomplish that properly.

COB stuff fails, because then it's obvious that you're jacking around with rotation of the base point, and it won't respect restricted fire arcs. MoveCtrl fails, because it would be massively complicated to make it properly emulate current movement behaviors in terms of slope, etc. Morph fails, because it would cause visual discontinuity.

[aegis]

doesn't cause visual discontinuity if you use luacob to sync the end of the previous animation with the beginning of the next one.

you couldn't tell the submersible ship was replaced by a new unit.. it even maintained the command queue perfectly (you could queue submerge/surface multiple times)

[Wisse]

I was about to write: "This thing gets debated every few months", then I checked date of the last topic I started and it's from 2007. I still remember it like it was yesterday -.-

Anyway maybe you should read it anyway: here