MiniaczQ
MiniaczQ
@microsoft-github-policy-service agree
If I understood what's going on correctly when experimenting, naga can interpret `acceleration_structure` type, but it cannot write it again in WGSL.
Windows 11, double closing is fixed, no warnings about unread events. Not sure if the order is considered a problem 
I don't think there is a need to complicate `NextState` with an opt-in API, I'd much better prefer a `SystemParam` wrapper around `(State, NextState)` pair that performs the check for...
The wrapper can check for values inside of `NextState` as well, the fun part is that it can be as complicated as you want because it doesn't mess up the...
Few more thoughts: The `NextState` force flag idea won't work with cases like: ```rs enum FooBar { #[default] Foo, Bar, } app.add_systems(Update, (sys_a, sys_b).chain()); fn sys_a(next: ResMut) { // Should...
Another problem with the entire idea of forced updates is it straight up doesn't make sense when you nest states. Which state is meant to be 'forced'? You can't decide...
If the current state is `Foo`, then I'd expect a `set` to be ignored if I try to use `Foo`, but proceed with an update if it's anything else, like...
> There was a logical intention for the next state to be `Foo` What if this happened due to system order ambiguity, then it's an additional thing to worry about
Just resolving whether an state update should occur during `set`, instead of the `transition` system would fix this Edit: No it wouldn't 🤡 I'm silly I'll recheck this topic some...