Dungeon Master Forum

It's likely a combination of DSB's higher resolution combined with its rendering positions not exactly matching FTL-DM's in every case.

Although I have done a lot of work developing the DSB engine, I haven't had time to develop my own dungeons. Well, that ends here! I will soon be releasing Dungeon Chaos Master Strikes Back, a new adventure for DSB that follows directly after DM and CSB. At the start of this new adventure, people ...

The reason just setting the definition to nil doesn't work is that obj has a metatable that appends every newly created archetype's key to a hidden array as soon as it is created. Iterating over a Lua table has no particular order, so doing it this way ensures that you can iterate over archetypes in ...

I've split these posts off to their own thread, which is how I'd prefer requests to be made. I don't mind hearing them but I'm not going to promise anything.

Well... the actual problem is that your code does nothing because it's wrong.
I haven't actually messed with this stuff in quite a while. I guess I should have double-checked rather than assuming you used the proper syntax. :P

Check obj.pit for the proper structure. Something like this should work ...

Linked objects are generated at the time the dungeon is loaded into DSB. They won't appear in ESB.

Try changing the line of code with create_linked_object to create_linked_object = "DH_doorframe_front",
There's nothing theoretically wrong with the way you wrote it but direct object references can ...

It seems like certain cell sizes are finicky. This has been fixed for 0.85.

Weirdly enough I had actually mentioned this many years ago and you were both in that thread! But I can't really blame you guys for forgetting since I didn't remember at first either.

The second number is the draw priority. Higher numbers are drawn later, so they are shown on top of lower numbers. This makes sure that objects in ESB are shown in a coherent fashion regardless of their actual order on the tile; e.g., doorbuttons always drawn on top of doors.

So, an interesting ...

There are a few ways to do it. Admittedly none of this is particularly well documented though you can see the code in editor/editor.lua which has plenty of examples.

The simplest way is to set esb_name equal to one of the standard archetypes (e.g. "stairsdown") which will tell ESB to use the icon ...

The door is either going to be drawn before the doorframe or after it.

If you want to do something more complicated you may have to split up your doorframe image into two objects: a "near side" doorframe that is always drawn before the door, and a "far side" doorframe that is always drawn after the ...

Yes, those are equivalent in Lua.

A short summary of how Lua tables work (copied from here ):

Lua tables are defined within { }'s, with a comma-delimited list of elements. { } alone is an empty table, which isn't useful by itself, but is necessary to create a table if you want to add elements to ...

I can't reproduce this. Since you found a solution that works for you it's probably not worth delving into!

Ok, I saw it in my test dungeon too. I'll hunt down why this is happening and fix it for 0.85.

In DM, if you are standing right next to a pit, you can see the corner of the pit, and if you are standing next to stairs, you see a little bit of the wooden railing. So what DSB calls near_side existed in DM but was very limited.

DSB actually uses neither the v2 or v3 walls, strictly speaking ...

Yes, so far, so good.

The x offsets for perspective and side views are mirrored on the right side, which is normally what you want, because that way the object is positioned the same on both walls. (As mentioned above in the doorbutton discussion, it is not always what you want)

If I had my dungeon designer hat on rather than my engine programmer hat, what I would do was give it a far_y_tweak that put it outside of the viewport. I don't know if this will actually work, and I don't "officially" support this method, but it might be worth a try.

This code worked for me:

gfx.doorbutton = dsb_get_bitmap("NEW_DOORBUTTON", "custom_asset_location/new_doorbutton.png")
gfx.doorbutton.x_off = 120
gfx.doorbutton.y_off = -110

gfx.doorbutton_side = dsb_get_bitmap("NEW_DOORBUTTON", "custom_asset_location/new_doorbutton.png")
gfx.doorbutton_side.x ...

As I said before, I've reached the limit of my ability to help without actually having the files.

Ok, reading Gambit's post made think about how DSB is actually doing this and made me realize that your paths are still wrong. (Thanks for the help, Gambit :mrgreen: )

All paths are relative to the dungeon's main folder. If your dungeon is installed at X:/DSB/Project/, then if you want to load X ...

Just having graphics.cfg present is enough.

Unfortunately, I think I've just about reached the limit of my ability to troubleshoot this problem remotely. Please zip up your files and send me the dungeon, or some portion thereof that is able to reproduce the issue.

Right, relative to DSB (or wherever the dungeon is installed) so it will work for people who have it installed somewhere other than a specific location on the X: drive, like you have it now.

Anyway, the result is not the same: now it's showing the (presumably) correct path, which is progress. The ...

First of all, writing absolute paths like that is a bad idea. Nobody will be able to play your dungeon unless they install it to the exact same place. You should use relative paths instead.

Anyway, I think what isn't working here is that you've used backslashes (\) which, in Lua, are used for ...

Another way is to not use the graphics.cfg at all and instead specify everything in custom new override files (which is how I originally started) but that seems to increase loading time.
It does. If you put everything into new files, then it loads the DM image in base/, trashes the DM image, and ...

It's a single variable. Your second example will keep overwriting path . I'd recommend doing it like this:

local paths = {
"folder/pics1/",
"folder/pics2/",
"folder/pics3/"
}

gfx.my_bmp = dsb_get_bitmap("MY_BITMAP", paths[1] .. "my_bitmap.png")
gfx.my_other_bmp = dsb_get_bitmap("MY_BITMAP ...

I'm glad you figured it out.

I'm not going to delete the post, because I think that "make sure your shortcuts are pointing to the right place" is helpful advice and may help someone else down the line. (Not just to keep your shame on public display )

I just tested it and it works fine for me. Please give me a more detailed description of what you're doing so we can figure out what you've done wrong.

The simplest way to do that is to just put an invisible wall on the tile.

You can set no_stopclicks to true in a monster's archetype to allow objects to be picked up from its tile.

Ah, yes. I hadn't actually used that function in a couple years. I'm glad you figured it out!

I've fixed my initial post above in case anyone stumbling across it gets confused.