Print

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

[scamtank]

Everywhere where I see colour tokens in raws, for example STATE_COLOR for inorganic

Spoiler (click to show/hide)

[INORGANIC:EMERALD]
[USE_MATERIAL_TEMPLATE:STONE_TEMPLATE]
[TILE:15][IS_GEM:emerald:STP:OVERWRITE_SOLID][DISPLAY_COLOR:2:7:0][MATERIAL_VALUE:40]
[ENVIRONMENT_SPEC:GRANITE:CLUSTER_SMALL:100]
[ENVIRONMENT_SPEC:SCHIST:CLUSTER_SMALL:100]
[ENVIRONMENT_SPEC:MARBLE:CLUSTER_SMALL:100]
[SOLID_DENSITY:2770]  Common to beryls.  Range 2630 - 2910
[STATE_COLOR:ALL_SOLID:EMERALD]

and here POWDER_DYE for dye

Spoiler (click to show/hide)

   [USE_MATERIAL_TEMPLATE:MILL:PLANT_POWDER_TEMPLATE]
      [STATE_NAME_ADJ:ALL_SOLID:dimple dye]
      [STATE_COLOR:ALL_SOLID:MIDNIGHT_BLUE]
      [DISPLAY_COLOR:1:0:1]
      [MATERIAL_VALUE:20]
      [POWDER_DYE:MIDNIGHT_BLUE]      
      [PREFIX:NONE]

I also see DISPLAY_COLOR token with approximated colour. So the colours are approximated already in raws, not in game? Which of these colour specifications the game actually uses? Or I understand it all wrong and these tokens do something different?

STATE_COLOR is used internally to decide the color when preferences and uniform assignments ask for it. It doesn't seem like it has an effect on what's displayed to the player. DISPLAY_COLOR handles that - I tried replacing the siltstone's DISPLAY_COLOR token with STATE_COLOR:ALL:AMETHYST and it just defaulted to material template stuff and eventually to just white on light gray when I ripped them out of the templates themselves.

What comes to dyes, the STATE_COLOR and DISPLAY_COLOR only apply to the powder itself, who knows what makes use of that info. The POWDER_DYE token is what decides the end result.

I think smuggling the STATE_COLOR values out into the open would be the ideal solution as far as usability goes.

[mifki]

STATE_COLOR is used internally to decide the color when preferences and uniform assignments ask for it. It doesn't seem like it has an effect on what's displayed to the player. DISPLAY_COLOR handles that - I tried replacing the siltstone's DISPLAY_COLOR token with STATE_COLOR:ALL:AMETHYST and it just defaulted to material template stuff and eventually to just white on light gray when I ripped them out of the templates themselves.

What comes to dyes, the STATE_COLOR and DISPLAY_COLOR only apply to the powder itself, who knows what makes use of that info. The POWDER_DYE token is what decides the end result.

Ok, so in short, if I make it possible to use more colours, then for dyes no changes required to raws - it should just approximate POWDER_DYE value to, say, 256 colours instead of 16. But for materials you'll have also first to define rgb values for additional colour indexes (again, 0-255 instead of 0-8) and then update DISPLAY_COLOR to make use of them, right?

Oh actually another question/problem - DISPLAY_COLOR defines background/foreground colours while colour tokens define only one colour...

[scamtank]

You know best what's the most robust way to go about things, but I'm a little leery about replacing the DISPLAY_COLOR values with something incompatible with the base system. I'd make the non-dye materials listen for a STATE_COLOR value instead and leave the DISPLAY_COLOR token redundant.

If you're going to modify materials, keeping all the colors in one place (descriptor_color_standard.txt) would make sense.

e: Dang, didn't even consider the background thing. I need to think about this.

[argh226]

Maybe PeridexisErrant can help you better - you definitely just dislike some change because of twbt in the latest starter pack, but I still don't understand what exactly, and anyway I don't use starter pack launchers and all so I don't know what's the easiest way for you to get what you want.

Dont worry about it, I wasn't pointing it at you, but rather at my ignorance about the whole MOD community.  I'll keep on reading and eventually will get a hang of it.
Until then I'll stick to my weird setup (see my 2 images, 1 or 2 pages back)

[Dirst]

So there are a bunch of different places that color gets specified, and they're not exactly consistent.  The wiki does a reasonable job of explaining how all of them work.

For gems and hardcoded materials, the STATE_COLOR is generally compatible with the DISPLAY_COLOR and so on (except for liquid water which is displayed blue but colored "clear").  For bodyparts and bodily fluids, the STATE_COLOR is the only color defined.

Non-gem stones don't define STATE_COLORs at all, relying on the stone template which defines the solid STATE_COLOR as GRAY.  This means a Dwarf with Gray as a favorite color is probably going to be perpetually happy, but it also means that the DISPLAY_COLOR, BUILD_COLOR, etc. are inconsistent with the STATE_COLOR.

It'd be possible to just display things in their STATE_COLOR and everything would work as expected.  Except for stone.  Which shows up fairly often in a typical DF game.

My suggestion would be to scope local display colors within materials, basically assigning the STATE_COLOR's rgb values to the closest display color.  For example, an AUBURN material would set the closest display color (4:0 which is "red") to 111:53:26 and use that anywhere that red was called for.  This conveniently side-steps the GRAY issue for stones if the display colors conflict with the STATE_COLOR, since that display color just doesn't get used anywhere.

