Calculator Issue
While feeding 'orientation' value in to 2 calculators, then with the press of a button, checking if it's either higher than '>', or lower than '<' 2 set values (basically, which way you are looking), the calculator checking for '<' always sends out a positive signal, even if the check is not true. The only thing i can think of, is do i need a frame delay? Frustrating. Found a work around for now, but would like to figure it out...
-
You have to think about what the calculator is actually doing. What does > mean for a multi-valued wire? It could mean all sorts of things. In Dreams, it means 1 thing... (Note the links to tutorials explaining this stuff better.)
The way calculators operate on fat wires in general is to operate on each separate value. Then recombine into the same fat wire type in the same positions.
As an example, if you have a direction of (0.316228, 0, 0.948683). You're checking if it's > 0.1. That will return (1, 0, 1), because the first and third values are > 0.1. That outputs that as a new direction (or really a "3 numbers" fat wire, at least).
But then how are you using that? If you're using it to power something, it's not checking to see if any of those values are 1. It's using the "default value" of the fat wire (1, 0, 0). For "3 numbers" fat wires, its default value is the magnitude (distance from (0,0,0)) of the fat wire. In this case, the distance between (0,0,0) and (1,0,0) is 1. So it takes that value 1 and uses it as the power. (If you just tried to use a number displayer to see the value, or looked at the calculator's "=" to see the output value, it would also show you this default value, not the full 3 numbers.)
Most gadgets are just at full power as long as the wire feeding them is > 0. 1 is > 0, so the gadget is now powered.
Such a direction will *almost* always have a positive and negative value somewhere in there. And so most likely will have at least one of the values turn into a 1 for whatever check you're doing.
Also, if you're doing something like (value) -> (>) -> (<)... then the output of the (>) calc will only have 1s and 0s, and probably one of each. So the (<) calc would then not be checking the original values, but checking if 1 < x and 0 < x.
On top of that, if you're using a true "orientation" (the rotation fat wire type), this gives outputs/uses inputs of degrees. But internally it uses a "Quaternion" value--made of 4 separate values to describe an orientation in a different way. So then the calculator is operating on those 4 numbers you can't even see, which can make it even more confusing to figure out what is happening.
... Really you shouldn't use an orientation, because the maths is very hard to understand. Ideally, use directions instead. And simple > and < won't be sufficient either, you should use a dot product between 2 directions to see how similar they are. Or skip all of this and go non-logic-y (always best if you can make it work)... by using an angle sensor. Very easy to set up, use, and understand.
-
Ok, yep, fat wire was the issue. Even though it outputs and displays a number in the calculator, that is in fact not the number it is reading.... messed up, but ok. Ran it through another splitter did the trick. Not sure if is my best solution yet, but at least i now know how it works.. Thanks
-
Ah, the number it shows you on the calculator is the "default" value of the fat wire, also. Just so you know.
If you wanted to use that default value, you can get that as its own thin-wire value in a number of ways: https://youtu.be/C-6t4ZQCpGw?t=482
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.