Questions about DSB/ESB

[Sophia]

Yes, dsb_get_alt_wallset.

Code: Select all

local ws_name = dsb_get_alt_wallset(lev, x, y, tile)

[Gambit37]

Ah amazing, thanks! It's not in the wiki, so I'll add it in.

[Gambit37]

Is it possible to have THINGS remain on the ground when clicked, rather than pop into the mouse cursor/leader's hand? It would be nice to add details and decorations this way, and maybe have the player inspect them by clicking, but leave them in place.

[Sophia]

If you return true from the arch's on_click function, then DSB won't allow the item to be picked up. This may work for you, but remember that to DSB it's still an item, so it'll still activate triggers, get grabbed by teleporters, and other things you may not want a decoration to do.

[Gambit37]

Aha, cool! Lots of possibilities. Related: can objzones be used for example in sys_render_other, and placed arbitrarily? I had a quick attempt and got a container's contents to display over the dungeon view but couldn't interact with them.

[Sophia]

That isn't how they're "supposed" to work so your mileage may vary.

[Gambit37]

Ok. Since it doesn't work, I'll take that as a no.

Although this capability would open up so many possibilities for non DM style interfaces.

[Gambit37]

So... one thing led to another and I'm now trying to construct an interface to immobile chests... I can display the items and pop one out into the mouse hand, but I'm totally stuck when it comes to handling what happens if there's already an item in the mouse hand. I looked at the "place_into_containers" and related functions but didn't really understand them.

Is there a good example of how to swap an item in the mouse hand with one at a specific location in a chest?

This is what I've got so far, more or less:

Code: Select all

xmin = gui_info.openchest.x
xmax = gui_info.openchest.x + gui_info.openchest.w
ymin = gui_info.openchest.y
ymax = gui_info.openchest.y + gui_info.openchest.h

[.. SOME FIND ARCH CODE ..]

if (arch.name == "CHEST") then
	use_exvar(v)
	if exvar[v].open then

		local gap = 2
		local chest_contents = dsb_fetch(IN_OBJ, v, -1, TABLE)

		-- Draw the 8 slots
		for x=1, 8 do
			local r  = x-1
			local rx = 34*(r % 4) + gap
			local ry = 34*(math.floor(r / 4)) + gap
			dsb_bitmap_rect(bmp, rx, ry, rx+31, ry+31, color.black, true)
		end

		-- If there are contents, draw the icons and respond to
		-- mouseclicks at the correct coordinates
		if (chest_contents) then
			for x=1, #(chest_contents) do
				local item = chest_contents[x]
				local r  = x-1
				local rx = 34*((r) % 4) + gap
				local ry = 34*(math.floor((r) / 4)) + gap
				if (mx > rx+xmin and mx < rx+xmin+31 and my > ymin+ry and my < ymin+ry+31) then
					if (leftclick) then
			 			local mouse_obj = dsb_fetch(MOUSE_HAND, 0, 0, 0)
			 			if (mouse_obj) then
			 				-- TODO some clever stuff here :-)
			 			else
							dsb_push_mouse(item)
						end
					end
				end
				local arch = dsb_find_arch(item)
				dsb_bitmap_draw(arch.icon, bmp, rx, ry, false)
			end
		end
	end
end

[Gambit37]

^^ EDIT/UPDATE: Ah, ignore me, I realise that trying to do anything with items already in the mouse hand isn't going to work, because it's all inside an immobile Thing which doesn't respond to clicks if the mouse is already full. I'll have to find another way of doing this, probably with flooritems that store/release objects when clicked.

[Sophia]

Objzone clickzones in the main viewport have a couple of significant problems due to the way DSB handles clickzones.

DSB creates all of the necessary clickzones for the game's UI, and also creates big "meta-clickzones" for any UI elements rendered by Lua. The Lua code (either the base code or code provided by the dungeon designer) then creates objzones and msgzones within those UI elements, which handles a wide variety of tasks in DSB.

