How to make hitboxes that don't persist?

Hi

I’ve noticed that if a HUD menu has one branch that’s gated to no longer draw, and another branch is gated to draw in the same location, the hitboxes for the first branch still work where their locations overlap the next bunch of hitboxes. And presumably since they were drawn first, they have priority.

Without having to set the Priority values for the hitboxes, can a hitbox that is no longer being added by EventReceiveDrawHUD be discarded until added again?

Tom

“as long as you add the hitbox in the same branch as drawing the UI item, when that branch gets gated off, the hitbox should not exist. every hitbox is discarded on every frame, so they shouldn’t exist unless you keep adding them.”
That’s not the behavior I am seeing in 4.2

Log:
[2014.06.08-08.24.18:185][ 11]LogBlueprintUserMessages: Looked up savegame MainSlot
[2014.06.08-08.24.18:185][ 11]LogBlueprintUserMessages: MainSlot found - Loading
[2014.06.08-08.24.18:185][ 11]LogBlueprintUserMessages: MainSlot loaded - CAST SUCCESS
[2014.06.08-08.24.18:254][ 12]LogHUD:Warning: Failed to add hitbox named HB300 as a hitbox with this name already exists
[2014.06.08-08.24.18:254][ 12]LogHUD:Warning: Failed to add hitbox named HB250 as a hitbox with this name already exists
[2014.06.08-08.24.18:254][ 12]LogHUD:Warning: Failed to add hitbox named HB200 as a hitbox with this name already exists
[2014.06.08-08.24.18:254][ 12]LogHUD:Warning: Failed to add hitbox named HB150 as a hitbox with this name already exists
[2014.06.08-08.24.18:302][ 13]LogHUD:Warning: Failed to add hitbox named HB300 as a hitbox with this name already exists
[2014.06.08-08.24.18:302][ 13]LogHUD:Warning: Failed to add hitbox named HB250 as a hitbox with this name already exists
[2014.06.08-08.24.18:302][ 13]LogHUD:Warning: Failed to add hitbox named HB200 as a hitbox with this name already exists
[2014.06.08-08.24.18:302][ 13]LogHUD:Warning: Failed to add hitbox named HB150 as a hitbox with this name already exists
[2014.06.08-08.24.18:397][ 14]LogHUD:Warning: Failed to add hitbox named HB300 as a hitbox with this name already exists
[2014.06.08-08.24.18:397][ 14]LogHUD:Warning: Failed to add hitbox named HB250 as a hitbox with this name already exists
[2014.06.08-08.24.18:397][ 14]LogHUD:Warning: Failed to add hitbox named HB200 as a hitbox with this name already exists
[2014.06.08-08.24.18:397][ 14]LogHUD:Warning: Failed to add hitbox named HB150 as a hitbox with this name already exists

for each frame, every hitbox on screen needs a unique name to call its overlap events. in earlier builds, maybe this wasn’t the case, but in the UI menu system i have been making, i have been using unique names from the start, so i didn’t notice a difference, but now that i tested buttons that share the same name, only the first button with that name becomes registered to receive hitbox events.

in my menu system, im parsing a list of text items to pull out all the labels and names of menu items, so each is unique, but if you want to procedurally make buttons, you may want to append an incremented number to the names that you want to reuse, like btn1, btn2, etc… and you can reset that number as the first thing you do after “event receive draw hud”. if you have separate menu pages that will never show up at the same time, like a settings menu and a main menu, they can have buttons that have the same name, but each page needs a list of unique button names.

this might be a feature that seems like a bug at first, but if multiple menu buttons were able to have the same name, they would call the same rollover event, causing them to both perform rollover logic when either is rolled over.

I know there’s a logic to the way things are, and I already started to cope with it.
At the same time :slight_smile: would be nice to have a HitBoxDiscard tickbox too.
That would make some cases miles easier to handle.

Yeah, this is incorrect. There is no method to discard HUD hitboxes and they persist on screen even if we change code branch. This is bad.
I’m forced to keep on changing HitBoxes names to try and workaround this.

Well, if more ppl need this Epic will end up adding it to the code.
They are super great programmers, they can fix this in seconds; We just need to wait till someone from staff can check this out and add a function to clear hit boxes in official releases or maybe they could explain us why hit boxes are persistent even though they have in code the ‘.Empty()’ command to clear them.

Impressive!

I don’t know how to add code to my blueprints project yet but I will try.
Last time I tried I destroyed the editor …

Will something like ClearHitbox be added natively to blueprints in future?

Hey guys,

Have either of you tried this out in 4.2 or 4.2.1? I haven’t been able to reproduce this issue in either one, let me know if it still happens for you guys and, if so, could you provide a screenshot of a simple setup that reproduces for you?

Thanks!

-Steve

Yes, in 4.2 it occurs. When you have two buttons in the same place (in different menus) when the first button is gated to be off its hitbox is still present and overrides the second button’s hitbox, since the first has priority.
I’ll try to record a video of the problem because it might be I’m going about things unorthodoxly.

My project is blueprints only – can I directly make changes to HUD itself via ‘Add Code to Project’ ? Specially because I already have a MyHUD blueprint specified in my gamemode … and I can’t seem to extend that in the create class options.

Someone told me he fixed the issue in 4.2.1 by unchecking the box
HUD Blueprint → Defaults Props → Suppress Native HUD.
Maybe this is related?! If you check this box are HitBoxes supposed to stay on screen static every frame and Empty() will never be called??

Hey guys,

After looking into this more once you mentioned the use of Suppress Native HUD, we were able to reproduce the issue when that option is Enabled. This is, indeed, a bug that those Hitboxes aren’t be purged each frame when that option is enabled and a defect report has been filed to have this fixed.

Edit: This has already been fixed internally and is expected to be included in the 4.3 Release

Thanks for all the information and we hope to have a fix implemented soon!

-Steve

Hi
Thanks for the infos. That’s nice to be resolved.
I don’t know much about Suppress Native HUD … but … wouldn’t it be nice and user friendly to expose a tickbox on the blueprint for Add Hitbox that lets you choose its persistence per instance? I think so anyway.