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

0 favourites
  • 5 posts
From the Asset Store
Convert multiple Excel files into JSON files and import them into construct3.
  • 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();
    		}
    	};
    }
    

    But one folder up is a file named the same thing and it has this:

    	"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);
    }
    

    There are also several other duplicate named files. and those duplicates have nothing going on in them other than the un-commented default. In total there are 12 files to edit in order to make a single behavior. Not to be the person who keeps saying, "Unity this, and unity that"... but in unity, you make one script, and maybe one more to define how properties are displayed in the editor, and that's it, not unlike many other engines out there.

    I mean, all this extra data should be generated by c3, and editable in editor. There is no reason to have to wade through 12 files, regardless of how 1337 your single ACE is. Imagine if you had to create 12 files in Unity, just to move a transform every tick. Rar,

    /rant

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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.

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

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)