Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Improve restart command #7328

Merged
merged 1 commit into from Sep 24, 2020
Merged

Feature: Improve restart command #7328

merged 1 commit into from Sep 24, 2020

Conversation

Berbe
Copy link
Contributor

@Berbe Berbe commented Mar 5, 2019

When the restart command is issued, a normal map is always spawned.

This improvement takes into account the current state of _file_to_saveload to check if a savegame/scenario/heightmap was previously loaded, and loads the same resource again.

@PeterN
Copy link
Member

PeterN commented Mar 5, 2019

I'm not sure I would expect restart to reload the game.

@planetmaker
Copy link
Contributor

planetmaker commented Mar 5, 2019

I'm not sure I would expect restart to reload the game.

I think such makes sense for competitive servers which re-run the same scenario. Could be argued that 'restart' generates a new map with current newgame settings while 'reload' restarts the currently loaded map / savegame.

@PeterN
Copy link
Member

PeterN commented Mar 5, 2019

Yes, a reload command is what I was thinking of.

@Eddi-z
Copy link
Contributor

Eddi-z commented Mar 5, 2019

Here's what i intuitively would think restart would do:

  1. try to load the scenario (or heightmap) this game was originally started from, or
  2. start a new game with the current game seed and settings

but don't do anything special with savegames.

@Eddi-z
Copy link
Contributor

Eddi-z commented Mar 5, 2019

That would mean, a reference to the original scenario/heightmap must be stored in savegames, and this reference must still work if the file was moved (fallback to 2. if it was not found)

@nielsmh
Copy link
Contributor

nielsmh commented Mar 5, 2019

How about the Quake approach - have a variable/setting containing a console command to execute on game end? That command could be a simple newgame command, or it could be one to execute a longer script. It would probably need some kind of additional check to confirm a new game was in fact started, and if not create a new default game.

@Eddi-z
Copy link
Contributor

Eddi-z commented Mar 5, 2019

i don't see how that has anything to do with the topic being discussed.

this is about what the restart command should do, not about ways it should be triggered

@Berbe
Copy link
Contributor Author

Berbe commented Mar 5, 2019

At the moment, in trunk, if you use restart on a randomly generated map, it generates the same map again, ie using the same seed.
Since the state does not change, I find it appropriate that when loading an external resource (be it savegame/scenario/heightmap), the same behaviour apply, that is applying the same exact starting conditions again.

Hence, I don't understand your restart/reload split as I am merely attempting to mimick the current behaviour.

@Berbe
Copy link
Contributor Author

Berbe commented Mar 5, 2019

Here's what i intuitively would think restart would do:

1. try to load the scenario (or heightmap) this game was originally started from, or
2. start a new game with the current game seed and settings

but don't do anything special with savegames.

Why would you make savegames stand out? Savegames and scenarios are kind of the same resource. To me they are interchangeable.
What if you wanted to host games deriving from a specific savegame? On (automatic - after year N) restart, you would spawn a new randomly generated map, which would miss the point.

@Eddi-z
Copy link
Contributor

Eddi-z commented Mar 5, 2019

Why would you make savegames stand out? Savegames and scenarios are kind of the same resource. To me they are interchangeable.

they might be interchangable on a technical level, but not really at a logical/usage level.

What if you wanted to host games deriving from a specific savegame?

you could make that savegame into a scenario, then start from that scenario.

but what about the reverse? what if you loaded a backup savegame because of some griefers that messed everything up? you'd restart from that instead of the original one in your way.

@Berbe
Copy link
Contributor Author

Berbe commented Mar 5, 2019

they might be interchangable on a technical level, but not really at a logical/usage level.

It is true I got carried away by the technical level, as I did not have a point of reference for semantics in OpenTTD. Savegames & scenarios are literally the same, except the former did not necessarily come from the editor...

I made some changes to only intercept savegames in editor mode. Would that be satisfactory?

@Berbe Berbe force-pushed the restart branch 2 times, most recently from 0e6a350 to e13ac77 Compare March 5, 2019 18:45
@Berbe Berbe marked this pull request as ready for review March 6, 2019 21:05
@stale
Copy link

stale bot commented Apr 5, 2019

This pull request has been automatically marked as stale because it has not had any activity in the last month.
Please feel free to give a status update now, ping for review, or re-open when it's ready.
It will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

@stale stale bot added stale Stale issues and removed stale Stale issues labels Apr 5, 2019
@Berbe
Copy link
Contributor Author

Berbe commented Apr 10, 2019

Ping?

src/openttd.cpp Outdated Show resolved Hide resolved
src/openttd.cpp Outdated Show resolved Hide resolved
@Berbe Berbe force-pushed the restart branch 3 times, most recently from 4b2718f to 1fdd16c Compare August 8, 2019 14:48
@Berbe Berbe changed the title Improve restart Feature: Improve restart command Aug 8, 2019
@Berbe Berbe force-pushed the restart branch 2 times, most recently from 8715f42 to 4279881 Compare February 10, 2020 20:17
src/openttd.cpp Outdated Show resolved Hide resolved
When the restart command is issued, a normal map is always spawned.

This improvement takes into account the current state of _file_to_saveload to check if a savegame/scenario/heightmap was previously loaded, and loads the same resource again.
@@ -1078,7 +1078,22 @@ void SwitchToMode(SwitchMode new_mode)
MakeNewEditorWorld();
break;

case SM_RESTARTGAME: // Restart --> 'Random game' with current settings
case SM_RESTARTGAME: // Restart --> Current settings preserved
if (_file_to_saveload.abstract_ftype == FT_SAVEGAME || _file_to_saveload.abstract_ftype == FT_SCENARIO) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made some changes to only intercept savegames in editor mode. Would that be satisfactory?

I don't think it would, tbh. Would just be a confusing edgecase.

Besides, when could this actually happen? You can't load savegames into the editor, only scenarios (even if they're just savegames renamed to .scn extension)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You refer to a reply from 13 months ago, on a codebase which has changed since then.
I do not understand your comment in the context on the discussion you quote, applied to unrelated code?
What are you expecting to see?

@LordAro LordAro dismissed their stale review April 13, 2020 16:01

Old review

@michicc michicc merged commit 8f3d1ec into OpenTTD:master Sep 24, 2020
@SamuXarick
Copy link
Contributor

I don't like this feature at all.
There should be an alternative method to restart a loaded savegame with the settings used for that savegame.
There was an effort to make 'restart' attempt to re-create the same world starting from the generating process, and making most of the world gen settings saved on the savegame played a part for that to happen.

That effort seems to have gone forgotten with this feature now in master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants