Civilian Interaction Module (beta)

[Nielsen]

when I drop a smoke the helicopter doesn't land but fly back to its initial position. My suggestion if it's possible to add an option where the helicopter I want it land by clik-map or somethingelse.

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

Very intersting.

Two questions:
1. Do released civilians re-join their original group they were in before arresting them?
2. (More of a feature request: ) would it be possible to use this module to fix the broken standard conversations (Location? Targets? Weather? ...) between player and AI?

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.

[zwobot]

1. No. At the moment they join "grpNull". [...] What do you think?

Depends on the situation. Could be that the released civilian wants to get back to his buddies quickly after having been released. On the other hand he/she might be a bit disoriented and clueless and just stand there...

Follow up question: how does this feature connect with the ALICE module, i. e. are released civilians handed back to ALICE (I don't know if this is even possible).

It would be nice to have it as optional setting if it wouldn't be too messy to keep track which group a civilian was detained from or would it be sufficient to only setVariable the original group of detained units on the unit itsself?

2. I have not looked into the conversation system, so I dont know how hard that would be.

I found the conversation system hard to get to grips with in the beginning. Once you understood how it works it is quite powerful and I think it is a pity that it is not working for Arma2 units anymore and that the default version was not thought through to the end, e. g. you cannot configure language skills of the units. So as Blufor Army unit you can not talk to Takistani civilians because they don't understand you.
This could be fixed with a community made addon I reckon.

Have you thought about a scripted version of your module which would not require an addon?

[ruebe]

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?

Joining grpNull is a bad idea, since this will create a new group each time. So you end up with one-unit groups for no good reason. So either rejoin them to their original group (remembered with setVariable on the unit) or create a single group the first time it's needed (dismissed waypoint) and then join them to that group from now on...
The second option could be better, since it's not guaranteed, that the original group still exists... so you could run into problems there (without further checks). Or do both and use that specific "released people"-group as a fallback maybe. Or something.

As for the running away: forceWalk and forceSpeed (for some time after release) could do the trick.

Otherwise this looks very promising.
Tweak on!

[Nielsen]

Depends on the situation. Could be that the released civilian wants to get back to his buddies quickly after having been released. On the other hand he/she might be a bit disoriented and clueless and just stand there...

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.

Follow up question: how does this feature connect with the ALICE module, i. e. are released civilians handed back to ALICE (I don't know if this is even possible).

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.

It would be nice to have it as optional setting if it wouldn't be too messy to keep track which group a civilian was detained from or would it be sufficient to only setVariable the original group of detained units on the unit itsself?

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.

I found the conversation system hard to get to grips with in the beginning. Once you understood how it works it is quite powerful and I think it is a pity that it is not working for Arma2 units anymore and that the default version was not thought through to the end, e. g. you cannot configure language skills of the units. So as Blufor Army unit you can not talk to Takistani civilians because they don't understand you.
This could be fixed with a community made addon I reckon.

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:

Have you thought about a scripted version of your module which would not require an addon?

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:

Joining grpNull is a bad idea, since this will create a new group each time. So you end up with one-unit groups for no good reason. So either rejoin them to their original group (remembered with setVariable on the unit) or create a single group the first time it's needed (dismissed waypoint) and then join them to that group from now on...
The second option could be better, since it's not guaranteed, that the original group still exists... so you could run into problems there (without further checks). Or do both and use that specific "released people"-group as a fallback maybe. Or something.

As for the running away: forceWalk and forceSpeed (for some time after release) could do the trick.

Otherwise this looks very promising.
Tweak on!

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?

[the chief]

Tried today with ACE2 and EOD mods. All worked well. Excellent mod. Thanks and keep up the work.

[ruebe]

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]

Awesome addon. Brilliant.

[Pellejones]

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]

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

[ruebe]

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