Question about an exvar

[Remy]

I'm working on a DSB dungeon builder, and had a question about an exvar I found and don't quite understand what it's for. In 'triggers.lua' there's a reference to an exvar called 'tc' - I can't quite understand what it does. At a guess, I think it's a state check, but it seems redundant. I'm just wondering if it's important.

[Sophia]

I'm working on a DSB dungeon builder

In 'triggers.lua' there's a reference to an exvar called 'tc' - I can't quite understand what it does. At a guess, I think it's a state check, but it seems redundant. I'm just wondering if it's important.

"Tc" means "trigger count." It's used to keep track of what valid triggering items are sitting on a pad. It's needed so that a pad with one valid item on it isn't triggered again when a second is put on it. It's also important so that const_weight works properly. So, it's important to the game mechanics, but I don't think anyone who is designing a dungeon without a lot of scripting needs to care about it.

[Joramun]

RemyR, you have ten times my courage.

I actually considered doing the same using Glade (gtk interface builder)
but the task of parsing / generating dungeon lua files looked quite difficult.

I think parallax started to document the exvars in DSB, maybe we could ask him to release his work so that other can start from it.

[Sophia]

I actually considered doing the same using Glade (gtk interface builder) but the task of parsing / generating dungeon lua files looked quite difficult.

I know what you mean.

I decided to be lazy about this and just use the same parsing code for both the editor and the game... which led to its own set of problems.

In my own attempt at an editor I got all the parsing stuff out of the way and then promptly got sick of writing Windows API code. I'm no big fan of GUI design anyway... oh well. I haven't completely given up hope.

[Remy]

Thanks for the info on the Tc - and if Parallax has some documentation, I'd love to see it, even if it's just for reference (I have a vague intention of including exvar documentation in a help file for easy reference).

Don't get too excited - I carefully said "builder", not "editor", because the one thing it currently cannot do is parse a DSB/Lua dungeon into it's native data format. I'm actually thinking of tapping into LuaInterface to handle parsing (every stab I've taken at doing it so far has invariably resulted in an error cropping up somewhere), but that hasn't come close to happening yet.

It can generate usable code, though (that's obviously a neccessity). I managed to recreate the first three levels of the original DM dungeon in the builder, output to DSB/Lua code, and load it into DSB without having to edit a single line of the exported code (actually, that's not quite true - I've yet to finish the Roster/Champion maker UI, so I stole the roster from Juramund's DM convert for testing purposes - your dungeon has help immeasurably in designing the builder, by the way). There's a small 'startup.lua' file required (it currently contains a couple of globals and a very minor rewrite of the 'spawn_door' function from 'utils.lua'), but that's it.

I skipped over win32 API and MFC completely, and am coding in C# and .NET 2.0. I realize this will limit usership to WinXP/Vista (and adventurous Win98/2000/Me users who've braved adding the framework to their OSes), but there are things I wanted early on that would have meant either alot of coding or using lots of outside libraries to do in VC++, neither of which appealed to me (I've got nothing against outside libraries - I just dislike having to learn lots of -sometimes wildly- different interfaces you need to use them, which is part of the reason LuaInterface wasn't implemented from the beginning.)

Anyway, thanks for the exvar info. In retrospect, it makes perfect sense.

[Joramun]

I'm no big fan of GUI design anyway... oh well. I haven't completely given up hope.

Well, Glade is very easy : you just create a new project, add all the windows/buttons etc. and it output an allmade C/C++ or whatever (python, C# ...) code, with all the necessary GUI objects and function calls. So it generates a "dummy" but functional interface. Then you just need to add the actual functionalities by inserting your own dungeon handling code. It even has functionalities to display images (e.g. maps) and probably to handle keyboard shortcuts/ ctrl-clicks etc.

The only requisite for it to work is the gtk graphical library, which is a portable ( Linux ! ) and actively supported library...

Basically, I looked into the gtk code, but what really stopped me is thinking about how I would have to :
- register archetypes in objects.lua,
- map instances and their exvars, local variables etc. in dungeon.lua as a function of coordinates AND reference (for targeting)
- decide if I use bmp maps or text maps.
- write an editable dungeon.lua ...

And I already did it for RTSB but it was much simpler, because I didn't have to make an actually readable version of dungeon.lua, but merely a syntactically correct one (and that's why all exvars are at the end of the file) and i didn't need a smart targeting system (to make dungeon mechanics by a combination of clicks)

[Parallax]

RemyR: What I have done is very rudimentary and, by now, badly outdated, but I'll PM it to you if you want. It's all text.