Normally, this all works fine, but when you have a user-designed UI element overlaying the game's viewport, some problems sneak in. The various viewport clickzones are given priority over your UI elements-- and this is normally good, because otherwise you couldn't pick up items or push buttons when you had a UI element overlaying the viewport. However, this also means that any time you have an objzone (or a msgzone) within a viewport clickzone, the viewport clickzone will take priority. For example, any objzones within the "throwing" area of the UI won't be able to take objects, as they will always be thrown. (There was also a crash that happened sometimes, but I did fix that for 0.79, for whatever that's worth!)

The other problem is DSB isn't really designed to handle overlaying UI elements over each other and you have multiple UI elements all overlaying the viewport. The click only goes to the first one in the list. Though it won't entirely fix your issues, I'd recommend simplifying this all down to one viewport overlay anyway, as the net effect is the same and it will make rendering a bit faster.

Anyway, beyond the technical problems, to me the main gameplay issue with an immobile chest is that it's basically moving inventory interaction to the main view, which creates some UX problems because that is not where it usually happens. You can't directly pull items from the inventory and put them into the chest, like you can on the inventory view, and you also can't really pull items of the chest and put them into the inventory, except into the hands or the automatic "put away" sorting you get by clicking on the character. So I'm happy to help sort out a solution to make DSB do what you're trying to do, but I'm also not sure if what you're trying to do is really what you should be doing.

I should also add, if you're messing around with clickzones, you may know this already but you can add "Debug = 1" to the "[Settings]" section of dsb.ini and the borders of clickzones will be drawn.

[Prince of Elves]

Just nudging in here a bit, but that one sparked my interest:

Anyway, beyond the technical problems, to me the main gameplay issue with an immobile chest is that it's basically moving inventory interaction to the main view, which creates some UX problems because that is not where it usually happens. You can't directly pull items from the inventory and put them into the chest, like you can on the inventory view, and you also can't really pull items of the chest and put them into the inventory, except into the hands or the automatic "put away" sorting you get by clicking on the character.

