The Oolite Extended Project - Fork, no oxp

[pmw57]

Did you try the new exciting way to find planets in trunk? El Viejo seemed quite pleased with it!

Not yet. Compared with using javascript to pull this and prod that, dabbling in the trunk is a big scary monster for me. I'm lucky I was able to resolve debug console issues by downgrading from Python 2.6 to Python 2.4

[Eric Walch]

This still leaves a bit of a problem if the other oxp says something like: 'just go to laleque, it's the planet marked on the map, and when they look at the map there's 10 marked systems? (is there a planet called laleque?)

That problem always has been there. I always have to look at the F5 screen also to see which marked system I should go.

A bigger problem is that marked systems are not linked to an OXP. Any mission that goes to a marked system will unmark it afterwards. But with 256 systems per galaxy the chances are just low currently that this happens. An oxp should not rely on the mark alone.

[Kaks]

I think daily snapshots are available for linux somewhere, so no need to do your own compile!

[another_commander]

Did you try the new exciting way to find planets in trunk? El Viejo seemed quite pleased with it!

Not yet. Compared with using javascript to pull this and prod that, dabbling in the trunk is a big scary monster for me. I'm lucky I was able to resolve debug console issues by downgrading from Python 2.6 to Python 2.4

We have a very easy way for bulding from trunk, if you are running Windows. Have a look at this thread: https://bb.oolite.space/viewtopic.php?t=5943

Alternatively, you can try Diziet's trunk installers. They can co-exist happily with the current releases. Info here: https://bb.oolite.space/viewtopic.php?t=6362

Finally, if you are on Linux, there is already a nightly builds system running, which allows you to download the current trunk binaries in autopackage installable format:
http://www.terrastorage.ath.cx/oolite/status.html

Feel free to try any of the above if you want to test the latest and greatest (and most dangerous ) in Oolite development.

[pmw57]

Feel free to try any of the above if you want to test the latest and greatest (and most dangerous ) in Oolite development.

I will thanks, but not right now. Time is rather scarce as it is. Already it's 4:30am and far too late to be up, but work beckons

[Eric Walch]

The hoopy translation into js shows a very interesting Oolite bug. The bug was reported before by Screet with 1.72 and I also had it once:

On docking you fly through the ship but the engine thinks you are docked. No key works but when pressing 1 you launch!

With the script it constantly happens on the second docking. So I dock, launch, stop, turn 180 degr and dock again. Just air around.

I tries it at least 10 times now (1.73 as well as trunk) It consistently happens on the second docking. When reverting to the plist script, there is no problem. When I disable part of the script the bug goes away but as yet I don't see what triggers it.

The conversion to JS is okay but it would be interesting if others have seen the same.

EDIT:
I have been away for an hour and now I can't reproduce the bug. But something in Oolite reacts wrong sometimes.

EDIT2: Not being able to reproduce the bug was because I made a script error and he defaulted to the plist script. Fixed that the bug is back. Every odd time I dock correctly and every even time i'm not docked.

Now I tried docking at the main station after a success full dock at the casino. I flew right through the main station. So something happens while being docked that sets a condition any next dock will fail. This could well be triggered in a combination with one of my other oxp's.

EDIT3: I found the trigger. "mission.choice" was not reset when finished. This is a bug that prevents other missions from making their own offers. There are other oxps that detect this bug (e.g. ups, but also an other) and correct that. So that oxp bugs Oolite and it is not code in this script that triggers it.

In the mean time I changed small parts in the Hoopy script so it now interacts correct with other mission oxp's. And that works as I got a missionscreen from Vector.oxp while docking at the casino. They both worked correctly together on my docking.

EDIT4: Finally found the two others oxps responsible for this. ups needs a cleared mission.choice to be able to make save offers so it clears the variable on shipWillDockWithStation() giving maximum time to the oxp that forgot to clear it to do it himself.

Than the bug starts with vector that reacts on this clearing with:

Code: Select all

this.missionChoiceWasReset = function()
{
	if(this.hasShown && missionVariables.offering == this.name) this.clearBlockade();
	if(!player.ship.docked || this.hasShown) return;
	//.... remainder deleted
}

