Questions about DSB/ESB

[Sophia]

the ambient light does actually work pretty well at creating brighter areas around a specificed radius. I'll certainly miss this effect in my dungeon if I switch to DSB

If all you want is a simple object to brighten a certain radius, oblivious to walls and obstructions, that probably wouldn't be hugely difficult and I could toss it into 0.47. If we start having to get into line of sight and such issues, though, then it starts becoming a real nuisance.

I'm curious about "renderer_hack" -- there appears to be only two settings for this, LEFTRIGHT and MAGICDOOR. I haven't investigated how these are setup yet, but I assume others could be created (such as DOWN)?

The renderer_hack property is something used by various object archetypes that render themselves in extremely unconventional ways to tell the core engine what they're up to. The number of valid strings is limited and hardcoded, and currently reflects only what default DM was able to do. If you want doors that open down, sideways, and all kinds of other weirdness, I'll have to build renderer_hacks for those into the core engine. It won't be that difficult, and I certainly don't mind doing it, but it was just something I didn't want to bother to do if nobody was ever going to use it.

Can DSB automatically handle different sized doors (ie, like the narrow ones you'll have seen in Zagor)? In zagor, you ca only open them by clicking on their doorhandle -- possible in DSB easily enough?

I'm actually not sure how you made those doors. I'm sure something like it could be made in DSB, but the amount of Lua it'd take would be more than you'd probably want to write. One thing I noticed: monsters will still rearrange themselves on the tile if you shut the door in their face, which means sometimes they'll seemingly move right through the closed door. This could be fixed in DSB, but it would require even greater amounts of Lua hacking.

Also, can I just say that I totally love you for ICONGRID.PCX This will be a massive time saver over how icons are handled in RTC. Having just one file + an offset = inspired

I'm glad it works! Since the offset is one-dimensional, if you're going to expand on this, don't change the width of the grid, or the offsets of everything will be thrown off. Hmm.. it might not be a bad idea for me to make the function that chops up the icon grid take parameters so you can just call it to make your own icon grids, too.

[Gambit37]

If all you want is a simple object to brighten a certain radius, oblivious to walls and obstructions, that probably wouldn't be hugely difficult and I could toss it into 0.47. If we start having to get into line of sight and such issues, though, then it starts becoming a real nuisance.

Whatever RTC does (seriously, don't worry about it, it's just a nice to have)

I'm actually not sure how you made those doors? One thing I noticed: monsters will still rearrange themselves on the tile if you shut the door in their face, which means sometimes they'll seemingly move right through the closed door.

Yes, I know about the monsters seeming to walk through the doorframe, haven't seen them walk through doors though...? The doorframw issue I can live with in RTC, but very cool if it could be fixed in DSB. As for the doors, they aren't real doors, they're actually flooritems that simply swap from a cloned solid pillar to a cloned floorgrate which allows movement over it. Plus two smaller items to act as the handle. This should explain it:

[Sophia]

Yes, I know about the monsters seeming to walk through the doorframe, haven't seen them walk through doors though...?

RTC doesn't check if a tile is blocked before allowing monsters to move around within that tile. There's no realistic reason to, either, given the default way DM mechanics work. However, with the way you have the doors set up, if a monster is on the "back" of a tile with a shut door (i.e., behind the door) RTC will allow that monster to move to the "front" of the tile (i.e., on the other side of the door-- seemingly passing through the shut door) without any problem. By default, DSB doesn't make this check either and would have the exact same problem. The "even greater amounts of Lua hacking" I mentioned would be to prevent it.

As for the doors, they aren't real doors, they're actually flooritems that simply swap from a cloned solid pillar to a cloned floorgrate which allows movement over it. Plus two smaller items to act as the handle.

Oh, that's definitely doable in DSB, if you don't mind doing all that. The "more Lua than you'd like to write" was to create it in a way that it could all be done as a single item.

[Gambit37]

These doors would probably take me a while to figure out, but perhaps they're a good example for me to learn more about DSB... thanks for the notes.

20) I couldn't find a "probability" exvar for triggers. How do I match this functionality from RTC, for triggers that will randomly activate?

