Print

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

[Meph]

Since you collect and update sets, you might want to know that traps can use overrides for each trap type. I haven't seen anyone using it, so here you go, in case you want to add that feature to any set.

Code: [Select]

[OVERRIDE:old-tile:B:TRAP:Trap:1:new-tileset:new-tile] pressure plate
[OVERRIDE:old-tile:B:TRAP:Trap:2:new-tileset:new-tile] cage
[OVERRIDE:old-tile:B:TRAP:Trap:3:new-tileset:new-tile] stonefall
[OVERRIDE:old-tile:B:TRAP:Trap:4:new-tileset:new-tile] weapon

[mifki]

Levers are traps too with subtype 0 and track stops with subtype 5.

[Meph]

Oh... didn't knew about the levers. That gives 2 more free tiles in the main tileset.

[jecowa]

Instructions for switching graphics pack to use TWBT:

• Move onLoad.init to the /raw/ folder.
• Move the contents of /data/twbt_art/ to /data/art/.
• Move the contents of /data/twbt_init/ to /data/init/.
• Move the contents of /raw/twbt_graphics/ to /raw/graphics/.
• Move the contents of /raw/twbt_objects/ to /raw/objects/.

This is so the TWBT versions can have alpha transparency on the main tilesheet and creatures, and non-TWBT versions can have simplified language files and true black color palettes (for TTF fonts). And also there's some difference in other objects files that might be needed for keeping tiles in different spots for overrides or using TWBT's large color palette feature. And also different print modes.

[jecowa]

I'm thinking about moving the onLoad files back into the /raw/ folder. I moved them out as part of separating TWBT stuff from non-TWBT stuff, but now that PyLNP can take the GitHub repo graphics packs and move all the files around to their proper places to enable the TWBT features (except for the onLoad file), and since the onLoad file shouldn't affect anything if it's installed without TWBT (except maybe some errors in the DFHack Terminal), it would probably be nice to have it back in the /raw/ folder so it's in the place it needs to be.

Just curious if anyone has any opinions for or against moving the onLoad_gfx.init file back to the /raw/ folder.

[CLA]

I don't know anything about TWBT and PyLNP. What's the difference? As far as I understand, the file needs to be in the /raw/ folder to work correctly, and if it's not there, users have to move it manually. Is that correct?
What about other LNP-like utilities? Do they all work the same?

[jecowa]

Yeah, it doesn't do anything unless it's in the /raw/ folder. A lot of the graphics packs include both a TWBT version and a non TWBT version. Those packs are in non-TWBT form until the TWBT parts of those packs are moved into the main parts. (e.g. moving /data/twbt_init/ into /data/init/).

I don't understand the question about LNP-like Utilities? Are there alternatives to PyLNP?

[CLA]

I don't understand the question about LNP-like Utilities? Are there alternatives to PyLNP?

I thought so. Isn't there one for Mac, one for Linux, the original LNP, etc? I'm probably wrong though, I never used these packs.

Those packs are in non-TWBT form until the TWBT parts of those packs are moved into the main parts.

So users will still have to move the other 4 folder contents, even if onLoad.init is placed by the maintainer?

[jecowa]

All three packs today use PyLNP, but I just checked out the old MacNewbie launcher made by iXen, and it still works on Mojave and probably Catalina too. It wouldn't be compatible with the separated TWBT components, but it's already not compatible with the reduced raw format used by PyLNP graphics packs.

If the onLoad.init is in a graphics pack's /raw/ folder, PyLNP and MacNewbie will both install it into the proper location. Before PyLNP was able to install the TWBT components itself, LNP maintainers would need to move the TWBT files into the proper folders if they wanted the TWBT version of the graphics pack in their LNP. Anyone wanting to make a pack with one of the predecessors to PyLNP should probably install those themselves if they want the TWBT or maybe include two copies of the same graphics pack if they want both versions.

[CLA]

I see, thanks. So, back to the original question then: the proposed change looks good.

[PeridexisErrant]

Sounds good to me too.  Thanks for all your work on this Jecowa <3

[jecowa]

I just figured out how to add graphics packs to the repo.

[rmblr]

@fricy @PeridexisErrant Could I propose adding a "Colors" repo to the DFGraphics github org?

We could definitely use a single repo containing community colors.

Edit: scratch that, apparently the lnp shared core project has it https://github.com/Lazy-Newb-Pack/LNP-shared-core/tree/master/colors

[FantasticDorf]

I thought i already P2W on this, but grim fortress isn't compatible with the new sets and needs some maintenance, mainly in the areas of updating the init from its download links with contempoary tree tiles.

It is very very pretty when it works however, some of my best forts.

[jecowa]

Is there any point in keeping the “ASCII” versions of these graphics packs updated ice they are converted to the new graphics format? I can go back and make a branch or something from an old commit at a later point if it turns out they’re needed, right?