Print

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

[jecowa]

I've noticed that some packs in the repo change some settings from their defaults.

Spoiler: list of settings that graphics packs probably shouldn't be changing (click to show/hide)

init.txt:

• sound
• volume
• intro
• windowed
• windowedx
• windowedy
• g_fps_cap
• vsync
• zoom_speed
• macro_ms

d_init.txt:

• autosave
• autosave_pause
• initial_save
• embark_warning_always
• economy
• show_embark_tunnel
• embark_rectangle
• coffin_no_pets_default
• population_cap
• baby_child_cap
• show_flow_amounts

I'm guessing these are being changed to the settings that fricy liked to play with. I think that these all should be set back to default, though.

1. It's not really the business of a graphics pack to change settings completely unrelated to graphics.

2. The Lazy Newb Pack doesn't allow graphics packs to modify these settings anyway.

3. For users not using a Lazy Newb Pack who are using custom settings in their d_init.txt or init.txt, they will probably expect that those will get reverted back to default settings when they install a graphics pack. But users using vanilla settings in those files will probably be confused when they stop getting migrants or when the sound turns off.

I'm not seeing an advantage to these settings being set to something other than default. Even if the custom settings are better, I don't think this is the way to go about getting people to change their settings. I've been switching the above listed settings back to their defaults when updating packs in the repo.


There's a few settings, though, that perhaps graphics packs should be able to modify, but I'm not completely sure about:

• engravings start obscured
• varied ground tiles
• show flow amounts

Do you think graphics packs should be allowed to modify any of those? Currently the Lazy Newb Pack doesn't allow graphics packs to modify any of those three. Should a graphics pack artist have any control over any of those?

[Taffer]

Spoiler: list of settings that graphics packs probably shouldn't be changing (click to show/hide)

init.txt:

• sound
• volume
• intro
• windowed
• windowedx
• windowedy
• g_fps_cap
• vsync
• zoom_speed
• macro_ms

d_init.txt:

• autosave
• autosave_pause
• initial_save
• embark_warning_always
• economy
• show_embark_tunnel
• embark_rectangle
• coffin_no_pets_default
• population_cap
• baby_child_cap
• show_flow_amounts

• engravings start obscured
• varied ground tiles
• show flow amounts

Do you think graphics packs should be allowed to modify any of those? Currently the Lazy Newb Pack doesn't allow graphics packs to modify any of those three. Should a graphics pack artist have any control over any of those?

I don't believe I modify any of that (let me know if I do) and I agree that graphics packs shouldn't modify the settings you specified. Almost all of them are clearly personal preferences and have nothing at all to do with the graphics: with a few exceptions, which I shall detail below.

I think it's important to exempt the following:

 • intro,
 • engravings start obscured, and
 • varied ground tiles.

In my opinion, all of the above look pretty lousy with the default settings for any graphics pack or tileset that isn't an ASCII lookalike (most of them). In addition, several sets are drawn with the assumption that varied ground tiles are turned off, so reverting that breaks visual consistency. It would be a mistake in my opinion to revert any of these settings for graphics sets that weren't meant for them.

You didn't mention it and it's not obvious, but I find that zooming looks much better for my set with texture_param set to nearest, so I do think that setting is also acceptable to modify.

[jecowa]

I don't believe I modify any of that (let me know if I do) and I agree that graphics packs shouldn't modify the settings you specified. Almost all of them are clearly personal preferences and have nothing at all to do with the graphics: with a few exceptions, which I shall detail below.

Yours is good. I noticed on the DFGraphics repo that your first edit was setting all those back to default.

I think it's important to exempt the following:

 • intro,
 • engravings start obscured, and
 • varied ground tiles.

In my opinion, all of the above look pretty lousy with the default settings for any graphics pack or tileset that isn't an ASCII lookalike (most of them). In addition, several sets are drawn with the assumption that varied ground tiles are turned off, so reverting that breaks visual consistency. It would be a mistake in my opinion to revert any of these settings for graphics sets that weren't meant for them.

Maybe we can get "engravings start obscured" and "varied ground tiles" whitelisted in the Lazy Newb Pack. I don't think odd-looking intros are a very big deal.

You didn't mention it and it's not obvious, but I find that zooming looks much better for my set with texture_param set to nearest, so I do think that setting is also acceptable to modify.

I think I like "Nearest" scaling best too. It doesn't work with "2D" rendering, though. It will work with "Standard" and maybe "TWBT", though. But the TrueType font feature only works with "2D".

Currently the Lazy Newb Pack already allows graphics packs to modify TrueType Fonts, Print Mode, and Texture_Param (Scaling Method). You can see the full white list by going to the graphics.py page and searching for "_fields = [" without the quotes.

Edit: Oh, it looks like graphics packs actually aren't allowed to change the texture_param.

[Rydel]

Is suspect that most packs that change these (not sure if mine does) come from the author basing it off their own init file, forgetting that they'd made modifications to it.

Does Rally Ho! change any of those?

[jecowa]

Is suspect that most packs that change these (not sure if mine does) come from the author basing it off their own init file, forgetting that they'd made modifications to it.

Does Rally Ho! change any of those?

No, it doesn't change any of those. It makes engravings start obscured, but I think that's an okay thing to do.

[PeridexisErrant]

