Friday Facts #412 - Undo/Redo improvements & Car Latency driving

[mwls]

The undo improvements look terrific. Any one of them alone would have been huge, but having all of them is even better. I assume that removing wires is also included in the "undo wire connection" improvement—multiple times I have inadvertently shift-clicked a power pole and removed all its wires, and then when attempting to undo that, accidentally undone something unknown elsewhere in my factory. So (1) being able to actually undo the wire change in the first place, (2) knowing what I accidentally undid, and (3) being able to redo whatever I did are all fantastic.

[mwls]

This doesn't apply to rotations made by hand using the R key, as that is easy to correct yourself and could spam up the undo queue.

It's easy to undo if it's the most recent action, but when you're undoing a series of multiple recent actions (like 10+), having manual rotations omitted is more painful and likely to get you back to an inconsistent state that never existed. Someone on Reddit suggested collapsing all consecutive rotations of an entity into a single undo stack entry, which I think makes a lot of sense and seems like a decent compromise to avoid spam. Similar collapsing could also apply to rotations immediately after placing an entity and to drag-placing multiple belts.

[Winged_Shade]

This all looks really good! Undo/redo is gonna make a big difference I feel.

One question though: Are the text popups on screen proportionally long for how many types of things are changed? I could easily see a situation where a complex area with many building types is changed, and the text goes by too fast to read it all. It could maybe even benefit from being color-coded green/red for construct/deconstruct.

Also I would hope that this feature could be disabled in case the popups become too intrusive.

Update 2.0 is looking great as always, can't wait to play it!

[Winged_Shade]

Follow-up question: I'm curious to know how this is going to work if my friend (server host) fires the gun turret on a car that I (client) am driving? Would this put my driving back to the old high-latency while they're shooting? This is how we always compensated for driving/combat latency.

[Ranakastrasz]

Any chance we can also get WASD compass direction controls for vehicles too?

Absolutely love the number of QOL changes coming. Aways wanted a redo button, but honestly having it tell you both when and what was changed is so useful.

[Stalinlover22]

So COOL, I wanted this feature since I was a begginer, what about a oficial trailer?

[adam_bise]

Yea!! Thanks for the latency driving Agree with others about shooting needing work as well.

Like the redo addition too!

[TROPtastic]

OH MY GOD THEY'VE FIXED DRIVING.

Unless they've also made vehicles snap to exact angles, they haven't. Vanilla vehicles are effectively unusable for safe driving within the confines of a base.

[steinio]

OH MY GOD THEY'VE FIXED DRIVING.

Unless they've also made vehicles snap to exact angles, they haven't. Vanilla vehicles are effectively unusable for safe driving within the confines of a base.

Exactly my thought too after reading this FFF

[Tooster]

It's easy to undo if it's the most recent action, but when you're undoing a series of multiple recent actions (like 10+), having manual rotations omitted is more painful and likely to get you back to an inconsistent state that never existed.

I couldn't agree more. I can already imagine how annoying it will be if I accidentally rotate something somewhere I didn't notice, and for some reason I can't undo and now my factory is borked. By extension, manually flipping an inserter in place is no different than rotating, so does it mean that the same rules apply to flipping? If yes, that's gonna be a PITA, if no, then it's gonna be confusing and inconsistent. I don't see how the two situations are different and how I wouldn't want to undo what I did.

What's more, your decision to omit rotations from undo queue directly contradicts what you wrote earlier in FFF:

[...] This presents a problem, because one of the axioms of Undo is that "anything you do will be undone" [...]

and later:

[...] This doesn't apply to rotations made by hand using the R key, as that is easy to correct yourself and could spam up the undo queue [...]

So... anything, but not really...

I would much rather have a "spam" (read: "anything I did") in my undo queue than an inconsistency like that. I can't even count how many times I missclicked R/F while hovering something when zooming out or in map view...
Please, treat all actions that can impact the factory as undoable, otherwise this inconsistency will be hugely annoying... You made good decisions when it comes to adding undo and now redo, but this... this is a step back...

Collapsing entries also seems like a good idea, in VIM you don't get undo for single characters and it is working great.

