Polymorph — Now for sale in the Scirra Store!

https://www.scirra.com/store/construct2-behaviours/polymorph-4201

<p>Edit collision polygons during runtime - insert the shape AsJSON from an array or a data string from the included Editor capx. </p><p>This behavior can scan a sprite image to determine a collision shape using image alpha values. It also allows you to inject an AsJSON shape into the sprite to change the collision polygon during runtime. It is compatible with normal collisions in C2 but has not been tested and should not be assumed to be compatible with any of the Physics behaviors (standard Physics, Box2D+, Chipmunk).</p><p>This download also includes an editor capx, which is ideal for setting collision shapes on large and/or complicated images. The editor is more convenient than the standard image editor and you can save the shape in AsJSON format or copy it for pasting directly into a project. </p><p>The AsJSON format is compatible with a C2 array object, so you can use an array of positions and upload them into a sprite to change its collision shape during runtime. Each vertex position is as a fraction of the width or height, measured from the midpoint. The example capx demonstrates this.</p>

Use this topic to leave comments, ask questions and talk about Polymorph

v2.01 submitted for approval

Minor bug fix. Occasionally, after On Create, an image-alpha scan or AsJSON polygon input would not change the c2runtime collision shape (it always worked in Box2D+). Just tidying up.

Updated the demo; still version 1.0.

Havok, I mean generally speaking for desktop. There are some bunnymark tests kicking around that show, with limited fidelity, that if you have an action game then you're going to meet limits in Godot before you do in c2 with NWjs. Now, that hugely depends on what it is you're looking to do. A point and click role play, some sort of non-action RTS - then Godot is probably the better option for you, just in terms of modularity and the ability to use nodes and scenes (prefabs). If you're looking for bullet hell madness and collisions are not too important then c2 is totally up to it.

Godot's editor and node system is simply fantastic. The only thing stopping me from going there is its performance is not as good as c2 + webgl. However, if you're not making an action platformer then it is simply outstanding! Hard to pick a best feature; perhaps the way you can animate anything in a spriter-like animation editor, or the node system, or the 2d lighting system, or the... etc .

Colludium, thanks for your great add-ons, I bought them all.

I have a stupid question, not connected with the plugin.

I liked the Shape editor, is there any way to use it to load collision polygon into sprites without Box2D+ ?

Maybe create a new object for this ...

(This would very much help to create complex polygons - obstacles in point&click, for example. There is no convenient editor for this in c2)

Hi. This is an excellent idea - I will work on one. It will have one caveat, though - that it will not support the standard Physics plugin (and Box2D+), if that's ok? I had nightmares getting it to be compatible with my version of box2d - I can't go through that again!!

I'm thinking the following features, a bit like Box2D+:

Load collision polygon from Array.AsJSON format.

Save the collision polygon in Array.AsJSON format.

Force the collision polygon to update to the one that's been loaded if the animation frame / animation changes.

Anything else you can think of?

That may be more challenging. It depends on how simple or complex the colors in the objects you want to record are. I had imagined you wanted something like a wireframe physics debug drawing but, I realize, you could want something a lot more complicated. I would try to record over a solid unique color background, like black. Then import the gif frames into GIMP or similar and set opacity by color for the background. A little more long-winded, but it should work.

You could create the physics in c2, record it using licecap and then import the gif into the image editor in your other project.

OK. With respect, I think that will squash c3 plugin creativity. I don't mean to be facetious, but can you imagine the threads:

Hey, Ash, I'm looking to make a plugin that will turn a sprite into a particle emitter. Any top-tips on how to create objects on the fly, control them from other objects and also how does the solid collision detection and bounce work with bullets etc? I want to be able to control all aspects of my particles, and so on, and maybe have the child objects become spawner parent objects themselves if the user wishes this to happen. How should I go about it?

This would be my thread to investigate ideas for my Emitter plugin... What is the motivation to engage in the forum to investigate the potential of looking into this, mainly because I would risk asking these questions and then someone else could take up the idea and beat me to it? Assuming I was brave enough to risk airing my idea, would you have answered to expose the inner-workings of sprite animation, solid collision detection and solid push-out and bounce routines...? All required for Emitter. Or would you say: "I don't see the need - it's all ultimately possible by using events and sprites" - because you're not certain that you won't change any of the runtime functions in 10 years time? Serious question, and not meant as a troll at all.

