Worked for 14m 48s
You're right to call that out. I’ll treat the newly uploaded project.json(1).2 as the source of truth, re-check the actual block wiring from that file, and run a small numerical reproduction of the relevant update loop if the project logic can be isolated. I’ll separate what the code proves from what the simulation test suggests, and give you a specific fix rather than guessing.

Parsed input structures

Validated integration steps

Corrected simulation timestep scaling and timing

Inspected saved states

Inspected Scratch project files, blocks, procedures, variables, lists, and orbit calculations

The updated engine uses a velocity-Verlet-style step: position advances by
v
 
d
t
+
1
2
a
old
d
t
2
vdt+
2
1
​
a
old
​
dt
2
, then velocity advances using the average of old and newly computed acceleration. That part is internally consistent. I’ve also confirmed the more suspicious mismatch: for timespeed above 1, _dt is scaled by 0.5 + Timespeed/30, while the engine separately increases the number of substeps to about Timespeed + 16. I’m testing whether those two scalings make the physics advance much faster than the simulation clock.

Reconstructed initial conditions

Estimated orbital stability and derived the corrected timestep

Validated the instability

Compared timestep behavior

Identified and diagnosed timestep scaling

Diagnosed timestep growth, scaling, and instability

Investigated N-body initialization, integration stability, and timestep update issues

I found an important difference in the updated file: my previous answer described the wrong version of your code. In the new project.json(1).2, the Apply and Update to … STAGE … procedure uses _dt in its position and velocity calculations; it does not use the Timespeed / 10 factors I cited before. Please disregard that diagnosis.

I’m re-reading the updated blocks and their execution order now. The key is to check not just the formulas in isolation, but when each acceleration list is cleared, copied, and recalculated during every substep.

What the updated code and Python test show
The main problem is the actual timestep _dt used on every substep, not the TurboWarp limit. In the uploaded file, the substep limit is 5000, but at timespeed 100 the engine uses only 116 substeps, so the limit is not being reached.

Here is the sequence in the current code:

It calculates _dt as elapsed real time × Timespeed.

When Timespeed > 1, it overwrites that value with elapsed real time × (0.5 + Timespeed / 30).

The ENGINE procedure then applies that same _dt repeatedly for every substep.

So both the timestep and the number of substeps increase with timespeed. Those two multipliers compound.

Measured setting

_dt per substep

Substeps

Total physics timestep per frame

Timespeed 10

0.0275

27 (your measurement)

0.7425

Timespeed 100

0.128

116

14.848

Using your measured values, the physics advances about 20 times as much per frame at timespeed 100 as at timespeed 10, even though you observe the displayed simulation date advancing only about 10 times faster. Also, the timestep for each individual step grows from 0.0275 to 0.128, which makes the orbital calculation less accurate.

A small discrepancy I noticed while checking the new file: its substep formula evaluates to 26 at exactly timespeed 10, rather than 27; it gives 116 at timespeed 100. That doesn't change the diagnosis.

I tested the physics in Python
I extracted the updated project's initial conditions for all 28 objects, its gravitational constant, and the position/velocity update formulas. I then reproduced the gravity and integration loop in Python. This is a numerical reproduction of the project's physics—not a launch of the entire TurboWarp runtime.

With _dt = 0.128, Io moved beyond five times its starting distance from Jupiter after about 156 simulation-time units, and Europa did so later. With a step of 0.0284, neither crossed that distance threshold during a 500-unit test; the run with 0.0275 also stayed bound over that test. This strongly supports the large per-substep timestep as the cause of the moons flinging out.

The fix I recommend
Do not just divide your current _dt by SubstepAmount. That is why your earlier test made the simulation too slow: the current high-timespeed formula already under-scales _dt relative to Timespeed, and dividing that result by the substep count loses even more time.

Instead, make _dt represent the correct amount of simulation time for one substep:

_
d
t
=
Δ
t
real
×
Timespeed
SubstepAmount
_dt=
SubstepAmount
Δt
real
​
×Timespeed
​

​

In your Scratch/TurboWarp blocks, change the _dt calculation as follows:

