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

Experiment on disarming #1621

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nicolasbadano
Copy link
Collaborator

Do not merge

This is not a real PR yet, but a way to see if there's any way to make this happen.

Here's the problem: the weapon classes never change, even if you remove the attachments. So if you disarm a guy who left the weapon attachments at home you still get a fresh weapon with all the attachments defined in the config. Commands to add/remove attachment from weapons stored on cargo (e.g. weaponholder) doesn't seem to exist. Neither for making a unit drop his weapon.

The only alternative I could think of is looking up the class hierarchy of the weapon and try to spawn the same weapon without attachments, but that may not be very reliable.

Any ideas??

@commy2 commy2 added the WIP label Nov 29, 2014
@commy2
Copy link
Collaborator

commy2 commented Nov 29, 2014

Just add the WIP tag and we know it isn't ready for merging.

@commy2
Copy link
Collaborator

commy2 commented Nov 29, 2014

This might be what you are looking for:

"arifle_mx_aco_pointer_f" call BIS_fnc_weaponComponents;
-> ["arifle_mx_f","optic_aco","acc_pointer_ir"]

@nicolasbadano
Copy link
Collaborator Author

This might be what you are looking for:

That's exactly it! Thanks

BTW, do you see any other potential problem?

@commy2
Copy link
Collaborator

commy2 commented Nov 29, 2014

Yes.

It's a BIS function after all. They use:
if (_weapon == "laserdesignator" || _weapon == "rangefinder") exitWith {[_weapon]};

Which leads to this miscalculation:

"agm_vector" call BIS_fnc_weaponComponents;
-> ["binocular"]

@nicolasbadano
Copy link
Collaborator Author

That's not a problem, I'll only use this for actual weapons.

Just a quick question. Any way to put items inside a vest before putting it into the weaponholder?

@commy2
Copy link
Collaborator

commy2 commented Nov 29, 2014

Another issue:
If an addon doesn't have a usable "plain" weapon (no attachments), it might return something like "rifle_base_f".

Any way to put items inside a vest before putting it into the weaponholder?

I don't think so.

@nicolasbadano
Copy link
Collaborator Author

If an addon doesn't have a usable "plain" weapon (no attachments), it might return something like "rifle_base_f".

Too bad. That is what I feared might happen if I did that myself.

Regardless of scripting commands not existing, the engine has to have a way of dealing with this. If you remove the attachments of a weapon and put it on a box it still has the previous class but it doesn't carry attachments if you pick it up again. Maybe there's some way of tapping into that.

@commy2
Copy link
Collaborator

commy2 commented Nov 29, 2014

You could always spawn invisible, invulnurable dummy AIs and do action "DropWeapon", "DropMagazine", "DropBag" with them. This was used by ACE often in A2.
The issue however is, that those actions are now linked to animations that have to finish before anything is dropped. Those animations won't finish often for some reason, so you always have to have a backup plan. Really dodgy stuff and I gave up on it in the end.

@jonpas
Copy link
Contributor

jonpas commented Nov 29, 2014

Any way to put items inside a vest before putting it into the weaponholder?

There are the following commands for putting into clothing containers:
addItemToVest, addItemToUniform, addItemToBackpack
And then you also have checks for that:
canAddItemToVest, canAddItemToUniform, canAddItemToBackpack

