Open Probe1 opened 8 years ago
The problem here is that when the JUKE_SHUFFLE
wire is cut, it attempts to set the jukebox's allowed_modes
to list(2 = "Single", 3 = "Once")
. At first I thought the problem was it using numbers instead of the defines, but it turns out BYOND treats them exactly the same. The reason why it breaks in this instance and not for loopModeNames
is because the latter has all three play mode defines, whereas this instance has only two. It turns out BYOND only allows numbers to be used as keys if and only if the numbers follow a 1,2,3, etc progression. Missing JUKEMODE_SHUFFLE
, which is 1
, causes the list to break.
This seems to be an inherent flaw with the jukebox's defines, and I don't know much about the juke code-wise or even in-game, so I'll leave it at that. The way to fix this would probably be to change the defines for the jukebox play modes to something other than numbers and then change the code to support that.
BYOND only allows numbers to be used as keys if and only if the numbers follow a 1,2,3, etc progression.
That's because they're indices, not keys BYOND doesn't allow numbers to be keys at all (Except when it does, but that's a bug)
I guess what I meant is that BYOND only allows numbers to be used in a list(a = b, c = d, e = f)
if the numbers follow a progression.
Indices are implicit for non-associative lists and must always be contiguous and start from 1, so there isn't even a point to allowing numbers to be used in that format of list declaration at all, is there? The final list is no different from a list(b, d, f)
.
You're right, there really is no reason for that syntax to work