To all lobby developers

[imbaczek]

Please test your lobby against unitsync from svn (the one installed by automated installers.) We need to know whether unitsync problems in svn are lobby-related (and/or lobby-fixable) or are simply bugs in unitsync and the new Lua parser.

current status:
TASClient (Satirik's version) - infinite ProcessUnits loop when trying to host

Code: Select all

unitsync initialized
unitsync: joining
adding archive: .\mods\BA561.sd7
adding archive: .\base\springcontent.sdz
adding archive: .\base\spring\bitmaps.sdz
adding archive: .\base\otacontent.sdz
adding archive: .\base\tatextures_v062.sdz
get side count: 
initfindvfs: SidePics\*.bmp
findfilesvfs: 0
syncer: process units
Loading all definitions:  1.600000
found 370 units
syncer: process units
Loading all definitions:  0.922000
found 370 units
syncer: process units
Loading all definitions:  0.906000
found 370 units
--- ad infinitum ---

springlobby svn 678 under Win XP - crashes when trying to host, after calculating map hashes (BTW there are some plugins for trac that allow reading git repos ^^)

Code: Select all

unitsync initialized
unitsync: hosting
adding archive: .\mods\BA561.sd7
adding archive: .\base\springcontent.sdz
adding archive: .\base\spring\bitmaps.sdz
adding archive: .\base\otacontent.sdz
adding archive: .\base\tatextures_v062.sdz
get side count: 

AFLobby beta 3.8 (more or less recent svn) - fails to create gui after connecting to server, but is responsive and can be closed

Code: Select all

unitsync initialized
unitsync: hosting
unitsync deinitialized
----

note that unitsync's logging isn't perfect, "get side count:" has a colon by mistake and there isn't any information that should be after that

[AF]

none of the lobbies should be able to connect, they should report that the spring version is unsupported and immediatly close or disconnect.

Processing Units uses an awkward iteration method, its not immediately clear as to the true usage and its very misleading.

Do you have a reliable link to a binary that isn't a 40MB installer dl?

[imbaczek]

Not to a localhost server (or http://www.osrts.info:8200.)

I could put up only unitsync somewhere, but it won't work, too much has changed (Lua defs parser, first and foremost.)

[imbaczek]

I think I found the bug that causes infinite loading; ProcessUnits was never returning 0, it does now. TASClient and springlobby r670 now can host a game just fine.

[BrainDamage]

Do you have a reliable link to a binary that isn't a 40MB installer dl?

http://www.osrts.info/~buildbot/spring/ is the spring buildbot base folder, if you look under build, you'll find the lastest uncompressed unitsync

spring bin has it's own folder

[AF]

no no no no no

You've fixed the loop error by introducing another error.

ProcessUnits() doesnt do all its processing in a single call, instead there are 2 functions.

1 parses and fills in unit data and then returns how many unprocesed units are left.

1 returns how many units have been processed (not how many units there are).

Look at CSync.java and javabind.cpp. I'll do so now and try to explain better when I have referenced it so Im crystal clear.

*looks around*

Code: Select all

/**
 * @brief process another unit and return how many are left to process
 * @return int The number of unprocessed units to be handled
 *
 * Call this function repeatedly untill it returns 0 before calling any other function related to units.
 */
DLL_EXPORT int __stdcall ProcessUnits(void)
{
	logOutput.Print("syncer: process units\n");
	return syncer->ProcessUnits();
}

So basically while(ProcessUnits > 0){}. Ironically it was me who wrote that doxygen comment in a patch a few weeks ago, and who advised the springlobby people as to how it all worked.

To be precise:

Code: Select all

        units.clear ();
        while(CUnitSyncJNIBindings.ProcessUnits ()>0){}
        unitcount = CUnitSyncJNIBindings.GetUnitCount ();
        for(int i = 0; i < unitcount; i++){
//            int i = CUnitSyncJNIBindings.GetUnitCount ();
            String s = CUnitSyncJNIBindings.GetUnitName (i);//+" - "+CUnitSyncJNIBindings.GetFullUnitName (i);
            //System.out.println(s);
            units.add (s);
        }

Taken from public static boolean SetWorkingMod (String modname){ in CSync.java

That is the expected behaviour, and yah it isnt ideal and yes it could have been written so that the loop was inside unitsync rather than making the lobby iterate instead.

[imbaczek]

ProcessUnits() doesnt do all its processing in a single call, instead there are 2 functions.

It does in 75b2. I have reasons to believe it doesn't in svn, that's why I asked lobby devs to *test* and *report* results. See unitsync/Syncer.cpp.

[BrainDamage]

sorry, can't test it much atm because i don't have the time to build unitsync, are you using a windows binary or are you building springlobby yourself?

in the case of the latter condition, you could locally merge my lobbycrashrept branch into the master and to be able to dump a stacktrace when it crashes

[AF]

If you can run aflobby, test it while running from a command line.

When unitsync crashes it will spit out a stack trace of the calls in aflobby and perhaps a little unitsync information. Run with the -verbose flag to catch all possible errors. That way you can determine which function unitsync crashes on and perhaps I can give your more details based on the stack trace.