Scripters cove

[Rese249er]

'Lo all. Decided to try my hand at reworking (ripping off) Okti's AutoSkim OXP by taking his autopilot concept and replacing the autoskimmer AI with an escort AI. I'm calling it Tagalong for now.

Problem is, I placed it in my Addons folder, and it won't show up on the equipment purchase screen. My brains are slag by now, having no previous experience with coding or scripting of any kind. Help!

Here's a link to what I have so far. Not even sure it deserves 0.1 as a version number.
https://www.box.com/s/b17d957a0bf81842db5e

[Wildeblood]

(
(
1, 100, "Auto Sun Skimmer",
"EQ_TAGALONG",
"A computer to autopilot falling into any formation.",
{
available_to_all = true;
"portable_between_ships" = 1;
"script" = "TagalongEq.js";
}
), <---- lose this comma
)

[Rese249er]

Done. Now to see if it'll work...

Well, I managed to make it show up, but now it's not autopiloting... Time to rack my brains again. Advice?

EDIT: OK, I need Javascript crash course. Anybody point me to a good link?

[JD]

Hi folks, I wonder if someone could help me understand where I'm going wrong with the logic below. I'm trying to establish a point on the sun's rim, as seen from the player's point of view. For now, any point will do, as long as it's at the rim.

I've already succeeded in doing this using some very convoluted 3d geometry, while largely avoiding using quaternions and vector functions, but I'd really like to do it more efficiently and economically, hence my faltering attempts with quaternions etc below.

Just recently, from a comment in another thread, I got the impression that Oolite's suns are actually rendered as flat discs, always facing the player. If that's correct, it should simplify the calculation a little. So for now, I'm assuming a flat disc.

My logic is:

1. Establish a vector representing the direction from player to centre of sun.
2. Establish a vector that is perpendicular to that.
3. Extend the perpendicular, from the sun's centre, for a distance of the sun's radius.
4. Bob's your uncle.

This is a snippet of code. I've chopped extraneous stuff out, so apologies if, in the process, I've removed something I should have left in for it all to make sense:

Code: Select all

// Direction vector from player to sun's centre
var vSunDirection = new Vector3D(player.ship.position.direction(system.sun));

// Need to rotate the player-sun direction by 90 degrees about the x axis to point to the rim as seen by player
//var qRotationToRim = new Quaternion(0, 1, 0, 0);	// also tried this quaternion, similar results
var qRotationToRim = new Quaternion(1, 1, 0, 0);
qRotationToRim = qRotationToRim.normalize();

// Obtain a perpendicular to the player-sun vector
var vSunPerpendicular = new Vector3D(vSunDirection.rotateBy(qRotationToRim));

// Extend from sun's centre, along the perpendicular, for a distance of sun's radius
var vPointOnRim = new Vector3D(system.sun.position.add(vSunPerpendicular.multiply(system.sun.radius) ) );

log("Test", "Sun radius : " + system.sun.radius);
log("Test", "Sun centre to flare : " + system.sun.position.distanceTo(vPointOnRim) );

The outcome is a point that is the correct distance from the sun's centre (ie it is one radius from the centre), but the line of sight places it in varying positions inside the sun's circumference.

I think step 2 (the perpendicular) is where it goes wrong, and it occurs to me this might be a similar problem to the one Wildeblood & Commander McLane were having earlier in this thread, in which a rotation is applied relative to the system, and not in this case relative to my vSunDirection vector. The key question is how do I establish a perpendicular to the vector?

Thanks in anticipation.

[Eric Walch]

The key question is how do I establish a perpendicular to the vector?

the cross product is your answer.

Code: Select all

myPerpendicularVector = player.ship.position.subtract(system.sun.position).direction().cross([1,0,0]).multiply(system.sun.radius)

cross() gives a vector that is perpendicular to two other normalised vectors. And as you have no particular point on the rim in mind, I now used the unit vector as a second vector.

Your calculation of the initial vector is wrong. You must use a subtraction of two positions. direction() is only for normalising a vector.

And when you want a point on the rim, you must add the suns position to above vector:

Code: Select all

