Q: When measuring three teeth at a time, doesn't that cause the infamous problem of accumulating tolerances over the entire length of the rack?
A: The scene works on the assumption that the location of 2 teeth (the green ones) are known. They could be any 2 teeth. The first reference tooth can be considered [0,0]. If the second point is known then the math will figure the best fit numbers between the two points, else you get an accumulation of tolerances. I tried the scene without a second point and got [-2.7,1.8] instead of [0,0] for tooth 6. A real measuring tool may not be as accurate as the simulated tool.
Nice work. This scene is very easy use and has a nice presentation. The code behind the scene is fairy involved, so I started digging into it. I thought "Why abstract the game board to an array when the objects themselves have all the necessary info?". The code is in the response scene.
My perspective is that your code is very effective and better than most coders on Algobox. I also think that the concept of the scene is more important than the coding. If I had a good idea for a scene, then I would probably be making that scene instead of picking on yours. The reason I suggest code changes is because I'm always trying to make my code simpler and appreciate it when somebody shows me a better way (like your code suggestion for the Rolling Stone scene). Another reason is it might make future scenes easier. In this case, the code suggestion would make scaling up to larger grids trivial.
Q: Did you run into the same problem with your scene?
A: No. I think I lucked out. The 0.05 step value automatically got saved as 0.050000001 in Algodoo. I will change my code slightly to handle edge cases.
I calculated "% lag weights" for each marble they are 16.0, 2.5, 3.4, 0.4, and 0.3 for sponge, rings, sparkle, swirl, and circle marbles. The % lag weight was calculated from (1-%lag/100)/numOfCopies when the scene had approx 50% lag. This calculation is system dependent.
A 8X8 grid of boxes at rest at the origin is hit by the blue ball coming from the right. Solving the conservation of momentum equation for the system will give the original speed and direction of the blue ball.
1. I couldn't solve the puzzle on my own so I downloaded the game and also downloaded an android emulator for Windows. I then found the exact puzzle which had a solution video which I screen grabbed. I took the screen grabbed video and extracted (1) frame jpg a second from it. I then automatically changed the jpeg image size to 50% of the original and renamed the files. I then took all the files and put them in the scene. So the solution is snapshots at one second intervals which averages out to be about 1 image per move. It's not exact, but it's enough information to figure out the solution. I could have exported 30 images per second and cherry picked 68 images, but I didn't. Diagonal moves are allowed in the original game if there is space for (2) rectilinear moves that would accomplish the same thing.
2. Q: What is "entity"?
A: Entity is the object itself. It's what you get if you execute entityByID(entityID) in thyme.
Q: How does that parameter get its value?
A: It's implicit.
I'm not sure what "e" is. Some object I guess. I think it has different properties for different functions. Thyme lets me use it in the scene.my functions, but I don't understand it fully.
If Xray was paying attention he should have guessed 1 greater or 1 less than my number of frames. Since nobody else guessed, any guess I made would be the closest guess. Did you calculate the number of frames or is there some way that Algodoo displays the number of frames? Should we disclose how this was solved, now that I received my cookie in the mail?
Q: Did you do that because you were not able to wrap one long spring around the two pulleys?
A: Yes.
Q: Would it produce a different result if you had done that?
A: No, I would expect pulley rotation and "rope" tension to be about the same, but springs don't wrap in Algodoo.
I added the metallic pulleys so that the pulleys would appear to be in synch with the "rope".
Very cool. Another version I was thinking of was to set it up so that every time you click the simulation run button in a new image, a new half size image gets created that has a coded "run" button. I won't be doing this anytime soon, so anybody can make it if they are up to the challenge.