Oolite Bulletins

I've been going through Xeptatl's Sword, a mission OXP that spans over 8 galaxies. And while doing so I see that a great deal of effort has been put to circumvent/avoid clashes with other mission OXPs. That made me think about some sort of mission control mechanism, something of a single flag variable that could be set to notify that a (big) mission is in progress.

Obviously mini missions (contracts, random hits, rescue missions etc) would not use it, but missions that just pop up asking the player to participate in some action could use it by checking the variable and instead of inviting the player could just ask the player to come back later or something. And mission OXPs that want to set up whole systems would definitely benefit from it by not borking other missions.

Removing an OXP that has set the flag would naturally clear the variable.

Core missions should also set the flag so that they do not get interrupted by OXPs.

Just a thought .

spara wrote:

... while doing so I see that a great deal of effort has been put to circumvent/avoid clashes with other mission OXPs.

Ain't that the truth!

I still have nightmares about jumping through hoops!

Rather than a flag, perhaps a string that contains the name of the worldscript that "has the ball" so to speak. That way, on startup, a check can be made to see if that worldscript still exists, and if not, the string can be cleared.

Thinking about it a bit more, perhaps an array should be used. OXP's could flag that they want the ball by adding their name to the array. The item at index 0 would be the OXP with the ball. As missions are completed, the array is adjusted, moving items up the list. OXP's could then check to see when their name hits index 0, and then start their mission.

This would be a really easy thing to OXP - naturally, the harder thing would be applying the change over all the existing mission OXP's.

But whatever way this goes, I think it's a really important thing to add.

This feels mostly like something which can be OXPed rather than needing core support (and OXPed quicker than we could necessarily provide core support) - if it works well we can always incorporate it later. Just agree on a mission variable to use for it.

Most mission OXPs don't particularly conflict with others running at the same time anyway - it tends to be the shorter one-off things like contracts which have time limits, while (realistically or not) the longer missions you can wander off and come back to another time largely without penalty.

The populator changes in 1.80 should make it easier to avoid conflicts over system content - at least once more OXPs are converted to use them.

As far as the core missions go:
- Trumbles can coexist with other missions (and the "mission" part of it is one mission screen sequence)
- Constrictor Hunt has no time limit and you can easily go do something else in the middle.
- Thargoid Plans likewise, though once you've picked up the plans it might not be a good idea to go elsewhere
- Nova certainly would conflict with other missions, but that can equally happen after it's finished. Avoiding G4 for OXP missions or having plausible alternative worlds to use in case of emergency is necessary here.
- Cloaking Device should be safe to occur within a normal mission.

I'll ponder it a bit while going through xeptatl's, that oxp probably uses most of the tricks in the book . While doing so, I'll try to remember to write notes on possible conflicts and list'em as more generalized scenarios. Maybe that will lead to something useful.

Thanks. I'm certainly happy to make it easier to avoid inter-OXP conflicts, but there's probably a better way than a "get mission lock" command to do it.

Here's the first scenario. I don't really expect there to be a solution to this, but maybe this will raise some thoughts.

Problem: A one shot overtaking of a system. Using custom populator is not really a solution as we will want to take over the system just once. Current effective way of doing it is by removing everything in shipExitedWitchspace (sendAllShipsAway and remove stations). Problem naturally is that this is done after the population step so spawning has already happened and OXPs most likely act on that assumption.

Possible solution: Some way of notifying that the system is going to be overtaken before population takes place. That way OXPs could act on it in advance. I have no idea how this would work in practice though .

spara wrote:

Using custom populator is not really a solution as we will want to take over the system just once.

Assuming you can write the mission such that you know before you enter the system that you want to take it over, then a custom populator should work fine:and then set it back to whatever its previous value was once the player leaves again. In 1.81 property changes are namespaced by OXP, so you don't even have to record what the previous value was - just set it back to null from the same script that set it in the first place, and whatever was there before will take effect.

Even if you only know it's definitely this one when shipWillEnterWitchspace is being called for the initial jump into the system, that's still early enough to make the change.

(Note: in 1.81 there's a possibility that another OXP will have also overridden the system populator and done so at a equal or higher layer than your OXP, so you may want to do a set followed by an immediate get - if that doesn't give the expected result, another OXP has already claimed the system for now, and you'll have to wait until it gives it back)

Cool. I was just blindly staring at planetinfo.plist and forgot all about infoForSystem. I'll obviously need to dig deeper. Wish I had more time.

A question about the populator. If I send allShipsAway, I assume that the populator will start repopulating the system by launching ships from stations and witchspacing in. I'm thinking about system with stations in place, but no ships launching or coming in. Should I just remove ships when they spawn or is there a nicer way of doing this?

And a quick addition here for those who are interested... I quickly tested using an empty populator and the system really is quite empty. There's the star and the planet. Then there's the main station (obligatory I suppose), but no buoy. In a while the main station starts to launch patrol ships so there's some traffic. Interesting. Looks like I'm in business here .

spara wrote:

Should I just remove ships when they spawn or is there a nicer way of doing this?

Override repopulator as well as populator.

Defining custom populator to ordinary systems works fine, but how about interstellar space? I assume this does not work because there is no permanent SystemInfo object for interstellar space: What would work?

At the moment? Setting the populator in planetinfo.plist, unfortunately. If two mission OXPs require different population for the same bit of interstellar space, that's pretty bad luck... (one reason that code doesn't work is that -1 is the value of system ID while in interstellar space, but it is not the system ID of interstellar space)

It might be possible to do something with this, but it's not straightforward, and the systeminfo while you're actually there has to remain read-only.

cim wrote:

At the moment? Setting the populator in planetinfo.plist, unfortunately. If two mission OXPs require different population for the same bit of interstellar space, that's pretty bad luck... (one reason that code doesn't work is that -1 is the value of system ID while in interstellar space, but it is not the system ID of interstellar space)

It might be possible to do something with this, but it's not straightforward, and the systeminfo while you're actually there has to remain read-only.

Ok. Old skool methods then. How about repopulator in witchspace? I assume that it can't be overridden either. Does it just keep on running, possibly spawning new things?