Nielsen

The module name is whatever you name the module when you place it in the editor. Like with any other object. Try a: playerName addeventhandler ["respawn","_this execvm '\respawnScript.sqf'"]; Make a respawnScript.sqf in the mission dir, and in that file put a: moduleName synchronizeObjectsAdd [playerName]; Remember to change out the moduleName and playerName to what you have named the module and unit in question.

1-2. I'll think about this. I certainly want to make as many options as possible, but before I do this I'll prolly first add support for east choppers. I'll keep it in mind though. 3. Yeah, that's not cool. Not sure how to fix it yet though. I'll look into it. In the meantime you can switch the audio off I'f it's too bad. 4. You can do that now with this setVariable ["nielsen_cim_AllowExtraction", false]; in the module init. It's all in the readme. 5. I dont think that is really viable. I thought long and hard not too clutter up the menu with too many actions. And first I did let them stay put when released. But that does not seem like the best behaviour overall, thats why they now regroup theyr old group. If you want them to stay put you can allways keycuff them. They wont go anywhere ;)... If that breaks immersion for you, then you can just make them stay there with a trigger or something. Just setup a trigger around the "holding zone" with civilian->present activation, and fire it with a variable or something. In the trigger activation have a "{doStop _x} forEach thislist;". That way everytime you fire that trigger all civs inside will stop.

That seems a bit harsh dude... Have you tried resyncronizing the module with the players after respawn with synchronizeObjectsAdd? Cause when a unit respawns it usually stops being synchronized with modules...

No doubt :) Just setting it up with nothing else in the editor? Are you remembering to run CBA also? That is the only thing I can think of right now, that might cause something like that. Are you running Arma2 AND OA? If yes, then please duplicate the error and post your .rpt file, and let me have a look at it. If you dont know how, then look below. To post .rpt info: The file can be found at: C:\Users\YourName\AppData\Local\ArmA 2 OA\arma2oa.RPT You will need to have "display hidden files and folders" enabled. Please open that file in a text editor. Delete everything in it and save it. Then run arma and duplicate the error. Exit arma, open the .rpt file and copy the content into a spoiler in a post here.

Thanks man. The prone thing might explain why I could not reproduce. I did not think of that. But I have tested the physical actions on prone civs. I will keep it in mind, and see if I can figure it out. Any more info you can find is greatly appreciated. This made me smile. Thats exactly the type of stuff that I love about Arma (and community content). Several times we have completed our objectives perfectly only to let our guards down on exfill, and have one of Reezos (trigger)men do us over on our way back :D. I'm really happy that I could contribute to your experiences. I allways run my mouth, so I'll tell you the experience that made me finally decide to do the CIM: While clearing a compound in Sangin we enter a building. My buddy looks out the window and spots an IED spotter on a little dirthill in a nearby compound. Sneaky bastard is on his belly looking over the compound wall and down the street, waiting for us to roll past. We rush the compound and get a hold of the hadji. We search him (with ACE interaction), but find nothing. We then decide that he is a risk and that we can not leave him... but the ACE arrest is really just a "setCaptive". He flashed some jazz-hands one time and then he just stood there. So then the only thing we could do, was to get the troops out of the area, and neutralize the civ quietly - off the record.:butbut:.. We were so psyched that we caught a triggerman that it was really a letdown when we realized that we had to kill him. Next time - running CIM - he will get the full treatment (I'm talking orange jumpsuits and intercontinental flights) :D Thats all good. There is enough appreciation to go around ;). I'm glad you like it. I myself really feels that it compliments the EOD aspect rather nicely :cool:. I just hope I can get it working right on dedicated. I'm rather excited to hear if the new version fixes most of the dedicated problems... Hehe yeah, theyr prolly just testing us out :p

Allright that is a bit more depressing. But that also makes it much more likely in my mind that pubVars are causing the issue. So, I'll start out with the pubvar thing. I guess I'll change all pubVars to CBA pubVar and hope that it makes a difference. As stated above I have fixed the animation so that should work I think. I have also made some FSM to handle behavior, I hope that makes a difference too. I'll update the pubVars and drop a new version later. Give my thanks to SSG. Awesome that you tested it on such a scale! EDIT: v. 0.15 is out :) Changelog: 0.15: [Fixed] - Chopper extraction is now better optimized for dedicated [Fixed] - typo in extraction hint [Fixed] - Civilians no longer stay Bluefor after being released. {Fixed] - Keycuff animations should now work correctly in multiplayer [Changed] - All publicVariables are now handled by CBA_fnc_publicVariable. [Changed] - All commands are now displayed in fixed order at the top of the action menu [Changed] - Released civilians now run and rejoin their original group. If that group no longer exists they will join CIM_holdGrp. [Changed] - The module Variable "nielsen_cim_SmokeType" is now an array of smoketypes (classnames), so you can use multiple colors. {Changed] - AI behavior for "Get Inside" command improved (now handled with FSM) [Changed] - The radio/sidechat msg on 'Request POW extraction' now displays player name rather than unit variable. [Changed] - The readme has been updated, and setVariable examples are now unformatted and can be copied from the pdf. I would really appreciate if you would give it a spin and let me know if it handles better on dedicated now. When joining myself in LAN is seems to work like it should.

Thanks :).. Hmm. Well I guess I consider the publicVariable issue backed by a second opinion then. I'll get right on it. When you say "get stuck" do you mean that you are no longer able to uncuff them and they remain in the animation loop forever or are frozen solid?

