Dungeon Master Forum

Don't forget about the wiki too. I added a lot of stuff to it over the years: https://dmwiki.atomas.com/wiki/DSB

ebeneezergude wrote: Sun Jan 19, 2025 11:40 pm Really sorry, I can't work out how to implement this dsb_qswap / qswapper... I've read the wiki, but I don't understand it and how to implement it. Could you spell it out if possible? Much appreciated.

Add a qswapper (FloorFlats/MECHANICS/qswapper) somewhere
Right click the qswapper, set its swap arch to whatever button type you want to swap to, and make it target the button
Have the button activate the qswapper with a delay of however long you want the button to stay pressed

Oh, if you're used to RTC, you might not know that DSB allows every target of a button to have its own different message and delay, which makes this kind of stuff a lot easier.

ebeneezergude wrote: Mon Jan 20, 2025 12:23 am And I meant to add one more: how can I click on a wallitem (or on a wall), and have it generate text at the bottom of the game screen? Essentially, like

Floor text is just a call to dsb_write, so you can just do this in code and run that code with a function_caller. This is actually probably better than embedding it in the dungeon because you can use localized text.

Thanks Sophia (and Gambit). I have got the qswapper working well, and the switch effect working as intended - apologies I missed that this was a floor mechanic.

Regarding the dsb_write, I can't seem to make this work. Do I trigger it in the Exvar box of the Wallitem via an Opby? I've tried various ways of entering the code as I thought might be correct, but it's not working. Am assuming it's an OpBy 'click' method, but entering dsb_write_ = "TEXT" doesn't seem to do anything. (Apologies, I am not a very good 'programmer' type... ) I have researched the localised text feature also, but can't make this work either. Have reviewed the base local.txt and this forum post: viewtopic.php?p=159450&hilit=localized+text#p159450

You'd need to write a small function in Lua that can accept a "text" exvar from the dungeon and then push that text into dsb_write() (or if you're using localised text, you'd push the label of the localised text item to display). Then in the ESB, you use a function_caller to link the name of your Lua function as the thing to activate when the button is pressed. (This is from memory, I don't have access to any of my DSB right now and I've not touched it for a couple of years, but I think that's the principle of it anyway.) Hope that helps!

Thank you Gambit. I can sort make this work now using a function_caller object in ESB. I have a WallItem that when clicked, activates the function_caller. The function caller is set to 'Activate' my new function code (in the What's Your Function' window) and this runs a small function description in the Startup.lua. This is the function code in the Startup.lua:
I have tried to integrate the dsb_locstr feature.

My localtext.txt has this code in it: The problem is: what I can't figure out is how to get this particular function call to point at the TEXT_B code. I think I need to replace the "TEXT_A" in my 'dsb_write({111,111,200}, dsb_locstr("TEXT_A"))' line with something that is passed to it by the function caller that says 'use TEXT_B' (or, C, D, E, etc), but I don't know how. I know having "TEXT_A" written here is incorrect, I don't know what to replace it with though.

I am assuming I'd have multiple function caller objects in the dungeon, and each one could have a unique pointer to each line in the Localtext.txt file (Ie, TEXT_A, TEXT_B, TEXT_C, etc). I am also assuming I only have one function required to display these mutliple messages.

Basically I have set up wall mounted stone tablets in the dungeon, and want each one to display a unique text when clicked.

Does this make sense? Any help much appreciated!

Don't hardcode the text into the function, instead add a new exvar in the trigger item in ESB which specifies which string to use from your local text file. So your exvar for the trigger would be something like:
Then your function would look more like this:
This is totally from memory and probably full of errors but hopefully will put you on the right track.

By the way, I'd recommend setting up some keywords for your dsb_write colours and using those instead. It's much easier if you decided to tweak the colours later.

Wow, that works Thanks Gambit, you're a star. That's some memory...! I think I've learned how exvars and IDs work a bit better now also - that's exactly what I meant be "passing on" the information, I just didn't understand how. Now I do (I think..!)

Will look into the keywords thing, thanks.

