Algodoo

Thanks.

scene.my.calculate && _once ? {
  sim.running = false;
  scene.my.numOfBalls = scene.my.bin0count
    + scene.my.bin1count
    + scene.my.bin2count
    + scene.my.bin3count
    + scene.my.bin4count
    + scene.my.bin5count
    + scene.my.bin6count
    + scene.my.bin7count
    + scene.my.bin8count
    + scene.my.bin9count
    + scene.my.bin10count;
  scene.my.mean = (
    - 5.0 * scene.my.bin0count
    - 4.0 * scene.my.bin1count
    - 3.0 * scene.my.bin2count
    - 2.0 * scene.my.bin3count
    - 1.0 * scene.my.bin4count
    + 0.0 * scene.my.bin5count
    + 1.0 * scene.my.bin6count
    + 2.0 * scene.my.bin7count
    + 3.0 * scene.my.bin8count
    + 4.0 * scene.my.bin9count
    + 5.0 * scene.my.bin10count
  )/scene.my.numOfBalls;
  text = "Mean: \n" + scene.my.mean;
  _once = false;
  scene.my.calcStdDev = true  
}:{};  

scene.my.calcStdDev ? {
  scene.my.var = (
    scene.my.bin0count * (- 5 - scene.my.mean)^2
    + scene.my.bin1count * (- 4 - scene.my.mean)^2
    + scene.my.bin2count * (- 3 - scene.my.mean)^2
    + scene.my.bin3count * (- 2 - scene.my.mean)^2
    + scene.my.bin4count * (- 1 - scene.my.mean)^2
    + scene.my.bin5count * (0 - scene.my.mean)^2
    + scene.my.bin6count * (1 - scene.my.mean)^2
    + scene.my.bin7count * (2 - scene.my.mean)^2
    + scene.my.bin8count * (3 - scene.my.mean)^2
    + scene.my.bin9count * (4 - scene.my.mean)^2
    + scene.my.bin10count * (5 - scene.my.mean)^2)
    /(scene.my.numOfBalls - 1);
  scene.my.stdDev = scene.my.var ^ 0.50000000;
  text = "Standard Deviation: " + scene.my.stdDev;
  scene.my.calcStdDev = false  
}:{};

test

Nice work. I see what you did.

The GUI doesn't work for that example, but the underlying function does work.
Run scene.my.ra_elemExists([[2, 1], [1, 2], [5, 6]] , [1, 2]) in the console.

For reference:
scene.my.ra_elemExists := (ra, value)=>{
  elemExists := false;
  n := string.length(ra);
  scene.my.xFor(0, n - 1, (i)=>{
    ra(i) == value ? {
      elemExists = true
    } : {}
  });
  elemExists
};

scene.my.xFor := (n1, n2, code)=>{
  n2 > n1 ? {
    m := (n1 + n2) / 2;
    scene.my.xFor(n1, m, code);
    scene.my.xFor(m + 1, n2, code)
  } : {code(n1)}
};
scene.my.ra_setItem := (ra, item, value)=>{
  n := string.length(ra);
  r := [];
  scene.my.xFor(0, n - 1, (i)=>{
    i == item ? {
      r = r ++ [value]
    } : {
      r = r ++ [ra(i)]
    }
  });
  r
};

eval("[4, [1, 5]]")

Question: Are you working on a design that would be an improvement over any in this group?
Answer: No. I'm out of ideas for now. Feel free to make a design that surpasses the rest. Angle variation of the orange link is not an issue. The problem seems to be the non-linearity (dy) at the ends of travel.

Read the instructions in the scene.

Nice demonstration.

Nice work.

"Click the buttons on the left to disable/enable certain features."
What buttons?

I don't understand what you mean by "multiple piece possibilities". Do you mean consecutive moves by the same piece? Na2xb5 is not a valid move.

Why show "LEGAL MOVES" if it is not being used?

@CPJchute,

Thanks. If I understand you correctly, then the "x" in "Na2xb5" means "from". The added "xb5" would be to remove ambiguity if, before the move, (2) knights of the same color could move to "a2".

@42flowermaster,

I haven't looked into your code yet, but I'm thinking that legal move detection was not a trivial task.

@Xray,
Thanks. I see you are correct. Algebraic_notation_(chess)

The reason for the mod in SAN is to disambiguate moves where two (or more) identical pieces can move to the same square. In my defense, I thought since "Na2" means knight moves to a2, that the added "xb5" was for disambiguation, which is wrong. In the “Na2xb5” case, the notation would be "Nb5" if there was not another identical knight that could move to b5.

@PizzaGuy22,

% of simulation time on my PC:

       sim.frequency
  Version  60   120
  ~~~~~~~~~~~~~~~~~~~~~~~
  v2.1.0   97   70
  v2.2.0 b2 93   30

Thanks. Method #1 are pendulums and should work in real life.

Q: The circle continuously creeps in a clockwise direction.
A: That's an Algodoo thing. In real life they don't slip once set.

Awesome.

Well done.

Nice work. Maybe add an altimeter.

Nice work but balls could use vertical retrace blanking.

Thanks.

Nice scene and coding.

Nice work. I suggest putting the hammer slightly unbalanced when starting the scene, else nothing happens (and no instructions) when the scene is started.

Nice presentation. Easy to use. Fun to play. I found the background slightly distracting. I found the code difficult to follow. The box postStep code appears to be dead. I'm fairly certain nobody cares about the code since the scene works so well.

I concur. All the fire scenes that I checked out were finely tuned for the desired outcome. This scene tries to mimic that but does not attain the realism of the original scenes.

I also noted that the fires were affected by changing sim.frequency. I try to remedy that in this scene.

Thanks.

The reason the coding gets complicated is because it requires a state machine to track which state the scene is in (no balls selected or one ball selected).

pseudo code:
  scene.my.firstBallIsSelected := false;
  scene.my.firstBallColor = [0,0,0,0];

  scene.my.onSomeBallGetsSelected = {
    scene.my.firstBallIsSelected ? {
      scene.my.firstBallColor == colorOfBallSelected ? {
        scene.my.firstBallColumn.firstBallPos = topOfSecondBallColumn;
        scene.my.firstBallIsSelected = false;
      }:{};
    }:{
      scene.my.firstBallColor = colorOfBallSelected;
      scene.my.firstBallColumn = selectedColumn;
      scene.my.firstBallIsSelected = true;  
    };
  }

Thanks.

Nice work. I like how the sliders have minimal parts and minimal code.