Spring RTS Engine

nemppu wrote:

Relative wrote:This also works under windows.

windows potr of linux program which make windows funktion to linux ????lol

No, java is multiplatform. AF is making this lobby for both windows and linux. This is just the linux thread.

Relative wrote:

nemppu wrote:

Relative wrote:This also works under windows.

windows potr of linux program which make windows funktion to linux ????lol

No, java is multiplatform. AF is making this lobby for both windows and linux. This is just the linux thread.

ok))))

http://spring.unknown-files.net/file/35 ... elease_10/

pre-release 10

If that works fine with no bugs Ill re-release it as Beta 3.5 final (so people aren't as confused seeing a big string of beta 3 releases).

Oh I did forget about the default values in settings.tdf

I want to get to work on beta 4 as soon as possible but I want this build verified as 100% stable.

I have no problems with this latest build.

With this release I have problems logging into a server i run locally. AFLobby chokes on hashing the last map. At first I thought that was a problem with the map itself and removed it from my maps directory, but the problem remains. There is no console output and the window itself stays responsive. Also the minimap image is created and the whole process works just fine on taspringmaster.clan-sy.com
I am running the latest server available from the download page in "lan mode".

Additionally AFLobby seems to be searching for maps not only in the maps directory. When I moved the map one directory up, it still tried to hash it.

Is it possible to determine if the correct unitsync.so is used? Apparently i pointed AFLobby to an old one at first and it gave no error.

The new battle screen layout doesn't seem to work well with 1024x768 and less. Screenshot: http://homepages.xnet.co.nz/~zangel/snapshot2.jpg

@koshi

I just tested aflobby with the linux lan host server found here, and it worked fine.

http://spring.clan-sy.com/dl/TASServer.jar

Are you sure the server is running correctly? What you described is what happens if it cannot find/connect to the server. If you are running a server you should either select the localhost option, or if its on another PC within your network manually enter the IP address.

koshi. AFLobby does nto search for files and folders. That is unitsyncs job, and unitsync uses the same code as spring.

If you have a map sdz/sd7 you can place it anywhere and spring will find it as long as unitsync knows to look in those folders. So the maps in the maps folder is not so spring can find it its so we know which archives are maps. You could download all your mdos and maps into the mods folder and it would still all work.

In the mean time I have no experience connecting aflobby to a local LAN server, and I expect it would give a LAN server an internet IP not a LAN IP. Too many variables, someone else is going to have to muddle through it as I lack the time and resources, and most importantly I lack a half decent lan server

Sorry guys, it seems i need a serious whack in the head.
Somewhen between last night and this morning my server (a headless box in a cupboard) restarted and since there was no error message from AFLobby i never even thought about checking if TASServer was running properly.
Beside me not thinking of the obvious there should be some sort of notification, should there not?

Well neither me nor lippy have found anything wrong (with the exception of beejayzed's battle lobby resolution issue), so I'd say let it go gold.

edit: @koshi

I agree

I've reduced the size of the battle window inside the IDE, it fits on an 800x600 screen now.

I've also added 2 command line parameters

netbeans will revert aflobby back to the old working directory behaviour prior to the bug fix so netbeans will continue to work correctly.

chat will remove all battle and map functions and remove all use of unitsync, allowing you to login in pure chat mode without aflobby even attempting to load unitsync. This is the same as what happens when AFLobby cant find unitsync only login is faster and there's no Unitsync error message window.

Also AFLobby is supposed to return you to the login page if it cant connect, instead if removes the channelview and stays put at the login page which is a bug I'm fixing now.

Beta 3.5:

You put the wrong default path values in settings.tdf, change them to this:
The resolution issue for 1024x768 and below still exists. I'll get a screenshot later.

Other than that's its fine.

A side note. Small divide is required. Without it the battle protocol command gives null as a parameter which is invalid, causing the server to reject the attempt to host a game and preventing the user from hosting.

All users should have small divide anyway, its a standard map.

AF wrote:A side note. Small divide is required. Without it the battle protocol command gives null as a parameter which is invalid, causing the server to reject the attempt to host a game and preventing the user from hosting.

All users should have small divide anyway, its a standard map.

Ahhh, so THAT's my problem

I was wondering why I couldn't host at all...

Ubuntu deb doesn't come with maps/mods, and I never play small divide anyway...

Why is it actually required? I don't understand.

Its assumed that all users have this map, so when you host a game, AFLobby specifies that map.

But because the map wasn't on your system the helper classes returned null as the files hash, and TASServer does not accept the value null so it borked and sent back an error message.

AF wrote:Its assumed that all users have this map, so when you host a game, AFLobby specifies that map.

But because the map wasn't on your system the helper classes returned null as the files hash, and TASServer does not accept the value null so it borked and sent back an error message.

Ah, that makes sense...

Would it be hard to make it choose the first map alphanumerically, rather than SmallDivide? Or even remember the last map used (after the first time, of course)?

beta 4 perhaps?

Windows unitsync stats:
http://www.darkstars.co.uk/linkcount.php

Recommendations for beta 4:

1. An integrated GUI for editing unitsync and spring executable locations in the settings tab. See Springlobby for an example

2. More information in main chat player list;
-Country icon
-away status


4. The battle lobby improvements:



Things like changing your ally and player ID (as we call them now) could be on the main tab.

Spectators should not have a "Not Ready" status, it can be somewhat confusing when hosting. You should either mark them as spec, or create a separate player list box (see supcom battle lobby) for spectators.

I also find there are too many tabs; features could be merged into the same tab, or brought over to the main tab.

Edit: Also, stop the player list in the battle lobby from scrolling down the bottom of the list every time there is an update to colours, ally, status....

spectators can be ready or not ready, tasclient just chooses to omit this.