John Kozak

I don't think so - there's an awful lot of traffic anyway... And it can be tweaked anyways. Are you saying JIP players will be aware of a variable which was published before they joined? If yes, broadcasting will not even be required

One advice is to build your mission logic (triggers) on public variables, not on triggers. Triggers are local (executed for each player separately), hence, for JIP players, they may not fire (because the conditions may have already changed). Public variables, on the other hands, can be synced. Example: Suppose I have a task "Get into boat" on the start of the mission. In singleplayer, what I'd do is just create a trigger like "{vehicle _x == myBoat} foreach [player1, player2, player3]" and sync it to the new Task module (Task Status => Completed). This works fine in SP/non-JIP coop. But when a player joins later - all players might have already quit the boat, so the task will stay uncompleted for him. Solution: Create two triggers. One has the same condition as before, but instead of being synced to the task module, it has the following in Activation: DW_Global_BoatTaskCompleted = true; publicVariable "DW_Global_BoatTaskCompleted"; And the second trigger has the variable DW_Global_BoatTaskCompleted in condition instead of "this" and is synced to the task module. I don't remember wheether public variables are automatically broadcast to JIP players upon joining, but if they're not, it can be fixed in one simple script: if (isServer) then { _null = spawn { while {true} do { {publicVariable _x} foreach ["myVar1","myVar2","myVar3",...]; sleep 1; } } }

Nope, it's a fact. When something already exists, and then new problems are introduced (even if someone considers them insignificant) - it's called "quality was reduced" ;)

Well, opinions are opinions, but the fact remains - it will create a few bugs and decrease the overall quality of the mod (which is great at the moment). As for this: My main use-case is to play random missions downloaded from Steam/ArmAholic - solo or with friends. Having to edit each mission to use the mod effectively nullifies the mod's value - I'll just go rampant and disable it after tenth mission :) So, if it's changed in later versions, I'll just stick with version 2.5 (current). Dixi.

Yes, I agree there is no perfect solution - unless BIS adds a separate slot for the facewear. However, IMHO, doing that would be creating several other problems by fixing one. For example: NV Goggles would no longer be visible, as you already said. Many scripts can possibly break (because they check for NVGoggles item specifically) (my guess)Wearing one will require you to pick it up each mission/each respawn - which means it can be used only in missions specifically designed for it For me, having goggles on top of the facewear does not outweigh the shortfalls :) Since making two variants is indeed not practical, I opt for the old one. At the moment the mod feels realy polished and non-intrusive - changing it to NV slot will break that. That's up to Cunico to decide, OFC. But I'd stick with the old version then - it's awesome enough :D

Please don't :( It will prevents the player from wearing NVGs just to use it - everyone will just not use it for this reason. Also, one will lose the ability to customize it in the player profile.

Yes, basically it's how it should be done. Ideally, there would be several checks for various body points (because, for example, player might be partially hidden behind a light pole => simple centerbody shielding check will give a false negative). Without it, direct shrapnel simulation is more accurate here - because it can hit any part of a character not hidden - but yeah, it'll be awfully expensive :) I doubt the full check of the first type will be implemented, though. I got a feeling they'll stick with current design for a while.

Okay, let me explain this part... First off, let's do a small classification. Historically, there are two main types of grenades: offensive and defensive. Defensive grenades are thrown from cover and have small number of heavy high-energy fragments, which give an effective radius of 30-40m. Prolific example: F1 grenade. Note the cuts on the grenade casing - it will always produce 30-something fragments Offensive ones are designed to have limited range and more-or-less constant shrapnel density in hit sphere. For this reason, they use fragmentating wire or small steel balls (or casing with large number of cuts) to produce small fragments which quickly lose velocity in air, resulting in effective radius of 10-15 meters. Examples: M67 grenade, Russian RGN (Ð ÑƒÑ‡Ð½Ð°Ñ Ð“Ñ€Ð°Ð½Ð°Ñ‚Ð° ÐаÑÑ‚ÑƒÐ¿Ð°Ñ‚ÐµÐ»ÑŒÐ½Ð°Ñ - Offensive Hand Grenade) These two types give us two distinct patterns: Small-fragment burst: can be modelled as a sphere, originating with a small radius at the moment of explosion and extending with the fragments flying; this means, any target will be hit with the number of shrapnel proportional to its solid angle as viewed from the center of explosion and with energy of each fragment inversely proportional to square of distance. Large-fragment burst: limited number or fragments evenly distributed on sphere. Here, distribution of individual pieces starts to matter. Let's test your model on both cases: 1.Test on small fragment burst Let's imagine 5 targets standing at 2, 5 or 10 meters from explosion in the open. Your model gives some fixed probability for each target to be hit - which will leave some targets unscathed. This obviously won't happen - as there is a lot of fragments flying all around. All targets will be hit more or less equally. Correct model must hit every target (as distribution is spherical) and calculate penetration and damage based on the energy of hit - i.e. body armor will not withstand the fragments up close, but will be able to stop them at distance. 2.Test on large fragment burst This case is a little bit more complex. Let's first perform a thought experiment with simplified terms. The setup would be as follows: Custom-made IED with 3 fragments flying with 120 degrees offset in horizontal plane 6 targets standing evenly around the IED (60 degrees offset), numbered clockwise (sorry, can't attach a picture from workplace) When such a device explodes, we'll have one of two cases: Targets 1, 3 and 5 are hit Targets 2, 4 and 6 are hit The probability that each individual target hit is, hence, 1/2. However, what's certainly not possible is that targets 1, 2 and 3 are hit and three other targets are not. This is what the catch with probability simulation is: your model treats events "target 1 is hit" and "target 2 is hit" as two independent events. However, in reality they are dependent on each other. If there is one fragment in a given solid angle section, it will hit only one target and can't hit two. That's what I meant by the phrase on effective shrapnel pieces number - suddenly, there spawns many pieces where only one should be. The case with a real grenade and real target configurations is much more complex, of course. But using a naive probability model (as you described) is going to give a lot of WTF factor where there shouldn't be (example - throwing a grenade into a group of soldiers will kill all the soldiers west of it, but leave all on the east unharmed).

