'Undo' knob

[ProDigit]

Ever had you wanted to put a 'drag and drop' train station and found the rail direction was in the wrong direction (leaving you eg: 6x1 rails (6 short ones) instead of 1x6 (1 long one))?
Ever had you wanted to create a tunnel or other item and it costed more than expected, or it didn't ended up where you wanted it to be?
Ever had when building a railroad the railroad ended up in the wrong direction, or so?

Ever created a flat land,in a city where you had a 'good' rating, to build an airport to only be denied to place it?

or perhaps,

Ever built a train or another vehicle seeing only after purchase you made a mistake (eg: food instead of goods vehicle)?

I often get some of these, and get more frustrated when there's little money, to first pay for what you don't need; then often having to pay for removing it, to only needing to pay again for what you need.

Ever had forgotten a password in multiplayer, only to figure out someone entered your company to waste your money in raising land or purchasing items which bring forth loss?

An 'undo' button would be nice in this case, undoing last action and resetting the finances to the value before. What do you think?


you have the right to agree, disagree, like or dislike this idea; but please leave sarcastic (which to me are unhelpful) comments aside.
Thank you.

[Conditional Zenith]

This suggestion has been made and rejected before. Please search the forums like the announcement up the top says to before making suggestions.

See also http://wiki.openttd.org/wiki/index.php/ ... tures#Undo

[Yexo]

Please read!

[dihedral]

can the word 'undo' not be banned from thread titles?

[ProDigit]

Well, we all know how lousy forum search engines are, and especially on forums with hundreds of topics, and thousands of posts.

In any case, thank you for the answer. The fact that many people are asking for this feat, is probably because lots of people would like to see it implemented.

And dihedral: It'd probably be better for your unhelpful comment to be banned from the forum than a question of someone who with good intention tries to come up with an idea to improve gameplay.
Comments like that really are better off not spoken (or written)...

Things depend from forum to forum,but the reason I don't read these forums is that there are too many people who find joy in bothering, being sarcastic, and being unhelpful.
I mean, it's not even funny anymore,everything one asks one gets trampled down.

There are enough forums on the internet where people hang out, and help each other.

If this forum had more of the first type of people (the helping & kind ones), and less of the latter, I might reconsider, read it more,and be more involved in this game.

[belugas]

In any case, thank you for the answer. The fact that many people are asking for this feat, is probably because lots of people would like to see it implemented.

That could be the case. But that does not mean we are ready to sacrifice the game's sanity for the sake of a feature, no matter how wanted it can be.
Same goes with multi-processors usage. OpenTTD would need to be re-written from ground up, if we wanted to add it.
Do we want to go there? not really. Why? Because it would mean development totally halted for who knows how long.

So in short: always weight the benefits over the efforts.
In both mentioned cases, the effort outweigh the benefits, BY FAR.

[Conditional Zenith]

Well, we all know how lousy forum search engines are, and especially on forums with hundreds of topics, and thousands of posts.

http://www.tt-forums.net/search.php?key ... mit=Search
Maybe that would be a decent argument, except that you didn't even try to search. Search engines are far from perfect, but they are also far from useless.

[Zuu]

Ever had you wanted to create a tunnel or other item and it costed more than expected, or it didn't ended up where you wanted it to be?

You can test how much a command will cost by holding shift when you release your mouse button. Then the command will not be executed but you will get a window telling you how much it would have cost to execute.

[JacobD88]

I've been thinking, and seen as a quick scan with the search revealed no answer to this specific question...

If someone was to take the time to implement and undo feature, as mentioned above and elsewhere this is a huge task, why can't it be implemented as a "cheat-patch" and therefore be excluded from multiplayer?

And a little OT in the sense of what the patch does, but very much the same in answers...

Why can't the ability for drag-drop placement of "purchased land" tiles also be implemented as a cheat and excluded from multiplayer?

