Archive for the 'Glest' Category

AFLobby Beta 4.2

Saturday, March 8th, 2008

Not many changes here aside from a few minor tweaks inspired by gota, and a bugfix for the registration page crash reported on the glest forums.  An installer has also been uploaded.

Edit :: Since darkstars lost all its files not long ago Ive decided not to put this version back up as I think it would be detrimental to my work. Instead look forward to Beta 5.

AFLobby Beta 4.1 & Glest

Sunday, March 2nd, 2008

Aside from a few minor aesthetic tweaks to make her and there such as glest logos on glest battles to make them easier to pick out, AFLobby is pretty much ready to go. With the new Glest 3.1.1 supporting command line parameters, what a better time to go? Read the rest of this entry »

AFLobby beta 3.9.9-4 experimental

Sunday, January 20th, 2008

The recent update to 0.76b1 has introduced several protocol changes. One such change that wreaks havoc on the current stable AFLobby is the introduction of two new ranks with make AFLobby crash almost immediately. The other change is the introduction of SETSCRIPTTAGS and the deprecation of UPDATEBATTLEDETAILS. AFLobby 3.9.8.1 and several alpha versions of 3.9.9 do not support these new commands, and thus fall apart in the new server protocol environment.

To this end a working version of AFLobby is needed. Support for mod options has been added along with a pretty new GUI page for setting them.

This release is more of an in between of 3.9.9 and beta 4, and you’ll notice many changes.

Numerous UI components have been torn out and replaced with tables which run hundreds of times faster while eliminating rafts of bugs in the process. A lot of internal structures have changed too, increasing stability and overall speed, aswell as other speed ups to prevent the user thinking the program has frozen, such as loading messages on mini maps. The map browser on the main view has been removed as it was a silly thing to have there and added more tabs, the colours on the battles are gone, substance GUI updated, a proper swing window rather than swing controls in an old AWT window, there’re a lot of changes going on.

In other news, I’ve been differentiating this site a little more, so you may see a lot more in the way of blue diagonal stripes. A good dose of css and png transparency goes a long way.

AFLobby beta 3.9.9-4 experimental

AFLobby 3.9.9+ Progress & Glest

Wednesday, December 19th, 2007

Recently I’ve had a little more time than usual with aflobby. Of note are a slew of bug fixes and glest support.

I’ve corrected numerous aesthetic issues, including icons that stretch tabs, and windows that are still undecorated such as the warning window. The bundled Substance has been updated to 4.1 stable, and I’ve made other GUI tweaks to make minor improvements.

I will make clear that 3.9.9 will not support the svn protocol changes unless spring is released before 3.9.9.

A glest castleGlest Support?

Indeed, with the recent Glest 3 multi player alphas there’s been some talk over glest lobbies. Sadly martinho tried out the wrong lobby program and was repulsed by tasclient, resulting in official support being dropped. Nonetheless, unofficial support started. Hailstone has been working on patching glest to give external lobby support, and I can announce that the aflobby side support is now completed, and sitting in the spring svn.

So what does this involve?

Glest games in the lobby will use the ‘Glest’ mod to identify them from spring based games. Battles will then move into a battle room before the host launches the glest battle set-up screen. Details such as team numbers, spectator modes, maps or battle status are all to be ignored. Chat, player joins, exits, kicks, locks and launches are all that are needed.

More updates

I’ve also removed the html control with the clunky html tables on the player list tab. Instead it now uses a table control, so the whole thing is much faster and prettier.

Playerlist

AFLobby Progress Report

Sunday, December 9th, 2007

With the recent release of 3.9.8.1, I’d like to address the immediate future and what i want to do in the next month or two.

A unitsync workaround

Some people, mainly satiric and smoth, seem incapable of running aflobby properly due to a mysterious unitsync issue. For some unexplained reason unitsync refuses to load. Tests with satirik showed no error messages or causes, just a generic unitsync unsatisfied link error. Further tests showed he was able to load native OS libraries with JNA but not unitsync. What’s more this all happens under windows, and never happens under Linux when setup correctly. They all have the latest and greatest versions of everything too.

So, to get around this, Ill write a small program in C++/C that will load unitsync and output all the necessary information to a cache file. The archivecachev6.txt file already outputted by unitsync is incomplete and doesn’t contain the necessary info to run the lobby.

This way the lobby doesn’t need to bother with java unitsync troubles if it’s not supported.

Glest Support

The new Glest 3.0 alphas have multiplayer support. Thus I went over to the glest forums to offer my help with a lobby effort by opening up the spring lobby code base to them via aflobby. Spring lobby support was also offered by brain damage. Suffice to say, martinho did the worst thing he possibly could, he downloaded spring and tested out tasclient, then judged the 2 other lobbies based on the fuglyness that is tasclient. Obviously tasclient didn’t impress him and he decided not to bother with us, despite never running or seeing aflobby or spring lobby at all.

But work continued! At the moment glest users are forced to hand around IP addresses by hand via email or forums to pre-arrange games. Since official support was officially gone, unofficial support is now the answer. The glest community at large seems to support the notion of a glest lobby client, and some have contacted me and have been looking into an unnofficial patch to add lobby support.

In anticipation, the svn version of aflobby currently has very basic multiple engine support. Some minor re factoring to the BattleModel class is needed to separate it into two classes (IBattleModel and IGUIBattleModel), but support is around 70% complete. Thise code also means that the eventual TA3D support can be started with 60% of the work instantly done, as is the same for any other engine using the same startup mechanism.