Print

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

[LeoCean]

Well there's a normal door and a fortified door, and then theres the hatch so 3 in that sense.

I'm pretty sure you'd need different raws if you wanted to have different leaves for the trees, it's not really that much of a problem because it'd only be a few files you'd have to change and it doesn't hurt save games.

Hmm wood doors from the raw should be 186 which is a wall upwards tile. Then 197 is the normal door. Then metal doors are 240.. 216 are door designations. (which I thought were the metal doors) You may be able to override all of those tiles, I'm not sure. If I actually had a map where I had those doors I'd check but I don't.

[Erendir]

Hmm wood doors from the raw should be 186 which is a wall upwards tile.

wooden door is inverted 186, and it's looking strange, so I'm using this:

Code: [Select]

[OVERRIDE:186:B:DOOR:Door::UDStairsTS:197]
[OVERRIDE:186:I:DOOR:DOOR::UDStairsTS:197]

[mifki]

A new Crash dump, definitely from the automaterial plugin this time .

http://dffd.wimbli.com/file.php?id=9670

Yep, this time it's me, thank you.

Sorry, I'm so tired lately, just don't use versions from autobuild server in any packs until I release new 4.xx version officially.

[mifki]

Can we already use separate tilesets for the following:
* bin, cursor, up/down stairs
I know bin and u/d stairs already worked, but what about the cursor?
* doors of various materials
* all the new tree tiles you can specify in the init files
and if so, what about specific trees? Say you want to have different leaves for deciduous and coniferous trees. Would you need to change the raws (so spruce leaves uses tile #123, and apple leaves use tile #456), and then assign them to a different tileset with twbt, or could you skip the raw changes and define, say, TREE:SPRUCE:LEAF or whatever to use #123 on tileset X and TREE:APPLE:LEAF to use tile #456 on tileset Y solely through overrides.txt without touching the raws?

There's a secret [CURSOR:tileset:tile] command but I don't recommend to use it and probably will remove it because it can replace only the original game cursor, but there's number of plugins that draw their own pseudo cursors with hard-coded 'X' and it's impossible to track and replace all of them. So I'd recommend to use X in the main tileset as a cursor and override it for bins/stairs.

Up/down stairs can be overridden in 4.xx only with an override by tiletype (see readme if didn't use it before).

Spoiler (click to show/hide)

[OVERRIDE:88:T:ConstructedStairUD:3:88]
[OVERRIDE:88:T:FeatureStairUD:3:88]
[OVERRIDE:88:T:FrozenStairUD:3:88]
[OVERRIDE:88:T:Grass1StairUD:3:88]
[OVERRIDE:88:T:Grass2StairUD:3:88]
[OVERRIDE:88:T:LavaStairUD:3:88]
[OVERRIDE:88:T:MineralStairUD:3:88]
[OVERRIDE:88:T:SoilStairUD:3:88]
[OVERRIDE:88:T:StoneStairUD:3:88]
[OVERRIDE:88:T:UnderworldGateStairUD:3:88]

Leaves are not items, but there are tiletypes for tree parts, so it's possible to override them in 4.xx only. And yes, you'll have to assign different tiles in raws if you want different tiles for different plants (and you can't use numbers >255 of course).

Spoiler (click to show/hide)

TreeBranches, TreeBranchesSmooth, TreeBranchEW, TreeBranchNE, TreeBranchNEW, TreeBranchNS, TreeBranchNSE, TreeBranchNSEW, TreeBranchNSW, TreeBranchNW, TreeBranchSE, TreeBranchSEW, TreeBranchSW, TreeCapFloor1, TreeCapFloor2, TreeCapFloor3, TreeCapFloor4, TreeCapPillar, TreeCapRamp, TreeCapWallE, TreeCapWallN, TreeCapWallNE, TreeCapWallNW, TreeCapWallS, TreeCapWallSE, TreeCapWallSW, TreeCapWallW, TreeDeadBranches, TreeDeadBranchesSmooth, TreeDeadBranchEW, TreeDeadBranchNE, TreeDeadBranchNEW, TreeDeadBranchNS, TreeDeadBranchNSE, TreeDeadBranchNSEW, TreeDeadBranchNSW, TreeDeadBranchNW, TreeDeadBranchSE, TreeDeadBranchSEW, TreeDeadBranchSW, TreeDeadCapFloor1, TreeDeadCapFloor2, TreeDeadCapFloor3, TreeDeadCapFloor4, TreeDeadCapPillar, TreeDeadCapRamp, TreeDeadCapWallE, TreeDeadCapWallN, TreeDeadCapWallNE, TreeDeadCapWallNW, TreeDeadCapWallS, TreeDeadCapWallSE, TreeDeadCapWallSW, TreeDeadCapWallW, TreeDeadRoots, TreeDeadRootSloping, TreeDeadTrunkBranchE, TreeDeadTrunkBranchN, TreeDeadTrunkBranchS, TreeDeadTrunkBranchW, TreeDeadTrunkE, TreeDeadTrunkEW, TreeDeadTrunkInterior, TreeDeadTrunkN, TreeDeadTrunkNE, TreeDeadTrunkNEW, TreeDeadTrunkNS, TreeDeadTrunkNSE, TreeDeadTrunkNSEW, TreeDeadTrunkNSW, TreeDeadTrunkNW, TreeDeadTrunkPillar, TreeDeadTrunkS, TreeDeadTrunkSE, TreeDeadTrunkSEW, TreeDeadTrunkSloping, TreeDeadTrunkSW, TreeDeadTrunkW, TreeDeadTwigs, TreeRoots, TreeRootSloping, TreeTrunkBranchE, TreeTrunkBranchN, TreeTrunkBranchS, TreeTrunkBranchW, TreeTrunkE, TreeTrunkEW, TreeTrunkInterior, TreeTrunkN, TreeTrunkNE, TreeTrunkNEW, TreeTrunkNS, TreeTrunkNSE, TreeTrunkNSEW, TreeTrunkNSW, TreeTrunkNW, TreeTrunkPillar, TreeTrunkS, TreeTrunkSE, TreeTrunkSEW, TreeTrunkSloping, TreeTrunkSW, TreeTrunkW, TreeTwigs,

In general, I'm not experienced in raws and other modding things, so again I recommend reading the readme from 4.xx version, all three override types are documented there with lists of possible values. Some other override types are planned, but if you have any ideas, feel free to write them. One of the things I do NOT want to do is to deal with materials in twbt.

Ah yes, version 4.57 fixes the crash in automaterial plugin, it was a bug in original plugin that just didn't lead to a crash without twbt.

[CLA]

[trees and stairs/bins]

I'll do that. It's good enough.

In general, I'm not experienced in raws and other modding things, so again I recommend reading the readme from 4.xx version, all three override types are documented there with lists of possible values. Some other override types are planned, but if you have any ideas, feel free to write them. One of the things I do NOT want to do is to deal with materials in twbt.

Yeah, I read the readme in the meantime. Thanks for clarification.

As for suggestions, after ctrl+f'ing my TODO list for TWBT on the readme, I'm left with one item:

* engraved floor / status icon (injury) / Bauxite

Ideally, I'd move engraved floors to a separate tileset, so I don't have to change the raws for Bauxite.

[mifki]

There are several tiletypes in that list such as ConstructedFloor, MineralFloorSmooth, StoneFloorSmooth and so on.

[Eko]

Just a quick question -

I am wondering if there's a way to make tiles transparent.  I'm looking at making pathable water transparent, instead of obscuring workshops and stockpiles underneath. 

The issue that I have right now is that the background color of water is hardcoded to blue, which means no matter what I make the tile, there's that opaque background that I can't get rid of.  Would there be any way to add a special token or something in the overrides to not draw the background color at all?

I know I found (somewhere...) a list of all the possible tokens for things that can be overridden, and I'm sure it isn't had to override only certain levels of water, but for the life of me, I can't find it again.

[mifki]

Uhm, well, making a tile image transparent will not make what's located beneath it visible.
Several pages ago I was experimenting with rendering things in several layers so that you see what's really behind items, buildings, etc. but that's very difficult to implement and far from being finished.

[Eko]

I really should have thought about that.

It only renders the top-most tile no matter what, so if there's water on top, it isn't visible.  Ok, I understand now.

Now I have to see if I can strip out the water rendering code, code cave a routine to only draw if >3 water in a tile. 

Thanks for the help.

[mifki]

Versions 3.41 and 4.61 have support for DF 0.40.12, and 4.61 also has completely untested build for Linux, it may work or may crash on load, or anything in between.

In general, now I (again) hope I've fixed all major bugs and issues with 4.xx and included plugins.

[notfood]

Neat! Linux support! I'm grateful. Which fork are you using for DFHack? I don't think main repo compiles for 40.12.

[salithus]

Neat! Linux support! I'm grateful. Which fork are you using for DFHack? I don't think main repo compiles for 40.12.

the /develop branch compiles and runs fine against 40.12 with a tweak pointed out by lethosor, but DFHack thinks its built for 40.11, so twbt doesn't fire off. just posted this in the dfhack thread:

ok, did that and it grabbed the new symbols, but it says this about twbt:

Plugin twbt was not built for this version of DFHack.
Plugin: 0.40.12-r1, DFHack: 0.40.11-r1

[mifki]

Just change .11 to .12 in cmakelist.txt in dfhack root folder.

[salithus]

Just change .11 to .12 in cmakelist.txt in dfhack root folder.

worked like a champ once I fixed my init (had FONT twice instead of FULLFONT). thanks!

[int_ua]

Versions 3.41 and 4.61 have support for DF 0.40.12, and 4.61 also has completely untested build for Linux, it may work or may crash on load, or anything in between.

In general, now I (again) hope I've fixed all major bugs and issues with 4.xx and included plugins.

twbt-3.41-linux / latest dfhack from 0.40.11-r1 branch with latest df-structures and  .12 in CMakeList.txt:

Can't load plugin /home/int/games/df/df_linux/hack/plugins/twbt.plug.so

Same with twbt-nextgen-4.61-linux. I'm on 64bit system, do I need to recompile it? Recompiling.
Ok, it worked. Just had to edit Makefile:

Spoiler (click to show/hide)

DFHACKVER ?= 0.40.12
DFHACKREL ?= r1
DF ?= /home/int/games/df/df_linux
DH ?= /home/int/games/df/util/dfhack/dfhack

Although multilevel command does nothing both on master branch and nextgen, am I missing something?
Found it, multilevel 5