Closed aaronjewell closed 3 years ago
Hi!
I actually was trying to solve this camera bug but didn't find where's the problem at until seeing this ticket! It's fixed by 36270b0
So before the loop is like
for (const obj of objPool) {
obj.update();
applyCam();
obj.draw();
}
where it should be
for (const obj of objPool) {
obj.update();
}
applyCam();
for (const obj of objPool) {
obj.draw();
}
this solves the camera bug, but not that related to "action priority", I wonder if you have some other cases you'd need action priority, or late actions?
Perfect! None at the moment, still exploring :)
Yea I remember having need for stuff like lateUpdate
before but can't remember what's the need exactly, going to leave this open for a while and see if someone has the need.
The camera position is the most common use case that I know of. Unity's MonoBehavior LateUpdate method calls out camera position specifically.
When needing to know a system has run for all objects before running a follow-up system, it's a convenient solution because it still allows for arbitrary execution order among objects during update. In Generic Dungeon Crawler 2021, if I want to know if the player input is a possible player movement position after all dungeon residents have moved and cast their "Spell of Blocked Tile" spells, I need to be able to define dependent actions, have a specific follow-up phase like lateUpdate, or some other approach.
as a workaround for now (v0.2.0), you can use plain
action(() => {
// ...
});
to achieve "late update". Plain action
s are called after all the object actions are finished.
Nice and simple, thanks!
Firstly, love the library, so simple and elegant.
When updating the camera position inside an object action, objects whose update phase have passed aren't rendered in the correct position that accounts for the updated camera vector.
A work-around is to add a "camera" tagged object as the first or last object so that either it's action runs before all other objects or that the camera is moved at the end of update.
I don't know that adding a priority number as an argument to the add calls would be better, or adding a "lateUpdate" event in addition to the current "update". The work-around isn't all that bad, it just might not be intuitive.