Basically, it's a list of all exvars as of version 0.14 or so, by file, with the first 10 exvars or so having descriptive entries. Actually, since I'm at it, let me take this opportunity to apologize to Sophia for never finishing it.

[Remy]

Yeah, I'd like to take a look, Parallax. I want to make sure I'm not missing anything, at the very least. Descriptions really aren't all that necessary at this point - I'm just using the list I'm making for an autocompletion routine (assuming I can get that chunk of code working right) at the moment.

[Sophia]

I carefully said "builder", not "editor", because the one thing it currently cannot do is parse a DSB/Lua dungeon into it's native data format.

Well, one thought is-- you could always just not do this part. The editor would load and save its own format, and when you were ready to try out your dungeon in DSB, you would "export" it to a piece of Lua code.
(Of course, an "import" function could be added later, if someone felt like doing it...)
I'd offer parsing code, since I've already done all that stuff with Lua already, but it'd be in regular C so it might not play nice with C# and .NET.

let me take this opportunity to apologize to Sophia for never finishing it.

Hey, it's no problem, you did start it!
I'd like to see where you got, too... maybe between all of us, we can finish it.

[Remy]

Well, one thought is-- you could always just not do this part. The editor would load and save its own format, and when you were ready to try out your dungeon in DSB, you would "export" it to a piece of Lua code.

That's how it's going to be done for now. I'd rather get a basic beta version of the UI out so people can point out errors than worry about something like this.

I'd offer parsing code, since I've already done all that stuff with Lua already, but it'd be in regular C so it might not play nice with C# and .NET.

I could just translate it, but I'm not sure how I'm going to implement it just yet. Thanks for the offer, though.

Basically, I looked into the gtk code, but what really stopped me is thinking about how I would have to :
- register archetypes in objects.lua,
- map instances and their exvars, local variables etc. in dungeon.lua as a function of coordinates AND reference (for targeting)
- decide if I use bmp maps or text maps.
- write an editable dungeon.lua ...

I thought about those things, too, and pretty much, I'm doing the same thing I'm doing with Importing Lua -- I'm ignoring them until they show up on my front door waving lawsuits.

Archtypes, in my builder, don't come from the 'objects.lua' file - I have a seperate file for them, mostly because I needed information not stored in the object listings.
Here's a snippet:

Code: Select all

    <Archtype Type="WallDecor" Icon="0">
      <Name>keyhole_gold</Name>
      <exvar Key="opby" value="key_gold" />
      <exvar Key="msg" value="M_DEACTIVATE" />
      <exvar Key="destroy" value="true" />
      <exvar Key="target" value="[Enter Target]" />
      <exvar Key="disable_self" value="true" />
    </Archtype>

As you can see, I needed an Icon index number (so that the mapper will look pretty) and I'm using a set of exvars - basically, these get copied to any instance of "keyhole_gold" that gets created, and the designer can then edit, remove, or add to them.
I realize this means doubling up code writing (if a designer has custom objects they'd like to place in the dungeon, they'd have to create a listing in an 'objects.lua' file and the Archtype Library), but this information is both useful and neccessary.

I've done the bit about keeping instances stored with their variables and exvars and an Id. Here's a screenie from the editor:
Screenshot...
Ignore the fact that there aren't any icons yet - I'm not graphically inclined and so I keep putting off making them.
As you can see, the instance property pane on the right has all that info. The designer can either set an Id themselves or let the builder do it.

And as of right now, the code it produces isn't all that readable. I ran into the same problem you probably did with RTSB - sequential creation. The code the builder produces actually looks similar to that of RTSB - it spits out the maps for each level, then the basic instances, then the instances inside containers, and finally all the exvars. It's broken up a bit with comments, and technically a designer could track down an instance by giving it their own rememberable name, but it's far from the "tmp / targ" system that hand-coded dungeons like test_dungeon use. I don't like it either, but it's the simplest way out of the sequential problem.

[Sophia]

Archtypes, in my builder, don't come from the 'objects.lua' file - I have a seperate file for them
...
I realize this means doubling up code writing

I guess it's not too bad, though it must have been a lot of work to translate everything in objects.lua
Maybe there's some way for a Lua script to parse the objects.lua and to autogenerate the file, for designers?
Don't mind me, just some thoughts that I'm not sure about...

And as of right now, the code it produces isn't all that readable.

It's probably more readable than the code produced by my version of an editor!

I don't like it either, but it's the simplest way out of the sequential problem.

