I and Turboss were thinking about how to make spads implement a !setengine command and we almost have it working.
One obstacle for doing this is that spads needs to generate unitsync wrapper for each engine. I think this perlunitsync.so needs to be placed in same directory as spads.pl. But does it have to be this way? Would it be possible to place unitsync in same directory as each engine?
Then you could have one spads installation that can run 50 different engines by just reconfiguring some paths in the conf. But is this possible?
[plugin] SetEngine
Moderators: Moderators, Lobby Developers, SPADS AutoHost
Re: SPADS AutoHost
Not necessarily. I think you can place it anywhere and configure your LD_LIBRARY_PATH to include this new path.Jools wrote:I think this perlunitsync.so needs to be placed in same directory as spads.pl. But does it have to be this way?
Re: SPADS AutoHost
Here's a plugin I did: it adds the following command:
[setengine]
!setengine <engine version|latest>. Will attempt to download unknown versions. Needs DownloadArchives plugin 0.5 or later
!setengine 98.0.1-353-gcae510f sets engine to version 98.0.1-353-gcae510f
!setengine latest sets engine to latest version in http://springrts.com/dl/buildbot/default/develop/
It finds the current engine from the path in spadsconfig, attemps to dl a new engine if it doesn't exist (looks for libunitsync.so and spring-dedicated) ands regenerates the perl unitsync module with spadsinstaller -g flag.
Here are some settings that need to be set/changed, in the conf file:
precedingstring:engine/
followingstring:/spring-dedicated
spadsconfname:spads-dev.conf
So it only works if the path to your engines is consistent. Also some versions spring don't contain spring-dedicated, so pr-downloader won't download it for those versions.
[setengine]
!setengine <engine version|latest>. Will attempt to download unknown versions. Needs DownloadArchives plugin 0.5 or later
!setengine 98.0.1-353-gcae510f sets engine to version 98.0.1-353-gcae510f
!setengine latest sets engine to latest version in http://springrts.com/dl/buildbot/default/develop/
It finds the current engine from the path in spadsconfig, attemps to dl a new engine if it doesn't exist (looks for libunitsync.so and spring-dedicated) ands regenerates the perl unitsync module with spadsinstaller -g flag.
Here are some settings that need to be set/changed, in the conf file:
precedingstring:engine/
followingstring:/spring-dedicated
spadsconfname:spads-dev.conf
So it only works if the path to your engines is consistent. Also some versions spring don't contain spring-dedicated, so pr-downloader won't download it for those versions.
Last edited by Jools on 10 May 2015, 14:29, edited 1 time in total.
Re: SPADS AutoHost
Thanks for sharing!
There are several problems with calling "use DownloadArchives;" directly as you did:
- it could try to load the corresponding Perl module directly if it's not loaded yet through the plugin infrastructure, thus failing sooner or later
- if the module isn't found it could fail with obscure error
- if the DownloadArchives plugin is unloaded afterward, your SetEngine plugin could crash
On the other hand, if you declare the getDependencies callback in your plugin, SPADS will perform all the necessary checks for you and ensure the dependencies are always loaded. Then you just need to use the getPlugin function to access to dependencies. For example:
There is a callback in the API to declare plugin dependencies: getDependencies()Jools wrote:Needs DownloadArchives plugin 0.5 or later
There are several problems with calling "use DownloadArchives;" directly as you did:
- it could try to load the corresponding Perl module directly if it's not loaded yet through the plugin infrastructure, thus failing sooner or later
- if the module isn't found it could fail with obscure error
- if the DownloadArchives plugin is unloaded afterward, your SetEngine plugin could crash
On the other hand, if you declare the getDependencies callback in your plugin, SPADS will perform all the necessary checks for you and ensure the dependencies are always loaded. Then you just need to use the getPlugin function to access to dependencies. For example:
Code: Select all
my $p_dlArchivesPlugin=getPlugin('DownloadArchives');
slog("Found DownloadArchives ".$p_dlArchivesPlugin->getVersion(),3);
Re: SPADS AutoHost
You're right. I tested it many times and it just fails with some error similar to "unable to instantiate plugin". I tested what happens and it's enough that the other module is present, it doesn't have to be loaded.
In the code, I use this way to check version:
So there is a message but it will only be output to log, not to the user.
But I will modify it to this other method of checking dependencies :)
In the code, I use this way to check version:
Code: Select all
sub new {
slog("Found DownloadArchives ".DownloadArchives::getVersion(),3);
die ("Sorry, this program needs DownloadArchives v.0.5 or later!") unless (DownloadArchives::getVersion()
>= 0.5);
But I will modify it to this other method of checking dependencies :)
Re: [plugin] SetEngine
Updated the dependency check as per advised logic.
Last edited by Jools on 10 May 2015, 14:29, edited 1 time in total.
Re: [plugin] SetEngine
Thanks, I see you changed the way you access the dependency to check the version number, you are now using getPlugin() which is good.
However you didn't define the getDependencies() callback to declare your dependency, which would be more failproof in my opinion as I explained.
However you didn't define the getDependencies() callback to declare your dependency, which would be more failproof in my opinion as I explained.
Re: [plugin] SetEngine
Here's a new version that also declares dependencies.
Last edited by Jools on 10 May 2015, 14:28, edited 1 time in total.
Re: [plugin] SetEngine
Nice, just one last thing I forgot to say: now that you are sure that the DownloadArchives plugin will always be loaded by SPADS before the SetEngine plugin, you should be able to remove the "use DownloadArchives;" line from the top of your plugin (using "use" on another plugin module can lead to obscure problems if any of the plugins is unloaded/reloaded).
Re: [plugin] SetEngine
Ok, here is updated version, now it works better:
By the way, maybe I can take these questions here: I always get this error output when starting spads:
Also one thing I don't get: why doesn't everyone just use the latest version of perl?
So it is better to use this latest version of the plugin, even if the previous versions will work under normal circumstances (that is you don't do anything weird, but you should not do that anyway :) )[15:52:51] <[PRO]Jools> !plugin DownloadArchives unload
[15:52:51] <[elderberry]Autohost> Unloaded plugins SetEngine,DownloadArchives.
By the way, maybe I can take these questions here: I always get this error output when starting spads:
I get that they are just stupid warnings, but I always have to scroll up/down when I restart spads to see relevant info, and isnt the command no warnings 'redefine'; supposed to stop those anyway?Subroutine AddBoxPolar::tan redefined at /usr/share/perl/5.20/Exporter.pm line 66. (like 20 times)
Use of uninitialized value in hash element at SpadsConf.pm line 771. (2 times)
Also one thing I don't get: why doesn't everyone just use the latest version of perl?
Last edited by Jools on 10 May 2015, 14:28, edited 1 time in total.
Re: [plugin] SetEngine
There are not necessarily stupid warnings... Concerning the AddBoxPolar::tan warnings, I don't see any "tan" definition in the plugin available here, do you use a different version? Concerning the "use of uninitialized value" I think it is due to at least one of your array config files having inconsistent data in it.Jools wrote:By the way, maybe I can take these questions here: I always get this error output when starting spads:
I get that they are just stupid warnings, but I always have to scroll up/down when I restart spads to see relevant info, and isnt the command no warnings 'redefine'; supposed to stop those anyway?Subroutine AddBoxPolar::tan redefined at /usr/share/perl/5.20/Exporter.pm line 66. (like 20 times)
Use of uninitialized value in hash element at SpadsConf.pm line 771. (2 times)
All Linux distro aren't updating their Perl packages that often. And people are lazy and don't want to update themselvesJools wrote:Also one thing I don't get: why doesn't everyone just use the latest version of perl?