Yes, I agree that probabilistic model would be better. BUT not the probabilistic model DMarkwick described - because it's just plain wrong, as I demonstrated above. Doing a proper statistical model isn't as simple as saying "okay, let's say X happens in Y% of cases". There are distributions, mean values, correlations, etc.. Problem is, it's very hard to get right - as demonstrated in the above example. Imagine one more lineage of bugs adding to the already rich on that ArmA. Plus, there are old grendades like RGO and M26, which produce small number of heavy shrapnel pieces. RGO's shrapnel can (with low probability) hit targets at a distance of 100m - imagine that. And with such cases, "proper" simulation is just plain better - because it (surprisingly) would require less calculations.

If you have probability 0.5 and 10 objects near grenade, you have 5 hits (5 effective pieces of shrapnel) on average. If you have probability 0.5 and 100 objects near grenade, you have 50 hits (50 effective pieces of shrapnel) on average. Sorry, but you didn't even understand what I'm talking about. Read again.

I agree with it, but then it must be correspondingly simulated. Let the wheels have some slip - and there'll be totally another feeling to it... Right now it seems like the vehicles are powered by budget-credit-car engines.

Well... That's a bad idea, because: 1.Number of effective shrapnel pieces will be dependent on the number of objects around 2.When there is a lot of objects in the radius, the amount of data to process is even more than that in case of "honest" simulation 3.The distribution of shrapnel will look strange - it will look like it's a self-guided machinegun, not a grenade :) Because the shrapnel will only fly towards hittable targets. So, no, I'm voting for "honest" simulation with reduced number of pieces. ArmA 2 engine handled shotguns with ~20 pellets pretty well. I suppose 20-30 would not be a large performance hit. P.S. I don't remember much problems with ACE2 either - setting aside the general slowness due to a lot of scripts executed each frame, fragmentation mines behaved really good.

No, actually, there is. Random chance won't take obstacles into account - and that gives the difference between dropping to cover and running away as a defending maneuver. FPS is still an issue though, yes. Sent from my HTC One S using Tapatalk 4

With that, I agree. Ragdolling & death definitely should produce tilt. It just shouldn't reorient you where there's no reorientation IRL Sent from my HTC One S using Tapatalk 4

I agree with tpw. The vestibular apparatus always gives a robust estimation of where the "up" and "down" actually are - hence, the brain can easily discern where "up" is. Being wounded is another story, though... A concussion can play a lot with the sense of orientation - it can be played around in the game.

Tried the mission just now... Unfortunately, ArmA just hang (deadlocked?) just at the start. No pretense, though, I guess it was dev branch problem. However, at the start of the mission I've got an error about undefined expression (see attachment). Forgotten "waitUntil isNil <....>"? Screenshot: https://dl.dropboxusercontent.com/u/57455736/2013-08-10_00001.jpg (434kb)

Nope, still wrong ;) But it would be a nice start, nevertheless. How are you calling your script? Something like this?

Hey there, LtShadow. Unfortunately, you fell victim to common misconception :) There's no sonic boom when an aircraft "passes" certain velocity. Rather, there's a cone of high pressure (shock wave) which is moved with the plane itself. The "boom" itself happens when this cone is dragged over the observer - i.e. effectively the observer is hit by the shockwave. See: http://en.wikipedia.org/wiki/Sonic_boom#Perception_and_noise That's not an attack on the work itself, I'm just pointing out that it may be worth changing the direction a little. As for your script, you should write instead of

Awesome. Special thanks for Ghost Recon-style ones. Just what I wanted. If only the engine allowed two pieces of facewear...

Hey, Cunico, I can help you with the signatures. Drop me a PM if you're interested. I'm trying to make some stuff from Ghost Recon too (CrossCom + UAV), so may be we can cooperate :) DarkWanderer

You're welcome :) Feel free to ask.

setCaptive will only make things worse, as it will introduce other bugs (enemies will not fire at the player when close to the helicopter) and still will not achieve the objective (the rating would be still lost, so friendly AIs will start firing at the player as soon as setCaptive becames false). A wild guess - can you try removing the blackhawk's rating itself? The rating's "rules of thumb" are: Every object has a rating When you kill an enemy object/person/vehicle/... you get its rating added to yours When you kill a friendly/civilian object, you get penalty of 7x it's rating. So, if you set its rating to zero, there should be no penalty. Try adding the following into the init script of the helicopter: this addRating -(rating this);

I run A3 on W8. No problems. DarkWanderer

Awesome work. Really great for mercenaries/specops packs. DarkWanderer

Well, possibly so. The problem here is that if the scenarios are all totally realitic and believable, they instantly start to get boring :P And if there is some WTF factor, some folks would not believe it happened even for real-life events - think Moon landing and all the moon hoax conspiracists :D I agree that more explanation wouldn't hurt, but, IMHO, there's no facts that are outstandingly wrong and unrealistic. It's not like you have to kill 200+ people alone - I actually completed the mission with bodycount as low as 7. I guess, it's a matter of taste here. There's an inherent compromise in game design to maintain it both realistic and interesting. But if I were you, I'd better not ask a game to be completely realistic - because this would also mean having 8 hours daily foot patrols (why, the military does it in real life) and military's beloved hurry-up-and-wait-24-hours routine :P Personally, I just take the good (no routine+tactically interesting scenarios) with the bad (possible subtle scenario incoherences).