How does BEHAVIOUR_FIXED_COORDINATES works

[Okti]

What if the behaviour at the time of the jump is not Standard? What if I had it set to Fixed Coordinates? It still needs some work before it's fully fixed.

It only changes the behaviour if it was standard, and changes back to standard. So changing it to anything else won't be affacted.

[another_commander]

Yup, you are right. OK, fine then

[Commander McLane]

What if the behaviour at the time of the jump is not Standard? What if I had it set to Fixed Coordinates? It still needs some work before it's fully fixed.

It only changes the behaviour if it was standard, and changes back to standard. So changing it to anything else won't be affacted.

Not fine. Because this means that the equipment doesn't work at all as advertised if the default happens to be FIXED_COORDINATES. Still a bug, albeit a different one.

The point is that the script cannot count on a specific behaviour being the default. It has to account for all possibilities, because other OXPs could have changed the default.

Have a look into cataclysm.js. There it's done properly. (And I think I mentioned that when the GalDrivePod was in the making.)

Here's the relevant snippets:

Code: Select all

this.shipWillEnterWitchspace = function(cause)
{
	...
	if(cause == "galactic jump") 
	{
		this.checkForGalDriveMod();
	}
	...
}

this.playerEnteredNewGalaxy = function(galaxyNumber) 
{
	this.resetGalHyperspaceBehaviour();
	...
}

this.checkForGalDriveMod = function()
{
	if(player.ship.equipmentStatus("EQ_GAL_DRIVE_MOD") === "EQUIPMENT_OK")
	{
		this.defaultGalacticHyperspaceBehaviour = player.ship.galacticHyperspaceBehaviour;
		player.ship.galacticHyperspaceBehaviour = "BEHAVIOUR_ALL_SYSTEMS_REACHABLE";
	}
}

this.resetGalHyperspaceBehaviour = function() 
{
	if(player.ship.equipmentStatus("EQ_GAL_DRIVE_MOD") === "EQUIPMENT_OK")
	{
		player.ship.removeEquipment("EQ_GAL_DRIVE_MOD");
		player.ship.galacticHyperspaceBehaviour = this.defaultGalacticHyperspaceBehaviour;
	}
}

The behaviour is only switched if a specific one-shot equipment is installed. Immediately after the jump the one-shot equipment is removed and the behaviour is changed back to whatever it was before.

[Okti]

It is Smivs's OXP, I think leaving the decision to him will be better.

[CommonSenseOTB]

Nicely done Commander McLane.

Like campers picking up the trash before they leave, oxp's should put things back THE WAY THEY WERE after they are done.

[Okti]

Not fine. Because this means that the equipment doesn't work at all as advertised if the default happens to be FIXED_COORDINATES. Still a bug, albeit a different one.

Sorry but don't agree with this one Commander McLane, the default for oolite is always STANDART. The other two can only be set by the OXP's, and if an OXP set it to FIXED_COORDINATES, changing that will bugger up the task of that particular OXP. And I don't think it must be overrided by any equipment. But for the time being I haven't come across with an OXP doing that, but there may be others I don't know implementing this behavior. If it is a mission the mission will be halted.

[Commander McLane]

Not fine. Because this means that the equipment doesn't work at all as advertised if the default happens to be FIXED_COORDINATES. Still a bug, albeit a different one.

Sorry but don't agree with this one Commander McLane, the default for oolite is always STANDART. The other two can only be set by the OXP's, and if an OXP set it to FIXED_COORDINATES, changing that will bugger up the task of that particular OXP.

What do you mean by "task"? Why do you assume that OXPs would only set a hyperspace behaviour as part of a task? I hope you are aware that galactic_hyperspace_behaviour is a planetinfo.plist key that can be used to set a different default than BEHAVIOUR_STANDARD. Therefore no OXP can rely on the assumption that BEHAVIOUR_STANDARD is in fact the default behaviour for every player. Chances are that it isn't. And that doesn't even account for the possibility that a buggy script can set yet another default, like in the case of GalDrivePod.

The possibility to change the behaviour on the fly in JS was implemented precisely to enable scripters to temporarily override the default, whatever the default for any given player would be. And indeed, here you're right, this temporary override will mostly be caused by the need to promote a mission. If my mission requires the player to reach an unreachable system, my script has to set BEHAVIOUR_ALL_SYSTEMS_REACHABLE for one specific jump, thereby overriding whichever default the player has. And after this one specific jump is done the script should restore the default behaviour. In Cataclysm I make that part of the storyline by tying the BEHAVIOUR_ALL_SYSTEMS_REACHABLE to a certain piece of equipment. Other front-end options are possible. But the point is that a mission may call for a specific behaviour at a specific point of its storyline, and the JS method allows the script to achieve this behaviour without screwing with the player's general setup for all other jumps.

