Dungeon Master Forum

I think the "key object" in the "surrender your possessions" pit should be randomized from a list of common objects. It'd bring back some of the insidious cleverness of the thing that is probably lost nowadays. Not that CSB experts would ever fall in there, anyway.

Hmm, maybe there should be some randomized teleporters that drop you in there from other pits.

Sophia wrote:not ..a random element, ...solving a known puzzle ...unexpected outcome

No reason such things could not be randomized.

There are lots of possibilities for mixing up the
cause-and-effect in many puzzles.

I want to make the standard Giggler randomizers
more deterministic....So that given CSB #2319, for
example, the keys and such will always appear in
the same place. In other words, do the randomizing
during initialization.

Paul Stevens wrote:In other words, do the randomizing during initialization.

In my "teleporting apples"-world, you could to that with a single initialized level, a large room where pressure pads appear or not, depending on the generated code. It's quite easy to make an algorithm for that, binary numbers will do the trick (pad there/not there) and you can convert that to a decimal number to make it readable. Now you teleport an apple around the room to activate all the pressure pads (which are there). That only makes yes/no choices, but you can combine several pads for more options.

Advantage of this method: It's visual and so even I could make use of it, since it would be operateable through the GUI of the editor.

PS: the apple is optional.

You could have a set of phrases/enigmas for each item and generate alcove + wallwriting triggers randomly.
I thought about that to enrich the "Chaos Hack" random dungeon generator.

Sorry about DM and CSB not being exact copies of the originals. They are indeed machine copies of RTC, with some quick fixes done in ESB.
I never went further than test it as "similar & playable" because CSB contains a lot of details and very delicate mechanisms
which would have taken me a long time to understand and render correctly.

I guess if you do make a converter from CSBWin to DSB, DSB Conflux is not far away

By the way, the main difference between DSB/CSB and vanilla is the absence of the Prison Load/Save party mechanism. I don't know if it's easily doable in DSB.

The Prison Load/Save was done to get around
limitations of the 512ST. I don't consider it an
important part of CSB.

Sorry about DM and CSB not being exact copies of the originals

No reason to be sorry. This is all a process of
successive approximations. Yours was the first
approximation and served very well in getting
the necessary DSB mechanics tested. It just
happens that I am being very particular in my
desire for exactness. Therefore, a second
approximation that is going rather smoothly
because of all the previous work, in both DSB
and in CSBuild.

You could have a set of phrases/enigmas for each item and generate alcove + wallwriting triggers randomly.
I thought about that to enrich the "Chaos Hack" random dungeon generator.

+1
I thought about some tags to identify changes from the original CSB. A special ( Paul Stevens ) demon face for instance.
So that players know, it is not an error, it is an intentional hack.

Do you plan to complement oracle hints ?

Custom graphics is beyond my capability.

Do you plan to complement oracle hints ?

No. If it were possible, it would be a nice thing
to do. Some sorts of random changes to the
dungeon might require changes to the hints, might
they not? That would be difficult to pull off.

