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.
3 replies on “AFLobby Progress Report”
That unexplained reason may be a stray Devil.dll in system32 – I had this problem and lost half a day on it.
I’m ipmrseesd. You’ve really raised the bar with that.
The odd thing is when I read that, I messaged satirik about a devil.dll in system32, and he fed be a story how braindamage had told him and he fixed it and aflobby worked on his system, despite braindamage not having a clue what I was talking about. =s
It’s a shame smoths out of action for a while.