Yeah that works. But I am a bit unsure which commands make unitReady or not. I mean doGetout and stuff like that might not be a high-prio thing, but it does lead to unitReady, right? I actually did that first, and then changed it to a specific type. For the next update I will just make the custom smoke color an [array] instead of a "string", that way you can put in as many colors as you want. :) Great post! Thanks a bunch for testing and quality feedback. Regarding the first thing with the stuck animation. Heh, that had me puzzled for a while. Now I think I see the problem. It is not a bug but rather intentional that he does not end the animation when released. He does still end the animation when uncuffed, right? I made the keycuff and the detain features completely seperate. I figured that I might want to "release" him from my group, but still keep him keycuffed so he cant blow himself up etc. That is why the "release" action does not also uncuff them, and you have to do that specifically. - Or am I completely off the mark here, and is there really a bug I'm not seeing? I had no idea that publicVariable was a problem with dedicated servers. Unfortunately I use it all over the place. But if CBA has a replacement that works with dedicated, then I guess it is just a matter of changing them all, which should not be difficult just a bit tedious :). I'll make this a priority. EDIT: I am not able to find any information about publicVariable not working on dedicated servers. And it seems unlikely that publicVariable should be the error, if the error happens the same places all the time, and I use publicVariable everywhere. Are you sure about this? I'm just asking because you said you thought so, and the CBA command seems to be about only broadcasting when the variable is different, but that is not really a problem. AFAIK I hardly ever broadcast the same variable again. And it would take an effort to change them all. If there is a point to it I will, if not I'd rather spend the time on something else :) Regarding the animations not showing on dedicated, I'll look into that asap. EDIT: I reproduced it, and I believe that I have now fixed the animation problem. At least it works when "dual-wielding" my arma installation in LAN. I made a function to take care of animations on all clients and fire it with CBA pubVar. The fix will be in the next update (or pm me if you want a link). To be honest I am somewhat thrilled that you did not find more and/or bigger bugs than that on dedicated. Regarding the houses, I am currently making an FSM to handle that feature. With that and maybe a look at the publicVariable I hope that fixes it. But I would of course welcome any more thoughts on the matter!

