Spring RTS Engine

New release 2.0
Changes (off top my head is)

Code cleanup

Split script into multiple files easier to work on it now. Inspired from Omni.
Plus as a small bonus, u will notice .pyc files after u run script (if u got write permission to the directory). There are python compiled version of parts of script, they basicly decrease load times for parts of script.

Removed unnessary imports that i had in before

Fixed FSAA

Also added the file GLOBAL.py
It basicly contains global variables i.e
where spring binary | background image are located at.
Also the config values so u can alter them i.e u can add a 4 water option, if they code a new render.

GLOBAL.py also has an option STARTUP = 0
Need to change it to STARTUP = 1 to get script to start, just to make sure users got it configured. Atm only outputs warning to console. Will throw together a GUI warning next time

Looking good i may test it in a bit and give my feedback, one thing though.

Will it be able to run from the same directory as FBO's port?

If i get time i try & glance @ fbo scripts
But would be nice if someone could send me in pm what they do exactly, since i dont have a debian distro. (Or if fbo has any request / ideas for the script.)

Can see why u couldnt use script atm
It just edits ~/.springrc & uses ~/.springrc (as a temporary file)
Both of those files can be changed in GLOBAL.py (assumes relative path from HOME Directory, can change that if needed to)

Other than that atm,

Skirmish Button just saves config & starts spring binary & closes spring-config while u are in spring. (No point havin spring-config open in background using up memory, will make it an option in future, alot of bits i want todo atm ).
Quit button saves config & quits out.
If u dont want to save press the X (close button) on the window.

U can also change the spring binary location in GLOBAL.py

What is springrc exactly?

I will try and figure this out shortly.

Seriously you guys need to make sure you use the same directory with the spring files, no one wants to have to have more than one set of mods, maps, etc.

Hey i got no debian distro. I cant just have every distro on the earth installed.
I keepin it distro friendly as possible.
Also my script got Global Variables in GLOBAL.py to change locations, background image, even the upper/lower default settings.

That way u can change them around or even package it along with spring, in a .deb .rpm ebuild for spring if package maintainer wanted to aswell

~/.springrc = /home/<username>/.springrc

That is default file (and location) for spring config file under linux.
It contains settings for Spring, and is just a file nothing else.

To check type Note:- My script will make that file & default settings if missing. Just incase someone just installed spring & hasnt started it yet. Tried out spring-config.

I highly doubt fbo has changed this in his scripts, cant see why u would.

Ah right i get it well i will get onto ubuntu now and install FBO's version and then install your version.

Actually, it's home/.springdir/localhost:0.0/.springrc

Why is it called .springdir? Just .spring would sound much better. There's no .xmmsdir, it's called .xmms

Found out that its named after hostname & display.

Why blah anyway more importantly how to u pass to
/usr/bin/spring.bin
to tell it where datadir is & .springrc is aswell (i.e what would u type in console)?

i.e /usr/bin/spring.bin --datadir=/foo --config=/foo

Screenshots below are current Work In Progress for skirmish section.
Note:- Ignore the extra large comboboxs in 2nd screenshot will fix once i get rest of gui layout figured out.





Got to love unitsync bindings
Just was looking @ it today, can extract
map info i.e description, wind, tidal, size & starting positions & it does the rendering for me *drools*

Also anyone notice the reduced comboboxs in 2nd screenshot.
If u pick Closed, other combobox's for players underneath it disappear :)

With some luck have it ready tomorrow.
Got background work done i.e to save to script.txt , just need to add GUI widgets.

*cough* similar interface that starts a server and keeps track of users that join aka multiplayer*/cough*

Word wrote:*cough* similar interface that starts a server and keeps track of users that join aka multiplayer*/cough*

That is called a lobby, and he has said he will take a look at omni.

Good work buddy, looking awesome!

Although one thing, don't make any player boxes dissapear, unless you have a way to add them back in

No..no it's not. That's called multiplayer. A lobby is online multiplayer big difference in complexity.

And by closing a player box you make all those below it dissapear...so naturally if you make it open again all those below it will appear again..

Oh yeah i get it hehe.

Ps. Any luck on asking FBO about his script yet hollowsoul? And you said in your original post about looking at omni and making a chat for lobby, any ideas if you might be able to implement actual battlerooms so we can play online on linux?

wow we've forgotten abotu AFLobby quickly, there are comments in the mailing list that quash all those antijava slowness myths your spreading.

I have posted askinf for updates in your AF lobby thread, have i forgot? NO

I was simply asking hollowsoul if he could come up with anything.

And have you ever used linux before with java, it gets slow. I am not spreading myths, i am not spreading anything jeezus.

Dont diss an entire language because a specific program ran slow. If that where the case we'd be calling every language slow.

I am not dissing it, im not dissing anything.

Ok let me make it clear as i don't want this topic to turn into an argument.

I am eagerly awaiting your lobby.

For me anything in java runs slow. No other thing does in linux.

And lets get back on topic?

Lets not get off topic plz.
If anyone wants to argue about AFLobby versus Pygtk. Go make yourselfs a new topic

Both apps (assuming AFLobby is gonna be opensource), are gonna be open-source.

While its possible to compile my script & turn it into a .exe
It would require abit of work, i.e add code to detect OS platform, & saving spring settings to windows registry.
Obviously this requires work & i got enough on my plate as it is. And thus not in my goals atm

As far as i am concerned its gonna friendly competation, while abit hard to rip code from each other. We can look @ how each other roughly got a feature, or maybe borrow a GUI design idea from the other.

Hollowsoul any ideas when you will have the skirmish options done?

And a suggestion - include an image for your app to use by defualt.

It be done when its done, i.e a couple of hours time -> tomorrow morning (GMT).
Atm tryin to figure out how to get side info from mod archive using unitsync = last stumbling block atm (i.e for XTAPE v7 Arm / Core).

Not gonna include image by default will just incase file size, and u only need to download a background once.
Hopefully when app is more complete some package maintainers will have it installed along side spring & already setup and include a image along with it.

But i do have plans for GUI front-end to configure app when its first run.

Mental Note :- Convince Radtoo to agree to seperate gentoo ebuilds for pygtk app