It really is the simplest way. I wouldn't worry too much; I think if there's a good graphical editor, nobody really cares about the human-readability of the dungeon.lua, because any nice code can be put in startup.lua (or wherever) anyway. Just don't forget to call dsb_spawnburst_begin() and dsb_spawnburst_end() or the dungeon will behave very strangely.

Oh, I'll also contribute this, whatever use it is.
My editor had a table called "important_exvars" that gave a list of exvars that should always go to the top of the list-- every other random one was put in alphabetical order below these. So for what it's worth here are the exvars that I considered "important":

Code: Select all

important_exvars = {
	"msg", "target", "generates", "min", "max", "lev", "x", "y",
	"opby", "opby_class", "opby_id", "opby_party", "opby_thing",
	"opby_monster", "destroy", "disable_self", "text", "shoots", "power", 
	"sound", "regen", "double"
}

[Remy]

Just don't forget to call dsb_spawnburst_begin() and dsb_spawnburst_end() or the dungeon will behave very strangely.

You know, I completely forgot about that...

So for what it's worth here are the exvars that I considered "important"

I can use that, actually. There's basically three ways to attach exvars - from the archtypes, just typing them in (with the finally working auto-complete), and from a pop-up menu of little helper commands. Important ones, though not neccesarily ones you want attached to every instance of a particular archtype, are going on that pop-up. I've had trouble deciding what should be included and what shouldn't.

**Edit**
By the way, this is just a preference question, but if you saw a set of up and down arrows used to navigate through the levels of a dungeon editor, which would you assume takes you to the higher-numbered (which normally means lower) levels - the up arrow or the down arrow?

[Joramun]

Up arrow goes upward, down goes downward in the dungeon !

As a side note, maybe "page up" or "page down" would be better for that ?
(since arrow keys could also be used to navigate horizontally in a given level)

PS: I can't see your screenshot !

[Remy]

So Up means the numbers get lower - got it...

And, while I wasn't going to use the arrow keys for level movement, I hadn't really thought which keys I should use - PgUp and PgDn are pretty good.

About the screenshot -- yeah, I noticed the site wouldn't let me log on this morning, I dunno what's up with it. It doesn't matter much - the builder got a big makeover this week - while the layout from the picture is similar, it's looks completely different. I actually really like the new look - I'll post a few screenshots tonight after work. Or if I pass out, tomorrow.
Let's just say soon...

*EDIT*

And some screenshots. Mostly, just showing off the interface...
Basic interface...

Dettached pane...

Two views - in this case, a map and the dungeon info panel

A sample of the outputted code, in the DDm code inspector...

I should note - first, I don't have a tileset I like -- I blatantly stole the floor and wall tiles in the above examples from ESB, mostly 'cause I was tired of the blue lines that display without them.
Secondly, the first picture actually contains a mistake - there are two 'target' exvars attached to the keyhole. Oops.

[Sophia]

I really like how this editor is shaping up.

I blatantly stole the floor and wall tiles in the above examples from ESB

Oh, if you want the rest of the ESB tiles, feel free to use them, though it seems like you have tiles for just about everything else: (I was using the green square as a trigger, the red circle with the yellow line as a monster generator, and the blue diamond as a teleporter, everything else should be pretty obvious what it is)
http://www.ojnk.net/dm/dsb/esb_tiles.png

Is the only change you made to spawn_door that it no longer automatically prepends the string "door_"? Because, if that's the case, I'll just take that out of my version, so that it doesn't have to be included in every DDM-generated dungeon.

Code: Select all

function spawn_door(lev, xc, yc, type, button)
	dsb_spawn("doorframe", lev, xc, yc, CENTER)
	local targ = dsb_spawn(type, lev, xc, yc, CENTER)
	if (button) then
		local tmp = dsb_spawn("doorbutton", lev, xc, yc, CENTER)
		exvar[tmp] = { target=targ }
	end
	
	return targ
end

One other question. Your use of spawn_door in the output code suggests to me that your editor considers a doorframe + door [+ doorbutton] to be a single object, like DM, and unlike DSB itself?

[Remy]

About door_spawn, yep, that was all I did. I took that bit out because it made things easier to read; "black" and "ra_magic" are not necessarily easy to recgonize as types of doors.

For completeness, I also have another function and a couple of constants in a 'startup.lua' file...

Code: Select all

INV_OBJ = -1
True = true
False = false

