Hi! I would like some help on translating my code with cc.eventManager to cc.EventTarget or cc.systemEvent, there are warnings about the cc.eventManager saying it will be removed on the version i’m using, so I would like to remove it, but I cant seem to find a respective solution to it, the code i’m using is:
cc.eventManager.addListener
({
event: cc.EventListener.TOUCH_ONE_BY_ONE,
onTouchBegan: function onTouchBegan(touch, event)
{
},
onTouchMoved: function onTouchMoved(touch, event)
{
},
onTouchEnded: function onTouchEnded(touch, event)
{
},
this.node
});
cc.eventManager.resumeTarget(this.node, true);
cc.eventManager.pauseTarget(this.node, true);
How can I do the same thing but using cc.EventTarget or cc.systemEvent ?
This change for changes sake stuff has to end. You break existing documentation and tutorials, just because someone was fiddling with a system for the sake of change. The Cocos projects have always been plagued with this and it’s harmful for Cocos Creator in general.
I was about to do an added tutorial for my series based on requests, but finding that this has broken (and not cleanly been replaced) breaking existing documentation just isn’t worth updating anymore.
These kind of changes just hurt everyone, the OP, the various other queries I found when my code suddenly broke. Hell, I’m looking at the message:
‘cc.KEY’ is deprecated, please use ‘cc.macro.KEY’ instead
Guess what… at least in the typescript definitions… cc.macro.KEY doesn’t exist. This stuff is frustrating and causes people to flee to other game engines.
@jare. Can you help address how developers should prepare for these changes?
@Serapth yeah I can see how frustrating this is. And you of all people would know given your popular videos. I apologize that we have now obsoleted your tutorials.
Thankfully it only broke one tutorial and that’s part of being a tutorial writer, it happens.
The problem is, people trying to learn, either using my own material, the forums, most of the documentation, it all comes to a crashing halt. I’m not entirely certain the new input change is even documented at this point. You have to trial and error to figure out the EventManager changes.
The worst part of it all though is… why?
This is core stuff, very very very core stuff. You need a damned good reason to break something as fundamental as input handling. Even if your initial design wasn’t perfect… live with it.
Imagine if C designers decided that hey… printf was a stupid name, let’s change it to just print. Hey, I agree with the context of the change, but no way you’d ever actually do it. A small win isn’t worth breaking a huge amount of existing code.
I’m looking around the forum in the post 2.x launches and I’m seeing a lot of frustration around these kinds of changes. Heck I’ve been doing tutorials around Cocos relate projects (cocos-html and cocos2d-x) for years and this has always been one of the biggest flaws with how Cocos is developed. A mature platform shouldn’t be constant breaking backward compatibility.
If they HAVE to break something as fundamental as input handling, it needs to be publically explained, justified and extremely well justified.
In this case, it was none of those. At least, not in English. As mentioned earlier, it felt like change for changes sake.
These changes were based on the needs of performance in JavaScript. We need to limit the property count in cc to ensure it always been ran in “fast class” mode. Same changes also happened on cc.Node object. Sorry for that.
