The Oolite Extended Project - Fork, no oxp

[pmw57]

That was the detail I referred to - quite a daunting page for someone who wants to learn because they have had a stunning OXP idea but no previous JS experience at all. Anyway, the answer is for me to shush moaning and write the summary and add it to the Wiki.

You, have a wiki account?

Speaking of which, why does the mission reference page not link to the mission offering how-to?

I would have thought that it's <zorg>pretty bloody important!</zorg> for people to know how to put things together like that.

http://wiki.alioth.net/index.php/Oolite ... e:_Mission
http://wiki.alioth.net/index.php/OXP_mission_offering

[Thargoid]

As a late thought to expand one that has been made earlier, why not use some dummy equipment that when bought is auto-removed again (so as not to appear in the equipment list of the ship), but use that to call up a mission screen of your own where you can do your buying, selling and income reviewing on a screen of your very own, without bothering anyone? You can then also charge a "fee" for accessing the purchase screens etc.

If you want to see how to do it, look at Eric's target reticle OXP or my RingRacer OXP for how to have a non-list piece of equipment, and of course for the mission screen when purchased bit iirc your station purchases already do that?

[Lestradae]

Some thoughts about the ideas thrown around here:

First, the player stations are already bought via the equipment screen. Then a missions window pops up (I used the template from your five thargoids aquatics equipment for that, T) that says something hopefully atmospheric about the bought station and shows it off.

The player stations are a piece of pseudo-equipment each (each one of the 192 stations is unique) that defines a mission variable when bought and is immediately removed.

The reason is as Screet said: Otherwise, the player stations wouldn't stay if you change ship, and they could be damaged in combat

As the mission variables now contain the information if and which stations you own, this info is independent of if the ship is changed/sold and it is saved in the savegame. Everything is then derived from there:

If the mission variable for a given station is on ("1" instead of undefined "null"), you are getting credits and legal consequences once each week, each station (its type, location system & galaxy plus income) is listed on the missions F5-F5 screen, the "sell" option for it/them starts to appear on the equipment screen and if you visit the system in the correct galaxy, it is spawned via planetinfo.plist there.

The mission-offering never figures into that, nor should it! Too much could go wrong there, Eric wrote about this, and it would be a pretty unwieldy way imho to list your owned stations like that.

As I said: I am happy to include any alternate listing solution that, at any time, shows the player all his stations, their type, average income, system & galaxy - as long as this is not done on the equipment screen or as a mission offering.

Hope to have consolidated the relevant information as food for thought

L

[pmw57]

As I said: I am happy to include any alternate listing solution that, at any time, shows the player all his stations, their type, average income, system & galaxy - as long as this is not done on the equipment screen or as a mission offering.

How about when people go to the mission screen, another screen is activated, says that a person walks by in passing who recognises you, and says "random comment #1" Choice: Do you wish to "Ignore them" or "See station details"

If player stations are not owned, it means no change to the interface.
If player stations are owned, you would F5-F5-Enter to ignore them
If player stations are owned, you would F5-F5-Down-Enter to see them

When seeing them you would have a full page to show information about each individual station, and a choice at the bottom to see the next station, or to go back to the normal missions page.

[Diziet Sma]

so why restrict it?

Extending the analogy with the banking system, I don't get charged to withdraw money in my home country, but I do get charged extra if I withrdraw my money abroad. It would just feel more real to me that the money I didn't take with me gets an intergalactic handling fee. Charging a fee at the moment the extra wealth is created seemed to me the simplest way to handle it.

Anyway, it might sould plausible to some people, and not so plausible to others!

Well, they are -Galactic- credits... not Intergalactic. You can't spend US dollars in Australia, even though they are both dollars...

Maybe this comes down to a residency tax discussion. So if you jump out of the galaxy you are charged some sort of capital gains tax which you stop paying again when you return to the galaxy and become domiciled.

Actually, you are always in the same galaxy, so this idea needs some re-thinking... The generally accepted story is that the 8 'galaxies' came to be known as such due to misunderstandings on the part of the earliest explorers. Later observations confirmed that they are actually 8 regions in the same galaxy, and are more correctly referred to as the 8 galactic charts or just 'charts' for short. Unfortunately the old incorrect terminology remains in use out of habit.

An interesting discussion on some related aspects of this can be found here. In particular, the 3rd map posted can help to visualise a probable layout.

[Eric Walch]

http://wiki.alioth.net/index.php/OXP_mi ... ne_with_JS

That was the detail I referred to - quite a daunting page for someone who wants to learn because they have had a stunning OXP idea but no previous JS experience at all. Anyway, the answer is for me to shush moaning and write the summary and add it to the Wiki.

I agree that that whole page has to be rewritten. I never found motivation to do that. I once wrote that page in detail before we had JS.

