I have an inventory widget of which each inventory slot has a “ItemSlotWidget” of which it assigns a custom tooltip on its “Event Construct”.
It looked cool in my CCC open world game until I got fancy with the widget animations. Now when I go to close the top-level inventory widget, I transition some items off screen and then fade everything else, including the item slots, using the render opacity.
Unfortunately… …when the animations are running, about 1.2 seconds, I still can mouse over each inventory slot widget and its tooltip appears (render opacity of 1) even though that inventory slot has its render opacity about 0. Looks not cool.
Therefore, I seek recommendations as to how to disable tooltips first prior to running the widget animations in reverse to close out my inventory widget before removing it from the parent.
Perhaps when you start the transition animation set a flag to not allow tooltips to show? do a branch on the tooltip showing to check if they are allowed to show before doing so.
In “ItemSlotWidget” I made a custom event called “SetWidgetRenderOpacity” which does a validity check on “ItemToolTip” of which if valid sets the render opacity of the ToolTip to the float passed on the event input.
In the top level “InventoryWidget” I created a function called “SetAllToolTipRenderOpacities” which loops thru all the items in the inventory WrapBox looking for “ItemSlotWidgets” children of which when one is found, valid “Cast To ItemSlotWidget”, calls the “SetWidgetRenderOpacity” function created in 1) with this functions render opacity input.
Added a call to “SetAllToolTopRenderOpacities” at the beginning of the “ReturnToGameEvent” with the render opacity set to 0 to solve the issue.
It works…
Bonus… …actually had the opposite problem when the widget was created, or fades in, in that again the ToolTips were visible before the item buttons became visible. Was able to use my super-cool “SetAllToolTipRenderOpacities” function to solve this as well.
So my way works but is there a better, or more correct, way???
Cool, one problem which it is a good idea to avoid is a lot of casts.
One way is on first creation the inventory widget you could iterate through and do the cast but store refs to all the valid tooltips in an array, Then when do SetWidgetRenderOpacity it operates on the array of valid tooltips and you won’t be doing loads of cast operations (they are expensive)
Another way would be to investigate interfaces, so you could just call the function on all the inventory items and only ones with the interface implemented would respond.
That is the rumor in that casting is expensive. Is that expensive in terms of time, expensive in terms of resource allocation or both?
In addition to minimizing casts… …I was thinking that I would create a new widget every time the user requested that widget type and that “RemoveFromParent” would cause the widget to be removed from memory; however, after Googling some I am not sure that is true.
I would be interested in your opinion as to if I should create just one instance of say the Inventory widget (or) create a new instance every time that widget is requested and assume that RemoveFromParent will actually send that new widget instance to GarbageCollection eventually if it is no longer referenced by anything.
Well looks like I am proven wrong, (Is casting expensive? - #28 by jwatte) I also just accepted the statement that casting was expensive and have generally avoided it. That being said I have always been in the habit of setting references outside of loops to avoid allocations and things so I still don’t think it’s a terrible idea. I also like the use of interfaces as it decouples the code nicely.
As for creating the widget once, yeah I like the idea as long as it is gonna be used often in the current game state - I assume as this is inventory it will be.
If the inventory widget has lots of references to objects that need to be queried and used you will have a instantiation cost for that widget that would be nice to only do once.
The only good reason to get rid of it is like you say to hopefully free up memory if needed but pointless is you will keep having to re-instantiate it and re-use the memory anyway.
I claim my solution is as follows; however, I feel it cannot be the only solution and I feel it may not be the best solution:
Converted my widgets to be persistent in that I keep references to the widgets once created.
During the EventConstrct of my ItemSlotWidget I create the custom InventoryToolTipWidget, save a reference to that ToolTip widget and set its initial opacity to 0.
My ItemSlotWidget has a custom event called SetToolTipWidgetRenderOpacity which set the ToolTip render opacity to its event input.
Created a ShowInventoryIntro custom event in the InventoryWidget to manage opening animations and setting the Tooltip opacities to 1 after the intro animations
Created a ReturnToGameEvent in the InventoryWidget which sets the ToolTip opacities to 0, plays the closing animations, removes the widget from the parent, un-pauses the game, sets the game mode and removes the mouse cursor.