fedca's Forum Posts

  • you can use iterators like this 

    for (const inst of runtime.objects.Sprite.instances()) {	
}

  • It sounds like stuff is already occasionally breaking and addon developers have to update their code. What happens when these addon developers decide to move on and stop maintaining their addons? We start facing backwards compatibility disasters and we are left to deal with the consequences.

    The community has created this Collective, besides funding new addons, it also mitigates that risk. So addons created under the collective can be maintained by other community members, including some monetary compensation.

    I also don't understand why you are left to deal with the consequences? We the community are. All you'd do is say: "your fault, told you so".

  • If there is a change that clearly improves c3, i.e. an improved text layouter, the chance of breaking something like the animate text addon might be painful but it's a clear benefit that makes this ok. In the worst case people late in development can stick to the previous stable (which they probably are already doing, as updating late in development is risky and makes porting more difficult).

    I am personally in favor of breaking compat more often than c3 is doing, at least if there is a clear benefit and a transition period.

    Bringing the scripting interface and addonSDK more in line sounds like a good idea, I am not sure I fully understand what you are implying with the wording though.

  • New-ish project about 3 weeks into development.

  • Up until now using undocumented feature meant we need to update addons if you make changes to the engine. I.e. you add RTL support to the text render and the animate text addon breaks, to fix that the addon dev needs to bring the addon back in line with the changes of the text renderer. (btw I don't think you got many, if any, people reporting that to you, but instead it was reported to Skymen).

    As you will always have some form of text rendering in the engine it's save to assume that while it might change, maybe even drastically, it is near impossible to be removed completely. This meant using undocumented features was a larger maintenance burden on the addon dev, with a small chance of being impossible to fix.

    Depending on the undocumented feature we could make an educated guess how risky it is to use. But now what you are saying means that you are purposefully intending to make all of this impossible permanently and you want to do it as soon as possible. Now we cannot weight the risk, because now there is Damocles sword over every undocumented feature.

    It's not clear to me what benefits this will bring, it sounds like a waste of time.

    I also think you underestimate how much value 3rd party addons bring to your product and it's a bit disheartening to hear that instead of trying to give more power to those developers you want to take power away. I also think you might not be aware how many developers and games moved away from Construct after hitting some limitation and then made highly successful games on other engines, these could have been hit games made with Construct.

    ... I could go on but I guess all these points have already been brought up by others

  • I see it as quite the opposite, the engine would become less reliable if we cannot fix our problem ourselves. This would be a risk for anyone building a game with c3. Because than the "wontfix" or "enhancement" has potential for much more dire consequences.

    This is also why having source code available is so common and the industry standard, as no company of a certain scale would risk this.

    Construct 3 already has a insanely limited addonSDK, I think bringing the addons sdk up to the industry standard would be a better solution if you are worried about engine hacks.

    • unreal engine: source available
    • unity: source available
    • Godot: open source
    • gameMaker: open source runtime
    • GDevelop: open source
    • Phaser: open source
    • playCanvas: open source
    • Defold: source available
    • ... and many more

    I'm confused what you, Ashley, mean with industry standard, as almost every game engine is either open source or source available.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It would be a very useful feature. Especially as you tend to have stuff you want to dynamically replace like this in string form inside a internationalization JSON.

    Still a lot of times you can use replace()

  • can you try with myNewInst.instVars.myId = i;

  • I think this is tricking you as Construct doesn't draw when nothing is moving but instead keeps showing the front buffer instead.

    So in that case the cpu draw calls and gpu usages goes down to basically 0. So I think it's not due to the tweens themselves but instead because the tween causes a new frame to be drawn ~220 times a second as now the screen is changing every tick.

    Try adding a simple rotating box to make sure the screen is still redrawn every tick in the tween off benchmark.

  • Here is an example of how you can add a random weight to the Flowcharts outputs:

    https://drive.google.com/file/d/1do6wH10LLeuj6NkkXOcrvg2Reh2iwQ8p/view?usp=sharing

    The higher the number you put in the value of the output the more likely the connected node will be picked. You can reuse the same thing across your project as long as you also use the tag "weightedRandom"

  • It doesn't show the dialog if the newest version is a stable, it just updates automatically. It only repeatedly show the dialog if there is a newer beta and you have enabled "notify me about beta releases"

  • try wrapping the set animation frame expression in int()

    Construct 3 changed to support animation frame tags in the set animation frame action, I think it does it by checking if the type is a string or number, while before it converted everything to a number.

  • For a shader like this the game would need to be rendered at a much higher resolution than the pixel art, so the pixels are small enough to be able draw the black lines like this.

    If you are interested feel free to contact me at: contact.fede.calcheraxso@gmail.com

  • Cut poorly? It's just a quick example. That shouldn't change the numbers. The top left area show this.

    Where it should show a 1, it shows 29.

    I'm assuming I'm missing something obvious, but it would be nice to actually have a template for these tilemaps.

    Auto16 works fine, but Auto47 doesn't.

    it looks like they are cut poorly around the 9, affecting the 2, 8, 10 and 16.

    You see how the rounded edge is erased over the border?

    To me this is the only thing that looks incorrect, the rest seems to work as intended.