It lives!
Moderators: winston, another_commander
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
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.
E-mail: [email protected]
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Existing OXPs should continue to work.
The prettified ships are currenty an OXP project.
The prettified ships are currenty an OXP project.
E-mail: [email protected]
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.Ahruman wrote:Barring that, well, dajt is suffering from a bout of Real Life at the moment, and Winston has evaporated. Any volunteers?
Download Fighter HUD, Stingray and System Redux from the EliteWiki
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Good question. Since I’ve never done a Windows build, I don’t know precisely. You will need: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.
- 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.
You’ll also need Subversion (or TortoiseSVN or similar) to get at the code repository.
E-mail: [email protected]
-
- Quite Grand Sub-Admiral
- Posts: 364
- Joined: Tue Aug 17, 2004 7:05 am
- Location: Orange, NSW, Australia
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.
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.
Regards,
David Taylor.
David Taylor.
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
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. :-)
E-mail: [email protected]
@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?
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?
Download Fighter HUD, Stingray and System Redux from the EliteWiki
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
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).
E-mail: [email protected]
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?
Does WebSVN work okay through a proxy server?
Download Fighter HUD, Stingray and System Redux from the EliteWiki
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
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
E-mail: [email protected]
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.
Download Fighter HUD, Stingray and System Redux from the EliteWiki
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?
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?
Download Fighter HUD, Stingray and System Redux from the EliteWiki
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
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.
E-mail: [email protected]
-
- Quite Grand Sub-Admiral
- Posts: 364
- Joined: Tue Aug 17, 2004 7:05 am
- Location: Orange, NSW, Australia
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:
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.
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];
}
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.
Regards,
David Taylor.
David Taylor.