Questions about DSB/ESB

[Sophia]

Unfortunately it seems like it was not.

[Gambit37]

OK, no worries.

[Gambit37]

Upon further consideration, might I request the addition of two new functions: dsb_sleep() and dsb_save() which would invoke the standard sleep function and save game system dialog respectively.

Enabling these two missing functions would allow for truly flexible and non-DM type interfaces in DSB. It's very restrictive only being able to use these functions through buttons that only show up within the inventory. I appreciate you might have all but abandoned DSB by now, but I'm still plugging away at a long term project using it and these functions would really, really help... pretty please?

[Sophia]

I wouldn't necessarily say "abandoned" but I'll certainly admit that I haven't been able to work on DSB lately.

After the new year I should be able to get back to DSB and I can (finally) get a new version out.

[Gambit37]

Oh my, I hope I didn't come across as demanding, I totally get that hobby projects are low priority with the state of the world as it is. I hope you understand that I only add these requests here to get them out of my head and I have no expectations for any kind of timely response. I hope you're doing OK, my sincere apologies if I was insensitive.

[Gambit37]

To slow a monster's movement, which property should be changed? I've tried fiddling with act_rate, quick_act_rate and quickness of a rockpile, to no avail -- it still seems to move between tiles far too quickly?

[kaypy]

What do you get if you set both act_rate *and* quick_act_rate high? I got a rockpile close to immobile...

As near as I can tell, with the base values a rockpile should be really slow, but if you hit it, then it will use the quick_act_rate which is >10x faster to try to counterattack, and can chase you at that rate for a fair while before it gives up.

[Gambit37]

Ah right, thanks that explains it -- yes it definitely moves a lot faster after I've hit it!

[Sophia]

