The Oolite Extended Project - Fork, no oxp

[Lestradae]

I can see that some way to help automate that part of the install ... that checks for known conflicting OXP folders and asks your permission to delete them ... I could come up with that for windows machines if you would make good use of it.

That's a very nice offer, but there are showstoppers imho:

1) People who actually read the installation instructions for future OSE don't need an installer, they will simply need to not double-install the oxps included and listed. If they ignore the install infos, chances are good they would also ignore an automated "compatibility-checker".

2) As there are three main operating systems and not only windows, I'm not sure if an automated installer/de-installer wouldn't confuse players on the other two OS.

3) The installer would have to keep pace with OSE itself, which will also need to be upgraded when the original oxps it partially consists of are upgraded, which would mean double work when upgrading, and that only for one-third of the OS.

4) I will create a folder termed "Oolite Ooniverse AddOns Package" that will contain the newest version of every other oxp not in OSE except the sound and HUD ones. There will be no merger or whatever (I thought about it, but it would be a royal pain in the ... to keep it upgraded then). So people could then download the Oolite installer, OSE, and that package and basically have an aaaall-of-them oxp, an extended Oolite with everything in that was created for it. So that might make installation much easier also, for beginners especially.

That's my rationale, for saying thanks for the offer, but no

Cheers

L

PS: What I could really, really need would be someone who attempted to translate the OSE-XML.plist script as a whole into java script. I simply can't do it, and it would help a lot.

Perhaps someone can be found to help me with this

Future players of OSE would be thankful for sure ...

[pmw57]

That's a very nice offer, but there are showstoppers imho:

1) People who actually read the installation instructions for future OSE don't need an installer, they will simply need to not double-install the oxps included and listed. If they ignore the install infos, chances are good they would also ignore an automated "compatibility-checker".

The issues aren't just at the time of install either. Several weeks later (months, years?) they can come across other OXPs and may want to install them to see what they are like. Are people expected to remember the large list OXPs already used in OSE?

I suggest that we revist mentioning on the wiki that certain OXPs are also included in OSE - to help remind people that they shouldn't download them if they already have OSE.

PS: What I could really, really need would be someone who attempted to translate the OSE-XML.plist script as a whole into java script. I simply can't do it, and it would help a lot.

Perhaps someone can be found to help me with this

Why do I feel that my long experience with javascript places me just right for this task.

:snappy salute: I'll do it my cap'i'tan - you can count on me!

Edit: I see that you initially converted from OpenStep to XML. You like creating work eh?

[Lestradae]

The issues aren't just at the time of install either. Several weeks later (months, years?) they can come across other OXPs and may want to install them to see what they are like. Are people expected to remember the large list OXPs already used in OSE?

I suggest that we revist mentioning on the wiki that certain OXPs are also included in OSE - to help remind people that they shouldn't download them if they already have OSE.

I'm not saying I'm against it - I think there is a lot that speaks for it - but this is far beyond my control or even influence to achieve. It would require every oxp maker to make a little sign that says "this is in OSE" or not.

And I simply don't think that's going to happen

If it is done, I would be happy about it, but ... see above.

Why do I feel that my long experience with javascript places me just right for this task.

:snappy salute: I'll do it my cap'i'tan - you can count on me!

Wow

That is very good news. If the whole legacy script could be translated to java script, I am led to believe that it would speed OSE up massively and noticably.

Please do that! Or should I say: Make it so?

Cheers

L

[pmw57]

That is very good news. If the whole legacy script could be translated to java script, I am led to believe that it would speed OSE up massively and noticably.

Please do that! Or should I say: Make it so?

Cheers

L

Excellent! I'm your man - now what is a plist, and how does one convert from that to js?

Edit: Ahh, http://wiki.alioth.net/index.php/Property_lists and http://wiki.alioth.net/index.php/Script ... JavaScript

Now to automate some of this . . .

[Chaky]

I've already made a tool that translates XML to ASCII and back.

I only haven't released it yet....

[Lestradae]

Perhaps you two could start an exchange about the XML -> java script translation then?



L

[Chaky]