[Joramun]

Use the "trigger_controller" item in ESB.

[Gambit37]

OK, thanks

Is there a full list somewhere of all the possible object properties? (Other than going through objects.lua and compiling my own)?

No, not at present. Someone will have to make one.

I'm going to do this. It will be useful for me to understand better how objects are defined, and I think it will also be useful for everyone else too. I'll work locally on a spreadhsheet. When the first version is complete I'll put it in the Wiki so others can update it if necessary.

Question: Does objects.lua contain all possible types, classes and properties? Are there any others known by the engine that aren't exposed in this file?

[Mon Ful Ir]

It certainly doesn't contain all the possible classes. There are an infinite number because they're user-definable. The mfi_dungeon files, for example, have a new class ("UNDEAD"). ESB automatically recognises this and lets you use it, once it's opened a dungeon that contains a user-defined class.

[Joramun]

Question: Does objects.lua contain all possible types, classes and properties? Are there any others known by the engine that aren't exposed in this file?

Try opening the editor.lua situated in editor/ to know which class/types might be relevant.

As MFI says, you can define any class/type/property you want. However, some properties (like "on_trigger") interact implicitly with the core engine (e.g. : on_trigger = when stepped upon) so can be considered more "hardcoded" than others, which are called only explicitly by a lua script (ie. you will find some function in some file.lua in dsb/base/ that calls them) and are therefore "softcoded".

[Sophia]

Question: Does objects.lua contain all possible types, classes and properties? Are there any others known by the engine that aren't exposed in this file?

It does contain all possible types. There are an infinite number of possible classes, but it contains all classes known to the base code. As for properties, probably not.

What has sort of prevented me from doing like this is the sheer vastness of it and the lack of any good scheme to organize stuff. Tell you what, if you do what you can, I'd be happy to fill in the information you don't understand and/or don't know about.

[Gambit37]

Just going back to my questions about narrow doors: would it possible to write some lua so that any creature entering a narrow door tile is automatically centred? And a group splits up and only one is centered, while the rest of the group stay on the tile behind?

Also, another question: Where is the code for handling the front door to the dungeon (start/resume/etc) -- I remember seeing it but now can't find it.

[Sophia]

Just going back to my questions about narrow doors: would it possible to write some lua so that any creature entering a narrow door tile is automatically centred? And a group splits up and only one is centered, while the rest of the group stay on the tile behind?

Of course.

Also, another question: Where is the code for handling the front door to the dungeon (start/resume/etc) -- I remember seeing it but now can't find it.

It's front_door in base/render.lua. It's invoked via sys_front_door in base/system.lua but there isn't much in there.

[Gambit37]

I'm still just poking around in files and trying to understand how it all links together. I haven't actually built or coded anything yet. I think part of the problem was that I instantly wanted to convert my RTC Zagor dungeon, but as it had a lot of unusual stuff in it, that threw me off.

I'm gonna go through your tuitorials and start with the basics, get to grips with the editor. I'll focus on just getting my basic dungeon layout to work without any complex stuff. When I've got to grips with that, I'll want to rebuild my champion selector and also do an intro sequence -- I'm gonna need a lot of help with that, though!

[Gambit37]

Re: Front Door code. How would I override this to make something like my static menu screen (in the Zagor RTC demo I sent you)? I can see there is an animating function and a click function that returns some values for buttons pressed. Say I want to make an animated background with no doors or to fade between different screens as an intro sequence, but keep a menu of buttons over the top -- how would I go about that? (I realise this is way beyond the basic tutorials at this stage -- I'm just looking for some idea of how complex that sort of stuff would be when I get around to it)

[Gambit37]

Just a couple of quick questions

1) See the post above about Front door code
2) Can the save system be changed to work the same way as DM2 / RTC through custom lua code in a custom dungeon? Or is this a hardcoded feature? It's kinda clunky as it stands and the DM2/RTC way is much more user friendly.

