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

Disable to change NewGRFs in running game by default #3012

Closed
DorpsGek opened this issue Jul 4, 2009 · 15 comments
Closed

Disable to change NewGRFs in running game by default #3012

DorpsGek opened this issue Jul 4, 2009 · 15 comments
Labels
component: NewGRF This issue is related to NewGRFs flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

DorpsGek commented Jul 4, 2009

foobar opened the ticket and wrote:

More and more people are complaining about things not working as expected after changing or removing newgrfs in a running game. It appears that the do-not-readme warning gets less and less sufficient.

In order to limit those 'bug' reports I came up with the idea to disable the possibility to open the NewGRF settings window from a running game by default. Enabling this feature (as it's still useful sometimes if you know what you're doing) should only be possibly by editing openttd.cfg, as people who edit that mostly know what they're doing or at least have read the manual and are aware of what can go wrong...

Reported version: trunk
Operating system: All


This issue was imported from FlySpray: https://bugs.openttd.org/task/3012
@DorpsGek
Copy link
Member Author

DorpsGek commented Jul 6, 2009

planetmaker wrote:

Editing the cfg won't do any good as it doesn't impact a running game. But an option in the cheat menu "allow changing newgrf" might be a solution :)


This comment was imported from FlySpray: https://bugs.openttd.org/task/3012#comment6294

@DorpsGek
Copy link
Member Author

DorpsGek commented Jul 6, 2009

foobar wrote:

Why not? My suggestion is only about hiding the newgrf dialog in a running game, nothing more, nothing less. That needn't be stored in a savegame, a setting under [misc] in openttd.cfg is more than sufficient.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3012#comment6295

@DorpsGek
Copy link
Member Author

Rubidium wrote:

You're missing one major cause of changed NewGRFs: loading other people's savegames. Adding a setting to hide the NewGRF settings doesn't fix that at all.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3012#comment6489

@DorpsGek
Copy link
Member Author

foobar wrote:

Interesting...
I'm not completely aware of how it's currently handled (I don't load other people's savegames if they require certain newgrfs I know I don't have), but anyways:

If not all newgrfs are available and my suggested feature is disabled (the default) then deny loading the game.
If my feature is enabled, load the game and display the usual warning.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3012#comment6490

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 5, 2010

planetmaker wrote:

The attached patch introduces a new config-file-only setting "gui.scenario_developer". Unless this setting is enabled, one cannot load games anymore where one is missing the exact newgrfs. Also one cannot modify the newgrf config in an existing game. It is supposed to work analoguously to ai_developer, developer and newgrf_developer.

EDIT: the question arises whether loading of savegames and scenarios with compatible NewGRF shall be forbidden by this setting as well (as now) or whether this should be allowed or guarded by yet another config setting - this time maybe by a visible one in the adv. settings?

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/3012#comment8860

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 5, 2010

planetmaker wrote:

The attached patch applies on top of the previous patch and adds an option in the adv. settings which allows to enable and disable loading of savegames with compatible NewGRFs.

Thinking about it, the visible option to load games with compatible NewGRF seems desirable: if not present, many people might enable the scenario_developer, even if only loading a game where they have not the exact same version... and then they will be able to change newgrfs.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/3012#comment8861

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 7, 2010

planetmaker wrote:

After IRC discussion, a pre-condition for proper support is action14 support for minimum compatible version. Attached patches provide action14 support for "MINV". The savegames save the current newgrf version and a savegame has missing newgrf, if only newgrf with a higher MINV are found.

They probably can easily be made one commit, though, but provided for better reading as three separate patches.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/3012#comment8875

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 7, 2010

planetmaker wrote:

Updated version of 'minversion.diff'. The min_loadable_version was not copied when a compatible newgrf was loaded. Thanks for spotting, frosch.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/3012#comment8876

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 7, 2010

planetmaker wrote:

test newgrfs:
snowlindmod-1.0.0.zip: contains version 39, no min_loadable_version set (=0)
snowlinemod.grf: version 45, min_loadable_version=37

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/3012#comment8877

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 7, 2010

planetmaker wrote:

Yet another update of the two main patches. Thanks for the quick and extensive feedback.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/3012#comment8879

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 7, 2010

planetmaker wrote:

Hm... as usual. The obvious typo or omission after posting

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/3012#comment8880

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 8, 2010

planetmaker wrote:

Update. Now only shows the newest version in the NewGRF selection from the main menu.

The introduced enum FindGRFConfigMode might (currently) be replaced by a boolean named 'get_newest', but the enum seems more extensible and possibly some subsequent refactoring, unifying the call of FindGRFConfig and putting some more logic in that routine; maybe adding a return parameter which tells whether an exact match, a compatible match, an incompatible match with the same grfID or no match was found.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/3012#comment8886

@DorpsGek
Copy link
Member Author

frosch wrote:

Grfs can now specify compatibility.

Alternative GUIs might still be nice :)


This comment was imported from FlySpray: https://bugs.openttd.org/task/3012#comment8936

@DorpsGek
Copy link
Member Author

planetmaker wrote:

updated patch under http://devs.openttd.org/~planetmaker/scenario_developer.diff


This comment was imported from FlySpray: https://bugs.openttd.org/task/3012#comment8938

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 7, 2010

planetmaker closed the ticket.

Reason for closing: Implemented

In various versions from r20918 to r21116


This comment was imported from FlySpray: https://bugs.openttd.org/task/3012

@DorpsGek DorpsGek closed this as completed Nov 7, 2010
@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) component: NewGRF This issue is related to NewGRFs enhancement labels Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: NewGRF This issue is related to NewGRFs flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

1 participant