Platform Editor 2022 ideas

[broncepulido]

18 hours ago, Byron said:

If I can beat my Scenedit into submission I plan to start writing some scenarios. Having said that, someone will have to a) point me to the latest/most used Db and b) show this hammer swinging old yardbird how to install the new Db without breaking everything. I do have time and a vicious imagination

Simply to point you:

 

[CV32]

One of the worst offending annexes when it comes to the hard ceiling of the annex limits is the Loadouts annex.

The HCDB/HCDB2 has tried to alleviate the pressure on total number of entries in that annex by sharing Loadout entries across multiple platforms when it comes to their 'Ferry' mission.

In other words, multiple aircraft of varying types with a roughly similar ferry range value now share a single Loadout annex entry.

Assuming annex limits remain, one way to potentially alleviate the pressure would be to create a new field in the Aircraft annex for 'Ferry range'.

This would eliminate the need to create 'Ferry' loadouts altogether, and free up hundreds of Loadout entries in that annex.

Its kinda ugly, it has potential side effects, and its just one example of where the annex limits create headaches for DB editors.

Random thought.

[TonyE]

I wrote some custom code to turn the list of requested platforms Eric has been recording into a tabular format should it be a useful format for consumption.  See the table at the bottom of https://harpgamer.com/harpforum/hc_platform_requests/

[donaldseadog]

On 11/18/2021 at 8:06 AM, Byron said:

If I can beat my Scenedit into submission I plan to start writing some scenarios. Having said that, someone will have to a) point me to the latest/most used Db and b) show this hammer swinging old yardbird how to install the new Db without breaking everything. I do have time and a vicious imagination

Hi Byron

I wrote a little "helper" for starting the scenario editor mostly to more easily manage the database reference. Its in the downloads section and called (I think) ScenEdit Launcher - or similar. 

It lets you eg put differing database files in respective folders and named however you like.

(Sorry I'm vague here but I'm working off phone on holidays)

DonT

[donaldseadog]

If I have it right at game start the referenced database is loaded into memory and that's what the GE uses during play. In a vague random thought I wondered if it's feasible to load additional data from an "addendum" db file or two? 

Would that help?

DonT

[TonyE]

6 hours ago, donaldseadog said:

If I have it right at game start the referenced database is loaded into memory and that's what the GE uses during play. In a vague random thought I wondered if it's feasible to load additional data from an "addendum" db file or two? 

Don, yes, when we switched from 2047 to 4095 items per annex that included loading the entire database into memory.  I tinkered with a similar approach a couple of years back except it was adding a new AnnexId (32-bit unsigned integer for 4 billion records) while leaving the existing AnnexId on all of the data structures.  Your suggestion is an interesting variant that would allow loading any number of databases so a deranged (as they all are) database author could split up data among multiple databases (USA platforms 1946-1978 in one DB, USA 1979-2000 in another, Portugal in another, ...).  For that person it would be a nightmare of maintenance but the existing platform editor could continue to be used.

The game changes would be significant but less significant than any approach I've considered.  A subset of the changes:

1. Data structure changes to have the database key move from AnnexId to AnnexId+DBName.  DB Flavor is made up of name and timestamp.  It is customary to also embed a yymmdd with the database name, ex. HCDB-150928.  I would think we would assume that practice is in play and use just the name portion so the Ship with AnnexId 2048 would be 2048+HCDB rather than 2048+HCDB-150928 but it is a business rule choice, as a programmer, I don't care which approach is chosen.

2. Anywhere the game references an AnnexId, update to AnnexId+DBName.  At the logic level this breaks scenario and saved game formats.  We've had scenario format conversions for a long time and saved game format conversions for years as well so this isn't new ground.  At the UI level, it means showing the DBName in a bunch of places (scenario editor unit picker so you make sure to grab an HCDB2 F-14D rather than an HDCB F-14D), Platform Display, etc.

 

This could be a reasonable fallback approach.  Thank you for raising it!  If I missed your intent, please correct me.

 

The approach driving my proof of concepts is to have a monolithic, multi-maintainer, database fronted by a web-based user interface.  Once you decide it or a piece of it should be usable in the game there are a variety of approaches to consider.