So right now in DSB I've basically been able to establish all the main items and workflows to port this project over, except for the full graphic UI - this needs work - from what I've read (I can't do an actual full graphic like RTC does as in my video). A few teething issues with some monsters not appearing on the tiles correctly, but I'll look to rectify those.

Now that I understand better how it works and the workflows, DSB just feels a whole lot better than RTC.

I'm glad you were able to solve this. I found the whole process a bit inelegant though, so in the newly released DSB 0.83 you can just send a "Next Tick" message to a floortext and it'll display its text.

A floortext can either use a "text" exvar to specify text directly, or (also newly added in 0.83) a "locstr" exvar to specify a localized string.

Ah that's cool, thanks for the improvement Sophia, very nice.

The issue with the new monsters I've created is: When using a 2 or 4 per square, the monster that is on the front spot of the square appears fine, but when it's on the back line, or middle spot, it appears too high up, and breaks the illusion of perspective. Is there any way to control this?

Also, while I'm asking about monsters, what are the different Group_Type categories, and how do I know how to use them, what they mean, etc? GT_WORMS, GT_BLUE_CLUB, GT_SLIMES, etc.

Thanks as always

I don't know what you mean by "too high up." A screenshot might help.

Anyway, the group_type controls which types of monsters are allowed to form a group together. Normally monsters can only group with their exact same archetype but this lets DM monsters and their (mechanically) identical CSB variants form monster groups together. So unless you're doing something similar it's not something you have to worry about.

Hi Sophia, yes of course, a screenshot may well help to explain. So I am testing out a monster, it is a copy of the Trolin (not a clone). The new monster is set to be able to have 4 per square.

Here is the Trolin, 4 per square. The rear two are slightly higher:


Here is the test monster, 2 per tile:


Here is the test monster, 4 per tile, and a couple of odd things happening:
A) One monster is side on, maybe on the middle of the tile? ...looking to the left. Height position is consistent, but is not "behind" the front two - should he be?
B) The monster at the rear is very high. Whilst the rear Trolins in the first shot are higher - I assume this is a deliberate effect to visually separate the monsters and make them more "presentable" in the game window - the custom monster is measurably higher than the Trolin is higher. Not sure why this would be?


Ultimatey I think this size of cusotm monster might be too mayny for a 4 per square anyhow, and I'll set it to 2 per square. But, they're only a little bit taller in the Y pixel dimension (174px high) than the Trolin (166px high).

C) It looks like the custom gfx may need and adjustment somehow, or an offset applied. Can I apply a standard offset in this instance for the "rear" position only?
D) What rules govern how monsters appear on the tile. Can They be told not to inhabit the centre of the tile, only the four corners?

Many thanks!

PS - E) Side question: Can I ask DSB to draw the monster in front of the side wall? Or do I need to edit the graphic to be narrower? You can see the axe head is occluded / slightly behind the side wall for the custom monster in the third image

Overall I'd say that image is too big for a four-per-tile enemy. As you've noticed, when you start going beyond DMs fairly boxy creatures, you can see why they kept the deisgns simple. Wider creatures don't really work. If you want to keep that creature, I'd make it just one per tile and place it in the center: most of the issues you've raised will disappear then.

It looks like you're experiencing a lot of the stuff I went through when trying to make a higher-res DM. In the end, much of what I wanted to do just didn't work within the limits of the basic engine and I had to simplify everything.

Yes I think you're right about the size on that one. I am experimenting with reducing the res slightly anyway on the art style, but was just curious on the way the 'placement' mechanics work for the groups of monsters. Did you ever release your project? Your images look fab.

I've had three projects in the works for DSB but never released anything! However the screenshots I showed earlier are for the third of those projects which will hopefully be finished and released one day... I don't have the time nor energy to work on it currently, but I hope to get back to it later this year.

Gambit is right. There are some graphics that... just don't work with the DM renderer, unfortunately. The perspective is kind of wonky and it's less flexible than it appears at first glance.

ebeneezergude wrote: Tue Jan 21, 2025 10:43 amIt looks like the custom gfx may need and adjustment somehow, or an offset applied. Can I apply a standard offset in this instance for the "rear" position only?

No, offsets have to be applied to all tile positions.

ebeneezergude wrote: Tue Jan 21, 2025 10:43 amWhat rules govern how monsters appear on the tile. Can They be told not to inhabit the centre of the tile, only the four corners?

Size 1 monsters (mummies, trolins, etc.) can be at all four corners or the center.
Size 2 monsters (worms, rats) can occupy the "front" corners, depending on the direction they're facing, or the center.
Size 4 monsters (dragon) can only occupy the center of the tile.

There is no way to tell a monster not to occupy the center of the tile, as that is the only "safe" place that any monster can be.

ebeneezergude wrote: Tue Jan 21, 2025 10:43 amCan I ask DSB to draw the monster in front of the side wall? Or do I need to edit the graphic to be narrower? You can see the axe head is occluded / slightly behind the side wall for the custom monster in the third image

