Colludium's Forum Posts

  • repkino - this might be possible - thank you for your idea! I'll take a look at it this weekend and see if I can make it work....

  • v2.06 submitted to the store for approval.

    Bugfix: Minify export was broken and is now fixed (closure compiler didn't like the use of a cr.ObjectSet forEach method).

  • just to add to this list:

    Don't use cr.ObjectSet.s.forEach(foo) because the c2 closure compiler is not compatible...

  • Colludium I hope they do it asap. btw Platform2 is really great behaviour, thanks

    p.s. are you planning to add some more features to the behaviour?

    Thanks! What sort of extra features would you like - I'm open to suggestions and will include them if the coding won't kill me .

  • Drago_18 - thanks for the interest! I can only provide support to the new c3 runtime if the sdk is completed and explains the runtime access methods that the Platform2 behavior uses (for collision filtering etc). As it stands all standard plugins are obfuscated so there is no way for me to figure this out (the SDK template says to look at standard plugin examples... ), and I don't have the time to try to guess how they work. No SDK explanation = no port to c3. I've explained my position to scirra and have been told that the SDK documentation will be completed soon. Until that happens then I can't do anything.

  • v2.05 submitted for approval in the store. Thanks RattyRat for the spot on this one.

    Bugfix: added missing reference angle to prismatic joints. Now the two bodies maintain their relative angles when the joint is formed.

  • matriax - thanks - and yes, I am working on adding an optional penumbra effect (from light width). Hopefully I'll have some progress to report soon.

    — Fawk - thanks and I hope so. I have not yet experimented with this in c3 but I have my fingers crossed that the runtime obfuscation isn't going to stop me...

  • I created a bunnymark behavior just to compare the performance of plugins to event sheets - and the plugin was 3x as as fast as using events. So... There is an overhead to the event system. The trade-off, of course, is event sheet convenience - if no one notices the overhead then it doesn't matter....

    Edit - this plugin was for c2 although it's likely the same for c3; I didn't check the forum title..!

  • Does the minifier work if you export for html5? And are you using any 3rd party plugins...? They may not support minify....

  • RattyRat,

    I'm not sure if that's a bug with the library or with the implementation in my behavior; I should have a better idea by the end of the weekend. I'll see if I can make the joint recreation algorithm more robust - in the meantime, as you suggest, the best course of action is to avoid animations on physics objects because the bodies and, therefore, the joints all need to be destroyed and then recreated each time an animation frame changes.

  • Dammit, it's hard to post replies at the moment...!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hello,

    Afraid I have spotted another one - here is the link : https://1drv.ms/u/s!Aup_NDH7UAIvgrZAt6XHUt-KeMcHqA

    Pressing LMB spawns a new object based on the position and angle of the previous one. Every few sprites you should get one that seems to be fixed in position (although the debug panel shows considerable downward velocity).

    This does not occur if A) the angle is always zero or B) the object has Box2D+ disabled initially.

    So.... Lots of things to keep you busy.

    RR.

    Hi. Thanks for this bug report - it's a good one, but not really a bug and more of a limitation...

    It is a limitation of the Box2D library I used and I am not sure that it will be a simple problem to work-around within the plugin - it's something you'll have to be aware of when using it in c2. The problem occurs when you set the object angle after the body is created and before the box2d+ library has had a chance to run the box2d world. Thus the object's body hasn't interacted with the world when you change its angle, and that causes the problem - and that is why it works ok if the behavior is disabled before the angle is set.

    To avoid this issue, if you're going to create objects and change their angles upon spawn, it's best to set the behavior disabled and only enable it after the object has been rotated.

  • Hello again.

    Thanks for the capx - it has helped me pin point a bug (or unexpected behavior) - here is a capx to demonstrate (based on your Assimilate demo):https://1drv.ms/u/s!Aup_NDH7UAIvgrY-Uhp8nrL-Ac5ruw.

    To see the problem simply press the "-" key while the objects are assimilated, it breaks the object completely and it is them impossible to re-assimilate the sprites.

    The work around is to make sure the sprite is un-assimilated before destroying it, so I suspect your behavior needs an explicit un-assimilate before a destroy sprite, assuming that is possible?

    Cheers,

    RR

    Hi. Thanks for the bug report. This is caused because one of the assimilated bodies is destroyed whilst it is assimilated, causing the behavior to contain references to objects that no longer exist. I can modify the plugin to prevent this from happening.

  • OK, I have a plugin design philosophical question for anyone interested:

    I propose to make the following group options for shadow-casting:

    1. Solids, Fall-through and Jump-through behavior objects.

    2. Flashlight Shadow behaviour, to come with this plugin.

    3. Object types that are added by events.

    You can select any option and those object groups will cast shadows. However, options 1 and 2 will be supplemented by 3 - any added objects will also cast shadows. Also, objects can be added to an ignore list (for ignore object type rather than object instance) so that if you have a family of solids then you can select some to be ignored, for example.

  • Take into consideration the C3 runtime ^^

    As soon as I've stamped out a memory leak (or, rather, confirmed that it's now actually fixed) and I've done some stress and bug testing then I'll give it a go in c3. Regarding the new runtime, it's all guesswork until the SDK is published... But yes, a c3 release is also in my TODO list.