Print

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

[DragonDePlatino]

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.

I haven't played Minecraft in a while so I took the opportunity to check out one of these new-fangled "resource packs".

...Holy cow! 8o Texturing one of those looks like it'd be a nightmare! Sure, you've got all of those file names, but editing the big terrain.png was already hard enough. Minecraft's insanely popular compared to DF, though, so I wouldn't be surprised if there are tools to streamline the process. I can agree about the end user thing, though. When it comes down to it, the end users outnumber the artists by the thousands. :I

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.

Crikey! Do ya see it there? It's tha rare "internet agreement" in it's natural habitat!

...Joking aside, this is a very nice compromise. I wrote all of GemSet's raws from scratch so I wouldn't mind putting in a little extra work to get a nice setup.

[mifki]

Also, I must say, apart from tileset authors who actually draw their tiles, there are people reusing and adapting already available graphics, especially when it comes to custom overrides for some items and buildings and not a complete tileset. In such case, again, it's much easier to drop a file you found somewhere to see how it looks in DF, and there are no problems you mentioned with palette and operations on all tiles at once. And this scenario I had in mind. Saying this just so that you don't blame me for a decision against artists:)

[PeridexisErrant]

Also, I must say, apart from tileset authors who actually draw their tiles, there are people reusing and adapting already available graphics, especially when it comes to custom overrides for some items and buildings and not a complete tileset. In such case, again, it's much easier to drop a file you found somewhere to see how it looks in DF, and there are no problems you mentioned with palette and operations on all tiles at once.

Have you considered looking in the raws for these images?  That would let mod authors seamlessly extend or override tiles, and enable PyLNP to handle everything. Just a thought... which I know Dirst has also been promoting lately.

[mifki]

Also, I must say, apart from tileset authors who actually draw their tiles, there are people reusing and adapting already available graphics, especially when it comes to custom overrides for some items and buildings and not a complete tileset. In such case, again, it's much easier to drop a file you found somewhere to see how it looks in DF, and there are no problems you mentioned with palette and operations on all tiles at once.

Have you considered looking in the raws for these images?  That would let mod authors seamlessly extend or override tiles, and enable PyLNP to handle everything. Just a thought... which I know Dirst has also been promoting lately.

What do you mean? Or a link.

[LeoCean]

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.

Unless the overrides they are overriding have the same tilesheet name they wouldn't have to use a image editor if they are truely lazy. At that point the only copy and pasting is in the text file.. Anyways this is looking like it's going to be awesome, I haven't really been keeping up though.

[DwarfCon5]

I don't get it. Are there any screenshots?

[mifki]

I don't get it. Are there any screenshots?

Spoiler (click to show/hide)

[Dirst]

Also, I must say, apart from tileset authors who actually draw their tiles, there are people reusing and adapting already available graphics, especially when it comes to custom overrides for some items and buildings and not a complete tileset. In such case, again, it's much easier to drop a file you found somewhere to see how it looks in DF, and there are no problems you mentioned with palette and operations on all tiles at once.

Have you considered looking in the raws for these images?  That would let mod authors seamlessly extend or override tiles, and enable PyLNP to handle everything. Just a thought... which I know Dirst has also been promoting lately.

What do you mean? Or a link.

The bits of the discussion you missed concerned getting the PyLNP mod manager to handle Stonesense content.  Pretty much anything stored under raw/ can be handled with little or no effort for the starter-pack folks.  It could be some dummy tag in the raws themselves, or more likely TWBT-specific files tucked under a subfolder.  The only complicated bit is how to handle collisions (two different mods trying to apply graphics to the same item).  The merged raw/ folder might end up with a specifically-named single image AND a configuration file entry for the same item.  Possibly multiple entries if modders name their configuration files differently.  All that's really needed is a consistent way of handling duplicate instructions (first-in-wins or last-in-wins).  If the structure is ragged such that entries can have highly variable lengths in memory, then I'd probably suggest first-in-wins and skip any duplicates.

[PeridexisErrant]

The bits of the discussion you missed concerned getting the PyLNP mod manager to handle Stonesense content.  Pretty much anything stored under raw/ can be handled with little or no effort for the starter-pack folks.  It could be some dummy tag in the raws themselves, or more likely TWBT-specific files tucked under a subfolder.

The plan as I understand it is to check the data/art/ subdir for individual tiles, and if not found look for the data/art spritesheet and config file.  Am I correct in this?

My proposal is to look for the file structure you've designed for data/art in the raws first (assuming first-on).  Specifically, duplicate the logic and file structure for data/art/ in <savedir>/raw/twbt/, then the same in the main raw folder, then in data/art/, and finally the spritesheet in data/art/. 

This means modded saves can overwrite particular sprites, saying "in this mod, <item> looks like <this> instead of the normal look".  Storing data in the raw dir makes modded saves portable, enables conflicting mods in the same install, and a few other nice tricks.  It's also easy for PyLNP and similar tools to handle - as long as files can be replaced atomically, which is the case for the new system (yes?) but not spritesheets.  I thus suggest only allowing the new system in the raws.

Happy to discuss further, of course.

[DragonDePlatino]

...What is the difference between overwriting a BOULDER and a ROCK? Is this some sort of DFHack fluke?

[OVERRIDE:7:I:BOULDER:BOULDER::items:28]

When I did that overwrite, it gave all of the dropped rocks (•) a tile. You'd think it would overwrite the big boulders (∞) but that's actually handled with the tile override StoneBoulder. Now it's time for me to do an override for ROCK and I have no idea what'll happen or what tile I'm looking for.

[scamtank]

One's an item, one's a tile feature like driftwood. ROCKs are the sort of knapped stones you see in adventure mode.

[Max™]

Yeah, the knapped stones or ones you gather from the ground, small granite rock, an obsidian, and obsidian boulder would be the one displayed on the ground.

[DragonDePlatino]

Thanks! I've done some in-game testing and I think I understand the difference between boulders and rocks now. I still find the name a little weird, though. Why not ROCK and STONE?

[Max™]

Ask the Toad?

[DragonDePlatino]

Toady One? I assumed BOULDER and ROCK were names the DFHack developers gave to the memory values. They also mixed up GrassLightFloor and GrassDarkFloor so I wouldn't be surprised.

Anyways, is it possible to overwrite PETs and VERMIN? I've been screwing around with overrrides like

[OVERRIDE:109:I:VERMIN:VERMIN::items:96]
[OVERRIDE:111:I:VERMIN:VERMIN::items:97]
[OVERRIDE:123:I:VERMIN:VERMIN::items:98]
[OVERRIDE:126:I:VERMIN:VERMIN::items:99]
[OVERRIDE:249:I:VERMIN:VERMIN::items:100]

And I can't seem to get it working. I've even tried a huge number of subtypes and nothing seems to work.

EDIT:

I've also discovered another interesting quirk. And unlike the glitchy material colors, I don't think the next release will address this.



[OVERRIDE:17:I:SIEGEAMMO:SIEGEAMMO::items:129]
[OVERRIDE:196:I:SIEGEAMMO:SIEGEAMMO::items:130]
[OVERRIDE:174:I:SIEGEAMMO:SIEGEAMMO::items:131]

Siege ammo won't display properly! D: I'm positive that I'm targeting the right tiles, but I could only change the middle tile (the shaft). Does TWBT only target a single coordinate for each tile override? To get this working, I think you might need to check the tile left and right coordinates of an item if it is SIEGEAMMO.