I seem to see a lot of suggestions quite rightly being dismissed by the devs because of their affect on gameplay and or multiplayer, but if someone is willing to take the time to build the appropriate patch for a function they and others require, why...

A) Not take the time to consider what the Devs say about how it affects gameplay and find a work around in the appropriate topic/discussion

B) Make it a cheat or limited to single-player as appropriate

C) Make it easy for players to choose if they wan't that patch/feature or not

Finally, if the patch maker does find work-arounds for adversely affecting gameplay or creating an opportunity for other players to abuse it's functions... Why do the Devs sometimes still refuse to add the features to trunk? (Though i do realise that it is their prerogative to not answer "why's") Even if the feature can be turned off? One of the things i love about all the TTO/TTD based games is choice... It's what makes them interesting and varied to play... Why cut out a feature that can be turned off simply because it would break the conventional style of gameplay for those who choose to turn it "on"... They wouldn't turn it "on" if they didn't want it!

Hope that makes sense, and it's not intended as a rant... Just want to see what people think about this as i can see i am not alone in being a little tired of the many threads asking for the same thing (which i agree with all who say it... Use "Search" to avoid this) and then the threads ending with a constant blast of "see this..." "read here..." etc. statements rather than doing what seems logical to me and simply getting the person(s) in the first post of a thread to justify their questions or requests in a mature fashion...




P.S. And for all those who say a feature is impossible (Though not in this thread)... I remember a time where curves under bridges or a no-vehicleID-limit to support multiple GRFs (as well as many other "impossible" features that are now i common use) were "impossible"... Well even OTTD was deemed "impossible" at one point... Who could have thought someone would have ever found the time to reverse code TTD?... Remember everything is possible to some degree, people just need time to do it... Look at what was deemed "impossible" at the time of TTDPatch 1.6 and see how many of those "impossibilities" have been overcome if you want an idea of the scale of what i mean...

[Rubidium]

I've forced my train to pass the red signal and it crashed, what would 'undo' do?

The problem with undo is the fact that what you want to undo is already long long ago (game state wise) when you want to undo it. So if you would introduce undo it would mean saving the complete game state and going back to the last 'save'. As you might know many people disable autosave because it's too interruptive in their game play, so an autosave every time you build something makes it even worse... Then there's the issue of actually going back. That'd mean reloading the savegame and that goes together with closing all windows as any pointer to a vehicle/town/station becomes invalid by that process. So what have you just implemented? A hot key for loading the last autosave and autosaving on every player action; not quite what people expect from an undo I'd reckon.

Then about "the devs" not adding all patches to trunk. Any idea how untested many patches are? And how few patch writers actually have the proper understanding of the things they are messing with? This means that all patches must be reviewed very strictly and one will find the most trivial bugs by a simple review that no one who was 'testing' had found, but then a crashing OpenTTD isn't worth mentioning. Those patches are all fine for those Integrated Nightlies because people expect them to crash, but people expect the official OpenTTD to not crash. Anyhow, all the non-trivial patches go through several rounds of review and rewrite (by the devs or the author of the patch) before they get added to trunk.

[Zuu]

I want to add, to what Rubidium said, that from patch writers point of view it can at times be frustrating how much effort you have to put into it. Compare writing a program on your own where you implement it, and when you are happy it is done with writing for code for OpenTTD. Both things have their up sides and down sides. When I write code for OpenTTD I improve my coding skills as that forces me to make good code and think about how to make things fit with the OpenTTD-way. Not that my own programs are just hacks, but since I don't need to convince anyone else that the code is good enough I don't spend the same amount of time with it. So progress is faster in my own projects. If quick progress is the only thing that matters I would not recommend coding patches for OpenTTD as you will need to spend lot of more time on each thing, but since you do spend more time on it it gets better and you learn from the dialog you have with other people about your code.

[ProDigit]

