Oolite Bulletins

Posted: **Sat Sep 05, 2009 1:33 pm**

Got around to ensuring that the list of changed JavaScript features for 1.73 is accurate.

Posted: **Sat Sep 05, 2009 6:32 pm**

Out of curiosity, what's the status of ~~max vertex/triangle count for ship models and the~~ (just saw the post about 1.73.1, before it was withdrawn again) the direct usage of .obj in addition to .dat files for them?

Posted: **Sat Sep 05, 2009 6:37 pm**

For the benefit of Mr. McLane, the SystemInfo objects generated by system.info are getting a bit more independent for 1.74. In particular:

SystemInfos now have galaxy, system and coordinates properties (read-only) in addition to planetinfo.plist keys.
They also have a distanceToSystem() method to measure the jump distance to another SystemInfo. (This is necessary because jump distances are calculated at a lower precision than normal vector distances in order to maintain the same jump routes as Elite.)
There is a function SystemInfo.filteredSystems() to search through systems, much like System.filteredEntities().
The prefix script provides a utility function SystemInfo.systemsInRange() to find the systems within a given distance from the current one.

The implementation of SystemInfo.systemsInRange() serves as a handy example:

Code: Select all

SystemInfo.systemsInRange = function(range)
{
    if (range === undefined)
    {
        range = 7;
    }
    
    var thisSystem = system.info;
    return SystemInfo.filteredSystems(this, function(other)
    {
        return (other !== thisSystem) && (thisSystem.distanceToSystem(other) <= range);
    });
}

Posted: **Sat Sep 05, 2009 6:38 pm**

Thargoid wrote:
Out of curiosity, what's the status of ~~max vertex/triangle count for ship models and the~~ (just saw the post about 1.73.1, before it was withdrawn again) the direct usage of .obj in addition to .dat files for them?

As per the forgotten release notes, 1.73 supports arbitrary vertex and face counts, but most of the other model loading stuff stalled.

Posted: **Sat Sep 05, 2009 8:25 pm**

In testing SystemInfo.filteredSystems(), I discovered a problem that also affected timers and system.filteredEntities(): when the function parameter is called,it’s done in such a way that it can’t access variables in the function that created it (in technicalese, it didn’t close over its declaring scope). This explains several problems I’ve encountered before, but not got around to analysing properly. (The use of thisSystem in the previous code snippet is an example.)

It turned out to be a known bug in SpiderMonkey; fortunately, there is a workaround, and it has now been fixed for 1.74.

Posted: **Sat Sep 05, 2009 10:58 pm**

To better support strict mode, and to avoid buggy scripts carrying information across games, I intend to reload scripts whenever the game resets in 1.74 and forward. This means:

The reset() handler will no longer be called. Instead, a new instance of each script will be run, and startUp() called.
There will be no persistent timers.

Posted: **Sun Sep 06, 2009 10:21 am**

All known bugs regarding Strict Mode are fixed.

Posted: **Sun Sep 06, 2009 10:40 am**

General note to OXPers: remember to include a requires.plist file if you use new features, like high vertex/face counts. I just tried to start 1.65 for testing, and it hung during startup due to over-large models in these OXPs:

griff_adder_normalmapped.oxp
ramon_anaconda.oxp
griff_boa.oxp
griff_cobra1_normalmapped.oxp
griff_cobra3_normalmapped_less_scuffed.oxp
griff_ferdelance_normalmapped.oxp
griff_krait_normalmapped.oxp
griff_sidewinder_normal_mapped.oxp
griff_thargoids_normalmapped.oxp
Neolite.oxp

There are almost certainly more with this problem, these are just the ones I happened to have installed at the time.

We have a nice, simple mechanism to avoid this, but it is (by necessity) the responsibility of OXPers to use it. If you haven’t tested with 1.65, you must include a requires.plist with { version="<the oldest version you’ve tested with"; } in it.

I’d quite like to simply refuse to load OXPs without one, but that would break compatibility with old OXPs that actually work.

Posted: **Mon Sep 07, 2009 10:43 am**

Ahruman wrote:
For the benefit of Mr. McLane...

I am thrilled!

Actually I just stumbled across the distinct difference between the planetinfo.plist-properties and the system-properties in respect to the SystemInfo objects, when Oolite refused to respond to System.infoForSystem(galaxyNumber, i).techLevel = 0. Turned out the planetinfo-property is techlevel, not techLevel.

Now there is yet one thing I'd like to do: Setting government, economy, and techlevel to something like "N/A" instead of one of the pre-defined values. Doable?

Posted: **Mon Sep 07, 2009 11:39 am**

Commander McLane wrote:
Now there is yet one thing I'd like to do: Setting government, economy, and techlevel to something like "N/A" instead of one of the pre-defined values. Doable?

Err, doable already, set the system property to nova:

System.infoForSystem(galaxyNumber, i).sun_gone_nova = true;

About the techlevel/techLevel thing: yes, I noticed the inconsistency too! One is the property of system, the other a property of info.

Same thing happens here: system.techLevel = system.info.techlevel

Unfortunately the lower case property is the key as it appears in planetinfo.plist. Probably the best way to remove the inconsistency is for us to completely remove the convenience shortcuts:

I'm sure Frame wouldn't be too pleased about the idea, but we could deprecate system.name in favour of system.info.name, system.techLevel in favour of system.info.techlevel.

As an aside, techlevel, according to the way most oolite plist keys are written, should really have been written tech_level to begin with. But let's not talk about that yet!

Posted: **Mon Sep 07, 2009 12:00 pm**

Kaks wrote:
Commander McLane wrote:
Now there is yet one thing I'd like to do: Setting government, economy, and techlevel to something like "N/A" instead of one of the pre-defined values. Doable?
Err, doable already, set the system property to nova:

System.infoForSystem(galaxyNumber, i).sun_gone_nova = true;

Interesting solution. But wouldn't that have some side-effects as well (like the system not being visitable anymore)? Well, will try it out.

Posted: **Mon Sep 07, 2009 12:49 pm**

Kaks: I think a better solution might be to support camelCase properties for “well-known” properties like techLevel and sunGoneNova, and also continue to support arbitrary keys (or possibly only arbitrary keys without capital letters). Need to think about it a bit.

Posted: **Mon Sep 07, 2009 1:19 pm**

Commander McLane wrote:
Interesting solution. But wouldn't that have some side-effects as well (like the system not being visitable anymore)? Well, will try it out.

Good point. There might be a scriptable way to survive inside a nova system. You can already resize the sun to something smaller, and shrink its corona too, but I wouldn't know what happens to ship temperatures once you do that.... If it's possible to make a novaed system survivable, you could add all sort of planets, stations & stuff...

Ahruman: yep, it's a bit of a conundrum that one. camelCase is the standard for js, and underscore_as_space is the standard we mostly stick to for plists.
Of course, that's not the case in descriptions.plist. There the hyphen-between-words notation reigns supreme!

Posted: **Mon Sep 07, 2009 1:22 pm**

Kaks wrote:
camelCase is the standard for js, and underscore_as_space is the standard we mostly stick to for plists.
Of course, that's not the case in descriptions.plist. There the hyphen-between-words notation reigns supreme!

Consistence above all

Posted: **Mon Sep 07, 2009 1:26 pm**

At least we is consistently inconsistent..

Oolite Bulletins

Progress