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

Cargo - Support of object without ace_cargo_size defined in config or -1 config value #6364

Merged
merged 7 commits into from
Jun 1, 2018
Merged

Cargo - Support of object without ace_cargo_size defined in config or -1 config value #6364

merged 7 commits into from
Jun 1, 2018

Conversation

Vdauphin
Copy link
Contributor

@Vdauphin Vdauphin commented May 23, 2018

close #6357

Actually, if _typeofcargo does not have ace_cargo_size define in config, the _radiusOfItem of the object is 1. This inconsistency can be avoid by using the ace_cargo_fnc_getSizeItem which take an object as parameter and get the size of the object defined manually by user ( ace_cargo_fnc_setsize).

By having a _radiusOfItem more accurate, the ace_common_fnc_findUnloadPosition will find better position for unloading and avoid vehicle explosion when big objects, without ace_cargo_size defined in config, are unloaded.

I don't know if it is the best way to handle this case but at least it is a work around. Cheers.

When merged this pull request will:

  • ace_common_fnc_findUnloadPosition can take object as parameter
  • Prefer the config way instead to determine the size of _cargo directly with ace_cargo_fnc_getSizeItem (this avoid inconsistency when player ace_cargo_fnc_setsize of an object lower from the ace_cargo_size defined in config)
  • Also check if the config value is not -1 to avoid the issue: Offest for large containers too small when being unloaded from trucks #6357 (comment)
  • If ace_cargo_size is not define in config, use the ace_cargo_fnc_getSizeItem to get object size set by player with ace_cargo_fnc_setsize
  • Update the ace_cargo_fnc_unloadItem accordingly (use the cargo object instead of the class name).

- use of ace_cargo_fnc_getSizeItem to determine size of item

- prefer the config way instead of manually set size

- This will also take into account object manually added to the cargo system with ace_cargo_fnc_setsize

