[GS] Two Modest Proposals about GS and NewGRF #8460
Replies: 4 comments
-
I like it, especially point 2. My specific usecase: Currently NewGRFs can change town growth behavior by changing cargo acceptance of houses, but only GS has access to changing the town information window. This leaves no way to effectively communicate to players your new town growth rules through NewGRF-only; it requires a 'companion' GS to add that information. (This is assuming the rule about keeping NewGRF and GS domains separate still holds, such that NewGRF won't gain this functionality) GS can also be useful for adding background or other gameplay hints through the storybook for more complicated setups, along with a host of other game-enhancing changes for a specific NewGRF. Although this is all possible now, it requires that players are aware of and activate your GS and NewGRF together, which can't be relied upon. Andy's point 1 would also potentially open up lots of possibilities, though what exactly would likely depend on implementation, and I don't have a specific usecase in mind at the moment. |
Beta Was this translation helpful? Give feedback.
-
See also GS Identities https://gist.github.com/TrueBrain/fe3c80e7dc9313b7ac7941540e5dee22 |
Beta Was this translation helpful? Give feedback.
-
I think 2 is a good idea. That said, Squirrel is much easier to read, write, debug and extend than NFO/GRF. On 1, I think that the principle of communication between mods (GSs, GRFs, etc.) is a good idea, but I think that the mechanism of shared writable registers is a bit problematic. Adding persistent registers scoped to a GRF as a whole seems fairly easy and inoffensive, but it seems likely that they'd also end up as another temporary scratchpad for computation/switches. Allowing GSs or other GRFs to write into the registers owned by another GRF is (in my opinion) not a good idea, and should probably not be allowed. GRFs are already quite opaque and difficult to debug. Unexpected interactions between unrelated GRFs are also already a problem. Giving GSs their own "GRFID" and their own registers which only they can exclusively write to would probably be better, (except for pre-emption issues, see below). GSs have different behaviour to GRFs:
could be interrupted between the two lines for an arbitrary length of time. Mod developers may want to communicate things larger than a single register, and may want to do things like send a request with data and receive a response in another register. A few other thoughts: |
Beta Was this translation helpful? Give feedback.
-
Thanks JGR for such a detailed reply 👍 Pre-emption issues seem difficult. I am wary of adding confusion by using the wrong terminology, but it seems to me that authors using GS<->grf communication need to design it to be asynchronous, more akin to message queues or similar. Examples use cases that might work:
Whereas e.g. delegating grf industry production callback handling to GS would be architecturally just not possible. This would be fine. Re: named registers. Same issue applies when authoring grf. They can probably be named as constants in nml, but I skipped that and named them in the FIRS compile https://github.com/andythenorth/firs/blob/master/src/industry.py#L1577 These are for the industry registers, which are not exposed externally, and vary per industry type, so it's just an FYI, not anything we could build on. I do have ideas for FIRS -> house grf communication, which will use the town registers, and will need a convention for which register holds what. I wondered about reserving some registers to provide something like a schema (mapping conventional labels to register numbers). Probably too complex right now though. I wondered about exposing a schema in action 14, but that would be grf-global, and rely on authors not changing the schema per-town. I am way out of my depth on that 😄 I haven't tried accessing the town register via grf debug window, but I will need to for the FIRS -> house grf idea. Aside I've only suggested registers for this as they're an existing structure and we understand them. There could be other ways. |
Beta Was this translation helpful? Give feedback.
-
1. Permit GS - NewGRF communication via registers
GS - NewGRF co-operation about data
Who gets to write, and who gets to read-only, I will leave to people better at this than me.
2. Permit packaging a GS with a grf
Reducing friction for players to use co-operative GS + NewGRF
Assumes something like Capability API pre-exists https://wiki.openttd.org/en/Development/Design%20Drafts/Scripts/Capability-based%20API
How to package 2 types of co-dependent content, I will leave to people better at this than me.
See also
"A modest proposal" is usually intended as satire 😄 https://en.wikipedia.org/wiki/A_Modest_Proposal
I don't intend these proposals as satire. They just seem quite...hard 😸
Beta Was this translation helpful? Give feedback.
All reactions