madrussian 347 Posted October 23, 2008 After thinking long and hard about zombies in ArmA and OFP, it occurred to me that while at first these missions are usually tense and exciting, after a while you realize that you can simply outrun the zombies.  Often the result is that things become tedious. A number of zombie missions have invented creative ways to combat this by keeping the players in a certain area.  For instance, Zombie Outbreak Simulation for OFP (ZOS for short and the greatest zombie mission of all time imo) had you geared up in NBC suits, traversing into towns and villages to locate survivors, and then calling in teams of trucks that would enter the zone, load up the survivors, and extract them.  All the while,  survivors were continuously attacked and infected, exponentially increasing the ranks of the ravenous pool of zombies.  Even the intro was excellent- On TV, the outbreak was explained by a realistically distraught news-caster. The mechanism of keeping the players in place in ZOS was that once a group of survivors was located and the extraction team was called in, there was a period of time while the truck was in-route that the survivors were vulnerable.  Your job as the player was to keep those survivors alive until the trucks got there and loaded them up.  (I’m simplifying this slightly.)  Highly creative and it served well to produce a compelling reason to stay in one place (at least until the last survivor was hauled off). The problem that came into play, however, was that the survivors just had to just sit there for all this to work.  This was highly unrealistic… who would just stay put in the face of an oncoming horde of zombies?!? In various other zombie missions, I’ve seen artificial boundaries introduced, where if the player leaves the boundaries, they lose the mission.  Not very realistic either.  IMO… A groundbreaking improvement for zombie mission makers everywhere would be a realistic fatigue system so that the players cannot simply run circles around the zombies. I have mastered changing the speed of various animations in the config, and seek to create an appropriate system to keep players afraid for their lives when the zombie start coming.  However, I’m having a bit of trouble. The blueprint for my fatigue system is to have the player’s speed degrade over time the longer they run.  Then as they rest a while, their stamina comes back and they can run full speed again until they get tired again, etc.  The zombies, on the other hand, are dead or infected, and so they undergo little or no speed degradation.  At the same time, perhaps they do not run as fast as the player when he is at full speed.  You see where this is going… eventually if the player is on the run, he will be overwhelmed and eaten alive. Now vanilla ArmA already has speed degradation built in, but I am having a devil of a time affecting it in the config. =============== Here’s the question: =============== After doing some tests, I have discovered some interesting facts (testing vanilla): 1. The speed command only gives forward speed (in km/h). 2. If you want to see speed in other directions, a special script is required.  Check out mine at the end of this post. 3. Player speed (while going forward) will degrade after sprinting for a long time.  4. Diagonal speed will never degrade.  This can be used as an exploit.  (i.e. when you get too tired and botton out going forward, start going diagonally.)  I have written an addon (not released yet) to address this (read on). 5. Forward speed will degrade, but only to 17.7 km/h (measured by my script, which I am using for all measurements) With that information, I started doing some experimentation in the config (in CfgMovesMaleSdr).  Here are my observations: 1. This item is good news: I am able to affect the amount of time it takes for speed to degrade while going forward.  (This is governed by duty) 2. The problem with the diagonal sprints is that the degradation cutoff is incorrectly based on a forward speed of 17.7.  When you are going diagonal in vanilla, you are already going slower than 17.7 km/h forward.  Thus no degradation.  Thus the exploit. 3. I cannot seem to affect this 17.7 floor cutoff for speed degradation, no matter what I change!  (all my changes have been in CfgMovesMaleSdr.) That #3 is the killer… Does anyone have any information that might help? Btw-  My workaround addon for the diagonals exploit is to only allow sprinting diagonal speed of 17.7, so players cannot run faster than the 17.7 in any direction after they are tired.  It does work, but like I said it's really a workaround. If I could lower the firm 17.7 km/h cutoff for degradation, we could really see a decent fatigue system.  And hopefully some great new zombie carnage! Also, if anyone understands exactly what relSpeedMin and relSpeedMax do, please provide a detailed explanation. Here’s my speed detection script.  It detect's ArmA speed command speed, any-direction speed, and also animation. Some of you may find it very useful for various applications. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ; _speed is in KM/Hr ; LongCalc and ShortCalc have both been tested and give the same correct results ; ShortCalc also gives an average speed since movement started ; LongCalc now considered obsolete _loop = "ShortCalcLoop" ;_loop = "LongCalcLoop" ;_loop = "JustAnimLoop" ?(_loop == "JustAnimLoop"): _delayS = 0.01; goto "JustAnimLoop" _speedThresh = 1 _minIters = 2 _delayS = 1 _delayM = _delayS/60 _delayH = _delayM/60 _iters = 0 _speedsTot = 0 _samples = 0 _avg = "N/A" _prevPos = position player ?(_loop == "ShortCalcLoop"): goto "ShortCalcLoop" #LongCalcLoop _curPos = position player _distM = [_prevPos,_curPos] call DistancePos _distKM = _distM / 1000 _speed = _distKM / _delayH _prevPos = _curPos hint format ["%1\nSpeed (F): %2\nSpeed (T): %3", animationState player, speed player, _speed] ~_delayS ?(true): goto "LongCalcLoop" #ShortCalcLoop _curPos = position player _distM = [_prevPos,_curPos] call DistancePos _speed = _distM / _delayS * 3.6 _prevPos = _curPos ?(_speed > _speedThresh): _iters = _iters + 1 ?((_speed > _speedThresh) and (_iters>_minIters)): _speedsTot = _speedsTot + _speed; _samples = _samples + 1; _avg = _speedsTot / _samples ?(_speed <= _speedThresh): _iters = 0; _speedsTot = 0; _samples = 0; _avg = "N/A" hint format ["%1\nSpeed (F): %2\nSpeed (T): %3\nSamples: %4\nAvg: %5", animationState player, speed player, _speed, _samples, _avg] ~_delayS ?(true): goto "ShortCalcLoop" #JustAnimLoop hint format ["%1",animationState player] ~_delayS ?(true): goto "JustAnimLoop" Share this post Link to post Share on other sites