DSB CSB is coming along nicely. Pretty much everything but actuators import perfectly.
(Of course, the actuators are the meat of the thing, so that means there is still a lot of work to do. But it's getting there...)

So, here's an interesting question to ponder. Should I duplicate CSB's bugs, too?

I noticed that teleporters in CSBwin will not teleport something that just got launched from a shooter. This is different from DSB's normal behavior. I don't think it matters terribly much-- however, it seems like at some point FTL did intend to teleport shot missiles immediately, or, at least, some CSB designer thought they ought to, because the "item randomization machine" has a teleporter straight out of the shooter that actually goes somewhere. With the current CSB mechanics, this teleporter won't ever actually work in CSB (or CSBwin) though. It's confirmed that it doesn't work by the fact that there is no "Random Item" entry in the CSB guidebook for its destination, unlike all the other teleporters in that hallway.

(An interesting side note: it breaks the Ful Ya pit sequence if missiles do get instantly teleported, because the corbum-grabbing teleporter will take away the des ew spells meant to instantly kill the black flame that gets teleported in. That particular situation is easy to fix in DSB, though, so its existence shouldn't figure into the decision of whether to keep the bug intact.)

CSBwin will not teleport something that just got launched from a shooter

Why? Do you know? I have no idea.

The shooter is triggered at time 0. The
teleporter is turned on at time 0 and off at
time 1. Does the object remain inside the
shooter for one tick, perhaps, making its
way into the world at time 1 so that the
first step is not a special case?

In any case, the shooter/teleporter timing
seems very critical.

Paul Stevens wrote:Why? Do you know?

LaunchMissile directly calls AddObjectToRoom. All interaction with teleporters and such is done in MoveObject, which only gets called once the missile has actually moved one square.

What I don't know is whether this was intentional or just an oversight.

OK. Then the first 'MoveObject' happens at
time 1 and the teleporter is turned off at time 1.
Therefore, it is not designed to work reliably because
there was no (I added it later) provision for
first-come/first-serve). The teleporter should
be disabled at time 2 to ensure success. In fact,
it may have worked in the Atari version....before
I added the first-com/first-serve feature. And it
may have worked 'sometimes' in the Atari version,
depending on the addresses allocated to the timer
queue entries.

All-in-all, I don't consider this a bug in CSBwin.
Especially since it has been updated to ensure
first-come/first-serve. It is a bug in the dungeon
design. Anyone disagree?

Edit......
I disagree.

In the actual CSBwin, the teleporter is set
active, the missile is added, the missile
is moved, then the teleporter is disabled.

The code places the object in the cell
without checking for teleporter.
It should check.

The code moves the 'missile' within the cell without
checking for teleporter....after all - if the teleporter
were active the missile would already be gone.
So I guess this is OK.

Therefore.........the error is that the shooter
should check the cell for a teleporter. But this is
a tough task. The code contains a function to handle
this task and perhaps it could be called when the
shooter places an object in the room. But Sophia
says this will destroy the Ful Ya Pit sequence.

Conclusion: DSB should not incorporate this bug
and I will not try to fix CSBwin but I will try to
add a comment in the shooter code to indicate
that the bug exists.

I wasn't quite clear, I guess. What I meant was that MoveObject only gets called once the missile has moved one entire square. Subtile advancement is handled via direct calls to RemoveObjectFromRoom and AddObjectToRoom within MissileTimer. What this means is that the first teleporter would never work, even if it was turned on constantly, because any check for teleportation doesn't happen until the missile is already gone from that square. For example, at time 1, the missile is placed directly via LaunchMissile; no check for teleporters. At time 2, MissileTimer advances the missile one subtile, without any check for teleporters. At time 3, the missile advances to the next map square, and only then does MoveObject (and the check for teleporters) happen.

Anyway, if we're deciding it's a bug in the dungeon design, then I'll just add an option for DSB to handle missiles like CSB does and the bug will continue to exist in DSB CSB.

Edit:
Or not. You edited while I was posting.

Every time I dive into CSBwin I find something horribly broken in DSB's attempts to simulate its mechanics.

It is enlightening and also a little depressing.

a little depressing

I imagine Michelangelo had his setbacks while
decorating the Sistine Chapel.

I'd agree with you in theory, but I found another puzzle (the flying scroll along Neta) that requires shooters to not check for teleporters. So I've implemented this behavior into DSB and made it optional, off by default, but enabled in DSB CSB.

DSB CSB is shaping up fairly nicely, but I'm noticing the one big drawback to the dungeon being a direct automatic port of FTL CSB is that it is not at all a good teaching tool for examining how various complex mechanics are accomplished-- you can learn a lot about how to build dungeons in CSBuild or in RTC by looking at their versions of CSB, but that won't be true in DSB. It's probably a small price to pay for having a functional and accurate CSB, though.

So I've implemented this behavior into DSB

Would it make sense to have this be a 'Shooter' option
rather than a 'DSB' option? I'd happily add a
"No Instant Teleport" option to all the shooters in
my dump. Then there is no special case for CSB.

Well, to be honest, that's a good idea... had I not already done it the other way. The actual impact between it being a flag applied to shooters it being a global flag is probably not enough to merit ripping all the code up and starting over.

Regardless, you wouldn't have to add anything to your end. I'd just assume that "CSB mode" (whatever that ends up meaning) applied to any dungeon that got automatically converted from a CSBuild dump and automatically set the appropriate flags in my conversion code.

Unlike FTL DM, the whole dungeon in DSB is always "active," whether it was visited or not. This means the gigglers are doing their thing even before you've visited the junction. I had a random item just pop into place while I was fighting the worms before I even left the start.

Duplicating the DM way in DSB would be bothersome, so I'd rather not do that... but if this is something people care about, once the automatic conversion is "finalized" and I start doing hand fixes I could always stick a row of monster blockers in there to keep the gigglers in place until you've been to the junction. Is there anywhere else in the dungeon people might object to the monsters moving before the party has been to that level?

The dragon might generate a ton of worms in the lower levels. There might be other flood triggers like that which could be accidentally triggered?

I remember this flood filled room. I had to hack my way through not giving an inch to this mess of worms.

I just want to add that I very much liked the crowded place( worms everywhere 15-20 pairs?)
Had a real strong party(imported dm-->csb) so around second to forth master level everything with 4 party members.
I guess it is an incentive or challenge for high end party and end game. So maybe unsuited for speedruns or casual / normal play, but good fun for an overpowered party.

So did I. Champions, imported from DM, in the 600+ health.
This mess of respawning worms was mostly boring.

CSBwin appears to have a hard-wired damage of
exactly one (unity....1....uno....multiplicative
identity) when a Poison Bolt strikes the party.
A rather special case in the code. This is particularly
noticeable in the room containing the Flambain where
Poison Bolts are released to race around the room.
The puzzle is extremely easy in CSBwin.

DSB applies the full damage and the same puzzle
becomes a bit more of a challenge. We (Sophia
and I) think it is best to use the more difficult (DSB)
way of applying damage.

Does anyone have an explanation for the CSBwin
way of doing applying Poison Bolt damage? Does
anyone think DSB should adopt CSBwin's way?

Only inflicting one damage applies when a poison bolt strikes anything, actually.
So, this solves the mystery of why des ven seems useless. It is!
(Previously, I always thought it was mostly useless because des ven applies a monster's armor as well as poison resistance. It does, and that will severely reduce damage... but I think this one is what really does it in.)

In the hint book, it says this room contains poison clouds. I wonder if they changed it in a later version.
That would certainly make it a lot tougher: you'd suffer far more damage, and the lack of visibility could make things tricky, too.