I'll need a little time to figure out how to do that because it's not real simple. It may take me a couple of days. I'll have to put my brain into "math mode" which sometimes causes headaches! lol
I got it working faster than I thought I would! It's the response scene to this one and it is titled "For Quark Down".
By the way, you can separate the laser from the circle if you want to and it will still point in the direction that the circle moves after colliding with another object.
s_noonan -- I originally used that simpler equation form but it didn't work because I now realize it had a typo. So, I went with the form that I've used in other scenes which uses the offset of pi/2. Either way is just as accurate.
Nice work, but I have just a couple of suggestions: 1. I think you meant "Predictor" instead of Predicator. Right? 2. Disable the Algodoo clouds. It doesn't make sense to have clouds floating by in a technical scene like this one.
Maybe the creatures should get weaker and smaller over time when they do not consume food. When they get below a certain minimum level of weakness, they die. There are a lot of other interesting things you can do with this!
The creatures turn into food when they die! I didn't think of that but it makes sense.
The only issue I see which is probably different from real life is the fact of entropy. These creatures must gain and use energy from the food they consume, and that energy doesn't remain in this closed system. So they must get renewed energy from some outside source (like the Sun?). If not, then the entire system will die over time as all the energy gets converted to heat.
Wow, there's a lot of "meat" here to chew on! I have my own favorite ways to write to arrays (single and multi-dimension) but if yours are faster and/or more efficient, I just might end up adopting them.
MyNameIsThis -- Algodoo isn't broken. Either there's a problem with my scene, or there's a problem with your computer. But before I get all worked up about it, I want to first find out if anyone else is having the same issue as you are.
IS ANYONE ELSE NOT ABLE TO SEE THE SPRING TEXTURE IN THIS SCENE? PLEASE LET ME KNOW IF YOU CAN OR IF YOU CANNOT SEE THE TEXTURE BY LEAVING A COMMENT. THANKS!
In the example which shows a letter array [h,e,l,l,o], I believe each letter needs opening and closing quotation marks. Otherwise, Thyme will interpret those letters as variables instead of text.
More: Same for the word "hello" in the Results example shown.
The MU button is "Mark Up". I found its syntax on the web and copied here for you:
The [MU] key is used for markup. Here is an example of the markup function. If the purchase price of an item is $120 and the profit rate is 25%, what would the selling price and profit be?
Enter the following:
120 [MU] 25 [%] (result 160)
[=] (result 40)
The selling price would be $160 and the profit would be $40.
I know that calculators are not easy to code using Thyme Script because I have tried it myself a few years ago. There are a few other calculator scenes here in the Algobox archive but only a couple of them are what I would consider "well made". A few, to be totally honest, are not at all usable.
You are making good progress on your calculator scene, but keep in mind that in order to get it working "perfectly" like the real world model (if that is your goal), it will take some time to wring out all the little bugs.
roshanali -- Yes, I am familiar with the math error that you described. That kind of error is due to the nature of how floating point values are calculated, and I have seen that error in other things that use floating point. The beauty of floating point calculation is the fact that it can handle very wide ranges of input and output values. It sacrifices accuracy for wide range and fast calculation speed. Usually the error is a very tiny percentage of the correct value which in most cases is acceptable. Many calculators "hide" the error by displaying only a certain number of digits of the answer. For example, if the error happens to be + or - 0.000001, the calculator might display only the first four decimal digits so that the human operator cannot see the tiny error that might show up in the answer! I did a Google search on "floating point calculation error" and it found many good articles that explain the error and why it happens.
Concerning "Mark Up", I think that would only be important to someone who runs a retail business who needs to calculate how much to mark up (increase the sale price) of items in order to make a certain profit. If you don't want to bother with making that button work, you can either just ignore it, or you can "hide" that button by sticking a patch over it that looks like the background color of the calculator. Problem solved! You can also hide the Calculator model number so that no one can look it up on-line to compare the actual one with the one that you made. Just a few things to think about!