Issue with Insane Limits with Procon Version (>=1.5.3.0)

[Prophet731]

We are aware of an issue with insane limits running on the latest procon version. The plugin doesn't work on the new .NET framework for some reason and we are still trying to figure it out. We have no timeframe on when this can be fixed due to IRL taking priority.

@ColColonCleaner and I will try to figure out a solution.

The issue is being discussed in the topic linked below. If you have any suggestions or a way to fix the problem please post it there.

 

View full article

[COREHQ Network]

Hi,

I have a workaround! You just need to change permissions for insanelimit.cs file and insanelimit  cfg file to 0777. This will solve the issue. 

Edited February 6, 2020 by COREHQ Network

[maxdralle]

@COREHQ Network

interessting, but the game provider g-portal does not allow to change the file permission. it is everytime the fix value 666.

[Uninstaller]

On 2/6/2020 at 4:17 AM, COREHQ Network said:

Hi,

I have a workaround! You just need to change permissions for insanelimit.cs file and insanelimit  cfg file to 0777. This will solve the issue. 

To be sure, we have to change permissions on  "insanelimit  .cfg" or "insanelimit  .conf" ?
Because on your screenshot it's "insanelimit  .conf" that we can see.

[COREHQ Network]

Definitely insanelimit_<ip_address>_<port>.conf file. 

[Hedius]

666 should be enough the files do not have to be executable. Everyone is allowed to read and write those files.

[Hodor]

Any fixes?????

[Prophet731]

On 2/20/2020 at 5:49 AM, Hodor said:

Any fixes?????

No, none yet.

[Hodor]

And how the hell then use Insane Limits on G-Portal hosting? Procon becomes useless! Why have you still not fixed the problem? @Prophet731

[ColColonCleaner]

I'll commit saturday afternoon to look into this.

[maxdralle]

after too many months of waiting i asked micovery (the good father of insane limits) for a solution...

[Hedius]

9 hours ago, Hodor said:

And how the hell then use Insane Limits on G-Portal hosting? Procon becomes useless! Why have you still not fixed the problem? @Prophet731

All of us have a real life. This is not a company. We are doing this during our free time. I started with debugging, but well: I have not done anything for 3 weeks and I also cannot share anything useful. I just do not have the time at the moment.... Same applies to many other members of this forum...

Edited March 12, 2020 by Hedius

[Prophet731]

after too many months of waiting i asked micovery (the good father of insane limits) for a solution...

And did he come up with anything on the issue?

Sent from my ONEPLUS A5010 using Tapatalk

[ColColonCleaner]

On my local instance it appears to be functional, but that could be because of the permissions. My permissions dialog on win10 is very different from the one you are seeing.

Is it just g-portal that have made this restriction or have other providers done it too?

[maxdralle]

On 3/12/2020 at 11:35 PM, Prophet731 said:

And did he come up with anything on the issue?

still not.

17 hours ago, ColColonCleaner said:

On my local instance it appears to be functional, but that could be because of the permissions. My permissions dialog on win10 is very different from the one you are seeing.

on my local pc, laptop and VM it does also not work (win 7).

Edited March 16, 2020 by maxdralle

[maxdralle]

update to the IL fix: i dont hear anything from micovery since a week :/

[Dr_Malle]

I also had a look at this tonight.

It seems to be a problem with the generated insanelimits.dll. This is also the reason why it works fine as soon as one takes the dll from the older version of procon.

In the old version, the file and product version of the dll are set to 0.0.0.0 whereas in the new version the file and product version are blank.

This causes problems since the references assembly is looking for a 0.0.0.0 version dll.

 

I did try to circumvent the problem by adding a wildcard assembly version in the buildLimitSource method like this:

@"using System.Reflection;
[assembly: AssemblyVersion(" + "\"" + "*" + "\"" + @")] 
directly added above the namespace PRoConEvents.

 

However, this leads to an error as wildcards are by default not allowed anymore. There is a switch for this, called "deterministic" which was earlier always false by default but is now true.

This is discussed here: https://developercommunity.visualstudio.com/content/problem/311322/the-specified-version-string-contains-wildcards-so.html

 

I did not find a way yet to set this deterministic value to false for the parameters.CompilerOptions in GenerateCompilerParameters() method. It seems like those MSBuild properties do not get recognized by the compiler.

 

As I see it there is two solutions:

1) Change the way Procon generates the plugin dlls and set file and product version to 0.0.0.0 as in previous versions.

2)  Find a way to disable the determinstic flag for the compiler inside insane limits (if this is even possible)