Print

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

[Fleeting Frames]

I just tried switching display mode to TWBT and playing around with multilevel for the first time.

Running ASCII, however, which mainly hurts grass on the first z-level going deeper (grass has natively varied tiles in hue, luminosity and appearance). Ramps are more clear - minecarts track are especially fun - if behaving slightly unexpectedly with downwards slopes (the vanilla multilevel).

I'll definitely mess around with settings a bit further, atm was pondering of something like harsher first step and multilevel 1 or 2. Then a hilly fortress dedicated to ramp romps....

But I was interrupted in my pondering by watching a badger pack migrate onto the embark, move and do their animal pathing counterclockwise spirals, into a cage trap.

That is so very awesome. Thank you.

[mifki]

Build is ready for 0.43.03-alpha1

[Meph]

Build is ready for 0.43.03-alpha1

Thank you

Edit: Is there any way to change the style of walls depending on the material they are made of? I'd like to make wooden walls to look different from stone walls.

I only found the tile types:

Code: [Select]

ConstructedFloor, ConstructedFloorTrackE, ConstructedFloorTrackEW, ConstructedFloorTrackN, ConstructedFloorTrackNE, ConstructedFloorTrackNEW, ConstructedFloorTrackNS, ConstructedFloorTrackNSE, ConstructedFloorTrackNSEW, ConstructedFloorTrackNSW, ConstructedFloorTrackNW, ConstructedFloorTrackS, ConstructedFloorTrackSE, ConstructedFloorTrackSEW, ConstructedFloorTrackSW, ConstructedFloorTrackW, ConstructedFortification, ConstructedPillar, ConstructedRamp, ConstructedRampTrackE, ConstructedRampTrackEW, ConstructedRampTrackN, ConstructedRampTrackNE, ConstructedRampTrackNEW, ConstructedRampTrackNS, ConstructedRampTrackNSE, ConstructedRampTrackNSEW ConstructedRampTrackNSW, ConstructedRampTrackNW, ConstructedRampTrackS, ConstructedRampTrackSE, ConstructedRampTrackSEW, ConstructedRampTrackSW, ConstructedRampTrackW, ConstructedStairD, ConstructedStairU, ConstructedStairUD, ConstructedWallL2D, ConstructedWallL2U, ConstructedWallLD, ConstructedWallLD2, ConstructedWallLR, ConstructedWallLRD, ConstructedWallLRU, ConstructedWallLRUD, ConstructedWallLU, ConstructedWallLU2, ConstructedWallLUD, ConstructedWallR2D, ConstructedWallR2U, ConstructedWallRD, ConstructedWallRD2, ConstructedWallRU, ConstructedWallRU2, ConstructedWallRUD, ConstructedWallUD,
I know its possible for doors, since they use different tiles in vanilla already, but I was wondering if you could somehow include this option for overrides.

[Rydel]

There was some discussion of it back here:
http://www.bay12forums.com/smf/index.php?topic=138754.msg5771011;topicseen#msg5771011
http://www.bay12forums.com/smf/index.php?topic=138754.msg5771577;topicseen#msg5771577

I think there were concerns about this making the OVERRIDE token too complicated.  A fix would be designing it to work as a block, the way  ENTITY or CREATURE tokens do.  That looks like it would be a fairly significant rewrite how how the overrides file works, but it would open the door for a lot of customization down the line.

[Meph]

Thanks.

Yeah, I'm not sure how many people would actually use it, but I think that metal, stone and wood should somehow look different. I was mostly asking for a total conversion with playable elves... they should get naturally-grown tree/bush walls, not the blocky type. I would do it with workshops and inpassable tiles, but unfortunately they are see-through. A workshop-wall made out of bushes and trees would still allow invaders to look through (and I think shoot through) it.

[jecowa]

I made a 32x32 version of the TWBT shadows.png.

Spoiler: "shadows_32x.png" (click to show/hide)

Anyone can use it for anything, if they want. Higher-resolution shadows probably aren't going to provide noticeable visual improvements, thought.

[Meph]

Official dfhack 43.03 is out: https://github.com/dfhack/dfhack/releases/tag/0.43.03-r1

The TWBT version for the 43.03-alpha dfhack did work, but the official release claims it is for another version. Aka TWBT is not working with the newest dfhack release.

[lethosor]

Yes, that's because TWBT was compiled for 0.43.03-alpha1 and won't work with anything else.

[scamtank]

exactly, that's the way it works. the plugin is compiled with suitable DFHack version hashes it's allowed to try interfacing with, encountering anything else makes the thing pack its whistles and go home

considering how there's exactly two ways it can work, "just fine" and "instant crash", this is arguably for the convenience of the user

[Meph]

Yeah. I just wanted to let mifki know that a 43.03 version was released and that an update would be nice.

[lethosor]

He's been in #dfhack working on 0.43.05 and other things, so I think he knows.

The plugin is compiled with suitable DFHack version hashes it's allowed to try interfacing with.

Actually, it just contains the DFHack version string, like "0.43.03-r1". You might be confusing this with the hashes in symbols.xml, which tell the DFHack core which versions of DF it can work with.

[mifki]

Released. Just recompiled, hope it's all ok.

[jecowa]

Thanks for the notice. I didn't realize that you had to recompile every time DFHack released an update for the same version of Dwarf Fortress.

[necrotic]

Thanks for the notice. I didn't realize that you had to recompile every time DFHack released an update for the same version of Dwarf Fortress.

Thats the case for any compiled plugin to prevent potential issues with the different versions.

[tapk]

Glad to say that game doesn't crash while building in PE's Stapter Pack 0.43.03-r03 with TWBT enabled. The bug seems to be fixed.