Addon sdk... better explanation of organization(why are there two behavior.js files?)

Call me dumb, but for the life of me, I can't figure out wtf half these files are doing in the template and why they are arranged that way. The addon sdk doesn't really help either. Ideally there should be some more pictures and break down whats going on. Instead, the manual is like, "Make sure you change this line here, and here, and here, to match this line over here... What is this? American tax season? I shouldn't have to waggle around 12 files to follow what a SINGLE behavior is doing. Its ridiculous.

You think you could just read them, and they would have comments explaining what they are doing, but not really, they more or less just warn you you can break a behavior just for doing things wrong... In the c3 runtime folder in behavior.js is this:

	"use strict";

{
	const C3 = self.C3;

	C3.Behaviors.MyCompany_MyBehavior = class MyBehavior extends C3.SDKBehaviorBase
	{
		constructor(opts)
		{
			super(opts);
		}
		
		Release()
		{
			super.Release();
		}
	};
}

	"use strict";

{
	const SDK = self.SDK;

	////////////////////////////////////////////
	// The behavior ID is how Construct identifies different kinds of behaviors.
	// *** NEVER CHANGE THE BEHAVIOR ID! ***
	// If you change the behavior ID after releasing the behavior, Construct will think it is an entirely different
	// behavior and assume it is incompatible with the old one, and YOU WILL BREAK ALL EXISTING PROJECTS USING THE BEHAVIOR.
	// Only the behavior name is displayed in the editor, so to rename your behavior change the name but NOT the ID.
	// If you want to completely replace a behavior, make it deprecated (it will be hidden but old projects keep working),
	// and create an entirely new behavior with a different behavior ID.
	const BEHAVIOR_ID = "MyCompany_MyBehavior";
	////////////////////////////////////////////
	
	const BEHAVIOR_VERSION = "1.0.0.0";
	const BEHAVIOR_CATEGORY = "general";
	
	const BEHAVIOR_CLASS = SDK.Behaviors.MyCompany_MyBehavior = class MyCustomBehavior extends SDK.IBehaviorBase
	{
		constructor()
		{
			super(BEHAVIOR_ID);
			
			SDK.Lang.PushContext("behaviors." + BEHAVIOR_ID.toLowerCase());
			
			this._info.SetName(self.lang(".name"));
			this._info.SetDescription(self.lang(".description"));
			this._info.SetVersion(BEHAVIOR_VERSION);
			this._info.SetCategory(BEHAVIOR_CATEGORY);
			this._info.SetAuthor("Scirra");
			this._info.SetHelpUrl(self.lang(".help-url"));
			this._info.SetIsOnlyOneAllowed(true);
			
			SDK.Lang.PushContext(".properties");
			
			this._info.SetProperties([
				new SDK.PluginProperty("integer", "test-property", 0)
			]);
			
			SDK.Lang.PopContext();	// .properties
			
			SDK.Lang.PopContext();
		}
	};
	
	BEHAVIOR_CLASS.Register(BEHAVIOR_ID, BEHAVIOR_CLASS);
}

Try this one if you havent yet.

construct.net/en/forum/construct-3/plugin-sdk-10/c3ide-construct-plugin-ide-141201

Try this one if you havent yet.

https://www.construct.net/en/forum/construct-3/plugin-sdk-10/c3ide-construct-plugin-ide-141201

Yes, thank you! This tool is amazing. I have used it a bit, but I prefer to make sure I understand all the things it is automating before really using it...

I think the biggest issue is that it is really easy to forget to change one line here or there (or worse, misspell it lol). Obviously that is a personal problem I suppose, There are a lot of 't's to dot and 'i's to cross - erm... the other way around... and so the workflow of adding a new _function to an instance and having a complete set of ACEs and property for that function is alot. Especially when perhaps it might just be basically a property with a getter and setter.

one is for Edit Time, the other for Run Time.

But I agree that it's super annoying to have to juggle a ton of different files for addons.

If I recall, in c2, I remember only a few files. One for shared scripts, one for edit and one for runtime. I'm curious why there was a decision to parse them out like this.

Adding the language support is nice, but that alone adds quite a bit of redundant typing and opportunities to misspell things - But I do like that the descriptions and such aren't wrapped up in those long calls to create new aces that we had in c2.