Transport Tycoon Forums

As I currently see a lot of topics with issues where the player ignored the "Do not change newgrfs in-game!!!" warning, I have a suggestion. Maybe a console command which has to be entered before changing newgrfs in-game is possible reduces the number of topics with this issue. People who know what they are doing only have to enter that command once for each game, so not too big a problem for them. People who don't have a clue and simply ignore the warning cannot change newgrfs in-game without some serious investigation and reading online.

Arie- wrote:As I currently see a lot of topics with issues where the player ignored the "Do not change newgrfs in-game!!!" warning, I have a suggestion. Maybe a console command which has to be entered before changing newgrfs in-game is possible reduces the number of topics with this issue. People who know what they are doing only have to enter that command once for each game, so not too big a problem for them. People who don't have a clue and simply ignore the warning cannot change newgrfs in-game without some serious investigation and reading online.

That's definitely quite worth the discussion at least. Obviously the big red warning message presented ingame has not much effect either

There's meanwhile a number of settings which allow some extended functions like newgrf_developer_tools, ai_developer_tools and 'newgrf_show_old_versions'; so introducing another 'scenario_developer_tools' might make sense. But then that name I used is wrong: a scenario developer should know better

The "problem" is that there's a number of occasions where changing newgrf config makes sense and is mostly save:
a) engine pool is activated and adding another vehicle set; especially sensible for scenarios designed w/o vehicle sets so that the newest version can easily be added.
b) adding a house, stations, or newobjects newgrf; adding railtypes newgrf when it doesn't re-define an existing track-type.
c) changing a GUI-only parameter, e.g. toggling the "show flags" parameter for Swedish Houses
d) Removing or adding a newgrf which could be used as static (GUI only changes, no game play effect; e.g. tunnel replacement).

Also you'd have the problem of loading compatible newgrf when the original isn't found anymore: that's a change of the newgrf config, too. Does that require this new setting?

In the light of these conditions I'd personally prefer some more differentiated treatment; but that might be too much work for the trouble.

Arie- wrote:As I currently see a lot of topics with issues where the player ignored the "Do not change newgrfs in-game!!!" warning, I have a suggestion. Maybe a console command which has to be entered before changing newgrfs in-game is possible reduces the number of topics with this issue. People who know what they are doing only have to enter that command once for each game, so not too big a problem for them. People who don't have a clue and simply ignore the warning cannot change newgrfs in-game without some serious investigation and reading online.

Why should the devs implement this? If people are stupid enough to ignore the big red warning than surely they deserve to have their game crash.

Badger wrote:Why should the devs implement this? If people are stupid enough to ignore the big red warning than surely they deserve to have their game crash.

Sure, but still: it gives rise to a high amount of pointless support requests and worse: bug reports. I'm not entirely convinced that making it more difficult to change newgrfs ingame would reduce the amount of those; it might just shift the focus from "why doesn't it work anymore" to "how can I change".

That is correct, I had not thought about the possibility of a shift towards "Why doesn't this work anymore?". And indeed, there are a lot of topics on "bugs" only because players ignore the warning, that's why I came up with the suggestion. These questions however, are easier to answer as you immediately know what it concerns: enabling the renewal of newgrfs.
So then the question might be, how is it possible to enforce players to read up on the subject, I think that is rather impossible. The only way I can think of is still making the menu's accessible, graying out an "Ok" button and include a "Why doesn't this work?" button.

Regarding the more differentiated approach: is it really an issue when those who don't know cannot change parameters of or renew newgrfs? If it's that big a problem that people want to change looks or use a new compatible version of a grf, they still can do so only by typing a console command (which can be found by reading) or asking for help.

Here's the patch agains r20794. It adds a config-file setting "newgrf_add_remove" which allows to change newgrf in a running game, when enabled. Default is 0.

It might need some refinement: it will be nice, if one could browse the parameters which this patch currently disallows, too. But allowing to browse the parameters, too, means to increase the size of this patch dramatically so I chose - for testing purposes - to not implement that (yet).

Ok I'm seriously considering installing a development environment on my PC, but I already know that it's going to take to much of my time as I'm currently already doing my Master thesis, my Bachelor thesis and a small research elective on the side. I'm afraid it's going to be too distracting. So, sorry I currently am not possible to test this.

