If MQTT publish is put in a FOREVER loop, other MQTT blocks don't work

Advanced Topics Advanced Help with Snap!
,
1

when a MQTT publish block is put in a forever loop, other MQTT blocks stop working.
project links:
server,
client

to reproduce:
open the server project, press the flag.
now, in a separate window, (or a separate browser, or a separate computer, but NOT just a separate tab) open the client project and press the flag. the red sprite can be moved using the arrow keys, and the green one should follow, but it only does if you enable slow stepping or open a block definition.

I'm pretty sure this is a bug

note: if two or more people try to reproduce this at once, it will probably break. to prevent this, set the server name variable in both projects to a different value. (but they need the same value)

2

I went to run the server but I go this error as soon as I opened the project
image

I just tried this tight loop script and it seems to work fine
mqtt

3

the error should be fixed now.

your script does indeed work, but the bug is that in a setup like in this project, the move script only works sometimes.

sprite one script:
broken MQTT script pic
sprite two script:
broken MQTT script pic (1)

4

aah - I see the issue now - let me investigate it....

5

This seems a quick workaround

image
image543×694 108 KB

6

Ok. I’ll try that in both projects later.

7

I don't think the workaround is 100% reliable so don't put too much effort into testing it at the moment

8

ok. the problem in the main projects is that the get cloud variable block has multiple MQTT blocks running one after the other

9

I managed to get some time to look into this and it seems to be an issue with the default broker

I switched to using mqtt.eclipseprojects.io and it seems to cope with the traffic levels of two publish blocks in tight forever loops

10

ok. I'll try that

11

alright! that seems to work well. I'm glad you found a solution.
Thanks!

12

It has highlighted that flooding a public MQTT broker with a lot of traffic is maybe not the best approach, so try and add some waits if possible

13

yeah... that's a problem though because for multiplayer projects you need fast and constant transmission of data

14

I can understand that but we are just free-loading on the goodwill of the public broker providers, so it's best to try and not thrash them if possible :slight_smile:

15

yeah. I don't think I could afford a paid broker just for Snap! :(
I wish there was some kind of cloud brodcasts or good cloud variables on Snap!
Oh well