myRimPosition = player.ship.position.subtract(system.sun.position).direction().cross([1,0,0]).multiply(system.sun.radius).add(system.sun.position)

[JD]

Thanks very much Eric. And phew, I don't think I'd have arrived at this method anytime soon. I'll give it a shot tomorrow.

[Edit] <Tomorrow> And having given it a shot, all I can say is thanks again Eric, that's absolutely cosmic. Has anyone noticed Eric's a bit of a genius?

[CommonSenseOTB]

Thanks very much Eric. And phew, I don't think I'd have arrived at this method anytime soon. I'll give it a shot tomorrow.

[Edit] <Tomorrow> And having given it a shot, all I can say is thanks again Eric, that's absolutely cosmic. Has anyone noticed Eric's a bit of a genius?

Yeah.

[Lone_Wolf]

The discussion about global namespace
meant that CCL was updated, and that in turns meant i had to update shieldcycler.
A comment (and a pm) from Commander McLane made me look back at older shieldcycler versions.

Before version 0.21.2 i used this.sc_foo for storing/changing values, but found they somehow didn't stick.
It looked like there were multiple instances of those values instead of just 1.
In 0.21.2 & 0.21.3 i tried to solve this by using global variables that were stored in global namespace.
This however didn't solve all problems, so i looked deeper.

Reading up on scope and JS calling context, i realised that when a function was called the caller determined whether a new context was created or an existing one was used.
Looking into oolite code, it appeared that there were different contexts created for :
equipment script events, ship script events and worldscript events.

Even though the handlers for these events were all in the same script, they didn't share the same context.

I found that calling a function as a method is the easiest way to ensure what the execution context will be at runtime.
In ShieldCycler 0.30.1 i created dummy event handlers like this in a separate script :

Code: Select all

this.activated = function()
  {
    worldScripts["Shield Cycler"].sc_activated();
  };

This effectively means all event handlers shieldcycler uses are now worldscript events and share the same context, thus solving the problems.


The reason i encountered these problems is likely the mix of equipment, shipscript and worldscript events shieldcycler needs to do its job.

I posted this here hoping my findings will be useful for other coders.

[Capt. Murphy]

Could something suitable be added to 1.77 please, for both materials and shaders? Presumably to dump out a dictionary of current settings, similar to what you'd feed back with setShaders/setMaterials if you wanted to apply them again?

See https://bb.oolite.space/viewtopic.ph ... 85#p175585

[Wildeblood]

Once you've set a star to nova, is there a way to "un-nova" it again by script, or can it only be restored by editing the save file?

[cim]

Once you've set a star to nova, is there a way to "un-nova" it again by script, or can it only be restored by editing the save file?

Yes.

Code: Select all

System.infoForSystem(galaxy,sysid).sun_gone_nova = 0;

[Commander McLane]

I would've thought, though, that a Nova is a permanent thing. Thus I can see no easy in-game reason why it should ever be reverted. (Except time travel, which isn't possible, I think.)

[Fatleaf]

I would've thought, though, that a Nova is a permanent thing. Thus I can see no easy in-game reason why it should ever be reverted. (Except time travel, which isn't possible, I think.)

For the native mission I would never change, but an oxp induced nova in my opinion is free game to change. Assassins Guild blows up a star. I have a little wip in G7 that was geting me thinking as to have work arounds if mission critical system was the nova system. With this bit of code I now have a few options.

[Cody]

I believe a star can go nova multiple times, and fade-back in between. It's supernovae that destroy themselves.

Disclaimer: I am not a cosmologist

[cim]

I would've thought, though, that a Nova is a permanent thing. Thus I can see no easy in-game reason why it should ever be reverted. (Except time travel, which isn't possible, I think.)

I think if OXPs are to be given the ability to cause novas - and it's too late to change that now - they also need to be able to be given the ability to declare a nova temporary (and probably revert it immediately the player exits the system) so that they don't cause incompatibilities with other mission OXPs set in the same galaxy.

(Didn't some variants of the original Elite nova mission target a specific planet with it, rather than just a random G4 one, or am I misremembering something I read there?)