feat: 105769, 105771: updates to korolov (continuous sandbox mode, up…

[ArisayaDragon]

…date to use properties, fix freighter criteria to allow any freighter designed for korolov compatibility)

https://ministry.kronosaur.com/record.hexm?id=105771
https://ministry.kronosaur.com/record.hexm?id=105769

[gcabbage]

I don't think these changes will be sufficient to get the behaviour you want.. as there are several redundant checks on player level / stronghold presence you haven't updated.

FYI - I originally converted the old station code to MissionType in: kronosaur/Transcendence#32 and kronosaur/Transcendence#33

• This used the standard rpgMissionAssignment lambda, so KSMission01 and KSMission02 had to include the check on the remaining missions and stronghold etc.

George added the "mission board" style dsKorolovEscortList in df3fd3c (and kronosaur/Transcendence#56)

• This duplicates a lot of the "can create" mission logic in the Korolov actionOperations action
• Normal non-escort missions are checked first via rpgMissionGetAssignment and manual calling of dsRPGMission
• player level checks, stronghold checks etc are also found here: https://github.com/kronosaur/TranscendenceDev/blob/master/Transcendence/TransCore/KorolovShipping.xml#L448-L515
• Even though you've modified the missions themselves to allow legends, the dockscreen will never attempt to create them in the first place.

We might need to think about the design of the Krolov mission assignment / escort assignment to make it a bit more flexible / meet all the sandbox needs, but I think:

• Mission "can create" logic should be removed from KSMission01 / KSMission02.

  • These are no longer called by the standard rpgMissionAssignment code, so we should not be reproducing the "available" mission checks etc here
  • korInitMissions is responsible for creating the escort missions. It will create a mission for EVERY available freighter, so we should probably move most of the checks etc here. (the standard rpgMission code assumes only one mission at a time will be open/active)

• The logic for "already a legend" / "charon dominates" etc could be moved to "blocker missions" - i.e. high priority missions that just display some text to prevent standard missions from generating

  • The "charon dominates" case will typically only occur if the player declines (or abandons) the destroy strong hold mission. But we could implement a follow on e.g. player is told to try again, but won't have any backup this time
  • Could also just update the operations action for now (or add another kor* lambda)

[gcabbage]

Is it worth splitting this into one property per level e.g.: korolov.containerPrice.1 korolov.containerPrice.2 etc.

These could be left undefined if you don't want them to offer for a particular level, effectively making korolov.minLevel unnecessary. You could also have a freighter only used for apprentices and masters but not journeymen (if you really wanted to)

[ArisayaDragon]

Ah yeah, thats a good idea

[gcabbage]

typ@ should also be able to get static data

[gcabbage]

We could also consider calling the rumor code when there are no missions or escort missions available

• this would be consistent with other stations that call rpgMissionAssignment
• this could be used to display some variant of the no escorts needs or freighters grounded messages

[ArisayaDragon]

I've switched this to a draft to get some more changes and fixes in, and to avoid merge problems with the Antares rework which is in a ready-to-merge state