Bug of wireless activity??

[mahdoosh1]

I was trying random things and noticed that after making a loop, my phone was getting laggy, and by interacting with non connected nodes, some nodes were getting fired without any relationship between them,

[mahdoosh1]

[mahdoosh1]

By clicking on not-connected node, other node gets fired

[mahdoosh1]

Is this bug or a fature?

[TodePond]

Wire loops are too slow at the moment: https://github.com/TodePond/Arroost/issues/158

And that node that is stuck 'on' is another bug I've seen. Not sure how to reliably reproduce it yet. It would be useful to figure that out! Thanks for testing it out :)

[mahdoosh1]

Youre welcome! But that node is not stuck, i clicked on it and the node next to it got activated for no reason.

[TodePond]

Oh I see! Thanks for the explanation. Sounds like the delete node didn't properly delete everything. That part of code was very rushed. I'll redo it again soon!

[loglot]

It's Bluetooth!

[mahdoosh1]

It's Bluetooth!

xD True i guess!

[TodePond]

Still not sure how this is happening 🤷

[TodePond]

@allcontributors add @mahdoosh1 for usertesting

[allcontributors[bot]]

@TodePond

I've put up a pull request to add @mahdoosh1! :tada:

[mahdoosh1]

not fixed by accident, i hoped this was being fixed without us knowing just like my second issue.

I guess the problem is from calculating if cell A should be fired when cell B will be fired in future, in a loop

Diagram: (@ means a cell or a slot) (F = future connection, P = past connection)

    @A
     P
    /\
    |
    @
     P
    /\
    |
    @  ---> F   @
     F          |
    /\          |
    |           |
    @B  F <---/

[mahdoosh1]

Problem is about this code but in arroost

[anderium]

Wireless activity becomes an issue in large machines where you use instant wire, because cells can be triggered multiple times when they shouldn't. Especially obvious in wires that go to ArrowsOfColour.

What I think is happening is indeed related to the code mahdoosh linked. Whenever anything is clicked, it causes a fullFireCell that refreshes all cells, but doesn't actually step to the next beat. Then when the beat happens, these cells fire again, even when they already did because of the user click. It's difficult to say what the expected behaviour should be, preferably only firing the cells that are directly connected with timing === 0 wire. I'm not sure whether those connected cells should have the option to fire again, though.

More specifically in my video, if you click during the aftermath portion when the wire changed you can change it another time, or if you click during the buildup phase of the previous beat.