I would'nt go that far . Ah, I see. I just stumbled upon it while looking in the code and thought that it was an oversight. Forgot to tell you at that time, and just thought of it. That would be great. Fingers crossed x--0--x I have been using the unitReady instead, but as I understand it, it wont tell me if the task/move was completed or failed, only that the unit no longer tries to comply. In the case of sending civs into buildings I wanted to know if they were blocked on their way in. Hehe now I know why those low-level commands would not work for me. I feel rather embarrassed that I didnt realize that it tied into FSM, but at least now I understand the whole high/low priority thing :o. Thanks for breaking it down. It does look rather interesting. And I can certainly see a lot of possibilities in FSM. I hope it wont be too complicated to get into. The most daunting part is to get familiar with the editor. That is quite clever. I opened one up as suggested and it actually seems kinda intuitive, although I'll have to spend some time understanding how it works in detail. But yeah I see your point about the need for "sleep", when you can just set up conditions for moving on. Now you've peaked my interest. I'll have to look into this right away - speaking of the need for sleep :D. EDIT: This is really usefull and less complicated than I thought. I'm glad you turned me on to it! I've got a problem though. With the high/low priority thing I'm not sure which commands not to use. Common sense tells me that all the "doXXX" commands are off limits, but they do not all seem to have a low prio equivalent. Is there a good rule of thumb? And should I be wary about other commands than the DO commands?

That is actually one of the reasons that I use doMove. Because if it is unitReady right away the civ will continue with whatever the mission maker has planned out for him. But it did cause problems. When ordering civs to get inside houses they would be unitReady and come right back out of there, so I did use a doStop on them when they have entered a house. I have not toyed with FSM before, but now that you mention it, I see that it must be the right way to go about this. I have looked at MoveTo(completed), but as it is a "low-level" command (not really sure what that means in praksis) I avoided it. Weird there is not a doMoveCompleted or something. I think I will look into it, and eventually make most of the civ behaviour run by FSM, when I figure out how to make them. Can you suspend (with sleep or waituntil) in an FSM? Regarding the first thing. I never use team-switch so I had not thought of that. The actions wont work with team-switch because the action is added to all players at mission start. Thanks for pointing it out. I will keep it in mind and try to fix it. As for your multiplayer problem that sounds really weird. I have not seen that before. Where you on a dedicated server? You could post your .rpt file (usually located@ "C:\Users\YourName\AppData\Local\ArmA 2 OA\arma2oa.RPT"), that would give me some more insight into what is going on. Let me know if you keep having this problem, and post any relevant info. I will do my best to resolve it. It was only fair seeing that I did get a lot of inspiration from your mod (and its code) :). I'm really loving the EOD mod. Wont go into Sangin without it :D. Just to be specific, 3 things made me do this mod. - First, having my group blown up by suicide bombers because I would not shoot civilians without warning, made my think of verbal commands and ordering them down - if they keep comming they are fair game ;). - Second, your "Evacuation feature" on the vehicles hinted me on a good approach. - Third, Finding a sneaky triggerman hiding in the bushes of Sanging made me realize that I had to expand from verbal commands, so I was able to detain him and send him off. I did not want to just kill him - and leaving him there to push the button was certainly not an option. :p Actually, now that I'm on about it, I've got two things about the EOD: Mod. 1. In your ...loudspeaker_evacuate.sqf script (line 30) you use the _rangeMin variable instead of the _rangeMax when getting nearEntities. I figure that will not return the wanted units as it should. 2. I think it would be cool if you added some small item on the unit when your script picks up a triggerman. Maybe some "evidence" object in lack of a cellphone or radio transmitter. That way you would be able to see "suspicious items" in their inventory, and have a reason to haul them off. When I finally catch a triggerman before he detonates I like to make a big deal out of it :D. Just an idea. Thanks. It should work in hosted environments. Me and my buddy use it all the time without problems. If you were thinking of dedicated, then yes, I'm affraid that I'm not quite there yet. I do intend to make this fully working on dedicated, and I have taken meassures while coding to make it possible. But I have no experience with dedicated (I only play small hosted coops), so it will likely be a rather bothersome process. I figured that rather than holding out and trying to fix this while Arma 3 gets closer, I should just put it out there now for those who can use it as is.

