Chadori's Forum Posts

  • Hi, you can use our Mobile IAP (Pro) plugin if you need subscriptions and other advanced features.

    constructcollection.com/documentations/mobile/mobile-iap

    The latest Billing version is also in Beta on our Discord server, pending a stable release.

    discordapp.com/invite/eS3HK88

    Ashley

    Therefore addon developers have, as a minimum, over a year to update their addons (one year starting from the next stable release). We will review this schedule over time and milestones may be delayed if necessary, but we are publishing this as a guide for addon developers to plan with on the assumption that this schedule will be adhered to.

    I would like to request that this timeline be extended to at least 2 years. Not because it takes time for us plugin developers to port the plugins to Addon SDK v2, but because I doubt the API will be able to catch up with the needs of the plugin developers.

    For context, it's been 5 years, and the scripting interface is still incomplete. It's only recently that the majority of the features have been interfaced with the scripting API, but that's still only relative to the event sheet.

    Assuming it took a year to cover all essential APIs for the plugin developers to get to work, which I doubt, they still cannot just instantly port all the plugins; additional time is still needed.

    Even if the plugin developers can work concurrently as new APIs roll out as new update releases, you cannot expect them to, especially those who are doing this only out of the kindness of their hearts for the community in their free time.

    Ashley

    As I've said before, I am keenly aware of the amount of work this will create, and that is regrettable. However, please understand that we are not doing this for fun: the current compatibility disasters and future risks are in my view so severe, that this is very much necessary, despite the magnitude of the problem it will create in the short to medium term. If you don't believe me or disagree with that judgement, I'm there's not much more I can add, other than to say that you either learn the lessons of history, or you are doomed to repeat them. The industry came up with encapsulation to solve these kinds of problems, and we are moving towards that industry-standard approach. If we postponed this by a few years and then were forced to do it anyway, it would be even more difficult and even more addons would need updating. So if it's going to happen - and in my view it absolutely has to - then the sooner we act the less bad it will be.

    Why are you trying to convince or gaslight everyone into believing that the developers are too lazy to update the plugins? That's not the issue here; the issue is that you are pushing for Addon SDK v2, making it look like it will solve all our problems with encapsulation when it barely has any API in it.

    You are launching an Addon SDK v2 with an incomplete API and blaming plugin developers that we do not cooperate. We're aware of what you're trying to do; you are making yourself look good and making it look like you have every customer's best interest in mind. 

    When, in reality, you are the one not cooperating. How are we supposed to port the existing plugins into the latest Construct 3 editor where, otherwise, other engines would work?

    Ashley

    We aim to solve this problem and ensure customer's projects can continue working even in the long term without maintenance by the addon developer.

    You say this like plugins don't break every now and then, every few updates. The only difference now is that 1) it's impossible to support existing, essential, and commonly used plugins; 2) the cons outweigh the pros; and 3) the reason is ironic; it creates the problem it attempts to prevent.

    Construct 2 never had such issues. A plugin from a decade ago still works even now. My projects from a decade ago in Construct 2 still work even now.

    Wouldn't you call that ironic? Every time you try to prevent project breaks, our projects break more and more.

    customer's projects can continue working even in the long term

    All my projects use Spriter; when Addon SDK v2 becomes mandatory, my projects will all break. Nice job, problem solved!

    You created the problems you sought to prevent.

  • Yeah, mobile export as well.

    Windows Defender log after having quarantined my exports:

    Detected: Trojan:Script/Wacatac.H!ml

    Hi Ashley, this seems like a serious issue.

  • Hi everyone, releasing a new update soon.

    If you have any feedback, please make sure to write it this week so that I can apply it in the next release.

    Thank you!

  • Release 46 - Stability Update

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

    New plugins

    1. PlayFab Master Collection (v2)
    2. PayPal - Web payment service!

    Thank you.

  • The PayPal plugin is now production-ready! I am really looking forward to the release of this new plugin.

  • Hi everyone, I'm preparing for the next version update. There is also an upcoming new PayPal plugin for web payments, if you have any concerns, please visit the Discord Community by clicking the link below.

    https://discord.com/invite/eS3HK88

  • Hi, sorry for the late response in the Discord Server, it should just be like this.

    PlayerManager.getEmailStatus(PlayerManager.loopEmailList)

    I hope that helps.

  • Hello, probably this issue: bugs.chromium.org/p/chromium/issues/detail

    Basically, Construct 3 is an HTML5 engine that uses Chrome Webview for Android, which has always been problematic and have horrible performance. It's not Construct 3's fault though, at least directly, rather the tech they use, which Google provides.

  • I usually import Spriter in an empty Construct 2 project, then import that Construct 2 project in Construct 3. Finally, copy the Spriter files to my main Construct 3 project.

    Spriter Team tried implementing the import same in Construct 3 as Construct 2. However, the Addon SDK is just that awkward.

  • _FlameSlayed_, press OK and F12 on the editor, screenshot the log, then upload it here, and I'll try to debug it.

    Whenever I get file corruption like this, I always get it repaired. In the worst-case scenario, though, as long as you have at least one backup within the month, it would only be an issue with swapping missing or corrupted files, so you would still be able to recover most of your progress.

    However, even if you don't have a backup, as long as the file size didn't significantly change, chances are it is still salvageable, depending on the log.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I can reproduce; I don't know what causes it. The steps to reproduce vary, however, and sometimes resolve themselves.

    For your reference:

    1. https://github.com/Scirra/Construct-bugs/issues?q=getModifierState
    2. https://github.com/Scirra/Construct-bugs/issues/7464
    3. https://github.com/Scirra/Construct-bugs/issues/7456
    4. https://github.com/Scirra/Construct-bugs/issues/7455

    The common error message is Uncaught TypeError: d.getModifierState is not a function. The Construct Team closes all issues regarding this since it's not reproducible from a project but rather the editor itself.

    To note, this issue started months ago, with the export not working if you don't preview first. However, now even that remedy doesn't work anymore. Then, the next remedy is to restart the editor. Now, that remedy also doesn't work anymore. It's practically random to me now when it will work.

    I myself am stuck with this and have to call it a day from time to time when this happens.

    My best guess is that some files aren't loaded properly in the editor while exporting, and this happens. I would like to dig into what's causing the issue to file a report, but the engine is so obfuscated that it's like an insult to anyone who does try to investigate, like our time doesn't matter.

    Ashley, if you want us to investigate issues ourselves, at least help us and not make it hard.

  • > > > > I use Admob and understand that the advertising ID maybe depends on the required DGPR settings. What should I do?

    > > >

    > > > You do not need the GDPR requirements you are thinking of for Google Play's Designed for Families Programs, specifically the Advertising Id. Furthermore, if you are using the Mobile Advert object, it's automatically incompliant because the consent dialog is hardcoded.

    > > >

    > > > I'm not sure if you can get away using the Mobile Advert as long as you do not launch the consent dialog. Although, considering it is Google, I wouldn't risk it. In spite of that, you still need a plugin to remove those ids specified, like this plugin does: constructcollection.com/documentations/mobile/mobile-advert-families-programs

    > >

    > > Ohh, okay.. and what do you think about these actions? Perhaps they can help?

    > >

    > >

    >

    > Those are only for COPPA, which are one of the requisites.

    Yes, but judging by this window we can treat all users as children. It also mentions the GDPR window, which is why there is a problem, because when it wasn’t there, everything was fine. The window requires mandatory data collection.

    Can you understand this? Google has introduced a mandatory requirement to illuminate the window, but it is prohibited for children. Haha, sur.

    They themselves cannot understand their decisions, it’s the same network, like Admob, like Google, they shouldn’t have problems. I can't remove the GDPR window because it's mandatory. Why should I bypass some strange methods and new plugins and write something in the manifest... Hide something.. Is it really not possible to just track whether it is a child or not, and show a window depending on the age.. Maybe there is an action "Tag for under age of consent" is exactly it.

    I apologize for so much text, but I want to figure it out once and for all. I removed children from the app and lost most of my audience. I won't be able to continue to receive such a stable income, and develop an update... It's a nightmare.

    It would also be a good idea for the Construct developers to look at this whole situation, because as you write, they “dialog is hardcoded”... I am surprised by the silence of many, because this is clearly a problem.

    If you are trying to vent, I understand. But, if you are asking me what's the issue, then to elucidate what's happening based on your provided Google rejection response:

    1. It's not an issue with your event sheet.
    2. Rather, it's an issue with your SDK integration and Android Manifest.
    3. You shouldn't have anything in your project that identifies your users since it's targeted only for children.
    4. In your case, your project's build integration.
    5. Assuming you only have the Mobile Advert plugin, you need to remove those identifiers.
    6. No, you do not need a consent dialog. Quite the opposite actually, it's preferably removed, if not required.
    7. Strictly remove the AD_ID permission.

    When writing for this compliance for my own projects and plugin collections (a quick solution). I used this as my guide: support.google.com/googleplay/android-developer/answer/9893335