madrussian

Interesting explanations there, Silola. :) I actually remember that format quite well, as in... it was kind of a bitch parsing through all that! :D (especially with the zones being in an arbitrary order and all.) I made a quick demo mission to show the functions in action: That email you provided me a couple years back still good? @DMarkwick I have big ambitions for that mission (still under development). Basically you have been wrongly imprisoned in an hostile country. While being transported on a prison bus the convoy comes under friendly attack - a rescue mission by resistance forces. Unfortunately, you get knocked out when the bus flips over in all the mayhem. When you come to, it seems you are the only survivor that has not fled - the dead bodies of guards, prisoners, and resistance fighters are everywhere, but it's obvious that scores of prisoners have escaped. Your undertaking is to escape the island and there's a big twist regarding respawn. As you encounter other prisoners, they'll join up with you. So kind of like group respawn but designed to work in coop even if all but one player is killed. (I.e. There's a death cam for dead players, but they can still get back in the game if the remaining players locate more prisoners.) Anyhow, I basically got the overlapping-moving-DAC-zones part working (with custom points), but then Arma2 came out, and of course no DAC in ArmA2 just yet. So that project on hold pending release of DAC 2.1. If you're interested, shoot me a PM and I'll see if I can't dig up what I had so far for you. Also, curious about your upcoming missions you might be able to incorporate it in? Sounds interesting. :) Apology for that bit of OT. Can't wait for DAC 2.1!!!

Trapper's ZOS zombie system back in OFP did attack side things a bit differently, and to great effect. Whenever the zombies would get close enough to attack you, they would swing their arms at you (like normal), but this would trigger the player automatically swinging his rifle back in defense! Thus there was a brief melee exchange between zombie and player. This small detail achieved two very important things missing in all Arma1 zombie mods (at least afaik): 1. Having the player auto-swing-back would keep the player in place momentarily, which gave the zombies a better chance to surround and swarm him. Overall effect here is that it amped up the tension and put the fear of death in you. You did not want to let them start getting close. I get shivers just thinking back on it. :eek: 2. Having auto-swing-back also gave the player great feedback that he was actually taking damage. I can't count the number of times in Arma1 where I got blindsided by a lone zombie and had no idea I was even being attacked... suddenly I am dead. Wtf? :confused: btw- Good to see all this progress!

Interesting suggesting on the keys. Based on past experience, that would probably require ArmALib (not out for ArmA2 yet) and an external program... probably too much of a hack indeed. So in keeping things a bit more simple... If worst comes to worst, for Air vehicles, I will simply check to see if if either the pilot(driver) -or- the main gunner is a player. (i.e. The player cannot control any of the special turret gunners via "Manual Fire On" anyway). The only known issue will be that if the AI main gunner in air vehicles fires, pilot is a player, and "Manual Fire" is off, my system will choose a dispersion method other than the correct one as defined in my purpose-built settings file. Shouldn't be the end of the world, but still, if anyone knows a way we haven't thought of to detect "Manual Fire On", I'm all ears!