Ah I see. I thought the units would go to that initial waypoint and then dissmiss. Thanks for clearing that up. That is clearly the way to go for released civs then. I'm not sure I want them to wander off when released, but yeah then I could just set the initial wp to dissmiss. I might do that. I was more curious about the waypoints vs. doMove regarding other functions in the module. The thing is that this needs to work with ALICE and civilians that mission makers have put in the editor, that might still have waypoints. And with the action for ordering civs out of the area the "dissmiss" wont work cause I need them out right away, and at a certain range. The "move" wont work cause I need them in every direction. And I need them to return to mission maker control after the move. It seems that if I use 'addwaypoint' instead of 'doMove' then it becomes more complex especially with editor placed civs (when they have not just been ungrouped and thus lost their old waypoints :) ).

Ah now I see what you mean. To have them walk. They would still wander off though, which is what I was trying to prevent, but I dont like the static behaviour of doStop either. I will probably go with a forceWalk to replace the doStop, and let the civs stroll off if they please. The reason why I dont use waypoints is that I want them to run off individually in different directions without disbanding the group. When releasing into a "hold-group" giving the group waypoints also seems in danger of adverse effects I think. I might not have thought it through yet. EDIT:Seems a little more complex to inject a waypoint if I dont (initially) know where to put it? I think I can only que them up without much trubble so I use doMove because that seems to work perfectly with civilians that have other waypoints from editor or ALICE. It just injects the behaviour and lets them continue with their business unless told otherwise. Is there a reason why I should avoid these commands, or use waypoints in general? ---------- Post added at 21:08 ---------- Previous post was at 20:51 ---------- Thanks for reporting on it! 1. I am not able to reproduce this :confused: I can not get them stuck in the cuffed animation, and I'm detaining/cuffing/releasing in all combos I can think off. Are you still having this issue? SP or MP? What other mods are you running, and does it still happen without them? 2. The civilians do actually die, it just takes a while to show because the civilians play out the animation cycle before falling dead to the gound. If you wait a while they should die when the animation ends. I could fix this, but I dont think it is really a problem that justifies making the addon more heavy by checking damage on every cuffed unit. Then again it would probably just be a single loop so it would not be all that bad. What do you think?

Yeah. Thats what I thought. And I figured it was best not to force it. That way people can set up scenarios where civs go to specific places once released or something. If I returned the unit to its old group, then he/she would take of running every time you released him. I saw that as the bigger problem, as I often want them to stay (more or less) put. I'm not sure (how) that is possible either. I did think about it, but did not know how to go about it. Not sure if ALICE ever excludes them. I have not tested if they still despawn after being released. I figured that people wont detain and release civilians en masse, so that it would cause a build up in the number of units end groups. That's an interesting question/idea. My only worry is that I would have to introduce a shit load of new global variables. I am very busy irl over the next month (which is why I decided to release a beta now), but I will keep it in mind and look into it further down the road. Yeah it is a shame that the conversations are so underdeveloped. I really like the concept. It certainly would make for a great addon, but I dont think this would be the right addon to toy with that. I have allready worried that the helicopter extraction and smoke features were too much past the scope of the addon. But I thought that it was kinda vital to be able to get civilians off your hands once you'd detained them. EDIT2: Indeed. It started out as a script. Before making this addon I was all like "Scripts > addons". But working on this and tweaking it all the time - and then have to reimplement it in all the missions I use (often with slight script changes) - it started to take its toll on my patience. Finally I came to the conclusion that the convenience of an addon makes up for the download requirements - especially during continued development. Once it is closer to completion I might do a script version if the demand is there.EDIT: Thanks for the input. Yeah I see now that I might have been a bit lazy. I thought about the group thing but figured it would not be aproblem with a few groups. Of course that is not the right approach. I think I will go with the second option for now and just make a new "hold-group", and then give the civs a dostop (or forceSpeed 0) command when they are released so they wont scatter. I'll do something more ellaborate when I get the time. Thanks for the hint on the forceWalk and forceSpeed. For some reason I am really concerned with using loops and such. Maybe it's just amateurish paranoia, but I am really trying to limit them in any way, that is why I have stuck to "doMove", "doStop" and such. Do you think this is an ineffective disposition?

