Archive for January, 2008

My Official Stance on the Music AI

Tuesday, January 29th, 2008

A while ago I wrote a proof of concept group AI. It used the windows MCI APIs to play MP3 files based on what was happening in the game, thus generating dynamic music playback.

This was hardly the ideal situation. My feeble attempts at looking into FFMPEG weren’t too thorough and in the end I spent ~4 hours in the early hours of the morning building the simplest example I could with the easiest API I could find.

As a result of using MCI, there’s no volume controls so no fading the music out. The group AI setup also means I can’t tell the difference between canceling a construction project and having a building blown up or a self destruct sequence. These are the two main criticisms of the AI.

With version 3 of the AI, I provided it as is, and didn’t have much time to repackage it with all the music or work on it much longer. This is when Tired stepped up to repackage it himself. Tired put effort into drawing up a lua widget to auto-enable the AI too,although who he bankrolled into this job or if he did it himself I am unaware of.

My official stance

Since that moment I have dropped maintenance of the AI. I haven’t the time or resources to actively maintain more projects than I have despite a constant influx of new work. Although I do take on new projects from time to time, I am far more selective at the present, and I am always looking to delegate responsibility to someone who can take better care of a project, such as the music AI.

There is also the question of the Ogg Vorbis lua playback support added by kloot to 0.76b1. Although some people have complained about its playback quality in comparison to the Music AI, I still believe it is a useful thing to have since the music AI is confined to Microsoft Operating Systems by the MCI API.

Why doesn’t it work anymore?

When new versions of spring are released, the AI interface changes slightly. As a result what an AI expects to see is not what an AI gets, and when the two interact they break. To combat this spring refuses to load AIs built with the wrong AI interface version. This si why the 0.75b2 AI won’t work with 0.76b1.

So how do I get it working?

To fix this someone needs to recompile the AI using mingw32 and 0.76b1 source code. I do not have the necessary time and resources to set up mignw32 and code blocks and compile everything at the moment.

If anyone is interested in building the AI and releasing it I can provide source code and a codeblocks project. I haven’t a clue how to go about using scons for it so don’t ask me about that.I do have a few minor changes to it to make to clean up the MCI wrapper class but functionally it is identical to version 3.

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 Progress

Saturday, January 12th, 2008

I have been implementing the new protocol specifications, and correcting GUI issues since my last post. Sadly I have not been paying spring as much attention as usual but thats due to University, and impending coursework deadline monopolizing my time among other things.

Of note would be the new lua mod and map options. Other lobbies have added these but have made no or little attempt to take advantage of the necessary changes, resulting in perhaps an extra tab as in tasclients case. Whereas I however have decided to take full advantage of this opportunity to breathe a little life into the battlewindow.

Thus I present the beginnings of the new way of setting and viewing game options, lua and nonlua:

AFLobby options

All the nonlua controls will be removed in favour of this approach rather than being left in as cruft for the sake of it. Map and mod options will be distinguishable via icons when completed, and eventually modder definable images for each option. In the far future a search option would be available, but don’t expect a search box for many months just yet.

I currently have checkboxes/boolean options implemented. I now need to tie in lua unitsync functions and create the other option type UIs for the list.

As it stands I have implemented client side support for options so desyncs should not occur, however the visual representation in the list is a todo. Hostside implementation is limited to those items in the list that where in 0.75b2.