As a longtime zombie mission lover, with many fond memories of going out into the foggy dark to save civilians, only to end up running like hell from the hordes in my all-time favorite zombie mission Trapper's *Zombie Outbreak Simulation (ZOS)*, I've reached the following conclusion: I firmly believe if we get enough brains working on this, by God the end result will be utterly dangerous and believable zombies and tense, murderous mission scenarios for ArmA2! Based on what I've seen working on my animations mod, this should be possible. Just make an animation class that inherits from the main one and then start tweaking speed values. And the good news in terms of workload is you'd only have to mess with the unarmed stuff on zombies (as the undead don't typically carry things!). Again, based on what I've seen in there, there's no reason why that couldn't work. Curious though what do you mean by "work for originals"? Child animation classes (mentioned above)? Did you try that in conjunction with the forceSpeed and/or limitSpeed? Also, did you try with only one unit in the group? (If you have multiple units in the group to avoid them going slower as they try to keep formation you can use setSpeedMode "FULL") I did some experiments a while back with achieving different speed and had some success getting them to stick to a varying degree of speed with a fine level of control within the speed range of various individual animations. Unfortunately these adjustments did NOT work on players. Otherwise we'd basically be there. (Also I haven't messed with trying to get them to go faster than max default though. Might be interesting. And now I'm curious, what's the fastest anyone anywhere has ever gotten an AI on foot to go? :D ) The other thing that could have bitten you are hard-coded limit(s) in the way relSpeedMin and relSpeedMax work. I don't completely understand it, but there definitely appears to be a hard-coded limit for speed degradation (which itself affected by the duty value). You know how when you've been running a long time and start to get tired? Anyone notice how you start to slow down (although only while sprinting)? Well in various experiments I've run at least while sprinting as the player, your speed will never drop below 17.6 km/h, regardless of any other factors which should allow it to drop below that threshold. btw- If you adjust the relSpeedMin and relSpeedMax incorrectly, you won't get speed degradation at all. In any event, the 17.6 limit is huge, because it's way too fast - otherwise we could simply adjust the duty value and tire the player out quicker. :) The only problem potentially here is he can still run away, and come back later to do the task or just keep running around, running circles around the zombies. Ultimately, imo we need a way to slow the player down (due to fatigue, etc). I truly think this is where the fundamental power lies. If we can temporarily disable certain animations the player has access to then we can slow him down, and that when the tension really starts to ramp up. The hordes don't get tired, after all. First and foremost, does anyone know where in the config it is specified that these animations are disabled? (for example, getting leg shot) In case anyone wants to start taking a look in the anims config and is unaware, here's a quick rundown of how things work: There are two main files, CfgMovesBasic.hpp and CfgMovesMaleSdr.hpp CfgMovesBasic contains the "action states", which define what his given controls do while in that "action state". In other words, based on what controls he's pressing, this file tells the unit which animation to proceed to. Most importantly, defined here is exactly which animations the player has access to, based on the state. CfgMovesMaleSdr contains information on the individual animations themselves. Within each animation class, one of the item contained is an "actions" value that points directly back over to CfgMovesBasic. So it's a vicious cycle back and forth between these two files. CfgMovesBasic tells CfgMovesMaleSdr which animation to proceed to (and strictly which animations are allowed given the state), and CfgMovesMaleSdr tells CfgMovesBasic which "action state" to be in. When someone gets "leg shot", BIS is somehow sending the player into an alternate "action state" within CfgMovesBasic. From that point on the player is limited to only a subset of animations (crawling around and standing only, but no longer able to run or sprint, etc). I can only assume the answers regarding disabling animations reside inside these two files. btw- Sorry about the novel there. :eek:

If I had a million years to spend delving inside this wonder you've created, rest assured, I'd still be in awe. :) Certainly. The big reason I went though all the trouble of writing these functions lies on page 16 of the manual (last line in the grey box): "Custom waypoints are lost when a zone is moved." Simply put, I needed the ability to use my own custom points upon moving an existing zone, with was not a capability in DAC 2.0. A bit more on my mission I was creating. I was using five overlapping DAC zones that were designed to follow and envelop the player as he moved around the map. Once the player moved far enough I would deactivate the furthest zone and move it to the new position of the pattern that the player was entering. Custom DAC points were critical to this mission. Figuring out how to make the logic/waypoints method for custom points would have been a nightmare in this case, but more importantly, it would not have worked anyway. (i.e. due to the zones moving) So I rolled up my sleeves and wrote up these three functions, and after many hours to my great surprise, I got it all working! I read and reread what you you've written here, and thought long and hard on it, and started to think that maybe I had mis-spoken earlier on having gotten it to work on-the-fly. Because what you are saying makes perfect sense. As you mention, when the groups are created, they pick a subset of all of the points of the given type for their zone. I have not looked at the code where newly created groups pick their points from the main set, but I am assuming they store the subset of points off in a new array? Or are they storing a reference back to the main set? In any event, here the weird thing: My ReplaceDACPoints function actually works. I have a test mission where I replace the zone's points via an action (while the zone is up, active, with groups wandering around), and here are the results: 1. The waypoint markers move to the specified positions atop my markers. 2. The group's DAC generated destination line showing where they are going redirects to my replacement points. The only thing I can think is that the groups retain a reference to the zone's main points array. --------------- I hope that clears most of it up. It just occurred to me also that even if the whole "Custom waypoints are lost when a zone is moved." thing gets cleared up and that's no longer an issue in 2.1, my functions could still be a great additional tool set for mission makers using the DAC for a few reasons: 1. They allow the ability to swap for custom waypoints on-the-fly while a zone is active. 2. User placed markers for custom points are a lot easier to work with than the logic/waypoints method. With user placed markers, it's simply a matter of: 3. Once you have your user placed markers in place, it's quite clean looking as opposed to the spaghetti-mess that is the logic/waypoints method for custom points. :D (Again that's imo, and allow me to mention again that the logic/waypoints is perfect though for those new custom shaped zones... Everything there looking sweet indeed!) Anyhow, thanks again for the DAC Silola. It's certainly revolutionized mission making in the OFP/ArmA series. Can't wait for 2.1! :cool:

