#pyri_state

53 messages · Page 1 of 1 (latest)

rough zinc
rough zinc
plain creek
#

🎉

#

Moving here from #general

modest imp
#

it's been a while so let me double-check.. :p

#

yes there are no commands currently for state stack operations, it seems like it would be possible to add them, and probably would be desirable

plain creek
#

I'll put up a PR if nobody gets to it first

modest imp
#

let me know if you need any help

plain creek
plain creek
#

I'm curious what exactly the bevy_state feature does. Do I only need that enabled if I'm going to try and use both bevy_state and pyri_state?

#

Looks like it adds the bevy state plugin and adds some machinery to register pyri states with it? Like, it derives pyri::State and bevy_state::States?

#

The default experience seems to be: I cargo add bevy, cargo add pyri_state, then add (DefaultPlugins, StatePlugin), and then I get a crash on startup from Bevy's state plugin being added twice

plain creek
#

@modest imp This prints nothing:

use bevy::prelude::*;
use pyri_state::prelude::*;

fn main() {
    App::new()
        .add_plugins((DefaultPlugins, StatePlugin)) // Adding the plugin
        .insert_state(NextStateStack::with_base(Menu::Main)) // Initializing the state
        .add_systems(Update, Menu::ANY.on_update(|| println!("Hello????????"))) // Check if we're in *any* state
        .run(); // nothing prints
}

#[derive(State, Clone, PartialEq, Eq, Debug)]
#[state(next(NextStateStack<Self>))]
enum Menu {
    Main,
}

Also I'm having trouble with the examples in the repo, I can't tell if they're not doing anything visible or if I don't know what they're supposed to be doing.

modest imp
#

so currently the examples are mostly just examples of what the code looks like / sanity checks that the API compiles

#

some of the examples do include input / logging though so you can see the state changes in the logs

plain creek
#

hmmmmmmmmmmm

#

i'm not seeing logging tho

modest imp
#

none of the examples include visuals atm although it would be nice if they did

#

like just a different bg color per state or w/e

modest imp
#

which you need if you're e.g. using an ecosystem crate that expects bevy_state states to function

#

like bevy_asset_loader

plain creek
modest imp
plain creek
#

hmmmmmm

modest imp
#

maybe the .insert_state line is the issue

plain creek
#

time to debug 🫡

modest imp
#

which means disabling default features and re-enabling everything except bevy_state

#

which is a little annoying but at least it works 😄

#

you can then depend on bevy_state directly if you want. it won't be pulled into the bevy prelude or automatically add its plugin, so there's no compatibility issue with doing that

quartz parcel
#

@modest imp what are the chances that pyri_state “unwinds” states in the “correct” order?

For example if I have a substate and I have a system listening to its OnExit (equivalent thereof), could I rely on that OnExit being called before the parent state’s OnExit?

Use case is that in my substate OnExit I am cleaning up some resources, but the parent’s OnExit also cleans up resources. The substate OnExit needs those resources first though, so I need strict ordering here and I don’t see a way to get it from bevy_state.

modest imp
#

which is under the hood quite literally .after or .before on some system sets

#

meaning you can specify that one state type's transitions should always run before another state type's transitions

quartz parcel
#

Yeah nice. So: yes is the answer 🙂

modest imp
#

yeah :)

#

although in bevy_state there is also ordering between parent and sub/computed states

#

specifically, it's like nested parens

#

"on enter" for the parent state, then "on enter" for the child state, then "on exit" for the child state, then "on exit" for the parent state

quartz parcel
#

Previously when I’ve looked at the repo, the first question that pops in my head is: but what about bevy_asset_loader. So you may consider adding a note or FAQ to the readme if you feel like it. Pretty sure using pyri means you can’t use bevy_asset_loader without your work, but could be worth being explicit 🤷

modest imp
#

good point. you actually can use them together but it's a little extra work

#

pyri_state has a feature where it can create a synced bevy_state state type for your states

#

which provides a compatibility layer

#

but for bevy_asset_loader specifically, it depends on bevy directly with the bevy_state feature enabled, which causes issues because that injects conflicting names into the bevy prelude

#

i should probably mention this somewhere

modest imp
quartz parcel
modest imp
#

ahh i misread your message, got it

quartz parcel
quartz parcel
modest imp
#

yeah, swapping out core bevy plugins is a tough problem. either the replacement has to be compatible with the rest of the ecosystem or vice versa. alternatively there could be a common interface with traits etc. like rand_core, but that's probably overengineered