Backwards Movement

[Argh]

I've done as much with transforming / morph as anybody has. I have quite a few complex transformations in P.U.R.E. already. That's why I'm incredibly dubious about that.

A submersible with vlaunch weapons isn't anything like a robot with a specific facing and fairly complex animation requirements on the ground (slope, etc.). You can get away with much more slop.

And that still seems like an overly complicated and funky situation. Each Unit would have to have a specific mirror... and what happens when you go from "forward" to "backward" to "forward" again? Hmm. Three different Unit states... lots and lots of Lua-->COB-->Lua-->COB there. Just to do one guy would take a huge amount of work, compared to an engine-side callin and a simple change in COB.

And when you morph things, they have to be created on a cardinal arc. You can then turn them, etc., but there is a slight-but-obvious visual smear while that occurs. It isn't instant, and it can't be.

[smoth]

what about like I do with the doms? just add some extra anims? I am sorry, didn't read the rest of the thread but wanted to ask why it isn't viable.

[aegis]

And when you morph things, they have to be created on a cardinal arc. You can then turn them, etc., but there is a slight-but-obvious visual smear while that occurs. It isn't instant, and it can't be.

uh I seem to remember it being totally seamless when the submarine surfaced/submerged, even when it was pointing in a weird direction

[smoth]

getheading etc takes care of that.

[Strategia]

Oh, just a quick disclaimer: Despite my comments earlier in the thread, I do support this request fully. Back when this was still TASpring, I recall the rationale being that TA units never moved backwards as well, but now, with so many non-TA mods (or mods only inspired by TA, e.g. CA, NOTA), that reason basically becomes obsolete. And surely there's some way to make this happen without having to rewrite half the pathfinding code? Then I see no reason not to make this possible via a few lines of code in the unit itself, rather than a hackish workaround that would only work for 60% of all units. Make it either use the existing locomotor(?) code (to use C&C Generals terminology, I have no idea how Spring calls it) and just add a line like CanReverseMove=1 or something, and/or make it possible to add a reverse locomotor, in case you want units to move slower when reversing. This is just a pointless engine limitation, and personally I don't see why it shouldn't be changed at some point, and why not define "some point" as "now"?

[Elkvis]

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.

your not serious, right.

[Das Bruce]

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.

your not serious, right.

I certainly seem to be.

[Elkvis]

Trickery pertains to the fact that the effect requires the engine to be tricked into doing something it does not natively support.

How is that a condescending or a prickish remark?


\/ Cynicism much?

[Peet]

By that logic, every byte of content and code in a mod/game file is 'trickery'.

[Pressure Line]

My point (which has now been covered by other peoples point's) is that yes, you can fairly easily make a BA Stumpy appear to drive backwards, because it doesn't really matter which direction its facing. It has no fixed armor zones, or firearc restrictions.

But making it look like its going backwards is only 1/2 the battle, now you need logic to tell the unit when to move 'backwards' and when to move forwards. To work properly, this code needs to take into account things like the turnrate of the unit, any speed restrictions on reversing units, etc to decide whether its quicker to reverse to the next waypoint, or turn around and go forwards.

Im sure I had a point, but i forgot what it was x:

[smartie]

The reverse script is pretty much the definition of lua trickery. It requires rescripting the cob file for each unit to alter the aiming code and flip the model when it drives backwards. An actual in-engine reverse would be much nicer.

Lua already supports altering armor zones on the fly. If support for altering firearc restrictions was added then the script could work in full.

Using morph seems like a bad idea, but i havn't looked into it. What happens to units guarding the morphed unit? or units with attack orders on it? or transports ordered to load it, or any command that uses a unit ID? It seems like you'd have to check through the command queue for every single unit in the game and look for commands using that unit ID and replace it with the unit you morphed it into. Not too bad if you do it every once in a while, but if you order 50 tanks to retreat all at once it could be messy.

[imbaczek]

for the record, moving backwards would require additional cob callouts anyway; animation during reversing in general isn't the same as when going forward (e.g. on walkers).

[Strategia]

for the record, moving backwards would require additional cob callouts anyway; animation during reversing in general isn't the same as when going forward (e.g. on walkers).

Which is why it should be entirely optional; if you want your units to back up, you'll have to put more work into them. I don't really see this as a bad thing.

[imbaczek]

it's not, just wanted to point it out - regardless if you're faking reversing or doing it the right way (which doesn't exist yet), you'll have to write more cob.

[IllvilJa]

Oh. For what it is worth...

I am all in favor of having the engine support NATIVELY that units move backwards. Mod developers who think it is critical that unit never moves backwards can skip taking advantage of this new feature, sure, but I'm convinced that Spring 1944 folks would be pretty quick on adopting it (so, at last, one can drive around in a Sherman and RETREAT THE DAMN THING BEHIND COVER WHILE THE BARREL RELOADS LIKE IN BATTLEFIELD #¤"%#¤%&@!).

So, things like "faking" reverse movement is called "trickery" because they, like most hacks it is fragile, inflexible and makes further development and maintenance of the mod FAR harder than needed once you reach a certain point in its development (which when you deal with hacks, occur far sooner than you find comfortable).

I work with software development and yes, I truly hate the situation when I have to work around some basic deficiency in a product. Sure, sometimes those deficiencies have to be there for a number of reasons (sometimes quite good reasons indeed) but it does not change the fact that the workaround struggle hits me in my work, no matter how much I manage to trick my end users to not even notice the deficiency.

And yes, I make this statement in spite of the fact that I probably never will have time to touch the Spring engine code and contribute to an implementation of REAL reverse unit movement (no matter how much I wish I actually had that time).

[SpikedHelmet]

stuff

+111111111111111111111111111111111

[Argh]

Meh. All of the above reasons are good. I guess I just don't get why this is even marginally controversial, frankly.

[Pressure Line]

Its not. Its just that no-one wants to re-write the pathfinder to support it natively (Well, I certainly don't)

As I mentioned earlier, its a big step up in logic complexity, UI issues (should it be possible for the user be able to disable unit reversing? [a-la low/high traj]) modder issues (should it be possible to set a capped distance for reversing?) etc etc.

Possible, yes, easy, not really. and people would still post about it because chances are it wont end up in BA, and as we all know if it isn't in BA it (effectively) doesn't exist

[REVENGE]

Yet another example of modders wanting to do less work vs devs wanting to do less work.