I have no idea how attachments work with this command, but it was working for me for everything else that has that config value (can't remember which) set to 1, meaning it can be put into clothing.

@commy2
Copy link
Collaborator

commy2 commented Nov 29, 2014

addItemToVest, addItemToUniform, addItemToBackpack

Those require the vest/uniform/backpack to be assigned to a unit.

With backpacks you could maybe use the addXXXCargoGlobal family of commands, because you can actually get the backpack subcontainer via firstBackpack and everyBackpack.
There are no such commands for vests and uniforms though.

@nicolasbadano
Copy link
Collaborator Author

Those require the vest/uniform/backpack to be assigned to a unit.

Exactly

With backpacks you could maybe use the addXXXCargoGlobal family of commands, because you can actually get the backpack subcontainer via firstBackpack and everyBackpack.
There are no such commands for vests, uniforms.

Backpacks are easy, cause you can force them to fall to the ground by adding a new one and then removing it. You cannot do that with vests.

@jonpas
Copy link
Contributor

jonpas commented Nov 29, 2014

Not sure if I understand, but you would be looking at the unit when disarming it I guses, so you could just do:
target addItemToXXX "itemClassname";

@nicolasbadano
Copy link
Collaborator Author

Not sure if I understand, but you would be looking at the unit when disarming it I guses, so you could just do:
target addItemToXXX "itemClassname";

Yes, but there's no command to drop the XXX to the ground after that

@nicolasbadano
Copy link
Collaborator Author

BIS_fnc_weaponComponents is basically useless. To work properly, it requires that every weapon inherits directly from the base version without attachments: that must be the inmediate parent. You cannot inherit from any other variant with any attachment.

I'm quite sure that might not be the case with way to many addons weapons.

@jonpas
Copy link
Contributor

jonpas commented Nov 29, 2014

Ah I see, didn't understand what exactly was wanted.

@commy2
Copy link
Collaborator

commy2 commented Nov 29, 2014

You cannot inherit from any other variant with any attachment.

Thats sad. We could write a better function, but that doesn't guarantee that there even is a base version without attachments.

@jonpas
Copy link
Contributor

jonpas commented Nov 29, 2014

Hmm, I have an idea.
The attachment(s) version always just has something added between weapon and "F", as in the string of the class name. Wouldn't that make it possible to remove the part of the string dynamically?

For example:
Base - srifle_EBR_F
ACO - srifle_EBR_ACO_F
MRCO+IR - srifle_EBR_MRCO_pointer_F

It's not same for all weapons, for example MXSW has arifle_MX_SW_F, making it 2 underscores before the attachments part.
I will guess and say it would have to be hardcoded and that's not something anyone wants... ever.

@commy2
Copy link
Collaborator

commy2 commented Nov 29, 2014

That would be even more unreliable with third party addons. BWA3 for example uses:
BWA3_G36_equipped: BWA3_G36.

BIS_fnc_weaponComponents already works with any weapons from A3 (or atleast I hope so...), but it's just not reliable.

@commy2
Copy link
Collaborator

commy2 commented Nov 29, 2014

Okay. I broke it:

"arifle_MX_black_F" call BIS_fnc_weaponComponents
-> ["arifle_mx_f"]

@nicolasbadano
Copy link
Collaborator Author

Okay I broke it:

Great. I didn't expected less from you

@nicolasbadano
Copy link
Collaborator Author

Ok, I think the only sensible thing left to try is to write a nice bug report and see if bux can get it looked at though twitter. Probably request a command to add a weapon as cargo with an array of attachments.

BTW, this same problem exists for secondary weapons and pistols

@commy2
Copy link
Collaborator

commy2 commented Nov 29, 2014

I made this one:

/*
 * Author: commy2, based on function by Jiri Wainar
 *
 * Description:
 * Returns array with classname of the plain weapon (without attachments), followed by classnaes of all attachments.
 * All classnames returned are converted to lowercase.
 * Should there be no plain version of the weapon, the weapon with attachments plus all attachments will be returned instead.
 *
 * Argument(s):
 * 0: classname of any weapon (String)
 *
 * Return value:
 * ID of the action (used to remove it later).
 *
 * Example:
 * "arifle_mx_aco_pointer_f" call BIS_fnc_weaponComponents;
 * -> ["arifle_mx_f","optic_aco","acc_pointer_ir"]
 *
 */

private ["_weapon","_config","_attachments"];

_weapon = [_this,0,"",[""]] call bis_fnc_param;

_config = configfile >> "CfgWeapons" >> _weapon;

// return empty array if the weapon doesn't exist
if (!isClass _config) exitWith {[]};

// get attachments
_attachments = [];
{
  _attachments pushBack toLower getText (_x >> "item");
} forEach ("true" configClasses (_config >> "LinkedItems"));

// get first parent without attachments
while {isClass _config} do {
  if (getNumber (_config >> "scope") != 2) exitWith {};

  if (count (_config >> "LinkedItems") == 0) exitWith {_weapon = toLower configName _config};

  _config = inheritsFrom _config;
};

[_weapon] + _attachments

Seems to work better. Should there be no attachment free parent, it will return the given weapon + attachments instead...

_unit = _this select 0;
_guard = _this select 1;

_allGear = [
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reminder: Move AGM_Respawn_fnc_getAllGear to Core.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants