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.

Sign up for GitHub

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

Jump to bottom

Improve selective UI API #3805

Merged
merged 7 commits into from
Jun 2, 2016
Merged

Improve selective UI API #3805

merged 7 commits into from
Jun 2, 2016

Conversation

jonpas
Copy link
Member

@jonpas jonpas commented May 20, 2016 •
edited
Loading

When merged this pull request will:

  • Use config class ACE_UI instead of hardcoding elements
  • Improve Selective UI API (setElementVisibility), can now be called by ACE_UI config class name from already preset options to prevent issues:
[true, "ammoCount", false] call ace_ui_fnc_setElementVisibility;
  • Add "InterfaceInitialized" event, executed when basic UI stuff is loaded and set from ui component
["InterfaceInitialized", {
    [true, "ammoCount", false] call ace_ui_fnc_setElementVisibility;
}] call ace_common_fnc_addEventHandler;
  • Fix elements getting overwritten due to multiple executions of "infoDisplayChanged" event (executed 3 times when on foot) with some logical comparisons with GVAR(elementsSet) - connected to API as well
  • Disable ammo count UI in reload component using Selective UI API
  • Add hint when setting has been forced by API when trying to change it via ACE Options menu
  • Fixes Stance UI not respecting settings (missing infoDisplayChanged event) - replaces UI - Delay a frame before adjusting advanced #3806
  • Separates settings that share IDCs for on-foot and in-vehicle (eg Improve selective UI API #3805 (comment))
  • Disable gunner weapon zeroing UI in fcs component (actually just marks it as it is hidden by other config which is necessary for FCS to work)

@jonpas jonpas added the kind/enhancement Release Notes: **IMPROVED:** label May 20, 2016
@jonpas jonpas added this to the 3.6.0 milestone May 20, 2016
@jonpas jonpas changed the title Improve selective UI API, Disable ammo count when reload component is… Improve selective UI API and disable ammo count from reload component May 20, 2016
@jonpas jonpas mentioned this pull request May 20, 2016
Closed
@PabstMirror
Copy link
Contributor

Not specific to this PR, but right now we hide ammo counts for all vehicles.
In 3.5.1 we only hide it while on foot.

image

@jonpas
Copy link
Member Author

jonpas commented May 23, 2016

It was introduced with Selective UI, I will look into that.

@jonpas
Upgrade Selective UI framework for controls that share IDCs for gunne…
26ee74c 
…r and soldier
@jonpas
Separate more soldier and gunner settings sharing same IDCs, Remove v…
a3d0867 
…ehicle gunner weapon which has no effect anymore
@jonpas
Separate more soldier and gunner IDC sharing elements, Fix typo, Fix …
6ab7532 
…API setting not being respected in case where selective type is not the same on load
@jonpas
Copy link
Member Author

jonpas commented May 24, 2016

@PabstMirror should be fixed, gunner and soldier elements are now separated (were using same IDCs, because thanks amazing config).

@jonpas jonpas changed the title Improve selective UI API and disable ammo count from reload component Improve selective UI API May 24, 2016
@jonpas
Rework Selective UI using ACE_UI config, Cleanup, Add ACE_UI to FCS c…
185187a 
…omponent to mark it (is already disabled due to other necessary settings for FCS to function)
@jonpas
Copy link
Member Author

jonpas commented May 24, 2016

I think I am finally done with this, quite a rework as well.

thojkooi
thojkooi reviewed May 25, 2016
View reviewed changes
addons/ui/ACE_UI.hpp
idd = 300;
elements[] = {118};
condition = QUOTE(ACE_player == vehicle ACE_player);
class conditions {};
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the purpose of condition vs conditions here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Condition is the main condition (vehicle/soldier UI), conditions class is for anything else to add extra conditions, such as other components or mods.

Copy link
Contributor

@thojkooi thojkooi May 25, 2016 •
edited
Loading

Choose a reason for hiding this comment

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

Maybe we should put our main condition in the conditions class?

Copy link
Member Author

Choose a reason for hiding this comment

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

I had that at first, but this makes it easier to handle, because the main condition gets evaluated before any other and if not applicable it doesn't toggle the element at all (no point as you can't see it anyways), while other conditions determine if it should be visible or hidden.

Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a different effect though? Both cases the elements end up not visible? Why are those separate?

Copy link
Member Author

Choose a reason for hiding this comment

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

https://github.com/acemod/ACE3/pull/3805/files#diff-fc2d593f082cd4c729bb26d91f30ede9R31

The only thing is that no other condition gets evaluated if that one is false. I could put it into conditions class and filter it out in configProperties as well if that would make it nicer.

Copy link
Contributor

Choose a reason for hiding this comment

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

Does that mean that if one of the other conditions is false, the rest of those are still evaluated?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, if one is false it will set the element to hidden, if they are all true it will show the element. The difference between the main condition and the conditions class is that when the control is shown by the engine you still need to make sure you hide/show it every time the UI gets updated by the engine. Meanwhile the main condition will exit right away if the control is not getting rendered at all.

Copy link
Contributor

Choose a reason for hiding this comment

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

So the condition defines when an element is available and the conditions if it is shown/hidden?

thojkooi
thojkooi reviewed Jun 2, 2016
View reviewed changes
addons/ui/ACE_UI.hpp
@@ -0,0 +1,177 @@
// Location (0-both, 1-ground, 2-vehicle)
Copy link
Contributor

Choose a reason for hiding this comment

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

A better solution would be to use macro defines instead.

@jonpas jonpas merged commit 4c995d4 into master Jun 2, 2016
@jonpas jonpas deleted the disableAmmoUI branch June 2, 2016 12:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
kind/enhancement Release Notes: **IMPROVED:**
Projects
None yet
Milestone
3.6.0
Development

Successfully merging this pull request may close these issues.
3 participants
@jonpas @PabstMirror @thojkooi