Page 42 of 49
Failing to load lobby solution
Posted: 30 Aug 2007, 11:08
by HeadHunter
There was a problem-AFLobby failed to load after a Setting up lobby position.

No error messages. :idea: Still when i cleared the minimaps folder it loaded ok. If it is your problem, try to make a simple bash script:
Code: Select all
cat aflobby.sh
rm /home/headhunter/.aflobby/minimaps/nightmare.smf.jpg
cd /usr/local/share/games/spring
/usr/java/jre1.6.0_01/bin/java -jar /home/headhunter/bin/aflobby/AFLobby.jar
Nightmare is the last map in lobby's load queue. I don't know why it is so, still it works.

PS:This script makes lobby to recreate minimap for the last map in its scan queue.

PPS:For some reason lobby is sometimes unable to send any string to server. I mean e.g. "/j main" or "brb change map please"
Still, the team and ally change messages are posted ok.
Posted: 30 Aug 2007, 19:18
by AF
stacktrace please
Posted: 01 Sep 2007, 23:54
by Relative
Just letting you know AF that the beta 3 pre-release 4 .zip file is corrupt.
Posted: 02 Sep 2007, 01:12
by Lippy
OOhh.. ye i got that too, downloaded pre-release 3 instead and forgot to mention it.
Posted: 02 Sep 2007, 01:22
by iamacup
removed from uf
Posted: 02 Sep 2007, 03:23
by AF
http://spring.unknown-files.net/file/35 ... release_7/
v5 anyone? EDIT*7?*
v5/4/3 ty to fix a settings.tdf loading bug in beta 3 pre-release. They also changed a few GUI elements for the better. Such as a vastly improved html layout for the player tab on the main page, and a proper layout for the player list in the battle as well as improved colours. They also included some re factoring, clean ups, and optimizations.
I recommend users use beta 3 pre-release instead of beta 2 final. It's much better and is much closer to tasclients full feature set than any other lobby save tasclient itself and its forks. There is very little I have yet to implement.
Right now I need to implement a sync column in the battle list, saving and loading of unit restrictions to a file, and moderator commands iirc. The number of people who use these features is tiny (and they're quite easy to implement). beta 3 pre-release has 98% of tasclients features, aswell as some more tasclient lacks, such as ForceFFA/FixTeams or draggable starting boxes with proper resize controls, smiley's, or the vastly improved GUI.
Installation of Beta 3 under Linux
Extract to an empty writeable folder (an old install of aflobby will mess this one up). You can extract it to your spring install but I do not recommend this. Once extracted open settings.tdf in the /lobby/aflobby/ sub folder, and modify the paths and file names of spring and unitsync.so if they're incorrect.
And that's it! Run
java -jar AFLobby.jar to start the lobby.
Installation of beta 3 under Windows
Extract to your spring folder (not a sub folder) such that AFLobby.jar and spring.exe are in the same place. And thats it.
To run aflobby, run
java -jar aflobby.jar from a command line/batch script. You can also run
javaw -jar aflobby.jar in a shortcut to prevent a command prompt popping up as long as you set the workign directory correctly. Depending on how your machine is set up you may be able to just double click on aflobby.jar in explorer to run it.
Troubleshooting
Q)Nothing happens when I run aflobby, and http://www.java.com is opened in my web browser
A)This is because your installed version of Java is too old, AFLobby needs Sun Java 6 or later to run. You can use java.com to retrieve the latest version of java.
Q)When I login there are no host or battle tabs
A)When AFLobby fails to load unitsync it shows an error message and then assumes the user just wishes to chat, disabling all battle related functions. This is o that users can use AFLobby as a chat client on a usb drive, or so that they can ask questions in #aflobby if they get an unsatisfied link error.
Posted: 02 Sep 2007, 15:22
by AF
Posted: 02 Sep 2007, 15:32
by Lippy
Mhhh... I think somethings messed up with my linux setup:
Code: Select all
java.lang.UnsupportedClassVersionError
at java.lang.VMClassLoader.nativeDefineClass (VMClassLoader.java)
at java.lang.VMClassLoader.defineClass (VMClassLoader.java:130)
at java.lang.ClassLoader.defineClass (ClassLoader.java:679)
at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:108)
at java.net.URLClassLoader.findClass (URLClassLoader.java:955)
at java.lang.ClassLoader.loadClass (ClassLoader.java:359)
at java.lang.ClassLoader$1.loadClass (ClassLoader.java:1333)
at java.lang.ClassLoader.loadClass (ClassLoader.java:310)
at java.lang.VirtualMachine.main (VirtualMachine.java:99)
I have Jre6 installed... whats am I doing wrong (I used to use aflobby all the time

)
EDIT:SOLUTION: For some reason /usr/bin/java was pointing to the wrong place, so i just linked to to the right java directory.
Posted: 02 Sep 2007, 15:36
by Relative
@AF
The image loading bugs are fixed for the most part, but smilies don't work.
Posted: 02 Sep 2007, 16:23
by Relative
http://pastebin.ca/678923
Also, I'm getting 50% CPU usage (100% on one core) whenever I exit (exited, kick, battle closed) the battle lobby window. This is 100% reproducible.
Also, the AFLobby icon doesn't appear on the window bar in gnome, just the standard java icon:
Edit: In battle lobby the number for player ID and ally to not display the correct number and does not correspond with the My team tab. Its always one less than its meant to be: Player ID 0 = 1, 2 =3, etc...
Posted: 03 Sep 2007, 10:05
by AF
Thankfully the NTai/C++ profiler debugger fiasco doesn't apply where aflobby is concerned.
According to Java the SetWorkingMod() call takes 1600ms or more to execute, which is not avoidable as it means a lot of work is being done by unitsync as it has to be reloaded. I've added an optimization so it wont reload unitsync and reset the working mod for the same mod twice in a row which means that after the first join/host itll be faster as long as you stick with the same mod.
Another performance eater was dispose() when closing the battle window. dispose() frees up all the native resources the window uses, and if I didn't call it then I'd have a 'memory leak' where the window remains in memory because the underlying native code running the Java OS still holds references to it meaning the garbage collector wont touch it.
To help the process I've set the window to non-visible before disposing but I'm not sure what good that'll do other than making the process cleaner.
I've also corrected some instances where images weren't flushed when finished with and graphics contexts not dispose which would mean a very slow and small incremental increase in the memory footprint over time.
And I've fixed the smiley's and window icons, they aren't critical anyway and don't really affect the ability to use it as a lobby.
I've also corrected a typo which meant that the windows unsatisfied link statistics where being opened in the web browser rather than being called in the background.
Posted: 03 Sep 2007, 16:57
by Relative
Well it seem almost everything is working fine now. The smilies and the window bar icon still don't work sadly.
There is, however, a bigger problem associated with running the client that creates an unnecessary barrier for new users. AFlobby requires that the working directory is the location of AFLobby.jar. However, aflobby doesn't specify the working directory when its started. This means it keeps the default working directory, which is the home folder (~/, or /home/*user*/).
This means if aflobby is either run by "double clicking" or a single command such as java -jar /path/to/AFLobby.jar its working directory is ~/ no matter where AFlobby is kept.
Code: Select all
java.io.FileNotFoundException: /home/rutter/lobby/aflobby/settings.tdf (No such file or directory)
This requires the user to either run aflobby in a terminal to change the working directory and then run, or create a custom script. For example I created a .desktop file to run o a script file that is linked to AFLobby with the correct commands:
Script file:
Code: Select all
#!/bin/sh
cd /home/rutter/Desktop/AFLB3WIP8 && java -jar AFLobby.jar
Although I could be completely wrong about this

