Print

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

[Meph]

Maybe you're right, mifki. For now, I'll just be defaulting to a subtype of 0 if I can't find any subtypes. If there's something I'm still missing at that point, I'll go ahead and ask here. Oh, but I still need to know what the tiles for bowls, mortars, pestles, carving knives, boning knives, slicing knives, meat cleavers, carving forks and pouches are. I can't find those items on the Tilesets page and I can't remember them off the top of my head.

Also, I'm working on a tile overrides list as well. It's going much more smoothly because I don't have to worry about the subtypes, just what the original ASCII tiles where. I'll go ahead and share that once it's finished.

You can find these tile-numbers in item_tool.txt. Tools are the only items that can use a custom tile, which is why you can't find any mentioning of a hardcoded tile.

Example:

Code: [Select]

[ITEM_TOOL:ITEM_TOOL_MORTAR]
[NAME:mortar:mortars]
[VALUE:10]
[HARD_MAT]
[TOOL_USE:GRIND_POWDER_RECEPTACLE]
[TILE:150] ===============>>> YOUR TILE NUMBER!
[SIZE:100]
[MATERIAL_SIZE:1]
[CONTAINER_CAPACITY:1000]

[DragonDePlatino]

Hey, mifki. I'm currently working my way through all of the possible item overrides, and I've run into a problem.



If I try overriding something with a black foreground like a wooden barrel, it won't display properly. The gold/iron variants with yellow/gray foregrounds are displaying properly, but the wooden barrel is just a completely-black tile.

As a solution, what if TWBT automatically used the old background color for the foreground color if the old foreground color was black? TWBT can already do things like automatically remove background colors so I don't imagine this would be that difficult.

You can find these tile-numbers in item_tool.txt. Tools are the only items that can use a custom tile, which is why you can't find any mentioning of a hardcoded tile.

And...noted! I really should have known this, considering that's where I got all of the subtypes from. ^^;

[Button]

Sorry if this has been answered, but there's too many pages of thread to go through for a quick question .

Has zooming been fixed yet? I really like the idea of TWBT, but being off by half a screen when I zoom in is a pain in the ass - especially if I'm zooming because I want to find a specific dwarf in my dining room.

In case it's relevant, I usually play with 2/3 of the screen as screen, and the rightmost third as the command sidebar.

[mifki]

Of course it's possible, but it doesn't look like an universal solution to be enabled by default. As you can see, there have been discussions about colours here recently, and also some time ago when I announced the next major TWBT version with much easier configuration for overrides. I think soon I will release beta version with new overrides system and also add some options for tile colouring, at least to start a discussion about what we want to achieve with colours.

[mifki]

Has zooming been fixed yet? I really like the idea of TWBT, but being off by half a screen when I zoom in is a pain in the ass - especially if I'm zooming because I want to find a specific dwarf in my dining room.