Sorry Badger, I tend to agree with Arie and Planetmaker. I'm involved in the development of the 2cc set and I often change the newgrf with the latest nightly. And often my test game gets screwed up because of that. Not to mention that I'm never 100% certain that everything in that game is OK and that I could see "bugs" where there are none.

I'm not chaging the newgrf because I'm stupid, but because I need to test the latest nightly and see if we've done something wrong. Do you think that making a new scenario every time would be easier? I don't think so, sorry. Personally, I'd really like to see the idea Planetmaker said:

planetmaker wrote:engine pool is activated and adding another vehicle set; especially sensible for scenarios designed w/o vehicle sets so that the newest version can easily be added.

From what I've seen the problems always seem to be when people remove grfs from a game, rather than adding newer ones.

Badger wrote:From what I've seen the problems always seem to be when people remove grfs from a game, rather than adding newer ones.

Usually. But I can easily write you one which will cause problems if you add it. And such newgrfs are around.

Badger wrote:From what I've seen the problems always seem to be when people remove grfs from a game, rather than adding newer ones.

Adding NewGRFs can disable (read: remove) NewGRFs, which is equally troublesome and not as obvious to the user or to us when reading the gamelog.

Furthermore updating NewGRFs is a tricky case, especially if one of the following NewGRFs (sharing the same GRF ID) is used. That list ignores NewGRFs with the same name that are incompatible with eachother due to shuffling of IDs or something.