Well, the code I made is painfully depndent on integrity of XML (not so vice-versa), and this tool I made (still haven't come up with a name..) already spotted "errors" with many XML-ed plists. "errors" as in <string> instead of <integer> for numbers..

I'm not sure if the quotes are mandatory for names with _ and without spaces.. I see alot of ASCII plists with quotes just about everywhere, but I'm pretty convinced that they are only needed with multi-worded names or values.. Maybe macs handle _ differently? Or nixes?

Regarding speedup... Let's take OSE for example. (because it has about the biggest shipdata plist). Simple change in XML formatting makes the 2 megs of difference (changing 4 spaces for 1 'tab'), and I'm pretty sure that smaller plists get parsed faster, hence improve overall performance.

[Screet]

Regarding speedup... Let's take OSE for example. (because it has about the biggest shipdata plist). Simple change in XML formatting makes the 2 megs of difference (changing 4 spaces for 1 'tab'), and I'm pretty sure that smaller plists get parsed faster, hence improve overall performance.

That's only parsed when the cache is built up. Later launches of Oolite will read from the cache anyway, instead of using that file.

What really would speed things up would be to translate the worldscript plist file from OSE to javascript, which is more efficient at being run by Oolite and also could be written MUCH shorter that way, as most of it is redundant: e.g. one script for AAA and one script for AAB and another for ABA while all would deliver the same result concerning the income when only the first A does determine it and the others are for the descriptions being displayed (L, please correct me, when I'm wrong on this).

Screet

[pmw57]

Regarding speedup... Let's take OSE for example. (because it has about the biggest shipdata plist). Simple change in XML formatting makes the 2 megs of difference (changing 4 spaces for 1 'tab'), and I'm pretty sure that smaller plists get parsed faster, hence improve overall performance.

That's only parsed when the cache is built up. Later launches of Oolite will read from the cache anyway, instead of using that file.

What really would speed things up would be to translate the worldscript plist file from OSE to javascript, which is more efficient at being run by Oolite and also could be written MUCH shorter that way, as most of it is redundant: e.g. one script for AAA and one script for AAB and another for ABA while all would deliver the same result concerning the income when only the first A does determine it and the others are for the descriptions being displayed (L, please correct me, when I'm wrong on this).

Screet

Except for accessing things like mission_playerstation_AAA from javascript, for which no searching has revealed documentation about, the rest of the conversion from plist to javascript is done.

Am in the process of testing some things now, and will update in a while.

[Commander McLane]

Any other oxps in existence are, as far as I know, compatible with OSE V0.69. All of them.

Actually I am not so sure about that.

If I understand correctly, there is a feature in OSE that, if you have bought a station, the script increases your bounty on every jump.

Well, there is a similar feature in Anarchies that the script decreases your bounty on every jump, modifying the in-built bounty handling.

Now I cannot be sure, and I can't test it, but I strongly guess that, if two scripts independently of each other manipulate the value of player.bounty on every jump, the results will be messing up each other.

I take it you have thoroughly tested that with a fugitive pilot, and OSE and Anarchies installed?

But my guess, not being able to test it myself, is that OSE for this reason will be incompatible to Anarchies.

[Commander McLane]

Except for accessing things like mission_playerstation_AAA from javascript, for which no searching has revealed documentation about...

http://wiki.alioth.net/index.php/Mission_variable

[pmw57]

Except for accessing things like mission_playerstation_AAA from javascript, for which no searching has revealed documentation about...

http://wiki.alioth.net/index.php/Mission_variable

Thank you

Let's finish this thing off

[Lestradae]

If I understand correctly, there is a feature in OSE that, if you have bought a station, the script increases your bounty on every jump. ... Well, there is a similar feature in Anarchies that the script decreases your bounty on every jump, modifying the in-built bounty handling ... I strongly guess that, if two scripts independently of each other manipulate the value of player.bounty on every jump, the results will be messing up each other ... I take it you have thoroughly tested that with a fugitive pilot, and OSE and Anarchies installed?

I did test this, and yes, you are correct with your above assumptions. I am not happy with the OSE WiP's way of handling this anyways, not only because it could produce a problem with anarchies.

I think the problem could be solved if the OSE script did not set a new fixed bounty but raise or lower the existing player bounty instead. When pmw57 has finished translating the player station scripts into java script, I'll look into realising it like that.

Then the two scripts should be able to function simultanously - anarchies would make its alterations and OSE too, the result should be a working mix. I.e. a pirate cove - owning crime baron who has a rising bounty on his head could continually clear his legal record by letting the hackers reset it for him etc.



L

[pmw57]

I think the problem could be solved if the OSE script did not set a new fixed bounty but raise or lower the existing player bounty instead. When pmw57 has finished translating the player station scripts into java script, I'll look into realising it like that.

I am working on that part now, as we speak. How do you want this to work. For each of the A to L stations (being the first of the three chars) what bounty increase do you want. +5 for A, +30 for B, etc...

[Commander McLane]

By the way: You may want to increase the bounty not on every jump, but distinguish between normal jumps and misjumps?

This is what the engine is doing with your legal status: The bounty is halved only for jumps ending up in a system. If you misjump, your bounty stays the same. So you can't get from fugitive to clean between one system and the other, just via a series of misjumps.

The revised routine in Anarchies follows this scheme. Your bounty is no longer halved, only reduced by 10%. But still this only happens if you jump into a system, not on misjumps. Have a look at the relevant part of the code in Anarchies: the shipWillEnterWitchspace and shipWillExitWitchspace event handlers and the functions attached to them. The names are pretty much self-explaining.