Oolite Bulletins

Posted: **Thu Dec 08, 2011 10:42 pm**

It depends a little on the desired nature and look of things as collision detection will get in the way if the parts are too close together. Similarly they would appear as separate targets to the player for ident or missile lock (unless given a mil scanner jammer to stop that) and separately on the scanner (again unless shipdata'd otherwise to be scanner-invisible).

Something similar could be done with the player ship, although it could get in the way of docking as well.

But it would need to be done with a frame callback or else things would look very odd and jerky.

Posted: **Fri Dec 09, 2011 12:36 am**

Thargoid wrote:
It depends a little on the desired nature and look of things as collision detection will get in the way if the parts are too close together.

The idea was to use it on:

- turreted freighters, simply divided between top and bottom to target two enemies at a time (plus the player's own target, which if empty could default back to the first enemy that hits either side of the ship),

- Borg cubes composed by 5^3 to 10^3 (5^3=125, 6^3=216, 8^3=512 ,10^3=1000) fixed but independent frangible armed entities (with some fancy programming so the inner entities won't try to shoot trough the outer ones before they are exposed).

- larger ships, such as a [wiki]Long Range Cruiser (Oolite)[/wiki], could be split like a centipede in 3 or four sections along its length wrapped around the flying entity (the one controlling the engine and main weapons), each subdivided in top, bottom, port and starboard sections - 12 or more independent fire control centres can make much sense on a ship so large.

Thargoid wrote:
Similarly they would appear as separate targets to the player for ident or missile lock (unless given a mil scanner jammer to stop that)

Actually I think it could be even more fun that way... to be able of picking off a large NPC bit by bit, while what's left still poses great danger, or if in a player ship, it can contribute immensely to immersion:

"Brace for impact!"
BOOOM
"Damage report!"
"Sir, we lost section seven and the turrets 6-3 thru 8-1! Damage control and medical aid parties are on their way, but are having trouble going around the debris."
"Sir, Shielding on sector 8 is now failing. Sir, sector 8 is taking damage."
"Helm, emergency roll to 150."
"Aye-aye, Sir, rolling 1-5-0 degrees; Sir, 1-5-0 my helm is on full burst clockwise."
"Tactical, give me a firing solution to that destroyer up ahead."
"Sir, sectors 4 and 6 are under attack but their shields are holding... also sector 12, Sir:"
"Sir, the plasma accelerator is fully charged and ready to fire, main armament trigger failsafes active; Sir, please validate the firing order."

Sounds like fun!!!
Such a player ship should necessarily have at least a couple of cinematic POVs to catch itself on action screenshots.

Thargoid wrote:
and separately on the scanner (again unless shipdata'd otherwise to be scanner-invisible).

Ideally, only the main element should appear - but if the complete set's size warranted it, it should rather appear as a blob.

Thargoid wrote:
Something similar could be done with the player ship, although it could get in the way of docking as well. But it would need to be done with a frame callback or else things would look very odd and jerky.

Yay, it can be done... or so I thought, and then you lost me on "frame callback". In any case, the (original) concept isn't to use it on fast moving and turning ships, but on things Python-sized or bigger.

Posted: **Fri Dec 09, 2011 3:55 am**

Quick question: Can you change the main station's orbital altitude via script? If so, how?

Posted: **Fri Dec 09, 2011 5:22 am**

Ryan - the answer is yes as you can change the position of any entity via script.

e.g. this will move the main station when it is spawned 500 metres closer to the planet

Code: Select all

this.shipSpawned = function(spawnedship)
{
if (spawnedShip.isMainStation)
{
var newPosition = spawnedShip.position.add(spawnedShip.vectorForward.multiply(500));
spawnedShip.position = newPosition;
}
}

to move it away from the planet.

Code: Select all

var newPosition = spawnedShip.position.subtract(spawnedShip.vectorForward.multiply(500));

Edit to add - don't forget to move the navigation bouy as well.

Posted: **Fri Dec 09, 2011 6:36 am**

Cmdr. Maegil wrote:
Yay, it can be done... or so I thought, and then you lost me on "frame callback". In any case, the (original) concept isn't to use it on fast moving and turning ships, but on things Python-sized or bigger.

I'll comment on most of it, but just quote the above bit to save space. Frame callback is the new(ish) method of doing actions on every frame displayed by the game. You'd need to do that to keep everything synchronised and in their correct positions. If you just did it by a script/timer set-up, you'd get a maximum firing of once every 0.25s (ie 4FPS). Visually it would be jerky as the entities moved (or didn't) at your normal game frame-rate but then every 0.25s things got moved around into their correct place.

By using the callback you can shift the position of all the sub-bits once per frame (ie 40FPS, or whatever rate your machine achieves) and everything will move smoothly. But it's a little more complicated to script.

As I said the biggest thing to get around will be the entity collision detection. If things get too close they will crash together, lose energy and to the extreme explode. That may limit how tightly you can keep all the bits together, hence the overall look of the thing.

But the general concept is fairly sound, but the devil will be in the detail.

Posted: **Fri Dec 09, 2011 8:04 am**

So it's really not something the likes of me can do on the back yard with a plasma cutter and a welding torch...
Anyway, thanks for the info.

Posted: **Fri Dec 09, 2011 1:52 pm**

Capt. Murphy wrote:
Ryan - the answer is yes as you can change the position of any entity via script.

e.g. this will move the main station when it is spawned 500 metres closer to the planet
Code: Select all
this.shipSpawned(spawnedShip)
{
if (spawnedShip.isMainStation)
{
var newPosition = spawnedShip.position.add(spawnedShip.vectorForward.multiply(500));
spawnedShip.position = newPosition;
}
}
to move it away from the planet.
Code: Select all
var newPosition = spawnedShip.position.subtract(spawnedShip.vectorForward.multiply(500));

Thanks. In my Ooniverse, I'd prefer a higher orbit for those stations.

Capt. Murphy wrote:
Edit to add - don't forget to move the navigation bouy as well.

Thanks for reminding me... this gives me so many funny ideas...

Posted: **Fri Dec 09, 2011 4:16 pm**

Cmdr. Maegil wrote:
So it's really not something the likes of me can do on the back yard with a plasma cutter and a welding torch...
Anyway, thanks for the info.

Have a look at the inner workings of Stellar Serpents OXP.

The head of the serpent is the "master" entity, but all of the body segments and the tail are each individual and distinct entities. It's just that they are not armed in any way, unlike in your thought. But the general concept is the same as what you are thinking of - a master entity with other ones being moved around and oriented in a suitable fashion to make the whole thing appear as a single entity.

Posted: **Tue Dec 13, 2011 8:59 pm**

Dear all

I've got a (very, very large) ship defined as a carrier. It launches defense ships (under certain conditions). But these ships do not, even after they've received a 'launched okay' message, intercept or attack when I - a script - tells them to. I've verified that (1) the script is actually running, (2) the defence ships in question have targets defined, (3) those ships are in the right AI state. And yet they just fly in a straight line forever (unless they get attacked). So I'm stumped. I've found existing stuff on the boards that looks a bit similar . .

Can anyone help, please?

Posted: **Tue Dec 13, 2011 9:35 pm**

I think the best route there would be to upload a beta somewhere to let people have a look. It's a little too complex a question I think to do via posts here.

Posted: **Tue Dec 13, 2011 11:59 pm**

Dear Thargoid

Thanks. Actually, though, I've fixed it. I was summoning up one of my own derelicts, instead of a live ship. But the ship still got animated by the carrier when it was launched - until it has 'launched okay', at which point it just kept its trajectory. The confusion had something - I don't fully understand it, though I've fixed it - to do with roles. Anyway, thanks again!

Posted: **Wed Dec 14, 2011 6:06 am**

Have recently discovered the array.forEach method for iterating across an array I thought I do some profiling to compare it's performance against a standard for loop doing the same job. I was quite surprised to find that array.forEach seems to have a significantly higher JS overhead than a standard for loop. Any thoughts?

The code I profiled was:

Code: Select all

this.forwardforloop = function()
{
 var counter = 0;
 this.arrayOfSystemNames = new Array;
 for (counter = 0; counter < this.arrayOfSystemID.length;counter++)
 {
  this.arrayOfSystemNames.push(System.systemNameForID(this.arrayOfSystemID[counter]))
 }
}

and

Code: Select all

this.forEachloop = function()
{
 this.arrayOfSystemNames = this.arrayOfSystemID.forEach(function (systemID){ return System.systemNameForID(systemID)},this);
}

where this.arrayOfSystemID is an array of the numbers 0 through to 255.

In both cases the vast majority of the overhead is the native functions, but the JS overhead for this.forEachloop() is several time slower than this.forwardforloop.

:time worldScripts["Array_Iteration_Profiling"].forwardforloop()
> console.profile(eval("(function codeToBeProfiled() { (" + "worldScripts[\"Array_Iteration_Profiling\"].forwardforloop()" + ") })"), this)
Total time: 571.113 ms
JavaScript: 4.384 ms, native: 566.716 ms
Counted towards limit: 567.311 ms, excluded: 3.8018 ms
Profiler overhead: 3.897 ms
NAME T COUNT TOTAL SELF TOTAL% SELF% SELFMAX
-[Universe generateSystemData:useCache:] N 256 560.27 560.27 98.1 98.1 9.88
SystemStaticSystemNameForID N 256 566.56 5.19 99.2 0.9 0.13
(../AddOns/Array_Iteration_Profiling.oxp/Config/script.js:19) <anonymous> J 1 570.86 4.30 100.0 0.8 4.30
-[NSString(OOJavaScriptExtensions) oo:jsValueInContext:] N 256 1.10 1.10 0.2 0.2 0.01
WorldScriptsGetProperty N 1 0.16 0.15 0.0 0.0 0.15
(<console input>) codeToBeProfiled J 1 571.10 0.09 100.0 0.0 0.09
OOStringFromJSString N 1 0.01 0.01 0.0 0.0 0.01

:time worldScripts["Array_Iteration_Profiling"].forEachloop()
> console.profile(eval("(function codeToBeProfiled() { (" + "worldScripts[\"Array_Iteration_Profiling\"].forEachloop()" + ") })"), this)
Total time: 585.927 ms
JavaScript: 14.21 ms, native: 571.703 ms
Counted towards limit: 582.617 ms, excluded: 3.30982 ms
Profiler overhead: 7.757 ms
NAME T COUNT TOTAL SELF TOTAL% SELF% SELFMAX
-[Universe generateSystemData:useCache:] N 256 565.16 565.16 96.5 96.5 9.76
(../AddOns/Array_Iteration_Profiling.oxp/Config/script.js:61) <anonymous> J 512 1161.73 11.43 198.3 2.0 2.23
SystemStaticSystemNameForID N 256 571.53 5.24 97.5 0.9 0.13
(../AddOns/Array_Iteration_Profiling.oxp/Config/script.js:61) <anonymous> J 1 585.66 2.70 100.0 0.5 2.70
-[NSString(OOJavaScriptExtensions) oo:jsValueInContext:] N 256 1.13 1.13 0.2 0.2 0.02
WorldScriptsGetProperty N 1 0.17 0.17 0.0 0.0 0.17
(<console input>) codeToBeProfiled J 1 585.91 0.08 100.0 0.0 0.08
OOStringFromJSString N 1 0.01 0.01 0.0 0.0 0.01

Edit to add - a reverse for loop appears to have the least JS overhead.

Code: Select all

this.reversedforloop = function()
{
 var counter;
 this.arrayOfSystemNames = new Array;
 for (counter = this.arrayOfSystemID.length - 1; counter >= 0;counter--)
 {
  this.arrayOfSystemNames.push(System.systemNameForID(this.arrayOfSystemID[counter]))
 }
}

Posted: **Wed Dec 14, 2011 7:07 am**

Capt. Murphy, are you using a debug build for your tests? Note that JS in debug is significantly slower than in release mode.

Posted: **Wed Dec 14, 2011 7:13 am**

Nope it's a standard nightly type build. A bit of googling suggests that forEach is known to be a slower method for array iteration.

Posted: **Wed Dec 14, 2011 8:31 am**

Capt. Murphy wrote:
A bit of googling suggests that forEach is known to be a slower method for array iteration.

One other JS construction that is relative slow is the 'yield' operator. That also allows similar actions on an array. Kaks used it in the Kestrel&Falcon.oxp. In the previous JS version that very often gave time-outs on my computer when using debug builds. The current JS version is much faster but I think that it still will be a slow method.

Oolite Bulletins

Scripters cove

Re: Scripters cove

Re: Scripters cove

Re: Scripters cove

Re: Scripters cove

Re: Scripters cove

Re: Scripters cove

Re: Scripters cove

Re: Scripters cove

Re: Scripters cove - Can't get ship to perform actions

Re: Scripters cove

Re: Scripters cove

Re: Scripters cove

Re: Scripters cove

Re: Scripters cove

Re: Scripters cove