Ashley's Forum Posts

  • Hi SDK developers,

    We're repeatedly running in to some difficult compatibility problems due to third party plugins and behaviors that are basically a copy of an official plugin or behavior plus a minor change. The benefit of the minor change is negated by compatibility problems in the long run. So on the whole this approach to plugin development appears to be harmful.

    Plugins which take this approach usually have a lifespan like this:

    1. Developer releases extension of OfficialPlugin, for example OfficialPluginX, with a minor change.

    2. Over time, OfficialPlugin gets bug fixes and eventually gains the features of OfficialPluginX as well.

    3. OfficialPluginX is not maintained and does not get any bugs fixed.

    4. Users keep using OfficialPluginX, and running in to bugs that are already fixed in OfficialPlugin. We end up supporting these users.

    5. It is difficult to replace OfficialPluginX with OfficialPlugin in events, because every event has to be changed manually. It is also difficult to add a feature in Construct 2 which can do this automatically, because the plugins are regarded as completely different and therefore incompatible by default.

    The minor benefit added by OfficialPluginX ends up being harmful to users in the long run, causing them to experience more bugs, and making it difficult for them to switch back to OfficialPlugin.

    On the other hand, I understand the benefit of third party plugins allowing users to use features before they make it in as an official feature. However, I would recommend the following approach for third party plugins and behaviors based on official ones:

    1. If the change is very small, please just suggest it as an official feature. It can probably be added quickly in to the next beta release. This removes the need for a third party plugin at all.

    2. If at all technically possible, design a standalone plugin which is not based on a copy of an official plugin, and just affects a different object. For example, if you wanted to add a 'Load random image from Flickr' action to Sprite, follow this process:

    • Make a new plugin from the empty template.
    • Add a single action, 'Load random image from Flickr in to Sprite'.
    • Use an object parameter so the user can select the sprite to affect.
    • In your code, check the properties exist as expected, so it is not broken if the user chooses a non-Sprite object.
    • Affect the chosen Sprite object from your plugin.

    Since this approach does not duplicate the entire plugin it is easier to maintain, and easier for the user to swap for the official action if it comes. However it will still require some maintenance in case the properties of Sprite change between releases.

    3. If the change is really big enough to deserve its own third party plugin, please change the plugin ID and release it as a separate plugin. Changing an official plugin which is maintained by different developers causes compatibility problems, but if you change the plugin ID the editor will treat it as an entirely separate plugin. This means both plugins can be updated independently without breaking each other. Please also bear in mind:

    • Please be diligent about following the changelogs of every C2 release carefully, and update your plugin whenever the official plugin is changed, in particular to adopt any bug fixes. You may need to use diff tools to track every change that is made, e.g. windiff.
    • If the official plugin ever gains the features of your third party plugin, I would request that you voluntarily de-list your own plugin and add a recommendation that all users should switch over to the official one, to minimise ongoing compatibility problems. This is possible if your plugin has a different plugin ID; it is extremely difficult for users to update if you have modified the official plugin directly.

    Please be aware that modifying an official plugin, behavior or effect is actually hostile to end-users and will likely cause them difficult compatibility problems or leave them with unfixed bugs. Never modify official code; at the very worst, publish a separate plugin as described above.

  • rexrainbow - what is the status of the TouchMouse plugin? I would recommend it is de-listed - it's superseded by the official Touch plugin and has some bug fixes the TouchMouse plugin does not, and some users seem to keep running in to TouchMouse bugs that don't exist in the official Touch plugin.

  • Don't use the TouchMouse plugin - AFAIK it's redundant, superseded by new features in the official Touch plugin, and is missing some important bug fixes in the official Touch plugin.

    I've reported the text bug to Ludei myself. I'm not sure about the other issues - you should probably report them to Ludei yourself, because there is not much we can do about it ourselves.

  • We don't add a limiter ourself in Construct 2, I think the browser adds one. Can you provide a .capx which plays sounds demonstrating a limiting problem?

    You might have to normalise your sounds to -3 to -6dB to avoid this problem.

  • Yep, this should be possible. Have you looked through Construct 2's Examples folder? There are lots of physics demos in there, including ragdoll.

  • — - did you have a look at the tutorials section? Your question is covered by the Physics Basics tutorial:

    b]Making the scenery

    You don't want your game's floor to fall away off the bottom of the screen with gravity too! ... Most of the time in our games we want to simulate the scenery being rock solid: not falling away with gravity, and not being pushed a little bit back by things hitting it. Set the physics object's Immovable property to Yes to simulate this.

  • You're right that this doesn't really make sense... so I've changed it for the next build, so that it won't set the angle of motion on the first tick, only if 'set angle' is 'no'.

    It's not just Space Blaster (which I have had to change to keep working the same) - it's just from experience any time we have to change existing features in any way we get a lot of support requests and new bug reports from confused people who either haven't read the release notes, or haven't understood them. They quite rightly also get annoyed that their project seems to have been broken by an update. So we really try to avoid changing existing features or keep them backwards compatible unless there's a strong case for a change. Hopefully this one will go smoothly...

  • cow_trix - I do think this is a bug so I've changed it in the next build to not duplicate invisible instances.

    You can remove invisible instances by hacking the project XML. The invisible instances are in the layout's XML file under a tag called 'nonworld-instances'.

  • Think I got this fixed for next build... let me know when r99 is out if it works for you.

  • You do not have permission to view this post

  • What do you mean by "terrible"? Can you illustrate what you mean with screenshots?

    If you draw an image at 64x64 and scale it up, there is no more detail to show, so you'll see linear or point filtering in between pixels. Because of this, often it's a good idea to draw your artwork at a higher resolution than necessary - e.g. draw a 128x128 image, then size it 64x64 in Construct 2. Then when the screen scales up, instead of just blurring or pixellating it, it will gradually show more detail, which is quite a nice effect.

  • We're working with appMobi to improve directCanvas integration. I would not expect anything to work in Test Local or Test Anywhere until appMobi next update AppLab. However in the mean time you should be able to build a complete app and that may work a little better.

  • shigalov2011 - you can't make OS-level windows in HTML5. You can try to pop up a new web browser window, but then you're at the mercy of the browser's popup blocker. So this is generally not done.

  • Woah, they're on 2.5m now. Yesterday when it was around 1.3m I was refreshing the page every few seconds and it would jump up $100-500 every time. Madness.

  • You do not have permission to view this post