No one ever makes static grf versions

[SyberSycho]

I'm surprised no one ever makes a version that would be compatible as a static GRF. This would really only benefit those who do a lot of graphics but would allow everyone to use these graphics no matter what a multiplayer server has for enabled grfs. For example I really like the 32bit trains in opengfx+ Trains and would love them over the zbase graphics whenever I play on some servers. Not really talented enough to do it myself though

[Eddi]

you don't really need "talent" to turn a GRF into a static version.

it's just removing a lot of code. the NML Tutorial should give you all the tools you need for that.

[Supercheese]

Honestly, I think it's because the very concept of a Static grf is quite obscure, and most folks don't even know what they are, much less how to enable or create one.

[SimYouLater]

How exactly do you do it? What are the benefits? I might look into it for Iron Horse Quicksilver.

[Andrew350]

A 'static' NewGRF cannot change anything about the game-state, this includes anything like adding or changing vehicles, industries, houses, or modifying any properties like costs, speed, etc. Really, just about the only thing a static NewGRF can do is replace graphical elements via Action A (or 'replace' in NML) or similar, so making any kind of train set or such 'static-safe' is not possible.

What the OP is asking for however, simply overwriting the default train sprites with new ones, will work, but only for the default vehicles. All you need to do to make such a thing is get access to the new sprites you want, then code them in via a series of 'replace' commands (if using NML) into a basic NewGRF file. It really is just about the most simple NewGRF you could possibly make

As far as benefits goes, NewGRFs added to your 'static' list in the openttd.cfg file are not counted towards the 63 NewGRF limit for games, so if you have a few NewGRFs in your usual list which only do some simple graphical changes, such as changing road surfaces or trees or something, then adding them to the static list and removing them from the 'regular' NewGRF list can open up a couple of slots for more. Also, NewGRFs in the static list are automatically loaded in any game you play, including multiplayer servers, all your savegames, and even the opening title screen. Static NewGRFs take precedence over any loaded NewGRFs, so if for example a server you're playing on uses 'OpenGFX+ Trees' but you prefer 'Stolen Trees', adding it to your static list will make the 'Stolen Trees' appear for you instead. And static NewGRFs are not saved in the savegame itself, and thus can be added or removed from the openttd.cfg at any time.

The problem of course is that there's very little way of knowing ahead of time whether a NewGRF is static-safe or not, unless you are familiar with how NewGRFs work and what each one does exactly. Which is why it remains a sort of 'hidden feature' and not many know about it.

