Civilian Interaction Module (beta)

[rübe 127]

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?

There is no need for any loops (and such). You'd simply issue

  _unit forceWalk true;
  _unit forceSpeed 2;  // _unit forceSpeed -1; to get them back to normal if needed

once on the released unit, and from then on that unit won't run anymore. I'm not quite sure if only one of those commands is sufficient (and if so which one), but something along those lines...

Also I wouldn't "doStop" them. Simply give the group a "MOVE" waypoint if you want them to group (and stay) somewhere. Or you could give that group a "DISMISSED" waypoint which will cause the guys in that group to wander off anywhere randomly. You could even have a thread/fsm running, that switches between these two waypoint-types after some cooldown time so they will regroup occasionally.

There are lot's of ways you could model the desired behaviour.

[kurow 0]

Awesome addon. Brilliant.

[pellejones 1]

Found two bugs!

First: Civilians get stuck in cuffed anim forever.

For Repro to this:

1) Keycuff Individual

2) Detain individual

3) Release individual.

The trick is to release him before uncuffing.

Now you can't uncuff him and he will be stuck in the Cuffed-anim forever :)

Second: Civilians are immortal

Civilians that are cuffed and get shot/die never leave the cuffed anim.

[Nielsen 10]

There is no need for any loops (and such). You'd simply issue

  _unit forceWalk true;
  _unit forceSpeed 2;  // _unit forceSpeed -1; to get them back to normal if needed

once on the released unit, and from then on that unit won't run anymore. I'm not quite sure if only one of those commands is sufficient (and if so which one), but something along those lines...

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.

Also I wouldn't "doStop" them. Simply give the group a "MOVE" waypoint if you want them to group (and stay) somewhere. Or you could give that group a "DISMISSED" waypoint which will cause the guys in that group to wander off anywhere randomly. You could even have a thread/fsm running, that switches between these two waypoint-types after some cooldown time so they will regroup occasionally.

There are lot's of ways you could model the desired behaviour.

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 ----------

Found two bugs!

First: Civilians get stuck in cuffed anim forever.

For Repro to this:

1) Keycuff Individual

2) Detain individual

3) Release individual.

The trick is to release him before uncuffing.

Now you can't uncuff him and he will be stuck in the Cuffed-anim forever :)

Second: Civilians are immortal

Civilians that are cuffed and get shot/die never leave the cuffed anim.

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?

Edited November 27, 2011 by Nielsen

[rübe 127]

The reason why I dont use waypoints is that I want them to run off individually in different directions without disbanding the group.

You can not use no waypoints. A group has always at least one (initial) waypoint, that gets implicitly created the moment you create the group. And this is a "MOVE" waypoint to the position of the groups leader. (at least with editor placed groups - I'm not quite sure about scripted groups, that start without units in it; thought that initial waypoint is present for them too). Anyway that initial waypoint is "completed" from the beginning. And since it's a "MOVE" waypoint, the units will simply stay put and react eventually.

To have units in a group randomly wander off, you either create a new, second waypoint (with waypoint-id = 1) and set it's type to "DISMISSED" or you can simply set the initial waypoint (waypoint-id = 0) to "DISMISSED" and set it to currentWaypoint... (if you're scripting, it's actually generally a good idea to always work on that one initial waypoint; altering it and setting it current over and over again instead of creating and stacking up new waypoints, which is more usefull for non-scripted/editor-only work).

[Nielsen 10]

Anyway that initial waypoint is "completed" from the beginning. And since it's a "MOVE" waypoint, the units will simply stay put and react eventually.

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.

To have units in a group randomly wander off, you either create a new, second waypoint (with waypoint-id = 1) and set it's type to "DISMISSED" or you can simply set the initial waypoint (waypoint-id = 0) to "DISMISSED" and set it to currentWaypoint... (if you're scripting, it's actually generally a good idea to always work on that one initial waypoint; altering it and setting it current over and over again instead of creating and stacking up new waypoints, which is more usefull for non-scripted/editor-only work).

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 :) ).

