Rocks'n'Diamonds

For this level LEVEL CREATOR shows it as having an exit, but even when getting enough EMERALDS the exit doesn't open.

"BOULDER DASH" > "THE BREMER TOWN MUSICUS" >"THREE BOULDER DASH GAMES B"
~/.rocksndiamonds/levels/Boulder_Dash/The_Bremer_Town_Musicus/bd_three_boulder_dash_games_b
Level 19

(Tape was done in a way that gets rid of all the BUTTERFLIES, and removes all visible emeralds, then goes next to exit that was shown in LEVEL CREATOR with a least the number of emeralds need done before times runs out, all on a working tape)

I have checked this case, and you are right -- this level is indeed broken!

What happens is as follows: This is a BD style level in native GDS format (which is a GDash cave file in binary format, contrary to the many BD level files in BDCFF format, which is a text format). It is detected as being in "PLCK" format (which stands for "Peter Liepa Construction Kit" format, which is the game engine of the Boulder Dash Construction Kit, also known as Boulder Dash IV). It is (AFAIK) the only BD engine that in fact uses a mode where the first and last line of the playfield are _not scanned_, which means that all game elements on these two rows are effectively static (and usually consist solely of titan wall AKA steel wall). This also means that a closed exit in the first or last row will _never_ change to an open exit for this special cave format.

I will ask the experts in the Boulder Dash forum if anybody is aware of this (type of) problem, and how a solution might look like. (Which could be just converting the cave set to BDCFF format and then simply manually changing that flag for that level.)

Holger wrote: ↑Tue Jan 07, 2025 6:51 pm I will ask the experts in the Boulder Dash forum if anybody is aware of this (type of) problem, and how a solution might look like. (Which could be just converting the cave set to BDCFF format and then simply manually changing that flag for that level.)

Wonder if originally it was in one format that worked, and then later converted to the format it's currently in.

BryanFRitt wrote: ↑Tue Jan 07, 2025 9:55 pm Wonder if originally it was in one format that worked, and then later converted to the format it's currently in.

That's exactly the case here, yes. The original format was a C64 game, from which it was converted to GDS format, which introduced the problem. (Or, alternatively, the format is OK, but the flag to scan the first and last row is incorrectly set by the GDash GDS file format loader. I will try to find out...)

As far as I was able to find out, this bug apparently already existed in the original C64 version of this level set.

Whatever might have been the true cause for this level being unsolvable, I have now manually fixed it and re-released the BD level collection package. So after updating the level collection from the new zip archive, this level will now be solvable.

Holger wrote: ↑Mon Jan 20, 2025 10:38 pm As far as I was able to find out, this bug apparently already existed in the original C64 version of this level set.

Whatever might have been the true cause for this level being unsolvable, I have now manually fixed it and re-released the BD level collection package. So after updating the level collection from the new zip archive, this level will now be solvable.

Tried out the new Boulder_Dash collection 1.0.4 on Rocks'n'Diamonds 4.4.0.4, and those levels are solvable now. Thanks!

Thank you for your feedback! I'm happy that it works for you now.