Exteneded GameObject (Sprite) not fire update method, but preUpdate

[hadikcz]

It's little bit wierd but all extened Sprites in V2 fires update method in class, but right now update not working. I discovered in UpdateList that is preUpdate is fired. But I think this solution is not clean as should be and can avoid some backend process.

Look at TestSprite.update and TestSprite.preUpdate

https://jsfiddle.net/athntebo/19/

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[kalebwalton]

@photonstorm Why is this complex/difficult? I just ran into this myself as the Sprite docs even state that 'update' is to be overridden.

[kalebwalton]

I'm surely too naive about this... but I'll ask anyway. Why can't we just add 'update' call after this line:

https://github.com/photonstorm/phaser/blob/1be486fab4177a25186117583e65c55ab5052434/src/gameobjects/UpdateList.js#L196

[samme]

See #3379 (comment).

[kalebwalton]

Doing this.scene.on('update', this.update) for now. Thank you for the reference @samme !

[photonstorm]

It’s flagged as complex because it requires a significant refactor to the internals, the creation of a new plugin and changes to how Groups work. To do this right touches lots of elements.

[samme]

I made https://github.com/samme/phaser-plugin-update.

[photonstorm]

Going to close this issue. These are plugins available to address this, and it's just the way v3 works. Will re-consider for v4.

[Krankomat]

Doing this.scene.on('update', this.update) for now. Thank you for the reference @samme !

@kalebwalton This did not work for me. However, this works (Phaser v3.21.0):

this.scene.events.on('update', (time, delta) => { this.update(time, delta)} );

I wrote a class that extends Phaser.GameObjects.Container, put this into the constructor and voila, it works.

[juanitogan]

So... when you extend a class in this framework, it changes behavior? Am I reading this correct? How terribly confusing and frustrating. I was trying to resolve why my Container objects don't call update() but seem to call preUpdate() instead -- which isn't listed as a method for Container in the docs. It seemed a bug. The class docs could warn us better of these things so we don't waste time chasing our tails. This shouldn't be closed until it is at least documented better.

[photonstorm]

@juanitogan classes do not change behavior when extended as update isn't called no matter what. It doesn't matter if it's an internal class or an extended one, it won't be called automatically. While the docs could be clearer, equally nowhere does it say this will happen, so it shouldn't just be assumed it will happen either. The function is there for you to call as required, or hook into a system that can call it for you (such as a custom pool, or a Group).

preUpdate is an internal function at heart, used for advancing internal systems such as the animation manager. While it can be overridden if needed (and lots of devs do), it was created to specifically separate internal update logic from your own game level update logic, because preUpdate should fire every step, whereas update frequency is entirely at your discretion when (or even if) it should fire at all.

[juanitogan]

Ah, I see. That adds up. Thank you for the explanation. I was having a hard time imagining how extending a class could change its behavior... even in mysterious JavaScript. I could only imagine that something else was detecting an extended class somehow for some odd reason.

When doing closer comparative reading between Scenes and GameObjects, I can now (and only now) see meaning in the nuances in text between the update methods for each. There is just so much to dig through to catch it all. And... just because an object may be on a scene's update list, it doesn't mean it will get an update event. That is finally becoming clearer as well. Surprising... but, okay, that's Phaser. I can see the logic in keeping the number of updated objects to a minimum... I just missed the clues on this pattern and how to work with it.

As a side note: This is a very hard engine to learn indeed. Unity felt easier to learn, and that's a pretty gnarly beast. Here, I run into a surprise like this about every other day and spend way too much time going in circles in the docs trying to reconcile it. I don't mean to sound overly critical -- I'm amazed by the amount of work and energy here -- this just may not be the engine for me. I'm considering switching to a WebAssembly solution -- not for speed but for thinner and simpler tools. Not sure yet. I'm only about 5000 lines in and my code is already a mess of programming patterns and workaround notes. Some OO best practices and guide would be a nice-to-have. In case anyone is curious, this is what I'm working on: https://juanitogan.itch.io/sendit-soccer