No. DSB is actually rendering it correctly in this case, because the the monster group is in the square beyond that wall, so anything in that square would be covered up by the wall. So in this case the axe head is rightly rendered as being behind the corner. Of course, it would look stuck in the wall had the monster been mirrored, but that goes back to what Gambit said: those graphics might just be too wide and some graphics just don't work very well.

Yes, understood, thanks both. I'll adjust these graphics accordingly. I made them small and limited to 2 (or 1) per tile and this works a lot better already.

Concerning that wierd group of four: I've seen that behaviour in worms too and I vaguely remember reading somewhere that it's because monster groups can split up or join. So if half of them decide to walk out to the side they rotate weirdly on top of the rest.

Yes, you're right. I seem to get that with 2 monsters per tile also, so it seems the "issue" isn't aabout 4 monsters per tile. It's when one of them inhabits the centre spot on the tile, it seems to move up and potentially look a little larger. Is there a way to stop them joining up?

Monsters shouldn't be in the center of the tile unless the rest of the tile is empty. I assumed you just dropped them down weirdly in the editor, but if this is happening as a result of play, then I would appreciate instructions how to reproduce the situation because this is a bug.

Having compared my custom monster to the base DM Trolin monster, actually I think DSB is doing it right. It's just a combo of the vertical offset the monster at the rear has (due to the base DM / DSB mechanics), and most possibly, that the custom graphics I am using pushes the centre of the bitmap further left than the base DM monster, as it's a wider graphic, making it appear more central on the tile.

When you say "dropped them down wierdly", what do you mean by that? AM adding them normally - I think! Thanks.

Question on Food Drop. How does one control this variable and how much food is dropped? I can see this function in the base monster.lua, but I don't quite follow it.
Many thanks!

ebeneezergude wrote: Wed Jan 22, 2025 2:49 pm When you say "dropped them down wierdly", what do you mean by that?

ESB doesn't forbid you from placing a monster on a corner on the tile and placing a second monster on the center of the tile, so if you place them like that in the editor, it will show up like that in the game. However, that's "weird" because that situation doesn't (or at least shouldn't!) arise in normal play.

ebeneezergude wrote: Wed Jan 22, 2025 5:51 pm Question on Food Drop. How does one control this variable and how much food is dropped? I can see this function in the base monster.lua, but I don't quite follow it.

Take a look at an edible monster in objects.lua, like obj.screamer for an example of how to use it.

Thanks Sophia. I can see the and the and used this successfully in some custom monsters, I just don't understand how it's controlled. Ie, can it be a random number of food drops between values x and y, or, always x number of drops, or, sometimes none. Sorry I didn't ask the question properly the first time round..!

Ah, I see now. The food_type property is the archetype that is actually dropped. It doesn't even have to actually be food, it can drop any object. You can use the properties min_food and max_food to specify the values; if you want "sometimes none" you can set min_food to 0.

When a monster dies, its on_die function is called, which is setup_food_drop in this case. This places the food into the monster's inventory. Then the engine deletes the monster instance and drops its inventory onto the floor, so the food is dropped.

Ah, got it, thanks, all makes sense. That's all working well now.

A graphics offset question if I may! I made a new wallitem, a decoration (a wall grate, essentially). I have the object working, I have adusted the graphic for it's Front position to sit in the correct position at the base of the wall. When I step back one square (to the "front_med" position, as it were), the graphic appears misaligned to the floor (too low). DSB is apparently using the 'Front' graphic and scaling it, and repositioning it for the intermediate front_med position.

My question is: can I add an .y_off = offset for it's _Med position, without having to create a new bitmap referenced in a 'front_med=gfx...' in the object entry? Can I just offset the scaled/repositioned _Med render of the bitmap that DSB automatically does?

This is the 'Front' bitmap:


This is the '_Med' position, using the Front bitmap. You can see it's dropped too low:


Hope that makes sense? Many thanks.

Yeah, if I recall you can add offsets for all views without needing extra graphics for each view. That said, you do get a better result if you prescale the extra views in your graphics program and use those images instead. DSB doesn't do a great job of scaling and stuff can end up looking a bit scratchy at the med and far views (due to DSBs renderer just throwing away random "un-needed" pixels, rather than interpolating using something like a bililear filter).

Ok thanks Gambit. I’ll have a hunt around to see how to do this. It’s probably been discussed here somewhere.

Another way might be to clone the DM grating object, and make the custom graphic bitmaps match that in terms of pixel dimensions.

Ah, think it might be this:
.mid_y_tweak = x

Will check in ESB tomorrow.