So if opening the immobile chest makes it somehow look like opening an ordinary one would (i.e. forcing open character inventory) everything should be fine? Would be a bit weird I guess, but if nothing else works that might be a solution (if it's even possible that way, of course)

[Gambit37]

Thanks for the explanation about objzones, that all makes sense. I'm not sure my solution falls into that though, as I'm only responding to global screen mouse movements and clicks using dsb_mouse_state() within a sys_render_other() gui zone...? These always work over the viewport (although they obviously have some inherent issues too).

The other problem is DSB isn't really designed to handle overlaying UI elements over each other and you have multiple UI elements all overlaying the viewport. The click only goes to the first one in the list. Though it won't entirely fix your issues, I'd recommend simplifying this all down to one viewport overlay anyway, as the net effect is the same and it will make rendering a bit faster.

In my solution, I'm only drawing a tiny area just above the chest, to display 8 icons max. There aren't multiple UI elements, it's all very discrete. The only reason it doesn't fully work is that I can't put items back into an immobile chest that's a Thing, because the on_click handler for the thing obviously doesn't respond to clicks when something is already in the mouse hand. I can display and interact with the 8 items inside the chest no problem (although everything rearranges each time an item is removed, which is a bit weird). Yes, there's no simple way to then get the items into the backpack, the player still needs to pop open an inventory, but rightclick as a shortcut for that makes it fairly painless IMO.

I also tried it with a floorupright, but there's something very weird about where I can click on these to get them to respond. Seems like only half the item is clickable. Perhaps floorflats are better?

Anyway, beyond the technical problems, to me the main gameplay issue with an immobile chest is that it's basically moving inventory interaction to the main view, which creates some UX problems because that is not where it usually happens.

Maybe, maybe not. I think all these different approaches are valid, depending on the gameplay style required.

I'm happy to help sort out a solution to make DSB do what you're trying to do, but I'm also not sure if what you're trying to do is really what you should be doing.

Cool, thanks. Basically I was looking at a gameplay variation: "No hoarding" - players can get things from chests, but shouldn't be able to carry the chests themselves, or lift them, or throw them. The no-fit-inventory arch property was initially adequate for preventing backpack carrying, but the player can still walk around with the chest in hand or in the mouse cursor, so it's not a full solution... which leads nicely into....

So if opening the immobile chest makes it somehow look like opening an ordinary one would (i.e. forcing open character inventory) everything should be fine? Would be a bit weird I guess, but if nothing else works that might be a solution (if it's even possible that way, of course)

I had thought the same thing -- if there's a sane way of opening inventory view when clicking on an immobile chest (as a Thing), that might work? Otherwise, what other things could be done to prevent the player from placing the chest in hand or the cursor, and still look inside it to get at the contents?

Another alternative is to do it the Lands of Lore way: don't show what's in the chest, and each click on it removes an item into the mouse hand. Clicking again puts it back. But that's basically some kind of lottery and not really the DM way.

[Sophia]

There aren't multiple UI elements, it's all very discrete.

I was talking specifically about objzones, and how you have gui_info.stats, gui_info.inventory, gui_info.poisoned, and gui_info.dungeon_overlay all defined and taking up the same space on the screen. Only one of these will receive clicks via the clickzone system, and if your objzone is in the "wrong" one, it won't ever work.

That said, if you're directly reading the mouse state, that's different. Click events won't be queued, which may or may not cause any sort of problems, but you're right that you won't run into any problems with clickzones. I haven't actually experimented with doing it this way!

everything rearranges each time an item is removed, which is a bit weird

You're using dsb_fetch to grab the chest contents, right? The table returned by dsb_fetch leaves out empty spaces.

I also tried it with a floorupright, but there's something very weird about where I can click on these to get them to respond. Seems like only half the item is clickable. Perhaps floorflats are better?

This seems odd too. I'd be curious to see a screenshot of what the clickzone actually looked like (using debug mode as mentioned above), I recall RTC has a bug where the clickzones were getting "offset" and maybe DSB is doing something similar...

if there's a sane way of opening inventory view when clicking on an immobile chest (as a Thing), that might work?

This would be a bit messy, because DSB is sort of hardcoded to expect anything you're basing a subrenderer on (like a chest) to be in hand, while if you're clicking on an immobile chest, then it isn't going to be in a character's inventory at all. There are ways around it, of course, but it involves hijacking the system renderers and it's just not going to be a whole lot of fun. So... perhaps not a sane way.

What I'd recommend doing is just making the chest extremely heavy, combined with making it not allowed to go into the inventory. You can pick it up and look at it, using the limitations of the DM UI, but trying to carry it around will make it almost impossible to move and of course you can't throw it. This does mean you can move it, slowly, but a big heavy chest could be shoved around, so maybe that's not that big of a deal. It would certainly make it impractical to carry a backpack full of chests.

[Gambit37]

Here's the click zone debug info when using chests defined as flooruprights. I've coloured in pink the area that I can click on. The arch only has front, side and same_square images defined, and I place in the corner of the tile, not the center. Notice that it seems fine when it's in the square in front of the party, but not when it's on the same square. (The red square is my gui_info bitmap, it gets chest contents drawn onto it when the player is facing the same direction as an open chest -- I still need to tweak that so it works in all directions)

What I'd recommend doing is just making the chest extremely heavy, combined with making it not allowed to go into the inventory. You can pick it up and look at it, using the limitations of the DM UI, but trying to carry it around will make it almost impossible to move and of course you can't throw it. This does mean you can move it, slowly, but a big heavy chest could be shoved around, so maybe that's not that big of a deal. It would certainly make it impractical to carry a backpack full of chests.

Yep, this was one of my first solutions. It just felt a bit inelegant though and I was looking for something a bit more slick, but I seem to have gone down a rabbit hole of much too complexity...!

I also tried using LOCK_MOVEMENT when the chest was in the player's hand, which does work, but it's really disorienting for the player unless I provide some other feedback, such as text saying "You can't move, the chest is too heavy." Maybe that's OK, but it felt a bit mean and not really in the spirit of DM.

I'll probably do the super-heavy chest solution as you suggest, it seems simplest all round and fits in with the DM UI/UX paradigm.

[Gambit37]

^^ Further to the above, I tried a heavy chest and it's still possible for characters to launch them several sub-tiles, even when set to 500Kg! Of course all their stamina and health depletes and they die (so maybe that's a fair penalty, perhaps they broke their back trying!), but I'd like to avoid it moving at all if possible.

I looked at the crazy axe demo, and could set the flytimer of a chest's on_fly event to 0, but it still travelled one sub-tile.

Maybe there is something that can be done with delta values? Looking back in this thread you added get/set delta functions years ago, but there's no info about how to use those on the wiki.

I'm thinking some combo of zero delta and zero flytimer might prevent the chest from moving at all, but I can't quite get there with my current knowledge.

[Gambit37]

Also, the party can still rush around at no penalty if a chest is in the mouse cursor regardless of how heavy it is.

[Gambit37]

^^ Ooops, sorry, disregard that comment, I got that bit wrong -- heavy chests do impact the leader's walking speed.

[Sophia]

Ok, I see what's going on. Standard DSB doesn't respond to a clickable flooritem in the same tile as the party, because that normally just never happens, so the click is always just sent to the standard clickzone for dropping items on the floor instead. If you click the flooritem outside of that zone, it'll still respond.

I see what you're doing with the chest interface and I'll mess around a bit with objzones. I'm not going to promise anything but I may have a possible solution.

heavy chests do impact the leader's walking speed

Sonja or Azizi always seemed quick enough to me!

... right. Not like you weren't thinking it.

[Gambit37]

I see what you're doing with the chest interface and I'll mess around a bit with objzones. I'm not going to promise anything but I may have a possible solution.

Oooh, awesome. Please don't go out of your way on it though, it's just a nice-to-have.

Sonja or Azizi always seemed quick enough to me!... right. Not like you weren't thinking it.

I really wasn't, but now I can't not!

[Sophia]

Solved it! In DSB 0.79+, if you return true from sys_render_other, then the currently rendered UI bitmap will be given top priority for that frame, which will allow objzones on that bitmap to work even if it's overlaying a dungeon clickzone. That should allow your objzone-based pop up chest interface to work. All you have to do to go back to normal is just not return true the next time the function runs.

So you'd probably want something like:

Code: Select all

function sys_render_other(bmp, gui_name, frozen)
  if (gui_name == "myobjzone_bmp") then
     local draw_objzones = -- figure out if objzones should be drawn --
     if (draw_objzones) then
        dsb_objzone(--whatever--)
        return true
     end
  end
end

[Gambit37]

Oh my! That sounds fantastic, thank you so much! You're amazing!

[Gambit37]

Is there a way of accessing the system date/time in DSB Lua?
Related, is there a way of timing how long a player takes to complete a game?

[Sophia]

No, not really. In standard Lua you'd use os.date or os.time but DSB doesn't enable the OS or IO libraries for security reasons.

[Gambit37]

OK, no worries thanks.

I think I might have found a bug in ESB: sometimes when I cut and paste Things that contain other Things, ESB either (a) crashes or (b) it pastes the Thing, but the contents are removed.

[Sophia]

I can't reproduce that. What exactly were you doing? What error is produced when it crashes?

[Gambit37]

I'm sure I already know the answer to this, but is there a way of providing bitmaps for the scaled views of creatures, rather than having the engine do it dynamically? When working in 2x pixels, creatures end up looking quite funky when scaled and don't really match the rest of the nice 2x pixel art.

[kaypy]

Going by objectsdata.c/~line1497 it certainly doesn't look like it.

https://github.com/sparkletwist/DSB/blo ... ectsdata.c

A bunch of object types allow eg front_med and front_far graphics variants, but not monsters...

Looks to me like the monster rendering code (render.c/~line1098) also specifically assumes no distance variants, so I'm guessing it also wouldn't be as simple as adding the other o_ptr-><orientation>view[n] entries...

[Gambit37]

Cool, thanks, yeah that's what I thought.

[Sophia]

Both of those statements are (unfortunately) correct!

[Gambit37]

How do I send the party to sleep?

You can't.
I honestly couldn't think of any time when this would be needed.

Is there a way of moving the zZZ button out of the inventory and into the main interface area, so it's always available?

Oh, I get it now.
Not at the moment. I'll look into this, too!

Was this ever implemented?