And one last thing:

(...) as that is easy to correct yourself and could spam up the undo queue

I don't think there is a madman pressing R hundreds of times. What's far more believable (and what I have been doing all along) is a combination of deconstruct + several single rotations + copy-pasting all over the place. 5 or so presses of R and F ARE something I want on the undo stack.

[meganothing]

Please, treat all actions that can impact the factory as undoable, otherwise this inconsistency will be hugely annoying... You made good decisions when it comes to adding undo and now redo, but this... this is a step back...

Collapsing entries also seems like a good idea, in VIM you don't get undo for single characters and it is working great.

Exactly. Even without collapsing entries consistensy is much more valuable than always having lots of meaningful changes in the queue. The farther back an action is on the undo stack the less likely it is that it would be useful to go back as eventually you do other changes that you don't want to undo. But it would be frustrating to having to remember which actions are undoable and which are not (at least for operations you often do).

[Svip]

The solution to the concern about spam is to "combine" them. So if you do several rotate actions in a row, each successive action is combined with the previous one, meaning that if you were to undo, you'd undo all those rotations in a row. This is a reasonable compromise, as this is what most text editors do. They don't keep every character you enter, but rather a reasonable list of them. Similarly, you could add a tick threshold before it creates a new entry in the undo queue.

[Tooster]

The solution to the concern about spam is to "combine" them. (...)

I think before coming up with a solution the first thing to do should be checking if the problem even exists in the first place, and I'm inclined to believe there wouldn't be, in fact, any problem. From the wording of the FFF it seems like wube thinks it could be a problem, but the FFF doesn't state they playtested it and acknowledged that the problem is real.

[OtlichnikTop]

Finally, it happened. I know how difficult it is to drive in a multiplayer game (I play on the server with the youtuber ParaToxic, on the IR3 assembly and often crashed into various objects on transport).

I understand that this is a good way to fix it, but I have one question. What happens if, let's say I have a very long delay and I shoot down an object on a tank, then restore it before my "physical" tank should crash into the object. What exactly happens if the tank breaks the object a second time or it passes through the object from our point of view?

As for cancellation, of course it's a small thing, but it will be very useful in huge databases!

[jamaicancastle]

Another undo-related annoyance that would be nice to fix: when you're rail planner-ing and you place a segment, the "root" of the planner where it starts drawing from jumps to the end of that segment. But if you undo your previous segment, the root stays where it is - which is now in the middle of nowhere, not connected to any rails, because you undid the segment that led to that point.

Effectively, the undo tool undoes building, but it doesn't undo the internal state of the rail planner. It should do both. If you have the rail planner open and the rail connected to the root is undone, the root should snap to the other end of the rail that was undone, so that you can rapidly prototype different curves from the same starting point to see which one is most suitable.

[catpig]

