How does BEHAVIOUR_FIXED_COORDINATES works

[Wildeblood]

Time to bump this old topic.

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. So...

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?

Is it reset by making a galactic jump? If planetinfo.plist specifies BEHAVIOUR_STANDARD, but galacticHyperspaceBehaviour is altered by script to BEHAVIOUR_FIXED_COORDINATES before making a jump, does it revert to BEHAVIOUR_STANDARD after the jump?

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

[Switeck]

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.

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.

I updated Quantum Drive System v0.2:
http://www.mediafire.com/?zwx6ge6dxxxcbyv

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?

player.ship.galacticHyperspaceBehaviour does not seem to be saved in the save-file.

Is it reset by making a galactic jump?

After 1 Galactic jump, it (seems to...) reverts back to player.ship.galacticHyperspaceBehaviour = "BEHAVIOUR_STANDARD";
...But I don't know what it'll do if planetinfo.plist specifies something other than "BEHAVIOUR_STANDARD".

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

Quantum Drive System v0.2 reports its X, Y Light-Year coordinates target in selected destination mode...although what those numbers mean may only be apparent through trial-and-error.

[Wildeblood]

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.

Thanks. My "Sensible GalDrive", which I've had for a while, looks suspiciously similar to your Quantum Drive System, although it contains no copy/paste. There are only so many ways to make a three item menu. I've just updated it to deal with the resets on start-up and after a jump, discussed above, and it's more-or-less finished now.

But, although it allows me to select BEHAVIOUR_FIXED_COORDINATES, it contains no means to actually set co-ordinates. I want the GalDrive Programmer (which is so far 100% vapour) to be separate so that it may be used independently, as most people will not like my take on how the GalDrive should be implemented.

[another_commander]

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

The coordinates are set using "galactic_hyperspace_fixed_coords" = "X Y"; in planetinfo.plist, where X and Y are the coordinates you want to set. Without this key, it defaults to coordinates "96 96", which is close to center of the galaxy.

[Switeck]

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.

[Commander McLane]

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.

Yes, you were mistaken, it never reverted. That's why I wrote earlier that any script changing the behaviour has to take care of that itself. It's only one additional line in playerEnteredNewGalaxy. So the complete code should look like this:

Code: Select all

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
}

[Switeck]

I don't see how that code catches the edge case of another OXP trying to modify player.ship.galacticHyperspaceBehaviour in its own this.playerEnteredNewGalaxy = function(galaxyNumber) section. As far as I can tell...sometimes it might run after your code, other times before. In short, a race condition.

It would probably be easier if player.ship.galacticHyperspaceBehaviour was automatically reset to "default" (whatever that might be) during each galactic jump, just to avoid 1 OXP trying to change to new Gal.jump behavior while another OXP tries to "fix" it back to what it was before.

[Kaks]

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

Switeck, even if we modify Oolite as you suggest, if 3 scripts try to temporarily modify the galactic jump behaviour at the same time - but only during .shipWillEnterWitchspace, it's still anyone's guess which one will actually be used...
It's likely that oxp writers agreeing on which OXP should take the precedence in case of conflict is the most effective way to try and resolve this particular issue.

[Switeck]

Barring that mediocre-at-best idea of mine, I was kinda hoping you were going to tell me a way for 1 script to consistently have higher priority than others and go first.

Gal.Hyp.Beh. = player.ship.galacticHyperspaceBehaviour

Yet more crazy ideas:

What I did for my Quantum Drive System OXP in its activation section (the only subroutine it has) was first report the existing Gal.Hyp.Beh. then set a mission variable based on that, then change both based on the current value. That takes effect immediately, but will/should get overridden/ignored by any script that changes Gal.Hyp.Beh. later.

Low priority equipment could change Gal.Hyp.Beh. at the moment the equipment is installed. A problem with doing that is reloading from a savegame probably resets Gal.Hyp.Beh. If the equipment is damaged or removed, I feel it's debatable whether the Gal.Hyp.Beh. state should be changed back at that moment -- either the equipment is needed to keep Gal.Hyp.Beh. changed or it already changed Gal.Hyp.Beh. and now something else is needed to set it back.