function spawn_monster(type, lev, xc, yc, pos, hp)
        tmp = dsb_spawn(type, lev, xc, yc, pos)
        if(hp > 0) then
                dsb_set_hp(tmp, hp)
                dsb_set_maxhp(tmp, hp)
        end

        return tmp
end

'spawn_monster' does some hp changes if the designer sets them. I know there's an 'hp' exvar, but from what I could tell in the code, it wasn't for setting monster hp. INV_OBJ wasn't really neccesary, but made the containers more consistent. The 'True' and 'False' are done that way because that's the way C# prints out booleans and I wasn't sure if Lua accepted them without being lowercase (and by the time I found out C# did it that way, I wasn't about to go back and change all the code).

Your use of spawn_door in the output code suggests to me that your editor considers a doorframe + door [+ doorbutton] to be a single object, like DM, and unlike DSB itself?

Yeah, it does. I know you can spawn doorframes without doors (and 'doorframe' is available, just tucked away in a different category -- doorbuttons, however, are not), but doors without frames (or doorframes with buttons and no doors) look rather silly, so the three are all lumped together as a single instance in DDM, so designers wouldn't have to add two or three things everytime they need a standard door. I guess if someone had a custom door that didn't need a frame, or custom doorframes, this could potentially be a problem. That's a bit troubling now that I think about it. Is there any other reason not to have them that way?

Oh, if you want the rest of the ESB tiles, feel free to use them, though it seems like you have tiles for just about everything else:

Thank you! I felt wierd using a tileset so similar to yours without permission. And, no, I really didn't - I used the same tile for everything in a category (all those brown squares in the screenshot? Those are puddles and slime and pressure pads and pits...), and it looks really dumb.

[Sophia]

I guess if someone had a custom door that didn't need a frame, or custom doorframes, this could potentially be a problem. That's a bit troubling now that I think about it. Is there any other reason not to have them that way?

Not that I can think of, of course, those two that you thought of are pretty big issues. There are two solutions, I think.

One idea is to just simply make all the door stuff available in the list of archetypes, and if a designer wants to get fancy, it's all there. It's not the prettiest approach, and old hands at the RTC editor might make more work for themselves than is necessary, but it's simpler than the second option.

The second option, in my opinion more elegant but probably more difficult-- is to make the door "meta-instance" more flexible, and add some stuff to spawn_door:

Code: Select all

function spawn_door(lev, xc, yc, type, button, frame_type)

	if (frame_type == nil) then frame_type = "doorframe" end
	if (frame_type ~= false) then
		dsb_spawn(frame_type, lev, xc, yc, CENTER)
	end
	
	local targ = dsb_spawn(type, lev, xc, yc, CENTER)
	if (button) then
		if (button == true) then button = "doorbutton" end
		local tmp = dsb_spawn(button, lev, xc, yc, CENTER)
		exvar[tmp] = { target=targ }
	end
	
	return targ
end

Because Lua treats a parameter that isn't given as a nil, and doesn't type-check parameters that are given, this is actually 100% backward compatible with the simpler version, too.

For completeness, I also have another function and a couple of constants in a 'startup.lua' file...

That spawn_monster function seems useful, but I think that yours will crash DSB if hp is nil, because it will try to compare a nil with an integer and Lua doesn't like that. So, I've rewritten it (and added it to the base code) as such:

Code: Select all

function spawn_monster(type, lev, xc, yc, pos, hp) 
	tmp = dsb_spawn(type, lev, xc, yc, pos) 
    if (hp and hp > 0) then 
    	dsb_set_hp(tmp, hp) 
        dsb_set_maxhp(tmp, hp) 
    end 
    
    return tmp 
end

INV_OBJ wasn't really neccesary, but made the containers more consistent.

Oh, this is a good issue. I've probably never actually explained what that -1 is for (it's not just a space-filler), and it might be useful.
If a slot is specified in a spawn, for example:

Code: Select all

dsb_spawn("a_thing", IN_OBJ, container, 5, 0)

it means to put the instance of "a_thing" in slot 5 of the container. If something's already there, it'll shove it out of the way, and everything inside will get jumbled around. It's handy if you really need one specific instance in one specific slot, though. What -1 says to do is to instead put the new instance in the first slot of the container where there's room, and leave everything that's already in there alone.
There's already a constant defined as -1 called VARIABLE, and that's a pretty accurate description, so maybe we should just use that? I've edited the test dungeon accordingly.

As an interesting aside, there's no hard limit on how many instances can be inside a container. The only reason a chest is limited is because the number of objzones created by its subrenderer is limited. Putting an instance directly into slot 10 (or whatever) of a chest will also work, it'll just be invisible.

