Spring RTS Engine

hmm, thats odd, it opens Opera for me but thats the windows specific code, Ill look into it.

And the next set of packages wont be numbered theyll have more descriptive names, AFLobbyJAR.zip and AFLobbyResources.zip so therell be no confusing one for the other.

Progress



Highlighting support has been added, and it applies almost everywhere. A single addition to one class means it is now supported in all ChatPane instances, aka channels, pms, battle window, the channel list, etc.



I've also made numerous adjustments to the battle window to move as much logic as I can into a BattleModel class. This should simplify singleplayer and AFS support greatly, aswell as increase speed and stability by allowing me to swap out the battlewindow for another GUI class.



Minor speed ups here and there by re-arranging some little but odd things, like moving the logoff button from the top to the first tab let me get rid of some code, and some deadweight property settings which were being set then overwritten.

And some fixes to the channel logging I implemented a few days ago.

There've also been some colour changes to give better support for substance looknfeel skins when I finally decide to implement the theme chooser.

The channel player list is looking a bit ugly atm but I dont care as Im ripping it out and putting a springlobby style table with filters in.

Theres also the whole AI thing

AF wrote:

The battle screen is the single reason why I dont like using AFLobby. The player list is a UI disaster :P. Columns, goddam it, Columns! I hope you are still planning on redesigning it so its more like supcom..

Other than that it rocks (from the limited time ive used it..)

If you flip a few pages back youll see a mockup of a supcom inspired redesign. I really want the table based control supcom has for setting out players and the seperate window for game options and the summary along the side.

In the mean tim stretching the tab control to fill the whole page, moving the minimap into the first tab, and putting the player list next to it would give me more horizontal space allowing columns of sorts.

AF wrote:If you flip a few pages back youll see a mockup of a supcom inspired redesign. I really want the table based control supcom has for setting out players and the seperate window for game options and the summary along the side.

Cool, that's good to hear.

Actually I just committed a verion with the chat tab re-arranged completely, the battle window looks quite different now. Namely the lack of bright blue everywhere.

Here you go Lippy:

http://img255.imageshack.us/my.php?image=mockupek8.jpg


@AF
I've noticed a few bugs in the battle lobby in Beta 2 final.

When hosting, changing the map isn't reflected by other player's lobby client. They only see the default map, small divide. When the battle starts the host loads the correct map, whereas everyone else fails to connect and loads small divide.

The players list in the battle lobby often becomes unresponsive, and its scroll bars disappear.




Also, changing allies, teams, colours, etc... is difficult as the lobby doesn't always seem to reflect settings changes. Eventually, after a couple of changes it all snaps into place. I'm often getting complaints regarding ally numbers because I do not reflect my chosen settings in the teams tab. Its kinda hard to describe or reproduce this one.

I would like to recommend that aflobby search ~/.spring for maps and mods instead of its current location which is either usr/share/games/spring or usr/local/share/games/spring. The current solution depends on the assumption that these folders are linked (not sure about the vocabulary) to each other. I believe the default location for maps and mods is ~/.spring/maps and ~/.spring/mods, but someone else who knows what they are talking about should confirm this.

Relative wrote:

lol, my thoughts exactly; was going to do the same thing but couldn't remember my photobucket password .

http://img255.imageshack.us/my.php?image=mockupek8.jpg - thanks relative.

The mockup looks good but I would recommend these changes (I understand you probably already had a few of em in mind... ill say em just in case);

*Firstly pictures > words for everything. Therefore replace "arm/core" with the appropriate pictures.
*Can't see a ready column (again with pictures of green/red circles or something)
*Have column headings, then replace any unnecessary words; e.g. add a team heading and instead of using "team 1, team 2 etc..." use just "1,2,3 etc..)
*A small summary of teams somewhere would be useful :)
*Satirik's lobby has a nice way of displaying any comshares etc.... Could you possibly implement that?

Once those important things are implemented; autobalance would be useful too . (Basically copy all satirik tasclient features, apart from anything springmark related ofcourse!)

Relative wrote: I would like to recommend that aflobby search ~/.spring for maps and mods instead of its current location which is either usr/share/games/spring or usr/local/share/games/spring. The current solution depends on the assumption that these folders are linked (not sure about the vocabulary) to each other. I believe the default location for maps and mods is ~/.spring/maps and ~/.spring/mods, but someone else who knows what they are talking about should confirm this.

I'm not too sure if ~./spring is default location; in the installation (http://spring.clan-sy.com/wiki/SetupGui ... stallation) guide you have to do; "echo '$HOME/.spring' > /etc/spring/datadir" which suggests that you define the location using the datardir file.
EDIT; Just checked, I changed the contents of /etc/spring/datadir and It couldnt find any maps. Therefore we can safely say that the directory to use is specified in /etc/spring/datadir

Relative thats fixed in svn, if youll notice there are scrollbars in the shots I posted earlier.

Then again that entire layout was changed yesterday and committed to svn.



Ill probs stick the minimap in a coloured panel and move those buttons to the bottom so theyre on every tab.

Quick question, where is the svn?

look in the dev forum in the sticky with the dev links

Something odd has just happened, aflobby can't get past the welcome screen. When I click on the Log into Lobby button nothing happens, but I do get a stack trace:

http://pastebin.ca/668517

Edit:

Ok, I've got it working again. There was something wrong with my settings.tdf.

This is what it looked: I then changed it to this, and it started working again:

I think thats because the ui.lasthosted.name = "" is causing an error

Now I got rid of those errormessages from the beginning. Only problem is now that when I log in to server it tries to generate minimaps and then crashes.. Any idea what could be wrong now? I have the correct path as datadir and all..

Itll try to write to /.aflobby/images/minimaps/ iirc, it needs to be accessible/writable.

btw do you have any maps to write minimaps for?

Beta 3 should be a simple extract drop in install all in 1 folder, the only intervention required being the user editing settings.tdf to point to unitsync.so and spring.

AF wrote:Itll try to write to /.aflobby/images/minimaps/ iirc, it needs to be accessible/writable.

btw do you have any maps to write minimaps for?

Beta 3 should be a simple extract drop in install all in 1 folder, the only intervention required being the user editing settings.tdf to point to unitsync.so and spring.

Yeah I have maps. The folder it makes those 4kb jpeg files is $home/.aflobby/minimaps .. I got the error message now and it is about libjpeg.so... damn. So there's something wrong with my unitsync.so right?

Even though it's compiled from source along everything else.. I'm not sure if the version of java I'm using has anything to do with this but it's:

java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

perhaps 64bit system is the issue here.. or?

No I think libjpeg.so is the issue.

Your unitsync is missing dependencies.

Beta 3 is indefinately stalled as I dont have a 64bit unitsync and nobody who can build one will do so.

I've now* gotten 32bit and 64bit JDKs installed, work has resumed, although a 64bit unitsync.dll is still desirable.

Don't you mean "now" instead of "not"?