For some reason it calls this.clearBlockade(); before checking if the player is docked. When I comment that line out, the problem goes away. In this.clearBlockade() is also a line that clears the mission.choice thereby again triggering the missionChoiceWasReset handler. It ends in a loop, but for some reason Oolite does not crash but also does not manage to dock correctly.

FINAL EDIT. I now removed both ups and vector and added the following line in my test oxp:

Code: Select all

this.shipWillDockWithStation = function()
{
    if(player.ship.docked) log(this.name, "Player is docked")
}

The result is false so nothing is logged. But only the fact I check for player.ship.docked during this handler triggers the bug and I am not visually docked.

[Lestradae]

Eric, if you find a way to get the java script version of the hoopy casino to work correctly, please tell as then I would update the OSE version with your fix or whole script.

A (perhaps incompetent) side remark: Couldn't the whole mission screens problem be eased by making some aspects of them automatised by the game? I mean, perhaps that's not even possible, but if I understood what you wrote part of the problem is that it is rather easy for oxp'ers to not correctly close a mission screen again, thereby blocking all sorts of stuff and breaking others.





L

[zevans]

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.

[zevans]

pmw57, can you please explain to me what the playerStationShow scripts actually do (precisely)?

Because I simply don't get that from looking through the script!

Don't explain it here... put it in comments.

[pmw57]

pmw57, can you please explain to me what the playerStationShow scripts actually do (precisely)?

Because I simply don't get that from looking through the script!

Don't explain it here... put it in comments.

Like this?

Code: Select all

this.guiScreenChanged = function (to, from) {
	if (to === 'GUI_SCREEN_MANIFEST') {
		// As of 1.73.4 scripting can only provide one mission description per script file.

However, the whole idea is a bust, so that code is down for for count.

[zevans]

I might have missed something here, but the station-owning stuff was ONE mission only that controlled its own internal state to reflect buying and selling of stations, etc, then that script could deal with putting a summary rather than a big list on the manifest, it could give you the weekly update, and it could keep track of as many stations as you want limited only by how you encode the state of all those stations into mission variables. Should be pretty slick because it looks like one fairly simple bean-counting mission to the Oolite engine that way...

... or have you already done that.

I volunteered to have a look at converting hOopy because it was a simple one and a good way to remind myself of JS -and- learn the OXP framework basics at the same time. I've just about achieved that but pmw had such a flying start on JS he beat me to it. I'm pleased to say I spotted the same bug as Eric at about the same time...

Doesn't matter tho, since the point was to learn.

So - instead of messing with hOopy, I will now download all this shiny new stuff and be a fresh pair of eyes on it. The detail in the Wiki for scripting is spectacular, I agree, but the principles of how it should hang together for best results, especially when it comes to mangling mission screens, are not entirely clear at first glance, because there -is- too much detail.

We could do with 7 bullet points on what makes an OXP hang together, such as, "most things get done during shipExitedWitchspace", "here is what you have to be careful of to ensure you don't tread on other OXPs", "the JS engine is event driven and be sure to think that way in your design - what events do you need to hook into to make your OXP work." It took me quite some time to absorb that top-down, and I agree the bottom-up part is easy because the detail is so well documented.

[zevans]

Code: Select all

this.guiScreenChanged = function (to, from) {
	if (to === 'GUI_SCREEN_MANIFEST') {
		// As of 1.73.4 scripting can only provide one mission description per script file.

However, the whole idea is a bust, so that code is down for for count.

Well, if that comment was already there, it's L's fault then.

Is it a bust though? Short version of my long post just now: You could have one mission controlling n stations. Or, you couldn't, for some reason I can't think of. Thoughts?

[pmw57]

=The detail in the Wiki for scripting is spectacular, I agree, but the principles of how it should hang together for best results, especially when it comes to mangling mission screens, are not entirely clear at first glance, because there -is- too much detail.

Ahem, I've been guilty myself of not being aware of what the wiki has to say about these things:

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

[zevans]

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.

[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? Oh if only I had one too