• "PeCeT_full's Food Shop/Bar" - "Real Arcade Town Set v.0.1"
• "Czech RoadSet v1.1" - "OpenGFX Graphics Replacement Set r1"
• "DBSextXL Extension" - "DB Double Deck Coaches"
• "New 8 & 32 bpp houses for Open TTD" - "Camping.grf"
• "Small cars" - "SeoulMetro + SMRTC" - "magnumccw.GRF" - "Korean Train set v1.6 (Dec 20th 2009)" - "Metro Subway Set" - "mahtu5w.grf" (yes, 6 with the same GRF ID).
• "DSW-B80C(c)BeSt&RK" - "RE160(c) BeSt-Com 2004"
• "Pizzabote" - "TT-MS_BRIDGE"
• "F1Jordan" - "Escort Van"
• "wrefit.grf" - "curvetst.grf"
• "Serbian road vehicles. Tram set." - "Serbian Tram set - OTTD Remix." (those don't sound compatible with eachother)
• "Japanese Stations" - "Chinese Town Names" - "Japan Set Town Names"
• "Brazilian Town Names 0.1 (Beta)" - "Indonesian Town Names 0.1 (Beta)"
• "TransRapid Tracks r1" - "Dutch Tram Set r15"
• "Tu-204/Tu-214" - "Boeing 757-300"
• "Polish PKP Set v1.6" - "Japan Face Set v1.1" -"CHINOOK.GRF"
• "Long Introduction Date for Trains and Cars" - "Powerfull Train"
• "New Factory for TTD" - "Multi-Storey Car Park" - "New HQ"
• "New carriage for the temperate climate in TTD" - "New helipad 2.0"
• "Articulated engine test" - "MagLev Replacement" (might not be considered as one is a test, but it has been used on a public server)
• "Ruauto. Maz 500,503,500B" - "Soviet passenger fleet: Project 342 "Raketa"" - "Mazw.GRF"
• "fairlie.GRF" - "TGV Atlantique" - "Dutch Trainset Prerelease 1"
• "Finnish Roadset" - "CS roads"
• "Finnish Railset" - "CS railroad tracks"
• "# Industry airport" - "# Water airport"
• "Metro Track Set" - "FIRS Industry Replacement Set nightly-r119"

That is 25 on 688 (unique) GRF IDs, so roughly 4% of these GRF IDs has definitely been used for multiple different NewGRFs and loading one of the others will definitely lead to unwanted results. There are actually a few cases where this resulted in an actual crash. What is especially worrying is that some GRF IDs are used by three or more different NewGRFs!

Nevertheless... BaNaNaS, OpenTTD's ingame content thingy, doesn't allow duplicate GRF IDs. So it will enforce uniqueness of GRF IDs amongst the NewGRFs uploaded there, but it doesn't solve the already existing pool of duplicate GRF IDs.

Rubidium wrote:[*]"Japanese Stations" - "Chinese Town Names" - "Japan Set Town Names"

Nevertheless... BaNaNaS, OpenTTD's ingame content thingy, doesn't allow duplicate GRF IDs. So it will enforce uniqueness of GRF IDs amongst the NewGRFs uploaded there, but it doesn't solve the already existing pool of duplicate GRF IDs.

I beg to differ - unless you get into specific versions of each I can have all three of these GRFs loaded at the same time.

Gremnon wrote:I beg to differ - unless you get into specific versions of each I can have all three of these GRFs loaded at the same time.

Might be true, but that doesn't mean that when you're using those specific NewGRFs you'll possibly get into trouble. The list is also purely based on GRF ID and I've copied the exact name of the colliding NewGRFs and only one version of each set, except for the CS vs Finnish rail and road sets as for those there are multiple versions of both.

Actually, the master server doesn't know any "Japan Set Town Names" or "Chinese Town Names" with a different GRF ID than the one they share! There are a few "Japanese Stations vX.Y" with a different GRF ID though.

Nevertheless, the point remains that the GRF ID can't be trusted when talking about upgrades, so upgrades aren't even close to safe when using the same GRF ID.

OK, a question made by a total idiot when it comes to IDs and other "programming" stuff:

Is it absolutely safe to change a NewGRF with a newer version (nightly) for testing purposes? If not, could it be implemented somehow?

Voyager1 wrote:OK, a question made by a total idiot when it comes to IDs and other "programming" stuff:
Is it absolutely safe to change a NewGRF with a newer version (nightly) for testing purposes? If not, could it be implemented somehow?

It's not and it cannot be. It all depends on what the newgrf author does.

What I usually do for nightly testing is just overwriting the previous version so that the new(er) nightly version is loaded instead of the previous nightly I was testing before. Usually that's quite save.

It is absolutely not save when the IDs of a house, station or industry tile or a vehicle are changed and get a different meaning or get removed.
Also you can get necessarily problems when the cargo properties / refit options for vehicles are changed, same possibly for industries.

You'll ruin your playing fun, if you re-define the output or input cargos of industries or houses, re-define the town growth cargos as it messes the economy.

Many things more, of course, anything what _can_ be different can in principle differe between two nightly versions of a newgrf. The question is: will it? Or will it 'only' fix small issues with, say, single vehicles, update graphics or add an additional one without changing other vehicles.

All in all: you'll have to use your judgement on whether the changes may break your game (somewhat) and whether these changes require you to test in a new game or whether you can continue to re-use your test game savely.

Thanks, that's all I wanted to know.

I never change anything except the nigthly in question, only one per game. Well, I'll just keep the faith that the newer nightly won't mess it up. At least not too much...

if this is implemented please leave an option to still flip palettes in game ive had a few GRFs who get their dos and windows mixed up and need their palette swiching to avoid horrible purple blobs everywhere

switching palette is always a safe action, there is no reason to remove that.

Rubidium wrote:[*]"Serbian road vehicles. Tram set." - "Serbian Tram set - OTTD Remix." (those don't sound compatible with eachother)

Actually, first is version for TTD Patch, and second is version for OTTD.

Eddi wrote:switching palette is always a safe action, there is no reason to remove that.

Yes, definitely. No NewGRFs check for the palette of OpenTTD/TTDPatch and disable themselves when they find the wrong palette. Or are there NewGRFs that actually check the palette? After all, they can check it so why not do it?

I know for a fact that the 1.0.x openttd[dw].grf actually actively check whether the palette OpenTTD provides is correct. So I see no reason why other NewGRFs don't do the same. There might be NewGRFs for which changing the palette is safe, but it is definitely possible to make a NewGRF that breaks OpenTTD in the same way as just removing a NewGRF in-game would do. So, in my opinion changing the palette in-game should be considered equally unsafe.

Having said that, NewGRF Action14 has been specifically designed to allow NewGRFs to tell OpenTTD about things such as the used palette. Support for that has been added to OpenTTD trunk and as such NewGRFs that give the right information will automatically get the right palette regardless of the palette of your base graphics. So the need to actually change the palette in-game (or at all) becomes lower and lower when NewGRFs start to actually provide this information. Just request that the others add the needed information to the NewGRFs so OpenTTD can do the right thing without the user actually having to toggle the palette.