Page 7 of 15
Re: Oolite Windows - Trunk nightly builds
Posted: Thu Dec 01, 2011 12:48 pm
by 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.
Re: Oolite Windows - Trunk nightly builds
Posted: Thu Dec 01, 2011 1:30 pm
by 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)
Re: Oolite Windows - Trunk nightly builds
Posted: Thu Dec 01, 2011 5:21 pm
by 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.
Re: Oolite Windows - Trunk nightly builds
Posted: Sat Dec 03, 2011 1:16 pm
by Fatleaf
And
http://terrastorage.ath.cx/oolite/status_win32.html is down again (sigh!)
04 Dec - EDIT: It's up again!
Re: Oolite Windows - Trunk nightly builds
Posted: Sun Dec 04, 2011 8:46 am
by 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.
Re: Oolite Windows - Trunk nightly builds
Posted: Sun Dec 04, 2011 4:20 pm
by 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!
Re: Oolite Windows - Trunk nightly builds
Posted: Fri Dec 14, 2012 2:01 pm
by 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.
Re: Oolite Windows - Trunk nightly builds
Posted: Fri Dec 14, 2012 2:19 pm
by 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]
Re: Oolite Windows - Trunk nightly builds
Posted: Fri Dec 14, 2012 3:52 pm
by 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.
Re: Oolite Windows - Trunk nightly builds
Posted: Fri Dec 14, 2012 3:54 pm
by Thargoid
My stderr says the same, for reference.
Re: Oolite Windows - Trunk nightly builds
Posted: Fri Jun 14, 2013 12:24 pm
by Switeck
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?
Re: Oolite Windows - Trunk nightly builds
Posted: Fri Jun 14, 2013 12:51 pm
by Cody
Switeck wrote: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.
Re: Oolite Windows - Trunk nightly builds
Posted: Fri Jun 14, 2013 2:01 pm
by cim
Cody wrote:Switeck wrote: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...
Re: Oolite Windows - Trunk nightly builds
Posted: Fri Jun 14, 2013 3:49 pm
by 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?
Re: Oolite Windows - Trunk nightly builds
Posted: Fri Jun 14, 2013 3:53 pm
by cim
Switeck wrote: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.