Hellop

I think this is a very important point and something that I completely overlooked. Your suggestion is to not use server-side global variables to store game state information. However using script-scoped variables would require a certain script that just runs in a loop all the time and never exits. I don't have any infinite loops in my mission yet, and I'd like to keep it that way. What I have in mind to prevent hackers from being able to change values on the server using publicVariable is to have the server randomly generate names of the global variables. Now that will require parsing the scripts and replacing the variable names. Even though concepts like that are un-heard of in most programming languages, it's something that I've always wanted, and thankfully BI provides this functionality with the "call compile format" command. This ability would be synonymous with a java program that altered it's own source code then re-compiled it with javac then ran it. Back to the player money example: When the client gets some money, it needs to tell the server. It runs the "sendToServer publicVariable command" which is basically a public variable scalar value that contains information identifying the sending client, which "PV function" to run, and the data. It would look something like this: "Player15, DepositMoneyFunction, $1000". Now, the DepositMoneyFunction has been altered at mission start so that the name of the server-side global variable that holds the bank-balance information for each player has been changed to a randomly generated name. So, on the server the function is called like this: [15, 1000] call DepositMoneyFunction; Then inside the script would be something like this: kd93kd72sk set [_this select 0, _this select 1]; //kd93kd72sk is the randomly generated name of the array that holds the bank balances for all the players. Inside the DepositMoneyFunction is where you can put your hack-detection checks, and/or logging. In this way, the clients will never know the names of the server's global variables and cannot alter them. This is probably confusing, but if mission designers can use this information in any way to reduce hacking, that would be great. I would be happy to discuss this further with anyone.

MadDogX, thank you for the detailed reply. It seems to me that using setVehicleInit as a replacement for public variable is not desirable. It's not what it is meant for. Most likely, it was designed to be run one time for each vehicle. It seems unpredictable and redundant to use it for network communication. It seems to me that the desired way for initlines to be run for JIP players, is for the initline to run one time for each vehicle, for whatever the initline happens to be at the time the JIP client joins. But it seems like what you are telling me is that when a JIP client joins every single initline code is run for every single time processInitCommands was run. I can't imagine what the purpose of that is. I don't suggest using setVehicleInit in this manner. Furthermore, the whole concept of publicVariable of "global" variables that can be altered by any client at any time doesn't seem desirable to me either. Because, you do not have control over what your current state is. To overcome this, I use publicVariable in a different way. I simulate a client/server architecture and allow a certain limited number of "commands" to be run. In this environment there is no such thing as a global variable, and the server alone keeps track of the state of the game. This technique, I think, adds to reliability by reducing the possibility of race conditions, and improves performance by reducing polling.

Crowe, can you discuss why using setVehicleInit with code is better then using publicVariable and the new publicVariableEventHandler? I'm guessing that your thinking is that instead telling the server of a state change like this: player5Money = 1000; publicVariable player5Money; You could do: player setVehicleInit "player5Money = 1000;"; processInitCommands; But, I'm not seeing how that's better. Thanks for your input, Crowe. -hellop

LOL, I have no anti-virus. I have a hardware firewall with ethereal tho...

Maybe a good way to stop cheaters would be to have some flags like you guys suggested... Some checks that determine that a client is doing something weird. That combined with player reporting, then: -Have a script that allows an admin to camera/watch players for cheating....

Part 1. Well, there's some news. Â That explains why BI decided to make Addons downloadable during mission join. Â *EDIT*: Sorry Yoma. Typo. That should read "why BI decided NOT to make Addons downloadable". Regardless, I guess the question is, why did BI decide not to let addons be downloadable when joining a server? *END EDIT* Question is, WHY are there executable programs inside an addon? Â then, HOW, can you make an .exe inside a .pbo run from Arma? Â <-- this feature needs to be eliminated. Part 2. Â Yoma, I still don't understand what you want to do. Â I think you want to figure out why you are getting errors in your .rpt. Â Do, client .pbos give you errors in your server .rpt? Â Can you explain your intentions more? Â BTW, you seem like a motivated and capable programmer... Fill this out please: 1. Problem Identification: Â e.g. "Client side .pbos generate hard to track errors." 2. Request for Proposals: Â "A way to find out which pbo generates the error" 3. Proposals: Proposal 1: Â ".pbo error/quality ratings" Proposal 2: Â "database of .pbos and MD5s" Â -doesn't bisign do this? Proposal 3: "database of unpacked pbo's to search for error output" Â -Shouldn't mission makers do this? Yoma, I'd like to help. Â And before you spend too much time... Â If you're talking about making some kind of 100MB online database I think you may be on the wrong track. Â We/You need to identify the problems better, and then maybe, we will figure out a suggestion that BI needs to put into Arma2 or a patch.... Â That will help everyone. Otherwise, I have access to servers and can host PHP/mysql...

Yes! Run a version of Arma that doesn't include Battle Eye, and Screenshots work fine. So, do we just post our Xfire name here, or do we add everyone elses name, or what? Now, once we get everyone on xfire, all we need is another forum to organize! -hellop ARMA XFIRE SCREENSHOT FIX. As I posted in the Able's Xfire thread.. The reason Xfire's screenshots are broken with the new version is Xfire is looking in the default directory for the Arma .exe, but since the patch, that .exe is located in the beta directory. To fix it, go to your games in Xfire and manually point Arma to your Arma install beta folder... Then screenshots work fine.

Arma 1.12b + Xfire working fine! I FIXED IT. So, contrary to popular opinion, Battle-eye doesn't seem to be breaking X-fire screenshots at all. You just have to manually configure X-fire to point to Arma's beta directory in Options-Games and X-fire starts working again.

Xfire Screenshots: Sorry if this has been answered already. Is there a way to turn off battle eye when I am just playing on my local computer, so that I can take screenshots? Is Battle Eye really needed if, for instance, I have no network connection? Thanks. Otherwise: A big thanks to the developers for trying to address the problem of idiotic cheaters/hackers/griefers. I just don't understand the point of "hacking" at all. Probably caused by the lack of a male role-model.

Yes! Run a version of Arma that doesn't include Battle Eye, and Screenshots work fine. So, do we just post our Xfire name here, or do we add everyone elses name, or what? Now, once we get everyone on xfire, all we need is another forum to organize! -hellop

FritzDaKat, Vista is your problem. I run 1280/1024 Max on a Pentium D 2.6Ghz with 1GB ram on XP with Arma 1.12 patch, 50-100FPS on local games. X1950Pro 256MB. Get rid of that nightmare called vista and see what your rig can do. Also, run no other programs.

wget http://www.armedassault.com/downloads/armalinuxserver-1.12beta.tar.bz2

Brit, I hope you will send those new cheats to Doolittle so he can update DooAcs.

That's a great idea! Perhaps the Practitioner of the Dark Arts could enchant a vehicle using voodoo. And the White Magic user could bless a vehicle with the holy rabbit foot of fortune. That would suck to have a slightly wounded devil tank following you around whispering "I will conveeeerrrt you to bio-diesel and buuurn you in my cylindarzzzzzz" Ok, I will definitely add that, keep up with the good ideas, MaxRiga.