#Non-determenistic systems behacior with picking and clicking

1 messages · Page 1 of 1 (latest)

north osprey
#

I'm following a bevy .8/.9 tutorial but updating for the latest versions.

The code I am using is posted https://git.ennwise.com/jennen/rpg

The menu I am displaying from https://git.ennwise.com/jennen/rpg/-/blob/main/src/ui.rs?ref_type=heads when I click it, sometimes it will process the click and spawn the tower. If it works, it works for the entire app run. If it doesn't work the menu despawns before triggering the tower spawn, essentially the menu disappears and doesn't register a click.

I've tried reordering the systems, putting the menu draw and the tower clicked systems in pre/post update while the other is in update etc. Not sure whats going on.

GitLab
Justin Ennen / rpg · GitLab

GitLab Enterprise Edition

GitLab
src/ui.rs · main · Justin Ennen / rpg · GitLab

GitLab Enterprise Edition

surreal sphinx
#

Try,

impl Plugin for UiPlugin {
    fn build(&self, app: &mut App) {
        app.register_type::<TowerType>()
        .add_systems(Update, (create_ui_on_selection, tower_button_clicked).chain());
      
    }
}
#

(system_0, system_1, . . ., system_N).chain() ensures that the given systems run in the given order.

south fulcrum
#

So the act of clicking the UI button is deselecting the tower slot.

#

I think this is actually a conflict between bevy_mod_picking's updating of PickSelection and bevy's ui interaction systems, both running in PreUpdate.

north osprey
#

bestRanar, would that explain why it works and its a coin flip?

#

@surreal sphinx forcing with chain didnt resolve. Sometimes works still, sometimes doesnt.

south fulcrum
#

yes, I believe it would.

#

And it's a bit out of your control -- I'm not super familiar with bevy_mod_picking but I think a way forward would be to handle the UI clicks with bevy_mod_picking instead of bevy's Interaction.

#

Or to keep the "last selected tower" state a resource/component of your own or something.

north osprey
#

I've updated the code to use bevy_mod_picking

#

I am seeing similar behavior.

#

It seems, that clicking the UI, deselects the selected tower first, and THEN it checks if the press on the button has a selected tower

south fulcrum
#

Yeah, mentioned that above. Strange that this switch alone didn't fix it though. I tried adding NoDeselect to the buttons and it seems to help. Not actually sure if switching to bevy_mod_picking's interaction was required for that to work.

north osprey
#

but not always, but atleast the full cycle is in bev mod pick now.

#

oh where did you find that gem

south fulcrum
#

Randomly stumbled on it in their examples

north osprey
#

I'm going to link my current branch and open an issue on their hub see what they recommend, but I'll try that after.

south fulcrum
#

The bevy_ui example may have some other gems.

north osprey
#

yea so I'm using the raycast picking engine here, they have a ui specific picking engine

#

and Im aware of people running both at once for different parts.

south fulcrum
#

Yeah the ui backend is enabled to default / you are sort of using it now (but not before) as far as I know.

north osprey
#

@south fulcrum it would seem nodeslect solves the issue 10/10 runs is better than I got before.

#

I supposed I could add a on click action to

#

but I like it as is for now.

#

On click would avoid the per frame queries I imagine.

#

Nah cause I'd still need to query the selected item in the On click even.

#

Yea I'm not great with rust, still figuring out idiomatic stuff.

#

Too many years in c++ land

#

Thanks for the help

south fulcrum
#

There still must be some system order dependency that's not being explicitly specified. Maybe there's also an ambiguity with bevy_mod_picking's own interaction system and its selection stuff. I just sort of assumed that they'd have that covered.

north osprey
#

mm.

south fulcrum
#

But adding NoDeselect seems very reasonable as a workaround.

north osprey
#

Yea I mean more or less thats the intent

#

I just immediately delete the entity, but if you select an item and click a menu, expected behavior is that item is still probably selected for more menu operations

south fulcrum
#

The selected thing gets despawned anyway, right?

#

yeah

north osprey
#

As a demo, its all just yak shaving anyways.

#

But definitely learning the systems.

#

I figured there was perhaps difference between 0.8/0.9 and current I was missing

#

But this does seem to be more of a library internals issue.

#

Or we are just holding it wrong.

#

🙂

ancient osprey
#

Deselection is expected behavior if you click something for bevy_picking_selection. That's what the NoDeselect component is for. You can also just replace selection logic if you need to, it's a very small, well contained little module/crate.

ancient osprey
#

The other issue is bevy_ui's interaction system is a bit... unfinished.

#

It's very difficult to interact nicely with bevy_ui with mod_picking, because it has opinions on ways things should work that aren't always reconcileable.

#

The latest few mod_picking releases have made that way better, but it isn't perfect.

#

The bevy_ui example should cover all the needs you've mentioned here though, and explains why things are the way they are.

ancient osprey
south fulcrum
#

I still think that there may be a 1-frame delay lurking due to a system order ambiguity internal to bevy_mod_picking somewhere affecting this.

It seems like on some runs, the Deselect event fires on the frame after Down. (and it's on those runs where kolie's game seemed to work properly.)

#

And actually, I think you already fixed it in the main branch.

#

Yeah, with bevy_mod_picking main, the behavior is consistent (and NoDeselect is definitely needed).

ancient osprey
#

Ah yeah, was just about to mention that.

north osprey
#

Ok.

#

So it was intended to not select and deselect immediately

#

the fact that it worked was a bug, as we determined the ordering

#

And so it shouldnt work and nodeselect is required.