Oolite 1.77 deployment build issues

[CommRLock78]

Yes. Sometimes, especially, after first I've launched 1.76.1

You know, that is a pretty old build your using there with r5046 - I'm running r5610. That might be part of the problem, too .

[OSH]

No, no! On 1.76.1 everything works ok. I meant, AFTER launching 1.76.1, 1.77 sometimes works OK.

[Cody]

But your pic shows a very old version of 1.77 trunk (as mentioned) - update to 1.77 Deployment build and try that, as much has changed.

[OSH]

Aaa, now I know what are you meant. I will download it and check. Thanks!

[pagroove]

I have sometimes the issue that dockable object spins incredibly fast (centrifuge style) and have displaced docks.

I've had this with Griff's objects but also with the Wildships stations.
Anyone has this?
I'm running on Mac.

[pagroove]

Nobody has this problem. ? It happens fairly often.

[Eric Walch]

Nobody has this problem. ? It happens fairly often.

Nope, not on 10.6, nor on 10.7.

Does it also happen with no oxp stations installed? And since 1.77 a script can read AND write the station roll. (I see this is not clearly documented on the wiki because it is only listed under ships, but should have an entry with stations also). What values do you get when reading out the value in the console? : system.mainStation.roll

EDIT: my editing was simultanious wit Cim's posting below. Still I think that roll should also be listed under stations because a ship roll feels as a different property as a station roll. And it is only writable for stations.

[cim]

And since 1.77 a script can read AND write the station roll. (I see this is not yet documented on the wiki).

roll is a property of Ship, so it's documented there.
http://wiki.alioth.net/index.php/Oolite ... _Ship#roll

No, I've not seen this either.

[JazHaz]

Nobody has this problem. ? It happens fairly often.

I've not seen it on Windows 7 64bit.

[pagroove]

Well next time it happens. I shall document it better.
To my knowledge it only happens only with OXP-stations.

They spin incredibly fast and the dock is displaced also so launching ships is difficult or impossible even. Landing in such a case is also not possible. The stations really spin as fast as a Washing Machine. I never use any time accelerating functions. So that can be ruled out.

I've seen this problems probably till now on:

Griff Stations,
P.A. Groove Stations (because they use a Griff model)
Wildship Stations (in Trunk at least. Not sure if this happens with the latest version also by Thargoid so I have to investigate).
navigation buoy's also

My system is a MBP 2011 running Mac OSX Lion 10.7.5
With a deployment 1.77 build.

[Thargoid]

Which version of WildShips are you using, 1.05 or 1.06 (or a beta of 1.06)?

The 1.05 to 1.06 update concerning the stations is the introduction of the two explicit docks, compared to the virtual dock that is used in 1.05 (with a bit of scripting to make the ships come out in both directions). But also one of the beta's introduced a slowing of the station roll rate once that functionality got put into the trunk code.

So if you're not using the released version of 1.06 with Oolite 1.77 then I'd recommend that you update to it.

[pagroove]

Which version of WildShips are you using, 1.05 or 1.06 (or a beta of 1.06)?

The 1.05 to 1.06 update concerning the stations is the introduction of the two explicit docks, compared to the virtual dock that is used in 1.05 (with a bit of scripting to make the ships come out in both directions). But also one of the beta's introduced a slowing of the station roll rate once that functionality got put into the trunk code.

So if you're not using the released version of 1.06 with Oolite 1.77 then I'd recommend that you update to it.

1.06. But I have not observed the 'spinning problem' with your stations. But I have to investigate it better.

[another_commander]

My Windows desktop shortcut icon for launching the game doesn't work. I think its because of the parameters I used to pass to the game:

Code: Select all

C:\Oolite\oolite.app\oolite.exe -nosplash -fullscreen -load c:\oolite\oolite.app\oolite-saves\Poseidon.oolite-save

The only way I can get the game to run is to execute oolite.exe from within the oolite.app window.

Are any of these parameters not working for deployment builds now?

As it turns out, the Objective-C runtime distributed with the Windows port of Oolite v1.77 (objc-1.dll) had some issues with exception handling. The inability to use Windows path separators in the parameter for the -load command line option was a result of that. The problem should be fixed with r5626. I guess some nightly build testing might be in order so that we can confirm that this is now fixed. Alternatively, you can download the new objc-1.dll from the Berlios repository and copy it to the oolite.app folder after backing up and overwriting the previous one.

You can still load a game from the command line in v1.77 even without the new dll if you use slashes instead of backslashes for path separators. In the example above, modifying the shortcut as follows:
C:\Oolite\oolite.app\oolite.exe -nosplash -fullscreen -load c:/oolite/oolite.app/oolite-saves/Poseidon.oolite-save will get the savegame to load successfully.

[Cody]

This seems to work fine in r5626 (Win 7) - but I do miss my intro music.

Code: Select all

D:\Oolite-Trunk\oolite.app\oolite.exe -nosplash -load d:\oolite-trunk\oolite.app\oolite-saves\Cody.oolite-save

[CommRLock78]

This seems to work fine in r5626 (Win 7) - but I do miss my intro music.

Code: Select all

D:\Oolite-Trunk\oolite.app\oolite.exe -nosplash -load d:\oolite-trunk\oolite.app\oolite-saves\Cody.oolite-save

I like the intro too, but I like even more quickly loading my game when I use the appropriate custom launcher