You just hit the nail on the head there! In zombie missions, we need the possibility for the player to be able to get tired and wear out, thus moving slower until he can get rest/food/water/whatever. (The zombies are dead, so they don't really need to get tired, necessarily.) Even simply temporarily removing the player's ability to sprint would get the job done. Somehow I think this has got to be possible. For example, when you get "leg shot" now, you lose access to a whole set of animations, so I can only assume it's possible.

Thanks for the response. I am indeed using the fired event handler, and have overcome some huge obstacles already. Namely, you can get at the shooter, like this: _shooter = _this select 0; At this point you don't know whether the shooter is a man or vehicle but that can be determined like this: _onFoot = false; if (_shooter isKindOf "Man") then { _onFoot = true; }; If he's on foot, I simply do an (isPlayer _shooter) to determine whether he is a player or not. However, if _shooter is a vehicle, the issue immediately becomes you don't know exactly who inside the vehicle fired the shot. Indeed, when _shooter is a vehicle, it turns out that (isPlayer _shooter) will always return true provided there is at least one player inside. So I had to get creative and pull the weapon values from the config for the particular vehicle type and compare them against the weapon the eventhandler provides. And then once you consider special turrets (gunners other than the "gunner" and "commander" positions), it's gets really hairy figuring out who fired the shot, but it's turns out it wasn't impossible after all. In any event, I've currently got all that logic working, and can now determine with 100% certainty whether a player actually fired the shot or not. There's just one thing left... If the player is in maunal fire mode and shoots, it causes his AI to fire as expected. But especially in air units, the player is really doing the aiming at that point, so I'd like to treat it as a special case and assume the player actually fired the shot. And so it comes down to one final thing: I need to determine whether the vehicle is in "Manual Fire On" mode or not. Unfortunately, I'm at a bit of a loss at the moment. :confused:

Awsome and awsome! :) What you describe above is letting the DAC pick a new set of points upon disable/enable, which I agree is a great DAC feature (and which I happen to rely on quite often). However, the function set I wrote actually does something completely different and new to DAC! The purpose of these new functions is to replace existing DAC points with a specified number of user defined positions in an array, and most importantly, do so on the fly (i.e. w/o disable/enable and furthermore bypassing the logic/waypoints method provided inside DAC). Best of all I was able to get it working with the DAC point markers. There are three main functions. 1. GetDACPoints.sqf // This function returns all waypoints of a given type for a given DAC zone // Call with [Zone, Zone_Type] call GetDACPoints // // Zone: The DAC zone to retrieve waypoints from. Can be the zone itself (trigger) or the name of the zone (string) // Zone_Type: The type of DAC waypoints to retrieve. One of the following: "S", "V", "T", "A", or "C" 2. ReplaceDACPoints.sqf // This function replaces a number of waypoints in a given DAC zone // Call with [Zone, Zone_Type, Replacement_Waypoints, Max_Replace] call ReplaceDACPoints // // Zone: The DAC zone to undergo waypoint replacement. Can be the zone itself (trigger) or the name of the zone (string) // Zone_Type: The type of DAC waypoints to undergo waypoint replacement. One of the following: "S", "V", "T", "A", or "C" // Replacement_Waypoints: The replacement set of waypoints (positions) // Max_Replace (optional): Maximum number of waypoints replaced. If used, the function will randomly select this number // of waypoints from the replacement set. If omitted, the entire replacement set is used. // // Requirements: This function requires the Shuffle function by toadlife (get from OFPEC Editor's Depot). // // Notes: It's important to know how many points are there, before replacing them. Use the GetDACPoints function first as necessary. 3. ReadMarkers.sqf // This function reads in information (including position) for all markers starting with a given base name, and returns an array containing this information. // Call with Points = [base_String, Blank_Limit, Info_Requested] call ReadMarkers // // Base_String: The base name of the marker. For example, "Station" will pick up information on "Station_1", "Station_2", "Station_3", etc. // Blank_Limit: The number of missing input markers to ignore. For example, assuming the markers present on the map are "WayPt_1", "WayPt_3", "WayPt_4", "WayPt_6", // using a blank limit of 2 or more would return info on all four markers. Alternately, using a blank limit of 1 would return info on the first three markers only. // Info_Requested: The type of information requested. Possibilities are "Pos", "Pos&Dir", "Name&Pos", or "Name&Pos&Dir". // // Note- The blank limit feature is intended so that you may copy and paste in markers and then delete any of the markers without worrying about gaps. // A blank limit of 1000 or more is therefore recommended, to eliminate such concerns. [Note: When using ReadMarkers as prep for ReplaceDACPoints, the Info_Requested value called out in ReadMarkers should be "Pos", in order to get back an array filled with positions only.] In my experience, using the DAC's logics/waypoints method of enableing user-defined waypoints was always kind of cumbersome, because there's that line connecting all the points, when the points themselves really aren't related to one another point-to-point. It always looked kind of "scrambled" to me. :eek: As a quick and easy alternative, simply pasting small dot markers and then calling the new functions is very clean, intuative, and clear. (I should probably mention though, just how nicely the logics/waypoints method appears in your new screenshots for the new arbitrary shaped zones! Now that's a great use of the lines associated with the logics/waypoints method... very informative! ) Anyhow, if you're interested in taking a look at my functions for possible inclusion in DAC 2.1 Silola, do let me know. If not, of course that's perfectly fine as well (your show after all). btw- I am also open to sharing these with anyone who is interested on a personal use basis. :cool:

