Q: Are you smarter than a chimp?
A: No, not according to my test results.
I wonder if this chimp works 40 hours a week doing this. If not, then he might be better off than most assembly line workers, who also work for peanuts. I would think that, with the improvements in productivity, we would be down to a two or three day work week by now, but I guess that's not how it works.
P.S. Looks like he has a pretty good dental plan (judging by his teeth).
Thanks xray, this scene is similar to my Zero Stiffness scene.
Q: I would assume that the device's accuracy and precision are greatly dependent on the type, shape, stiffness, and other mechanical factors of all three springs.
A: The vertical spring rate needs to be 2X the horizontal spring rate and the horizontal spring free length needs to be the distance from the anchor point to the center pivot.
Q: Do the changing colors indicate mechanical stress or some other physical property?
A: No. The color of each spring element does not change. The plastic slinkys are sometimes rainbow colored.
Thanks. I agree. This scene only deals with one aspect of your scene, the image sensor. Your scene is much more than that. Your scene is done well and I rated it accordingly. To use this scene's image sensor with a lens, set laser max rays to 3.
Q: Did you try to straighten out those dips?
A: Yes, by varying the spring force, constant, and damping. In the end I just tried to hide them by setting Smoothing to 50 on the Plotting widget.
I found that the higher restitution results in a smaller unsmoothed blip. Also, I still get the blip upon removing the frame, so I think the blip is mostly associated with the mechanism inside the frame.
Your scene is breaking some of my (and other people's) scenes. Running this scene replaces "sin = {math.sin};" in the config.cfg file in the Algodoo folder with "sin = -0.019242514;". Start your scene then enter sin(0.75) in the console then press enter. The sin function will fail. Resetting Algodoo will fix the config file until you run your scene again. I fixed the scene by changing all "scene.my.sin" to "scene.my.b" and removing "scene.my.sin" from your scene. I've added the corrected scene as a response scene. You can use it to replace your scene if desired. I will remove my response scene upon your request after you fixed your scene or indicate that you don't care. You will need to reset Algodoo after updating your scene in order to fix your config.cfg file.
P.S. I revised your scene to _03 to eliminate warnings in the console window. Those warnings were caused by not initializing all your scene.my variables. Some object properties were tried to be set to unknown variables. It's good practice to initialize scene.my variables before use.
Regarding "App.GUI.playMode = sim.running", as far as I know that will only work in an object and can't be done at the root level. If you still have code forcing "mode=sim.running" when you create a new scene, then check the last few scenes you downloaded to see which one caused the problem. If you locate the scene, then you could post the scene's url in the comments here and I can look for the source of the error. Some scenes put the "App.GUI.playMode = sim.running" code in the update event of an object, so there is no way of getting out of playmode for that scene. Loading a new blank scene should not automatically start playmode (assuming you shut it off before starting a new blank scene.
Q: Is there a way how to get rid of it?
A: Yes, use the phunlet in this scene.
Q: Where in console is this code running?
A: I don't have a clue. The console does not retain any code. As far as I know, the only code that runs in the console is temporary code that a user puts there. Code that caused problems for me has always been in a scene. Usually its the result of Algodoo tripping over some code and causing unintended damage or a user creating variables at the root level instead of using "scene.my." variables.
Q: Can I report a scene for doing this, without me knowing it?
A: Maybe, but it usually helps if you identify the scene. Otherwise it's reporting that one of the 158,000+ scenes is causing a problem but you don't know which one it is.
"it makes me mad when Algodoo is doing things on it's own, outside the scene I downloaded"
Some settings persist after the scene is closed, some don't. If a scene creator is going to change a persistent setting, then the scene can read the the users settings when the scene is opened and put them back when the scene is closed. Even this will fail if the user loads a new scene without closing the old scene. Most user's (including me) don't know which variables are persistent and which aren't.
My suggestion would be to find the culprit and tell him in his scene comments that you don't like what he's doing. Most scene creators don't cause problems on purpose.
P.S. An example of a scene breaking the config file can be found at Bacteria under the microscope. Load the scene. Open the console. Start the scene. A few warnings come up. The damage is done. Enter sin(0.75) in the console. Algodoo says it doesn't recognize the function. Close the scene. Reset the config file. Open a blank scene. Open the console. Enter sin(0.75) in the console. Algodoo shows the correct answer. This is an interesting example. I'm sure matto did not do this on purpose.