Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Systems that can run multiple times that internally reset change detection #5851

Open
asafigan opened this issue Sep 1, 2022 · 2 comments
Open
Labels
A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use

Comments

@asafigan
Copy link
Contributor

asafigan commented Sep 1, 2022

What problem does this solve or what need does it fill?

Sometimes you need to do work based on calculated components before they would normally be calculated.

You could move the corresponding systems before your system but systems after that system might update these components again.

You could run the corresponding systems before your system by adding them again right before your own but this will cause them to be calculated twice.

What solution would you like?

It would be nice to have some way to configure a system to have an internally change detection that is synced across multiple instances of itself. Basically resetting each time it runs even if it appears multiple times in a schedule.

I don't think this should be the default behavior for systems because it is just an optimization for some use cases.

Basically having a method on system that could recreate a new system that has this behavior.

Something like update_system.internal_change_detection() which returns a system that can be used multiple times.

Could also be a different query filter like InternalChanged or InternalAdded.

I don't think "internal" is the best word for this but it is the only thing I can think of right now.

What alternative(s) have you considered?

  • living with repeated work
  • living with one frame delays
  • implementing an external library

Additional context

My use cases in the past have been with GlobalTransform so an external library would not be an optimal solution.

I just lived with a one frame delay because I didn't think of finding the systems responsible for updating GlobalTransform in Bevy and reading them before my system. This would cause them to be calculated twice even if they weren't changed between the two duplicate instances of the systems.

@asafigan asafigan added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Sep 1, 2022
@alice-i-cecile alice-i-cecile added A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use and removed C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Sep 1, 2022
@alice-i-cecile
Copy link
Member

Does #5838 (which was just merged) solve this for you? @StarArawn had an extremely similar use case.

@asafigan
Copy link
Contributor Author

asafigan commented Sep 1, 2022

It seems like this could be used to implement a solution to this. I could play around with this a bit and see if I can make a prototype.

I still think that an implementation should be in Bevy and used my some systems like transform propagation so that people can easily add these systems multiple times without causing performance issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use
Projects
None yet
Development

No branches or pull requests

2 participants