Because if you won't expose the workings of the commonace.js to that kind of question then the offer of a QA session becomes nugatory - because we (the amateur sdk devs) know that the answer will always reduce to something like: there's nothing to see here. So we won't ask and the c3 sdk is dead in the water.

I don't wish to become a repeating poster of the same point, so this is me done in here - I believe that I have clearly argued my point. Thanks for your responses - I appreciate your candor, even if I disagree with your position.

Ashley - anything you can do to support amateur sdk devs is going to make things easier in future, for sure.

I must admit that I am a little intrigued as to what sort of copying of plugin code has taken place so that it makes you so against granting access to any plugin code now. Why did these devs who came to you with their dramas of failed plugins not just roll back their version of c2 so everything would work again - why make scirra responsible for un-f'ing a 3rd party's lack of support? Most pros, I understand, lock their design environment to avoid these inevitable catastrophes. Why should it not be the same here?

Making plugins for c2 and c3 is relatively complex, compared to Godot and Unity, for example. In Godot, having never used Python before, I made a sine plugin equivalent in a couple of hours. Except that it was more powerful :p. However, my point is that there's an order of magnitude of difference between Godot's documentation and that for the c3 sdk. And Godot is free (and, I know, supported by a lot of devs...). If you're going to restrict access to plugins then that requires the sdk documentation and the example library to be vastly improved. It's not all about me, I hope, although I feel like a bit of a lone voice here. So maybe someone else has an opinion on this as well? I am no asking for you to support only me..!

Many of the awesome plugins we have would not have been possible without such a preview of plugin code: off the top of my head, I imagine that Canvas, jcw_Trace and most of RexRainbow's plugins would not have been possible without other c2 plugins being human-readable, but I could be wrong.... I feel that this restriction will sacrifice the creative, just to avoid giving support where I think you shouldn't be giving support anyway.

And - to alternatives, I just re-read your answer - us amateur devs don't know what's available in the runtime if we can't find out about it. So, you're unlikely to get questions about alternative methods because, forgive me, often your response has been that you don't see the need for them. And many of the more creative plugins were created to fill gaps in the official plugin list. For example, raycasts were asked for many times and you never saw the need; IIRC you stated that we should just use a sprite (! - what about collision point and normals etc?), then jcw_Trace came out. But, considering Trace, if you decide to change the

collision_poly [/code:35q8qusg] variable to something else (completely in your remit, it's not in the sdk) then that would probably break the only raycast plugin we have (and all of my plugins too...).  My point being that just because you don't see value in a plugin or feature does not necessarily mean that there is no value in it to many other game devs.  

And, so, it becomes complicated.  Because I am asking for access to methods in the runtime that you may not want to grant access to.  So, I say, rather than hide these runtime contents and changes - they should be published and open (as part of the sdk manual?) so that anyone with half an hour of JavaScript could fix changes to an open source plugin or, more importantly, a dev could fix their plugin to keep up with scirra....  If the runtime was open (not open source), and that includes the plugins, then you'd probably find sdk devs swarming here.  And if you had a roadmap then sdk devs could anticipate affecting changes instead of being reactionary...

I think I've said way more than I expected - so, apologies for the diatribe... and I hope it does my point justice.

Far, far longer than I hoped...

Just wanted to make sure we were both talking about the same thing...! I understand your position and reasoning.

One of the strengths of c2 was (is!) its accessibility to amateur coders. That meant that it was easy for amateur devs to create the many plugins we now see, all to fill the gap between standard plugins and what event sheets could access within the runtime. And they were all educated into the ways of c2 by learning from the offical plugins. As soon as the new c3 runtime comes out I am afraid that will cause the list of unofficial c3 plugins in the addon repository to be tiny... But maybe that's not the market that c3 is aimed at. In either case, it's a crying shame, IMO.

Maybe I'm missing something here. Can I just check that you mean that you don't want people to replace the standard plugins with modified versions of the standard plugins? If that's the case, why not just lock access to the standard plugins in the c3 editor: make them non-replaceable (if that even could be possible using the addon manager)?