Calculators treat “8 values” fat wires differently than 2-4 values
Create a combiner and use it to combine 8 different signals. Connect that to a Calculator, and use that calculator to multiply the fat wire’s values by 3, by setting the slider on the Calculator’s other operand.
Use a splitter and number displayers to inspect the values of the eight signals coming out of the calculator (or search “signal display” on the dreamiverse)
Observe that the values were multiplied by (3,0,0,0,0,0,0,0).
Tweak the Combiner to change its type to “4 values” and observe that now the calculator multiplies by (3,3,3,3).
I would expect that “8 values” be consistent with the “4 values” behavior and multiply by (3,3,3,3,3,3,3,3) instead.
If you are meaning the split gadget, It's quite different from it alone. If you would interpret the fat wire as a SIMD vector, then split gadget is loosly equivalent to SIMD "store" operation, which is "put every value from vector into it's individual variables". Splat is more like "get a single (one number) value and put it into every slot in the vector". So literally a dreams' merge with all inputs connected to the same thing, or what should happen when you connect a thin wire to a gadget expecting a vector fat wire (what this bug is about).
Anyway, This is of course all just a loose in interpretation on my part, because in reality you would have to talk more about registers and memory when talking about SIMD operations, but dreams doesn't really have that. So take it all as a useful metaphor :)
Oh fascinating! Never heard of that before, cool!
Of course, Dreams uses the term "split"--so we split a fat wire using a splitter. Funny how they're so similar and have pretty much the same meaning...
Thanks for clarifying!
heh, it's not autocorrect. I wrongly assumed that this is a somewhat known word, but seems like it's actually quite esoteric. Anyway, splat simply means "distribute a value to all vector lanes". It's commonly used in SIMD processing context. Hope that explanation makes things clearer now :P
(Do you mean "split"? You must mean split, right? It seems you write "splat" every time. Is that some sort of autocorrect that happens every time?)
I've found a workaround how to do a splat using just two wires using signal manipulator. The trick is to use remapper mode set up to remap 0-0 to 1-1 and modulate that value. See attached screenshot for details.
It works well in my case, but fixing the bug would remove the need for it completely. It would just be a direct wire connection with wire blend set to modulate.
Oh interesting... I'll have to test that again then. Perhaps that inconsistency is a clue as to what is causing this bug too.
That's what I have initially thought too, but it is indeed taking a max of all values, without even treating negatives differently. I think this is a very good thing, as 8 sized vector magnitude isn't really useful in practice. Instead we have a very needed gather operator. I hope that this part will stay as is.
Yeah I'm not saying "there's no need to fix it." They should totally fix it. I'm just thinking of workarounds that are more efficient than spliter -> 8 calcs -> combiner.
I thought an 8-number gives you the magnitude of the vector, just like with 2-number and 3-number fat wires?
@TAPgiles I'm using fat wires in a very thermo sensitive system (pathfinding nodes with 8 channels), it would cost me about 40% of additional wires thermo if I was to copy the whole thing over. Right now Its less costly to splat the values manually where needed on the path follower logic, and keep the nodes as optimized as possible using 8x fat wires. Fixing that bug would allow me to squeeze in a few path followers more into the game, and it would drastically simplify some parts of logic.
Also note that converting 8x wire into single value gives you the highest value out of 8 channels back. having that combined with working 8x splat would allow for very neat logic optimizations where you can scatter values into 8 channels, do 8 calculations in parallel and gather the highest result. Right now the scatter part is unnecessarily costly.
@Beardy: Player Info's default value uses the player value that is furthest from 0. I'm guessing currently it uses that default value, manipulates it, and spits it out. So if it manipulated all values and spits that out as a fat wire, it would result in the same default value and so in most cases shouldn't cause an issue.
@Friz: Could you use 2 4-number wires instead? Then the calculators would work correctly and you'd only have to do it twice.
I've made a cleaner screenshot that presents the value on single adder for each multi-number fat wire type. This can be very annoying, as manually splatting the values into the eight slots every time is very annoying and in my case also eats through the wires thermo quite significantly.
A similar (but not identical - in this case the calculator outputs a thin wire) thing happens with "Player Info" fat wires.
But for Player Info, Mm have really painted themselves into a corner by making it the output type for so many gadget tweaks that could have been thin wires (controller sensor outputs, variables and scores not tweaked to be per player etc). By now, too many creations will be relying on Player Info's simplified Calculator behaviour for Mm to add it to the set of fat wire types for which Calculators operate on each channel in parallel.
Not sure if they'll run into a similar problem if they try to do that for "8 values" fat wires.