Upspring Linux link?

[PTSnoop]

Is there a Linux version of Upspring available anywhere? IÔÇÖve been looking around, but the link at http://springrts.com/phpbb/viewtopic.ph ... &start=420 takes me to a ÔÇ£You need a SSL client certificate that the Web server will recognizeÔÇØ page, and the version at http://github.com/Kloot/upspring wonÔÇÖt compile for some reason (IÔÇÖm using Ubuntu Jaunty, for the record). And IÔÇÖm on an ATI graphics card so it wonÔÇÖt work in Wine.

Also, is there a Linux version of Scriptor anywhere, or will I have to get it working in Wine? (This hasnÔÇÖt worked either so far, but I reckon the problemÔÇÖs more likely to be at my end... IÔÇÖll start tweaking settings and see what happens.) Or is there another BOS/COB compiler that works fine on Linux? (I remember hearing something about Brain or Cobbler, but both linked to dead fileuniverse.com links..)

[Tobi]

I suppose you're talking about the post quoted below. Here I have updated the links tho.

Source: http://springrts.com/svn/spring/trunk/tools/Upspring/
Patch to make it compile on Linux: http://springrts.com/mantis/view.php?id=516

(It's written in C++, using FLTK toolkit.)

As for scriptor; you could try out Lua unit scripts if you use a recent development build of Spring. Then you don't need any compiling at all.

[PTSnoop]

Okay, thanks. I now have all the Upspring files downloaded and sitting in ~/Programs/Upspring .

Next question: how do I install them? I can't see a makefile or anything like that. Is there some SVN-ish way of installing? (I've never really used SVN before...)

[Kloot]

the version at http://github.com/Kloot/upspring wonÔÇÖt compile for some reason

Where does it fail? The sources in that repository are slightly more up to data than those from Tobi's SVN link, and should be easier to compile. (Still not point 'n click though.)

[maackey]

upspring also works perfectly fine in wine. might save you some trouble/time.

[PTSnoop]

On the github version, in src/fltk2, running './compile' works fine but 'make' gives a long line of compilation followed by

/usr/bin/ar cr ../lib/libfltk2.a ...
/usr/bin/ar: ../lib/libfltk2.a: No such file or directory
make[1]: *** [../lib/libfltk2.a] Error 1
make: *** [all] Error 2

The whole output's at http://pastebin.com/m46ce39d8 , if it helps.

---

maackey: Not for me it doesn't.

.

[Kloot]

/usr/bin/ar cr ../lib/libfltk2.a ...
/usr/bin/ar: ../lib/libfltk2.a: No such file or directory
make[1]: *** [../lib/libfltk2.a] Error 1
make: *** [all] Error 2

This means that for some reason make failed to create the proper output directory 'lib/' (under src/fltk2/) on your system. If you do so manually and then re-run it, the build will succeed.

[PTSnoop]

Okay, thanks.

*compiles*

Okay, now fltk2, lib3ds and LuaJIT compile fine (or appear to), but Upspring itself gives

Code: Select all

EditorDef.h: At global scope:
EditorDef.h:174: warning: ÔÇÿImageFileExtÔÇÖ defined but not used
make[1]: *** [../obj/CurvedSurface.o] Error 1
make[1]: Leaving directory `/home/andrew/Programs/gitUpspring/Upspring/src/upspring'
make: *** [all] Error 2

Again, the complete output (or as much of it as I can copy from the terminal) is at http://pastebin.com/m29c2156f .

[Kloot]

I've pushed a few fixes to the repo; please pull them and try again.

[PTSnoop]

Which one have you updated? The git one?

I've downloaded and tried both; same problems as before.

[tizbac]

Kloot: on MdlObject::InitAnimationInfo there's a 64 bit compatibility problem
when typecasting pointers use long int instead of int so on 64 bit OS it will be 64 bit and on 32 bit it'll be 32

[roxi]

[quote="PTSnoop"]Best Free Web Hosting
Which one have you updated? The git one?
I've downloaded and tried both; same problems as before.[/quote]
Ya, the same with me

[Amalrik]

hey !
I tried to compile Upspring on my x64 linux, but I failed. Can someone confirm it s a 64bits pb ?

http://pastebin.org/438577

I took sources from http://github.com/Kloot/upspring btw

[SpliFF]

Unfortunately Upspring is built against a 32-bit only LuaJIT.

I created a new version with 64-bit Lua support and hundreds of compiler warnings cleaned up. Unfortunately I ran into some problems while rewriting the resource loading code to use a folder instead of data.ups. Then I went to Thailand and I've been catching up on my paid projects ever since.

Anyway the point is if you go to http://github.com/SpliFF/upspring you'll find a version that will compile and run fine under 64-bit linux provided you fix the data loading code I broke. ATM you'll see warnings like unable to load skybox textures and buttons if the resources aren't found.

The problem is pretty trivial for a C++ coder but I just don't time to sit down with it right now. Perhaps kloot could look at merging some of my updates back into his. The only real issue to watch other than the resource loader is I haven't built a SWIG wrapper for the new Lua.

I think stable LuaGIT may support 64-bit by now so perhaps that could be swapped back in to avoid rewritting the SWIG.

[HeadHunter]

Okay, it really seems to build fine... If i make it work any better I'll send u patches.

[HeadHunter]

I also have trouble it can not load button icons because they are not in the repo...

[SpliFF]

they're in a zip file called "data.ups" you need to extract it first. I found the idea of using the zip an unnecessary complication so the plan was to use flat files instead.

[HeadHunter]

so how do i unpack it exactly?

[SpliFF]

If I remember correctly it's just a zip file with a silly extension. If not then I must have found or extracted the original files some other way. If you can't unzip data.ups let me know and I'll send you the files.

EDIT: I just checked the git repo and it looks like I have moved/lost some files. I'm about to upload data.ups and the buttons folder to the data folder. You can probably work it out from there.

[SpliFF]

Resources uploaded. Just be aware they are not necessarily in the places or formats that UpSpring is looking for. I have some other local changes here which relate to changing the search paths and methods but since I know those changes broke some stuff as well I won't upload them unless you really need them. It would probably be better if you make your own choices as to where and how these resources are stored and loaded (or you could choose to revert to the original "data.ups" method (at least give it a zip extension though).