Register to handle strings with given version character

[justarandomgeek]

Request spurred by the following IRC conversation:

<KomanBryce> justarandomgeek: do you have a link to anything about the blueprint format?
<KomanBryce> e.g. utilities for read/writing it
<justarandomgeek> it's "0" + base64(deflate(json))
<justarandomgeek> older ones are base64(gzip(serpent))
<justarandomgeek> and disk uses a bastard mix of the two, base64(gzip(json))
<@HanziQ> y u no version byte
<justarandomgeek> what version byte should i use for it?
<justarandomgeek> other than not-"0"
<justarandomgeek> it seems wrong for me to use 1, because then you guys have to skip a number one day
<@HanziQ> just use something
<@HanziQ> d
<@HanziQ> j
<@HanziQ> whatever
<@HanziQ> make it distinguishable
<@HanziQ> that's why it's there
<justarandomgeek> and the lack of documentation around the string format makes the intent unclear
<justarandomgeek> i'll update it to use d or D then
<justarandomgeek> would be nice if a mod could register to handle strings pasted with a given version char
<@HanziQ> interesting idea
<justarandomgeek> and get either the string or the json object it contains in game-standard version+base64(deflate(data))
<justarandomgeek> i guess i need to talk to Rseding91|P about that, huh?
<@HanziQ> most likely

I would like to be able to register for a callback when a data string is pasted in the blueprint import box with a given version character, with either the raw string or the data table it contains as data on the callback. This would simplify import/export of data for mods using item-with-tags, like my DISK mod. Ideally, game would handle the encoding/decoding, since that will result in more consistent data-string if more mods use this facility.

[justarandomgeek]

Thinking about how this might work, I think the simplest way may be to define a prototype similar to the custom-input one which specifies the char/string prefix to use, and an event name to fire when one is imported. Ideally, we'd get an event-data object that is the decoded data, but the string itself as data would also work.

Alternately, a method could be added script.on_string_import(prefix,f) to register for these similar to events, but that seems more likely to have problems when multiple mods want to register for the same prefix.

[Rseding91]

Thinking about how this might work, I think the simplest way may be to define a prototype similar to the custom-input one which specifies the char/string prefix to use, and an event name to fire when one is imported. Ideally, we'd get an event-data object that is the decoded data, but the string itself as data would also work.

Alternately, a method could be added script.on_string_import(prefix,f) to register for these similar to events, but that seems more likely to have problems when multiple mods want to register for the same prefix.

Multiple mods registering for the same event isn't a problem. All events already work that way.

[justarandomgeek]

Thinking about how this might work, I think the simplest way may be to define a prototype similar to the custom-input one which specifies the char/string prefix to use, and an event name to fire when one is imported. Ideally, we'd get an event-data object that is the decoded data, but the string itself as data would also work.

Alternately, a method could be added script.on_string_import(prefix,f) to register for these similar to events, but that seems more likely to have problems when multiple mods want to register for the same prefix.

Multiple mods registering for the same event isn't a problem. All events already work that way.

You're looking for a different kind of problem -- I'm imagining a scenario where careless mod authors register for two different formats using the same identifying prefix, which seems like it should be an error. I can't come up with any scenario where i'd want a mod-format string handled by multiple mods that doesn't involve secondary ones subscribing (via event or remote.call callback) to the primary handler to get called with the *result* of importing said string.

I think registrations for prefixes should have to be unique, and if multiple mods try to register the same prefix it should either be an error or have a clear "winner" that gets all the events (like last-registered?). I also think there should be a public registry of used datastring prefixes, to help avoid collsions, and will probably create one if nobody else does.

Perhaps instead of shoving this into the event space, it should really be another namespace like remote and command, something like "datastring" or "importstring" or similar.

add_prefix(string prefix, LocalisedString formatname, function import(table data or string data))
remove_prefix(string prefix) (maybe?)
prefixes :: dictionary string->Localised String (?)
game_prefixes :: dictionary string->Localised String (?)

Thus, a mod could register (and maybe unregister? not sure that's useful...) for prefixes that are not already claimed, and must provide the prefix, a display name for the format, and the handler function for importing. If import() is given decoded data (instead of the raw string), It may also be useful to provide datastring.export(string prefix, table data) for producing export strings (so everyone uses consistent compression/encoding - the same as blueprints!).