My 2 bits

[DeltaUniform 3]

First and foremost, preventing hacks is easy, mostly dependent on how much thought was put into detection when the game was designed. Detecting an individual who has been hacked is even easier. It's a handful of if statements in a handful of functions that are called in a handful of other functions. These are expanded on and optimized as more and more hacks and exploits are learned.

The jist:

detectHack(_EVENT iEvent)

{

/****

* Detect a hack involving a player death

* TODO: Make each if statement a separate method

****

if(iEvent == _MURDER)

{

PlayerData *victim;

PlayerData *lastmurderer;

(_EVENTDEST)victim = iEvent.getDestination();

(_EVENTSRC)lastmurderer = iEvent.getSource();

if(distance(victim,lastmurderer) > _MAX_MURDER_DISTANCE)

{

// flag murderer's profile murder anomoly +1

// all hackers are innocent until proven guilty, and we have a function for that

hFlag(murderer, _MURDER_ANOMOLY, A_MAX_DIST);

// reset player to last known status before the time the event occured

resetPlayer(victim, iEvent->getTimeStamp);

}

if(distance(victim,lastmurderer) > getMaxWeaponDistance(murderer->getWeapon())

{

hFlag(murderer, _MURDER_ANOMOLY, A_MAX_WEAP_DIST);

resetPlayer(victim, iEvent->getTimeStamp);

}

if(lastmurderer.getAttributes(prev, 10)->isInvisible() == true)

{

// Get the murderer's status last report to server start 1ms before event

// if the player was invisible, flag invisible murder anomly and resurrect

hFlag(murderer, _MURDER_INVISIBLE, A_INVISIBLE_PLAYER);

resetPlayer(victim, iEvent->getTimeStamp);

}

and another

and another

and another

and as more hacks are created, more if statements and methods will be created

}

Your methods investigate every murder. Your server keeps track of player status every loop, caches this status for about 5 minutes, and you write methods who can use the last 5 minutes of events to see if what just happened is even possible.

First you wait for a key event... such as a player was just murdered, you call a given set of functions to investigate the death. If the death wasn't possible, flag the hacker and reset the victim.

You have another set of events that happen every 5 seconds, checking for ghost connections, and other anomolies

you have another set of events you run periodically to check for instance... did this player go from 2000 blood to 12000 blood and not eat anything? how many times has another player reported shooting this player? etc Etc...

Eventually you end up with a pretty complete set of checks and balances.

Why oh why would you develop a multiplayer game without putting checks and balances such as this into place?

[mironrijff@hotmail.com 41]

Becuase arma2 Runs on a trusting engine Wich was need meant for running a mmo like dayz.

It is intended to be a modifiable engine that doesn't limit possibilities.

[DeltaUniform 3]

Trust? Really?

[tazgecko 7]

yep, arma players tend to be more mature than the regular pvp peps. Flexibility and customization is one of its strengths. It just doesn't sit well with a mod like dayz. I can see why they will be pushing to get the standalone out soon and lock it down ...

[edit] - I shouldn't be taking the focus away from what you are doing, I like the idea :thumbsup:

Edited September 2, 2012 by tazgecko