# .font: font.text_2
2021-11-06 12:17 dustin  
# .font: font.text_1
shit, i accidently deleted this cave (i wanted to delete another cave which was unpublished)! sorry for your solution,  darkstoorm !  
  
not a jubilee this time, but a speciality about the number 200 in bd ;)  
as usual in amoeba cso caves, luck is required in addition to the right strategy!

# .font: font.text_2
2021-11-06 12:18 dustin  
# .font: font.text_1
alright, now i delted the cave i wanted to delete :d

# .font: font.text_2
2021-11-06 12:20 DarkStoorM  
# .font: font.text_1
I thought there was a cave fix :D let's try again!

# .font: font.text_2
2021-11-06 12:27 dustin  
# .font: font.text_1
successful with 7 attempts, yes! :d

# .font: font.text_2
2021-11-06 12:29 dustin  
# .font: font.text_1
i made a quick test cave to be 100 percent sure that the intended solution is the only one. then i wanted to delete the test cave again but i hit the published cave xd

# .font: font.text_2
2021-11-11 15:14 dustin  
# .font: font.text_1
solution free! it's based on the exact amoeba rules (i think they slightly differ from engine to engine so this cave would probably not work the same way elsewhere):  
  
the following amoeba rules for  krissz 's engine are based on experiments and conclusions and might not be entirely precise.  
  
1. each frame during the cavescan, an amoeba counter runs siimultaneousely and also counts newly grown amoebas immediately. as soon as the counter reaches 200, the "overgrown" flag is set and next frame, every amoeba is converted into |.  
  
2. if a | activates a magic wall, the "stop amoeba" flag is set immediately. in this case, the engine does not wait with the conversion until next frame. every amoeba which is scanned after the activating | is immediately converted. this means the conversion can be split over two frames!  
  
3. once the "overgrown" flag is set, it can't be overwritten by the "stop amoeba" flag anymore.  
  
what does this mean for the solution?  
  
if ^ just waits, the amoeby will reach 200 and rule 1 will convert it into |||. so it's clear that the amoeba must be stopped with one of the magic walls, but the amoeba must still reach 200 pieces!  
  
so we have two conditions which seem to contradict each other at first sight:  
  
c1: When the magic wall is activated, the amoeba count must already be 200. this is because of rule 2 - the "stop amoeba" flag is set immediately so no more amoebas can grow after the mwall is activated.  
  
c2: when the magic wall is activated, the amoeba counter must still be below 200. otherwise rule 1 would have set the "overgrown" flag before and rule 3 would not allow an overwriting of this flag.  
  
there is one way to solve the seemingly contradictory conditions c1 and c2: the lower-left magic wall must be used because then the activating | is scanned after the first 190 amoebas but before the last 10. one frame before the activation, the amoeba count is still 199 or less. then in the frame of activation, the last amoeba(s) must grow (this requires luck). now when the activating | is scanned, the amoeba counter is only at 190! so the "stop amoeba" flag is set before the last 10 amoebas are scanned. this way, the amoeba counter never reaches 200! :d

# .font: font.text_2
2021-11-14 10:59 altermaven  
# .font: font.text_1
Clever deduction,  dustin ! my initial understanding was that the scan order using the lower left magic wall took precedence over the amoeba reaching 200.  
  
but i have never accounted for the case that it took a look at everything before the order and seeing "oh, this is 190, it's not 200, so I can convert). it does make for an interesting conundrum regarding that one bizarre exception to the rule.  
  
however, considering how the rng is rolling the moment the cave begins and it depends on other various factors (including system timer!), I do not think this can be employed in a safe manner as a gimmick for any cave...

# .font: font.text_2
2021-11-14 11:07 altermaven  
# .font: font.text_1
there are some other nuances regarding amoeba rng and how it is seeded, but a few of these involve prior actions in a cave set, as well as what has happened during the last scan.  
  
an individual performed a tool-assisted speedrun of c64 boulder dash, and cave G -- where amoeba is trapped -- was the author's biggest headache in regards to constraining the rng to be at the right place at the right time.  
  
to pull it short: the nuances were so broad, he had to write a programme to brute force the ideal scenario where he can establish the requisite \'s that required fully-cooperative amoeba. the author realised that what happened before cave g influenced the rng in cave g, so he essentially had to recreate the scenario involving caves past just so he could get the right rng.  
  
the tl;dr: of this is as such -- amoeba rng is so elaborate, you can't really constrain it to generate two equal scenarios on a whim.

# .font: font.text_2
2021-11-14 12:48 nesdori  
# .font: font.text_1
 altermaven , the rng the original boulder dash uses for boulder pushing and amoebas is based on the cia1 and cia2 timers and the state of the carry flag and there are no other seeds. this is the full assembly code of the bd1 timer based rng:  
  
TimeBasedRandomNumber:  
6ad0   ad 04 dc   LDA Cia1_TimerALo  
6ad3   4d 05 dc   EOR Cia1_TimerAHi  
6ad6   4d 04 dd   EOR Cia2_TimerALo  
6ad9   6d 05 dd   ADC Cia2_TimerAHi  
6adc   4d 06 dd   EOR Cia2_TimerBLo  
6adf   4d 07 dd   EOR Cia2_TimerBHi  
6ae2   60         RTS  
  
so everything the user does since he/she turns the computer on affects the state of the cia timers. even before loading and running the game. it's indeed is possible to do tool assisted run with an emulator where you can control the amoeba to some extent. each scan takes different amount of time depending on what objects there are on the cave and playing sounds and scrolling also of course affects the timing. it's very hard to plan the actions beforehand to get a certain amoeba growth result because you have to do cycle exact analysis of boulder dash engine and c64 hardware workings. but it's possible to just try actions by brute force until you are satisfied with the amoeba growth. i think this is what the player you mentioned did.

# .font: font.text_2
2021-11-14 21:10 altermaven  
# .font: font.text_1
Hm, that's very enlightening! having that knowledge will most certainly allow the person to commit the tas. what I was referring to is that it's not realistically ideal to coerce a situation where two rng moments can happen at the same time (unless, of course, you have emulation, which in this case the timers and memory values are preserved in a freeze-frame, but that's not realistic now, is it?)

# .font: font.text_2
2021-11-19 18:35 dustin  
# .font: font.text_1
oh, i should definitely check the "last commented caves" database more often. i have a feeling that i thought this a few times already :d  
  
just watched the bd1 l5 tas on youtube. great fun! :d