Colludium's Recent Forum Activity

  • 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!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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 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.

Colludium's avatar

Colludium

Member since 26 Aug, 2013

Twitter
Colludium has 11 followers

Connect with Colludium

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • x3
    Coach One of your tutorials has over 1,000 readers
  • Educator One of your tutorials has over 10,000 readers
  • RTFM Read the fabulous manual
  • Email Verified

Progress

18/44
How to earn trophies