(and by the time I found out C# did it that way, I wasn't about to go back and change all the code).

Search and replace?
Seriously, I'm a little hesitant to add these to the DSB base code just to compensate for something goofy with C# and/or .NET, but on the other hand, to have to have every custom dungeon have a startup.lua just to handle these two constants is kind of ugly, too.

EDIT: Actually, it might be ok to break the rules, here. Normally, it's not a good idea to define constants or add code to dungeon.lua, because none of that is preserved when it gets compiled. However, since these constants will only be used in parsing the file (and get turned right into normal Lua constants), there's no harm done.

[Joramun]

All thumbs up !

As for the provided startup.lua : I did the same for DM, CSB and my other dungeon projects (under development), sometimes a little ugliness is better than a lot of tediousness.

As the interest of DSB is the custom code, I suppose a startup.lua will exist for most dungeons anyway !

Your editor looks great ! I can't wait to get my hands on it
Keep up with the good work !!!

[Parallax]

Wooo! This is absolutely amazing! I have nothing to contribute to this thread but I'm cheerleading all the way!

[Remy]

Well, first, the need for another constant for booleans is gone - so it doesn't have to appear in any Lua file. The last place it still existed anyway was in the bit of code that spit out spawn_doors, and it no longer uses internally stored booleans.

Speaking of which, I agree that the a fancier spawn_door is the better option, but the way I'm doing it now incorporates both your solutions. The reason being is I thought of another reason to seperate them - to attach exvars to doorframes and doorbuttons.
So, the way it works now is that normally, a door spawns as per the original spawn_door, but both buttons and frames can be changed (so, the newest spawn_door reacts to the button arguement the same way it does the frame, to allow for different kinds of buttons). The archtype library also includes seperate archtypes for doorframes and doorbuttons. I'm not including door objects by themselves, to avoid people getting confused about "wooden_door" and "wooden_door" and not knowing which is calling spawn_door and which is using an ordinary spawn. So if want a door without a frame (so that you can add a spawned one with exvars), you'll have to set the door's attached frame to "false", then drop in a doorframe.
Does that make sense?

I also changed up the containers dialog to let you choose which slot objects go into. I never knew that before.

The editor always spits out an HP value for the spawn_monster (it defaults to -1, which is why the check was originally for anything above 0), but if you're going to include it in with Lua, a more universally acceptable version is needed.

As the interest of DSB is the custom code, I suppose a startup.lua will exist for most dungeons anyway !

While I agree, it's one of the unstated goals of this editor to not require the designer to add anything extra. So, forcing them to use a 'startup.lua' when they probably already have their own is messy. RTSB could get away with it because when you were done with RTSB, you were pretty much done with your dungeon - it was a converter, not a builder. This builder is supposed to take care of the tediousness of putting together dungeons in DSB - but its just one step in the dungeon creation process (in my opinion, the most gruelingly boring step - hence an editor to speed up the process), so that designers could get on with the cooler bits of DSB (though, I wanted to take advantage of as many DSB's features when it comes to dungeon building as I can).

Speaking of which, does someone have an alternate wallset? I'm currently working on putting them in, but it would be helpful to actually have one to test with.

**Edit**

I really like how this editor is shaping up.

Your editor looks great ! I can't wait to get my hands on it
Keep up with the good work !!!

Wooo! This is absolutely amazing! I have nothing to contribute to this thread but I'm cheerleading all the way!

I just wanted to add that I'm not ignoring the praise.
It's very appreciated!

**Edit Again** ( I blame the coffee)
I'm also using spawn_pit, but with no changes (and there's going to be a user setting to turn it off if people don't want it). My question is - it's currently only attached to 'pit's, not 'ipits' or 'fakepit's (I think thouse are what they're called) - should it be attached to all of them? Should there be seperate user settings for each? I imagine not (since 'ipit's are supposed to be invisible, and fakepits aren't really pits, but I thought I'd ask).
And one last question, before I think it's time to start a different thread, since we've veered way off the 'tc' exvar topic - 'dsb_msg_chain': is there another way to duplicate this functionality with exvars, 'cause currently there's no way to attach instances like this within the editor, and it may be neccesary.

[Joramun]

EDIT : I have some wallsets on my computer that I can transfer to you (PM)

They were not done by me, making a full wallset is very long, and I'm only a beginner...

[Remy]

Please do... Can you send stuff through PMs? DO you just want my e-mail (which I'll send to you PM..lol)? Would that make it easier?