1. Keep the elapsed-time calculation and multiply by Timespeed.

Set _dt to:

(
(
days since 2000
×
86400
)
−
last time
)
×
Timespeed
((days since 2000×86400)−last time)×Timespeed
2. Divide that result by the actual number of substeps.

Add an if block:

if <SubstepAmount > 0> then
set to (_dt / SubstepAmount)
else
set to (0)
3. Remove the old high-timespeed override.

Remove the existing block that says, in effect:

if <Timespeed > 1> then
set to
(elapsed time * (0.5 + Timespeed / 30))
Keep your reverse-timespeed sign handling after the new calculation, and keep updating last time after calculating _dt.

With a measured frame interval of about 0.033 seconds, these are the approximate resulting steps:

Timespeed

Substeps

New _dt per substep

Total per frame

10

27

0.0122

0.33

100

116

0.0284

3.30

That gives the physics the intended 10× increase in total simulated time from timespeed 10 to 100, while keeping each step much smaller than the current 0.128 step that destabilized the moons in my test.

Keep Proportional Substep To Timespeed enabled, as it is in the uploaded project. If you disable it and keep only 26 substeps at timespeed 100, each step will still be too large. You don't need to increase the 5000 substep limit to fix the timespeed-100 issue.

My conclusion: your position and velocity formulas are consistent with a velocity-Verlet integrator. The immediate problem is how _dt is calculated and then reused unchanged for every substep. Correcting that calculation is the first fix I would test before restructuring your gravity loops.

please don't paste walls of LLM output

I'm confused. What is the purpose of this very long post?

Paddle2See wrote:

I'm confused. What is the purpose of this very long post?

….

10152693 wrote:

Paddle2See wrote:

I'm confused. What is the purpose of this very long post?

….

Thats the ST : o

10152693 wrote:

Paddle2See wrote:

I'm confused. What is the purpose of this very long post?

….

Can you answer the question xD

medians wrote:

(#6)

10152693 wrote:

Paddle2See wrote:

I'm confused. What is the purpose of this very long post?

….

Can you answer the question xD

Honestly this is pretty funny lol

It seems to be as a way to show how bad chatgpt is at helping with Scratch projects? At least that's the way I see it

scratchcode1_2_3 wrote:

medians wrote:

(#6)

10152693 wrote:

Paddle2See wrote:

I'm confused. What is the purpose of this very long post?

….

Can you answer the question xD

Honestly this is pretty funny lol

It seems to be as a way to show how bad chatgpt is at helping with Scratch projects? At least that's the way I see it

Yeah chat GPT tends to output some random mix of programming languages, as it can't display scratchblocks.

Did ChatGPT help you fix a bug?

rdococ wrote:

Did ChatGPT help you fix a bug?

emmmm……………….. I increased orbit stability in my SSM2 already…. (and without using Chatgpt and I figure it out by itself)



“Life is really simple, but we insist on making it complicated." - Confucius

that is true

Can you explain the purpose of this topic though (I'm still confused)

medians wrote:

Can you explain the purpose of this topic though (I'm still confused)

I guess this topic is just to show how ChatGPT reacts when you send them a .sb3

ose737 wrote:

medians wrote:

Can you explain the purpose of this topic though (I'm still confused)

I guess this topic is just to show how ChatGPT reacts when you send them a .sb3

It*
It's not a person, it's not even a living being, it's a bunch of math running on a company's data center, so it should be regarded as such and nothing more.
I use AI a lot but there's a correct way to use it, and anthropomorphizing it and/or getting emotionally attached to it is incredibly unhealthy and usually leads to worse

scratchcode1_2_3 wrote:

ose737 wrote:

medians wrote:

Can you explain the purpose of this topic though (I'm still confused)

I guess this topic is just to show how ChatGPT reacts when you send them a .sb3

It*
It's not a person, it's not even a living being, it's a bunch of math running on a company's data center, so it should be regarded as such and nothing more.
I use AI a lot but there's a correct way to use it, and anthropomorphizing it and/or getting emotionally attached to it is incredibly unhealthy and usually leads to worse

I know, I was just a little lazy when I wrote that post.