fedca's Forum Posts

    • Post link icon

    I have marked my none effect addons as deprecated now as I am not sure I'll port them. They are open source though and it should be straight forward for anyone to port them if your project relies on any of the addons.

  • Array, dictionary and JSON all can have different data and state.

    FlowchartControllers all have the same data but a different state.

    Unless I am missing something.

  • I agree, I was supper confused when I realized it about a week ago.

    I initially assumed Flowcharts controller hold their own data and state, just like a the JSON, Array and Dictionary Plugins. But it seems like flowchart controllers all reference the same current flowchart, they only differ in the state of that current flowchart.

    This makes it way less flexible, can't really have one flowchartController for npc dialogue (maybe you would even want to have a flowchart controller in a container of each npc, each referencing their own dialogue tree) and one for the progression system etc.

    With the current implementation it means you have to swap the flowchart all the time making it really weird imo.

    Tough I'm sad as it seems like it might be too late to change it due to backwards compat.

  • Since r376 you can set animation frames by tag too, it is done by checking the type (set frame by number if number, set by tag if string). So this is intentional I think, but yea I have also seen a lot of people on the Construct Discord getting tripped up by this..

  • in the example the function is named "add" not "Addition", did you maybe rename it only in one place?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The built-in advancedRandom objects scripting interface allows getting different types of noise in js. Afaik it uses a wasm module which means it should be speedy.

  • Object.pickedCount <= 0?

    Events don't run if a picking condition returns 0 instances.

    So the else solution is also the one I use

  • 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