You are the man Silola! The man! :) I love the new any-shape/any-orientation zones! Some big requests for 2.1: 1. Removal of DAC units from the DAC system on the fly (via a function). Recently we gained the ability to add non-DAC units to the DAC system on the fly, which was huge. What is sorely missing now imo is the reverse. This is big for a number of reasons, namely so that we as the mission designer can grab a DAC group, temporarily "unDAC" them, send them out on a mission related task, and then add them back to their zone when ready. 2. Changing the number of groups in a given DAC zone on the fly, via a function. 3. Assigning a user defined point cloud to replace all or a portion of existing DAC generated points in a zone, on the fly, via a function. I actually wrote a set of functions achomplishing this for DAC 2.0 which work like a charm (personal use). I've also got a robust function that pulls in marker points (prep to get them into the DAC) that folks would probably find useful in conjunction. If interested Silola, let me know and maybe they can make their way into 2.1, provided they're up to your standard. 4. Destroying a DAC zone completely, and returning the groups to the system (different than #1). Anyhow keep up the good work. You've made so much possible for all of us over the years with your DAC... Indeed, I'm not afraid to admit I still enter a mesmerized state just watching the DAC do it's thing and personally I cannot thank you enough Silola. :)

The problem imo with continual respawn is that you can't ever lose the mission by losing all playable soldiers. To each his own though, maybe the best is make it all optional. As far as cutscenes goes, Laggy has indicated a desire for some level of cutscenes in his upcoming MP missions, and I so I say for him that's the way to go. (i.e. Because he's passionate about making those kinds of missions.) Great thing about OFP/Arma though is the large productive community. No matter what our individual preferences, chances are there's someone making a mission that suits us. In fact, I can think of no other game engine that allows the sort of custom respawn I'm dreaming up. EDIT- btw Laggy, I reread the choices in you're poll and it's actually a pretty loaded question, to an extremely humerous fault. Based on the words "long story-based mission..." in the topic title, you're definately gonna get a slew of people that are interested in those types of missions. btw- I think I mentioned this before, but - Count me in! :D

So here's the simple question: Given an unknown unit, how can we determine whether it's on foot? (I.e. Is it a vehicle or a man?) Now some details: So I've got a "fired" eventhandler set up. I get the shooter like this: _shooter = _this select 0; The next thing I need to do is to determine whether the unit is on foot, which I've always done like this: _onFoot = false; if ( _shooter == (vehicle _shooter) ) then { onFoot = true; }; IIRC, this used to work like a charm, but apparently not any more! :confused: When I do hints and check the values of _shooter and (vehicle _shooter), they are always the same value, regardless of if the firing unit is actually on foot or not! I tried using (crew _shooter), but that returns a single unit when the unit is on foot, and thus would be ambiguous as well. (_shooter in _shooter) does not work as advertised either. It reports true no matter if on foot or in a vehicle. I even tried assignedVehicleRole, as in: _onFoot = false; if ( (count ((assignedVehicleRole _shooter) select 1)) > 0 ) then { _onFoot = true; }; which works (only gunners report a turret), but after thinking on it a bit, it's just as ambiguous as the others, because it could be a footman assigned to a gun position but be waiting on foot outside the vehicle (i.e. using orderGetIn false). :eek: ...As I've typed all this it finally dawned on me what I can use in my particular case. Tested it and it works in every case I can some up with (including a vehicle with an empty driver seat): _onFoot = false; if ( (driver _shooter) == _shooter ) then { _onFoot = true; }; This works in my case because I know the unit fired and is thus not a driver. (Recall that I got the _shooter from a fired eventhandler.) However, I am still scratching my head on this though... :confused: What if we simply need to determine whether an arbitrary unit is a vehicle or on foot? Now that I've gone into all this detail, I have a feeling someone is gonna dazzle me with just how simple this really is. :) EDIT: Hmmmm... It appears I've just dazzled myself: _onFoot = false; if (_shooter isKindOf "Man") then { _onFoot = true; }; Hope this helps someone out. :)

Can't wait to check this out with issues ironed out... keep it up McRuppert! :)

I was thinking about that too. Somehow I think we would have to code oour own physics for the "joints" and then let the game's physics system do the rest. :eek:

Sounds extremely cool. Gotta check this out! (I especially like seeing the built in custom spectator script as a feature.) IMO, plenty of missions (especially if on the smaller side), are fine without respawn or revives. Difficulty settings are always nice, but certainly not a necessity. In short, having or not having these things does not necessarily make a mission good or bad. The good news is there are all kinds of missions coming out, so for the most part we can all be happy. :)

