Rough instance-json-builder config json

[neil-morrison44]

Hey, as mentioned on the discord here's roughly (it's late here, just want to sketch things out before I forget) what I think'll work for the JSON file which updaters (etc) parse to know how to build the instance jsons

So in the core you'll have, alongside data.json & core.json etc a instance-packager.json (or a better name) which, for this, could look like...

{
   "output":"Assets/pcecd/Mazamars312.PC Engine CD",
   "data_slots":[
      {
         "id":100,
         "filename":"*.cue",
         "sort":"single",
         "required":true
      },
      {
         "id":101,
         "filename":"*.bin",
         "sort":"ascending",
         "required":true
      }
   ]
}

with the "sort" being "single" | "descending" | "ascending" - the latter two starting at the specified id then listing files sorted in whichever order - could also just use the presence of the wildcard for this if we don't care much about descending vs ascending / throwing an error if there's more than one .cue.

for anything requiring a bit more we could have...

{
   "output":"Assets/ng/Mazamars312.NeoGeo",
   "data_slots":[
      {
         "id":3,
         "filename":"srom",
         "sort": "single",
         "required":true
      },
      {
         "id":4,
         "filename":"prom",
         "sort": "single",
         "required":true
      }
   ],
   "memory_writes":[
      {
         "address":"0x00000004",
         "data":"0x12345678"
      }
   ],
   "overrides":{
      "wjammss":{
         "memory_writes":[
            {
               "address":"0x00000004",
               "data":"0x87654321"
            }
         ],
         "data_slots":[
            {
               "id":3,
               "filename":"srom",
               "sort": "single",
               "required":true
            },
            {
               "id":4,
               "filename":"prom",
               "sort": "single",
               "required":true
            },
            {
               "id":5,
               "filename":"crom0",
               "sort": "single",
               "required": true
            }
         ]
      }
   }
}

Here the script would merge in the overrides on top of the default if the folder where it found all the required files matched "wjammss" - allowing all the things that can go into an instance json like core_select etc

Updaters would read the data_slots list & walk the Assets/.../common folder for the core until they find a folder with matching files then process it into an instance.json & place it in the output folder with the right data_path, magic value etc

Let me know if there's anything this wouldn't cover, property names etc can definitely be improved & it could maybe have an extra layer of nesting to guard against if Analogue ever add properties called output / overrides

[Mazamars312]

Just added to the /dist/core/ folder the instance-packager.json file.

Will that help?

[neil-morrison44]

Think so yeah, means me and / or @mattpannella can have a go at an implementation of the parser / json builder & see if the format's enough

[mattpannella]

finally getting around to looking at this, seems good to me. not sure of what else i'd need, but maybe once i implement this i'll run into something

[neil-morrison44]

Couple of things from trying it out:

{
   "output":"Assets/pcecd/Mazamars312.PC Engine CD",
   "platform_id": "pcecd",
   "data_slots":[
      {
         "id":100,
         "filename":"*.cue",
         "sort":"single",
         "required":true,
         "as_filename": true
      },
      {
         "id":101,
         "filename":"*.bin",
         "sort":"ascending",
         "required":true
      }
   ]
}

• Added a platform_id so we can know where to start looking for the files from just reading the one file - the core.json does let you specify multiple platforms but I'm not sure if this should have to worry about that? (since that'd require multiple output folders too...)
• As per discord discussion with @mattpannella have added an (optional) as_filename property to the data slots so we can copy the .cue (or whatever's name) as the JSON's filename (will default to the folder name if unset)

Can also set the filename explicitly for overrides

{
   "overrides":{
      "wjammss":{
        "filename": "Windjammers"
      }
  }
}

[neil-morrison44]

How safe do we think it is using the folder name as the key for the overrides bit?

If it can't be trusted we could use a hash of one of the files or something (similar to the as_filename key)?

Could be that keying off of the folder name is static enough between sets & it's not worth worrying about though

[mattpannella]

yeah i feel like using the folder name as key is safe enough. if someone doesn't use the right name, it won't break. it just won't get the overrides

[Mazamars312]

Just to give you a heads up @neil-morrison44 we are limited to 27 tracks, I completely forgot about the other system files here.

[neil-morrison44]

I wonder if we should add a property to the JSON that says the maximum number of all slots & if it's over that we do something?

Probably just warn the user & not save the JSON file (unless files with too many slots have some functionality?)

[Mazamars312]

Done in the json now :-)