a. Make all of the game modifications to accept the gigantic database, build in filters to make selection easier (i.e. search for F-14 rather than scrolling to Iran or USA then finding right platform as we do today).  I view this as the best user experience but the most development-intensive.

b. From the platform editor have the scenario author choose the platforms they want to use in their scenario, enforce the 4095 items per annex limit, and export a one-off database for use in the game.  No game changes would be needed to leverage this one-off.  The complexity is on the platform editing tool side and the poor user experience is for the scenario author needing to select their platforms both in the platform editing tool and in the scenario editor leading to some back and forth, multiple database exporting, etc.

c. Have the database authors group platforms into releases that fit within the 4095 item per annex limit.  Scenario authors then have a package from which to start.  But...scenario authors would be limited to the bundling choices made by the DB author so you probably won't be flying F-14s off of USS Nimitz against Misubishi Zero fighters.

[donaldseadog]

6 hours ago, TonyE said:

Don, yes, when we switched from 2047 to 4095 items per annex that included loading the entire database into memory.  I tinkered with a similar approach a couple of years back except it was adding a new AnnexId (32-bit unsigned integer for 4 billion records) while leaving the existing AnnexId on all of the data structures.  Your suggestion is an interesting variant that would allow loading any number of databases so a deranged (as they all are) database author could split up data among multiple databases (USA platforms 1946-1978 in one DB, USA 1979-2000 in another, Portugal in another, ...).  For that person it would be a nightmare of maintenance but the existing platform editor could continue to be used.

The game changes would be significant but less significant than any approach I've considered.  A subset of the changes:

1. Data structure changes to have the database key move from AnnexId to AnnexId+DBName.  DB Flavor is made up of name and timestamp.  It is customary to also embed a yymmdd with the database name, ex. HCDB-150928.  I would think we would assume that practice is in play and use just the name portion so the Ship with AnnexId 2048 would be 2048+HCDB rather than 2048+HCDB-150928 but it is a business rule choice, as a programmer, I don't care which approach is chosen.

2. Anywhere the game references an AnnexId, update to AnnexId+DBName.  At the logic level this breaks scenario and saved game formats.  We've had scenario format conversions for a long time and saved game format conversions for years as well so this isn't new ground.  At the UI level, it means showing the DBName in a bunch of places (scenario editor unit picker so you make sure to grab an HCDB2 F-14D rather than an HDCB F-14D), Platform Display, etc.

 

This could be a reasonable fallback approach.  Thank you for raising it!  If I missed your intent, please correct me.

 

The approach driving my proof of concepts is to have a monolithic, multi-maintainer, database fronted by a web-based user interface.  Once you decide it or a piece of it should be usable in the game there are a variety of approaches to consider.

a. Make all of the game modifications to accept the gigantic database, build in filters to make selection easier (i.e. search for F-14 rather than scrolling to Iran or USA then finding right platform as we do today).  I view this as the best user experience but the most development-intensive.

b. From the platform editor have the scenario author choose the platforms they want to use in their scenario, enforce the 4095 items per annex limit, and export a one-off database for use in the game.  No game changes would be needed to leverage this one-off.  The complexity is on the platform editing tool side and the poor user experience is for the scenario author needing to select their platforms both in the platform editing tool and in the scenario editor leading to some back and forth, multiple database exporting, etc.

c. Have the database authors group platforms into releases that fit within the 4095 item per annex limit.  Scenario authors then have a package from which to start.  But...scenario authors would be limited to the bundling choices made by the DB author so you probably won't be flying F-14s off of USS Nimitz against Misubishi Zero fighters.

I didn't realise the ge still made so much reference to the external db structure, I envisaged it filling pigeon holes with the external data then just referencing its pigeon holes, and by loading from multiple data base just filling more pigeon holes - kind of analogy.

I'd been pondering ways of spreading the load of database management and flexibility in updating.

I like your 'b' option especially if the scenario editor can choose from multiple database 🙂

[TonyE]

5 hours ago, donaldseadog said:

