"Undo" button - was it added?

[Malleus Dei]

Customizability is a real word.

That's w-o-r-d.

[Goody]

Originally Posted by Malleus Dei

Customizabiity is a real word.

I'm tired and I first read that as "customizability is real world." which is a pretty powerful statement.

[Malleus Dei]

Customizability is a real word in the real world.

[fhomess]

Originally Posted by Markus Heinsohn

That's the reason why it isn't in there yet

Considering how long people have been asking for this, and how it's likely quite a bit simpler to solve than something like mass select or rewriting the pitching model, I don't understand why this is.

Originally Posted by Smetana

Instead of an "undo" feature, put a confirmation box on certain events, like lineup changes, roster moves, etc. You move the player, then a box pops up and asks if you want this to happen

You don't even need a confirmation box that pops up, just a button that allows you to accept your changes. I honestly can't think of one good reason why you would design software that doesn't allow users to recover from mistakes. It's not like you need "undo" functionality on everything, just the areas where it's easy for a user to flub something. Heck, OOTP6 asked you to confirm lineup changes before it saved them, and that's not something that is unrecoverable even after it's saved. Putting the wrong pinch hitter in or dragging and dropping a player to the wrong part of your organization have an impact on that game or player.

[Smetana]

Originally Posted by Crosley Field

Kind of what I said 2 posts before yours, isn't it?

Guess I might wanna' read a bit better, huh?

[Malleus Dei]

Or maybe just more.

[jmknpk2]

I think a generic undo "anything" button would be an extremely overwhelming task. It would require catching-before-implementing, or temporarily-holding of each action, or recording-in-a-reversable-manner every action that the game performs. Which would affect basically everything the game does (and nearly all the underlying code involved). Not to mention an extreme level of complexity that it might introduce behind the scenes.

The mention of a transaction log in a database is a good analogy. But I think all of the actions that the game performs, especially with underlying files, etc. are too varied to generalize in a database transaction log model, without completely rebuilding the entire game with that goal in mind.

On the other hand, I think the most common situation where people want the undo button is on the in-game roster changes. I think we have all done something like accidentally dropping a relief pitcher onto our backup catcher's lineup slot when the starting catcher has already been expended, leaving us in a heck of a mess. If I try to imagine schemes where this might happen in real life (like assigning the task to a foolish coach or something like that), I come up empty.

I think the ability to have a big green button at the top of the lineup changes screen that says "accept changes" and a red button that says "undo changes" is something that the developers might be able to get their hands around? Seems like isolating just that portion of code and re-writing would not necessarily be a monumental task?

Is version 12 too far ahead to start hoping for something along these lines?

As far as undo for other items in the game, I, personally am satisfied with the ability to make and recover from backups. If I screw up enough, I can just go back to my most recent backup and "do over". Once I overcame the massive learning curve involved with the game, I rarely make a mistake that causes me a big enough headache, except for the in-game lineups. Sometimes I forget to set the scouting budget or something along those lines, but depending on the circumstances the "undo" button wouldn't adequately fix that kind of problem in a simple or straight-forward fashion anyway.

[endgame]

Maybe we can narrow down the scope of the problem areas to the ones in which users commit the most errors and include the option in v12 for 5X magnification and the temporary disabling of the mouse or touchpad to micro-pixel movements.

[Qrusher14242]

i know i wish there some kind of undo or confirmation when pinch hitting. Wasnt this in the old versions?? A box used to come up asking you if you wanted to do this. And if you made a mistake you would just hit no. Course it was a lot harder to make a mistake before because the lineup screen had a better layout and it was easier to read. In the last few versions, its very easy to place a player in the wrong spot. I've done it a lot.

Now, it would be cool if after you selected a player and then dragged him over the player you want, it maybe highlights the player or have a box around it to indicate thats where you want him to go. Right now you can drop the player in between 2 players and have no idea where he is going.

[Tullius]

But I think all of the actions that the game performs, especially with underlying files, etc. are too varied to generalize in a database transaction log model, without completely rebuilding the entire game with that goal in mind.

