I found a link to some images and simple explanation for those interested:

openarena.ws/board/index.php

As for the Velocity Verlet Integration, I can seemingly only find info on the version that infers velocity from current position and last position. I didn't know there was another, can you point me to it?

I think I know of Explicit Euler (and semi-version), Midpoint, vk4, The german named one lol... something like rungakatta?, and Verlet (velocity infered by position)

This is documented actually

https://www.construct.net/en/make-games/manuals/construct-3/scripting/scripting-reference/object-interfaces/iworldinstance#internalH1Link3

But iirc it isn't available in the SDK.

Gosh dang it, the addon sdk is different than the javascript blocks and assets???!!! So now you have two connections to the c3 runtime that differ?

Hence the direct access to the collision engine which as far as I can tell, is undocumented. It's also bad because I think it actually skips most optimizations like collision cells, it's just a raw call of "Is instance X overlapping instance Y"

What makes you think that? all the built in behaviors that call it would suffer but they seem performant enough, regardless of how many solids exist. I mean, I can set up some tests, but it would be absurd to me to have a call that bypassed the optimizations. atoh, If you are specifically testing 1 instance vs another then optimizations aren't going to matter a whole lot anyway (1st check being an aabb, I would think, which is super fast.) I haven't actually looked through this area of the engine since c2 so, this is as all hypothetical conjecture.

Looks like that method is called leapfrog integration. It averages out changes to acceleration from frame to frame.

Most behaviors use velocity verlet integration. Which handles constant acceleration motion perfectly no matter the timestep.

verlet is appropriate for springs and the like, correct?

I remember learning about the one I mentioned in order to correct maximum jump height in games running at different frame rates. I had the issue with my platformer behaviors having drastically different maximum jump heights at 30fps and 60fps

I'm really confused.

I read through the manual for addon sdk several times. I also searched for it as well...

Every included behavior that moves instances around and deals with collisions involves getting a reference to the CollisionEngine and using it for things like .TestOverlapSolid. I notice the example with the GhostShooter tutorial uses .testoverlap but that also isn't mentioned in the sdk as far as i can find (when I search for it)

runtime.GetCollisionEngine isn't included in the sdk, but .runtime is. Are we allowed to use it? Why or why not.

Is this not a part of the official sdk, and if not, how are we "supposed" to go about testing for collisions?

I want to agree if it's going to grant us power, but just need to understand better.

I think Iʻll give it a shot, Overboy can clear up anything I get wrong.

Imagine you are creating a game. In said game you have a spaceship. The space ship is really just a frame with many components. Engines, shields, thrusters, weapons, hull parts and so on. Each component on the ship doesnʻt need to know about other components implementations. The shield doesnʻt care what type of engine exists, so long as the power output is sufficient. The issue with the using functions, is that component specific code now needs to be placed under the ownership of other components which is BAD for maintainability and scaleability.

Lets say your dynamic spaceship is all set up and built by the player. Then lets say during a mission, an enemy fires a vampire hull mine that is triggered by arcane engine output excess. Where do you put that code?

The easiest and best answer is that it should go in the eventsheet/script for the vampire hull mine, not the arcane engine script. When the custom action to activate the engine triggers, there should only be code related to what the engine does. It doesnʻt care it there is a mine on the hull or not. you shouldnʻt have to write "if vampirehullmine is attached, then call vampirehullmine.activate". Instead, that should be in the vampire mineʻs script : "On specific engine type on a specific craft activates...".

What if you have a shield that autoactivates on the ship hull taking damage? Imagine all the code tangle that will become impossible to manage once you have 10 different types of energy storage systems, dozens of weapon types, dozens of engine types, modules that add unique and specific abilities, components that dynamically react to specific situations or the pressence of other components, and so forth. A single ship could easily have dozens of parts. Just like a character in a rougue action game could have dozens of dynamic abilities, plus equipment, plus weapons.

The issue seems not so bad when you make a single spaceship object in an arcade shooter and just hardcode everything. But the moment you try to make complex interacting systems, you need architecture/organization to handle it. In my experience, you have to add alot of custom boiler plate code to handle message passing in construct. I use callbacks, but that means every object has to maintain a list of listeners and iterate through it in order to callback to them when some event takes place. That equates to alot of foreach/pickbyUID/callback function.

AND I didnʻt even get into passing parameters! Which is an absolute must. Many times, you want to pass several, or a whole object... ("UID to ANYTHING" ) probably the best 3rd part asset ever.

You can color/effect certain portions of the sprites in the following ways:

1. (expert), create an effect shader yourself that either uses a mask to target the effect (could be its own texture), or a use colorLUT based on index and generate the mask from there. Afaik, this method wonʻt be very scaleable, as it combines multiple shaders in one and isnʻt ideal on the programming side.

However, it will result in the easiest editor side work. I donʻt think you can reference other shaders in a shader in construct, that would be ideal if you could. You need to obviously know your way around shaders to go this route.

2. Create your base sprite (as you have) then Create an additional sprite out of the areas you want to specifically effect with the shader and apply the effect to those that object. It should have the same number of frames, etc, as the parent sprite. You can then either pin, or manually move the effect sprite to always match position with the parent. Or you can use object Hierarchies, whichever is easier for your project. You can split up an object like this into many different parts with many different effects.

I think this thread has deviated a bit from its original intent. But the whole discussion of these "real trigger function signals" are still kinda relevant

Oh, I'm happily sipping tea over here. Might even grab some popcorn. In all seriousness, I agree with much of what Overboy is advocating for. Though, personally, I have never created a project that relies on broadcasting signals. I like callback methods to drive communication, but that is more tightly coupled for sure/

Ashley , thanks. I realized now after creating another project that it had to do with the way I was pinning the covering sprite (at the center), the speed of the height change (in absolute pixels over time) and the display resolution. By changing height over time (slowly over,say 5 seconds) with a center image point, the object ends up "clicking 2 pixels at a time" in height change. Basically, since the object is shrinking from both top and bottom, the way the math works you get both the top of the sprite and bottom rounding at the same time, creating a "click". If the sprite displayed is absolutely only 8 pixels on screen, and the screen is low res enough to see the pixels (1080p 15"), you can def see the height change occur in 4 "distinct" steps - which makes sense after doing the math.

In short, setup issue, combined with a particular display.

Thanks for the project file!

Would somebody be able to confirm an easy bug for me?

You need to be using the editor in Firefox.

Simply create a new project, create a sprite, and then open the sprite editor.

Put the mouse cursor on the image and Click and hold with the middle mouse button to pan the image. While holding the middle mouse button down move the cursor to the browser tabs/urls UI at the top of the screen. What happens?

When I am panning around a sprite and overshoot and my cursor ends up in the firefox menu/tab area. Construct crashes.

This does not happen in Chrome for me.

Aloha all,

I was curious if anyone else noticed this. When uses the mouse wheel to zoom in and out while in the sprite editor, firefox zooms in more better :D. While chrome requires expnentially more finger work to continue to zoom in. If that makes any sense.

Basically, with one or two clicks you will be zoomed in on Firefox, but with chrome, the further you zoom in, the more clicks it takes to keep zooming in. This is very relevant while working with pixel art.

Perhaps there is a setting I changed in the editor in one browser but not the other? Not sure if construct has a setting for zoom speed/scale/distance.