Jaser Newell

Understood, but I still consider such things as bugs. There's a reason I said, "[E]ven if this choice was necessary can still problems." Basically, if it is something for which one has to find a work around, I consider it a bug even when there are good, understandable reasons for it.

I understand what you're saying, but I still consider it a bug. I admit that I didn't understand the nature of how floats worked in lsl in the beginning, and in fact did make the mistake of thinking the ASCII representation would be an accurate description, and I thank those of you that posted for pointing out my error. Yet as you pointed out, base 10 can be done by emulation. SL chose not to do that, which even if this choice was necessary can still problems. As you also pointed out, lsl uses the same representation for assignment and comparison. That's why converting it to a string and back to a float after the arithmetic operations allows it to work without any of the difficulties referenced thus far. This seems to be a perfectly suitable solution that gets around that pesky binary problem.

Madelaine, the purpose of using a float in the script in question is to easily regulate "subtasks" which I found to be easier for me by using a float and allowed me to get rid of multiple variables and just use one. The script actually used a different type as the variable previous to this change, but I was forced to use multiple variables to keep track of all the different possible variations. Dora, considering I have solved the issue with a simple conversion, comparison equals works just fine for my purposes. I agree that it is normally a bad idea to use comparison equals on a float, but since the issue has been resolved and the usage of it is so simplistic, I'm making an exception in this case. As far as the issue not being a bug, I would disagree. If something as simple as 3.1 + 0.03 creates any other value than 3.13, then I consider that a bug no matter what the reasoning is behind it.

After further investigation I think I figured out what the issue was. My original script made use of "+=", creating the number as the script ran, as follows: Task = 3; Task += 0.1; Task += 0.03; This seems to sometimes create a slightly different value for "Task" than would be expected that is undetectable when it is converted into a string. While "(string)Task" will produce "3.130000", "Task" does not equal exactly 3.13. Since I have a user defined function that is always ran right after "Task" is changed, I just threw "Task = (float)((string)Task);" into it. Since the slight difference is undetectable when converted to a string, when the resulting string is converted back into a float it produces the value originally expected and allows the script to work.

Just noting that I found that if I convert "Task" to a string and back to a float, it works. Just bizarre.

You're completely right, of course, and thank you for trying to help out by the way. I wanted to let people know about this issue, and see if anyone knew why this occurs. As I said, the values are definitely equal and should work, but lsl will not recognize them as equal for some unknown reason. I'm counting this a bug on SL's end.

I was hoping not to have to do something like that, but I may not have a choice. It is known to me that when this problem occurs that "Task" equals 3.130000, so I really don't think it's a rounding error. In fact, I tested it with an extremely simple script. float Task = 3.13;if(Task == 3.13){ llOwnerSay("Works");}llOwnerSay((string)Task); The only thing it ends up doing is saying "3.130000" and nothing else. It does the same thing with several other float values as well.

I had an idea to use use floats to help organize the flow control of if statements dealing with a series of actions, mostly dealing with dialogs. It worked out great, until I realized that it wasn't working for one of the tasks I had scripted. I checked, and rechecked multiple times, but couldn't find anything wrong with the coding. My script has built in error detection coded into it, which allowed me to locate exactly where the problem was occuring. The strange thing is there shouldn't be a problem. An if statement isn't registering a comparison equals that it should be registering. The line of code in question looks like this: }else if(Task == 3.13 || Task == 3.23 || Task == 3.3){It works fine when "Task" equals 3.23 or 3.3, but not when it equals 3.13. As far as I can tell, there is nothing wrong, and my error detection has told me that "Task" does in fact equal 3.13 even though the script looks right past this statement. I've tried everything I could think of to get it to work, but it is still malfunctioning. What's going on here?