PapaCharlie9 / insane-limits

PRoCon plugin Insane Limits by micovery
10 stars 9 forks source link

Improve plugin activation vs settings loading #40

Open PapaCharlie9 opened 11 years ago

PapaCharlie9 commented 11 years ago

The interlock between plugin activation and settings loading seems overly complicated. Signalling the activate_handle seems haphazard. In any case, there seems to be a timing problem that makes the test for Agreement == true fail. Users report these messages, which should be impossible if settings were loaded correctly:

[05:27:56 85] [Insane Limits] Enabled! [05:27:57 59] [Insane Limits] Thread(activator): Waiting for privacy_policy_agreement value [05:27:57 59] [Insane Limits] Thread(activator): WARNING: You must review and accept the Privacy Policy before plugin can be activated

Note that the waiting message and the warning message happened in the same second. That's only possible if someone Set the activate_handle before the wait. That would indicate that False was stored in the settings file. But then why does disableing/reenabling IL fix the problem (Agreement would have to be stored as True)?

Razer2015 commented 8 years ago

I solved why this was happening to the server I'm adming on (not sure if it's the case for all). The Insane Limits was working fine at first but then the server IP and Port changed and so the InsaneLimits config file IP/Port at boot changed aswell. Now every time the procon server is rebooted, it reads with the new IP and Port but that config is empty of course -> must accept the Privacy Policy.

However when you disable and enable the plugin, it reads the config file path from the Configs\ip_port\InsaneLimits.cfg and that points to the old config file and so it reads all the limits just fine.

I fixed it by changing the BASE64 encoded "limits_file" path to the new ip and port and then changing the InsaneLimits_ip_port.conf aswell. It's working just like it used to before :).

As said, I don't know if this is the problem for all but it was for me and it's working now.

I was debugging the line 11519 from version 0.9.17.0.