Edited November 28, 2011 by Nielsen

[DZR_Mikhail 15]

Sound like and awesome addon! I'll test it for sure. Thank you.

[rübe 127]

It seems that if I use 'addwaypoint' instead of 'doMove' then it becomes more complex especially with editor placed civs

Just to be sure, that you've got this right: waypoints "work" on groups only. You can't have a waypoint for a single unit - unless that is a single-unit group of course. So yeah, for individual unit movement/commands, you need to work with doMove et al.

Though, there's a "problem": the very moment a unit completes a doMove (or commandMove), it will be "unitReady" again and thus return to it's group (and to whatever the group is up to). One option would be to doStop a unit the moment a doMove completes.

The other option would be to work with doFSM and inside them you would work with moveTo (and moveToCompleted|moveToFailed). The nice thing about this is that aslong as the FSM executed on a unit by doFSM (or commandFSM) is running, that unit will be not unitReady. Once the FSM has finished, the unit gets unitReady again and return to it's group. This could be quite comfortable to model the "beeing captured" behaviour of civilians.

As you please. :)

[YayForLife 10]

I've got a question about using this for multiplayer missions.

In the editor, it only seems to work for the unit I start the mission as. If I team-switch (Even to a unit in the same squad) then the options are not available to me. Is there some way to make it work with more than one player?

Edit: I just tried the mission in multiplayer, and even the starting player lacks the shift commands. I can still call for POW extraction with all players.

Edited November 28, 2011 by YayForLife

[Reezo 45]

- Reezo: His EOD mod inspired this mod (and peaking his code helped make it possible)

Thanks mate! I really appreciate being in the credits for a mod that really got my attention on the news page!

[PELHAM 10]

Great Mod! If this could be made suitable for Multiplayer it would be one of the greatest. Myself and another guy are working on a coop game mode and he added some interrogate and search add-actions but this does so much more.

[Nielsen 10]

Though, there's a "problem": the very moment a unit completes a doMove (or commandMove), it will be "unitReady" again and thus return to it's group (and to whatever the group is up to). One option would be to doStop a unit the moment a doMove completes.

The other option would be to work with doFSM and inside them you would work with moveTo (and moveToCompleted|moveToFailed). The nice thing about this is that aslong as the FSM executed on a unit by doFSM (or commandFSM) is running, that unit will be not unitReady. Once the FSM has finished, the unit gets unitReady again and return to it's group. This could be quite comfortable to model the "beeing captured" behaviour of civilians.

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?

I've got a question about using this for multiplayer missions.

In the editor, it only seems to work for the unit I start the mission as. If I team-switch (Even to a unit in the same squad) then the options are not available to me. Is there some way to make it work with more than one player?

Edit: I just tried the mission in multiplayer, and even the starting player lacks the shift commands. I can still call for POW extraction with all players.

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.

Thanks mate! I really appreciate being in the credits for a mod that really got my attention on the news page!

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.

Great Mod! If this could be made suitable for Multiplayer it would be one of the greatest. Myself and another guy are working on a coop game mode and he added some interrogate and search add-actions but this does so much more.

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.

[Reezo 45]

No intention to hijack the thread but the creator itself wrote these and I want to reply. Anyone has something against this talk to my lawyer (if you can find him).

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.

It does get the desired effect..because in that module the two variables work differently: _rangeMin is the range people hear your loudspeaker and _rangeMax is how far they move away when being evacuated. This is ..if I can remember correctly but I am pretty sure about it :)

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 . Just an idea.

True, this might make me a final v2.24 sometime soon ;)

[rübe 127]

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.

There is no need for a doMoveCompleted, since doMove is a "high-level" command. To check if a doMove (or any other "high-level" command) has completed, you simply evaluate unitReady _unit. If _unit is ready, no "high-level" command is active anymore. On the other hand, if _unit is currently executing any "high-level" command, it wont be unitReady.

