How does this affect Cordova exports with the Construct 3 Build Service?
For an engine willing to deprecate or destroy plugins to "prevent" a "possibility" of future project breaks through Addon SDK v2, you sure do lots of project breaking updates.
I find it ironic that the goal of Addon SDK v2 is to prevent project breaks by breaking projects with plugins. But when it comes to your updates breaking such projects, you have no regard for them.
What makes the Addon SDK v2 so important that it's worth breaking all 3rd party plugins?
If I understood correctly, v2 is mainly to prevent plugin developers from using undocumented APIs.
In other words, you value your control more than the projects of your customers.
Your engine is so slow on Android and iOS; you complain of lacking time to accommodate the most requested essential features, but still have time for this?
Stop lying to us!
Xbox support is great news!
Finally, thanks for the Collision scripting interface.
Yes, I run a game studio.
If you don't understand, well sorry, I've already given you all the info. It's up to you to do more research.
To illustrate, some of the issues became evident when Ashley tried to create a game using primarily JavaScript, which is Command and Construct. Construct 3 had a lot of scripting bug fixes, changes, and improvements. If it were an ordinary user, he would otherwise just revert back to the event sheet approach of scripting, having no means to fix the engine and understand its quirks.
Now, the issue is that Ashley has focused on other things. Your issues won't be expedited since it is evident that issues and limitations still exist, as was the case with multiplayer issues when Ashley focused on other features. It's not a problem for hobbyists, but for professionals with actual contracts, it's not ideal.
Furthermore, Ashley recommended the full scripting approach in his previous blogs. You actually have to be updated with the current events to know these first.
Contrary to the recommendation, as someone who actually attempted it, there are substantial issues with that, especially being locked out of the event sheet context as a last option when it is evident that the JS Scripting API is heavily lacking compared to the event sheet ACEs. You would inherently be self-limiting and rely on building everything on your own.
There are two approaches to using scripting: one is full scripting, and the other is through the event sheet context. The latter is what I recommend.
"there is still some limitations and missing API, so you have to mess with events from time to time"
You actually answered your own question, try collision performance test with only the JS Scripting API.
Despite the great progress however, without full engine support for JavaScript, such as collision. I would recommend sticking with the event sheet.
Using solely JavaScript in Construct 3 right now is like making a game without an engine.
This is great progress!
Ashley, this Stable release broke many of my projects.
- Scripts purpose reset.
- Icon purposes reset.
- AJAX request action removed.
- Files renamed to lowercase causing issues.
- And object conflicts that was caused by the engine automatically changing files and references.
All of these corruption I can see from GitHub changes. I am one of the lucky ones who use GitHub with project folder, and managed to easily revert changes.
At this point, I'd recommend using GitHub as source control to avoid issues like this in the future and easily revert changes or corruption made automatically by the engine, or even manually yourself.
This has been a painful update, and from a stable version of all releases.
Oh, hell no, it was never better. - 👴
That's understandable.
If multiple event triggers for functions / actions cannot ever be supported. How about at least add some flexibility? For example: Call 'custom' action by name.
At least we have an option, it's not mandatory to use. If some people find it unorganized, they don't have to use it.
I think that's a fair balance for organization and functionality.
Hi,
The custom actions feature, isn't it harder to use in actual projects? Probably not if the engine is for education and teaching programming, but for actual projects this is hard when scaling.
Imagine this, writing JavaScript functions directly like how it is in the event sheet. All functions are called directly, no strings, no dynamic names, etc.
I feel like Construct 2's Function object represents actual functionality in programming. Now, in Construct 3, it looks more about cosmetic and which looks easier to use.
I use JavaScript, so I'm not affected. Even with the new Construct 3 built-in Functions feature, I use "runtime.callFunction("functionName", param1, param2, param3,...)". However, those who don't will wonder why they have to create so many custom actions for such simple tasks.
Member since 10 Oct, 2014