Q: What does "Reset Array" do, and how should it be used?
A: "Reset Array" clears the path array. The array should be empty before drawing with the chain. The problem is that the array automatically gets filled with the sample link entityIDs when the widget is spawned.
Q: You explain how to use the yellow circle in the widget but not the blue circle. What is the blue circle's purpose in the widget?
A: The blue circle is required to complete the chain link. The yellow circle adds its entityID to the array upon spawning. Once the yellow circles are created, the blue circles and hinges are no longer needed. The yellow circles are left so that you can change their position if desired. If you don't need to adjust the yellow circles, then you can skip steps #4 and #5. A drawing can be made up of several chains. The reason for two circles instead of one box is that I wanted to record the position of the hinges, not the center of the link.
Q: It would be a nice feature to be able to adjust the size of the tracer, the color, and the fade time.
A: I did not include that since that widget is already available in Algodoo. The tracer base circle has a _blank property that is true for retrace blanking and false for continuous loop. The base circle also has a _cycleTime property that automatically gets set in the onSpawn event.
Q: You might want to mention something about adjusting the "link distance" of the chain in order to make the animation more or less smooth.
A: I agree. I thought the link distance got saved with the scene, but apparently not.
Looks good and works well. I put "real" gears in it. The big internal gear should really have 48 teeth instead of 50. I suspect that nobody really cares if the gear has 48 or 50 teeth. Nice work.
P.S. Now I'm not sure how many teeth the big gear should have. I was changing the mass of the flywheel to adjust the speed and found out that the clock does not return to the same point each revolution. With circle gears, there are about 56 (but not exactly) swings of the flywheel per revolution. Something's not quite right, but you may already know that. I suspect that the clock could be designed for exactly 60 flywheel periods per revolution.
P.P.S So now I modified the clock for 60 flywheel periods and 60 Algodoo seconds per revolution. I will post it as a response to this scene.
Thanks Xray. I don't think I'll be taking up the 3D challenge any time soon. First, this scene is at about my limits for programming and math. Second, I spent a lot of time on this scene and I'm not ready to dive back in. You can experiment with more or less Fourier terms by changing the _n value in the "Create Robot" button. _n = 64 creates 128 robot arms.
I checked out "ROTATE A 3D WIREFRAME CUBE - V3". Nice work
It's more fun to hit the targets without the arrows. Otherwise it's like trying to get ahead in traffic but always falling behind. My recommendations would be to slow down the hose angle motor for more precise positioning and to reduce the brake torque on the orange gear so it turns easier. Another idea might be to have the arrow fade before it switches. That way the user would know when it's about to switch.
The scene file size is quite large. I don't know if that matters these days. You have a 2.4M funnel image in your .phz that doesn't seem to be used anywhere.
One approach may be to eliminate negative numbers (since they are a fairly recent invention). If you use small increments for non-arrowed objects and bonus points for the arrowed objects, then the scoring would be similar to a pinball game. That way players would not get their precious feelings hurt getting a big negative (loser) score (like me).
1. If I want to see a single property for several items at once, then the standard Algodoo property widgets are hard to organize and obstruct the scene. The info boxes this scene generates are smaller, translucent, and can be a permanent part of a scene or just used temporarily.
2. This allows a user to make permanent property displays without any coding. The design is made to make things easier. If it doesn't do that for a user, then he should not use it.
3. I expect the user to learn some things by trying it out. If they can't figure out the enable/disable button then they should not use the widget.
4. You are correct. I could not figure out another way to have a user enter text while in design mode.
5. You are correct. I don't know how to code against that behavior. Sometimes, if the behavior causes no damage, then I allow a user to experience the behavior instead of posting warnings.
Although the answers above may seem somewhat defensive, I do appreciate the feedback.
I had checked your scene out before choosing to go with the Algodoo text box. What I found out was that , in design mode, onKey along with e.keycode and e.keychar were not available. keys.IsDown does work, but then I figured I would need to make an array with every possible key press and iterate thru the array checking to see if a key was pressed. I would also need to check for special keys like space, delete, and backspace. I would also need to ensure that the keys don't automatically repeat. At that point I figured even if I did that, the result would not be any better than the widget that Algodoo already supplies. I may still give it a try.
I ran into an interesting problem with my spring generator scenes. Since I use a general solution that could include springs with tapered wire, I calculate the centroid of each spring element polygon. It turns out the centroid calculation degrades the further it is away from [0,0], so that a small spring created far away from the origin looked disheveled. I corrected this in all my applicable spring scenes. I now calculate the centroid with the polygon over the origin before moving it to the final destination.
Nice work. Looks good. I see you used "real" gears and cut them to make them look sharper. In the old Phun days I think you could reduce the opacity slightly and gears would sharpen right up, but now with Algodoo we have to resort to cutting big gears. Most people will notice the sharp gear tooth profile before they notice a cut. This scene works flawlessly. I didn't realize that a tourbillon is the balanced escapement at the bottom of your watch until I started playing with your other scene.
1. Sorry I got you fired up. That was not my intention.
2. I appreciate the selfless work you do and would not want to do it myself.
3. I was not too upset that you deleted the initial scene. I interpreted it as a reflection of society norms where death and destruction are OK but certain bodily functions are taboo.
4. I would have liked to know what was the most objectionable about the scene (the stream source, the stream, or the receiver) so I could take corrective action. Right now the hidden source is a kangaroo with swim trunks (I wasn't sure if naked kangaroos were OK).
5. I think you do a great job, even if we don't agree on everything.
6. I do take some joy in challenging authority, but you're taking some of the fun out of it.
7. I don't think I'll be taking this up with the Algoryx guys.
8. So I guess you won't be rating this scene a 10.
Thanks for the response Xray. Upon review of my initial comments I can see that it would have made more sense to focus on the shortcomings of the scene than to attack the reviewer.
I'm OK with leaving the comments in so that others will learn from my mistakes and it may save you the effort of repeating yourself later on. My preference would be to make this scene equivalent to the original scene but replace the original subject with the kangaroo in swim trunks. I'm still not sure if that's OK, but I assume so since matto's scene with a couple of butt cheeks pinching out a loaf appears to be OK.
Nice first scene. See help next to the "Add Reply" button to see how to add a youtube video to the description. Here's Rolling car! RollGolf 2.0 testdrive for reference.