Wrap unitsync to preserve compatibility

[ashdnazg]

19

I don't know perl, so I've figured it will be easier for you to adapt the wrapper code for linux.

[Yaribz]

Thank you, unfortunately the problem I was speaking about in issue #19 was mainly concerning linux, which is used by 90% of the autohosts. Indeed, on linux the Unitsync interface is statically generated using Swig so you can't add a wrapper easily as you did for the Windows case.

Sorry maybe I should have been more specific about what was problematic, but I though you were going to add a wrapper at Unitsync interface side, not at SPADS side. And I really didn't think you would start with the Windows Unitsync interface of SPADS :/

[ashdnazg]

The same code can be put on top of the linux SWIG interface, just the question is where.

[Yaribz]

On linux platform the PerlUnitSync wrapper is generated during installation, so the code you are looking for is here .

The problem is not really to put a wrapper on top of the interface, but to make SWIG generate a library which can be dynamically linked with both versions of the unitsync library.

[ashdnazg]

Wait, you want to switch unitsync versions without regenerating the glue? Is that even possible?

Anyway, I now have code which seems to mostly work on linux

[Yaribz]

Yes, switching unitsync version without regenerating the glue is required to be able to host simultaneously different games using different versions of the engine without having to install SPADS multiple times... That's exactly what I meant when I said "making SPADS compatible with both versions at the same time isn't exactly straightforward"

[ashdnazg]

Why can't you just keep using the latest version?

[Yaribz]

I suppose autohost owners use old Spring engine versions for games that aren't compatible with latest versions. For example currently there are 8 SPADS autohosts running Spring versions from 94.1 to 101.0, hosting games such as Conflict Terra, Imperial Winter, Journeywar, Planet Annihilation and Planet Defense.

[ashdnazg]

Yes, but what will happen if you run them while your script is linked with a newer unitsync? Where does it break?

[Yaribz]

It will show wrong Spring engine version in lobby and in report messages, so clients won't use the correct engine version when connecting to the games hosted by the autohost.

[ashdnazg]

Don't get spring version from unitsync, get it from the executable or something.

[ashdnazg]

Or just store it in config, it's really not worth it making insanely complex code just for the version. As far as I am concerned I did my part in enabling spads to work on any unitsync.

[Yaribz]

Compiling the unitsync library 103 so that it loads Spring 100 base content for example can be quite annoying. The location/instalDir of the library and the corresponding base content location are also relevant. And you can't expect an autohost admin who is only hosting Spring 100 for example to also have to compile the Spring 103 unitsync and place it in unitsync v100 location (so it loads exactly the same archives and base content) just for SPADS, it becomes insanely complex for the autohost admin...

Ok, thank you for your work, I will make it available in the contrib release of SPADS for those who are interested.

[nixtux]

Hi just a quick question, is it's already live if using contrib?

[nixtux]

hmm even using this patch over current contrib still errors with, /usr/bin/perl: symbol lookup error: /home/***/Desktop/spadsInstaller-test/PerlUnitSync.so: undefined symbol: GetMapWidth