Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

I consider it an essential part of Dwaf Fortress, and can't play without it.

119 (18.4%)

I use it for pretty screenshots, but otherwise don't use it during play.

211 (32.7%)

I only try it occasionally.

174 (27%)

I have no idea why I'm even in this thread, I don't use it.

141 (21.9%)

Total Members Voted: 642

[Xerberus]

I think the soapmaker's workshop might be the one to copy, since it's also a custom workshop.

In other news, this:

Spoiler (click to show/hide)

oh my god that just looks gorgeous.....can't wait for the when we can fiddle with stonesense in DF2014.

i hadn't really tried stonesense in the DF2012 version, was it fully functional as an overlay gameplay-wise?

[Rose]

A note on building sprites :
If a building requires more than one material for its construction, you can pick which item is used for coloring which part of the building. You can check wells and mechanics to see how that works.

This means that, using wells as an example, you can have the well body, rope, and bucket, all being colored right, including showing dye on the rope color.

[Dirst]

I found a little wonkiness with Stonesense's creature sprites, and it's probably because I have a bizarre creature.  I'll put the work-around here in case anyone is as OCD in their creature raws as I am.

The creature in question has two dozen castes, and due to how descriptions appear in-game there is no way to tell what caste one is when looking at its detailed description.  To insert some differentiation, I changed the TLCM_NOUN for skin to something unique for each caste.  So the Awakened Granite has "granite surface" instead of "skin", the Awakened Slate has "slate surface" and so on.  This also looks nice in combat logs.  Most of the castes have several possible surface colors (for example, marble has [TL_COLOR_MODIFIER:WHITE:10:ASH_GRAY:4:GRAY:2:MOSS_GREEN:2:PALE_PINK:1]).

Stonesense throws errors if I refer to the creature's "skin" bodypart, which it should.  But it doesn't seem to understand

Code: [Select]

<variant caste="BASALT" sheetIndex="0"  color="bodypart" bodypart="basalt surface" zoom="2">
<subsprite sheetIndex="1" color="bodypart" bodypart="eyes" zoom="2" /> <!-- The missing pattern_index is not an error, their eyes are a solid color. -->
</variant>
It does color the main sprite properly, but the subsprite isn't drawn.  This happens even if I use a named color for the subsprite.  I figured out this is because Stonesense defaults to the first color-modifier defined for the sprite and breaks out of the entire <variant> structure.

But you can make this work.  Simply omit the bodypart= argument. There are no errors in the console, it defaults to the correct color, and it processes the rest of the <variant>.  The problem is that the custom TLCM_NOUN seems to wreck references to any colors defined later in the creature.  In my case, all creatures of the same caste have the same color eyes, so I could just do it with named colors.

