There's a great resource on motion integrators here. A lot of the jump height drift can be improved by using time-corrected Verlet or a RK4 integrator for behaviors (see first link), instead of Euler based solutions. However I would like to point out that even those doesn't solve the problem completely.

The thing is, although all these fancy integrators support different framerates they are not designed to handle dt fluctuations at every frame. Their formulas are expected to use a constant dt throughout the simulation. In practice C2 uses a variable timestep which introduce small fluctuations to dt at every frame, that in turn induces small errors that accumulate and can get big over time.

To fully solve this and ensure that the jump height is the same all the time it's necessary to use a deterministic approach, AKA using a fixed timestep for the simulation. That's the solution most engines use nowadays in combination with interpolation or extrapolation for the rendering part to handle variable framerates. There are some great resources about this in the links below. The second one has a great example of how small errors turn big when using variable timesteps.

http://gafferongames.com/game-physics/fix-your-timestep/

http://www.koonsolo.com/news/dewitters-gameloop/

Now it's probably not practical to implement this last solution in C2, but I would love to see it for C3. Besides solving the varying jump height problem it also eliminates the missed collisions due to small framerates (AKA tunneling), it removes the randomness of each play session which helps enormously in making a replay function or in games where the physics must behave exactly the same every time, it allows to set a smaller frame rate for the simulation (like 30 fps) freeing more cpu budget (specially good for mobiles), and it makes things easier for beginners since it's not mandatory to add dt in events that deal with time. It can also be backwards compatible by automatically setting the value of dt to compensate for the moving rate of objects, in case the new fixed timestep is different than 60.

Here's a demo of the algorithm I suggested: Fuzzy Match Demo

And here's the capx: Fuzzy Match capx

*To test it just type in the editboxes and it will calculate the similarity between the two strings, giving a match if it's over 80%.

I included some other heuristics that you can test to see what fits better your use case. To combine them I just used a simple average and got very decent results.

In my auto-complete demo I have also used the number of matched characters, but in this demo I only included the strings' length similarity. However if you also want to implement it you only need to do the same it's done in the pairs comparison, just feed individual letters to the arrays instead of pairs.

There's an efficient and easy to implement fuzzy match algorithm that I used in my proposal for typing events that could probably fit your needs (there's a working example in the previous link). Here's a website that describes the algorithm in detail: http://www.catalysoft.com/articles/StrikeAMatch.html

Basically you pre-process the strings you would like to compare by splitting it's letter pairs ("TEXT" => "TE,EX,XT"). You can store each pair as an entry in a 1D array or use a comma separated string. Then you iterate through each pair of the first string and find if there's a match in the second one (you can use the Find expression). If there's a match you increment a variable Intersection an remove the pair from the second list. After processing every pair you calculate the similarity of the two strings by dividing the number of matching pairs by the total number of pairs (sum from the two strings):

Similarity = 2 * Intersection / TotalNumberOfPairs

Having the similarity, you just need to set a threshold of how much the strings need to match an use a compare:

Similarity > 0.9 => do stuff

In that function "a" is replaced with whatever object type you call the function with. So if you called it like this:

Call indist (sprite, 100,100,50)

"a" would be Sprite. It's basically another way to make things more generic.

Yeah, that part I get it and would be very useful. My main doubt is how to make this viable.

From my perspective, in order to make it work the "a" would need to be a sol variable previously defined and limited to only one object type, in this case "Sprite".

Otherwise you could call "indist(sprite, 100,100,50)" or "indist(tiledBG, 100,100,50)", two different object types with different specific conditions. So when placing the condition you would need to select the condition inside a list of an object "a", of the type "sprite", that would temporarily appear into the object list (like local variables do). If not, how would you deal with different object types that have specific conditions not present in other object types? Like you could call both a sprite or a tiledBG, but they don't have the exact same condition set (like "animation is playing" for instance).

Unless all the object types have a common subset of conditions (like position, size, opacity...) and you can only use these when picking an object through a variable (like "a"), and select them through the system object.

*Actually I have some ideas for families with multiple object types that probably could help with this. When I get more time I'll post them.

How about inline vectors?

OK yeah, I know...

Well remembered. It's something that would be great if could be incorporated.

Very interesting topic.

There's some ideas that could (and in my opinion should) already be applied to the current event system. Like the possibility to define variables inside event blocks or actions, reference instances by the order of picking, and be able to name function's parameters. I already felt the need for these before and totally endorse them.

I also really like the idea of creating temporary families inside the code. This could be extremely useful to use with functions and make more modular events.

Also the possibility to save the SOL to variables is one of my dreams. Being able to pre-process a SOL, store it, and later load it again could help save some serious processing when dealing with a lot of instances and expensive filters. There's some cases where you need to repeat the exact same complex picking at a later time, plus some different conditions, that could be seriously optimized with this. Instead of checking collision, plus position, plus variables, plus n other things... for thousands of instances repeated times, you just compute it once and store it, then load it when needed. Most certainly just manipulating a list should be a lot faster than to compute everything again.

One thing that I noticed is that your proposal works easily with typed code, but do you have thought in how it would work with the event wizard?

For instance, since the actions don't seem to show an explicit object type like conditions do ("sprite: ..." or "system: ..." ), I imagine they would be a generic editbox where you type actions as expressions, am I right? That works well for setting variables, but how about other actions that depends on dropdowns with options and the like? Or things that are very specific to an object type?

Also here the "a" is only referenced inside the function but appear as an object type in the condition below. To place the second condition, would it show on the objects list like local variables do, or the idea is to have a generic editbox for the object type as well?

+-------------------------------------+
| on function "indist" (a, x,y,dist)  | returnSol a
| a: filter distance(a.x,a.y,x,y)<dist|
+-------------------------------------+[/code:2711oo0f]