If autosave is interruptive,I don't know. I mainly play small lands.
Maybe a very simple function can be implemented then, autosave every minute to 'autosave-undo.sav' and the other minute to 'autosave-undo2.sav'.
Alternating between the 2 files. this should give you the ability to load the game upto 1-2minutes before time. (just in case a train would crash,and before you could undo, the autosave took a snapshot of the game).

Then every 5 or 15 minutes (preset in config) the undo.sav is copied to a regular save.

Then an undo/redo knob that will load last autosave, and the autosave before that / restore last autosave and/or original game.

it's not hard at all to implement that,and on small lands(128x128, 256x128) one can hardly notice the autosave feat.


The diskspace issue current autosave takes can easily be diminished by saving only 3 auto-save games instead of 9 or 10.


I do understand on large lands that having an autosave every minute will be very annoying,always pausing the game.
Maybe a system could be thought of, that could save part of the game to ram instead on disk, for a faster 'undo'.
OpenTTD was made to run on computers running 128-256MBof ram.
But the prices of RAM have dived the last years,leaving most home pc's with at least 1-2GB of RAM, some even 3-4GB.

So there's enough RAM space to work with.

[Rubidium]

The interruptive part of autosave is actually making the memory copy of the game state. The compressing/saving to the file is done in a separate thread and isn't as disruptive as the memory copy.

Still making autosaves every minute doesn't make it a undo.

[CommanderZ]

Would you like if Word deleted everything you wrote in last minute every time you hit Ctrl Z? I would have to smash the keyboard soon. Undo would only really make sense if it reverted last construction/destruction operation.

[FooBar]

Undo would only really make sense if it reverted last construction/destruction operation.

And in the meantime a train has occupied your newly built track. Then you hit undo. Then you complain that your train is stuck in the middle of the woods...

[CommanderZ]

Undo would only really make sense if it reverted last construction/destruction operation.

And in the meantime a train has occupied your newly built track. Then you hit undo. Then you complain that your train is stuck in the middle of the woods...

I'm not saying it makes perfect sense. There was a long thread about Undo some time ago. I explained my idea there in detail, I'm not going to explain it again. And I am also not saying it should be implemented, there much better to do. Such as Cargodest. Or copy&paste.

[ProDigit]

Nevertheless it can be argued that a lot in the game can be optimized by more fully using the ram,instead of writing to disk.
Another reason why I believe this could be possible (snapshot) is, if openttd uses CPU cache memory to take a snapshot, the information needs to pass the frontside bus. When OpenTTD was created, computers had an FSB of 100 to 133Mhz (both intel and AMD alike).
Now not only have the processors and ram increased in speed, and size; but the cache as well as the FSB speed.
Today's FSB is about 1000-1333Mhz, about 10x the speed of a pc of the late '90's;and cache went from 64kb to 6Mb (about 100x larger) while OpenTTD has not increased more than 4x in complexity (I presume) compared to the firsts of versions created. This should translate to at least 10x faster snapshots.

