Page 3 of 5
Posted: Thu Mar 08, 2007 10:39 am
by JensAyton
The Javascript and textured-planets branches were always branches, i.e. experimental versions. I hope to integrate the JS branch at least into the trunk.
Posted: Fri Mar 09, 2007 5:45 pm
by ovvldc
Will this break anything? OXPs and so on? To the best of your knowledge, of course...
How about the prettified ships that keep being drawn up?
Best wishes,
Oscar
Posted: Fri Mar 09, 2007 6:44 pm
by JensAyton
Existing OXPs should continue to work.
The prettified ships are currenty an OXP project.
Posted: Fri Mar 09, 2007 7:23 pm
by CaptKev
Ahruman wrote:Barring that, well, dajt is suffering from a bout of Real Life at the moment, and Winston has evaporated. Any volunteers?
What would I need installed to build my own version of Oolite for the PC? I have compilers for C, C++ and C# but not for object C.
Posted: Fri Mar 09, 2007 8:10 pm
by JensAyton
CaptKev wrote:What would I need installed to build my own version of Oolite for the PC? I have compilers for C, C++ and C# but not for object C.
Good question. Since I’ve never done a Windows build, I don’t know precisely. You will need:
- GNUstep, in particular the GNUstep Base Library. There’s a binary installer on the GNUstep FTP server. The GUI libraries and developer tools should not be required.
- A build of GCC which can do Objective-C. I’m not sure where to get this, and the GNUstep site isn’t very forthcoming.
- SDL - specifically libSDL, SDL_mixer and SDL_image, if I recall correctly.
Hopefully dajt can provide some insight.
You’ll also need
Subversion (or TortoiseSVN or similar) to get at
the code repository.
Posted: Sat Mar 10, 2007 1:29 am
by dajt
First thing to do is read the "Building Oolite from source" information on the wiki -
http://wiki.alioth.net/index.php/Runnin ... rom_source.
This is slightly out of date, but I think the only thing missing to get the trunk going is libxml2. The DLL is in the deps directory but you need the .lib and include files to build the game so you'll need to actually build libxml2 and have it installed in $GNUSTEP_LOCAL_ROOT for the build to work. Then rebuild gnustep-base, telling it to use libxml2 so it can understand XML plist files.
If you want to try building the JavaScript branch you'll also need to copy the JS related stuff to the proper include and lib directories. This is all actually in the bracnh deps so at least you don't have to build it.
Sorry it is a bit of a mess - no-one else has tried to build Win32 for a long time so my dev env has grown and changed over time and I've not made a simple to use package to get others going.
I'm swapping my laptop for a new one next week so I'll have to go through this process myself soon. That might be a good time to look into making an env for other people, but it will be a BIG download - essentially a customised GNUstep installation.
Posted: Sat Mar 10, 2007 1:37 pm
by JensAyton
In the meantime, if you (Kev) do get it working, updating the write-up (there was one already, whaddya know) would be a valuable service for the community. :-)
Posted: Sat Mar 10, 2007 4:08 pm
by CaptKev
@Ahruman and dajt, thanks for the info guys!
I've built libxml2.lib and setup everything as specified in 'Building Oolite from source', but I'm getting this error;
svn: Unknown hostname 'svn.berlios.de'
when running this line;
$ svn checkout svn://svn.berlios.de/wsvn/oolite-linux/trunk
Do I have to register with Berlios to access the files?
Posted: Sat Mar 10, 2007 4:30 pm
by JensAyton
For anonymous access, no. In any case, that's a DNS error. The line seems to be wrong – it should be svn://svn.berlios.de/oolite-linux/trunk – but that shouldn’t affect the error. Check whether you can connect via HTTP:
http://svn.berlios.de/ (works for me right now).
Posted: Sat Mar 10, 2007 5:31 pm
by CaptKev
Hi Ahruman.. I did try svn://svn.berlios.de/oolite-linux/trunk first, but that didn't work so I connect via HTTP: to
http://svn.berlios.de/ (works okay) then selected the oolite project which added wsvn/oolite-linux to the URL, so I tried svn://svn.berlios.de/wsvn/oolite-linux/trunk too.
Does WebSVN work okay through a proxy server?
Posted: Sat Mar 10, 2007 5:49 pm
by JensAyton
WebSVN – the /wsvn/ in that URL – is simply a server-side script-based browser for Subversion repositories. svn://svn.berlios.de/oolite-linux/trunk is the correct svn: (svnserve) URL. Proxies or firewalls could be a problem with svnserve repositories; you can also check it out over HTTP as
Code: Select all
svn checkout http://svn.berlios.de/svnroot/repos/oolite-linux/trunk
Posted: Sat Mar 10, 2007 9:30 pm
by CaptKev
Still didn't work even after setting the http-proxy-host in WebSVN, so I installed WebSVN on the server which worked straight away
, then manually copied it across.
Posted: Sun Mar 11, 2007 8:05 pm
by CaptKev
My first build appears to of worked okay with a few OXP installed
, the build went very smoothly.
I would like to have a go at including the JavaScript branch, would I just build the makefile in the branches\js, then copy the .exe and js32.dll across?
Posted: Sun Mar 11, 2007 8:15 pm
by JensAyton
You could try that, but bits of the JS branch seem to be missing – files related to another experiment of dajt’s, and also bits of the JS code. Most of the extant JS code is now in the trunk, but I can’t seem to make it do anything. One of the apparently-missing bits of the JS code is the bit that actually loads JavaScript. I may have to trawl through old revisions of the JS branch.
Posted: Sun Mar 11, 2007 11:07 pm
by dajt
I've just built the JS branch and it is working fine. I have a couple of files modified locally, which would be to do with the equipment refactoring I warned you about.
The JS scripts are loaded the same time other OXP scripts are, in ResourceManager.loadScripts. The main loop in that method looks for JavaScripts scripts, OOScripts, then finally PLIST scripts. Here is the code to load JavaScript ones:
Code: Select all
if ([[NSFileManager defaultManager] fileExistsAtPath:jsFilepath])
{
Universe *universe = [Entity dataStore];
JSContext *cx = [[universe scriptEngine] context];
OXPScript *scr = [[[OXPScript alloc] initWithContext:cx andFilename:jsFilepath] retain];
if (scr)
[results addObject:scr];
}
I tried it with the JS version of AsteroidStorm and it behaved as expected.
Note that only OXP scripts can be JavaScript (or OOScript). The main game scripts can still only be PLIST scripts because neither OOScript or JavaScript can handle multiple missions in a single source file which is how the main scripts are done. I tried to support this with the JS ones but couldn't get it to work.
This should not be a serious problem.