Posted: 03 Sep 2007, 17:40
by AF
Well under windows that problem vanishes yet for some reason things are different under Linux.
If I run aflobby.jar, how do I retrieve the location to that file programatically without user intervention, config files, command line parameters, or pre-defined install locations?
Posted: 03 Sep 2007, 17:43
by CoolyOriginal
Unsatisfied link error Make sure you have a JNI aware UnitSync library, and that it is compiled correctly. Such a library should come as standard with spring 0.75+. If under linux, check that you've correctly edited the tags in settings.tdf to point to unitsync.so and spring. AFlobby needs the unitsync library to be able to use spring. Linux users need unitsync.so Windows users need unitsync.dll Apple Mac users need unitsync.dylib (Mac is not entirely supported and upto date mac builds of unitsync arent included due to time restrictions) Expecting an absolute path of the library: path variable = /home/cooly library path = /usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client:/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386:/usr/lib/jvm/java-6-sun-1.6.0.00/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib
This is the error what i do now ???

Posted: 03 Sep 2007, 17:47
by Relative
CoolyOriginal wrote:Unsatisfied link error Make sure you have a JNI aware UnitSync library, and that it is compiled correctly. Such a library should come as standard with spring 0.75+. If under linux, check that you've correctly edited the tags in settings.tdf to point to unitsync.so and spring. AFlobby needs the unitsync library to be able to use spring. Linux users need unitsync.so Windows users need unitsync.dll Apple Mac users need unitsync.dylib (Mac is not entirely supported and upto date mac builds of unitsync arent included due to time restrictions) Expecting an absolute path of the library: path variable = /home/cooly library path = /usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client:/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386:/usr/lib/jvm/java-6-sun-1.6.0.00/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib
This is the error what i do now ???

You need to edit the settings.tdf to your unitsync.so
The settings.tdf is located in /lobby/aflobby/ of aflobby's files. Try copying mine and see if it works:
Code: Select all
....
unitsyncpath=/usr/share/games/spring/unitsync.so;
....
Then run in the terminal my command to start aflobby, but modified to suite your setup:
cd /home/
*user*/path/to/aflobby/ && java -jar AFLobby.jar
Posted: 03 Sep 2007, 17:52
by koshi
AF wrote:Well under windows that problem vanishes yet for some reason things are different under Linux.
If I run aflobby.jar, how do I retrieve the location to that file programatically without user intervention, config files, command line parameters, or pre-defined install locations?
should do it, but i've only used it on a windows box
Posted: 03 Sep 2007, 17:53
by CoolyOriginal
Posted: 03 Sep 2007, 17:54
by Relative
Is there one in:
/usr/local/share/games/spring ?
Posted: 03 Sep 2007, 17:59
by Relative
Or:
/usr/lib/spring
Posted: 03 Sep 2007, 18:02
by CoolyOriginal
i have copy it to /usr/share/games/spring
but the error stills