Thanks!

[Sophia]

Sorry, I missed your last post. What I have to say probably isn't too useful anyway.

Question #1
It's hard for me to just explain how to do what you want to do, because the code is pretty powerful and flexible, and your request is pretty broad. There is an option to fade between static screens relatively easily, now, by just adding an extra true parameter to your dsb_fullscreen call.

"Buttons" are defined in the click function by simply checking the coordinates where the click occurred. You could create some sort of manager on top of this (I think ian_scho started doing this) but it's not required for a simple GUI.

As for other things, it might be best if you just play with the front door code and make small changes and see what they do. I can help with more specific inquiries, of course.

Question #2
It's hardcoded and it would be kind of difficult to expose this to Lua. What do you find wrong with it? Maybe I could make some improvements.

[Gambit37]

OK, thanks, I'll check out the front door code. As for the save game system, it does seem much improved in 0.49 -- older versions were more clunky. I just got so used to having the 8 slots in RTC, going back to 4 seems kinda limited. There's not really any good reason for sticking to 4 simply for nostalgia sake -- wouldn't it be better to take these opportunities to improve things from what went before?

[Gambit37]

Wooty! By following the original door code and your animation tutorial, I've now got a fully animated title screen with clickable buttons . Perhaps this coding lark ain't gonna be so tricky after all

[Sophia]

There's not really any good reason for sticking to 4 simply for nostalgia sake -- wouldn't it be better to take these opportunities to improve things from what went before?

You're right, simple nostalgia is not a good reason.
The reason I stuck to 4 save slots in DSB is because the code and graphics to handle the standard DM four button GUI were already there because other parts of the DM GUI required using it. Doing something different would've required more effort.

[Gambit37]

Ah, but more effort yields greater rewards (I think!?)

Why do I sometimes hear a giggler during start up?

[Sophia]

It's just a goofy easter egg.
Every startup has a 1/64 chance of playing the giggler noise.

[ian_scho]

no way.... I always thought that it was my dungeon's fault. An interpreter error or something.

[Gambit37]

QUESTION: How could I continually check the light level, or if a torch is burning in the players' hand, and change the wallset accordingly? I thought it might be nice to design wallgraphics that have a more realistic light effect in the tiles around the party...

[Sophia]

You don't really need to check it continually, just when the light level changes, and when the level the party is on changes. Then, you can change the level's wallset with dsb_level_wallset(level, wallset). Of course, that method only works if the entire level uses the same wallset. If you have squares that use a special wallset, the whole thing gets a lot more messy because you have to iterate over the level and change the wallset all over with specific calls to dsb_alt_wallset-- it's just iterating over what's likely to be a 32x32 or so grid, so it's not like it'll slow the game down, it just gets a bit messier.

[Gambit37]

Cool. Any chance of a code example?

[Sophia]

Sorry, not at the moment.

[Gambit37]

No worries, I'm certainly in no hurry

[Gambit37]

Is there a way of including other lua files in my objects.lua? It's gonna get crazy messy and I'd like to organise things into files such as items_food.lua, items_weapons.lua, etc.
I tried using the lua require command but DSB complains.

[Sophia]

You can use dsb_import_arch. Just ignore ROOT_NAME and treat it like a straightforward inclusion.

Code: Select all

dsb_import_arch("", "items_food.lua")

[Gambit37]

Aha, cool, thanks. So simple when you know how

[Gambit37]

How can I get some useful debugging info on screen in a full screen renderer? (values of variables, etc.)
You mentioned before that I could output stuff using __log or dsb_write.
I can't seem to get __log to work at all, and dsb_write does nothing if you're in a fullscreen renderer, until you exit from it and enter the game view.
???