There are a couple cases that need some thought.  For example, one modder might display an AZURE material (0:127:255) as light blue and another as cyan and yet another as light cyan.  The plugin would customize one of those display colors and leave the other two as defaults.  Personally, I'd rather live with near-misses like that than try to code in a bunch of exception handling to second-guess the modders.

[mifki]

The problem is that for objects for which the game approximates colour tokens to one of 16 colours, I think I found this code and if properly patched, it will just approximate to more colours instead.

But for objects for which colour token is defined but DISPLAY_COLOR is used instead, things get more complicated as either raws will need to be updated, or I'll need to update material colours in memory (and probably to parse raws myself).

Anyway, scam tank and Dirst, thanks for the explanation, I'll try the simple things first and then we'll see.

[mifki]

I can only get this to work in TWBT_LEGACY mode. If I use TWBT, it prints

Code: [Select]

TWBT no display patch
in the console, and DF runs without twbt enabled.
I am using ubuntu 14.04.
Any help would be appreciated.

I just tried on 14.04 and everything works fine. Are you sure you have different fonts for text and map specified in init.txt?

[UristWoodie]

This rocks!!!

OK, I've been playing with the default workshop types, and thanks to the pointers here (clement!), I've made good progress.

I switched from WORKSHOP_CARPENTER to WORKSHOP_MECHANIC, as it's easier to find mechanisms laying around in this fortress.

So..
[TILESET:Vanilla DF - 24x - Items.png:Vanilla DF - 24x - Items.png:Van24x]
[OVERRIDE:128:B:WORKSHOP_MECHANIC:Workshop::Van24x:41]
[OVERRIDE:128:I:TRAPPARTS:::Van24x:43]

Line 1 causes all item #128 (mechanisms) that are a part of a Workshop_Mechanic (notice the B type and BuildingID) to use tile #41 found in Tileset "Van24x" (defined in line 0). Note that this does NOT affect tile #128 that is used with just an item.

Line 2 causes all item #128 (mechanisms) that are placed as ITEMS with the ItemID "TRAPPARTS" (like a mechanism in a stock pile), to use tile #43 from tileset "Van24x". Note that this does NOT over-ride the Workshop definition, that continues to work as before.

If Line 2 is left in w/o Line 1, as you may expect, ITEMS placed outside a Workshop display the VAN24x override, and the BUILDING PART (#128) displays the base tileset tile.

I do not know what the performance implications are, I know someone expressed concern about that earlier.

I think the ID map that was posted above for the Carpenter is not quite right...I think it should be:
61 34 34
176 39 96
176 93 176

Thank you, and good night.

[Lord Afabie]

I can only get this to work in TWBT_LEGACY mode. If I use TWBT, it prints

Code: [Select]

TWBT no display patch
in the console, and DF runs without twbt enabled.
I am using ubuntu 14.04.
Any help would be appreciated.

I just tried on 14.04 and everything works fine. Are you sure you have different fonts for text and map specified in init.txt?

I checked again. I'm getting the two fonts now (I don't know why it wasn't working before), but multilevel isn't working. It changes the down ramps to up ramps, but doesn't actually show any more levels.

[mifki]

Oh I see, ok I'll fix it.

[Lord Afabie]

Thanks! I really appreciate all the work you do to keep this plugin working for everyone.

[mifki]

Thanks! I really appreciate all the work you do to keep this plugin working for everyone.

Try 5.19.

[Lord Afabie]

It works, huzzah!

[Dirst]

But for objects for which colour token is defined but DISPLAY_COLOR is used instead, things get more complicated as either raws will need to be updated, or I'll need to update material colours in memory (and probably to parse raws myself).

I'm not sure how much information you have about an object, but if it's STATE_COLOR and pattern descriptions are in there then I think this is the lightest-weight approach.

1. On load, scan through all of the DESCRIPTOR_COLOR objects and associate them with their closest display color based on the current color scheme.  Internally, you'd end up with something like

Color name	Color token ID	Color token brightness
AMBER	6	1
AMETHYST	5	1
AQUA	3	1
AQUAMARINE	3	1

2. When rendering a tile, on a local instance of the display color table, stamp the color(s) present on top of their associated display colors from the color scheme.
3. Apply all other fancy shading and stuff from multiview, etc.
4. Render the tile.

This misses out on patterns of close colors (e.g., amethyst and violet stripes) but those never rendered correctly to being with.

A quick test would be to make the render routing instantiate a local copy of the display color table and use that for rendering (without any changes due to the object's named color).  If that kneecaps the FPS, then this is the wrong solution.

Edit: Forum's table tool is a tad finicky.

[mifki]

I've had a number of people ask about tiles for the world map (in worldgen and embark).  If this could be a standard tile set defined in overrides.txt, that would be awesome - just drop in a specialist set once developed, or use a square text set, and default to the text tiles if it's not set.

Yeah, I saw people complained about text world map. Ok let it be the next thing to do. The only problem I'm afraid to tell you is that world map tiles will have the size of text tiles, so not square. Can't do anything about it. Otherwise it's quite simple.

That's awesome!  Shame about the size and shape, but thinking back it always was that way.  I guess tile artists will have to be creative 

Tried now and can certainly say that graphics tileset squashed to the size of curses font looks like shit. So two options here - either use a different, more squary font as default text font. Or dynamically change text tile size to square on these several screens with world maps because there's not much text on them anyway. Or wait until someone makes a nice rectangular world map tileset, but I'm not sure that can be done.