TPW MODS: enhanced realism and immersion for Arma 3 SP.

[Valken 622]

Awesome work TPW! Now if STEAM would FINALLY validate ARMA 3 (AGAIN!!) then I can play with the new versions. That fog mist looks fantastic.

[Jimmakos 168]

Thanks so much tpw for the update,cant wait to try the new fog effect!

 

Keep up!

[tpw 2315]

Tanoa suspicions...

 

I just thought I'd take a break from mod coding to air my suspicions about Tanoa. Since the moment it was released to dev a few weeks ago I was struck by how visually similar to coastal North Queensland it appeared. My suspicions were further aroused when I started hearing Kookaburras laughing in the jungle. The penny finally dropped when I was walking along a back road and saw this sign for bloody crossing wombats! 

 

 

So what do you reckon, is Tanoa really a South Pacific archipelago or a mysterious Australian island off the coast of Cairns?!

[kremator 1065]

Hey tpw, 

 

Just tried out the new fog and I'm finding something wierd with it.  Depending where you LOOK it changes in density, and when you look back to the original direction even that has changed.  Are these particles physically bound to the map (when they are spawned), as generation on the fly seems really strange?  Next, does the fog block AI view as well?

[Jimmakos 168]

Hey tpw, 

 

Just tried out the new fog and I'm finding something wierd with it.  Depending where you LOOK it changes in density, and when you look back to the original direction even that has changed.  Are these particles physically bound to the map (when they are spawned), as generation on the fly seems really strange?  Next, does the fog block AI view as well?

 

Yeah it looked a bit weird for me too, when i first tried it but when i changed this to that:

 

tpw_fog_mist = 0.05

everything looked smoother and nicer.

[kremator 1065]

Yeah but I am running 0.05 so that can't be the solution.

[emerald 8 10]

Is there anyway you could make this mod self-installing?

 

I bet we all would love that.

[gliptal 25]

TPW SETTINGS [2.3.4] Download link

 

- parameters matching CARS [1.46] PARK [1.15] FOG [1.39]

[EO 11277]

For a first iteration, the ground mist system looks and performs very well, played around with the settings for a while and found your recommendation of 0.5 to be a sweet spot, and given that there are so many factors at play (dewpoint calculations, weather conditions, time of day, map position) the results are pretty spectacular.

And once your in mission and focusing on AI rather than the mist itself, the overall effect just blends into the background, very sweet and subtle.  Great work.

[das attorney 858]

Hi Tris,

 

I was looking at how you did your civvie scripts and noticed there's something you could add to make it a bit safer.

 

At the moment in tpw_civs.sqf - tpw_civ_fnc_civspawn, there's no check for if an empty group is available so you could reach the 144 groups for civ and then your function fails as there's no free group to put the civ into.

 

You could put something like this prior to the createGroup command to abort if none are free (I checked for 130 max here to give it some leeway with other mods/scripts etc)

if ({side _x isEqualTo civilian} count allGroups > 130) exitWith {};

Hope that helps mate.

[kremator 1065]

You trying to melt you machine again DA with 14 groups :)

[tpw 2315]

Thanks guys.

 

Kremator you've noticed the primary problem with Arma particles, in that they appear to change position and alpha depending on the direction of your gaze. Larger particles tend to exacerbate the problem. I've tried to find a compromise by using a particle size around 30m. Much larger than this really amplifies the effect, and much smaller means I have to spawn many more particles which kills FPS. 

 

Das, thanks very much for that. I actually did initially implement something similar for TPW CROWD where there was a risk of running up against the 144 group limit. In the end I just put all civs in a single group which works fine and cuts down CPU usage. I guess there might be someone playing Arma in their spare time on a NASA quantum supercomputer that could run 144 full simulation enabled civs at 60 fps. So for their sake I'll have a look at reimplementing it.

 

emerald8 there actually is an installer script provided in the download which will install TPW MODS and its config to the correct locations.Then all you have to do is select it in the A3 launcher and you're golden. Or am I missing something?

 

EO, thanks very much for the feedback. Whenever I first develop a mod I spend  a lot of time running around checking that it works, how it looks and performs etc etc. Eventually the novelty wears off and it just becomes part of the game world. My intention is that people only notice my mods when they're not activated!

[das attorney 858]