It is not a problem (and modern database management systems offers many solutions here) but it is a problem when your datas are not "properly" organized. Before anything is changed the programm can simply check if the "undo" button is not used and only then write the changes in all other files.

I have mentioned a mistake when i included a pinch hitter in the pitchers slot in a DH league and after realizing my mistake i substituted him instantly. In this case the pincher hitter will have nevertheless a fielding stat as "P" although he was never on the mound.

The problem i see is that the game method of data handling is relative basic and grown over many versions so that changing it would require a huge amount of work but when it is not really broken then you think at least twice about it ...

[CalvinHobbes]

I agree with some of the other posters that all you need is an Apply button. So that if you drag a player to pinch hit and put him in the wrong spot, or your finger slips off the mouse button you can just move him to the appropriate spot and then hit apply. That way nothing is written to the various other places in the game and there is nothing to undo. However once you hit apply, all bets are off. Seems fair and, if I may say so, easy? Wouldn't it be easier to code the game to NOT make changes until that apply button is pressed? I don't know, I took C++ programming once and hated it.

[thbroman]

Well, in the absence of any useful "undo" option, I will have to remain content with my own version of "undo": a sudden CTD caused by my pulling the plug! A bit time-consuming to reboot and all, but very effective!

[CalvinHobbes]

Originally Posted by thbroman

Well, in the absence of any useful "undo" option, I will have to remain content with my own version of "undo": a sudden CTD caused by my pulling the plug! A bit time-consuming to reboot and all, but very effective!

You can just kill the thread. Open up Task Manager, look for OOTP10.exe, and hit End Process.

In case you didn't know that.

[thbroman]

Originally Posted by CalvinHobbes

You can just kill the thread. Open up Task Manager, look for OOTP10.exe, and hit End Process.

In case you didn't know that.

Yes, for sure. I was exaggerating for effect. Call it dramatic license.

[BusterKing]

Originally Posted by CalvinHobbes

You can just kill the thread. Open up Task Manager, look for OOTP10.exe, and hit End Process.

In case you didn't know that.

Did you even noticed by doing that the pitchers rests are all screwed up like they played the game? Happened to me.

[Killing Time]

After reading that I am now very glad I have never pulled the plug on the game like that.

[CalvinHobbes]

Originally Posted by BusterKing

Did you even noticed by doing that the pitchers rests are all screwed up like they played the game? Happened to me.

I haven't, but I've only ever done it once that I can remember. It was after an inaugural draft, when I suddenly realized that I had drafted only prospects and nobody was ready to play in the bigs.

[mused2B]

On a mac, a force-quit of the app is an easy solution and I've relied on it for years with OOTP for these situations. I like that I'm forced out of the program, rather than tempted to repeat "trials" of a situation.

A compromise might be a "revert to saved" command, which should be pretty easy to implement.

[Malleus Dei]

Originally Posted by mused2B

On a mac, a force-quit of the app is an easy solution and I've relied on it for years with OOTP for these situations. I like that I'm forced out of the program, rather than tempted to repeat "trials" of a situation.

A compromise might be a "revert to saved" command, which should be pretty easy to implement.

I'd like to see a "revert to saved" command added to the game.

[texasmame]

Originally Posted by Tullius

It seems to me that including the "undo" button would require a massive change of code. A reason could be that the game uses an older database management system. Modern systems like ADO.net are so designed that between the orginal database and the "database in the memory" is a layer which is something like a placeholder (i have tried to explain it in a very simple way). So when you change something the original database is not affected until you want it. Then it is no problem to cancel changes. Modern database management systems use already transaction logs and so on so that you have as programmer much more opportunities.

What i have learnt here and by looking through some other threads is that the game uses only a very simple model. You change something and it is immediately saved. Period. It works well but is archaic and limits the options.

Now Markus can not simply use ADO.net because he supports also Macs and Linux. I sure there are solutions which can handle all plattforms but such an undertaken would require a rewrite of a big part of the engine.

Seems to me that lineup changes (where most of the UNDO problems occur) should be temporary until you return to the game screen. No UNDO button needed, just make returning to the game screen the DO button.

*shrug*