I found this bug by coincidence (forgot to decompose the blocks first):
.. whereas:
I found this bug by coincidence (forgot to decompose the blocks first):
.. whereas:
I think I know why this happens
When a ringifyed stack is split by blocks it reports the inputs separately from the block itself, but when it’s just 1 block it reports it normally
even tho its a bug it would be useful ngl
How would it be useful?
detecting block
?
The identical to operator probably works properly
it does not
That’s what you would expect to happen is it not?
20 is not equal to 10
I meant detecting block, not exactly a block with its values
The “split by” block already separates a block from its inputs
yeah i use it
but it has issues with local blocks
That’s because they are the same blocks, and that’s all that item 1 is, the block itself, not the inputs
As do most things
It's a bug (post #1). Better have the Snap ! development team look into it.
Yea it’s a bug, but why does it happen?
From the looks of it it’s only evaluating the last item in the block stack
I think this is because as I said earlier, snap sees block stacks inside rings as a sort of list of all the blocks, so if a block isn’t intended to handle lists in this way than it just goes off the last item
I have just confirmed, it’s definitely only evaluating the last block in the stack and ignoring all others.
You can test it yourself it’s definitely the case or at least looks like it
Depending on what version this originates from I suspect it has something to do with the vardradicness of the equal to block
Oh, then its not useful
Actually it seems the equal to block has been Unhyperized in the update that did this
This could be the root cause of the problem
The grater than blocks work fine still
In my personal opinion every block in the library should be hyperized because it just makes more sense
Are you sure it ignores all others?
Looks like these blocks must be the same