I like your 'b' option especially if the scenario editor can choose from multiple database 🙂

My mental analogy to 'b' is a hardware store.  You sit at home building a list of what you want, a small subset of what the store stocks.  Go to the store, buy everything on your list, go home and start on your project.  Then you realize you need three more parts, go to the hardware store, buy some more.  Rinse and repeat.  It works but isn't as great as having the who inventory of the hardware store right outside your door.  It may well be the optimal place to start, we can always build the teleporter to the hardware store 'a' later.

[donaldseadog]

On 11/19/2021 at 6:02 AM, CV32 said:

One of the worst offending annexes when it comes to the hard ceiling of the annex limits is the Loadouts annex.

The HCDB/HCDB2 has tried to alleviate the pressure on total number of entries in that annex by sharing Loadout entries across multiple platforms when it comes to their 'Ferry' mission.

In other words, multiple aircraft of varying types with a roughly similar ferry range value now share a single Loadout annex entry.

Assuming annex limits remain, one way to potentially alleviate the pressure would be to create a new field in the Aircraft annex for 'Ferry range'.

This would eliminate the need to create 'Ferry' loadouts altogether, and free up hundreds of Loadout entries in that annex.

Its kinda ugly, it has potential side effects, and its just one example of where the annex limits create headaches for DB editors.

Random thought.

I don't think that's ugly at all. I love it. Maybe load outs could have a range factor and be shared across multiple aircraft? Maybe don't need loadouts but compatible weapon bundles, each with its range factor? 

Maybe this could then even allow getting around the unlimited aircraft weapon situation?

Very random thoughts.

[donaldseadog]

arguably this thought is more scenario design, but there's an overlap with the current database discussion I think. Often when doing a scenario design you know in the back of your mind a platform you want to use but you can't remember which country uses the one you're after. What would be useful would be a search of the database on key words, eg pull up all F16s. Maybe a stand alone tool?

[TonyE]

2 hours ago, donaldseadog said:

arguably this thought is more scenario design, but there's an overlap with the current database discussion I think. Often when doing a scenario design you know in the back of your mind a platform you want to use but you can't remember which country uses the one you're after. What would be useful would be a search of the database on key words, eg pull up all F16s. Maybe a stand alone tool?

Agreed, from above <g> ", build in filters to make selection easier (i.e. search for F-14 rather than scrolling to Iran or USA then finding right platform as we do today)."

[TonyE]

An initial technology platform strawman.

PlatformEditor.drawio.svg

[CV32]

On 11/21/2021 at 2:42 AM, donaldseadog said:

I don't think that's ugly at all. I love it. Maybe load outs could have a range factor and be shared across multiple aircraft? Maybe don't need loadouts but compatible weapon bundles, each with its range factor? Maybe this could then even allow getting around the unlimited aircraft weapon situation? Very random thoughts.

Speaking as a DB editor, its worse than ugly.

The last thing you want (again, from the perspective of a DB editor) is for your changes to any single annex entry to have negative effects on the values of multiple other annex entries. To the point of potentially making a scenario unworkable.

Speaking as a scenario creator, its worse than ugly.

[donaldseadog]

2 hours ago, CV32 said:

Speaking as a DB editor, its worse than ugly.

The last thing you want (again, from the perspective of a DB editor) is for your changes to any single annex entry to have negative effects on the values of multiple other annex entries. To the point of potentially making a scenario unworkable.

Speaking as a scenario creator, its worse than ugly.

I hadn't thought of that aspect of changes, yes that would put a spanner in the works 😑

[TonyE]

While I've been quiet, I have been tinkering away.  I'm working on a docker compose file to spin up the various major software components on which to build the new platform editor.  There has been a lot of trial, and a lot of error, but I'm making progress.  My current battle is with the Kong API gateway.  I was attempting to just use mapped paths but am succumbing to the fact that I'll have to use docker volumes to prevent permissioning problems.  It is also more extensible but more complex.  In short, nothing fun to show yet but nginx (static content), nginx (reverse proxy) containers are starting up without error, Kafka is close, MongoDB isn't started, and SpringBoot isn't started.