Unitsync library is no longer compatible with SPADS

[TurBoss]

Hi

My autohost worked fine with my maps <---- ( not true anymore) (based on map-blueprint and mapconvng) but having some other maps like "TMA-0 v1_1" break the bot

starting the bot:

NOTICE   - [SPADS] Initializing SPADS 0.11.39
/usr/bin/perl: symbol lookup error: /home/spring/spads-develop/PerlUnitSync.so: undefined symbol: GetMapWidth

thx!

[FabriceFABS]

Same problem here on [ACE]Synchronous that hostes BAR-CD + SpringRTS 103-282DEV. This problem doesn't occurs with earliers ENG versions (As I rememeber 103~100DEV) should work.

[abma]

https://github.com/spring/spring/commit/a1f8bb55da2174ff196be3641a9dc93a65cde662

edit:

this is maybe more useful (the code was already disabled in the commit above)

https://github.com/spring/spring/commit/0806c632fb2268c03d0c4206403469e04e4e6e31

[Yaribz]

Current dev builds of Spring contain changes in the unitsync library interface which break backward compatibility.

And as I explained to hokomoko (I could copy-paste our pm here for the details if he agrees), updating SPADS to be compatible with the new interface would be very simple, but making SPADS compatible with both versions at the same time isn't exactly straightforward. hokomoko proposed to try to workaround the issue 2 months ago but I have no news about that since then.

SPADS needs to be compatible with older Spring versions, because they are still used by lots of games, and I don't want to maintain separate versions of SPADS for different engine versions so I won't fix that for now.

[ashdnazg]

As @Yaribz mentioned, I didn't work on this at all. I do promise that I will make sure things work before 104.0 is out.

[TurBoss]

thx!

[TurBoss]

Plz notify here when its fixed

thx

[FabriceFABS]

Thank you !, same for notification plz TurBoss / Hoko.

[Teteros]

@Yaribz @ashdnazg Any progress on this?

Asking because Chobby (as a menu) depends on newest engine so SPADS cannot currently host for Chobby.

[Yaribz]

Sorry, no change is planned at SPADS side concerning this and I don't know what's planned/done at SpringRTS engine side.

[specing]

Mine attempt receives missing symbol GetMapGravity

NOTICE - [SpadsInstaller] Checking Perl Unitsync interface module CRITICAL - [SpadsInstaller] Unable to load Perl Unitsync interface module (Can't load './PerlUnitSync.so' for module PerlUnitSync: ./PerlUnitSync.so: undefined symbol: GetMapGravity at /usr/lib64/perl5/5.22.3/x86_64-linux/DynaLoader.pm line 193, line 3. at PerlUnitSync.pm line 11. Compilation failed in require at (eval 40) line 2, line 3. BEGIN failed--compilation aborted at (eval 40) line 2, line 3.

What is the latest engine SHA before breakage was introduced?

[abma]

https://github.com/spring/spring/commit/a1f8bb55da2174ff196be3641a9dc93a65cde662 is the first commit where the deprecated functions are disabled as default.

( the code was removed in https://github.com/spring/spring/commit/0806c632fb2268c03d0c4206403469e04e4e6e31 which has some hints which function(s) should be used instead)

in this case GetMapInfoCount() + GetInfo*()

[specing]

Hmm, that is too old.

How are we supposed to host new engine versions? At least one S44 developer/contributor would need them as 103.0 does not fit the bill.

[abma]

in spring 101 the GetMapInfoCount() stuff was added: https://github.com/spring/spring/commit/606a88b3d8731bc94a88ecdeb1cc594180ae0ace

the majority of current autohosts use spring 103. Supporting Spring 101.0 to the current development version is IMO fine.

[Teteros]

If you are willing to compile the engine yourself, one hacky workaround atm is to git revert a1f8bb5 and 0806c63.

Alternatively you may patch -Np1 < this.patch https://gist.github.com/Teteros/c1e5d468eaf3e0c613b8d8cede0ac685 instead.

Then compile with ENABLE_DEPRECATED_FUNCTIONS e.g.

    cmake . \
        -DENABLE_STREFLOP=NO \
        -DENABLE_DEPRECATED_FUNCTIONS=YES \
        -DAI_TYPES=NONE \
        -DBUILD_spring-headless=NO \
        -DBUILD_spring-legacy=NO \
        -DNO_SOUND=YES \
    make

for spring-dedicated only build, since this propably woudn't sync (especially with streflop off)

NOTE As with any (git) engine change: If you do this, to be consistent with buildbot versions/compiles you will need to make sure to checkout the develop branch and keep the hash the same as your desired engine hash/version.

This is because if the .git folder is present, the cmake scripts will use that for versioning. You can remove the .git folder and manually set engine version via the VERSION file before building. e.g. echo "$(git describe --long --abbrev=7)" develop > VERSION See my full build script if you wish (albeit redact any arm stuff, that's not working :c)

Lastly, remember to rebuild perl UnitSync once you have spring-dedicated and libunitsync.so (spadsInstaller.pl -g) (instructions for linux, refer to spring docs for windows since I'm unfamiliar with that build environment)

Apologies for this lenghty post. I've figured this may be helpful to someone as it has been brought up in #sy channel yesterday. @FabriceFABS @TurBoss @specing

I could be totally wrong in some of these, in my short-test this worked. In-game untested, YMMV

[Yaribz]

Thank you for this workaround, it should be useful for those who want to host latest SpringRTS versions with SPADS. However this workaround is only necessary for the unitsync library building part, not really for spring-dedicated which still can be built directly from official sources or taken from official static packages.

[specing]

I've been hosting latest engine for a good week and it seems to be working, but no major games have been played there. In my understanding of the affected code, it is only an API that is used outside running games and thus should not prevent clients from syncing with the server even if the former are using an unpatched version. I did it similarly to the above:

git clone /var/portage/distfiles/git3-src/spring_spring.git/ cd spring_spring/ git checkout develop git revert 0806c632fb2268c03d0c4206403469e04e4e6e31 git revert a1f8bb55da2174ff196be3641a9dc93a65cde662 git format-patch -2 mkdir -p /etc/portage/patches/games-strategy/spring mv 000* /etc/portage/patches/games-strategy/spring/ cd .. rm -rf spring_spring/

emerge '=games-strategy/spring-20170612'

ebuild: https://paste.pound-python.org/show/Z5z7bMKNO29OpN93n1Zg/

It integrates well with Gentoo's user patching, but you might need to add some lines at the start of src_configure or something to get it to pull them in (For that I have a system-wide script for all packages).

[specing]

Hmm, I was thinking... while we are at this, what if SPADS had a generic engine wrapper? i.e. a new config entry called wrapper for a library that would wrap a particular engine interface for SPADS use? Then SPADS could both ship several wrappers and provide instructions on how to make your own wrappers.

Thinking forward, this would move SPADS to be a generic game hosting program, not just for spring engine based games.

[ForbodingAngel]

I'd rather it just worked properly in the first place tbh

[Yaribz]

A generic engine wrapper would be interesting, but it's much more work than I can offer atm unfortunately.

ashdnazg's patch has been applied to contrib SPADS release, so I close this issue.

[TurBoss]

Thanks!

[springjools]

The contrib patch cannot change engine versions on the fly like the unstable versions can. So for now we should stay away from any versions past 103.0, or it will corrupt unitsync?

[Yaribz]

All standard SPADS releases (stable/testing/unstable) are now compatible with all Spring versions, there is no need to use the contrib release anymore.