vgstation-coders / vgstation13

Butts
GNU Affero General Public License v3.0
265 stars 545 forks source link

Runtime on jukebox hacking #9143

Open Probe1 opened 8 years ago

Probe1 commented 8 years ago

runtime error: list index out of bounds
proc name: UpdateCut (/datum/wires/jukebox/UpdateCut)
  source file: jukebox.dm,77
  usr: Gregory Atweeke (/mob/living/carbon/human)
  src: /datum/wires/jukebox (/datum/wires/jukebox)
  usr.loc: the plating (172,268,1) (/turf/simulated/floor/plating)
  call stack:
/datum/wires/jukebox (/datum/wires/jukebox): UpdateCut(8, 0)
/datum/wires/jukebox (/datum/wires/jukebox): CutWireIndex(8)
/datum/wires/jukebox (/datum/wires/jukebox): CutWireColour("brown")
/datum/wires/jukebox (/datum/wires/jukebox): Topic("src=\[0x21033fb3];action=1;cut...", /list (/list))
Jorister (/client): Topic("src=\[0x21033fb3];action=1;cut...", /list (/list), /datum/wires/jukebox (/datum/wires/jukebox))
## TESTING: sql_ckey = redun
waiting for redun to have their fingerprint. started: 158470
got redun's fingerprint at 158475 took 0.5s
## TESTING: REdun/redun logged in with age of 517/545/2014-10-29
## TESTING: sql_ckey = carshalash
waiting for carshalash to have their fingerprint. started: 159062
got carshalash's fingerprint at 159068 took 0.6s
## TESTING: Carshalash/carshalash logged in with age of 90/90/2015-12-30
## TESTING: sql_ckey = kavaloosh
waiting for kavaloosh to have their fingerprint. started: 159432
got kavaloosh's fingerprint at 159437 took 0.5s
## TESTING: Kavaloosh/kavaloosh logged in with age of 1816/732/2011-04-09
## TESTING: sql_ckey = xenonia
waiting for xenonia to have their fingerprint. started: 159975
got xenonia's fingerprint at 159980 took 0.5s
## TESTING: Xenonia/xenonia logged in with age of 1331/1047/2012-08-06
23:26:59 Runtime detected
list index out of bounds at jukebox.dm:77
 proc name: UpdateCut (/datum/wires/jukebox/UpdateCut)
  source file: jukebox.dm,77
  usr: Gregory Atweeke (/mob/living/carbon/human)
  src: /datum/wires/jukebox (/datum/wires/jukebox)
  usr.loc: the plating (172,268,1) (/turf/simulated/floor/plating)
  call stack:
/datum/wires/jukebox (/datum/wires/jukebox): UpdateCut(8, 0)
/datum/wires/jukebox (/datum/wires/jukebox): CutWireIndex(8)
/datum/wires/jukebox (/datum/wires/jukebox): CutWireColour("brown")
/datum/wires/jukebox (/datum/wires/jukebox): Topic("src=\[0x21033fb3];action=1;cut...", /list (/list))
Jorister (/client): Topic("src=\[0x21033fb3];action=1;cut...", /list (/list), /datum/wires/jukebox (/datum/wires/jukebox))
Shadowmech88 commented 5 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.

Exxion commented 5 years ago

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)

Shadowmech88 commented 5 years ago

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).

Exxion commented 5 years ago

You're right, there really is no reason for that syntax to work