Hmm. This has only happened to me when testing out the extraction feature too close to the helicopter spawn point(?). Because the helicopter spawns on a helipad, it will land on that (instead of the invisible helipad created by the smoke) if ordered to that area. Where you far from the helicopter when testing this? Could you tell a little more about the circumstances. When I test it the helicopter is quite reliable :) 1. No. At the moment they join "grpNull". I did think about it, but then I thought if you detain someone and bring them along, and then later you release them while clearing a compound. If joining an original group far away, the civilian will take of running as soon as you release him. I could make him rejoin the group but order him to stop. What do you think? 2. I have not looked into the conversation system, so I dont know how hard that would be. I made this mod to be able to order civilians down or away instead of shooting them if they get too close. The other features grew from there. Regular conversation requires that you are up close, so it did not seem suitable for yelling at them.

Thanks for all the kind words. I really appreciate it. Or at least it makes the bare minimum of combat interaction possible :D Thanks for the feedback. Yeah I know about the ctrl key. That was my first pick. Not sure if it is only a matter of taking care of control options ingame (e.g. reassigning the target button or something) or if it is hardcoded. The way I see it right now shift or alt seems to be the best options for quick use. Both have pros and cons though. Great stuff! I had not thought of that. I think it is because the surrender module makes them "setCaptive" and that in turn makes them civilian. That is a cool bonus effect. Actually, I'll add it as a feature so people know that it works. Thanks for pointing it out! :).

Hmm. That is strange. Are you also using the mouse scrollwheel to go through your action menu? You have to scroll while holding left shift.

Make sure you run the command in an activation field and not an init field. It has to be run after mission start, so launching it in init will not work. Other than that, the "" might be twisted by the forum font. I think I've seen that before. The command you posted look right. I see your problem. I first set default to left control, but realized that when ctrl is held the action menu is not available. I thought about using left alt, as I have trackIR that would work. But I ended up going with left shift because it is within reach, and because it is tied to run/walk it works nice when standing still. Of course it can be a problem when moving depending on the setup. I am open to better ideas for a default key. But: 0 = findDisplay 46 displayaddeventhandler ["keydown","hint format ['%1',_this select 1];"]; Should tell you the DIK-code of a pushed key if run after mission start. I use a "CIM-Key" because I hate cluttering up the action menu. I thought that would be a better way of making it less intrusive. But action menu seemed like the only way to make this work. A dialog would have frozen the player. Way to dangerous with suicidebombers around. I think a required key is a good compromise, I just hope it does not seem over the top. EDIT: Fixed command line :o EDIT2: I'm not sure how to make the CIM-Key local. It would obviously be a cool thing, so I would like to do it, but right now I'm not entirely sure how.

@Foxhound: Thanks. You work fast :) @MugAben: Thanks man. Yes it is. It works with more or less any civilians. :)

I figured that with such a small filesize it would not matter much. But no worries, rapidshare link added :)

I like that idea.

Just an awesome mod man. It's allready standard in my group. Would be so cool with a UGV. Grats and thanks!

But I want it soo bad :butbut: :p

What about this? Is this not sort of a confirmation on underground structures? Or is this just wishfull thinking? :D

I've mostly seen this when sniping. I've had it happen many times with 7.62 at medium range.. I do recognize your point, but when you put your rounds on target as a marksman, you kinda expect them to kill.. Not sure if it is hit detection or reduced damage that does it, but I've had many 7.62 rounds fail to kill with headshots at around 500m.

To get the variable for the group, in the leader init field put: Groupname = group this; You use _x to refer to the unit in a ForEach loop. Try this. (Remember to fill in the name of the plane and the group). {_x action ["Eject", planeName];} forEach units groupName; EDIT: If you do not want them to spill out all at once, you can put a sleep in the forEach loop.. Like so: {_x action ["Eject", planeName]; sleep 5;} forEach units groupName;