- use the cargo object for ace_cargo_fnc_unloadItem.
private _itemSize = if (isNumber (configFile >> "CfgVehicles" >> _typeOfCargo >> QEGVAR(cargo,size))) then {
getNumber (configFile >> "CfgVehicles" >> _typeOfCargo >> QEGVAR(cargo,size));
} else {
[_cargo] call EFUNC(cargo,getSizeItem);
Copy link
Contributor

Choose a reason for hiding this comment

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

there is error here if cargo module is no loaded

Copy link
Contributor Author

Choose a reason for hiding this comment

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

[[_cargo] call EFUNC(cargo,getSizeItem)] param [0, _radiusOfItem]; could resolve that issue.

Copy link
Contributor

Choose a reason for hiding this comment

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

I meant if cargo module is not loaded there is no EFUNC(cargo,getSizeItem) and you call non-existing function

Copy link
Contributor Author

@Vdauphin Vdauphin May 24, 2018

Choose a reason for hiding this comment

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

I just learned in scheduled EFUNC(cargo,getSizeItem) will trow an undefined variables error which is not the case in unscheduled.
If you guys are using an other approach, let me know, I will use it for consistency.

Copy link
Member

Choose a reason for hiding this comment

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

if (["ace_backpacks"] call EFUNC(common,isModLoaded)) then {

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks!

@PabstMirror
Copy link
Contributor

For safety we could take the max of both numbers

This fix handle the case when cargo module is not loaded for scheduled and unscheduled environnement.
if (isNumber (configFile >> "CfgVehicles" >> _typeOfCargo >> QEGVAR(cargo,size))) then {
_radiusOfItem = (((getNumber (configFile >> "CfgVehicles" >> _typeOfCargo >> QEGVAR(cargo,size))) ^ 0.35) max 0.75);
private _typeOfCargo = if (_cargo isEqualType "") then {_cargo} else {typeOf _cargo};
private _itemSize = if (isNumber (configFile >> "CfgVehicles" >> _typeOfCargo >> QEGVAR(cargo,size))) then {
Copy link
Contributor

Choose a reason for hiding this comment

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

this code piece already exists in EFUNC(cargo,getSizeItem), so can be optimized well

Copy link
Contributor Author

@Vdauphin Vdauphin May 25, 2018

Choose a reason for hiding this comment

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

I did a choice here as explain in the PR description:

Prefer the config way instead to determine the size of _cargo directly with ace_cargo_fnc_getSizeItem (this avoid inconsistency when player ace_cargo_fnc_setsize of an object lower from the ace_cargo_size defined in config)

I can add a parameter in EFUNC(cargo,getSizeItem) to prefer the config if exist or prefer varaible if exist

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am supposing that ace_cargo_size in config is correct so if I am calling EFUNC(cargo,getSizeItem) and if player has ace_cargo_fnc_setsize an other value (a smaller one for exemple) the function will return a bad position base on a wrong value changed by player. This avoid that case and also cover the objective of this PR where ace_cargo_size in config is not defined.

private _itemSize = if (isNumber (configFile >> "CfgVehicles" >> _typeOfCargo >> QEGVAR(cargo,size))) then {
getNumber (configFile >> "CfgVehicles" >> _typeOfCargo >> QEGVAR(cargo,size));
} else {
if (["ace_cargo"] call EFUNC(common,isModLoaded)) then {
Copy link
Contributor

Choose a reason for hiding this comment

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

EFUNC(common,isModLoaded) -> FUNC(isModLoaded)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

EFUNC(common,isModLoaded) -> ace_common_fnc_isModload
FUNC(isModLoaded) -> ace_cargo_fnc_isModload

Because the second doesn't exist I am using the first one as suggested by @jonpas here: #6364 (comment)

Copy link
Contributor

Choose a reason for hiding this comment

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

here we are in common module (addons/common/functions/fnc_findUnloadPosition) so FUNC is ace_common_fnc

Copy link
Contributor Author

Choose a reason for hiding this comment

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

woups!!!

_radiusOfItem;
};
};
if !(_itemSize isEqualTo -1) then {
Copy link
Contributor

Choose a reason for hiding this comment

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

just _itemSize != -1

Copy link
Contributor Author

Choose a reason for hiding this comment

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

With isEqualTo you can compare different type like: nil isEqualTo -1 so the function will never fail

It doesn't throw error when comparing different types, i.e. ("eleven" isEqualTo 11)
But, if ace use it as convention I will change it.

Copy link
Contributor

Choose a reason for hiding this comment

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

_itemSize here is always number

};
};
if !(_itemSize isEqualTo -1) then {
_radiusOfItem = (_itemSize ^ 0.35) max 0.75;
Copy link
Contributor

Choose a reason for hiding this comment

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

most significant change: before this PR if cargo module is not loaded _radiusOfItem was 1 and now it becomes (1 ^ 0.35) max 0.75.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ahah! I didn't know we could make joke in review!
Thanks a lot for the time you take to review this :-), I appreciate your feedback!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

(1 ^ 0.35) max 0.75 = 1 max 0.75 = 1

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry I thought you were ironical :/

- _itemSize here is always number
- here we are in common module (addons/common/functions/fnc_findUnloadPosition) so FUNC is ace_common_fnc
@Vdauphin Vdauphin mentioned this pull request May 25, 2018
10 tasks
@Vdauphin
Copy link
Contributor Author

For safety we could take the max of both numbers

@PabstMirror
I presume the config value is the perfect value for the ace_common_fnc_findUnloadPosition.
If user change to a higher, the object could be no more unloadable because the ace_common_fnc_findUnloadPosition will return an [].

The value give by user should only be use if no config value is available.

Vdauphin added a commit to Vdauphin/HeartsAndMinds that referenced this pull request May 30, 2018
- this is correcting the unloading position with the ace_cargo_size define as variable
- this can be removed when: acemod/ACE3#6364  is merged
- if the config value is -1, get the `ace_cargo_size` from the `ace_cargo_fnc_getSizeItem
-
 #6357 (comment)
@Vdauphin Vdauphin changed the title Cargo - Support of object without ace_cargo_size defined in config Cargo - Support of object without ace_cargo_size defined in config or -1 config value May 31, 2018
@PabstMirror PabstMirror added this to the 3.13.0 milestone Jun 1, 2018
@PabstMirror PabstMirror added the kind/bug-fix Release Notes: **FIXED:** label Jun 1, 2018
@PabstMirror
Copy link
Contributor

looks good, it does require that people set reasonable cargo sizes for items they load

@PabstMirror PabstMirror merged commit f994365 into acemod:master Jun 1, 2018
@Vdauphin Vdauphin deleted the Extend_findUnloadPosition_to_object branch June 1, 2018 06:24
@PabstMirror PabstMirror modified the milestones: 3.13.0, 3.12.3 Jul 5, 2018
BaerMitUmlaut pushed a commit that referenced this pull request Aug 5, 2019
…or `-1` config value (#6364)

* Add: Now findUnloadPosition support also cargo object

- use of ace_cargo_fnc_getSizeItem to determine size of item

- prefer the config way instead of manually set size

- This will also take into account object manually added to the cargo system with ace_cargo_fnc_setsize

- use the cargo object for ace_cargo_fnc_unloadItem.

* FIX: old work around

* FIX: error when cargo module is not loaded

* As suggested by @orbis2358

This fix handle the case when cargo module is not loaded for scheduled and unscheduled environnement.

* Use ACE framework to check if module is present

* FIX: EFUNC and isEqualto

- _itemSize here is always number
- here we are in common module (addons/common/functions/fnc_findUnloadPosition) so FUNC is ace_common_fnc

* FIX case where config value is `-1`

- if the config value is -1, get the `ace_cargo_size` from the `ace_cargo_fnc_getSizeItem
-
 #6357 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug-fix Release Notes: **FIXED:**
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Offest for large containers too small when being unloaded from trucks
4 participants