Dungeon Master Forum

Posted: **Wed Apr 03, 2013 8:17 pm**

Right. I'll add dsb_get_flydelta and dsb_set_flydelta which will do what you want.

Posted: **Wed Apr 03, 2013 8:24 pm**

1st Suggestion: Could graphics.lua be an automatic include (like objects.lua... it doesn't need to be in the lua_manifest)? If graphics.lua was automatic, wouldn't it be easier to find a way for ESB to load custom graphics... graphics.lua is where ESB expects to find all your custom graphics, just like objects.lua is where it expects to find custom objects and the like. You could add a new command to ESB similar to "Reload Archs", but instead it'd be "Reload GFX" (and the Control-R shortcut could trigger them both).

2nd Suggestion: I feel that the first step to getting any custom graphics handling into ESB would be to have a basic graphics viewer: load the graphics.lua (remember all the "name" values and paths to each graphic used by dsb_get_bitmap) and compile the "name" values of each handle into a list... when selecting an entry in the list, display the corresponding bitmap in a preview window. You don't have to actually load the graphic into RAM until a preview is demanded... remember the path to each image, but don't actually load the image itself (you could still open it just to make sure it exists and stuff, then close it again).

3rd Suggestion: Could you add the option to view an architype's Lua code (read-only, just view what ESB has since the last "Reload Archs")? For instance, right-clicking on the entry in the architype list could pop up a window that shows the Lua that the given object uses (in a simple text box)... so the poison dart in the test dungeon would show:

Code: Select all

obj[ROOT_NAME] = clone_arch(obj.dart, {
	on_impact = poison_dart_impact,
	on_melee_damage_monster = poison_dart_melee_damage		
} )

Or you could even go so far as to say "because the poison_dart_impact and poison_dart_melee_damage functions are used, display that code too":

Code: Select all

function poison_dart_impact(self, id, hit_what, hit_ppos)
	if (hit_what) then
		local hit_arch = dsb_find_arch(hit_what)
		if (hit_arch.type == "MONSTER") then
			do_poisoning(hit_arch, hit_what)
		end
	end
	return false
end

function poison_dart_melee_damage(arch, what, ppos, who, monster_id, hit_power)
	do_poisoning(dsb_find_arch(monster_id), monster_id) 
end

obj[ROOT_NAME] = clone_arch(obj.dart, {
	on_impact = poison_dart_impact,
	on_melee_damage_monster = poison_dart_melee_damage		
} )

Sorry for the bombardment... but I've been fiddling with ESB a bit and these things are on my wishlist

And sweet! Sounds like dsb_get_flydelta should be exactly what I was looking for!

Posted: **Wed Apr 03, 2013 8:28 pm**

I put graphics in all sorts of files, I prefer to keep asset defintions related to say, a new creature, all in the same file (along with sound fx). I imagine that this causes a lot of the headaches with parsing graphic data into ESB and so I don't see that adding an automated system for this is going to work for all designers...

Posted: **Wed Apr 03, 2013 8:45 pm**

@Gambit: I have to wander, if you had a built-in graphics editor in ESB right from the very start, would you still feel the same way? If it did all the work for you (like RTC does with it's dungeon file)? I know that I would love such a feature in ESB... it'd really improve the editor (and probably drag in some more RTC converts, hehehe)

But, I consider my suggestion to be only the first step on that very-very-looooooooooooong road.

Posted: **Wed Apr 03, 2013 9:27 pm**

Now that I've worked both ways, I actually think the managing stuff in text files can be a lot more efficient than a GUI. Plus it matches the workflow I use for web development (my day job), so it was easy to adjust.

I don't know that having a full GUI for managing graphics is actually that useful once you start working with text files, as there would be a lot of swapping around between ESB and the code editor. All I'd like to see in ESB now is simply a graphical representation of the things that I place in the dungeon: that's the thing that's really missing. I can't always remember what pillar1 might be vs, pillar2 so to be able to quickly see the front view of any given arch would be a godsend.

As for RTCs GUI for handling graphics: Works well for a few items, but once you start doing a lot of new stuff/replacements, it was actually pretty awful to be honest. Using "scalings" as a way of grouping images just didn't make any sense at all and the tabbed interface was nightmare to use quickly. I think the tree view that ESB uses is much better, and if that tree view could also show images for the archs, it would suit me just fine.

Posted: **Thu Apr 04, 2013 11:44 am**

Gambit37 wrote:All I'd like to see in ESB now is simply a graphical representation of the things that I place in the dungeon: that's the thing that's really missing. I can't always remember what pillar1 might be vs, pillar2 so to be able to quickly see the front view of any given arch would be a godsend.

But, then the question becomes "how is this actually done (programming wise)"? Sophia has already mentioned that parsing the files for graphics would be quite a challenge... so my suggestion was to unify all graphics into a single file (and even with a pretty long list of custom graphics, that file shouldn't really get that big. And even a huge file that consists of almost nothing but lines of "dsb_get_bitmap(blah,blah)" isn't really that difficult to use either)

ESB could parse the graphics.lua quite quickly (cause it knows to only search that file for what it's after), and as I stated in my suggestion it could simply remember the paths to all the images (and this would make it parse the file in mere fractions of a second, cause it doesn't have to load the actual images themselves). When the designer comes along and goes "I wanna see what Pillar1 looks like"... it simply looks up the architype's graphics entries and goes "I need PILLAR_1_FRONT" lets go look for that in the list we got from graphics.lua (the entry from graphics.lua that loads PILLAR_1_FRONT tells you the path)... load the image at the given path into our preview window.
But, that all hinges on the ability to compile a list of used custom graphics (and more specifically, the paths to each custom graphic)... and that's why I suggested the unification. It seems to be the only way to actually head in that direction. Otherwise, it'd be a complete programming nightmare for poor Sophia.

Posted: **Thu Apr 04, 2013 12:20 pm**

Question: How do I check if a character's hands are empty? Can a put a flying item into a character's hand (imitating a "catch"), if so how?

Posted: **Thu Apr 04, 2013 9:34 pm**

Lord_BoNes wrote:How do I check if a character's hands are empty? Can a put a flying item into a character's hand (imitating a "catch"), if so how?

Yes, you can dsb_fetch and it will return the instance id of whatever is in hand, or nil if the character's hand is empty. For example:

Code: Select all

-- Get the id of whatever is in the left hand
local l_item = dsb_fetch(CHARACTER, who, INV_L_HAND, 0)
-- Get the id of whatever is in the right hand
local r_item = dsb_fetch(CHARACTER, who, INV_R_HAND, 0)
-- Do something simple
if (not l_item and not r_item) then
   dsb_write(debug_color, "BOTH HANDS ARE EMPTY!")
end

If you're looking for a specific arch, the base code includes a helper function to do this for you, called find_arch_in_hand.

To put something into the hands, just dsb_move it to that location.

Posted: **Fri Apr 05, 2013 5:56 am**

I've noticed that when doing dsb_move inside an on_fly method, it can result in a "segmentation fault" for some reason

Code: Select all

local check = dsb_fetch(CHARACTER, who, INV_R_HAND, 0)
if (not check) then
	dsb_write({255,255,255}, who.." CAUGHT OBJECT "..id);
	dsb_move(id, CHARACTER, who, INV_R_HAND, 0)
	return nil
end

check = dsb_fetch(CHARACTER, who, INV_L_HAND, 0)
if (not check) then
	dsb_write({255,255,255}, who.." CAUGHT OBJECT "..id);
	dsb_move(id, CHARACTER, who, INV_L_HAND, 0)
	return nil
end

return nil
--return x, y, tile, face, 0

If I uncomment the last line, the fault occurs. The "return nil" on the 2nd last line stops the "segmentation fault" but, it means that the object falls to the floor if no catch is made

This seems to be a bug, but I'm not quite sure.

Posted: **Fri Apr 05, 2013 6:43 pm**

Yes, it's a bug. You've yanked the item out of the air and DSB didn't account for this, so it essentially tried to keep flying through your inventory-- with unpleasant results. I've fixed this.

I've also modified it so a return of nil just means "proceed as normal" instead of "fall out of the sky."

Posted: **Fri Apr 05, 2013 7:09 pm**

If you wanted to make it fall out of the air, you've always got the option of setting flytimer to 0.

Posted: **Fri Apr 05, 2013 7:10 pm**

A great mental image there (items flying through your inventory). Some kind of "random rucksack grenade"? An RRG, not an RPG. Could be a cool weapon....

Posted: **Fri Apr 05, 2013 7:44 pm**

It's flies through, knocking all your good items out on the floor

Posted: **Fri Apr 05, 2013 7:53 pm**

At one point, I did envision some particularly annoying item with an on_click that would immediately move it some random location in your backpack. That is, whenever you tried to grab it, it would appear to hop to another location.

Posted: **Fri Apr 05, 2013 7:59 pm**

Sounds almost like a "virus" item

Posted: **Fri Apr 05, 2013 9:05 pm**

...or a "soap in the bath" object.

Posted: **Sat Apr 06, 2013 6:46 pm**

Is DSB able to take 2 images (flying toward & flying away) and construct an animation that has 4 frames: frame 1 being flying away, frame 2 = flying toward, frame 3 = vertically flipped flying toward, frame 4 = vertically flipped flying away?

I imagine that this is possible, and so my question becomes "How?"

Posted: **Sat Apr 06, 2013 8:46 pm**

I'm not entirely sure what you're asking, but, of course, DSB has a full set of bitmap manipulation commands so you should be able to create whatever animation sequence you want...

Posted: **Sat Apr 06, 2013 9:10 pm**

Let's say I load two images called "axe_away" and "axe_toward"... I want to create 2 more images, which are simply vertically flipped (flipped upside-down) versions of these 2 images, can this be done on-the-fly with code in DSB?

Now, taking these 2 new images (let's call them "axe_away_flipped" and "axe_toward_flipped") I want to construct an animation sequence that has 4 frames: "axe_away", "axe_toward", "axe_toward_flipped" and "axe_away_flipped"
How would I do this in DSB Lua?

Posted: **Sat Apr 06, 2013 9:44 pm**

There is no code to automatically vertically flip a bitmap, but it's the sort of thing that's not that difficult to write yourself. Something like this should work for you:

Code: Select all

function vert_flip_bitmap(source)
   local w = dsb_bitmap_width(source)
   local h = dsb_bitmap_height(source)
   local dest = dsb_new_bitmap(w, h)

   for y=0,h-1 do
      for x=0,w-1 do
         local rgb, a = dsb_get_pixel(source, x, y)
         dsb_set_pixel(dest, x, (h-y)-1, rgb, a)
      end  
   end

   return dest
end

After these images are made, you can call dsb_animate with a table consisting of your four images:

Code: Select all

gfx.axe_animated = dsb_animate({ gfx.axe_away, gfx.axe_toward, gfx.axe_away_flipped, gfx.axe_toward_flipped }, 0, delay)

(As an aside, the sheer flexibility of what you can do with graphics in DSB is partially why any sort of automatic graphics management in ESB is such a nightmare.

)

Posted: **Sun Apr 07, 2013 6:33 am**

Thanks Sophia! That was very helpful code. I also did a "flips horizontally" function, and I've used it to do the side images (for rotating CCW: starting image, flip vertical, flip horizontal, flip vertical again... the object appears to "tumble" like an axe or club does).
I just changed this line

Code: Select all

dsb_set_pixel(dest, x, (h-y) - 1, rgb, a)

To this

Code: Select all

dsb_set_pixel(dest, (w-x) - 1, y, rgb, a)

The main reason I was doing this was because I wanted the "Vorax" images from DM2 for my custom axe... and DM2 only has single toward/away/side images (they must do all this flipping inside the engine), and I wanted DSB to be nice and create the animations for me

Well, that and it's been an interesting learning experience to create my new axe

Posted: **Sun Apr 07, 2013 6:54 am**

Sophia wrote:At one point, I did envision some particularly annoying item with an on_click that would immediately move it some random location in your backpack. That is, whenever you tried to grab it, it would appear to hop to another location.

I was just thinking on this... I thought of a way to "catch" such an item: fill your backpack... it'd have nowhere else to go.

Posted: **Sun Apr 07, 2013 1:48 pm**

Sorry for the triple post

Is there any way to "stack" an item (arrows, shurikens & darts for instance... so you could have say 10 darts "stacked" in 1 inventory space)? If not, could it be implemented? I can imagine this having demand.

Posted: **Sun Apr 07, 2013 3:08 pm**

Gambit37 wrote:Now that I've worked both ways, I actually think the managing stuff in text files can be a lot more efficient than a GUI. Plus it matches the workflow I use for web development (my day job), so it was easy to adjust.

I don't know that having a full GUI for managing graphics is actually that useful once you start working with text files, as there would be a lot of swapping around between ESB and the code editor. All I'd like to see in ESB now is simply a graphical representation of the things that I place in the dungeon: that's the thing that's really missing. I can't always remember what pillar1 might be vs, pillar2 so to be able to quickly see the front view of any given arch would be a godsend.

As for RTCs GUI for handling graphics: Works well for a few items, but once you start doing a lot of new stuff/replacements, it was actually pretty awful to be honest. Using "scalings" as a way of grouping images just didn't make any sense at all and the tabbed interface was nightmare to use quickly. I think the tree view that ESB uses is much better, and if that tree view could also show images for the archs, it would suit me just fine.

well, it only took a day to put in most graphics without a line of code. of course that is once you have the files. i wish Sophia would get that GUI working, without it, the engine will be limited to a certain few. i'd like to be a part of it, but the code is so ugly. think of it as like an app. press here and it does things for you. when will DSB be like that?, i am hoping soon.

Posted: **Sun Apr 07, 2013 8:02 pm**

Lord_BoNes wrote:Is there any way to "stack" an item (arrows, shurikens & darts for instance... so you could have say 10 darts "stacked" in 1 inventory space)? If not, could it be implemented? I can imagine this having demand.

There are some pretty hackish ways of doing it (generally involving making the "stack" a container and doing various trickery involving that) but no actual "item stacks."

Posted: **Sun Apr 07, 2013 8:23 pm**

Sophia wrote:There are some pretty hackish ways of doing it (generally involving making the "stack" a container and doing various trickery involving that) but no actual "item stacks."

Is there a way to "stack" or count money? If you collect gold pieces for example say, can they increase with number of pieces collected, but be stored on a single inventory slot (like Bloodwych)? Assuming not possible as this is the same issue as with the stacking?

Posted: **Mon Apr 08, 2013 9:49 am**

@Ebeneezergude: Isn't that the job of the "moneybox"? You can store craploads of coins/gems in the thing, and it keeps on storing more

Which is basically what Sophia said: making the "stack" a container and doing various tricks...

On a different note: Are all object exvars saved when dungeon does, or do you have to set them up (using dsb_export or some such)? I tried setting an exvar to remember who owns an individual object (called "owner"... it gets set when the item is equipped) but, this value seems to degrade back to nil whenever I load the dungeon (equip item, set owner, drop item on floor, save dungeon... then load dungeon and exvar value gone).
And, I swear I saw a list of "important exvars" (which looked like exvar entries that are going to save with the dungeon) but I can't for the life of me remember where it was...

Posted: **Mon Apr 08, 2013 10:38 am**

I use this for saving data:

Code: Select all

snp_data = {
   sound_feet = "feet_stone",
   sound_ambient = 0
}
dsb_export("snp_data")

That way, you only need to define one array for export, and you can shove whatever you want in there.

Posted: **Mon Apr 08, 2013 11:01 am**

Sneaky! That works. So it saves ALL entries in the named table, handy to know... that's always been a worry (will it save this, will it save that)

Posted: **Mon Apr 08, 2013 11:28 am**

I haven't done much testing yet, but this was the method Sophia recommended. I just set the array at the top of my startup file. I assume you can add new key/values to the array at any time in your code and they will be saved automatically, but maybe it doesn't work that way and all key/values need to be defined up front? Sophia?

Dungeon Master Forum

Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB

Re: Questions about DSB/ESB