research.json: Allow inline resmessage definition, derive major research from msgName/intel* properties#4810
Conversation
All major research should specify `msgName` (the `RES_MSG` to display in intel screen), and all minor research should not. As such, `techCode` property in `research.json` files seems superfluous as it is mutually exclusive with `msgName` in those files. This update uses the presence, or lack thereof, of `msgName` in the `research.json` file to set the `research.techCode` property in research data, and then removes all `techCode` properties from the `research.json` files in `base/stats/` and `mp/stats/` folders. Some research topics had neither `techCode: 1` nor `msgName`, which will be discussed in the PR and may require further commits to add missing research messages for those items.
Refactor emum `research.techCode` to a bool `research.isMajor` to make code more legible.
|
Alfred added a few more mortar upgrades for campaign so you may have to look at those and rebase off master. IDK what messages are missing between campaign/mp, or how much some of those .txt are still playing a role. Ultimately I could envision that we can probably rip out similar stuff away from the MP files to isolate the unique messages, and MP can have its own (small) unique files for mp-specific stuff only (and then resmessages from data/base gets loaded along side a resmessagemp). For Scourge, I happened to find And no, we don't need multiple message files for skirmish (or really campaign either). It's a relic from when there were split research files for the 3 campaigns (and probably a similar system for tech levels) when Pumpkin probably did init stuff in a more piecemeal fashion. As of now all those resmessageX.json files are loaded all at once together. |
|
I've been making JSON Schemas for all the JSON files so should be able to detect any other missing stuff; will take a look at the weekend. I'll also take a look at what's going on in the code to see what's involved in trimming down to a single file for cam and a single file for mp. While it would be trivial to filter out any unused resmessage ids for mp, I don't know if they're used by mods so probably best to keep them. |
|
tl;dr: Merging the What I've found so far with the `resmessage*.json` loading - pure horror...
But any There doesn't seem to be any duplication (I'll need to write a script to fully confirm) across the files. As an initial step to getting a handle on what's in each file, I asked an AI to categorize the messages - this is for campaign and I assume mp is similar: So yeah, looks like cam 1, 2, 3, then stuff relating to cam 1+2, and 2+3, and general stuff that's not specific to a particular campaign. Knowing this at least gives some indication of where to add any missing messages. To "confirm" that the entries in
// around line 1446 in whatever this is 👀🤷♀️:
bool success;
/* load a data file */
debug(LOG_NEVER, "file: %s %s", (yyvsp[(2) - (3)].sval), (yyvsp[(3) - (3)].sval));
success = resLoadFile((yyvsp[(2) - (3)].sval), (yyvsp[(3) - (3)].sval)); // <-- here
free((yyvsp[(2) - (3)].sval));
free((yyvsp[(3) - (3)].sval));There's an ancient map somewhere drawn in charcoal with a drawing of a UFO with tentacles captioned "here be low level tokenizer".
Anyways, there's no technical reason to have multiple files, but I suspect if they were combined in to single files, or even renamed, it would break any mods that alter research, so... looks like we're stuck with multi-file chaos. That being said, if there's a will to break some mods I'd totally be up for merging them or at the very least renaming them so it's obvious what's in them. Or put them in a |
|
Initial scans of the json files with basic validation script... loads of unused research messages in both cam and mp. How much stuff would break if we renamed all the research messages to be the same as the id of the research they are linked to, because that would make so much more sense? Checking research/resmessages json in BASE
|
|
I did some experimentation with putting resmessages in to single file, but also moving the resmsg audio / text in to
|
This is backwards compatible so shouldn't break any mods or addon campaigns. If both `intelAudio` (string) and `intelText` (array of 4 strings) are defined in a `research.json` entry, create a `VIEWDATA` (id = research id) based on the research data, store it in `apsViewData`, and update `msgName` property in research data to be value of the research id. Additionally, the icon used for the intel screen is derived from the research item :) If a research entry contains both `msgName` and `intel*` properties, the `intel*` properties take presendence over `msgName`. The WzConfig filename is stored in the VIEWDATA, allowing modded `research.json` to be used, and also handles switching between campaign and multiplayer modes, etc., loading/unloading VIEWDATA as expected. While this will add a little RAM bloat, due to duplication of the existing messages, that can be offset if we cull unused messages from the current `resmessages*.json` files (there are loads of messages defined that don't get used anywhere as far as I can tell). This will enable mods / addon cams / etc, to port over to new format as and when desired, with the ultimate goal of completely removing the `messages/resmessages*.json` files as that data can be put in `research.json` instead.
|
New commit allows research message to be defined inline within the research data in If both If a research entry contains both The WzConfig.filename is stored in the VIEWDATA, allowing modded While this will add a little RAM bloat, due to duplication of the existing messages, that can be offset if we cull unused messages from the current This will enable mods / addon cams / etc, to port over to new format as and when desired, with the ultimate goal of completely removing the |
aubergineagain
changed the title
techCode from msgName presence in stats/research.jsonresearch.json: Allow inline resmessage definition, derive major research from msgName/intel* properties
2 participants
Summary:
research.json:intelAudioandintelText(array of 4 strings) in the research definition to create a custom research message for that item, which will use the same icon as the research item.msgName, it will work as expected. Note thatintel*properties take precedence overmsgName.techCodeproperty removed (or ignored); presence ofintel*ormsgNameproperties will make it major research, otherwise minor research.Ultimate goal is complete removal of
messages/resmessages*.jsonfiles at some point in the future.TODO: Add some missing research messages that were identified during work on this PR (see original PR description below).
Fixes #4839
Click for original PR description...
All major research should specify
msgName(theRES_MSGto display in intel screen), and all minor research should not. As such,techCodeproperty inresearch.jsonfiles seems superfluous as it is mutually exclusive withmsgNamein those files.This update uses the presence, or lack thereof, of
msgNamein theresearch.jsonfile to set theresearch.techCodeproperty, and removes alltechCodeproperties from theresearch.jsonfiles inbase/stats/andmp/stats/folders as they are no longer required.EDIT: Refactored
research.techCode(enum) ->research.isMajor(bool) to make code more legible.ini2json_research.pystill referencestechCodebut left that unchanged. Any occurrences oftechCodeinresearch.jsonfiles (eg. in Reclamation addon campaign) will be ignored.Some research topics were missing both
techCode(thus defaulting to0= major research) andmsgName(effectively = minor research) properties, as follows:base/stats/research.json:"R-Defense-Pillbox-RotMG"msgNamemissing"R-Wpn-RocketSlow-ROFRR01"techCode: 1was missing"R-Wpn-Missile2A-T"msgNamemissingmp/stats/research.json:"R-Defense-MRLHvy"msgNamemissing"R-Sys-SpyTower"msgNamemissing"R-Wpn-Missile2A-T"msgNamemissing"R-Wpn-Rocket02-MRLHvy"msgNamemissingQuestions:
RES_MSGstuff betweenbase/messages/andmp/messages/, including themessages/strings/resstrings.txt, as applicable?RES_MSG- and if so, what ID should it use, and whichresmessages*.jsonfile(s) should it go in?mp/messages/resmessages*.jsonfiles, given there are no campaign chapters in mp/skirmish/challenge games? Could it be pruned to justresmessagesall.json(in another PR)?