fedca's Forum Posts

  • I always just do everything in WAV and c3 automatically converts it to webM on import. So there is no need to ever use the webM file directly for me, still audacity can open webM fine.

  • I haven't updated this thread, but I did release a couple of shaders since the last post:

    Reflecting Water:

    https://www.construct.net/en/make-games/addons/1233/reflecting-water

    Gradient Depth Fog, fog exponential but with a color gradient:

    https://www.construct.net/en/make-games/addons/1212/gradient-depth-fog

    Cloaked, hides an object but slightly shows its silhouette with animated chromatic abberation:

    https://www.construct.net/en/make-games/addons/1215/cloaked

    Vertical/Horizontal tube, fake 3d like distortion:

    https://www.construct.net/en/make-games/addons/1196/vertical-tube

    https://www.construct.net/en/make-games/addons/1195/horizontal-tube

    Pallete swap 8 and 4, replace the color palette, with optional dithering:

    https://www.construct.net/en/make-games/addons/1199/palette-swap

    https://www.construct.net/en/make-games/addons/1214/palette-swap

  • I wrote a new timer behavior that uses real triggers https://www.construct.net/en/make-games/addons/1236/trigger-timer it outperforms the build in timer behavior in all cases I have tested and also only has one instance picked in the on timer trigger. (I also added some additional features)

  • 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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • 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"