Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setCaptive compatibility / implement _fnc_setCaptivityStatus #542

Closed
Feivel69 opened this issue Jul 21, 2014 · 8 comments
Closed

setCaptive compatibility / implement _fnc_setCaptivityStatus #542

Feivel69 opened this issue Jul 21, 2014 · 8 comments
Assignees
Labels
Milestone

Comments

@Feivel69
Copy link

Hello!

The setCaptive-command doesn't work, when using AGM. I tested it several times with all other addons/mods deactivated except AGM and vice versa.

Reproduce:
1.Place Bluefor-Unit -> Init: this setCaptive true;
2.Place Opfor-Unit in Bluefor-Unit's front
3.Opfor will shoot Bluefor

@Trigger81
Copy link

Can confirm this

@commy2
Copy link
Collaborator

commy2 commented Jul 21, 2014

null = this spawn {waitUntil {_this setCaptive true; time > 5}};

@commy2
Copy link
Collaborator

commy2 commented Jul 21, 2014

@KoffeinFlummi
Maybe you should use the alternative syntax of setCaptive:

https://community.bistudio.com/wiki/setCaptive
https://community.bistudio.com/wiki/captiveNum

@commy2 commy2 added this to the Version 0.93 milestone Jul 21, 2014
@nicolasbadano
Copy link
Collaborator

I've seen this the other day when testing the command. The problem lies in the medical system, which currently uses setsCaptive false for every unit on init.

@Feivel69, the syntax by @commy2 is a workaround for now, but the setcaptive state will be lost if the unit is knocked unconcious and then healed

@KoffeinFlummi
Copy link
Owner

I was thinking about this the other day...

We use setCaptive in multiple places, so why don't we adopt a sort-of bitmask system for it? That would prevent this from happening.

@nicolasbadano
Copy link
Collaborator

Yes, that sounds good. However, probably using setCaptive = true on mission scripts would still break the system. Mission makers should adapt things to use some reserved bit/s.

Or even better, we could expose a custom setCaptive function for them to use, where you pass as argument the reason of the captivity and it sets the bits automatically. E.g.:

[_unit, "AGM_Captive_Prisoner"] call AGM_Interaction_fnc_setCaptive;

and

_unit call AGM_Interaction_fnc_getCaptive

returning the reasons of captivity: ["AGM_Captive_Unconcious", "AGM_Captive_Prisoner", "AGM_Captive_MissionCustom1"]

@commy2
Copy link
Collaborator

commy2 commented Jul 21, 2014

I working on what @esteldunedain suggested.

@commy2
Copy link
Collaborator

commy2 commented Jul 21, 2014

Now all we have to do is make use of the new function. Assigning to Flummi because I never used setCaptive anywhere.

Syntax: (e.g. Handcuffing)

// to handcuff
[this, "MyTag_Handcuffed", true] call AGM_Interaction_fnc_setCaptivityStatus;

// to uncuff
[this, "MyTag_Handcuffed", false] call AGM_Interaction_fnc_setCaptivityStatus;

// is this unit handcuffed?
_isHandcuffed = "MyTag_Handcuffed" in ([_unit] call AGM_Interaction_fnc_getCaptivityStatus);

Edit:
This should be a CBA or even BIS function btw. Wouldn't be surprised if there is one already,,,

@commy2 commy2 added the task label Jul 21, 2014
@commy2 commy2 changed the title setCaptive doesn't work setCaptive compatibility / implement _fnc_setCaptivityStatus Jul 21, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants