#Sprite Interaction System

58 messages · Page 1 of 1 (latest)

karmic oar
odd crow
#

Not that using separate struct is wrong, but have you considered using a single enum for the events?

karmic oar
#

I gave it some thought, I think it could go either way but

fn example (
    mut ev: EventReader<HoverBeginEvent>
) {

}

Just seemed to more clearly signal intent than having to dig through and find

if ev.state == HoverEvent::Dragging {}
odd crow
#

Yeah, after having looked at the code a bit more I understand

#

Though usually, you'd use a match expression in rust

#

But since you handle the different events in separate places, it doesn't fit the use case

karmic oar
#

yeah, it'd be odd to handle HoverBegin and HoverEnd in the same function, although you totally could

odd crow
#

I'll admit I've a bit of difficulties parsing your code, not sure why

#

What's the purpose of hover_persist_ev?

karmic oar
#

it's a convoluted event flow that I probably need a better way to deal with

#

hovering over the sprite sends a HoveringEvent

#

which is just anytime you're hovering

#

that's the persist ev

#

the handler looks at the persist events

#

if they're new it adds a HoveringOver entity to keep state information on the thing you hovered and it sends the begin event

#

then it checks all the current hovers and if they didin't have a persistent hover it removes the HoveringOver and sends the end event

odd crow
#

If you renamed handle_sprite_mouse_interactions to emit_hover_events I feel like it could help comprehension

#

ah, it's for more than just the hover events

karmic oar
#

yeah that one handles the initial 3 interaction types

#

and the handle_sprite_hover_events emits the begin/end

#

the only reason it's like that is because let res = helpers::pointcast_2d(&rapier_context, cursor_point_game, &sprites); raycasts every sprite

#

I think splitting it up like this is creating sequencing errors though =x

odd crow
#

I feel like removing the _sprite in your system names could help then

#

It's just noise, whether it's a sprite is not relevant, and it helps focus the name on the actual purpose of the system

karmic oar
#

that seems fair yeah

odd crow
#

In handle_sprite_begin_drag, you don't need the &Dragging in the sprites query, you never read it.

#

In handle_sprite_hover_events there is some formatting woes for HoverBeginEvent

#

Also in handle_sprite_hover_events, you don't need that continue in the if current_hovers….

#

in handle_sprite_mouse_interactions I'd use an else branch instead of an early return after the if button_input.….

#

Have you considered relying entirely on a Hover component, rather than a bunch of events?

karmic oar
#

I did try that initially although I'm second guessing my reasons for changing it hmm

#

thinking back I think I had made a mistake using Changed instead of Added which doesn't make sense

#

that might work better

#

it's a bit awkward though I guess, Removed isin't really as simple for components

odd crow
#

At one point I did try to write a Hover component for bevy-ui-navigation, but I had a lot of difficulties, specifically with regard to being resilient to Visibility changes

karmic oar
#

yeah it seems difficult

odd crow
karmic oar
#

I've already run into issues where dragging and hovering have to be exclusive

#

because of mouse latency >.>

odd crow
#

Yeah, could having an enum like the following help?

#[derive(Component)]
enum Interaction {
  Hover,
  Dragging,
}
karmic oar
#

Didin't even know enums could be components

#

that's interesting

#

hmm, I'll look into refactoring it to be more component-y

#

I think for dragging the events are relevant because they actually need the metadata

#

but for hovering it seems like removal is perfectly fine

#

I guess the only reason they can't all be components is really just removal

#

I guess drag_end could specifically be one event

#

and the rest could all be ECS based

sacred arrow
#

Recommend looking into this potentially... not sure how well it fits the use case but seemed relevantish

karmic oar
#

Thanks, I looked over the code and it makes sense. I think I'm going to take a slightly different approach and use a singular entity with a state enum in my case as I'm having trouble thinking up ways to avoid race conditions involving dragging and hover in combination otherwise. Really appreciate all the input ❤️

# 
#[derive(Reflect, Component, Clone, Default)]
#[reflect(Component)]
#[component(storage = "SparseSet")]
pub enum InteractionState {
    None,
    Hovering,
    Dragging {offset: Vec2, start_pos: Vec3},
    Returning,
}
#

something like this probably

karmic oar
#

Okay I think I've massively simplified things

#

Leaned in much harder to the entity system and utilized enums, it seems a bit rustier

#

no more race conditions

#

only two sequential systems