We also have the Construct Community Collective where addons can be crowdfunded. A few ones like The FMOD addon, the open sourcing of 3dObject etc. have been funded that way.
On the Construct Community Discord there are a bunch of addon devs and we have an offer channel.
But you can probably make an offer here on the forums as well.
As someone that uses a mix of scripts and events in all projects, an overhaul of the c3 scripts editor would be amazing, as I don't like switching to an IDE. The auto completion c3 gives is not really helpful in its current form and could be be much better if it had type hints. Also auto formatting as I suggested here https://github.com/Scirra/Construct-feature-requests/issues/80 would go great with this.
this is an issue specific to 0.93, I reported it here: https://github.com/Scirra/Construct-bugs/issues/8309
and a fix is already done but will take some time to be deployed
this is the explanation from the person that made the original nvpatch:
toptensoftware.com/blog/nvpatch-how-it-works
Skymens tool is afaik just a ui wrapper for it, so it's easier to use.
you unpack, run the updater, remove it, zip it again and then distribute
Btw I also have been using space separated string tags for my own systems and so I did some performance measurements of different approaches of the tag comparison.
Here I am comparing Array (includes) vs Set (isSubsetOf). Array is hugely faster, I tried with different tags amounts etc, still array seems to be consistently 3 times faster:
https://jsbenchmark.com/#eyJjYXNlcyI6W3siaWQiOiJ1Vnc1N0tXUm4wWXZJMnNzY09mS3YiLCJjb2RlIjoiY29uc3QgdGFnczEgPSBcImhlbGxvIHdvcmxkIGFuZCBiZXlvbmRcIi5zcGxpdChcIiBcIik7XG5jb25zdCB0YWdzMiA9IFwiaGVsbG8gd29ybGRcIi5zcGxpdChcIiBcIik7XG5cbmlmICh0YWdzMS5ldmVyeSh2ID0-IHRhZ3MyLmluY2x1ZGVzKHYpKSkge30iLCJuYW1lIjoiYXJyYXkiLCJkZXBlbmRlbmNpZXMiOltdfSx7ImlkIjoib2t0bFgtaEZsVy02c3gxOS1ZVmpKIiwiY29kZSI6ImNvbnN0IHRhZ3MxID0gbmV3IFNldChcImhlbGxvIHdvcmxkIGFuZCBiZXlvbmRcIi5zcGxpdChcIiBcIikpO1xuY29uc3QgdGFnczIgPSBuZXcgU2V0KFwiaGVsbG8gd29ybGRcIi5zcGxpdChcIiBcIikpO1xuXG5pZiAoIXRhZ3MxLmlzU3Vic2V0T2YodGFnczIpKSB7fSIsIm5hbWUiOiJzZXQiLCJkZXBlbmRlbmNpZXMiOltdfV0sImNvbmZpZyI6eyJuYW1lIjoiQmFzaWMgZXhhbXBsZSIsInBhcmFsbGVsIjp0cnVlLCJnbG9iYWxUZXN0Q29uZmlnIjp7ImRlcGVuZGVuY2llcyI6W119LCJkYXRhQ29kZSI6IiJ9fQ
This may be interesting to consider for Diego and Ashley, as afaik currently Sets tend to be used for tags. Though this is a simplistic test, maybe for other reasons sets are benefitial and faster.
Having multiple tags for timers would be useful, but one downside is that checking tags vs tags is heavier than just a string comparison. But if perf impact is minimal or a fast early out if only one tag is used is possible I am in favor of it.
You could do a loop with 18 repeats and increment it yourself with a local variable (or multiply the loopindex by 20)
For multithreading you can use web workers, there is an example project for it too: https://editor.construct.net/#open=scripting-web-worker
But in my tests the cost of messaging really made the performance gains minimal or even made performance worse, so it ends up not being worth the additional complexity in most situations. You can probably make it work much better by using sharedArrayBuffers, but that doesn't tend to be supported well or at all on platforms like itch.io, scirra arcade(?) etc.
Develop games in your browser. Powerful, performant & highly capable.
There have been multiple suggestions about family inheritance over the years (like this one: https://github.com/Scirra/Construct-feature-requests/issues/1) but AFAIK Scirra is not interested in pursuing this design and wants to enforce a more component based architecture. But this is also difficult to do with events as it's not easy to traverse families, for that I made this suggestion: https://github.com/Scirra/Construct-feature-requests/issues/7
I feel like either of these additions could make your intended system easier to implement
An additional feature that could make families more flexible, but not directly connected to this issue, is having a type that is based on worlObject instead of plugin type, suggested here: https://github.com/Scirra/Construct-feature-requests/issues/383
Global or normal layers don't keep their state. Only global or persistent objects do.
Seems like a proper way to handle this is missing, maybe having a getFamilies() API on the objectClass interface would make sense.
getFamilies()
made a suggestion:
https://github.com/Scirra/Construct-feature-requests/issues/373
agreed, this limitation makes booleans annoying to use and I also prefer numbers that I set to 0 or 1. The only downside is that it doesn't enforce only setting to 0 or 1 and can be less explicit especially if you work on the project with multiple devs