I always assumed that aimingSpeed was the lag between where you are and where the enemy AI is aiming. So if you are moving very quickly, then an AI with a high aimingSpeed would be able to keep the gun on target better. An AI with a low aimingSpeed would still blast away but just be shooting where you just were. In this case, the low aimingSpeed AI is having trouble "keeping up" with the target with respect to aim. One thing I've not seen in Arma2 yet is the ability of the AI to lead a target. They seemed to have much less problem with at least attempting this in Arma1. Case-in-point: As part of testing for the dispersion mod I'm developing, I temporarily set dispersion on high rate of fire weapons to zero. I set up a scenario where an AI unit has plenty of ammo and is trying to kill me. On my motorcycle, I ride at a reasonably high speed from left to right across the AI's span of vision. He blasts away and I see the tracers flying, but all rounds consistently zip past behind me and the AI never seems to adjust and compensate for the fact he's shooting at where I WAS. He simply appears unable to lead his fire and get any closer to hitting me. Now once I slow down his rounds catch up and finally kill me. My theory is that in this case the AI's aimingSpeed value is too low to hit me at the higher speed. I intend to run additional testing to sort this out. But if the above statement is indeed correct, how then do we adjust the AI's ability to lead his fire in front to actually attempt hitting a moving target?!?

I hope you guys do release it. Sounds like these items would be great as a starting point for lots of mission ideas. Also, many of your items would be central to potential "Sleeping" mods.

