Page 6 of 56
Posted: Wed Oct 24, 2007 12:10 pm
by Arexack_Heretic
Ahruman wrote:Arexack_Heretic wrote: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
Posted: Wed Oct 24, 2007 1:06 pm
by JensAyton
OK.
Context:
Arexack_Heretic wrote: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.
Posted: Wed Oct 24, 2007 1:41 pm
by 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?
Posted: Thu Oct 25, 2007 11:32 pm
by 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!
Posted: Thu Oct 25, 2007 11:42 pm
by 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.
Posted: Fri Oct 26, 2007 11:11 am
by JensAyton
Arexack_Heretic wrote: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.
Posted: Thu Nov 01, 2007 12:54 am
by nijineko
Arexack_Heretic wrote: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.
Posted: Sun Dec 16, 2007 10:56 pm
by JensAyton
The ability to get property lists into world scripts, for instance through descriptions.plist. (Alternative idea: stick it in the scripts.plist entry.)
Posted: Mon Feb 18, 2008 11:40 am
by 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 );
Posted: Mon Feb 18, 2008 12:08 pm
by 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!
Posted: Mon Feb 18, 2008 4:49 pm
by JensAyton
I thought I’d done that already, but apparently not.
Posted: Mon Feb 18, 2008 7:52 pm
by 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');
Posted: Tue Feb 26, 2008 4:43 pm
by 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.
Posted: Tue Feb 26, 2008 4:43 pm
by JensAyton
Posted: Tue Feb 26, 2008 5:55 pm
by Kaks
Ahruman wrote: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!