You mean zooming to something/somebody? Sorry, no:(

[DragonDePlatino]

Of course it's possible, but it doesn't look like an universal solution to be enabled by default. As you can see, there have been discussions about colours here recently, and also some time ago when I announced the next major TWBT version with much easier configuration for overrides. I think soon I will release beta version with new overrides system and also add some options for tile colouring, at least to start a discussion about what we want to achieve with colours.

A new update with easier overrides and better colors? Neat! And while we're at it, here's a suggestion...

Why not include a list of default values for the Tile parameter? Like, if you tried an override without a Tile parameter like [OVERRIDE::I:ANVIL:ANVIL::items:100] then TWBT would automatically try 229. This way, if a TWBT artist couldn't remember what a tile was or forgot the parameter, TWBT would do it's best to fix it. So far, I can confirm all of the following Tile values work in Vanilla DF:

Code: [Select]

ID:TYPE
(ORIGINAL TILE)
SUBTYPE

AMMO:AMMO
(47)
0 ITEM_AMMO_BOLTS
1 ITEM_AMMO_ARROWS
2 ITEM_AMMO_BLOWDARTS
AMULET:AMULET
(12)
ANIMALTRAP:ANIMALTRAP
(127)
ANVIL:ANVIL
(229)
ARMOR:ARMOR
(91)
0 ITEM_ARMOR_BREASTPLATE
1 ITEM_ARMOR_MAIL_SHIRT
2 ITEM_ARMOR_LEATHER
3 ITEM_ARMOR_COAT
4 ITEM_ARMOR_SHIRT
5 ITEM_ARMOR_CLOAK
6 ITEM_ARMOR_TUNIC
7 ITEM_ARMOR_TOGA
8 ITEM_ARMOR_CAPE
9 ITEM_ARMOR_VEST
10 ITEM_ARMOR_DRESS
11 ITEM_ARMOR_ROBE
ARMORSTAND:ARMORSTAND
(14)
BACKPACK:BACKPACK
(146)
BALLISTAARROWHEAD:BALLISTAARROWHEAD
(17)
BALLISTAPARTS:BALLISTAPARTS
(220)
BAR:BAR
(240)
BARREL:BARREL
(246)
BED:BED
(233)
BIN:BIN
(88)
BLOCKS:BLOCKS
(254)
BOOK:BOOK
(8)
BOULDER:BOULDER
(7)
BOX:BOX
(11) LEATHER
(146) STONE/WOOD/METAL/GLASS
BRACELET:BRACELET
(153)
BUCKET:BUCKET
(150)
CABINET:CABINET
(227)
CAGE:CAGE
(19)
CATAPULTPARTS:CATAPULTPARTS
(220)
CHAIN:CHAIN
(179)
CHAIR:CHAIR
(210)
CHEESE:CHEESE
(37)
CLOTH:CLOTH
(167)
COFFIN:COFFIN
(48)
COIN:COIN
(36)
CORPSE:CORPSE
LOTS OF TILES
CORPSEPIECE:CORPSEPIECE
(253)
CROWN:CROWN
(230)
CRUTCH:CRUTCH
(194)
DOOR:DOOR
(15) GEM
(79) GLASS
(186) WOOD/BONE
(197) STONE
(240) METAL
EARRING:EARRING
(235)
EGG:EGG
(248)
FIGURINE:FIGURINE
(143)
FISH:FISH
(224)
FISH_RAW:FISH_RAW
(224)
FLASK:FLASK
(173)
FLOODGATE:FLOODGATE
(42) GEM
(88) STONE/METAL
(215) WOODEN/BONE
FOOD:FOOD
(37)
0 ITEM_FOOD_BISCUITS
1 ITEM_FOOD_STEW
2 ITEM_FOOD_ROAST
GEM:GEM
(4)
GLOB:GLOB
(247)
GLOVES:GLOVES
(91)
0 ITEM_GLOVES_GAUNTLETS
1 ITEM_GLOVES_GLOVES
2 ITEM_GLOVES_MITTENS
Alternately, you could just include this list once it's finished in the documentation. It'll save artists a lot of time.

[mifki]

then TWBT would automatically try 229

And where would it take it from?
Anyway next version will not require tile numbers. If you didn't read last several pages, it's going to be as easy as placing a file like anvil.png in a folder, or ITEM_GLOVES_GAUNTLETS.png in gloves subfolder, and so on.

[DragonDePlatino]

And where would it take it from?

The list I just showed you, of course. Though I guess that's irrelevant now.

Anyway next version will not require tile numbers. If you didn't read last several pages, it's going to be as easy as placing a file like anvil.png in a folder, or ITEM_GLOVES_GAUNTLETS.png in gloves subfolder, and so on.

Please, please, please tell me there's still going to be support for sprite sheets...Working with separate image files sucks. For a lot of reasons.

[mifki]

And where would it take it from?

The list I just showed you, of course. Though I guess that's irrelevant now.

Anyway next version will not require tile numbers. If you didn't read last several pages, it's going to be as easy as placing a file like anvil.png in a folder, or ITEM_GLOVES_GAUNTLETS.png in gloves subfolder, and so on.

Please, please, please tell me there's still going to be support for sprite sheets...Working with separate image files sucks. For a lot of reasons.

I didn't have the list before) Now I'll think about that.

Can't you just use some software that would extract separate tiles from your sheet?
The whole idea was to get rid of configuration files so that users can take any image from anywhere and of any size, drop it into a folder and it will just work. Especially handy for multitile workshops for which there will be a single image per building instead of configuring each tile. Also, there is support for animations, again you just include several frames in a tile image and no configuration necessary.

On the other hand, feedback from artists is also important, so I'm open for suggestions.

[DragonDePlatino]

Well...I'm very hesitant to work with multiple image files instead of a sprite sheet because it significantly slows an artist's workflow. I'm sure it is easier to program, but there are a number of downsides to image files.

1. If you decide you want to work in a size other than the default, you will have to go through each individual image and resize it. With sprite sheets, you can resize the image and it will update all of your sprites.

2. If you work with indexed color, you will manually have to go through thousands of images and apply your custom palette to each. With sprite sheets, you can update the palette of a single image and it will simultaneously update all of your sprites.

3. When you are open/saving files, you have to navigate to the file location for each file you want to find. With sprite sheets, everything is in the same file and you can see everything at a glance.

4. If you wish to use a resizing algorithm like hq2x or xBr to create higher resolutions for your graphics, you will have to go through each image and apply it. With a sprite sheet, you do one resizing operation and you're done.

With that being said, there could be a compromise. A long time ago, I did some graphical modding for UnNetHack (A NetHack mod). The vanilla game handles everything in a sprite sheet like this but the modder designed UnNetHack to handle hundreds of separate image files. So I did pretty much what you said...I worked in a big sprite sheet, then wrote a Python script that dumped everything into separate images. For TWBT, there could be a sheet image in the uppermost directory and a small executable that splits the image into the files. The only problem with this approach, though, are the aforementioned animations. I'm not sure how those could be handled.

Alternately, I'd suggest an organizational approach like I did with DawnLike, which had a huge number of animated sprites. Categorize all of the images into smaller sheets, and append a number onto the end of a filename if it's part of an animation. Some image-editing programs like ASEprite will even automatically turn that into an animated .GIF you can preview.

EDIT:

Oh! I've got an idea. For the first approach, you could have have a bunch of big sheets like Master0.png, Master1.png, Master2.png, etc. When you run the executable that splits the image up, it checks in Master1.png onwards if there are more frames for a tile. If the extra frames are transparent, the executable throws them out and snips the animation to a shorter number of frames.

[mifki]

Yeah, I can understand most of your points.
I think it will be possible to support loading sprite sheets as well for those who want the. There will be a config file with mapping from names to coordinates.
Another thing, now there will be overrides not just for items/buildings but also for different states, like door, door-locked, well, well-dry, workshop/masons-working, workshop/masons-idle, etc. (each of them may or may not be animated). So we got rid of tile numbers, IDs and all that, and now there's just a list of identifiers for everything that can be overridden. And actually it's not a big difference whether to load images for this identifiers from corresponding files or from a sheet at given coords.

[DragonDePlatino]

Ahhh! So there's a configuration file that let's you specify the coordinates within an image and the image's location? Like with creature graphics? Great! In that case, just do whatever. People can set up their workflow however it makes them comfortable.

The state overrides are also interesting. I haven't done any tile/building overrides yet so I'm not sure of the implications, but more flexibility is great.

[mifki]

Ahhh! So there's a configuration file that let's you specify the coordinates within an image and the image's location?

No, there's no at the moment, but will be if you and other artists need it.

[The_Fool76]

This reminds me of when Minecraft switched from using a big texture sheet to individual files.  I can absolutely say that working with multiple files VS one single one does slow down the workflow a bit. It also makes the task of making a new pack more intimidating to newcomers.

That said, I think having multiple files is ultimately the better way to go.  It makes customizing the game a LOT easier for the end user.  Want one person's wall sprites an anther person's workshop sprites?  Just copy the appropriate files over and go.  With a sprite sheet they are stuck having to copy stuff using an image editor.  Even a config file can be an issue as then they have to figure out how to properly merge the bits they want from one into the other.  Mind you, in THIS community I suspect having to wrestle a config file might be considered a relaxing break from playing the game so that may be less of an issue.

[mifki]

Want one person's wall sprites an anther person's workshop sprites?  Just copy the appropriate files over and go.  With a sprite sheet they are stuck having to copy stuff using an image editor.  Even a config file can be an issue as then they have to figure out how to properly merge the bits they want from one into the other.

Exactly this.
Anyway, I think it's decided now, it will use config file with identifiers to coords mapping and also look for individual files. Everyone will be happy.