Sdk2 script interface trouble

Post reply
0 favourites
  • 7 posts
From the Asset Store
Impact Action Interface
$9 USD
J.BoB Impact Action Interface Sound Pack comes with 120 high-quality sound effects
jbobsound's avatar
jbobsound

  • Hello,

    I am having trouble accessing behaviors from js in construct:

    For example. I am using the sdk2 sample behavior. 

    const o = runtime.objects.Sprite.getFirstInstance();
const b = o.behaviors.MyCustomBehavior;
o._setMyProperty(5);

    I get the error that _setMyProperty is not a function. In the v1 of the sample behavior, the script interface maps to _setMyProperty.

    The manual says to simply put what we want to access via script in main class.

    Which, I am trying to understand. Wouldn't this mean we have no ability to prevent users from accessing a behaviors runtime methods or properties, or will #private protect them. I wanted to test this, but atm, I can't access anything from script on v2.

  • It's a typo in your code. You wrote o._setMyProperty(5) instead of b._setMyProperty(5).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Wholly barbecued barnacles. You have no idea how long I stared at that even after you pointed it out.

    Thanks.

    As to the second point, is there a way to prevent users from accessing functions we want to keep private?

    I have typically structured my addons the way it is recommended, with properties and methods in the main class and all ACES simply calling getters/setters/and functions, but I always had some functions that shouldnʻt be accessed out of order or context and I donʻt really need them exposed to the scripting side in c3 editor.

    ex: 

    //Some complicated task
DoSomething() {
	_doPrepThingA();
	if(_checkThingB()) {
		_doSomething();
		_resolveThingA();
	}	
}

    Where DoSomething wraps up all the things that need to happen everytime a user would want to do the thing. But, _doSomething does that thing without the additional checks and is used internally for performance reasons, but shouldnt be available to the user.

  • I would just use private methods. They already have broad browser support and we're going to start using them in the core engine soon. Closure Compiler doesn't support them, but UglifyJS does (part of the motivation to move to it), and we're going to drop support for Closure Compiler as soon as we're confident UglifyJS works well enough (which it looks like it does so far).

    BTW I'd recommend setting up TypeScript for addon development - it will help catch errors like the one you ran in to. The type checker and autocomplete are really good.

  • Okay, Cool, cool.

    ... Uh, Does type script work within the c3 environment?

    I thought typescript only works outside of c3?

  • At the moment TypeScript does require an external editor like VS Code. But as TypeScript compiles to JavaScript files, it's not much different for addon development, as that already needs an external editor.

  • Ah gotcha, I was doing alot of js blocks to test out script interfaces, so I wasn't in vs atm. I suppose I could write it there and then just paste it to blocks so I don't make dumb mistakes like this.

Post reply
  • 7 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)