These are some of the best improvements so far (but only some, because you've showcased some absolutely amazing ones previously too!)

Couldn't agree more ^^

[Lou]

Awesome, now please fix shooting weapons in Multiplayer, which is far worse than the Vehicles.


Like merely holding the "Shoot" Button causes the Game to lag like mad, if there is any latency, even if you dont have Ammo at all, its like its trying to send my mouse coordinates every game tick... (speaking from transatlantic multiplayer experience)

Latency hiding in combat is generally problematic, because we would need to simulate a lot of expensive stuff.

I am not sure what do you mean by "lag", but currently when you are shooting, the latency hiding is dropped -> you should have a delay but not lag in the sense of minifreezes.

What i mean is i suddenly walk significantly more slowly with a lot of input delay to the point i always frikkin die when engaging in combat in transatlantic Multiplayer. Anything that is not a Nuclear Rocket Launcher is basically impossible to shoot in Multiplayer for me.

Same goes for the Vehicle Mounted Guns, I have to resort to AAIs Automatic Gun Turret on Tracks to be able to even have any sort of Combat at all, so clearly Combat CAN work with no latency as long as the weapons I use dont have to transmit my mouse position to the Server and back. (is what i suspect)

Obviously some of this can be mitigated by overpowered modded utility that makes me practically invulnerable, and throwable weapons like Grenades and Poison Capsules. (I am not agile enough for turret creep, unless I got the picker dollies mod installed)

Edit: Spidertrons and Laser Armor are ofcourse a bit too endgame and are not considered fun Combat, since they just wipe out everything passively.

Unfortunately, I have no good news feature-wise for you, all I can offer is some explanations.

The automated weapon systems you mentioned (like personal lasers or turrets) don't have their latency hidden either, they are functioning in the gamestate time just like enemies, so it feels smoother but when you see them functiong, the information is latency-ticks old.

Walking slowly when shooting or trying to shoot is a feature. It also drops you from latency hiding specifically so the combat wouldn't be too jitteryat the cost of no longer hiding the latency (which we cannot do fully anyway). Manual shooting (both targeted and general) should work correctly, only you don't see the effect right away (because no latency hiding). Some things cannot be helped. like stuff around position of enemies (getting swamped or deploying position (not unit) based weapons, like grenades).

[Lou]

...
I understand that this is a good way to fix it, but I have one question. What happens if, let's say I have a very long delay and I shoot down an object on a tank, then restore it before my "physical" tank should crash into the object. What exactly happens if the tank breaks the object a second time or it passes through the object from our point of view?
...

Shooting and robots do not have latency hiding, placing entities do. Shooting in adition even drops you from latency hiding. Assuming "restoring" happens by robots, there can be more scenarios dependent on the timing, but here is IMO the most likely scenario for long latency:

1. You are driving, latency is hidden, everything OK, you see obstacle you want to shoot
2. You aim and press the shooting shortcut
3. nothing happens for latency - ticks
4. shooting happens in game state, you get temporarily dropped from latency hiding -> this will appear as snapping backwards and watching your projectile fly and do its thing.
5. after some small time the dropping out latency hiding is no longer relevant and you snap back into latency hiding -> this will appear as snapping forward
6. latency hiding simulation will continue based on the state where the obstacle is destroyed -> you are driving no latency no problems
7. once you reach the point where the obstacle is revived by robots in the game state, any latency hiding simulations will take that into account. This will be an abrupt change in the shape of one of the following:
   
   1. Assuming the obstacle was destroyed by the collision, you snap back a little bit and your new speed will be slower (the collision slowed you down)
   2. Assuming the vehicle was destroyed by the collision, you snap back into a a position of destruction just as your character (assuming your vehicle prototype does not kill you on destruction)
   3. Assuming niether the obstacle nor the vehicle was destroyed by the collision, you snap back into a state where your vehicle is pushing into the obstacle
8. You continue no problem, latency is hidden

[GregoriusT]

Walking slowly when shooting or trying to shoot is a feature. It also drops you from latency hiding specifically so the combat wouldn't be too jitteryat the cost of no longer hiding the latency (which we cannot do fully anyway). Manual shooting (both targeted and general) should work correctly, only you don't see the effect right away (because no latency hiding). Some things cannot be helped. like stuff around position of enemies (getting swamped or deploying position (not unit) based weapons, like grenades).

What I mean is not the normal "slowdown while shooting" (I do play singleplayer too afterall), it's an amplified extreme slowdown while holding the shoot button, even if I am not shooting due to lack of Ammo.

Ofcourse the automatic Turrets have latency, its just they do not influence the movement latency of the Player.

As for the other bit about Car Guns, are you seriously snapping back and forth during combat in a visible manner? That sounds kinda jank.

For BOTH of the aforementioned things, I kinda hope that movement can be entirely decoupled from shooting, just as a quality of life, because those two things being entangled is the exact annoyance I have been talking about.

I dont mind if my Guns themselves have latency, I care if my Legs, Wheels and Treads have latency! And Guns somehow latencify my Legs, Wheels and Treads for no nice reason!

[cheetahrunout]

Imo the button on the confirmation tab of the undo action that is now called "back" should be called "Cancel".
The undo action itself is some sort of "back" feature that could confuse people. Really you try to cancel the undo action, not going back to anything.

Aside from that, great stuff and amazing work again. Cant wait to play 2.0.