System Demux

[mcarans]

Code: Select all

	var excl = new Array();

	if (worldScripts['Famous Planets Launch Script']) {
		excl.push(8, 130, 40, 125, 247, 101, 56, 155, 149, 142);
	}	

	if (worldScripts['Famous Planets 2 Launch Script']) {
		excl.push(7, 129, 39, 124, 246, 99, 55, 154, 147, 141, 73, 50, 89, 35, 227, 250, 188, 111, 186, 101, 222, 29, 23, 177, 93, 131, 42, 21, 100, 28, 16, 221, 36, 198, 150, 62, 172, 241, 200, 18, 86, 126, 3, 153, 132, 90, 44, 228, 13,
        458,370,298,365,383,463,392,262,280,304,309,334,460,449,477,492,322,314,344,396,445,321,400,434,301,369,371,313,350,285,289,330,378,310,279,444,338,
        570,677,618,710,676,
        781,815,898,786,890,
        1040,1217,1255,1116,1033,
        1431,1286,1365,1426,1520,
        1725,1682,1666,1654,1573,
        1969,1823,2003,1949,1812);
	}	
	for (var i = 0; i < excl.length; i++) this.system_info[excl[i]] = 0;

Is this fix already in system demux or is it coming later?

[Eric Walch]

Is this fix already in system demux or is it coming later?

It is not in yet. Give DrBeep some time to fix all the small issues. (Most are the same issues as with the original System_Redux 1.2).

And my above fix has a bug because I retrieved the system numbers directly from the Famous planet script. But systemDemux is "1" based so I should have added 1 to all system numbers above.
On comparing the system numbers for FP 1.0 and 2.0, I noticed two of the old exclusions were also wrong. I proposed DrBeep a better fix were the system number for FP are not hardcoded but read in from the script at startup time. My hardcoded example worked only correct for FP 2.5 but by letting the script looking into that other script, it will follow any future change of FP. Something like:

Code: Select all

	if (worldScripts['Famous Planets 2 Launch Script']) {
        var planets = worldScripts['Famous Planets 2 Launch Script'].planetList;
        for (var i=0 ; i<8; i++) {
            for (var j=0; j<planets[i].length; j++) {
                this.system_info[i * 256 + planets[i][j]] = 0;
            }
        }
	}

but making sure it runs after FP and make al systems "0" based to keep things easy.

And seing the benefits of transforming some of the maps in cube maps, I think DrBeep will only doing an update after converting at least those maps were the artifacts show clearly.

[Commander McLane]

... by letting the script looking into that other script, it will follow any future change of FP. Something like:

Code: Select all

	if (worldScripts['Famous Planets 2 Launch Script']) {
        var planets = worldScripts['Famous Planets 2 Launch Script'].planetList;
        for (var i=0 ; i<8; i++) {
            for (var j=0; j<planets[i].length; j++) {
                this.system_info[i * 256 + planets[i][j]] = 0;
            }
        }
	}

but making sure it runs after FP and make al systems "0" based to keep things easy.

I agree. Famous Planets should best take care of its list of changed planets itself, and other OXPs should access that list.

Would the list be better accessible from the start, if it wasn't a property of the FP-script, but a global variable defined in the beginning of FP? Something like

Code: Select all

var famousPlanetsPlanetList = new Array(...);

That would be availably to all other scripts at all times, wouldn't it?

[Kaks]

No, it would be an internal variable to FP, no other script would be able to see it.

Same as, when you write a function, you can create internal variables to that function...

[Eric Walch]

No, it would be an internal variable to FP, no other script would be able to see it.

Same as, when you write a function, you can create internal variables to that function...

Normally you are right on JS things, but not here. Other scripts can see it. On the global level all scripts use the same global variables.

I even double checked:
Put "var famousPlanetsPlanetList = "loaded";" in one oxp and than you can read the content from the console or an other oxp. No need to make a this. variable from it. But on the long run I think we get name conflict if we starting doing this as not everybody will use long unique names for this. So better make such variables a property of this an access it over the worldSrcipts.

[JensAyton]

Put "var famousPlanetsPlanetList = "loaded";" in one oxp and than you can read the content from the console or an other oxp. No need to make a this. variable from it. But on the long run I think we get name conflict if we starting doing this as not everybody will use long unique names for this. So better make such variables a property of this an access it over the worldSrcipts.

Correct. vars and function declarations that are not used as values in root scope become properties of the global object – generally recognised as a bad decision in the design of JavaScript, but one that’s deeply entrenched. This is the same reason script methods need to be explicitly assigned to properties of this.

It’s possible to work around this with SpiderMonkey, but it’s a hack and conflicts with the ECMAScript language standard.

[Kaks]

I stand corrected then, & I'll rephrase it this way:

No, it wshould be an internal variable to FP, no other script wshould be able to see it.


And now, for something slightly different:

Encapsulation conflicts with the published ECMAScript standards? Ahruman, would you care to elaborate?

By the way, here's a perfectly valid js example of what I mean:

Code: Select all

function A() {

  var _a; // "private" a

  this.getA = function _getA() {
    return _a;
  };

  this.setA = function _setA(a) {
    _a = a;
  };

}

var a = new A();

a.setA(10);
alert(a._a); // undefined, "private"
alert(a.getA()); // 10

taken from the following page:
http://dmitrysoshnikov.com/ecmascript/c ... apsulation
It's a bit of a palaver, but its behaviour is both consistent across browsers, and respects ECMAScript standards, which, afaik, is simply not too bothered by encapsulation either way...