(When I define the eyes first and the faux-skin second, the default color becomes the eye color.  But in that case I can reference the eyes properly, I just have no way to reference the faux-skin's color.)

So if you have some bizarre creature with odd description text, you can take advantage of Stonesense's intelligent fail-over behavior, but then you only get to reference that one color.  I imagine that parsing custom TLCM_NOUN text is really low on the priority list, but it would be an awesome addition when the program is stable.

Spoiler: Entire XML file (click to show/hide)

Code: [Select]

<?xml version="1.0" ?>
<creatures file="tesb_awakened_stone.png">
 <creature gameID="AWAKENED_STONE" >

<!-- The "skin" bodypart is renamed in the creature raws to fix in-game descriptions.
      Stonesense doesn't pick up the custom names properly, but the default seems to be
  the first color defined, which works just fine.  They eye colors differ from
  the creature raws slightly for better visibility. -->

<variant caste="ANDESITE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="CREAM" zoom="2" />
</variant>

<variant caste="BASALT" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="RED" zoom="2" />
</variant>

<variant caste="CHALK" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="WHITE" zoom="2" />
</variant>

<variant caste="CHERT" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="FLAX" zoom="2" />
</variant>

<variant caste="CLAYSTONE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="CREAM" zoom="2" />
</variant>

<variant caste="CONGLOMERATE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="FLAX" zoom="2" />
</variant>

<variant caste="DACITE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="SILVER" zoom="2" />
</variant>

<variant caste="DIORITE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="PURPLE" zoom="2" />
</variant>

<variant caste="DOLOMITE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="BLACK" zoom="2" />
</variant>

<variant caste="GABBRO" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="AMETHYST" zoom="2" />
</variant>

<variant caste="GNEISS" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="BLUE" zoom="2" />
</variant>

<variant caste="GRANITE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="EMERALD" zoom="2" />
</variant>

<variant caste="LIMESTONE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="BLACK" zoom="2" />
</variant>

<variant caste="MARBLE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="GOLDEN_YELLOW" zoom="2" />
</variant>

<variant caste="MUDSTONE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="SCARLET" zoom="2" />
</variant>

<variant caste="PHYLLITE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="AUBURN" zoom="2" />
</variant>

<variant caste="QUARTZITE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="INDIGO" zoom="2" />
</variant>

<variant caste="RHYOLITE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="TURQUOISE" zoom="2" />
</variant>

<variant caste="ROCKSALT" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="CHESTNUT" zoom="2" />
</variant>

<variant caste="SANDSTONE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="AMBER" zoom="2" />
</variant>

<variant caste="SCHIST" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="AQUAMARINE" zoom="2" />
</variant>

<variant caste="SHALE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="IVORY" zoom="2" />
</variant>

<variant caste="SILTSTONE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="BEIGE" zoom="2" />
</variant>

<variant caste="SLATE" sheetIndex="0"  color="bodypart"  zoom="2">
<subsprite sheetIndex="1" color="named" color_name="DARK_BROWN" zoom="2" />
</variant>

 </creature>
</creatures>

[Caldfir]

I found a little wonkiness with Stonesense's creature sprites, ...

Ah, yeah if it can't find the top-level sprite, stonesense doesn't read the rest of that xml block because it assumes you've made a mistake and prints an error message, however it can still draw the initial sprite if there's enough information there to point it at an image file (this is why when people mess up their xml, they usually get naked dwarf spites). 

I think technically you still want to use the term "skin" when referring to the creature's body in the stonesense xml.  Stonesense looks up the bodypart by the bodypart name, not the TLCM_NOUN.  It should still get the correct color, since it does a case-wise lookup to figure out which color to use, since it is still actually called "skin" in the raws (TLCM just changes how it shows up in text boxes and descriptions I think).  If that doesn't work, open up the stonesense init and turn on debug mode, then use "v" to look at the creature in DF and place the DF/Stonesense cursor on the creature and you should get a detailed description of the known bodyparts and colors - so use whatever words it uses there in your xml.

Also, I think the "fail-over" behavior you're describing is just stonesense failing to find a bodypart, so if just defaults the value to the first bodypart, which just frequently happens to be skin.  Looking at it, I think it really should fail-out in that case rather than try to guess, since it confuses people more than anything. 

Let me know if that works - and if it doesn't please post the error message you got, since that can be helpful.

[Dirst]

I found a little wonkiness with Stonesense's creature sprites, ...

Ah, yeah if it can't find the top-level sprite, stonesense doesn't read the rest of that xml block because it assumes you've made a mistake and prints an error message, however it can still draw the initial sprite if there's enough information there to point it at an image file (this is why when people mess up their xml, they usually get naked dwarf spites). 

I think technically you still want to use the term "skin" when referring to the creature's body in the stonesense xml.  Stonesense looks up the bodypart by the bodypart name, not the TLCM_NOUN.  It should still get the correct color, since it does a case-wise lookup to figure out which color to use, since it is still actually called "skin" in the raws (TLCM just changes how it shows up in text boxes and descriptions I think).  If that doesn't work, open up the stonesense init and turn on debug mode, then use "v" to look at the creature in DF and place the DF/Stonesense cursor on the creature and you should get a detailed description of the known bodyparts and colors - so use whatever words it uses there in your xml.

Also, I think the "fail-over" behavior you're describing is just stonesense failing to find a bodypart, so if just defaults the value to the first bodypart, which just frequently happens to be skin.  Looking at it, I think it really should fail-out in that case rather than try to guess, since it confuses people more than anything. 

Let me know if that works - and if it doesn't please post the error message you got, since that can be helpful.

Thanks for the insight and the pointer to debug mode.  The more I look into Stonesense the more impressive it becomes.  Might be a few days before I can get back to this project (Go away real world!  Get away from me!), but I'll let you know what happens.  I can tell you however that bodypart="skin" threw an error (one for each caste on load) and drew the sprite as it appeared in the sheet which happens to be a light grayscale.

On an unrelated topic, I was working on the actual art for these guys last night to put some subsprite highlights in case the surface is black... Stonesense seems to support full alpha channels, yet the vast majority of the included files (and all of the examples on the wiki) use the magenta trick.  For me GIMP is kinda like threading a needle while wearing boxing gloves, but for others who actually know what they are doing with graphics, knowing that Stonesense supports alpha channels could be really helpful.

Also, I noticed that if the creature's claws are cut off if they intrude a bit into foreground tiles.  Is there a way to turn off that clipping?  If there was a wall in front of the creature, its feet would be occluded anyway.  My GIMP skills aren't quite up to horizontally shrinking five different subsprites and keeping them aligned in their cells.  (Edit: I suppose it might just be the foreground floor tiles being stamped on top of the sprite.  That would mean I have to rebuild my sprite sheet again...)

[Rose]

Yeah, that would, indeed, be the forward floors being drawn on top of the sprites. It's not easy to get around that, because it would mean changing the entire draw operation, and probably wouldn't work anyway.

As for the pink, yeah, the default sprites mostly use pink, with some of them being transparent. And some use a combination for handy guides, like pink text explaining stuff, and sprite outlines, to keep creatures inside the tile.

[Dirst]

Yeah, that would, indeed, be the forward floors being drawn on top of the sprites. It's not easy to get around that, because it would mean changing the entire draw operation, and probably wouldn't work anyway.

As for the pink, yeah, the default sprites mostly use pink, with some of them being transparent. And some use a combination for handy guides, like pink text explaining stuff, and sprite outlines, to keep creatures inside the tile.

I just wanted to make sure any graphic artists knew that they had the alpha channel available, that's all.

For the clipped claw issue, it could work if all floor tiles were drawn first (from rear to front) then all sprites (from rear to front) in a second pass.  Floor tiles are already handled differently because their sprite sheets have different dimensions, but I'm not sure it'd be worth the effort to split things up into two passes.

[Dirst]

I found a little wonkiness with Stonesense's creature sprites, ...

Ah, yeah if it can't find the top-level sprite, stonesense doesn't read the rest of that xml block because it assumes you've made a mistake and prints an error message, however it can still draw the initial sprite if there's enough information there to point it at an image file (this is why when people mess up their xml, they usually get naked dwarf spites). 

I think technically you still want to use the term "skin" when referring to the creature's body in the stonesense xml.  Stonesense looks up the bodypart by the bodypart name, not the TLCM_NOUN.  It should still get the correct color, since it does a case-wise lookup to figure out which color to use, since it is still actually called "skin" in the raws (TLCM just changes how it shows up in text boxes and descriptions I think).  If that doesn't work, open up the stonesense init and turn on debug mode, then use "v" to look at the creature in DF and place the DF/Stonesense cursor on the creature and you should get a detailed description of the known bodyparts and colors - so use whatever words it uses there in your xml.

Also, I think the "fail-over" behavior you're describing is just stonesense failing to find a bodypart, so if just defaults the value to the first bodypart, which just frequently happens to be skin.  Looking at it, I think it really should fail-out in that case rather than try to guess, since it confuses people more than anything. 

Let me know if that works - and if it doesn't please post the error message you got, since that can be helpful.

Well I had a chance to play with this.  I'm also working in version 40.10 now rather than 40.08, and the wonkiness is different.

It turns out the TISSUE and the TLCM_NOUN were both set to the same text, but if I changed one then Stonesense is definitely picking up the TLCM_NOUN.

With the debugging info and the 'v' readout, it appears that Stonesense does actually see both bodypart colors.  But when I try to use the second one it comes up with something random.  IVORY looks cyan, AQUAMARINE looks like a slightly pale red, and in this screenshot so does AMBER.

Spoiler: Beware, ugly artwork-in-progress inside (click to show/hide)

All of those surface colors are valid possibilities for the SANDSTONE caste, but the eyes are all supposed to be AMBER.  You can see that the debug info even sees the AMBER and assigns the correct rgb to it, so I'm not sure what's going on here.  I did try a variant with no spaces in the name; that didn't make a difference.  The subsprite's color is incorrect even if I use a named color in the XML.


Now for the strange part.  If I fail to include the bodypart= attribute or specify an invalid one, it loads the first color and now the eyes work.  If I put in the bodypart="sandstone surface" in there, it renders the subsprite in some consistent-but-incorrect color.  Aha, so I can get this working by having identical code for each caste.

Code: [Select]

<variant caste="SANDSTONE" sheetIndex="0"  color="bodypart" zoom="2">
<subsprite sheetIndex="1" color="bodypart" bodypart="eyes" zoom="2" />
</variant>

and the obvious conclusion is that I can replace all of that with

Code: [Select]

<creature gameID="AWAKENED_STONE" sheetIndex="0"  color="bodypart" zoom="2">
<subsprite sheetIndex="1" color="bodypart" bodypart="eyes" zoom="2" />
</creature>

but that renders the sprite in the correct color and skips the subsprite completely.

Undeterred, I recall seeing something about a none-of-the-above <variant>.  Now this file does what I want it to do:

Code: [Select]

<?xml version="1.0" ?>
<creatures file="tesb_awakened_stone.png">
 <creature gameID="AWAKENED_STONE">
 
<variant sheetIndex="0" color="bodypart" zoom="2">
<subsprite sheetIndex="1" color="bodypart" bodypart="eyes" zoom="2" />
</variant>

 </creature>
</creatures>

Still need to do something about creatures with a BLACK surface, but I have a working version.  Hopefully the steps to get there helps you in figuring out what's not working as designed.

[Rose]

Simple solution for black is to change what DF defines as black.

[Dirst]

So, to summarize what I think is happening:

1. When a <variant> has an "odd" but correct bodypart attribute, it somehow distorts the color of the <subsprite>.  Needs more testing (Does this happen at the <creature> level?  Does it happen for "standard" bodypart's like "skin"?) but it was getting really late.
2. When a <creature> cannot find a bodypart, Stonesense colors the sprite with the first color in the creature and breaks out of the <creature> structure.
3. When a <variant> cannot find a bodypart, Stonesense colors the sprite with the first color in the creature and processes the rest of the <variant> structure.
4. An error is written if a non-existent bodypart is specified, but not if the bodypart is omitted completely.

My completely uninformed guess is that 1 is caused by a slightly off-kilter memory offset somewhere, especially because the behavior is different between 40.08 and 40.10.

2 and 3 and 4 are just differences in error handling.  Personally I prefer how the <variant> works now, but I can see the wisdom of making a failed search fail spectacularly enough to prod people into fixing their XML.

[Dirst]

Simple solution for black is to change what DF defines as black.

I would like my mod to co-exist peacefully with other mods, so I'll probably go the route of coloring the black ones CHARCOAL if I can't get highlighting to do what I want.  All of them also need a black outline to fit in with other Stonesense sprites.

[Dirst]

I've tried to add my custom building graphics and found that Stonesense totaly ignores "game_custom" parameter.
For example I have:

Code: [Select]

<building name="Soapmakers Worshop" game_type="Workshop" game_subtype="Custom" game_custom="SOAP_MAKER" file="workshop.png">
<
... sprite order
>

<building name="My Worshop 1" game_type="Workshop" game_subtype="Custom" game_custom="MY_WORKSHOP" file="workshop.png">
<
... sprite order
>

<building name="Altar of Storms" game_type="Workshop" game_subtype="Custom" game_custom="ALTAR_STORMS" file="workshop.png">
<
... sprite order
>
They are all in different files and added to index file properly. And works nice if used one in time.
But not with all files together to be load.
Stonesense sees the same game_type="Workshop" and game_subtype="Custom" parameters, and makes no difference between those buildings and draws them using the last loaded rule of the third building.
So now you can have only one custom building and it's Soapmakers workshop already.

Bad thing is I found this problem after a lot of time spent making sprites for all of this stuff.
Is there a way to fix it?

Was there ever a resolution for this?  Ideally Stonesense would be able to handle multiple custom buildings at some point, but for now would <variant> tags within a single custom workshop do anything?  If that works, it just means replicating the Soapmaker's Workshop and Screw Press at the bottom of the mod's XML.

[Rose]

I's supposed to handle custom buildings, and did at one point. I'll have to see why it doesn't.

[Rose]

Okay, I found the problem, and it's been fixed for the next version.

[Dirst]

Okay, I found the problem, and it's been fixed for the next version.

Much appreciated.  You have saved us from the hell of living amongst a multitude of Soapmaker's Workshops!