Is it possible to reference things outside of your plugin?

For developers using the Construct 2 Javascript SDK

Post » Mon Aug 18, 2014 7:49 pm

These might be painfully obvious and I'm not just seeing them. I might also be trying to make the plugin system do what it isn't intended to do.

Is there a way, for example, to access a list/object/array/whatever of all of the sprite instances on a layout and act on them?

Can I reference a behavior from my custom behavior? For example, could I set path targets and initiate movement programmatically?

Thirdly, is there a way to access a "global" variable that is persistent? Does runtime.extra function that way?

Thanks for any/all help! Actually, is there a more "informal" api reference? I feel like there's a lot more available than what is in the SDK reference? Am I wrong?
Developing Surolace, the survival role playing space game.

surolace-survival-role-playing-space-game_t116953
B
14
S
4
Posts: 303
Reputation: 1,730

Post » Tue Aug 19, 2014 1:36 am

Yes , it is possible to reference other plugin or behavior. For example, reuse ACE in your plugin or behavior-
http://c2plugins.blogspot.tw/2014/02/reuse-ace.html
B
109
S
27
G
277
Posts: 4,481
Reputation: 154,922

Post » Tue Aug 19, 2014 3:29 am

I want to say thank you for that. Those examples taught me a lot about how to go about writing a C2 plugin. In the example of calling an action, is there an easier way of finding the parent instance instead of traversing the plugins array? In this example, a behavior that on create sets the width of the sprite it's attached to.
Developing Surolace, the survival role playing space game.

surolace-survival-role-playing-space-game_t116953
B
14
S
4
Posts: 303
Reputation: 1,730

Post » Tue Aug 19, 2014 4:08 am

The owner of one behavior could be got by "this.inst" directly, "this" is the behavior.
B
109
S
27
G
277
Posts: 4,481
Reputation: 154,922

Post » Tue Aug 19, 2014 5:16 am

Thank you so much. I am much more comfortable with how to navigate the different parts of c2 now.

What is the preferred method of having a global data structure? In HTML5 I'd use window as the global namespace, but am I allowed to be sure the window object will be the root when exporting?
Developing Surolace, the survival role playing space game.

surolace-survival-role-playing-space-game_t116953
B
14
S
4
Posts: 303
Reputation: 1,730

Post » Tue Aug 19, 2014 5:28 am

I am not sure, it depends on your plan.
B
109
S
27
G
277
Posts: 4,481
Reputation: 154,922

Post » Tue Aug 19, 2014 5:46 am

I just want a big sloppy object floating around in the global namespace for me to store all of my game specific variables. I'm unfamiliar with a lot of what construct does on the backend to export things and don't want to shoot myself in the foot by referencing window if there is a preferred solution. It should be noted I'm not intending on releasing what I write.
Developing Surolace, the survival role playing space game.

surolace-survival-role-playing-space-game_t116953
B
14
S
4
Posts: 303
Reputation: 1,730

Post » Tue Aug 19, 2014 11:59 am

I would strongly recommend you do not design plugins that operate on any part of the game that the user does not explicitly tell it. For example don't automatically find objects and work with them - require the user to add the object via an object parameter before your object works on it. This avoids surprising "magical" behavior that can't be turned off, conflicts with other plugins that take the same unwise approach, and allows the user to exercise control over precisely what your plugin does. I would give more specific advice if you had mentioned exactly what you're trying to achieve.

For private global data, just put some variables in the file-level closure that wraps everything. It will be global to all instances and types, and it does not pollute the global namespace or attach any junk to "window".
Scirra Founder
B
399
S
236
G
89
Posts: 24,527
Reputation: 195,386

Post » Tue Aug 19, 2014 1:23 pm

@Ashley

The dependence to other plugin could reuse current plugin/behavior , or just add some decorator to these objects. Yes, I agree the dependence will let user confuse, but it could be solved by clear document.
B
109
S
27
G
277
Posts: 4,481
Reputation: 154,922

Post » Tue Aug 19, 2014 1:38 pm

rexrainbow wrote:but it could be solved by clear document.

Assuming users read documentation :)

In the past we've even had messageboxes pop up with very clear instructions on what to do, and users still come to the forum asking why it doesn't work.
Scirra Founder
B
399
S
236
G
89
Posts: 24,527
Reputation: 195,386

Next

Return to Javascript SDK

Who is online

Users browsing this forum: No registered users and 0 guests