Although the same principles are valid for JS:
1) Never create a mission page when an important page is shown. (That are mainly the mission-screen and the arrival_report-screen as those content is lost by overwriting)
2) Never use the mission.choice variable when it contains a value that your script has not generated as that can contain a value that must be read by an other script.

I have always had an JS example script in ups and some time ago I just added that script to that page but mission offering in JS should get a page of its own. The example script is just one way to achieve this goal and is optimised for showing a screen on docking.

[pmw57]

Although the same principles are valid for JS:
1) Never create a mission page when an important page is shown. (That are mainly the mission-screen and the arrival_report-screen as those content is lost by overwriting)

Would you kindly arrange for the guiScreenChanged event on the wiki to provide access to those screen names. The "to" and "from" words could link to a separate page that provides those names.

http://wiki.alioth.net/index.php/Oolite ... eenChanged

That separate page could then be built on to indicate things like which ones are useful to check first, to prevent over-running other processes.

2) Never use the mission.choice variable when it contains a value that your script has not generated as that can contain a value that must be read by an other script.

That information would be very valuable to have up at the following location:
http://wiki.alioth.net/index.php/Oolite ... e:_Mission

Aside from the reference, there seems to be quite a market for a users guide

[Commander McLane]

Well, they are -Galactic- credits... not Intergalactic. You can't spend US dollars in Australia, even though they are both dollars...

Maybe this comes down to a residency tax discussion. So if you jump out of the galaxy you are charged some sort of capital gains tax which you stop paying again when you return to the galaxy and become domiciled.

Sorry, but this makes no sense.

The credits are GalCop's currency, and GalCop spans over all 2048 planets in all eight charts. That's the vey premise of the game.

So of course you can earn and spend credits anywhere, at least at any station run by GalCop (= every main station, and a couple more). And the rest of the world (like Rock Hermits, or Salvagers) would be foolish not to accept the Ooniversal currency.

That doesn't mean that each and every planet can't have its own currency, and at least some of them will. But this simply doesn't matter to you as player, because GalCop regulations explicitly prohibit you from dealing with the planetary markets directly. All trade has to go through the main system station, which is controlled by GalCop for the very reason of creating a ooniversally working trading system, see above.

And you can see on every Galactic Hyperjump that your accound balance stays exactly the same (except for the 5000₢ the Galactic Hyperdrive itself sets you back, of course).

[pmw57]

Would you kindly arrange for the guiScreenChanged event on the wiki to provide access to those screen names. The "to" and "from" words could link to a separate page that provides those names.

http://wiki.alioth.net/index.php/Oolite ... eenChanged

That separate page could then be built on to indicate things like which ones are useful to check first, to prevent over-running other processes.

Even more usefully, there is this.reportScreenEnded() event handler which fires when the resports screens are all done, so mission screens can then be activated after that.

http://wiki.alioth.net/index.php/Oolite ... creenEnded

[Commander McLane]

Would you kindly arrange for the guiScreenChanged event on the wiki to provide access to those screen names. The "to" and "from" words could link to a separate page that provides those names.

The names, as well as many other vital informations, are available on the legacy scripting methods page:

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

There you for instance find also the documentation of the various coordinate systems usable in Oolite.

While legacy is deprecated, it is still working in much of the underground of Oolite, therefore it is essential to be aware of it as well.

[Commander McLane]

Even more usefully, there is this.reportScreenEnded() event handler which fires when the resports screens are all done, so mission screens can then be activated after that.

Note, however, that you still need the other event handlers as well, in case there is no report screen displayed on docking (happens all the time). Then the handler won't fire, of course.

******

On a general note: While it is useful to link to more information in the Wiki, I seriously think that http://wiki.alioth.net/index.php/Oolite ... e:_Mission is not the place to discuss fundamentally how to handle missions and mission screens. It is exactly what it says on the tin: part of the Oolite_JavaScript_Reference. And its job is to document the properties and methods related to the Mission object. No less, and no more.

[pmw57]

While legacy is deprecated, it is still working in much of the underground of Oolite, therefore it is essential to be aware of it as well.

Would it were that I had a wiki account, I would happily translate that information over to appropriate javascript-based information.

What's the hasing ritual for obtaining such an account?

[pmw57]

On a general note: While it is useful to link to more information in the Wiki, I seriously think that http://wiki.alioth.net/index.php/Oolite ... e:_Mission is not the place to discuss fundamentally how to handle missions and mission screens. It is exactly what it says on the tin: part of the Oolite_JavaScript_Reference. And its job is to document the properties and methods related to the Mission object. No less, and no more.

The case for a User Guide is growing

[Lestradae]

What's the hasing ritual for obtaining such an account?

I think it involves contacting (summoning, evoking, conjuring up, channeling) winston.

[pmw57]

What's the hasing ritual for obtaining such an account?

I think it involves contacting (summoning, evoking, conjuring up, channeling) winston.

I could have sworn that I had already. What happens when a PM sits in the outbox and doesn't do anything?