Colludium's Forum Posts

  • Hi rraffo. I doubt the plugin will be possible under the new sdk, although I haven't checked (and have no desire to tbh). Your best bet is to lobby scirra to make an official version that will always be supported. I am having more fun with Godot Engine, as it's free and open source. I have no intention of returning to c3 - Godot is just so much more accessible.

  • The easiest and most reliable option would be to allow users to set the bodyDef:gravityScale value, the bindings for which should be readily available in the wasm Box2D distro that C3 uses.

    Applying a force per tick would just try to undo what the B2World would have just calculated for an object's velocity change; it would do it imprecisely, and with odd looking results. You certainly couldn't mimic zero gravity using that method.

  • How long are you applying the force for (in seconds)? Or is this a one-tick force and not a force applied over time? I think you're probably applying force over time, but I can't be certain from your question.

    Box2D compensates for framerate by modifying the each-tick result of an applied force depending on delta time. The idea being that, when a force is applied over a period of time then the change in velocity will always be the same no matter what the frame rate. This is a way to measure impulse, which is why applying an impulse to an object is framerate independent so that the velocity change is always the same.

    Whether you are applying the force in one tick or over a period of time, this means that:

    If you are applying a force over time, do not change the magnitude of the force.

    If you are applying the force in one tick to cause a desired change in velocity, do not use a force - apply an impulse instead.

  • Update v1.0.1.0

    • Code tidying.
    • A complete re-work of the body and joint destruction system to ensure better reliability.
    • Added protections so that you can destroy objects or joints out of order ie before destroying any associated gear joints.
    • Increased default memory allocation for better performance (check out the stress test!).
    • Rebuilt using Emscripten and the best webassembly optimisation options.
    • Fixed a couple of Box2d / Liquidfun core project bugs. Unbelievable, but I found a couple that were previously driving me mad (joints not being fully destroyed and a memory leak!).

    This should be the final update other than for maintenance. Please let me know if you encounter any bugs or (better still) wish to share what you've made using this plugin.

  • Update - bugfix - v1.0.0.25

    Fixed a crash when destroying bodies with joints.

    Tombas - hopefully this will have fixed it for you - please let me know if you find any more problems.

  • Tombas - I can reproduce the bug. Rolls sleeves up... :)

  • Hi Tombas - I don't get the error message when I run the layout... :/

    Is there anything I need to do to make it happen?

  • Update - v1.0.0.24

    Bugfix to correct errors when handling the destruction of assimilated objects.

    Please let me know if this works for you Shadownox Tombas - hopefully this is all fixed now. Thanks for your patience everyone!

  • Ashley - I totally understand and appreciate your telepathic debugging guestimate as to the possible cause. I meant no implication that this was a bug in C3, I merely hoped to identify what changes might have elicited this plugin bug.

    To everyone else - I am still working this and will keep you updated. Thanks for your patience.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hi Ashley - I know that support for 3rd-party plugins can be a bind. If you could shed light on this (2 posts above) then that would be amazing. Thanks in advance.

  • Nepeo - I wonder if I may ask for your help, if you're able?

    I did some regression testing and it appears that r237 and later versions of C3 break the LFJS plugin. Specifically, there is a crash when the layout restarts, but this only happens after there have been object collisions. The collision triggers operate in a similar way to the Physics plugin, but the callback and collision filtering system is different (I am not sure if this is relevant necessarily, but the fact that the crash only happens after a collision makes me suspect that the problem is here somewhere). Here are some details from the console:

    Uncaught (in promise) TypeError: Cannot read property 'GetFamilies' of null at EventSheet._Trigger (eventSheet.js:11) at EventSheetManager._Trigger (eventSheetManager.js:13) at EventSheetManager._RunQueuedTriggers (eventSheetManager.js:18) at Layout._StartRunning (layout.js:16) at async C3Runtime._DoChangeLayout (runtime.js:78) at async C3Runtime._MaybeChangeLayout (runtime.js:75) at async C3Runtime.Tick (runtime.js:68)

    This relates to this function: 

    _Trigger(method, inst, behaviorType) {
 if (inst) {
 const objectClass = inst.GetObjectClass();
 let ret = false;
 let r = this._TriggerForClass(method, inst, objectClass, behaviorType);
 ret = ret || r;
 for (const family of objectClass.GetFamilies()) {
 r = this._TriggerForClass(method, inst, family, behaviorType);
 ret = ret || r
 }
 } else
 return this._TriggerForClass(method, inst, null, null)
}

    I couldn't find anything in the plugin SDK examples that stood out as different and that maybe I should now be doing... I wondered what might have changed so that I can work around it? Thanks.

  • Tombas , Shadownox - thank you both for your bug examples.

    Edit - still working the problem. More than one bug!

  • Tombas - thanks!

  • Thank you both - I'll take a look and see what's going on!

    Edit: Tombas - I couldn't find your example unfortunately - the link appeared broken.

  • Tombas - unfortunately I have been unable to recreate that bug. Are you able to send me a project file that reproduces it please? You could like here or hit me on discord and I'll take a look. Thanks!