Now if you're going to _unit doFSM [...], then that doFSM (or the FSM as a whole) is your custom "high-level" command. Therefor you can't issue other "high-level" commands inside that FSM. Instead, you need to use "low-level" commands such as moveTo.

Now remember thath the unit will not be unitReady (or in other words the unit will be occupied) for aslong as that FSM is running, then it should be clear, that we can't use unitReady inside such FSMs, it never will be ready. Therefor we have other commands to check if a "low-level" command has been finished or not (see comments/talkpage about doFSM).

If you're going to use "low-level" commands such as moveTo outside of FSMs called by do-/commandFSM, then this won't work aslong as the unit is unitReady - the moveTo will do nothing. But if you'd issue a doStop first, then this would work too. Guess, you need to experiment a little with this, to really get the difference.

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.

I think this would be the most convenient solution. Working with the FSM editor is rather fun anyway :)

Can you suspend (with sleep or waituntil) in an FSM?

You cannot use sleep or waitUntil inside FSMs. And that's not needed anyway most of the time (or aslong as you only have a few easy conditions).

But if you want to slow down (or suspend) a FSM, you can simply construct a loop that will be choosen after all other (expensive) conditions have failed (no condition, lowest priority), then you go to an extra "delay" state, where you remember the current time (_t = time;) and then you need one outgoing path back to the main loop (with all the conditions) with the condition that current-time - _t is bigger than the desired delay-time.

Just study some BIS FSMs. They use them all over the place in the official missions and campaigns.

[sv5000 127]

This is an epic addon, great work Thanks!

[Nielsen 10]

the creator itself

I would'nt go that far .

It does get the desired effect..because in that module the two variables work differently: _rangeMin is the range people hear your loudspeaker and _rangeMax is how far they move away when being evacuated. This is ..if I can remember correctly but I am pretty sure about it :)

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.

True, this might make me a final v2.24 sometime soon ;)

That would be great. Fingers crossed x--0--x

There is no need for a doMoveCompleted, since doMove is a "high-level" command. To check if a doMove (or any other "high-level" command) has completed, you simply evaluate unitReady _unit. If _unit is ready, no "high-level" command is active anymore. On the other hand, if _unit is currently executing any "high-level" command, it wont be unitReady.

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.

Now if you're going to _unit doFSM [...], then that doFSM (or the FSM as a whole) is your custom "high-level" command. Therefor you can't issue other "high-level" commands inside that FSM. Instead, you need to use "low-level" commands such as moveTo.

Now remember thath the unit will not be unitReady (or in other words the unit will be occupied) for aslong as that FSM is running, then it should be clear, that we can't use unitReady inside such FSMs, it never will be ready. Therefor we have other commands to check if a "low-level" command has been finished or not(...)

If you're going to use "low-level" commands such as moveTo outside of FSMs called by do-/commandFSM, then this won't work aslong as the unit is unitReady - the moveTo will do nothing. But if you'd issue a doStop first, then this would work too. Guess, you need to experiment a little with this, to really get the difference.

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.

I think this would be the most convenient solution. Working with the FSM editor is rather fun anyway

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.

You cannot use sleep or waitUntil inside FSMs. And that's not needed anyway most of the time (or aslong as you only have a few easy conditions).

But if you want to slow down (or suspend) a FSM, you can simply construct a loop that will be choosen after all other (expensive) conditions have failed (no condition, lowest priority), then you go to an extra "delay" state, where you remember the current time (_t = time;) and then you need one outgoing path back to the main loop (with all the conditions) with the condition that current-time - _t is bigger than the desired delay-time.

Just study some BIS FSMs. They use them all over the place in the official missions and campaigns.

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?

Edited November 29, 2011 by Nielsen

[rübe 127]

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.

You could always see how great the distance from the unit to the commanded position is, the moment unitReady get's true... But since movement-precision in ArmA is rather awful (see here for example), I doubt you could realiably tell if a unit "arrived" or not - even with the low-level set of commands: moveTo, moveToCompleted and moveToFailed... (personally I never care and always assume the unit has succeded, so the script/fsm can go on, no matter what...)

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?

