With the launch of PICOWARE, I got many reports from player saying they got a "communication error" when trying to play the minigames. This error was a fail-safe mechanism intended to avoid a situation, wherein someone tries to start a minigame cart in any other way than from the main cart.

The implementation is: on main cart load, zero out the "difficulty" save data. On subcart load, set the difficulty — it's guaranteed to be in range 1..15. In subcart, check if saved difficulty is 0 — if yes, stop the cart and display a message about a communication error.

Subcarts decide what mode/difficulty/minigame will be used based on the data received from the main cart, and so this is to enforce starting from the main cart. Furthermore, after a whole playthrough, subcarts are supposed to return to the main cart and inform it of the score. Can't imagine a situation when the player starts a minigame in a "single minigame" mode, then the subcart starts the whole story mode, and after finishing returns to the story cart which informs the player that they beat the whole stage.

As players started flooding in, I got reports saying they get the "communication error" during normal play. Different browsers, different operating systems, web and standalone, online and offline, and very unreliable. Further investigation showed that indeed — very rarely, with no noticable pattern — the save data in the subcart is zeroed out.

Nothing seems to have any effect on this bug: changed dset/dget to poke4/peek4, tried setting the data a few seconds before the load, still the bug hasn't disappeared. Tried reproducing this with a set of test carts using code below:

a.p8.png:

function _init()
 cartdata("foo_bar")

 -- set to a random number
 for i=1,10 do dset(0, rnd(-1)) end

 dset(0, 1337)
 load("b.p8.png", "breadcrumb")
end

b.p8.png:

function _init()
 cartdata("foo_bar")

 -- should fail if dget(0) ~= 0
 if dget(0) == 1337 then
  extcmd("go_back")
  return
 end

 cls() print(dget(0), 1, 1, 7)
 flip() repeat until false
end

I've had this running non-stop for 10 minutes, and… nothing. This just works. I'm lost. This probably is influenced also by something else — PICOWARE cart is so dense (it seems to have broken the cart image somehow), maybe that could be a factor.

Here is a GIF of me reproducing the bug (PICO-8 standalone, offline cart):

And the steps to reproduce:

1. Load PICOWARE (e.g. load #picoware)
2. Start story cart (any mode, any cart)
3. If cart was loaded and started correctly, go back using the breadcrumb menuitem and try again until bug occurs

Also, one thing I noticed personally — this never happened the other way around, that is when returning from a subcart. Although communication data in the subcart is set instantly right before returning, there never appears any problem with the main cart receiving this data — which, if happened, would appear as the main cart showing the title screen first instead of the cart view/score screen (cartdata is used for this too).

This seems like a very peculiar bug, nonetheless one that affected many PICOWARE players, and I'm lost trying to figure out the root of this.

EDIT: Additional updates in comments below.

Small update: I've been able to reliably reproduce this issue with Firefox Focus on Android, although I feel like this probably isn't related. (Firefox Focus is a "full privacy" kind of browser)

and @Skulhhead1924 thanks <3

Another update: I got a report that on PocketCHIP, when using BBS, the "communication error" shows up everytime, but after carts are manually saved and run locally, the problem doesn't appear. This is with the current method using pokes to 0x4300+, so this feels like it could lead somewhere.