Liquidfun JavaScript - LFJS - [behavior]

...and here are the Expressions:

Now to start the conditions... ugh... ;)

Looking good! Nice work.

I just remembered something... will this be possible with your plugin? I do hope so :)

construct.net/en/forum/construct-3/general-discussion-7/case-collision-filtering-again-140632

Thanks Mikal,

Thanks WackyToaster - and to answer your question: if I understand that other thread correctly, you're asking about collision filtering for non-physics objects? For LFJS, I'm trying to make an-almost-complete port of Box2D with Liquidfun - at least as complete as it can be when accessed through C3 (and later for C2). So the collision filtering in LFJS will have no effect on anything that is not inside LFJS. So maybe 'no'.

However, if you're interested in a Physics alternative with bespoke collision filtering then: yes, LFJS will have full Box2D collision filtering via Collision Mask, Collision Filter and Collision Index. It will also include a Pre-Solve trigger where you will be able to enable/disable a particular collision that the filters don't cover (If you're that way inclined!). Does that answer your question?

you're asking about collision filtering for non-physics objects?

No, I think you misunderstood that.

However, if you're interested in a Physics alternative with bespoke collision filtering then: yes

That´s what I´m looking for. Awesome!

Blast it! the plugin is (was) almost complete, but I made a mistake. Obtaining joint pointers is not compatible with game save because all recreated joints have different pointer numbers compared to before the save event (so all event references to them won't work). I should have realized this before. Time for some editing to add a joint tag system, and hopefully nothing will break...

Then there are only a couple of actions to add and we're ready to roll out the beta!

This is causing me to hesitate releasing the plugin. Depending on what you want out of the plugin, this could be a show-stopper...!

You can always release it as a beta if you are unsure, as soon as more people use it it´s likely that they will find a bunch of bugs you never found anyway. Every software has some quirks or bugs here and there and often there are ways to live with them or work around.

I agree with WackyToaster. I am sure that you will find more bugs in the future. You can just release a beta version. There are a lot of stuff from this plugin that could be used in many projects. It doesn't need to be completely perfect at the beginning anyway...

Thanks WackyToaster and Karentzos, I appreciate the support.

I'm going include a simple function so that convex polygons with up to 8 vertices will definitely not get broken down, so you can design shapes that won't get decomposed and elicit this bug.

I'm comparing two separator algorithms at the moment. One based on Earcut triangle decomposition and the other based on Poly-Decomp by Schteppe, both from GitHub. The each have their strengths.

Then I've got some more examples to make, to demonstrate how to use the plugin. And then I'm running out of excuses to not release it...!

Very impressive

Colludium Ear cutting works pretty well, and it's easy to understand compared to most other methods. The downside being that it doesn't support polygons with holes or self intersection (Non-monotone polygons). I think most algorithms that deal with holes attempt to resolve it into multiple monotone polygons first. Of course if you can guarantee that the polygon is convex then simple fan triangulation is the way to go, as it's simple and fast.

In terms of release I'd echo what others are saying. It's better not to hold off because of one bug. Your users might discover another edge case you haven't thought to try when you do release, making the delay pointless. Just make sure to clearly note any known issues in the release.