[Okti]

What do you mean by "task"? Why do you assume that OXPs would only set a hyperspace behaviour as part of a task? I hope you are aware that galactic_hyperspace_behaviour is a planetinfo.plist key that can be used to set a different default than BEHAVIOUR_STANDARD. Therefore no OXP can rely on the assumption that BEHAVIOUR_STANDARD is in fact the default behaviour for every player. Chances are that it isn't. And that doesn't even account for the possibility that a buggy script can set yet another default, like in the case of GalDrivePod.

I tried to help to correct that buggy code without causing other clashes with other OXP's. The task is a mission stage as far as I meant. And I think FIXED_COORDINATES was only provided to make an oofic story can be scripted. Gal Jumping from somewhere in G7 and end up in Oresrati. Regarding your equipment in your OXP, shall it be available to everyone after that stage is completed?. Maybe Yes maybe not, you may have a think about it when you upgrade your mission to 1.75.

[another_commander]

And I think FIXED_COORDINATES was only provided to make an oofic story can be scripted. Gal Jumping from somewhere in G7 and end up in Oresrati.

The reason for the existence of FIXED_COORDINATES is mainly to simulate some of the older Elite 8-bit versions. This way, those who prefer the way it was done back in the old days can still have it. The story scripting part is a very welcome side effect.

[Okti]

The reason for the existence of FIXED_COORDINATES is mainly to simulate some of the older Elite 8-bit versions. This way, those who prefer the way it was done back in the old days can still have it. The story scripting part is a very welcome side effect.

Thanks for the information another_commader.

[Switeck]

The possibility to change the behaviour on the fly in JS was implemented precisely to enable scripters to temporarily override the default, whatever the default for any given player would be. And indeed, here you're right, this temporary override will mostly be caused by the need to promote a mission. If my mission requires the player to reach an unreachable system, my script has to set BEHAVIOUR_ALL_SYSTEMS_REACHABLE for one specific jump, thereby overriding whichever default the player has. And after this one specific jump is done the script should restore the default behaviour.

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

Here's my little Galactic Hyperdrive hack OXP:
Quantum Drive v0.1.oxp.zip
http://www.mediafire.com/?9mv2h1ht92h7v59

[Cody]

Here's my little Galactic Hyperdrive hack OXP:
Quantum Drive v0.1.oxp.zip
http://www.mediafire.com/?9mv2h1ht92h7v59

Neat little tool, Switeck... cheers.

[CommonSenseOTB]

Here's my little Galactic Hyperdrive hack OXP:
Quantum Drive v0.1.oxp.zip
http://www.mediafire.com/?9mv2h1ht92h7v59

Neat little tool, Switeck... cheers.

Yeah very cool. And mediafire wasn't to bad. Quick, no pop-ups in my face. For the love of all that is holy, thankyou! Thankyou for using mediafire.

[Switeck]

It's unpolished and is more like Hackers' equipment (from Anarchies OXP) than whatever the Galactic Navy uses to get around fast.
It may stomp all over any mission/campaign OXPs that expect specific galactic jump behavior, but at least it reports what mode it's changing to...which hints what the mode was before.

We'll seriously have to consider (and then do) something like Okti talks about here:
https://bb.oolite.space/viewtopic.php?f=4&t=9672
...to avoid Galactic Hyperdrive behavior conflicts and even misjump conflicts.

A big problem is knowing what the author's intent is and whether partially or totally suspending an OXP'S functionality (its .js file/s) is really the best solution.

Even the priority/probability/odds numbers on roles can really be a monkey-wrench to the game. An OXP might make a ship with pirate(9), pretty much reducing to infinitesimal obscurity another ship that uses pirate(0.05) or lower.

[Smivs]

Just to put the record straight, I do not believe there is a problem with the GalDrivePod OXP. It is (and was also before the recent update) working exactly as intended. The GDP simply allows a ship to jump (using a standard galactic drive) to un-reachable systems if that ship has a GDP on board. The GDP can then be used to leave the un-reachable system, and as soon as the GDP is deployed, the galactic behaviour reverts to "BEHAVIOUR_STANDARD" provided another OXP is not also affecting galactic behaviour.
It always did this even before the update, and this was tested very carefully before release. The update has just made what happened anyway a bit more pro-active.
I can't comment on other OXPs which change galactic behaviour, other than to point out that they could also have unexpected affects on the way GDPs work, and that if a player uses OXPs which affect galactic behaviour, they should be aware that there may be unexpected and unpredictable conflicts/interactions between them.
Obviously if a proper fix for this becomes available I will happily update GDP again, but GDP is not broken/buggy and is working properly and as intended.