Quote:
Originally Posted by EFFx
On the link constants, there are descriptions on how you set ip up to be able to connect. I thought it was enough for people to understand.
|
I'm not talking about URLs, I'm talking about the cURL module and its corresponding include file. It would be nice to know which version you've tested with and a quick way to download it.
Quote:
Originally Posted by EFFx
Think a little: the system downloads plugins automatically without you having to touch the server. Imagine you have 20 servers using 7 plugins you created. With this, you just upload all 7 plugins on your website and the system will download all updated plugins for all servers at once without you having to install them manually on all 20 servers. It helped me a while ago with a lot of plugins I built for users. Sometimes I lost the FTP data or had too much auto connections registered on File Zilla. With this all I had to do was update the plugin from my website and all servers got the plugin updated, saving me a lot of time.
|
I'm not sure I'd want 20 identical servers though . . . Not sure who would need that many identical servers. If, instead, you set up a system that would allow the server to identify itself and then grab a list of plugins specifically configured for that server, maybe it makes more sense. Something like a JSON file per server; I guess you could just change the JSON file URL (and maybe the others) into a cvar and that would actually implement that feature.
Quote:
Originally Posted by EFFx
To register any other file:
PHP Code:
{
"1":{
"pluginname": "Plugins Languages",
"filename": "translations.txt",
"directory": "addons/amxmodx/data/lang"
}
}
In this case, it will be always downloaded on every map start since there is no version or file size checking avaliable for me to use before the download feature to trigger.
So in the end:
cURL:
PHP Code:
{
"1":{
"pluginname": "Kill Display",
"filename": "killdisplay.amxx",
"directory": "addons/amxmodx/plugins",
"version": "1.1", // To trigger the download, I changed the previous version to the same version registered in register_plugin("Kill Display", "1.1", "EFFEX"), before it was 1.0
"licensecheck": false // this will ignore the IP check, everybody can update this plugin
},
"2":{
"pluginname": "Plugins Languages",
"filename": "translations.txt",
"directory": "addons/amxmodx/data/lang",
"licensecheck": false // this will ignore the IP check, everybody can update this .txt file
}
}
|
By file organization, I was referring to having to organize the files on your web server since not all plugins are downloaded as fully completed packages ready for copying directly into a server. For example, I was thinking of a file tree like this on the web server:
Code:
.
├── plugin1
│ ├── addons
│ │ └── amxmodx
│ │ ├── data
│ │ │ └── lang
│ │ │ └── plugin1.txt
│ │ └── plugins
│ │ └── plugin1.amxx
│ └── models
│ └── plugin1_specific_model.mdl
├── plugin2
│ ├── addons
│ │ └── amxmodx
│ │ └── plugins
│ │ └── plugin1.amxx
│ └── sound
│ └── plugin2_specific_sound.wav
Then, you would only need to configure for that plugin (and not all the files individually) and it would grab all files for that plugin. I didn't expect that you would need to list each individual file.
Overall, FYI, I was just trying to understand how this was supposed to be used (and for the sake of others), I'm not criticizing it.
__________________