Das, thanks very much for that. I actually did initially implement something similar for TPW CROWD where there was a risk of running up against the 144 group limit. In the end I just put all civs in a single group which works fine and cuts down CPU usage. I guess there might be someone playing Arma in their spare time on a NASA quantum supercomputer that could run 144 full simulation enabled civs at 60 fps. So for their sake I'll have a look at reimplementing it.

 

Ha ha - I would like to have a go on that computer!

 

I noticed it the other day when I was playing TPW with some other mods that did stuff with civilians as well and it ended up all falling down due to 144 max groups  :(

 

I wish this game either raised that limit or introduced some new sides to use as well.  It's really frustrating when you run out of relationships to use in the game - there could be some really cool stuff developed if there was more choice with who-is-friendly-to-who!

[tpw 2315]

Ha ha - I would like to have a go on that computer!

 

I noticed it the other day when I was playing TPW with some other mods that did stuff with civilians as well and it ended up all falling down due to 144 max groups   :(

 

I wish this game either raised that limit or introduced some new sides to use as well.  It's really frustrating when you run out of relationships to use in the game - there could be some really cool stuff developed if there was more choice with who-is-friendly-to-who!

There's actually a tpw_civ_maxciv setting which sets the upper limit to the number of civs that will spawn regardless of other settings. I've just added a hardcode limit of 100, so if some psycopath wanted 250 simulation enabled civs he'll be disappointed. 

[Jimmakos 168]

Hey tpw, i've been using some of your scripts (tpw_core, tpw_fog, tpw_rainfx) on one of my missions posted on the arma 3 workshop and i've got some people which they using the normal standalone version of your mod asking if they have to disable them before playing my mission as they are included and running as scripts over mine.

Basically i have no idea what they should do, are the standalones going to be overrided from the scripts while running on my mission or they are going to get corrupted?

Really appreciate any kind of help since you're the best person to ask.

 

BTW im getting this error from the tpw_core.sqf 

 

[taro8 806]

Hey TPW. I have a request: could you turn the skirmish part of the mod into a module with can be placed in the editor? I really loved the skirmish module in Arma 2 and your skirmish mod really scratches that itch. However I would like to have a control when it's on, preferably by turning it on rather then off, so it does not interfere with scenarios and such. Also, an addition of blacklist markers, so you can set up safe zones, would be great.

[dakaodo 52]

Jimmakos: That's probably b/c you implemented your TPW_core.sqf in your mission script prior to the latest TPW releases. TPW changed the parameter inputs, so now it takes an extra array for blacklisted strings of unit class names:

0 = [["RyanZombie"]] execvm "scripts\tpw_core.sqf";

 

For no zombies and no exclusions otherwise, use:

0 = [[]] execvm "scripts\tpw_core.sqf";

 

I used to get TPW civ spawns with Ryan's zombies liberally interspersed and behaving like civs but still being recognized as hostiles. With the above in my init.sqf and this for tpw_civs.sqf, I'm golden:

0 = [1,80,3,.5,4,50,1,20,15,0,["RyanZombie"]] execvm "scripts\tpw_civs.sqf";

 

(Other parameter notes vs. default: shorter delay before spawning, much tighter scanning radius, .5 = 2 civs / house. More efficiently places AI nearer player to be more likely observed, while conserving total number of AI units. Tends to work better in dense urban areas.)

 

I also had to edit skirmish.sqf to add an extra || or condition to blacklist the same string in the section for excluding VR and pilot men.

 

I'd also like to know about players running the mod version, but then joining my hosted server mission. TPW doesn't officially support MP aspects. I've tried running both for a test, but so far can't tell whether the mod inits first or the scripts init first. I'd imagine the last one to run overwrites the variables that were previously set. You might try setting some extreme parameter inputs for the mod/script versions of a single TPW component (e.g. setting HUD to on versus off, or parked cars to on versus off), and see which one is implemented last and stays running.

 

TPW: Your recent work on this has been nothing less than inspired. Some notes:

 

I edited your new custom car and park string lists in the parameters, for use with CUP civ and LOP:

 

0 = [100,100,80,20,20,["CUP_C_","RDS","_civ_"]] execvm "scripts\tpw_park.sqf";

0 = [5,800,3,30,0,["CUP_C_","RDS","_civ_"]] execvm "scripts\tpw_cars.sqf";
 

(Yes, I know my other parameters are crazy high. I wanted to see how close to an aggressive GTA-V level of AI/car spawning Arma 3 and your scripts could get, to really strive for a "bustling bazaar" feeling on Diyala or in downtown Kavala. The above plus 100 crowd and 20 civ works OK albeit with some noticeable pop-in spawning, so long as there is no combat going on. It probably suits some users' values of acceptable, since for comparison GTA V is ultra-aggressive about de/spawning people and vehicles within 10-20m of the player, and often just outside of the 120-degree player FOV)

 

"_civ_" is necessary, b/c using "LOP_" spawns in Leights' militia armed offroads and other paramilitary vehicles. "CUP_C" works like a charm.

 

I just experimented with skirmish.sqf for the first time (separate mission, not the GTA V experiment). My mission uses BLUFOR for player, but I wanted to 1) spawn in both hostile OPFOR and INDFOR GUER fighting each other, and 2) give OPFOR the air support. Possibly in conjunction with the other request about making this an editor module with parameter inputs, here are my thoughts:

0 = [4,4,1,0,500,1200,1,[0],[0],(30+random 60),"i_g_","i_g_","o_","o_","",""] execvm "scripts\tpw_skirmish.sqf";

 

multiple lines:

Changed side player == EAST //no effect other than to correctly set sidechat

Changed _grp = createGroup east;

Changed references to createGroup west to be createGroup resistance instead, and set squad member selection to string "i_g_" (which throws story units in there, but also medic, sharpshooter, etc. that are not prefixed "i_g_soldier_".

 

_planetype = selectRandom ["O_Plane_CAS_02_F","O_T_VTOL_02_infantry_F"];

Line 224: I set the CAS plane to randomly pick vehicle to spawn in as CAS.

ditto for _helitype and _uavtype (adding the new Apex UAV via selectRandom)

 

changed side specific behaviour on line ~940 to be _side == east.

 

Considering all the times I've utterly failed at scripting, this edit worked exactly as I planned on my first try.

 

Tried different ways ("o_truck") to make your script detect only all unarmed infantry vehicles (trucks, Ifrits, the new LSV), but gave up and hardcoded line ~1410 to be so that it completely ignores your _enemycarlist var:

 

[EAST,_enemyunitlist,["O_Truck_03_covered_F","O_Truck_03_transport_F","O_MRAP_02_F","O_LSV_02_unarmed_F"],_num] call tpw_skirmish_vehspawn;

 

I set normal patrol behavior to "GREEN" instead of "YELLOW," for safe style patrols instead of aware. Finally, I changed all the patrol and waypoint spawns to pick only 3 waypoints, but 700m radius. Not sure if it matters, but I was hoping to save a tiny amount of CPU time with fewer waypoints.

 

In doing so, I really got to understand the script better, and it's pretty amazing how it works. Overall, in my editing process, I felt like more parameter inputs for setting all 3 sides in conflict, optional vehicle / soldier arrays (nice use of defaults already, btw), sides, side-assignable CAS/artillery support, would have been a great aid. I also specifically wanted to strip NVGs and add gun flashlights, but that was a pretty simple:

 

_x linkItem "NVGoggles";
_x unlinkItem "NVGoggles";
_x linkItem "acc_flashlight";
 

The link/unlink is shorter than individual unlinkItem commands for every type of NVG now available. It overwrites whatever NVG the unit may start with (OPFOR, INDFOR, APEX, addon mods; probably won't work for the combo NVG helmets), then removes the new, forcibly-standard NVGoggles. Also, unlink does in one command what unassign/remove does in two commands. EDIT: on second thought, I probably could have used BIS_fnc_instring checking partial string "NVG" forEach assignedItems _unit.

Not sure if the fnc or the un/link hack would be faster.

 

Did this in 2 places for squads and for vehicle crews.

 

Anyway, those are my thoughts on using skirmish.sqf. Maybe it will or won't give you ideas on next additions/edits. Thank you again for all your script efforts!

 

Hey tpw, i've been using some of your scripts (tpw_core, tpw_fog, tpw_rainfx) on one of my missions posted on the arma 3 workshop and i've got some people which they using the normal standalone version of your mod asking if they have to disable them before playing my mission as they are included and running as scripts over mine.

Basically i have no idea what they should do, are the standalones going to be overrided from the scripts while running on my mission or they are going to get corrupted?

Really appreciate any kind of help since you're the best person to ask.

 

BTW im getting this error from the tpw_core.sqf 

 

[tpw 2315]

dakaodo, many thanks for taking the time for that awesome post. I really appreciate when people take the time to pass on detailed information like that. Part of the reason that I release the script versions is to give people and easy way to look under the bonnet as aspects of TPW MODS and perhaps change and improve things for their own use and share with others. So thanks again for doing just that. I'll try to address a few points

 

1 - Mods vs Script conflicts

Currently you can run either TPW MODS addon or the scripts, but not both at the same time. IF you have the addon and script both running simultaneously they'll both fight for the same variables etc. At best you'll get reduced performance, but usually things will just spaz out or crash.

 

Because I'm constantly developing TPW MODS, I usually am just running the script versions from a generic init file that I use on all maps. Once things are at a point I'm happy with then I fire up BinPBO and turn the whole lost into the addon. I then test the addon version. In my init I use

if !(isclass (configfile/"CfgPatches"/"TPW_MODS")) then 
{
run the script versions
};

So basically the addon version takes precedence over the script version, but not the other way round. There's currently no clean way to deactivate a currently running addon version of a TPW MOD, but I may be able to work out something.

 

As far as how people go running client versions of TPW MODS when connecting to a server running them also, I have no idea and no intention of finding out first hand due to my unapologetic total lack of interest in MP. Maybe someone can tell me :)

 

2 - SKIRMISH

Some very nice extensions to the skirmish concept you've demonstrated there. I'm glad you could get your head around my convoluted code, I may be disorganised in real life but I do insist on lots of comments in my code so I can remember what the !@#$ I have done! As I state in the readme for this mod, I have no real intentions of expanding it further to include indfor or more symmetrical combat, armour etc as I think there are more fully fleshed out systems that do it more comprehensively. That said, if you'd like to send me your modified script and parameters I'll have look and see whether the changes can be cleanly implemented. If so, you may just find yourself as a co-author with all the privileges that entails, such as endless members of your preferred sex lining up for your company, job offers from Bohemia/Ubisoft/Google/SpaceX, and quite possibly a nobel peace prize.

 

3- GTA de/spawm

I don't have the game but most games that do have crowds and other ambience tend to be pretty aggressive with the despawning. I tried to implement things intelligently, so that it doesn't happen right before the player's eyes, but it gets to the point where all the visibility and FOV checks are consuming more cycles than they're intended to save.

 

4 - Module version

Requests for this periodically pop up and strangely enough I never get round to doing it. My original design philosophy (and prerogative) was to have a system that just worked as soon as you loaded an empty map. So rather than activate individual mods with modules and their parameters, you can just deactivate individual mods with logics/triggers and their parameters. If the chorus of complaints gets too deafening then I may relent, but it's a lot of work at my end to enable people to achieve essentially the same end result. 

 

Thanks again for your input mate, I really appreciate it.

[dakaodo 52]

:D You mean I have to methodically edit and script my additions neatly, instead of leaving it as the horrific hack search/replace job I initially did?

 

OK, TPW, check your PM for a Pastebin link. I didn't know if it was cool to publicly share what I've edited.

0 = [2,2,2,2,2,2,500,1500,1,1,1,[0,1],[0,4],[0,6],(30+random 60),"b_","b_truck_01_transport","o_","o_truck_03_transport","i_","i_truck_02_transport",["B_Plane_CAS_01_F"],["B_Heli_Light_01_armed_F","B_Heli_Attack_01_F","B_T_VTOL_01_armed_F"],["B_UAV_02_CAS_F"],["O_Plane_CAS_02_F","O_T_VTOL_02_infantry_F"],["O_Heli_Light_02_F","O_Heli_Light_02_v2_F","O_Heli_Attack_02_F","O_Heli_Attack_02_black_F"],["O_UAV_02_CAS_F","O_T_UAV_04_CAS_F"],["I_plane_whatevs"],["I_heli_whatevs"],["I_UAV_whatevs"]] execvm "scripts\tpw_skirmish.sqf";

This is the altered script parameter line. The air support class names are optional, and unnecessary where a single default is required -- I just left them in to show what all the new parameters are.

 

With a couple paltry hours' work, I have successfully added a complete set of RESISTANCE faction variables, permitting the player to set parameters for all 3 sides at once in skirmish. Each side has its own set of variables for calling in CAS/helo/UAV/arty support. CAS/helo/UAV now each take an array of vehicle classname strings instead of single strings, good for randomizing between different types of air support (now you can have Little Birds AND Blackfoots randomly spawn in if helo support is called; not responsible for shenanigans if user enters VTOLs in for CAS or helo support -- seems iffy when used in helo support role). Please NOTE: I am still not great at scripting, so I couldn't figure out how to convert TPW's isClass config checks for the support classnames into a forEach _x loop for each string element of the support name arrays. So for now it's up to the user to correctly enter in valid classnames.

 

Simplified the shemagh replacement with a shorter hack that no longer checks side (irrelevant, since all sides have option to wear shemaghs).

 

Reverted my cheap hack back to TPW's previous number of waypoints -- didn't see real benefit, and the skirmish units failed to patrol into each other (resulting in a no-skirmish skirmish.sqf).

 

For anyone else interested in using this in MP to some limited extent, I THINK that the current use of global marker creation will mean that a player in any one side WEST/EAST/RESISTANCE will see all CAS/helo/UAV/arty markers for ALL sides' support calls. I'm rubbish at MP scripting, and even worse at dedi server scripting. So I'm going to quit while I'm ahead. Pending TPW's approval to share this, if someone else wants to pick up the torch and make this script a bit more MP-compatible, we would be appreciative!

 

 

I was getting some _unit undefined errors, but it turned out to be my overly aggressive check for excluding civilian units, causing the script to return an empty array of unit types when Syndikat was set as the type. So using "i_c_", "o_", "i_", "b_", "i_g_", etc. custom strings will still spawn all units of that faction but can now also result in having partisan faction civilians randomly attached to your skirmish spawned units. I haven't figured out a string check to exclude civs more thoroughly than the fnc_noncom check TPW already had in place.

 

While I'm pretty proud of slotting in and replicating your work fairly seamlessly, I could never have cooked up this script in the first place. One additional bit I'm proud of is I figured out how to count crew positions and randomize crew count up to that.

 

But while the helo support works, and I've confirmed multiple CAS bombing runs, I seem to have broken the UAV bomb strike. The only skirmish.sqf-related errors I get now are related to _plane undefined for the script section relating to the UAV. I can't figure it out:

EDIT: N/m, figured it out -- forgot to declare my new variable for being able to specify _uavtype string(s). There are now no skirmish.sqf errors thrown, and the drone strikes are glorious.

[Spock 12]

re: TPW_HUD

 

!!my_text markers don't seem to be working for me. everything else functions well.

 

also, for those with 2560x1080 screens, i've adjusted the lower right hud display and shrunk the icon text as follows:

tpw_hud_grd[] = {1,0.45,0.325,1}; // GRD = GPS grid coordinates.
tpw_hud_azt[] = {1,0.55,0.3252,1}; // AZT = azimuth (direction of gaze).
tpw_hud_asl[] = {1,0.65,0.3256,1}; // ASL = height above sea level. [1 = active ( 0 = inactive), 0.6 = X position, 0.45 = Y position, 1 = text size]
tpw_hud_hlt[] = {1,0.45,0.425,1}; // HLT= health.
tpw_hud_rng[] = {1,0.55,0.435,1}; // RNG = range to centre of player's gaze.
tpw_hud_tmp[] = {1,0.65,0.385,1}; // TMP = temperature (from TPW FOG) .
tpw_hud_prx[] = {1,0.55,0.38,1}; // PRX = display numbers of nearby units.
tpw_hud_vel[] = {1,0.65,0.445,1}; // VEL = speed of player (or player's vehicle).
tpw_hud_lmt[] = {1,0.45,0.475,1}; // LMT = local mean time.
tpw_hud_unit[] = {1,1,0.25,0.5}; // UNITS/MARKERS displayed on HUD, where 1 = active ( 0 = inactive), 1 = icon max size, 0.25 = icon min size, 0.75 = text size ( 1 = same size as HUD text).
tpw_hud_offset[] = {0.34,0.26}; // HUD offset. [x,y] -0.5 to 0.5
tpw_hud_scale = 0.9; // HUD scale. > 1 = larger
tpw_hud_textscale = 1; // HUD text scale. > 1 = larger 

hope that's useful for someone. :)

[dakaodo 52]

Re: TPW Fog, on the Tanoa map, blank mission with only my player unit, I see in Zeus view a boatload of Game Logics scattered around wherever I've been. These seem to coincide with when local fog was very dense, but I'm just speculating that your clean-up routine may not be picking up all the fog particles?

 

Steps to reproduce: start empty mission on Tanoa, sometime in June around 6:30 am, overcast 50% in case that matters. You can see more ground mist in the trees, exactly as intended. Around 7 or 8 am fog can really increase. Let the game run for maybe an hour or so (15 mins on 4x speed?).

 

TPW settings were default with mist set to 0.05 as recommended.

[tpw 2315]

re: TPW_HUD

 

!!my_text markers don't seem to be working for me. everything else functions well.

 

also, for those with 2560x1080 screens, i've adjusted the lower right hud display and shrunk the icon text as follows:

tpw_hud_grd[] = {1,0.45,0.325,1}; // GRD = GPS grid coordinates.
tpw_hud_azt[] = {1,0.55,0.3252,1}; // AZT = azimuth (direction of gaze).
tpw_hud_asl[] = {1,0.65,0.3256,1}; // ASL = height above sea level. [1 = active ( 0 = inactive), 0.6 = X position, 0.45 = Y position, 1 = text size]
tpw_hud_hlt[] = {1,0.45,0.425,1}; // HLT= health.
tpw_hud_rng[] = {1,0.55,0.435,1}; // RNG = range to centre of player's gaze.
tpw_hud_tmp[] = {1,0.65,0.385,1}; // TMP = temperature (from TPW FOG) .
tpw_hud_prx[] = {1,0.55,0.38,1}; // PRX = display numbers of nearby units.
tpw_hud_vel[] = {1,0.65,0.445,1}; // VEL = speed of player (or player's vehicle).
tpw_hud_lmt[] = {1,0.45,0.475,1}; // LMT = local mean time.
tpw_hud_unit[] = {1,1,0.25,0.5}; // UNITS/MARKERS displayed on HUD, where 1 = active ( 0 = inactive), 1 = icon max size, 0.25 = icon min size, 0.75 = text size ( 1 = same size as HUD text).
tpw_hud_offset[] = {0.34,0.26}; // HUD offset. [x,y] -0.5 to 0.5
tpw_hud_scale = 0.9; // HUD scale. > 1 = larger
tpw_hud_textscale = 1; // HUD text scale. > 1 = larger 

hope that's useful for someone. :)

Thanks speedway. The manually placed markers do actually work, but you have to make sure that they are "hd_objective" type markers, which look like a hand drawn circle with a cross through it. When you place a marker down manually by default it's a dot, so just press the down arrow once to get it to hd_objective.

 

 

dakaodo, thanks so much for sending the modified script and detailed description of your changes, it's really mind blowing. I'll be in touch when it's integrated in. Also, thanks for the heads up on the FOG logic bug, I've fixed that stupid oversight for the next release.

[taro8 806]

About the skirmish module: how about simple module that just starts the skirmish with settings defined in the userconfig, regardless if the skirmish is turned on in the config.

[dar 12]

Hey TPW, love your mods, especially the "Fall" module of the pack - I always have it active, since it is so much more immersive. Just finished the whole East Wind campaign with it doing its magic - amazing. However, I felt like jumping over to Tanoa with a friend of mine trying the new coop campaign and I noticed some issues that might be related to the "Fall" module when it is active alongside the new revive system introduced and implemented by BI. In detail, a player that has been hit and will fall from the bullet hit also gets incapacitated by the revive system - but he won't stay that way, because your fall module will let him regain control and start to get on his feet again, only to then die instantly without other players being able to revive him. Can you or somebody confirm this? Also, when turning the tpw_fall_player setting in the userconfig hpp to "0", players will actually still get knocked over by bullets, at least thats what I noticed in test runs in the editor. 

 

Now I know your mod is strictly focused on SP gameplay and not intended to work with revive systems and that stuff, but since it is an official BI system, and the new campaign is meant to be played in coop, I thought I'd give it a try and ask for a solution to this, or at least clarification. Thanks again for your modset, keep up the good work.

[tpw 2315]

Gday dar, thanks for the kind words and the heads up.

 

I've fixed the (stupid) player fall bug, it'll come out in the next release in a day or 2.

 

Re revive: you are right in that the vagaries of MP are beyond my particular concern, however I think there is a workaround. The newest version of FALL uses setunconscious to ragdoll hit units. This command is part of the revive system and may well be interfering. However you can force FALL to use the older style physx and animation style falls, which don't invoke setunconscious. tpw_fall_ragdoll = 1

 

Please try this and let me know how you go.