Another thing that can be done during snapshots (or autosave) is to perhaps set a higher priority to take a snapshot of "moving things",and alternating values (like train/cars positions, finances, cargo load/unloading, ;and put priority lower for more static values (like eg: town's inhabitants, town names and locations, places and types of houses and industries, trees location etc...).
That way it might be possible to create a non-interuptive autosave that can spread over a couple of thread passes (or CPU cycles),leaving only the changing and vital savegame data on the first cycle or pass of creating a savegame...

I'm not a programmer, but think this should be possible given some work,and should somewhat reduce the time a system freezes to take a snapshot.
Then one can save the snapshot from RAM to HD in however cpu cycles are necessary (in another thread).

This should at most somewhat slow down the game, but not totally freeze the game.

I don't know how far autosave already implements this way of taking a snapshot, but it seems programmers are up to date to create separate threads for OpenTTD,which should somewhat improve gameplay.

As to the user who commented against autosave undo,and talked about CTRL Z in Word:
What would you preferably want? Accidently erasing a large part of text,and being able to recover 20%;or erasing a large part of text and being able to recover 75%?
Most people can remember what happened in the past 2 minutes of a game/text, but forget what happened in the past 15minutes.

If you don't like it, then it'd be nice to have a button where one can disable the autosave feats, set the amounts of autosaves to disk, and enable/disable the undoautosave...
if one can disable it in the main option window,I think a game can only improve; giving the option to all users.

[DaleStan]

When OpenTTD was created, computers had an FSB of 100 to 133Mhz (both intel and AMD alike).

Not so. My computer, which wasn't fast when it was new, and is at least half again as old as Open, has a 100 MHz FSB.

Now not only have the processors and ram increased in speed, and size; but the cache as well as the FSB speed.
Today's FSB is about 1000-1333Mhz, about 10x the speed of a pc of the late '90's

Which has exactly nothing to do with the price of tea in China; OpenTTD was released in 2005, I believe. Possibly 2006, and definitely no earlier than 2004. I know because it wasn't around when I joined the forums.

Another thing that can be done during snapshots (or autosave) is to perhaps set a higher priority to take a snapshot of "moving things",and alternating values (like train/cars positions, finances, cargo load/unloading; and put priority lower for more static values

And how do you propose to guarantee that the "more static" values won't change (due to player interaction, for example), while the shot is snapping? Freeze the simulation is by far the easiest solution.

What would you preferably want? Accidently erasing a large part of text, and being able to recover 20%; or erasing a large part of text and being able to recover 75%?

Neither. I want to recover all 100%. And so would any OpenTTD user.

[Rubidium]

Another thing that can be done during snapshots (or autosave) is to perhaps set a higher priority to take a snapshot of "moving things",and alternating values (like train/cars positions, finances, cargo load/unloading, ;and put priority lower for more static values (like eg: town's inhabitants, town names and locations, places and types of houses and industries, trees location etc...).
That way it might be possible to create a non-interuptive autosave that can spread over a couple of thread passes (or CPU cycles),leaving only the changing and vital savegame data on the first cycle or pass of creating a savegame...

I'm not a programmer, but think this should be possible given some work,and should somewhat reduce the time a system freezes to take a snapshot.
Then one can save the snapshot from RAM to HD in however cpu cycles are necessary (in another thread).

So Word should make an autosave while you're pasting in an image and only store 50% of that image with a very high chance that it results in a corrupt file? If you don't know anything about programming, don't pretend that you know the solution because you (usually) don't. This is proven by your statements once again. Furthermore if you start talking about CPU cycles also take the paging into account as that might very well be more significant than the number of CPU cycles the saving takes.

[ProDigit]

you know?
Both of you are bitching like little bitches.... Sorry to say...
Instead of being grateful for responses, and ideas.
I might as well just shut up(or be like you,bitching about nothing working)... Which I don't.
I thought we've evolved from being teenagers (at least I did),and try to work together instead of working against eachother.

No wonder nothing like this exsists yet. And if Word can save a file without pause, OpenTTD which is based on Transport Tycoon created in the latter '90's, can do so too.

But if y'all goin' to say 'no' to everything,then have your OpenTTD work like today, without anything new;even 20years from now.
It's not as much as which feats get implemented or not; I'm not doing the programming,so I wouldn't care about what the developers decide that goes into openttd, and what not; it's more the way people respond on this forum that has been sub standard already for many years.
Despite me only having joined in 2005; the first time i read the forum was around the time when the mars edition came out on TTD (in the what's now known as 'New GRF settings'.

Instead of helping to move forward,anything written, any idea,any effort to help is being trotten down.
You know it costs me time too to write this thread?


So,with this I totally disagree with the explenations mentioned above! It is more than perfectly possible to do an autosave like I mentioned above, since it's in part already done; only now it can be optimized.
Many games already have autosave feats without pausing a game; including simulators.