Unity recompiling loop is faster than testing sdk addons. Tips to speed up?

So... as much flak as unity gets for having to recompile everytime you change a script, that look is much faster than making adjustments to behaviors or plugins.

I'm deep into development now, and there are 2 things that really stand out.

1. Why do I have to leave the construct editor to author sdk files when I should be able to do that in the same place I can write js blocks and script files?

2. Debugging addons takes place in 3 places. 1st you have your ide, then you have to solve errors if the addon can't be loaded. (things like 2 parameters expected in description, only 1 found), then lastly in a running project.

Then you have to relaunch c3 everytime you make editor side changes. While previewing a project is super fast and no compile time exists for editing events, the cycle for sdk addons is pretty slow.

This is more of an observation than a real complaint and was curious if others speed things up.

It's beyond me as I do not know anything about addon development, but, are you using developer mode? Maybe you already are, but wanted to mention just in case!

construct.net/en/make-games/manuals/addon-sdk/guide/using-developer-mode

It's beyond me as I do not know anything about addon development, but, are you using developer mode? Maybe you already are, but wanted to mention just in case!

https://www.construct.net/en/make-games/manuals/addon-sdk/guide/using-developer-mode

Yes, thank you for asking though. I currently am using c3IDE to build behaviors, and it is also super helpful, but I notice it doesn't catch alot of errors before export.

But I'm also pretty sure its a js thing, and I'm just not used to the dev cycle for it. Mostly things like, you can't call this._someFunction at runtime, but you can sure as you please include it without warning.

C3IDE is pretty old nowadays and I don't think will be maintained in the future. I would recommend switching to C3IDE2 that has been completely remade to be faster to dev with and easier to maintain. C3IDE2 doesn't have an editor yet, but there are plans to make one in the future, however I can attest that it is overall smoother to use than C3IDE was.

github.com/ConstructFund/c3ide2-framework

github.com/ConstructFund/c3ide2-cli

Also, I recommend doing addon work in two main passes. First you do the editor side where you define all the ACEs and properties of the addon, and then you do the runtime side where you actually implement the addon itself. Nowadays C3 can (or at least is supposed to) reload addon files from the dev server when you hit preview. I don't think this updates the editor side, but it does update the runtime side.

An optimal workflow would be to open an empty project and save with your addon added, and keep reloading C3 and that project until the addon is set up. Once that's done, implement the actions you wanna test, and press preview every time you wanna test your implementation.

C3IDE was also not really designed with that workflow in mind, as it assumes you will be implementing the runtime part of each action immediately after defining them. The new framework cleanly separates the two.

Also, the new framework was designed to be used with all the advantages VS Code comes with, including generative AI to autofill repetitive tasks for you, so if you have Copilot, writing addons can be done much quicker as well. I would say to be weary of doing that because often Copilot can fill in the wrong things, and you can easily end up spending more time fixing its problems than actually just writing the code yourself. Keep that in mind if you plan to use it.

Since the framework doesn't have an editor, creating new addons and starting the web server have been moved to the CLI instead. You can still do the process manually if you prefer though. Also each addon comes with an individual dev server script in case you prefer to work that way.

Ah, that makes good sense.

If there is no editor for c3ide2, what exactly does it do for you?

I like that with cside, I can add a action and that I cal fill out the details and it auto generates the json definition and language file, etc... It has a nice level of hand holding that limits the number of stupid mistakes you make (like defining parameters, etc...)

Part of my issue is that I tend to sketch as I go. As often as not, I am brainstorming what I need as I write it. I tend to have have something loosely in mind - (for example, I'm tired of using events to calculate the dot product, so I make a plugin to do it, or similar).

But I'm also constantly adjusting my behaviors, either splitting them apart, or combining them to afford me maximum flexibility and minimise repetitions in events. (not being able to nest families, or extend behaviors from behaviors, or share them is all part of the issue )

Applying editor-side changes while the editor is open is an extremely difficult problem. What happens to the project you are looking at if the addon has a breaking change made while you have a project open? There are probably hundreds of ways the editor could crash after that, and it's infeasible to spend weeks or months doing all the work to sort out all those possible cases instead of doing other things like new feature development, just so you don't need to reload the editor during development.

That doesn't apply to the runtime though, so you can in general make any runtime change and it will apply on the next preview.

Applying editor-side changes while the editor is open is an extremely difficult problem. What happens to the project you are looking at if the addon has a breaking change made while you have a project open? There are probably hundreds of ways the editor could crash after that, and it's infeasible to spend weeks or months doing all the work to sort out all those possible cases instead of doing other things like new feature development, just so you don't need to reload the editor during development.

That doesn't apply to the runtime though, so you can in general make any runtime change and it will apply on the next preview.

I wasn't meaning to say the ability to make hot changes to the editor should be added! I totally agree, not worth the dev time. To be fair too, in unity you basically have no choice, all game logic is scripts that must be compiled after every change, whether runtime or editor side.

If there is no editor for c3ide2, what exactly does it do for you?

It still does the same thing, the only difference is that you fill out a much simpler JSON format and the framework compiles everything to a proper c3addon.

In general, it offers more or less the same capabilities as C3IDE, but loses some of the editor capabilities (like dropdowns instead of a list of accepted values written in a comment). In exchange, it offers way more freedom to change about anything you need inside the generated addons and the structure of things.

For example, I have used it to make it so scripting runtime can be auto filled by the framework for you, instead of having to define all ACEs a second time for the JS scripting side.

In the same vein, I have used it to simplify the process of working with DOM side scripts, external scripts, C++ wrapper extensions etc, all of which C3IDE doesn't and can't support because of the way the editor has been designed.