Oolite Windows - Trunk nightly builds

[another_commander]

Sounds good, but can we not leave it for after 1.76? Two reasons for this:
- It is not strictly a bug fix. Make clean has always worked by cleaning everything and adding fclean may be a nice idea, but it sure sounds more like a new feature.
- IMHO, playing with build settings at this particular time is probably not the best idea.

[Getafix]

fclean stands for???

It seems to me more rational (humble opinion though) to leave "clean" do a clean.
Wearing the "user hat" I would expect from a "clean" target to revert the folder structure to its original state as much as possible.
If partial clean is that much necessary, then why not put this functionality in a separate target?

EDIT: One more thing. "-d" option didn't work for me. (See dev mailing list for details)

[Kaks]

force clean!

Hmm, from a user perspective your own OXP & savegames should not disappear thanks to whatever Makefile does.

It might be the case that the standard savegames location might need to be moved somewhere else under windows, and that the debug oxp files might be better integrated within the oolite.app file structure in the future...

Anyway, something to consider for after 1.76. Resetting the Makefile as it was, to avoid build settings changes at this stage.

[Fatleaf]

And http://terrastorage.ath.cx/oolite/status_win32.html is down again (sigh!)

04 Dec - EDIT: It's up again!

[Capt. Murphy]

Changes since previous successful build (r4673)

------------------------------------------------------------------------
r4675 | kaks | 2011-12-03 22:25:11 +0200 | 4 lines

Wormholes fixes:
- stopped NPCs following the player at different times from smashing against the navbuoy.
- 'velocity zero' fix ported to NPCs following the player.
Minor code cleanup.
------------------------------------------------------------------------
r4674 | another_cmdr | 2011-12-03 19:51:19 +0200 | 1 line

MNSR step 1: Rolling version number to 1.76.
------------------------------------------------------------------------

Is the mythical about to become reality......exciting.

[Getafix]

@FatLeaf
FritzBox and DynDns failed their handshake.
Unfortunately I don't have remote config enabled and I'm away. I'll be back late at night and the service will be refreshed.
It's getting to my nerves too!

[DGill]

Tried Oolite 1.77.0.5555 works well, no problems - very nice effects with BGS-A1.6_r66

However, just tried oolite-trunk-1.77.0.5575-dev.win32 and it crashes to Windows desktop when exiting a fuel station (Fuel Station 1.33.oxp). No error given in the log file and not an issue under 1.77.0.5555.

[Thargoid]

Same result here, although in my case it was entering the station. Only thing in the log (and the console) was

Code: Select all

14:16:08.727 [script.javaScript.warning.ooliteDefined]: ----- JavaScript warning (militarytargettingsystem 1.0): removeFrameCallback(): invalid tracking ID.
14:16:08.727 [script.javaScript.stackTrace]:  0 (militarytargettingsystem.js:177) <anonymous function>
14:16:08.728 [script.javaScript.stackTrace]:     this: [Script "militarytargettingsystem" version 1.0]

But that's unrelated to this issue I would say.[/color]

[another_commander]

Confirmed using Fuel Station 1.34. Seems to happen also on r5556, which is the revsion where we changed to GCC 4.7.1. The only thing that I have here is stderr.txt, giving the following:

Code: Select all

oolite: Uncaught exception NSGenericException, reason: Collection {} was mutated while being enumerated
Stack

The information is minimal. There is no backtrace when run under the debugger, as the program seems to exit normally as part of the exception handling. The GNUstep stack seems to be empty. Further invesigation definitely required.

[Thargoid]

My stderr says the same, for reference.

[Switeck]

Nightly trunk binaries for the Windows port of Oolite are now available from the page below:
http://terrastorage.ath.cx/oolite/status_win32.html

The script producing the builds runs every night at 04:00 UTC (05:00 CET).

While I know that new builds were no longer being generated every night, it seems as if this has stopped updating completely as a result of moving from Berlios to GitHub.

Should I be looking elsewhere for more recent dev builds of Oolite?

[Cody]

Should I be looking elsewhere for more recent dev builds of Oolite?

No, I think it's only a case of no additions/revisions to trunk lately.

[cim]

Should I be looking elsewhere for more recent dev builds of Oolite?

No, I think it's only a case of no additions/revisions to trunk lately.

Exactly that. There are a bunch of commits in Github that aren't in the Berlios SVN repository, but they're either part of the changes to migrate to the new version control software, or they're not intended to form part of 1.77.1 (and for obvious reasons "what will become 1.77.1" is the nightly build target). Well, okay, bar one change which I've not got around to making in SVN as well...

[Switeck]

Ok, so it's pretty up-to-date then.

Not that I'm in any rush, but should I be looking to the old location in about 1-3 months for a newer build?

[cim]

Ok, so it's pretty up-to-date then.

Not that I'm in any rush, but should I be looking to the old location in about 1-3 months for a newer build?

If you're just downloading the nightly builds, the location you download them from is unlikely to change. If you want the latest source code, then in 1-3 months hopefully the migration to Github will be complete by then.