Medium priority equipment could change Gal.Hyp.Beh. using this.playerStartedJumpCountdown = function(cause) -- thus overriding low priority change.

The high/highest priority change to Gal.Hyp.Beh. almost has to be done in this.shipWillEnterWitchspace = function(cause) ...kind-of like a bar's last call for alcohol!

[Okti]

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

Useally the first one wins in real life, but as far as JS is concerned, the last one wins.

[Kaks]

@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!

@Okti: yep!

[Svengali]

@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!

Me? No - I'm just a n00b

But I'd think a set of mVs could avoid a lot of clashes between OXPs. And mVs are (at least currently) the only way to control the populator as well via conditions in shipdata.plist. This is the reason for the missionVariables.CCL_OXPStrength. For my own OXPs I've tried to reduce the number of mVs drastically as the list of mVs is already pretty long (and accessing gets slower and slower). So stuff which doesn't need to stay in mVs can be deleted after reading in.

- startUp: reading in, storing the values in properties, setting a flag
- playerWillSaveGame: storing properties in mVs, setting a flag
- guiScreenChanged: if flag, delete mVs

guiScreenChanged is fired after saving. And this handler can be created on the fly in playerWillSaveGame if necessary. This way the list can be shortened without frickling around with Timers.

Oh, and OXPConfig works only with/for worldScript properties .-)

[cim]

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.

To expand on the ideas, then, what about a short worldscript with two functions:
this.registerRole(role,variant,priority) {}
and
this.currentVariant(role,variant) {}

So, a galactic hyperspace mod would do in its startUp script when conditions were met
this.registerRole("GALACTIC_HYPERSPACE",this.name,100);
and another one might do
this.registerRole("GALACTIC_HYPERSPACE",this.name,10);

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.

Should an OXP need to have variable priority (for instance, 10 if the equipment is installed, 9999 if not; or a different priority based on OXPConfig variables), it simply calls registerRole again with the new priority. If the OXP itself needs persistent storage to determine priority it can use missionVariables, of course.

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)

Could be useful for planetinfo as well - though that would require more thought. What order planetinfo replacement goes in is going to be messy. Replace-then-append where both run in a particular order is usually correct (GalNavy or Feudal States-style appends should probably be after Famous Planets-style replacement, for instance), but other times replace-only (Nova mission and other OXPs that completely change single system details) is necessary. That would probably require the conflict manager to set up a queue and then pass out callbacks in order (but how does it know when to start processing the queue?)

[Svengali]

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.

Sure - it would require a worldScript which is a dependency for these OXPs. In CCL the mV gets reset to default value on playerWillSaveGame (plus storing it temporary in a property), so it gets reset to the set value on guiScreenChanged after saving. This way even after taking CCL out the default setting is available. The mV is not meant to be set by other OXPs and handled through CCL. The mV and other script properties are reset when the player leaves the system (shipWillEnterWitchspace) and if there's nothing defined for the target system. The same check is done when the player arrives.

But as I've said the missionVariable is only necessary to give OXPs a way to use it in plists too. JS based stuff is probably better done as a script property, but a combination of both ways is pretty flexible and catches most cases. CCL minimizes possible clashes by using a per system based registering and a property that gets checked in the inserting script.

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.

CCL merges the entries if multiple OXPs are registering for a specific system, using the most restrictive values. But this is only one possibility and depends on the mechanism and the goal for this mechanism. A weighting sounds pretty sensible for the jump-behaviour handling, returning true/false in the registering/callback function is tied to the mechanism itself. You can't make it right for everybody - so simply pick your choice and document it .-) One way could be to return true in the registering only if the priority is higher than already inserted values and calling back only for the 'winning' OXP(s). But as I've said it depends... .-)

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)

If such a mechanism gets used then is another question, but thinking about ways to avoid clashes is no waisted time. And offering options for OXPers is a cool thing! It may need time before it gets used, but hey .-)

Looks as if you were to do the job - very cool! Keep on rocking