Just to clarify how all these numbers fit together, for normal monster movement, its act_rate is the number of ticks in between turns. When it has attacked, the attack_delay is also applied. This slows down wasps and the like (early versions of DSB didn't have this, and you got stung to death quite easily!) but it is a large negative number for slow monsters like rock piles, so they get another turn very soon after they attack. The quick_act_rate is applied if the party is standing next to the monster. For rock piles, this means they'll be quite slow unless you're standing next to them or they're attacking. This is all done the same way DM does it as best as I understand how DM works.

(For completeness, quickness is used in the melee combat calculations and doesn't figure in here at all)

[Gambit37]

This is great, thanks for explaining, makes much more sense now!

Another quick question: When using the Magic Map, if you cast a map spell on it, it vanishes very briefly and you can see the default food/water subrenderer instead before the map re-displays with the rune highlighted for the map spell just cast. I know you don't maintain the magic map code, but I was wondering if you might have any insight into why this happens?

[Sophia]

Right, I don't maintain the magic map code, so I really have no idea about how it works.

[Gambit37]

OK, no worries, I think I know what the problem is, hopefully it's a simple fix.

Also, I just checked the start date of this thread -- over 11 years ago.

[Gambit37]

Would a function such as dsb_version() be possible? This could be used to warn players about mismatches between their version of DSB and the version required to play a particular custom dungeon. (This request is born out of re-reading the Surgical Strike thread where it required 0.37 of RTC but players were using 0.49 and getting issues...)

[Sophia]

I could add this, but I don't really like the idea of version-locking a dungeon to a particular version of DSB. I try to maintain backward compatibility and I think I've done pretty well since about 0.60 or so. Being realistic about it, given my rather slow pace of DSB innovation, the biggest changes to DSB going forward are probably just going to be bug fixes. If a dungeon demands a certain version of DSB then players using future versions will miss out on the fixes.

[Gambit37]

OK, that makes sense. I was thinking more along the lines of recent new features not working. If I use a new feature from 0.79 for example, and a player runs the dungeon in 0.78, won't DSB crash the moment that new feature is invoked? So it's not about version locking as such, it's just a check to make sure the player has the minimum version of the engine required to play that dungeon. It seems more polite to test that in the dungeon code and warn about it, rather than just crashing.

[Sophia]

If the dungeon is compiled, DSB will refuse to load a dungeon compiled with a newer version.

[Gambit37]

Ah right, perfect then!

[Gambit37]

Is there a way of changing the mouse cursor on demand? Some kind of dsb_mouse_bitmap()? I was certain something like this existed but can't find anything on the wiki?

Also, is there a way of forcing an animated bitmap to re-start at frame 0 before it's displayed? At the moment, animation timers seem to continue running even when the animation isn't displayed which messes up some effects I'm trying to achieve.

[Sophia]

It does already exist. It's dsb_mouse_override(bmp), and takes the image you want to use. Pass it nil or false to remove the override image.

Where is the animation? If the animated bitmap is associated with an inst, you can use dsb_set_animtimer(inst, timer_val) to reset the timer to 0. Other animations (like for the gui) use a global frame counter.

[Gambit37]

It does already exist. It's dsb_mouse_override(bmp), and takes the image you want to use. Pass it nil or false to remove the override image.

Ah fabulous, thanks. I'll add it to the wiki.

Where is the animation? If the animated bitmap is associated with an inst, you can use dsb_set_animtimer(inst, timer_val) to reset the timer to 0. Other animations (like for the gui) use a global frame counter.

OK, yeah that's a problem, I'm doing some animated stuff in the UI. It's for a fading/flashing effect which completely breaks with a global counter. Ideally there would be a way of resetting the start frame of any animation just before it's displayed.

[Sophia]

How many bitmaps are there?

Giving each bitmap its own frame counter would be sort of a mess, which is why I currently use a global frame counter for things not associated with an object inst. However, as long as you only have a few different instances, or they're going to be synchronized, I could just add a few more global frame counters and let you choose which one you want to use, and reset it to 0.

Altenatively, I could let you associate an object in the dungeon with a bitmap and take its frame counter from there, but that is a little hacky.

[Gambit37]

Only 4 bitmaps in my test sequence which goes 1-2-3-4-3-2. It's a bit clunky so I might need to increase that to smooth it out a bit. The anim needs to start at frame 1 each time it's displayed, otherwise it looks broken.

[Sophia]

Oh, I meant, how many animated bitmaps are you using? In other words, how many independent frame counters do you need?

[Gambit37]

Oh right! Just one for now, but maybe a couple more. Let's say 5 to be safe. Is that possible?

[Sophia]

Quite doable! I'll make it 16 because that's a nice round number and there's plenty of room.

So, DSB 0.80 will no longer have just one but 16 global frame counters. By default every animation will use counter 0 but you'll be able to use the command dsb_bitmap_animtimer(bmp, num) to specify which one to use, and use the already existing dsb_set_animtimer with these new global counters.

If you then set the animated bitmap to use the proper frame counter and set its value to 0 when you first enable your UI element, your animation will always start at the beginning. (Don't set it to 0 when you draw it or you'll set the count to 0 every frame and your bitmap won't seem to animate at all!)

[Gambit37]

Wow, that sounds perfect, thank you very much!

Another quick one: If I'm building a game that doesn't use any DM stuff at all, and I want to start from scratch, can I simply redefine the obj and gfx tables from scratch? Ideally I'd like ESB to only show my new stuff, presumably a redefined obj would enable that? (Plus copying the required triggers/mechanics over).

[Sophia]

It might work, though I will say it's not a "supported" configuration. I know there are some references to default stuff buried in the base code, so you'll probably have to copy some objects over, but I don't know for sure exactly which ones.

[Gambit37]

Cool, I'll try it out and see what happens!

Another question: is there a way of stopping right-click from opening the inventory by default? It would be cool to use right-click to offer alternate actions on the combat buttons, but right now the "open inventory" function always wins.

[Sophia]

What the mouse buttons do is pretty hardcoded at the moment. However, for your specific example, DSB internally supports displaying 16 attack methods per weapon, so if you wanted more than 3, it's just a UI thing.

[Gambit37]

16! Wow I was thinking more along the lines of Grimrock: left click to take the item out of the hand, right click to use it. But I understand that's a big change, and as I don't have an actual use case anyway, don't worry.

Last question for now: You previously added a setting to the gui_info for the resurrect subrenderer: act_like_subrenderer = true. I'm finally getting around to redoing this subrenderer and have no idea what this setting does? Does this enable the ability to code up a whole new subrenderer -- if so, is there a hook for that?