Print

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

[mifki]

It's nice to be able to see more than one Z-level at once, but it can make it kind of confusing to determine which level the cursor is on.

I remind that for some tilesets, fog colour/density and shadow colours may need to be adjusted. I only use Spacefox tileset and the default parameters are tweaked for it. Other tilesets are usually darker and indeed with the default parameters it's hard to distinguish between z-levels.

[jecowa]

I remind that for some tilesets, fog colour/density and shadow colours may need to be adjusted. I only use Spacefox tileset and the default parameters are tweaked for it. Other tilesets are usually darker and indeed with the default parameters it's hard to distinguish between z-levels.

Thanks for the help. More fog sounds like what I need until I get more used to it. I remember seeing an old screenshot and wishing it could still look like that.

Spoiler: old TwbT example (click to show/hide)

But maybe a change to the fog color would also make it much more obvious to me.

[mifki]

I remind that for some tilesets, fog colour/density and shadow colours may need to be adjusted. I only use Spacefox tileset and the default parameters are tweaked for it. Other tilesets are usually darker and indeed with the default parameters it's hard to distinguish between z-levels.

Thanks for the help. More fog sounds like what I need until I get more used to it. I remember seeing an old screenshot and wishing it could still look like that.

Spoiler: old TwbT example (click to show/hide)

But maybe a change to the fog color would also make it much more obvious to me.

There are also fog start and step parameters (https://github.com/mifki/df-twbt#multi-level-rendering), so you can configure bigger difference between z-levels (with step), or bigger difference between the current z-level and the first z-level below (with start).

[jecowa]

Is it the eventual plan for this repo to have PyLNP use it to auto update its tilesets? If so, is there any special format for commit messages or something we should use to make it readable by PyLNP?

[PeridexisErrant]

No, there are no plans for auto-updates.

I've written a tool that downloads the latest version, but that simply operates on the latest tag/release (so be sure to hit the 'release' button on GitHub when it's ready).

Best practice for git commit messages is pretty easy to google up; basically a short one-line summary, then a paragraph explaining in more detail if required (usually not, for this project).

[jecowa]

I've been watching starter-pack.log trying to figure it out. I was starting to think that it didn't update things automatically. I flagged a commit on Phoebus for DF v0.43.03, but nothing seemed to happen.

[jecowa]

Is it okay to update Rally-Ho on the repo for DF v0.43.03, or should I send a pull request?

Just line 62 of inorganic stone layer needs updating (to remove the [REACTION_CLASS:FLUX] bit).

[Rydel]

I can update it tomorrow directly.  I've just been a bit busy on another project.

Edit: Updated.

Also: Rally Ho! uses separate plant raws for Text Will Be Text.  This can cause some unwanted behavior if the user isn't using TWBT.  Currently, I have a separate download on DFFD without the plant raws and with a different init.ini file, but I'm not sure of the best way to handle it for the GitHub repo.  I put in instructions for non-TWBT users, but if someone's using it through LNP, they likely won't see that file.

[jecowa]

Do you think it's okay to update AutoReiv's pack on the repo? He just needs a few config settings added to his d_init.txt for compatibility with Dwarf Fortress v0.42.01 through v0.43.04.

[PeridexisErrant]

Of course it's fine, the fact that anyone who has time can do all the basic updates is practically the whole point of the DFgraphics project and group!

Other goals were added later, but even they boil down to 'make that as easy as possible'.

[jecowa]

Unless HaterSkater is against it, is it okay to add Duerer to the repo? It doesn't look like he had a problem with fricy having his own distribution of Duerer, since he's still linking to it in his OP.

While the non-TWBT version still works fine, the TWBT version of Duerer could use a little work. I kind of thought this pack would already be on the repo, since I think the DFGraphics repo originated as fricy's graphics repo. Maybe Duerer was removed at some point? It's listed in the OP as being one of the packs maintained here. Maybe I'm just overlooking it?

[burned]

. . . I kind of thought [Duerer] would already be on the repo . . .
. . . Maybe Duerer was removed at some point?
. . . Maybe I'm just overlooking it?

Based on what I understand about the LNP (and this post), it wasn't so much the character tileset versus creature tileset distinction that concerned him, so much as it came down to "Does this set need modified graphic raws?" If the answer was no, he removed the set from the graphics repo.

In other words, I don't believe PE removed Duerer from his LNP, so much as "a graphics pack must contain graphics raws, or be one of the two ASCII special cases" when it comes to the repo.

Just a guess, since Duerer is a character tileset and not a creature tileset.

[jecowa]

That's interesting. Maybe this explains why I can never remember which graphics packs are in the repo. I keep thinking Grim Fortress is in there. It seems that the default Curses graphics were in the repo at one point too. It looks like these are the ones that were removed:

• Curses
• Duerer
• Grim-Fortress
• MLC-ASCII
• Shizzle
• Tergel
• Vherid

It looks like Jolly Bastion was one of the two special cases. I guess it got to stay because it modifies an objects file. That why I was wanting Duerer on here, because it modifies 3 objects files to assign custom tiles.

I wonder what the other special case was. Maybe AutoReiv didn't have racial graphics at the time? I guess Tergel didn't have racial graphics at the time either. Maybe this is why he added them.

[PeridexisErrant]

As I recall it was just the issue of graphics raws - but I have no objection to packs with object raws if someone is maintaining them.

Really its just that a little extra has to be drawn between tiles eland graphics pack *somewhere* (too many of the former and they need no maintenance), and this seemed like a good idea at the time. Now that there are multiple members, I'd be happy for someone else to decide

[jecowa]

I was wanting to provide updates for Duerer 0.6.A on the repo. You would have to initialize it, though, since you're owner. It shouldn't be to hard to keep updated with just three objects files.