Colludium's Forum Posts

    Ashley - That's great. I'm glad it helped and I hope this resolves the issue for everyone. 👍

    I have created a project example that repeatedly demonstrates this crash.

    Here's what it looks like. If you've lost work to this then you might want to look away... ;)

    Click to play if it doesn't do so automatically:

    Here's the project caproj:

    Crash test .caproj project

    Steps to reproduce:

    1) Open the project. Be patient, it can take a minute...

    2) Edit any sprite using the "Animations: Edit" in the properties bar (note, the open layout has no sprites in it, so memory use for this project is at a minimum).

    3) Close the sprite editor. If you're prepared to wait a minute then it might recover, but if you click on anything / try to close it again / click anywhere else then it'll drag up the windows crash popup.

    Things to note. C2 is using approx 152 Mb of memory with this layout open in the editor. After the crash and selection of "wait for the program to respond" then the reported memory use goes down to 20 Mb. Although C2 appears to have recovered, clearly it is not working properly...

    What's with the cycling through 150 sprites or so after initially closing the sprite editor...?

    Anyway, Ashley, I hope that this is what you need and it'll repeatably crash on your super-computer.

  • Update: v1.0.0.16

    Added new feature: Enable/Disable Particle System Strict Contact Checking.

    Strict contact checking is an option that ensures correct particle behavior when their fixture contacts are ambiguous. With this enabled the engine is more careful to make sure particle behavior is what you would expect, but at the expense of a CPU factor n*log(n): so only use this if necessary. Adding this feature removes one of the known bugs that was previously listed in the first post.

    There is a new demo added: Particle System - Strict Contact Check.c3p. This demonstrates the 'bug' and how enabling this prevents incorrect particle-fixture collision.

  • SIMPLE Games

    You can obtain the particle velocity using its UID and the ParticleVelocityX & ParticleVelocityY expressions.

    For performance reasons the plugin doesn't obtain the particle velocity buffer unless one of these expressions is called. Then the velocity buffer is obtained for all particles for that tick. That data then remains stored in the plugin for that tick, in case you make any other calls to obtain the velocity values of other particles. That way the velocity buffer is only accessed once per tick - to minimise the overhead of talking to the webassembly module.

  • Update to v1.0.0.15

    Code tidying to improve the begin-contact and end-contact data tracking.

    Bugfix - one of the conditions wasn't working.

  • Mikal - loving that effect!

  • Hi Tombas - glad to hear it's going well.

    To answer your questions:

    1) I may add a velocity clamp in future. Before then, you can obtain the VelocityX and VelocityY of the body you wish to speed clamp from the expressions.

    Then get the angle of travel, using VelAngle = angle(0, 0, VelocityY, VelocityX).

    Then get the absolute velocity using VelocityAbs = distance(0, 0, VelocityX, VelocityY).

    Let's say your clamped max velocity is MaxVelocity, then the final velocity will be VelocityFinal = clamp(VelocityAbs, 0, MaxVelocity).

    To apply this to the body then use action Velocity at angle to set the velocity to VelocityFinal at angle VelAngle.

    I may add this in future but I'm working on something else in the plugin at the moment. Hope this makes sense?

    2) You have all the correct settings there. Other tips would be standard for C2/C3 - minimise jank by avoiding creating/destroying large numbers of objects at any one time, etc.

    Thanks.

  • Update to v1.0.0.12

    Bugfix

    Spelling mistake in en-US.json file.

    Destroying a sensor after a Wait delay, when it was overlapping a body, caused a crash.

    OnBeginContact and OnEndContact were called for each fixture. Now fixed so that OnBeginContact is only called once until both bodies have separated and OnEndContact is only called once after both bodies have completely separated. This only really was a problem when a sensor object was overlapped by a body that had multiple fixtures.

  • Update: v 1.0.0.11

    Bugfix. Error when calling body property action (density, restitution, friction).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Try setting a velocity X rather than applying a force X to make the sideways jump. Forces have different results depending on the frame time (the engine assumes that the force is applied for the duration of the frame).

  • winkr7 - yes - all particle system settings are 0 to 100 apart from density and damping (which are 0 to 1 to remain consistent with the rigid bodies).

    Cheers.

  • Thanks winkr7 - the viscous is indeed clamped. However, the value was too much when the viscous behaviour flag was set at the same time as the elastic flag (weirdly, when elastic was enabled when it was already enabled). I have reduced the maximum value to account for this - it appears to be a Liquidfun limitation. The editor input range is still 0 to 100.

    Update: v1.0.0.10

    Bugfix - Out of range error when elastic behaviour set with the viscous behaviour flag.

    Note: Most of the system settings are input in the range 0 - 100. Inside the plugin the input value is factored for the range of values that haven't produced bugs in my testing. Some of these ratios mean that the max values in my post above can be exceeded. My reasoning is that higher values can cause even better effects (like the viscous max value in the Liqudfun b2ParticleSystemDef is 0.25 whereas in LFJS it can be 1.0 - because 0.25 isn't as striking). This means that there may be other quirks or bugs where combined behaviours might cause problems. I hope that the likely options have now been covered - but with over 32000 combinations I am not able to test them all to be sure.

  • Update: v1.0.0.9

    Fixed some spelling and description errors. Mostly incorrect references to buffer index which should have been particle UID.

  • I think this is what you're after:

    Scripting in Construct 3

  • winkr7 - I've frigged most of the particle system parameters so that they are input in the range 0 to 100 (the max values can be rather arbitrary), so the max values from the b2ParticleSystem.h b2ParticleSystemDef struct equate to an action input of 100. Actually, it's a little more complicated. Some of the value ranges can be bigger and I've broadened the range slightly where I thought it ok. Like you, I saw that changing some of the values didn't make a big difference (I was in 2 minds as to include them or not). Particle system damping is indeed clamped between 0 and 1. Values greater than 1.2 caused chaos in my tests. Part of the particle system def struct is copied below to show you what I mean by the values being somewhat arbitrary: 

    b2ParticleSystemDef()
{
	strictContactCheck = false;
	density = 1.0f;
	gravityScale = 1.0f;
	radius = 1.0f;
	maxCount = 0;
	
	// Initialize physical coefficients to the maximum values that
	// maintain numerical stability.
	pressureStrength = 0.05f;
	dampingStrength = 1.0f;
	elasticStrength = 0.25f;
	springStrength = 0.25f;
	viscousStrength = 0.25f;
	surfaceTensionPressureStrength = 0.2f;
	surfaceTensionNormalStrength = 0.2f;
	repulsiveStrength = 1.0f;
	powderStrength = 0.5f;
	ejectionStrength = 0.5f;
	staticPressureStrength = 0.2f;
	staticPressureRelaxation = 0.2f;
	staticPressureIterations = 8;
	colorMixingStrength = 1.0f / 128.0f; 
	destroyByAge = true;
	lifetimeGranularity = 1.0f / 60.0f;
}

    The lifetimeGranularity is not accessible and is set inside the plugin depending on the framerate (fixed = 1/30 or 1/60; variable = 1/60 is assumed). For particle systems it is recommended to use fixed framerate because of a known bug where particles gain energy with variable dt values.

    newt - good question. If you use a variable framerate then the world steps are all smooth at lower timescale values (but very small values of dt can cause this bug: link). If you use a fixed framerate then the world step value remains as 1/30 or 1/60, so at lower timescale values there is a longer delay before each world step (the size equating to dt at 1/30 or 1/60). I guess that if there was a slo-mo phase then it would be best to set variable framerate for the duration, then go back to fixed.