Scripting requests

[Arexack_Heretic]

Are all entity-properties still read-only (as documented in the wiki) or can they already be changed in 1.69.1 JS?
(I know you said they would probably all be accesible in 1.7, how is that progressing?)

“Accessible” does not mean “editable”. And I don’t think I said “all”.

yes you did actually. discussion-progress:

PostPosted: Fri Jun 08, 2007 1:12 pm
Currently not all of them, but there will probably be a way to access them all in 1.70.

:p

[JensAyton]

OK. Context:

Besides accessing their values for shader-purposes,

all these states and conditions of the entity-object can be changed by JSmethods?

I was referring specifically to the Entity.call() method, which is similar to the way shader bindings work. However, call() and shader bindings have different data type constraints, so the “all” bit is wrong, at least for 1.70. Extending call() to cover all the types that can be used in shader bindings is probably a reasonable goal for 1.71.

I certainly never intended for all properties to be editable from JavaScript (the headaches that would cause would be immense), so I must have misread at the time.

[Arexack_Heretic]

I already get headaches

Getting to understand JS is proving harder than anticipated,
for one thing all online refernces insist on doing things web-browser related,
secondly my undefined-ness in what is implemented in 1.69 and what is in the works,
thirdly there seem to be many ways to write the syntax.
fourthly I'm a fool.

Got a embryonic understanding of how things are working now though.
I kept trying to nest conditions like we do in plist scripts, the way of JS however seems to be '//do stuff' , which means generally a single condition_statement and call another function. (repeat).

-----------

about the example code you posted earlier today/lastnight
edit: just saw you doing it again in the 'J&B-coffeecorner'.

You are using the 'let' command again to initiate variables, will you upgrade to JS v1.7 in Oolite v1.70 then?

[nijineko]

well, i'm specifically reference the effect i mentioned elsewhere about being inside a convenience store near the witchpoint in close proximity to a cascade mine blowing me out of the store and out of the system in short order. even jumping to another system fails to reduce my speed. help!

[Arexack_Heretic]

keep jumping untill your vector lines up with a planet or sun.

should you miraculously be able to generate fuel at relativistic speeds.

[JensAyton]

secondly my undefined-ness in what is implemented in 1.69 and what is in the works,

Everything listed here should be working in 1.69. Things listed here generally are not. That’s why they all have a notice at the top saying so. :-)

This page documents a planned future Oolite scripting feature. It is presented as a basis for discussion or to help developers organize their thoughts. The functionality presented may end up taking a radically different form, or may not become available at all.[/b]

thirdly there seem to be many ways to write the syntax.

Yes.

Got a embryonic understanding of how things are working now though.
I kept trying to nest conditions like we do in plist scripts, the way of JS however seems to be '//do stuff' , which means generally a single condition_statement and call another function. (repeat).

Er, there is no problem with nesting if statements. I do it all the time. For example, in the updated cloaking device mission script, which is a pretty straight translation of the old one:

Code: Select all

this.willExitWitchSpace = function()
{
    // If we're in galaxy 5...
    if (galaxyNumber == 4)
    {
        // ...and the asp-cloaked's death_actions haven't triggered...
        if (missionVariables.cloak == null)
        {
            // ...then we count of jumps...
            var cloakCounter = missionVariables.cloakcounter;
            if (cloakCounter == null)  cloakCounter = 1;
            else  cloakCounter++;
            missionVariables.cloakcounter = cloakCounter;
            
            // ...until we reach six or more.
            if (cloakCounter > 6 && system.countShipsWithRole("asp-cloaked") == 0)
            {
                // Then trigger the ambush!
                system.legacy_addShips("asp-cloaked", 1);
                system.legacy_addShips("asp-pirate", 2);
            }
        }
    }
}

You are using the 'let' command again to initiate variables, will you upgrade to JS v1.7 in Oolite v1.70 then?

Yep. (This was part of the cause of the recent extended problem getting it building on Linux.)

I also intend to upgrade to JavaScript 2.0 when possible. Oolite won’t make much use of the new language features, but the engine should be significantly faster.

[nijineko]

keep jumping untill your vector lines up with a planet or sun.

should you miraculously be able to generate fuel at relativistic speeds.

tried, until i ran out of extra fuel tanks.

[JensAyton]

The ability to get property lists into world scripts, for instance through descriptions.plist. (Alternative idea: stick it in the scripts.plist entry.)

[JensAyton]

Ability to find systems within hyperspace range, or possibly an arbitrary specified range. A filter predicate may be useful. Example:

Code: Select all

let systems = System.systemsInRange(7, function(properties) properties.techLevel > 3 );

[Hoopy]

ah! so that's how you ask for a new command when you want it for your OXP.

thanks!

do we need one for converting a system number to it's name as well? Otherwise you end up with the the way the UPS pirate missions work - you tell the user it's planet 85 but can't name it. but you can put a red cross on the galactic chart for them!

[JensAyton]

I thought I’d done that already, but apparently not.

[Kaks]

The ability to block sale of ships, equipment, or goods via javascript

somehing like

market.blockSale('fuel');

then after the woma company is rescued:

market.unBlockSale('fuel');

[JensAyton]

In principle, you could do that by redefining EQ_FUEL to have a tech level of 99, then set missionVariables["TL_FOR_EQ_FUEL"] to control availability. Not entirely elegant, I admit.

[JensAyton]

getSystemName()

[Kaks]

In principle, you could do that by redefining EQ_FUEL to have a tech level of 99, then set missionVariables["TL_FOR_EQ_FUEL"] to control availability. Not entirely elegant, I admit.

Still, better than nothing!