Everything looking great! I love that huge central mountain dominating everything around it. Reminds me of "Thunderclap" in Stephen King's Wolves of the Calla. Your island in ArmA1 was overwhelming with all the possibility for mission makers. It absolutely oozed story potential! Also, good to hear about the many enterable buildings in the new version. Quick question- Will any of the custom buildings be destructable? (i.e. like with the default Arma2 buildings)

Not sure if it helps out with the "tracers not being visible in certain cases" issue (and no idea if this has been discussed already), but have you cracked open 6th Sense Tracers from ArmA1 to see how he went about it? I could always see those tracers no matter if they were coming or going. Anyhow, great mod! I'm making heavy use of 1-1 in testing the dispersion mod I've been working on. Thanks for your hard work on this!

Everything looking really good again in Arma2! Can't wait for your islands in particular! edit: Probably going a bit overboard here, but are you looking to make any of the buildings destructable (like in Arma2 default islands)?

Great campaign so far. I made it through the first mission and got a few nice surprises in the second. Really makes me want to keep going! This may have been covered already, but when you die as the team leader and team switch to another player, the rest of the squad just stops. (At least for me that's what happened.) How about an option to (re)take command of the squad again as the new unit? You should be able to do it pretty easily by a quick change of the ranks for the player and all the player group AIs. Bump the player up and the others down. Maybe in an upcoming version?

Something like the original Tonal in Arma2 would be insane (in good way). Not sure if there's any frame-rate friendly jungle vegitation out there to really make that work, but here's hoping. Based on the awsomeness of Panthera, I can't wait for your new creations!

Awsome mission Wiper. :) I am loving it! The focused design makes for a completely unpredictable experience every time (in a good way).

@andersson So have gravel roads been made to work just like the paved roads? ...Or did you just raise them up part-way towards the level of paved roads? One thing that would be interesting would be to make top speed on all surfaces the same... but create/maintain thresholds for damage above certain speeds for the various surfaces. Probably fairly script-heavy though.

I just ran a quick test and lobbed about 100 grenades from a moddified M203 launcher (with dispersion set to 0.05). Based on your info, I set up a target exactly 100m away and placed two cones exactly 5m apart staggering the target. While standing, I carefully lobed all those grenades directly at the target, and indeed they all passed inside the zone, and some right up against the imaginary "field goal posts" (i.e. directly up from the cones). In short, everything worked like a charm. Thank you so much Q1184 for finally cracking this mystery for me! My dynamic dispersion mod just got simplified many fold. :) @All Another quick question. Q1184 also mentioned different stances treating dispersion at modified amounts. Anyone know where this is defined in the config?

First off, I did a fair amount of dispersion work in Arma1, that I'm thinking about porting over to ArmA2 (including the new A2 weapons, of course) for release. Couple of quick questions, in case anyone knows out of the blue: 1. As most of us are aware, when the config dispersion value for a given weapon increases, the projectiles become more disperse. (i.e. less acurate). However, does anyone know what this number actually means? From my testing in Arma1, using a weapon dispersion value of zero yields absoutely NO dispersion, as expected. But, for instance, what does a weapon dispersion value of 0.5 really mean? Also, anyone know if projectile speed is already "baked" into this dispersion number? This info is integral due to the nature of my dynamic dispersion mod. 2. As an initial step in testing the question above, in Arma2 I created a modified M16A4 giving it the following config values: class M16A4_MOD : m16a4 { displayName = "BUBGUN"; dispersion = 0.5; descriptionShort = "BUBGUN"; }; My hope was that the new gun would fire at a max of a 45 degree angle out of the barrel for a quick explanation. To my surprise however, as the player I fired several rounds and there was no noticable dispersion to speak of. Based on what I remember from Arma1, this dispersion value would affect both player and AI alike, with aiDispersionCoefX and aiDispersionCoefY affecting only the AI. Question is, does this dispersion value somehow not affect the player in Arma2? And if so, how then in Arma2 do we affect dispersion in player fired weapons?