[JensAyton]

In your example, _a is hidden (visible only in the activation scope of a call to A() and closures defined within A). However, A and a, having been declared at root scope, are properties of the global object (or “window” in a browser context).

[Kaks]

In the browser context, sure.

But aren't world & ship scripts meant to be instances of the generic script object, just as a is an instance of the A function/object?

To go back to the browser's analogy, you can have a look at what happens when you have two different frames in a frameset, or an iframe inside another html document: what's globally declared inside a frame doesn't get exported to top, aka the overall global environment, indeed it's explicitely not meant to.

The current global js namespace situation in Oolite, while continuing the fine legacy script tradition of having everything in the same place, might well mean that the current worldScripts arrray & various ship.script objects are possibly just an interim implementation of Oolite's js object model!

Anyway, I still fail to see how proper encapsulation and/or separation between scripts goes against ECMAScript standards! Perhaps a bit of a hyperbole there?

[JensAyton]

Anyway, I still fail to see how proper encapsulation and/or separation between scripts goes against ECMAScript standards! Perhaps a bit of a hyperbole there? ;)

I never said anything of the sort. In fact, I have demonstrated encapsulation using closures on this very forum, earlier today.

What I did say is that, in the following exchange, McLane and Eric are right and you are wrong:

Would the list be better accessible from the start, if it wasn't a property of the FP-script, but a global variable defined in the beginning of FP? Something like

Code: Select all

var famousPlanetsPlanetList = new Array(...);

That would be availably to all other scripts at all times, wouldn't it?

No, it would be an internal variable to FP, no other script would be able to see it.

Normally you are right on JS things, but not here. Other scripts can see it. On the global level all scripts use the same global variables.

In terms of ECMA-262, 5th Edition, section 14 (“Progam, Semantics”) a program is executed in “a new execution context for global code as described in 10.4.1”. In section 10.4.1[.1.2], it is specified that the VariableEnvironment for such an execution context is the Global Environment. Section 10.2.3 specifies that “The global environment’s Environment Record is an object environment record whose binding object is the global object (15.1).”

The result of this is that a var declaration in global scope declares a property on the global object. This is a known flaw in the language, repeatedly lamented by Brendan Eich, among others. Several fixes have been proposed, but they basically boil down to various ways of using syntactic sugar to build module systems on top of objects and closures – semantically the same as using object properties or doing things inside functions rather than declaring anything in global scope. Such a fix could be standardised, at earliest, in 2013.

(Going back to the web context, a single “page” from a user perspective may contain several JS contexts with distinct global objects. Multiple scripts loaded in the same context can and do pollute each others’ global namespaces this way, while scripts in different contexts do not.)

We could probably get more intuitive behaviour in Oolite by making each script its own global object, inheriting from the “real” global object, but it would be non-trival to make it work properly and would slow script execution. It would also be a very deliberate attempt to circumvent the specified semantics of the language.

Hmm. Which thread are we in, again? :-)

[Kaks]

What I did say is that, in the following exchange, McLane and Eric are right and you are wrong:

which I promptly acknowledged!

Still,

It’s possible to work around this with SpiderMonkey, but it’s a hack and conflicts with the ECMAScript language standard.

made me ask for some further clarification, which you provided.

However, at this level it's purely a matter of point of view: if you have a look at paragraph 10.2.2.3, that 'circumventing' you mentioned would actually fall within complying with the standard itself, since those scripts can be - and indeed at least partially are - defined as objects, as opposed to programs. And that's what I meant when I corrected would with should!

In any case, implementation details might well be different once we get the new super-duper js engine!


Which thread are we in? Good point!
Plus, as engrossing as this conversation is for the both of us, I suspect that watching paint dry might be slightly more exciting for most people!
Sorry for the interruption of the scheduled programme! Signing off for now!

[Eric Walch]

Sorry for the interruption of the scheduled programme! Signing off for now!

Okay back to the topic than.

mcarans asked if the compatibility code with Famous Planets is already in the code. Its is not, but you can download my modified script here. Until DrBeep has updated his release you can use this script. It also fixes the double planet addition on multiple launches and the deprecation warning in the log about the setTexture method. Just replace the original "script.js" file with this one.

[Thargoid]

Is DrBeep the censored cousin of DrBeeb who wrote the OXP?

[Frame]

about all this conflicting

I have just been having repetitive OXP crashes, with no error log, so after hours of back tracing

I found it to be two timers, each attached to their own ship entry in the same shipdata.plist file, and each residing in a different script file of the js kind, but in the same oxp.

the only thing that was identical was the naming of the timer, which looked like this

Code: Select all

this.shipSpawned = function()
{
this.runningTimer = new Timer(this, this.checkHostile,0,0.75);
}

I was getting about 1-3 mins of play before Oolite Chrashed..

I thought I was safe using the "this" prefix, apparently not
as my crashes went away after renaming one of the timers to

Code: Select all

this.shipSpawned = function()
{
this.Other_runningTimer = new Timer(this, this.checkHostile,0,0.75);
}

The thing is that this was darn hard to track down, and had it not been for this and other discussions about namespace prefixes, I likely would not have solved it other than by chance..

So I can only point out again, how important it is to have uniqely named objects..

Even when scripting with this. prefix it seems..

Cheers Frame...

[JensAyton]

Sorry, but no. If those are different scripts, they’ll be different this objects, and there can be no conflict. The apparent fix is a coincidence.

Any actual information about the crash would be welcome.