In response to the init field question:  on the PyLNP end, I've opened this issue to have the launcher handle more - I think this is now the full list of graphics-related init fields.

On the DFgraphics side of things, once I get to writing some automated tests it should be easy to ensure that we only change whitelisted fields.  Tests and better documentation have been planned for a long time... but they're moving up my todo list, now that the pace of updates has slowed and I've written PyLNP a new-pack-from-old importer.

[Taffer]

In response to the init field question:  on the PyLNP end, I've opened this issue to have the launcher handle more - I think this is now the full list of graphics-related init fields.

I don't have a bitbucket account, but I'm not sure it's necessary to modify SHOW_FLOW_AMOUNTS. Some tilesets draw 1-7 with water graphics with that setting in mind, but in every case disabling the setting doesn't disrupt the aesthetic as the artist also needs to draw the water tile. The majority of graphics packs that I've seen modifying that setting don't do anything special with 1-7 and the set actually looks better with it off. It's simply the artist's preference.

Still, I'm content to be overruled on this. I clearly have bias: I prefer the setting as default. If it does stay, perhaps it can be disabled for sets that weren't drawn with it in mind (1-7 appear as normal numbers).

[CLA]

I'm in the same boat as Taffer on this, SHOW_FLOW_AMOUNT is definitely a personal preference for me, but contrary to other personal preferences (varied ground tiles for example), that doesn't have any impact on the tileset art or color scheme, and consequently, it's not necessary to modify it for my tileset.

[jecowa]

Taking off "show_flow_amounts" sounds good to me. I don't know of any tileset that tries to change that.

For the "varied_ground_tiles" setting, Grim Fortress and Jolly Bastion are the only tilesets I know of that try to disable that. I'm not very familiar with this stuff, but from looking at Jolly Bastion's tilesheet, it looks like it's designed to only use the period for the ground and not the comma.

I'm kind of curious about the "mouse_picture" setting. I don't think that feature currently does anything. There aren't any tilesets that try to change it, but GemSet includes a custom "mouse.png". But I'm pretty sure it only includes that to fulfill PyLNP's requirement that all graphics packs include both a "mouse.png" and "font.ttf".

[CLA]

PyLNP's requirement that all graphics packs include both a "mouse.png" and "font.ttf".

There was an issue with a library on OSX/Linux if I understood that correctly:
http://www.bay12games.com/dwarves/mantisbt/view.php?id=2688

[jecowa]

There was an issue with a library on OSX/Linux if I understood that correctly:
http://www.bay12games.com/dwarves/mantisbt/view.php?id=2688

I guess this bug report is saying that it's a bug that Dwarf Fortress requires both a "mouse.png" and a "font.ttf" to run?

I was thinking PyLNP could leave behind the default "mouse.png" and "font.ttf" files in the art folder so that every graphics pack doesn't have to include them both. If a graphics pack did include a custom font or mouse, then they would overwrite the defaults when that graphics pack was copied over.

Or if there's a problem with that method, maybe PyLNP could check if there was a "mouse.png" and "font.ttf" in the art folder after installing a graphics pack and copy over those files from the baselines folder if needed.

Or how does it do it with the reduced raws format? It might be easiest to do it however it does it with that. That is already being used for the raw/objects/ and data/init/ folder, it probably wouldn't be too hard to expand it to work on those two files in the data/art/ folder.

[PeridexisErrant]

If you put those files in "LNP/Tilesets/", they can be omitted from graphics packs.

It should be pretty easy to pull them from the vanilla copy if missing, too - I'll make a pull request to add that to PyLNP.

[jecowa]

Thanks for the tip!

[jecowa]

That would break the desirable property that copying graphics over a DF install correctly installs the graphics - we want them to be very simple to do manually or automatically.

An alternative approach (which I prefer) would be to add "twbt_data" and "raw/twbt_objects" folders, and copy them over the non-twbt pack if TwbT is enabled.  Regardless, any further discussion should happen in the DFgraphics thread, as it's not really about the Starter Pack.

That sounds good. I was thinking that they could share art folders, but it would be kind of nice to have separate art folders.

I did some testing to see how many extra MB all these duplicate folders would take in the DFHack Lazy Mac Pack.

Spoiler: graphics packs with TWBT overrides: (click to show/hide)

• Afro_16x
• AutoReiv_10x
• AutoReiv_20x
• Duerer_15x
• DungeonSet_24x
• GemSet_24x
• Ironhand_18x
• Mayday_16x
• Obsidian_16x
• Phoebus_16x
• Rally_Ho_16x
• Spacefox_16x

At first glance it looks like duplicating the data folders of all graphics packs with TWBT overrides would take an extra 14.9 MB, but after removing all the TWBT overrides stuff it goes down to 9.9 MB, and then removing DejaVu Sans brings it down to 6.2 MB. Then compressed in a zip, it's only an extra 4 MB.

Duplicates of the raw/objects folder of TWBT graphics packs are an extra 13.1 MB. I'm really surprised that text files take up so much space. But they compress very well. They only take up 958 KB compressed in a zip file.

So in total, it would be like an extra 5 MB for the user to download.

[PeridexisErrant]

The trick would be to only retain twbt_X files that are different to the standard ones - I think that would cut the file size down some more.