Kicked Off (Battleye: Public Variable Restriction #0)

[RC_Robio]

Ok cheers.

 

I'm pretty sure everything is correct though. GSP made the install in the TCADMIN panel running on our dedi.

 

It doesn't happen ALL the time. Just occasionally after a restart. It renames the publicvar.txt to publicvar.txt.original and then creates a new one.

I can't help with GSP install. You need to send your GSP a ticket.  

[RC_Robio]

Man, I suck at doing videos. If you want to jump on my ts, I walk you through it. 192.99.38.40, or if you want me to jump on yours.

[matrixmark]

Whoever installs it is irrelevant.

 

They would have followed the instructions / guides given from the website.

 

These kicks have nothing to do with them otherwise it would happen all the time.

 

Currently atm its around every 2 or 3 restarts it will for some unknown reason rename the original publicvariable.txt to publicvariablr.txt.original. It will then create another default publicvariable.txt which is then what gets us kicked.

[LouD]

I run several other servers myself without any service provider.

The server runs fine and everything works except the admin menu because of the BE filters.

[LouD]

The log files in the BattlEye folder keep filling up with normal ingame things. Is this how it's meant to be?

[uniflare]

No you should get any logs AFAIK if vanilla and setup correctly. Also, it is supposed to overwrite the public variable.txt., it does this as variables are generated at restart. So it needs to tell be what the new filters are each restart. Make sure your using the latest server pbo and DLL.

[LouD]

No you should get any logs AFAIK if vanilla and setup correctly. Also, it is supposed to overwrite the public variable.txt., it does this as variables are generated at restart. So it needs to tell be what the new filters are each restart. Make sure your using the latest server pbo and DLL.

That's the thing.

I downloaded the latest files from the website and used them. All paths are set correct.

[RC_Robio]

Whoever installs it is irrelevant.

 

They would have followed the instructions / guides given from the website.

 

These kicks have nothing to do with them otherwise it would happen all the time.

 

Currently atm its around every 2 or 3 restarts it will for some unknown reason rename the original publicvariable.txt to publicvariablr.txt.original. It will then create another default publicvariable.txt which is then what gets us kicked.

The publicvariable.txt is rewritten at EVERY restart with random vars. And will continue to do so no matter how many restarts. The idea is to create a random var each restart so script kiddes can't bypass it. Like I said if you are getting kicked then you made a mistake somewhere in setting it up.

[Steven1230]

The publicvariable.txt is rewritten at EVERY restart with random vars. And will continue to do so no matter how many restarts. The idea is to create a random var each restart so script kiddes can't bypass it. Like I said if you are getting kicked then you made a mistake somewhere in setting it up.

 

I am on a different server host and getting this same exact problem. The publicvariable rewriting is causing the built in admin panel to become worthless. I finally got tired of going back in after every restart to fix the issue just so we could admin my server. I finally just used BEC to help with kicks and bans. It is not the Server host that has the issue it is how the rewriting is happening. The original needs to have the acceptation for the built in Admin panel or there is no need for it to even be in the mod at all. There are over a dozen threads around the web with this issue going on with the publicvariable restriction #0. So it can not be the hosting sites failing to install it correctly.

 

Sorry if i seem irritated but I am after spending days trying to fix this and it just gets rewritten over and over and over.

 

EDIT: I just noticed the change log for 0.2.5.2 so that makes me a bit more happy to see what is fixed with the kicking.

[Fixed] False publicVariable kicks that happen since the ArmA 3 update 1.36.

[LouD]

Well, I removed my whole SC dir and recopied it from the zip file and it seems to work now. Will test more tonight.

Still getting all sorts of logs though.

 

Selectplayer:

12.12.2014 16:25:46: **** (****:2304) ****- #0 2:938 Epoch_Male_F 2141193850 [2401,5088,87]

Addmagazinecargo:

12.12.2014 16:26:35: **** (****:2304) **** - #0 "FAK" 0:0

All kinds of value restrictions in the publicvariable log but no kicks. And logs in the createvehicle one. 

[RC_Robio]

Well, I removed my whole SC dir and recopied it from the zip file and it seems to work now. Will test more tonight.

Still getting all sorts of logs though.

 

Selectplayer:

12.12.2014 16:25:46: **** (****:2304) ****- #0 2:938 Epoch_Male_F 2141193850 [2401,5088,87]

Addmagazinecargo:

12.12.2014 16:26:35: **** (****:2304) **** - #0 "FAK" 0:0

All kinds of value restrictions in the publicvariable log but no kicks. And logs in the createvehicle one. 

You will get logs. Anytime a player adds an item to something it creates a log. If you use Notepad++ and document monitor and open up createvehicle.log, attachto, or many of the others you can watch the logs be updated live and get a sense of what each filter does.

 

 

I am on a different server host and getting this same exact problem. The publicvariable rewriting is causing the built in admin panel to become worthless. I finally got tired of going back in after every restart to fix the issue just so we could admin my server. I finally just used BEC to help with kicks and bans. It is not the Server host that has the issue it is how the rewriting is happening. The original needs to have the acceptation for the built in Admin panel or there is no need for it to even be in the mod at all. There are over a dozen threads around the web with this issue going on with the publicvariable restriction #0. So it can not be the hosting sites failing to install it correctly.

 

Sorry if i seem irritated but I am after spending days trying to fix this and it just gets rewritten over and over and over.

 

EDIT: I just noticed the change log for 0.2.5.2 so that makes me a bit more happy to see what is fixed with the kicking.

[Fixed] False publicVariable kicks that happen since the ArmA 3 update 1.36.

Which host? Had problems with GTX at first. But it was blamed on their TCAdmin panel and permission settings. And I still don't know if they have gotten it totally fixed.

[Steven1230]

You will get logs. Anytime a player adds an item to something it creates a log. If you use Notepad++ and document monitor and open up createvehicle.log, attachto, or many of the others you can watch the logs be updated live and get a sense of what each filter does.

 

Which host? Had problems with GTX at first. But it was blamed on their TCAdmin panel and permission settings. And I still don't know if they have gotten it totally fixed.

 

I'm on survivalservers.

[RC_Robio]

If you know that your paths, passwords, admin's are all set correctly then I would take it up with them. 

[matrixmark]

Sigh I wish the staff would stop blaming it on GSP's and us.

 

It was all set up exactly as instructed via the install guides.

 

The default public var that it comes with works FINE it's the one that is put in on restart that doesnt work.

 

If i delete the publicvariable.txt and rename the publicvariable.txt.orginal back to publicvariable.txt it works fine.

 

Please stop trying to move the blame on to others and accept that their is a problem here and it needs to be dealt with.

 

[Fixed] False publicVariable kicks that happen since the ArmA 3 update 1.36.

 

lol....I wonder....

[RC_Robio]

Sigh I wish the staff would stop blaming it on GSP's and us.

 

It was all set up exactly as instructed via the install guides.

 

The default public var that it comes with works FINE it's the one that is put in on restart that doesnt work.

 

If i delete the publicvariable.txt and rename the publicvariable.txt.orginal back to publicvariable.txt it works fine.

 

Please stop trying to move the blame on to others and accept that their is a problem here and it needs to be dealt with.

 

 

 

lol....I wonder....

There are hundreds of servers that have been running fine with the 1.36 update. I installed my server after the 1.36 update and yet have not had any issues. Not here to lay blame to anyone. Simply stating that if you know your setting are correct and you are on a GSP that sending them a ticket to check your settings could help you in the long run.

[matrixmark]

Not really. They will just tell us to come here and post about it.

 

Which I've done.

 

I'm not the only one having these issues either.

[RC_Robio]

Post your settings for redis.conf, epochServer.ini, epochAH.hpp, Bec config.cfg, a Bec log file, and and a recent rpt.  x out your steam id's and whatever else you want hidden.

[reaperz73]

Ok guys for the publicvariable #0 kick, I have found that adding -autoInit to my startup parameters has fixed the issue for me, I have not had to modify any filters at all and I am not getting any publicvariable kicks.

Mileage may vary but for me it seems to work , I guess because it loads the mission before any players join and the variables get modified by the server dll before any players join.

Hope this may help you guys.

[uniflare]

Ok guys for the publicvariable #0 kick, I have found that adding -autoInit to my startup parameters has fixed the issue for me, I have not had to modify any filters at all and I am not getting any publicvariable kicks.

Mileage may vary but for me it seems to work , I guess because it loads the mission before any players join and the variables get modified by the server dll before any players join.

Hope this may help you guys.

Nice, I actually looked for this but I missed it in the wiki. So thanks, I kinda want to use this. Will add to the FAQ also when I got time.

Cheers

[TekHunter]

Ok guys for the publicvariable #0 kick, I have found that adding -autoInit to my startup parameters ........

I had this sorted and tonight it started happening again found this and added it..........fixed !

[matrixmark]

Ok guys for the publicvariable #0 kick, I have found that adding -autoInit to my startup parameters has fixed the issue for me, I have not had to modify any filters at all and I am not getting any publicvariable kicks.

Mileage may vary but for me it seems to work , I guess because it loads the mission before any players join and the variables get modified by the server dll before any players join.

Hope this may help you guys.

 

Sadly it didn't work. Sure enough on the next restart.... boom publicvariable #0 kick.

 

 
14.12.2014 08:47:48: Mortis (**.*.***.***:2302) ********************************* - #0 "eegtpillbcoydzsnjplykgpjiap" = ["Map to Teleport",2,<NULL-object>,"edzeyvtazukowvmfdohyqsdik"]
 

 

On trying to activate the click map to teleport option... It does this crap on every restart. This is getting rediculous now. Getting kicked for using EPOCHS OWN ADMIN MENU.......

[TekHunter]

After experiencing this issue on and off It seems to be a random occurrence after a restart here is what I have learned If you do a server restart and it renames the original publicvariable.txt and than makes a new one when you do something from the admin menu you will get the error , so if after a restart I notice this happens. I just delete the newly created publicvariable.txt file and change back to the original file and restart again it seems to work every time. So to recap if on a restart you notice the original file was renamed and a new one created you will get the error.

[uniflare]

After experiencing this issue on and off It seems to be a random occurrence after a restart here is what I have learned If you do a server restart and it renames the original publicvariable.txt and than makes a new one when you do something from the admin menu you will get the error , so if after a restart I notice this happens. I just delete the newly created publicvariable.txt file and change back to the original file and restart again it seems to work every time. So to recap if on a restart you notice the original file was renamed and a new one created you will get the error.

My public variable file is overwritten every restart. And I have no problems. If your using the same file with no changes every time then its not generating/changing the variables in game. So check you unblocked the DLL etc.

[matrixmark]

What .dll are you referring to.

 

I have gone through most of them and they are unblocked as far as I can see when viewing the properties.

 

 

 

 

 

I'm running this on a dedicated machine with TCADMIN. I know it's not an issue with that but meh might be worth mentioning.

 

Edit: just had the 4pm restart and again publicvariable kicks when it comes back up. I have to delete the publicvariable.txt and rename the publicvariable.txt.original back to publicvariable.txt before it will work again.

 

sighhhh it's making it hard to keep people in the server when this shit keeps happening. Please fix it.

Edited December 14, 2014 by matrixmark

[TekHunter]

My public variable file is overwritten every restart. And I have no problems. If your using the same file with no changes every time then its not generating/changing the variables in game. So check you unblocked the DLL etc.

 

Let me be more specific, Yes mine is also overwritten every time BUT not every time does it create a backup of the original and change the extension to .txt.original (or something like that) when that latter happens the error occurs.