As a rule of thumb all this "high-level" and "low-level" talk only relates to move commands. You can do-/commandWatch, doFire (really? not sure about this, hehe - commandFire could lead to do-/commandMove's to target...hm. I'm sorry, the Arma-engine is a tricky bitch, hehe) and stuff anywhere you like. And if in doubt, just give it a try. :)

... wait... no. The rule of thumb is: if ia command leads the unit to not be unitReady, then don't use it while/inside do-/commandFSM. That was it, no? ;)

Edited November 29, 2011 by ruebe

[YayForLife 10]

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.

This actually solves my problem. :)

To clarify, I was testing it in multiplayer on my own (I hosted a LAN game and just respawned as different units to test it all out).

If it works for each player at the start of the mission, that should be fine. A little annoying, but not mission breaking.

In any case, the addon is great, I love it!

One more question, though:

Is there a way to change the script so the extraction can be marked with any colour of smoke, as opposed to just one? I usually find that I run out of smoke for an individual colour pretty quickly.

[pellejones 1]

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?

1. Single player, ACE2 with all extra stuff. ACRE, JayArma2Lib. ShacTac movement, a few extra islands and units.

2. Let hem finish and then fall down :)

SSG did a dedicated server test yesterday with EOD at the same time. CIM does not work as it should on dedicated. We had a look at your code and we think that "publicVariable" is the problem. That command does not translate well to dedicated servers.

This is what does not happen:

1) The handcuff anim does not work.

2) They do not go inside, they just stop at the doors.

The rest seems to work.

You should use CBA for global commands, that should work. PublicVariable does not send to all clients I think.

[Nielsen 10]

... wait... no. The rule of thumb is: if ia command leads the unit to not be unitReady, then don't use it while/inside do-/commandFSM. That was it, no? ;)

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?

Is there a way to change the script so the extraction can be marked with any colour of smoke, as opposed to just one? I usually find that I run out of smoke for an individual colour pretty quickly.

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. :)

1. Single player, ACE2 with all extra stuff. ACRE, JayArma2Lib. ShacTac movement, a few extra islands and units.

2. Let hem finish and then fall down :)

SSG did a dedicated server test yesterday with EOD at the same time. CIM does not work as it should on dedicated. We had a look at your code and we think that "publicVariable" is the problem. That command does not translate well to dedicated servers.

This is what does not happen:

1) The handcuff anim does not work.

2) They do not go inside, they just stop at the doors.

The rest seems to work.

You should use CBA for global commands, that should work. PublicVariable does not send to all clients I think.

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!

Edited November 30, 2011 by Nielsen

[UGLY58 10]

Nice work,

Played with this tonight and coupled with Rezzoz EOD mod awesome !

CBA would help you a lot on the public variable issue. I found as well that even locally the civilians eventually get stuck in the Handcuff position

[Nielsen 10]

Nice work,

Played with this tonight and coupled with Rezzoz EOD mod awesome !

CBA would help you a lot on the public variable issue. I found as well that even locally the civilians eventually get stuck in the Handcuff position

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?

[pellejones 1]

Ok another test done. 30 players using CIM.

The only two things that works is handcuff, the AI stands still but the anim does not work.

The second is to make them join the group and also leave. That one works.

Get on ground etc. does not work.

[Nielsen 10]

Ok another test done. 30 players using CIM.

The only two things that works is handcuff, the AI stands still but the anim does not work.

The second is to make them join the group and also leave. That one works.

Get on ground etc. does not work.

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.

Edited December 1, 2011 by Nielsen
New version out

[bad benson 1733]

would it be possible to fix the default intel system or maybe even make a new one? it would be awesome if u could ask civs for enemy positions and they would mark them on the map if they had seen some like friendly units do (those static markers of last known positions). or even better would be to make the civs point in the direction with some kind of pointing anim. just an idea. love what u have done so far.