Oolite Bulletins

Wildeblood wrote:

I want to write a "programmer" for the GalDrive when it is in BEHAVIOUR_FIXED_COORDINATES mode, essentially a menu of interesting destination systems in each galaxy/sector. It should have "explorer" and "military" modes. In the former would be listed the "lost worlds", in the latter the Navy Secom systems.

Wildeblood wrote:

Is the current state of galacticHyperspaceBehaviour normally stored in the save-file, or will it have to be stored in a mission variable and reloaded with a startUp function?

Wildeblood wrote:

Is it reset by making a galactic jump?

Wildeblood wrote:

How do I find out the co-ordinates of a system anyway?

Switeck wrote:

Programming in a list of destinations to significant systems for the next jump could be done with a mission menu and/or very long CASE sections in your code. Adding that to Quantum Drive System might be easier than starting from scratch, so go ahead and use that if you want.

Wildeblood wrote:

But, although it allows me to select BEHAVIOUR_FIXED_COORDINATES, it contains no means to actually set co-ordinates.

Switeck wrote:

Changing player.ship.galacticHyperspaceBehaviour is indeed temporary! After 1 Galactic jump, it (seems to...) reverts back to player.ship.galacticHyperspaceBehaviour = "BEHAVIOUR_STANDARD";

Switeck wrote:

Switeck wrote:

Changing player.ship.galacticHyperspaceBehaviour is indeed temporary! After 1 Galactic jump, it (seems to...) reverts back to player.ship.galacticHyperspaceBehaviour = "BEHAVIOUR_STANDARD";

I was mistaken, or at least this is not the case with Oolite v1.76...player.ship.galacticHyperspaceBehaviour stays changed even after a Galactic jump.

this.shipWillEnterWitchspace = function(cause)
{
    if(cause === "galactic jump") 
    {
        this.defaultGalacticHyperspaceBehaviour = player.ship.galacticHyperspaceBehaviour; // store the player's current default
        player.ship.galacticHyperspaceBehaviour = "YOUR_DESIRED_BEHAVIOUR"; // <- specify your desired one time behaviour here
    }
}

this.playerEnteredNewGalaxy = function(galaxyNumber) 
{
    player.ship.galacticHyperspaceBehaviour = this.defaultGalacticHyperspaceBehaviour; // restore the player's default
}

Kaks wrote:

No matter where it happens, the race condition is always going to be present...

Kaks wrote:

@Switeck: Well, you could always 'register' a new special variable via oxp config: something like missionVariables.galControl perhaps...

Then all an OXP would have to do is see if they're registered before making any adjustment( along the lines of if(missionVariables.galControl == this.name) { etc, etc... } )

But this is a very simplistic example, Svengali can definitely come up with something much better than that!

cim wrote:

A slight problem I can see with using missionVariables directly is that they persist over save-reload but the OXP list doesn't. So unless you were careful you could end up with a situation where OXP B overrides OXP A (by agreement of both authors) if both are installed - install OXP A and it works, install OXP B and it overrides, play for a bit, uninstall OXP B, and OXP A doesn't start working again.

cim wrote:

this.currentVariant() would then return true if that was the lowest priority variant for that role, and false otherwise. Not sure whether it's best to handle ties by returning true for both OXPs, or false for both OXPs, or having registerRole return false.

cim wrote:

The big difficulty regardless of framework is getting all OXP authors in a particular field to use the same role name and agree a common set of priority numbers, especially for older OXPs from missing authors (I suppose we could provide a list of pre-framework worldscripts that are considered to have top priority)