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

Feature Request: ACE Arsenal #1

Closed
dedmen opened this issue Apr 24, 2018 · 6 comments
Closed

Feature Request: ACE Arsenal #1

dedmen opened this issue Apr 24, 2018 · 6 comments

Comments

@dedmen
Copy link

dedmen commented Apr 24, 2018

Features: acemod/ACE3#5734
Stats: acemod/ACE3#6110
https://ace3mod.com/wiki/feature/arsenal.html
https://ace3mod.com/wiki/framework/arsenal-framework.html

Full arsenal is easy to implement

["Open", true] call bis_fnc_arsenal;

->
[player, player, true] call ace_arsenal_fnc_openBox

The limited arsenal variant is slightly different. ACE Arsenal takes array of all Classnames without categorization. I think BI arsenal does things differently in that regard.

If ACE Arsenal is used then

["Preload"] call bis_fnc_arsenal;

is not needed.
and
_unit addAction [localize "STR_DOM_MISSIONSTRING_1585", {["Open",[true,nil,param [0]]] call bis_fnc_arsenal}, [], -1, false, true, "", "true", 3];

should also be replaced.

@Xeno69 Xeno69 closed this as completed in b36c91d May 1, 2018
@dedmen
Copy link
Author

dedmen commented May 1, 2018

The limited arsenal variant is slightly different. ACE Arsenal takes array of all Classnames without categorization. I think BI arsenal does things differently in that regard.

You definitely should not modify a static variable that is computed at gameStart.

https://ace3mod.com/wiki/framework/arsenal-framework.html#11-adding-virtual-items

@Xeno69
Copy link
Owner

Xeno69 commented May 1, 2018

First of all, uiNamespace variables are getting recreated each time a player connects to a server (because of security concerns, was changed during A2/OA times).

Second, BI does it correctly and puts the virtual arsenal classes into a variable in mission namespace (ace does the same just not mission namespace).
It is never a good idea to just hope that third party users do not change those public variables.

@dedmen
Copy link
Author

dedmen commented May 1, 2018

First of all, uiNamespace variables are getting recreated each time a player connects to a server (because of security concerns, was changed during A2/OA times).

Nope. Not at all. missionNamespace yes. But none of the other namespaces.

Second, BI does it correctly and puts the virtual arsenal classes into a variable in mission namespace (ace does the same just not mission namespace).

ACE arsenal does it so it doesn't have to rescan items each mission restart. Allowing for instant arsenal open without any preloading.
The ACE thing is completly different. It's a list of all existing Items in config. Selecting which items should be displayed is done later.

It is never a good idea to just hope that third party uses do not change those public variables.

Yeah sorry. Oversight by me. I already notified the arsenal author to decide if we should compileFinal that variable in the next update.

Xeno69 pushed a commit that referenced this issue May 1, 2018
@Xeno69
Copy link
Owner

Xeno69 commented May 2, 2018

Believe me, uiNamespace gets deleted when a player connects to a server otherwise one could change whatever he likes in uiNamespace in the single player editor, change scripts or whatever and do nasty things once connected.

It was a major security issue during OA times and BI changed it back then.

Compilefinal is also not a solution.
The extDB3 author added a compileFinal to the only public variable the mod has and broke all missions using it because it was no longer a boolean variable but code.

Anyway, if there is an easier solution to clean the ace arsenal array let me know.

Best solution would be to make the variable a normal mission namespace variable, that would only be filled if needed once per mission.

@dedmen
Copy link
Author

dedmen commented May 2, 2018

The extDB3 author added a compileFinal to the only public variable the mod has and broke all missions using it because it was no longer a boolean variable but code.

Not a concern. no-one should be accessing that variable. And if someone does... His fault.

Believe me, uiNamespace gets deleted when a player connects to a server

I will believe you if you tell me why ACE arsenal works at all if the variable that only get's created once at gameStart gets deleted before being accessed.

Or how all my mods variables are always in uiNamespace although I only set them once at gamestart. If uiNamespace gets deleted like you say. Explain me how the variables keep existing.

Best solution would be to make the variable a normal mission namespace variable, that would only be filled if needed once per mission.

https://ace3mod.com/wiki/framework/arsenal-framework.html#11-adding-virtual-items That is how it works. And works about the same as BI arsenal.

It might very well be like that in OA. But not in A3.

@commy2
Copy link

commy2 commented May 2, 2018

Believe me, uiNamespace gets deleted when a player connects to a server otherwise one could change whatever he likes in uiNamespace in the single player editor, change scripts or whatever and do nasty things once connected.

This is demonstrably wrong. In fact, this not being the case is the only reason compileFinal exists: to cache the functions library in ui namespace while at the same time be unable to inject arbitrary code.

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

No branches or pull requests

3 participants