Chadori's Forum Posts

  • You do not have permission to view this post

  • Ah, this is dark theme, and it's called the action/condition highlight. I think it is implied that this is done to commonly used actions/conditions. This is not based on your usage, rather predefined by the developer.

    In the default theme, that would be a dot on the left side of the action/condition, on the action/condition selection dialog.

  • Release 43 - Stability Update

    Hi everyone, there is a new stable update for the Construct Master Collection, please click here to read the release note and download the update.

    Thank you.

  • Hi everyone, for those who are using the Pro UI plugins, here is the fix to get audio to work in the latest versions of Construct 3.

    Steps

    1. Unwrap the aekiro_proui.c3addon by renaming to aekiro_proui.zip.

    2. Extract folder

    3. Open the file instance.js in the c3runtime folder with any text editor, preferably applications like VSCode.

    4. Find this code below: 

    this.act_PlayByName.call(audio,0,this.fileName, 0, this.volume, "sound");

    5. Replace with the code below: 

    this.act_PlayByName.call(audio, 0, this.fileName, 0, this.volume, 0, "sound");

    6. Repack the files back by compressing into a .zip file, aekiro_proui.zip.

    7. Rename into aekiro_proui.c3addon.

    8. Reinstall Construct 3 addon (plugin).

    Before screenshot

    After screenshot

    Jase00

    I do not agree about Scirra being unaware or choosing to ignore the issues

    On my own project, a desktop rhythm game, I have different settings for visuals, and when on "Ultra", I do see jank when cpu and gpu usage are both about 60% and the FPS is always stable

    Of course you don't, I reckon you mainly export to desktop.

    This is exactly it, no one in other platform exports have any idea. They think the same performance issues they have on desktop or web are the same, it literally isn't. You can still make rhythm games on desktop and reach 60% CPU usage while playable. However, mobile can reach 5% CPU usage and already starts lagging, because there is performance throttling and horrible stability issues.

    The desktop export is very powerful, not because of your device performance, but the browser itself, yet you still complain about performance issues. Imagine our case with weaker devices, very problematic browsers and zero engine features to alleviate it.

    You shouldn't use your case as a reference to our issues. This toxic positivity just makes our situation overlooked even further.

    If they cannot resolve anything, is it up to Scirra to find a workaround or solution? I do not know.

    Please just don't make it worse, ignorance of mobile issues and trying to make it look alright is a quinquennial problem now.

    The Construct 3 developer isn't aware, and after reading posts like this, we'll surely be pushed back from scratch again.

    Hear hear!

    Construct 3's mobile department is hopeless, no one is even bothering to check for any issues.

    It is pointless to argue since it's apparent that the Construct 3 developer isn't even aware of the issues or chooses to ignore them. So many people have tried and just gave up.

    Most tests the Construct 3 developer makes are about how fast JS is in the web, since that's what he only ever truly does. And then advertise how fast JS is, and make it look like even mobile is as well. Not after those benchmark tests that have no relevancy to actual issues of performance stability and performance throttling on mobile builds.

    For new users, if a game isn't as simple as Flappy bird or Angry Birds, then don't bother making it. If you think performance will get better after export, you'll be surprised it will be at least 30% worse after export than preview. And that's before the stability issues.

    Back in 2016, the Construct 3 developer said devices are getting more powerful and the performance will get better. Well, that's true, but not that you will benefit from it, Construct 3 performance is getting worse.

    Every tick needs to be light on mobile, but even the actual event sheet is so heavy and bloated, it's almost like a JS sandbox. I've fixed that by coding with JavaScript, but wait until you hear about a bigger problem, refresh rates on mobile.

    The browser is still as slow, but the demand for graphics is getting higher. Dealing with 60Hz on mobile exports is bad enough, but now we have 120Hz, and the Construct 3 developer is acting like it's no big deal, they made another product Animate since they probably feel like they have so few things to improve in the actual game engine.

    And then we suggest for frame rate locking, and the Construct 3 developer indirectly says it is a horrible idea for some technical reasons in which Chromium doesn't support, yet other engines like Phaser support. We then get linked to that everlasting Chromium issue that everyone already abandoned, forgotten or worked around.

    What's worse, is that people who either are clueless or only exports to web, web mobile or desktop, will also reply and say that the performance is fine, making us getting ignored even further. That is until they have to experience it themselves, and then be the ones to complain in the future.

    It's so easy to brush something off you don't experience or care.

  • Can we have runtime events for layouts? Specifically:

    Undocumented events

    1. beforefirstlayoutstart
    2. afterfirstlayoutstart
    3. afterlayoutstart

    Needed events

    1. beforelayoutstart

    Most especially beforelayoutstart, since running plugin tasks after the event trigger On layout start causes timing issues. I currently need to do plugin calibrations before the event sheet starts.

    Tagged:

  • I'm sorry to bother you, but either the SDK (which is not an SDK btw) or the documentation is lagging behind or missing parts

    Construct 3's official Addon SDK documentation is definitely not a real documentation, it's more of a dictionary.

    In the early days, we used to inspect Construct 3 to know how to use them properly, which is also inconvenient due to the engine being obfuscated.

    Fortunately, there are already a lot of addons available now for learning material, you can just unpack them and see how it all works.

  • I also have no idea what this has to do with Construct Animate or why anyone even mentioned that.

    and I would emphasise, that is absolutely nothing to do with Construct Animate

    Since you are curious:

    From past discussions, it has already been pointed out (by others) that whenever someone complains about something and it goes on for a while, at the end of a long discussion you always end up saying you have a small team and it is not feasible to implement. However, you were still able to create an ambitious project like Animate that no one ever suggested.

    Just a suggestion, no need to get defensive. I didn't say the technicalities involve Animate, I said the potential workload is probably better risked here where your majority of users reside, compared to a future sighted project like Animate.

    This feature already exists in other free HTML5 game engines like Phaser and GDevelop.

  • I wouldn't even suggest this considering you could waste your time when browsers eventually support this, especially since you have a small team.

    However, I think most would agree that your time is better potentially risked to be wasted here than something like Animate, which your subscribers probably rarely use.

  • Would it be preferable to include support for setTimeout() if requestAnimationFrame() wouldn't get us support for limiting fps? At this point, I think it is worth it.

    The cons of not using requestAnimationFrame() are tolerable compared to working around the uncontrollable application fps, especially on mobile. Unless you recommend us to only make simple games.

    It is so easy to skip frames in Construct 3, especially since the event sheet already has a huge overhead than JavaScript. Having a 120Hz mobile phone, that leaves us little processing time per cycle, it's not farfetched to think that it could only take a For each condition in a RTS game to create phantom stutters on runtime. Especially since it is already hard to optimize smoothness for a 60Hz mobile phone.

  • Hi sialifecom, upon checking everything seems to still check out.

    My best guess is that you haven't configured your Xcode application or haven't updated updated to the latest version, which is required by Construct 3, especially with SDK integrations like ad-networks.

    If you need realtime technical support, please kindly visit our Discord server.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Hi everyone, sorry for announcing too late. Support channels are on halt until Nov 03, 2022. Thank you for understanding.

  • The first method I mentioned doesn't require another Construct 3 plugin, that is just an automated way to do it in your build outside the Construct 3 Build Service if you do not use a Construct 3 plugin.

    Now that I looked at your linked snippet, that's exactly what the Cordova plugin does.

    However, if you plan to modify your Android Studio project directly, you can look for the line com.google.android.gms.permission.AD_ID in the AndroidManifest.xml and remove it.

  • You can remove that through a Cordova plugin: chadori-mobile-ad-families-programs, you just insert it in your config.xml through Cordova project export.

    If you have the Construct Master Collection, you can do this automatically by adding the object Mobile Advert Families Programs.