New GRF

[OSkar000]

Disallowing the change of newgrfs after starting the game is by design. NewGRFs are an integral part of the map. That holds also for vehicles.

I think some kind of manual override is needed, otherwise it will kill a lot of the fun with making new scenarios.

It usually kills my fun when every day there's a new bug report of <whatever> going wrong and then only to find out that the person changed newgrf after map create.

use set scenario_developer 1 in the console and your control over newgrfs is back. Then all warranty is void though (as if there's been some in the first place ). If you can avoid to change NewGRFs, then do it by all means. Even changing vehicle grfs in the scenario editor does compromise the game and has the potential to introduce quite a bit of unwanted behaviour.

Thanks, that solved my problem (and maybe gave me some new probems).

[Gord]

I don't normally post in this section of the forums (or normally look here to be honest because if I come across a problem with the game...it's usually something I've done and not the fault of anyone else!), but just want to say thanks for posting that Planetmaker.

Good to know there are options for us who know the risks!

Although I do completly understand why the changes were made.

[Voyager One]

Sorry for bumping this already discussed topic but... I've noticed a "new" thing in one of the latest nightlies. You CAN'T change NewGRFs in-game any more, there's no option for that.

How do I change a NewGRF with the latest nightly? I need to do it 2-3 times per week. Do I need to start a new game every time from now on?

[planetmaker]

Sorry for bumping this already discussed topic but... I've noticed a "new" thing in one of the latest nightlies. You CAN'T change NewGRFs in-game any more, there's no option for that.

That's right, it's one of the primary reasons for game crashes and no-one ever reads the red warning box that it's the source of many different kind of troubles.

(svn r21116) -Add [FS#3012]: Reduce the chances to accidentially break savegames with NewGRFs

If you change NewGRFs on an existing map on a daily basis and you do NOT develop NewGRFs you do something wrong [TM]. If you test NewGRFs, just overwriting the existing NewGRF with the updated version will work and the game will most often load as compatible as usual (unless those versions are indicated as incompatible); as such even then you usually don't need to change the newgrf config, just replace the grf file and reload the game.

If you still insist on messing with savegames and insist you know all implications, e.g. it is an old scenario which you need to 'update' (and then provide such useful scenarios on bananas like one of the 'England and Wales' ones ) use the scenario_developer switch or use the newgrf_developer_tools for even more power (both console only) to get back the old behaviour.

[Voyager One]

Thanks for the tips. I'll try renaming the new nightlies.

I'm aware of the risk but I'm contributing and testing the 2cc set and I really want to know if I've drawn something wrong or anything else that's wrong in the nightlies.

Thank you.

[planetmaker]

I'm aware of the risk but I'm contributing and testing the 2cc set and I really want to know if I've drawn something wrong or anything else that's wrong in the nightlies.

Yes, but exactly there such setting is not needed active usually;-) The nightlies come all with the same filename within the same folder. You can just overwrite the existing one. And reload the game. Removing and Re-adding NewGRFs is MUCH more dangerous than such smooth update by a compatible newgrf.

(Just to convince myself that there's really everything just overwritten when unzipping a newer nightly over the old: No version names present except in the zip file name:

Code: Select all

~/ottd/grfdev/2cctrainset> unzip -l 2cctrainset-nightly-r683.zip 
Archive:  2cctrainset-nightly-r683.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
        0  11-26-10 10:39   2cctrainset-nightly/
  1093984  11-26-10 10:39   2cctrainset-nightly/2cctrainset.grf
      745  11-26-10 10:39   2cctrainset-nightly/changelog.txt
    35147  11-26-10 10:39   2cctrainset-nightly/gpl.txt
    18092  11-26-10 10:39   2cctrainset-nightly/license.txt
     4967  11-26-10 10:39   2cctrainset-nightly/readme.txt
 --------                   -------
  1152935                   6 files

[norbert79]

(svn r21116) -Add [FS#3012]: Reduce the chances to accidentially break savegames with NewGRFs

If you change NewGRFs on an existing map on a daily basis and you do NOT develop NewGRFs you do something wrong [TM]. If you test NewGRFs, just overwriting the existing NewGRF with the updated version will work and the game will most often load as compatible as usual (unless those versions are indicated as incompatible); as such even then you usually don't need to change the newgrf config, just replace the grf file and reload the game.

I disagree, and I hope this change won't be for long term. One very simple scenario: Running game, I discover a new GRF handling some more pretty fences or trees, but it's not the same I have used. So I have to add a new GRF and remove an older one. It needs to be done.
Other scenario: I start a game, play with it for around 10 years of gameplay, discover I have made a mistake by forgating addign one GRF, and/or to set right parameters. That needs to be also be done.

So I really don't like the idea not being able to modify any GRF settings while in game. I think such risk shall be leaved on the user, but having a reminder, that the user shall blame himself/herself if the game might crash. This has nothing to do with stability, this is just user own decision.

[Voyager One]

The nightlies come all with the same filename within the same folder.

Actually that's my stupidity at work - I download a nightly and rename it with a suffix regarding revision number (i.e. 2cctrainset-r685.grf). I'll just stop doing that.

Thanks mate.

EDIT: @norbert79: Have you read this topic at all? Did you understand it?

[norbert79]

The nightlies come all with the same filename within the same folder.

Actually that's my stupidity at work - I download a nightly and rename it with a suffix regarding revision number (i.e. 2cctrainset-r685.grf). I'll just stop doing that.

Thanks mate.

EDIT: @norbert79: Have you read this topic at all? Did you understand it?

Yes, I have.

[Voyager One]

Then you must understand why it has been deleted. Causing just too much problems.

*cough* and too many similar "why did my game crash" questions *cough*

[Nite Owl]

Actually that's my stupidity at work - I download a nightly and rename it with a suffix regarding revision number (i.e. 2cctrainset-r685.grf). I'll just stop doing that.

Actually you do not have to stop doing that. I do the same thing with regards to adding a version number to the name of a grf I have downloaded. If you add the newer version of the grf to the proper folder and then remove the older one and then start up OpenTTD it will recognize the newer version provided the grf ID has not changed. At least I believe it is based on the grf ID not changing. Please correct me if I am wrong.

[planetmaker]

At least I believe it is based on the grf ID not changing. Please correct me if I am wrong.

That's correct, but not the whole story.

Different grfIDs are never considered compatible.

But grfs with the same grfID can (meanwhile) define a version number and a minimum_compatible_version number. As such the grfID needs not change anymore (e.g. with this scheme FIRS would never have had to change grfIDs or NARS and NARS2 could have the same). The grf authors can now declare incompatibility by setting the min_compatible_version to the oldest version of itself to which it is still backward compatible.
The result can then be, of course, that a game played with an old version cannot update to a newer one, if it declares itself to be not compatible to that old version. After all NARS isn't compatible to NARS2 either.

See http://wiki.ttdpatch.net/tiki-index.php?page=Action14 for details

[Voyager One]

I changed the filename as I've said and it works fine. Ah, no problem, I just need it to work somehow. Thanks to all for the tips.

[belugas]

Just to remind you what can potentially happen:

Most precisely, the part where you can see the user's action

THis is far more frequent then what people may think.

[Voyager One]

I know, that's why I'm testing with a "test" game, not my "real" game. So, if it goes to hell, so be it. I just didn't want to make a new test game EVERY freaking time a new 2cc set nightly gets out.

[slaca]

ICE3 (db set xl) has smoke (like steam engines) in the newest nightly. Whats the problem?

[Kogut]

ICE3 (db set xl) has smoke (like steam engines) in the newest nightly. Whats the problem?

http://bugs.openttd.org/task/4275
http://www.tt-forums.net/viewtopic.php?p=914992#p914992

[zero.eight]

Is changing parameters in a running game considered to be dangerous in the same way that adding/removing NewGRFs is? I don't know how OpenTTD handles this, but changing parameters in a running game is useful for giving players options with immediate results. Given a large number of options and a user who wants to try all of them, it is much easier to change parameters in a running game than to change them from the main menu and start a new game each time.

A specific case: I have a NewGRF that provides sprite replacements (Actions A/5). Users can change the graphics by changing the values of parameters. Action 14 defines parameter minima, maxima and defaults (forced to 0). Parameters are handled by Actions 7 and 10 skipping forwards and backwards. I haven't managed to crash the game or get any unexpected results with this code, but that isn't proof that I won't ever do so. I can easily see the results of changing parameters since I set newgrf_developer_tools = true, however the average player will have to start new games because of FS#3012.

Arguably it is up to the NewGRF developer to provide code that won't lead to crashes or unexpected results through adequate testing and using code that isn't expected to cause such issues. In the case of parameters, this is helped by Action 14 limiting the allowed input values so a user cannot input a value that has not been tested. Therefore a developer has control over what a player can do with parameters, so perhaps it would be acceptable to (re)allow this functionality. Unless, of course, it is unsafe.

I hope I don't sound like I'm whingeing I think the change is good but I wonder whether it can be scaled back slightly.

[Eddi]

If only Action5/A are affected, the parameter change would probably be safe [compare: static GRFs], but OpenTTD cannot check that this is the only thing affected, thus it must be assumed it is unsafe.

an extreme example: you might combine two entirely different GRFs into one, and switch between them via parameter. this would be the same as switching the GRFs.

[planetmaker]

Is changing parameters in a running game considered to be dangerous in the same way that adding/removing NewGRFs is?

Yes. Consider this: if (param1 == 1) { deactivate(this grf) } else { deactivate(other grf) }. We can't do a semantical analysis of the whole grfs.