(The game will warn you and fail if you try to add a non-safe NewGRF to the list, so don't get any smart ideas about putting FIRS in your static list )

[kamnet]

Would it be helpful if we compiled a list of NewGRFs which could be used for static NewGRFs?

[Eddi]

if by "help" you mean "it will always be incomplete and outdated" and "the target audience won't find it"?

what we actually need is a proper GUI to set static newgrfs, and possibly an action14 entry (automatically filled in by NML, if possible) to easily filter for GRFs that can be made static.

possibly we could use a word that is more intuitive for non-programmers to describe what a static grf is

[planetmaker]

if by "help" you mean "it will always be incomplete and outdated" and "the target audience won't find it"?

what we actually need is a proper GUI to set static newgrfs, and possibly an action14 entry (automatically filled in by NML, if possible) to easily filter for GRFs that can be made static.

possibly we could use a word that is more intuitive for non-programmers to describe what a static grf is

I would recon, that such action14 could be easily abused. It probably would be better if OpenTTD would scan the NewGRF and determine from the actions it contains whether it is possibly a static NewGRF (possibly with erring on the side of excluding some legitimate ones).

[wallyweb]

I just scanned my current openttd.cfg and found the header [newgrf-static]. There were no GRFs listed under that header.
From the discussion, I get the impression that [newgrf-static] is akin to a preset with the difference being:

[preset-{preset name}] A GUI accessible collection of GRFs selected by the player where the collection is invoked by the player.
[newgrf-static] A text editor accessible collection of GRFs selected by the player or by the GRF itself where the collection is invoked by the source code.

Where a preset can consist of any GRF, a static must consist of GRFs that follow a set of specifications that are defined within the source code.

So now the question seems to be whether one wants [newgrf-static] to be GUI accessible and what would be the impact of such a decision.
Who gets to decide that a GRF is to be static?
Are the rules to be arbitrarily imposed?
How would one recognize the static status of a GRF?
Am I missing anything that needs to be considered?

[Eddi]

if by "help" you mean "it will always be incomplete and outdated" and "the target audience won't find it"?

what we actually need is a proper GUI to set static newgrfs, and possibly an action14 entry (automatically filled in by NML, if possible) to easily filter for GRFs that can be made static.

possibly we could use a word that is more intuitive for non-programmers to describe what a static grf is

I would recon, that such action14 could be easily abused. It probably would be better if OpenTTD would scan the NewGRF and determine from the actions it contains whether it is possibly a static NewGRF (possibly with erring on the side of excluding some legitimate ones).

the action14 entry would not have any impact of the GRF being loadable as static, it's just a hint for the GUI to allow easy filtering without scanning all GRFs beforehand.

the alternative would be to do the static-scanning in parallel to the md5 calculation.

I get the impression that [newgrf-static] is akin to a preset

depends what you mean "akin".

[history sidetrack]
originally, there was only a [newgrf]-section in the .cfg of the format "<filename>=<parameters>", and the used NewGRFs were not recorded anywhere, so you could change them at will.

because that led to all sorts of problems with savegames and multiplayer, the used NewGRFs got added to the savegame. from that point on, if you load a savegame or join a multiplayer game, the correct NewGRFs will be loaded.

at this point, the [newgrf-static] section got introduced, for the purpose of having GRFs that are not recorded in the savegame, so these GRFs will be loaded after all NewGRFs in the savegame are loaded. To make this safe with Multiplayer, there are some serious restrictions put on the type of GRF that can be used here. the short version is: "only graphical changes, nothing that affects gameplay".

the specifics varied a bit over time, and the check is a bit stricter than necessary, because that makes it faster to check. in theory you can craft things that are perfectly safe wrt. multiplayer, but to find that out is unprovable in the general case. (this is akin to the halting problem)

the newgrf-presets came much later, as the GUI evolved and the usage of GRFs increased, people demanded easier ways to switch between multiple sets, without going to the .cfg file and commenting out some lines. they copied the same "<filename>=<parameters>" format. at that point, in theory you could edit the .cfg file and turn any [newgrf-preset] section into a [newgrf] section.

and the last change in that series is the [newgrf]-Section itself, it got adapted (especially in the context of BaNaNaS) to handle multiple versions of the same GRF, and less reliance on paths, so the format there is now "<MD5sum>=<filename and parameters>" and differs from the other sections.
[/history-sidetrack]

Who gets to decide that a GRF is to be static?
Are the rules to be arbitrarily imposed?
How would one recognize the static status of a GRF?

the game does. and only the game. everything else is just guidelines and hints.

Am I missing anything that needs to be considered?

plenty of things, probably.

[kamnet]

if by "help" you mean "it will always be incomplete and outdated" and "the target audience won't find it"?

what we actually need is a proper GUI to set static newgrfs, and possibly an action14 entry (automatically filled in by NML, if possible) to easily filter for GRFs that can be made static.

possibly we could use a word that is more intuitive for non-programmers to describe what a static grf is

It might not every be complete, but not reason for it to ever be outdated. Maybe it's just me, but such a list seems more viable at the moment than adding a new GUI and code to the program.

*shrugs* Just a thought, anyhow.

[wallyweb]

I get the impression that [newgrf-static] is akin to a preset

depends what you mean "akin".

Similar in function, a select grouping of GRFs.

[history sidetrack]

All good stuff.

How about an Action14 that signals a GRF to identify itself in the "Detailed NewGRF information" panel in bright red bold all-caps as STATIC? (With apologies to orudge)
A proper description in the NewGRF Specifications would inform the viewer as to the implications.

[planetmaker]

I get the impression that [newgrf-static] is akin to a preset

depends what you mean "akin".

Similar in function, a select grouping of GRFs.

[history sidetrack]

All good stuff.

How about an Action14 that signals a GRF to identify itself in the "Detailed NewGRF information" panel in bright red bold all-caps as STATIC? (With apologies to orudge)
A proper description in the NewGRF Specifications would inform the viewer as to the implications.

A NewGRF which *can be* used as static NewGRF needs not necessarily be used as static one - it can be used as normal NewGRF required by all players - or at every individual player's choice - additional to any normal NewGRF as static one.

To me it's not a "selection of NewGRF like presets" (which is a user-defined set of NewGRFs), it's more a property of NewGRFs which the user has no influence upon (similar to "this is a vehicle NewGRF"; it's a property defined by the programmer when choosing to use or not use certain features. A property which OpenTTD can check (to some extend; the actual NewGRF specs are too complicated to detect in a sane way all edge cases comprehensibly without actually using the NewGRF ingame - thus OpenTTD would need to check it conservatively. To some extend at least OpenTTD does these checks for a NewGRF when it is actually declared to be used as static)