...Holy crap.
...Holy crap.
I haven't seen crashes so far, but switching to standard rendering means goodbye to TTF since the current renderer doesn't support TTF over OpenGL, and in windowed mode the graphics is blurred. In fullscreen it looks good.It's already open: https://github.com/Baughn/Dwarf-Fortress--libgraphics-
And as for TTF: The current display code is in serious need of upgrading, I really hope Toady will consider opening this part of DF (on linux it's already done...) and we can go with lnxt's rewrite (http://www.bay12forums.com/smf/index.php?topic=94528.msg4350663#msg4350663) which has better TTF support, and then separating fonts from graphics could be done in the graphics code, and not in a dfhack plugin.
But even if he does not, we still have this option: If we can agree on a standard tileset for fonts I'm ok with lack of TTF, the cutoff can be annoying, but my preliminary testing didn't uncover anything serious. The possibilities are very good once the tile authors start supporting it, as they'll have much better freedom for creating graphics.
Bugreport: Both Ctrl-S (save macro) and Ctrl-M (browse mechanism dfhack plugin) refreshes the display to use only the font tileset. Changing Z-levels will reset the screen to the desired display. Overall I'm impressed with this, and will upload a new MacNewbie for beta testers.
TTF rendering ... currently has problems with ... not being used on some screens (I wonder why) and in text output by dfhack plugins.Truetype can only be used on viewscreens which Toady has actually coded to work with TrueType - most notably, the "text viewer" (used for thoughts/preferences, item descriptions, in-game help, etc.) does not support TrueType.
/snip...but as Meph commented Toady is against this, so I'll just shut my mouth. :)
The basic idea is to get rid of any platform-dependent code in the main executable and to make the rendeder live in .dll on win32 while at it. There are five interfaces - musicsound, textures (creature graphics index), keyboard (keybindings, ...), platform (read/write/create/delete files, messageboxes, ...) and the renderer (which isn't finalized yet).
First stage would be a (fully functional, of course) libgraphics.so which instead of containing all the PRINT_MODE and musicsound implementations, will dynamically load them.
After that I hope to persuade Toady to extract whatever code uses the sdl12 calls and is still not in g_src, so that executable itself will not in any way depend on third-party libraries. With some win32-specific glue code and recompilation of the game for win32 using my work, we will at last have means to swap around renderers in win32 too.
@fricy: you're on OS X so it's trivial to copy and email me crash log(s) to check.I think I figured it out: Somehow the dfhack.init causes some instability on my system. It's not a specific setting, but the order of the settings in the init file. I was playing around with:
fix/cloth-stockpile enable
fix/feeding-timers enable
fix/growthbug enable
and wanted to change the order, to put them close to each other and the game started crashing right after launching the game before your plugin kicks in.I had a discussion with lxnt, baughn and Toady, and later on another with Taffer, Baughn and Toady. Baughn would like to update the graphics significantly, but cant work without source access. Toady understands this, but wont give this access. (which is perfectly within his right to do)
If this works on specific workshop tiles, you could add an unlimited amount of custom pics for workshops, as detailed as you like... just take a 256x256 png, chop it up into 16x16 tiles and build a large, 16 tile x 16 tile workshop... and voila, it will look like the original png.
Regarding the plugin, manually hacking into the vtables is a very bad approach when dfhack has an already available vtable interposing (http://github.com/DFHack/dfhack/blob/master/library/include/VTableInterpose.h) API, which doesn't require any weird inline assembly, and even allows different plugins to define hooks for the same methods without conflicting.
Another thing is that renderers don't have the right to access any game objects, because rendering is run in a different thread and is only synchronized for a buffer swap. Thus, the appropriate way to do such thing is to hook the render vmethod of viewscreen_dwarfmodest (using the interposing API is a must, because other plugins already hook it), and work with the tile arrays via the Pen API. In order to make the game load the necessary tile images, you can assign one of the tiles in your bitmap as a graphical icon for something silly and impossible like "cat miner ghost" via raws, and then use findGraphicsTile to look up the index.Yes, threads issue is a good point, I'll think about this.
Why not just go ahead and read the exact item type and allow individual items or letters to all point to separate graphics if desired? For example, animal traps and small mountain biomes are both in the graphics area. If using memory reading anyway, should be able to fairly simply assign separate graphics to each.
Is there a way to give grass tiles a specific character and soil floors a different one?
These renderer classes are not in dfhack (and we even don't know which one is actually used), so "manually" (in quotes because that's what dfhack is doing anyway) changing vtable is the natural way to override couple methods. "Weird" assembly is required because of the special C++ calling convention used on Windows, dfhack is also doing something weird to overcome this, but I'm not sure.
Anyway, these classes are not in dfhack, so it's pointless to talk about what would be possible to do if they were there.
Also, messing with renderers is also not something to be undertaken lightly because of the threading limitations; it is also not needed unless you are doing something well beyond the current capabilities, like warmist's lighting plugin.The first part of my plugin (for separate text font) doesn't have any threading issues as it does not access game objects. And renderer's update_tile() that exists specifically to update texture coords for changed tile is the best place to specify different coords in terms of speed and logic.
However, when you are going that far, you might as well subclass the base class and implement vmethods normally.
But since you're using memory access anyway, why base it off of text area versus graphics area???And this would be (for me) even better than Caldfir's stonesense overlay. So many display upgrades...
Why not just go ahead and read the exact item type and allow individual items or letters to all point to separate graphics if desired?
This is one of the most beautiful things i've ever seen. Maybe even better than rendermax....Holy crap.
So I can't seem to figure out how to use this. I put the plug.dll into the dfhack plugins folder, but DFHack doesnt want to see it apparently?
Oh now I understand the font/graphics font thing, I'll mess around thanks.
Edit: So I guess one thing to note is that by using this it seems to not use the graphic raws, for example spacefox's different dwarves. It seems to just show them all as if you weren't using the graphics and only the tileset which means they all look like dead dwarves.
I wrote this small plugin for myself because I was tired seeing coffins instead of zeroes and all that stuff. It allows to specify separate fonts for map tiles and for text. GRAPHICS_FONT/GRAPHICS_FULLFONT will continue to be used for map area(s), and FONT/FULLFONT will be used for everything else. Requires OpenGL PRINT_MODE (STANDARD, VBO and so on). Adventurer mode and possibly some other screens need some more work.
Also it allows to override tile numbers for buildings and items, see overrides.txt for details.
Supports OS X, Windows.
At DFFD http://dffd.wimbli.com/file.php?id=8575
Just saying that I am watching this with interest. :)
Does it still clash with Rendermax?
Ok I'll make a binary for r4 soon.
I'm sorry, could we have some installation instructions for those of us with minimal tileset and init knowledge? ;D
Mifki, do you have a bitcoin address I can send some donations to? This is amazing.
I'll be able to check it with bins later.
Can you try something else in the meanwhile? Doors definitely worked, just remember that doors can be both Items and Buildings.
[OVERRIDE:197:I:DOOR:::0:87]
[OVERRIDE:197:B:DOOR:::0:87]
Added the two lines above to init.txt, changed the print mode to STANDARD (also tried VBO).
For the starter pack - is there some way I can have the plugin active for some graphics packs but not others?
While great for Spacefox, there are people who might be annoyed if it changes the pure ASCII they love...
Added the two lines above to init.txt, changed the print mode to STANDARD (also tried VBO).
Stop. You put overrides.txt to data/init folder, not adding lines from it to init.txt
For the starter pack - is there some way I can have the plugin active for some graphics packs but not others?
While great for Spacefox, there are people who might be annoyed if it changes the pure ASCII they love...
Well, it acts according to the configuration (FONT/FULLFONT for text and GRAPHICS_FONT/GRAPHICS_FULLFONT for the map) - if they are set to the same tileset, it won't do anything (and won't load itself).
I'm sorry, could we have some installation instructions for those of us with minimal tileset and init knowledge? ;D
Assuming you're already using some graphical tileset, have dfhack r3 installed and all is working fine, then to have separate tilesets for the map and text:
1. Copy appropriate plugin binary (.so on OS X or .dll on Windows) to hack/plugins folder.
2. Copy supplied ShizzleClean.png file to data/art folder.
3. Edit data/init/init.txt and make sure PRINT_MODE is set to STANDARD (or VBO), and change FONT and FULLFONT to ShizzleClean.png.
4. Enjoy.
Esc key causes ascii to appear (When using a tileset)
Activating Alt-W (workflow) causes the tileset to be unloaded. alt-tab out of the game and back in or hitting some directional keys gets the tileset to reload.
Esc key causes ascii to appear (When using a tileset)
Activating Alt-W (workflow) causes the tileset to be unloaded. alt-tab out of the game and back in or hitting some directional keys gets the tileset to reload.
It appears only momentarily (blinks), right?
I'll check Alt-W, thanks.
Is there any way that the same concept of this utility for glyphs also be applied to color schemes? I.e., specifying overrides and zones where one color scheme is used in one place and another in another?
So that you can have more than 16 colors, of course.... (and more than 8 non contingent colors). Same exact concept as the glyphs?Is there any way that the same concept of this utility for glyphs also be applied to color schemes? I.e., specifying overrides and zones where one color scheme is used in one place and another in another?
Should be possible, but can you explain why do you want this?
So that you can have more than 16 colors, of course.... (and more than 8 non contingent colors). Same exact concept as the glyphs?Is there any way that the same concept of this utility for glyphs also be applied to color schemes? I.e., specifying overrides and zones where one color scheme is used in one place and another in another?
Should be possible, but can you explain why do you want this?
You don't want mountains and animal traps to have to share the same tile, etc. Well, you might also not want walnut wood to look the same as maple wood either (which they don't at all). Without more than one color reasonably close to brown, you don't have that option.
The colors in the raws are well-defined with exact RGB values, which is convenient.Yes, the game recognizes a bunch of colors, but it displays them in 16 buckets. A wonderful tweak would be to display things according to the RGB values, but lots of things in the game have tile/item colors unrelated to the material colors they inherit from a template. For example, all stone of all types in vanilla is GRAY.
The colors in the raws are well-defined with exact RGB values, which is convenient.Yes, the game recognizes a bunch of colors, but it displays them in 16 buckets.
What's changed? Well, we can customize the grid size now. And, um, limited Truetype support on Windows.Truetype works on all platforms.
Source: Mike Mayday's full graphics suggestion thread (http://www.bay12forums.com/smf/index.php?topic=41266).I almost implemented this stuff few times already, just to show that it's possible. But due to time constrains (and my attension span being similar to fruit fly's) it has not yet come to pass.
The thread on depth by darkening (http://www.bay12forums.com/smf/index.php?topic=30114) may also be relevant, at which stage the Rendermax thread on multi-view rendering (http://www.bay12forums.com/smf/index.php?topic=128487.msg4463100#msg4463100) looks pretty similar and it might be worth getting Warmist on board for the ability to render arbitrary parts of the map.
Up/Down tiles are ramps and edges of z-levels. They look like arrows pointing up or down. Ponds/River have them as well.
If you want something really difficult as a project, someone posted this mock-up in the suggestions thread for dfhack plugins:(seeing that the url points to goblinart, I'd say that Mike Mayday himself did this. You can also see lots of up/down tiles on it. :)Spoiler (click to show/hide)
Source: Mike Mayday's full graphics suggestion thread (http://www.bay12forums.com/smf/index.php?topic=41266).
The thread on depth by darkening (http://www.bay12forums.com/smf/index.php?topic=30114) may also be relevant, at which stage the Rendermax thread on multi-view rendering (http://www.bay12forums.com/smf/index.php?topic=128487.msg4463100#msg4463100) looks pretty similar and it might be worth getting Warmist on board for the ability to render arbitrary parts of the map.
What are up/down-tiles?I meant up-down-stairs, sorry.
I saw this image and said in that thread that it looks great for outside but I personally don't see much benefits from it underground, compared to work required to implement and likely gfps degradation.Personally in almost all my forts, there is no distinction between aboveground and belowground scenes. It's below ground on one side of a cliff face and above on the other, at the same z level.
Another semi-working idea - the grid doesn't have to be uniform across screens and even on one screen:Spoiler (click to show/hide)
An absolutely neat thing would be to render mist whenever there's water (or magma!) below. I don't know how much of a hassle it'd be, though.It would be way cooler to use existing mist/flow mechanics to spawn them. Maybe depending on temperature? That might include fog (non-evil), maybe some sort of lava particles shooting in close range (would make lava way more dangerous).
I would like to vote against actual mist/magma-mist, because FPS hurt a lot from those.I noticed rendermax hit fps a fair bit.
Trying to integrate v2.01 into the starter pack, and it just crashes about a second after I launch DF - iff I've set up the second tileset in init.txt, it's fine but obviously nonfunctional otherwise. Any ideas what might be causing this on Windows 8.1? In every other way the build is identical to the current pack (r56). I get the same problem on a windows 7 laptop - it takes a little longer to appear, but I'm pretty sure that's just the (big) performance gap.
Maaan, this is progressing faster than my mind can comprehend alongside the normal DF development timescale.
A few suggestions for showing more z-levels:
-show z-levels below by default.
-make z-levels above toggle with a key; mode 1: off, mode 2: on, mode 3: (auto) off when the center of view is within range of a wall on this level, otherwise on. (what is "within range" might be best to set in an init file)
-always off when in a "cursor state" (placing a building, designating something, querying something, making a zone, etc)
It might be useful to auto change the current z-level when you're in "mode 2", but not the others.
I think this should work equally well in adventure mode.
This is the main thing I've been hoping for out of this ordeal. Square tiles on the map, easily legible 8x12 in the menus and text viewers. If there's a practical way to do so, please, there'd be demand!
I already said this, but i'm going to say it again. This is absolutely beautiful. Do you have working plugins for any of these yet?
1. If the main tileset is 16x16, then menu font size on the main screen will also be x16, not x12Gettings the text to be non-square is quite important I think. If you are not using ttf for the text, many things in the menu will be cut off, from item names in the trade screen, over unit names, to reaction names. I really hope you find a way to use differently sized tiles for the text in menus. :)
Looks amazing. So many people will want to embark on mountains with that. :)
I have been trying to get this to work without any luck. I use https://github.com/andrewd18/df-lnp-installer on Debian Wheezy. I copied the r3 .so into the hack/plugins directory and made the changes in init.txt. However, when I start DF, dfhack says it couldn't load twbt.plug.so in red text. Any ideas?
There is quite a few limitations. I can only adjust width of entire column(s) of tiles, or height of entire row(s), including adjusting both for entire screen. So,
1. If the main tileset is 16x16, then menu font size on the main screen will also be x16, not x12
2. On screens that are text-only I can change to any tile size, but size of tiles making border around screen will change as well. That's not critical but not ideal.
3. On some screens it's not possible at all.
So I don't yet know what to do with this idea.
He said that its currently not possible. See point 1. But its the same thing I requested/asked about earlier. ^^There is quite a few limitations. I can only adjust width of entire column(s) of tiles, or height of entire row(s), including adjusting both for entire screen. So,
1. If the main tileset is 16x16, then menu font size on the main screen will also be x16, not x12
2. On screens that are text-only I can change to any tile size, but size of tiles making border around screen will change as well. That's not critical but not ideal.
3. On some screens it's not possible at all.
So I don't yet know what to do with this idea.
I understand. Didn't think it'd be so simple.
Even so, it could be useful. How about something like an 8x12 basic font, accompanied with a secondary 8x8 used only for the gameplay window itself? A nice and square map ASCII set with a neatly kerned reading ASCII set for all the menus and text screens, including the stuff that's out of bounds. If I understood you right, that'd be viable, wouldn't it?
What happens if you have a ton of Z-levels (like the edge of a steep cliff)? Do the lower levels get so dark that they effectively turn black?
# Kind is I for item or B for building
# Id see buildings_other_id.h or items_other_id.h
# Type see building_type.h or item_type.h, may be empty
# Subtype is some numberical value, don't know what values correspond to what
They're right in the root folder of the download. Open with any text editor.
Could somebody point me towards the buildings_other_id.h and items_other_id.h ?
Argh, I did look in the Text will be Text download from Milo Christiansen, he just uploaded a version with 3 tilesets. But he did not include those files... my mistake. Simply looked in the wrong folder.They're right in the root folder of the download. Open with any text editor.
Could somebody point me towards the buildings_other_id.h and items_other_id.h ?
alphabetically from the raws.The raws aren't alphabetical. It sounds like it's just in order of listing in the subtype text files. For example, ITEM_WEAPON_WHIP comes alphabetically after ITEM_WEAPON_AXE_BATTLE, but is listed first.
The raws are alphabetical. The objects in the raws are not. But the raw files themselves are read out alphabetically from top to bottom. Sorry for the confusion.alphabetically from the raws.The raws aren't alphabetical. It sounds like it's just in order of listing in the subtype text files. For example, ITEM_WEAPON_WHIP comes alphabetically after ITEM_WEAPON_AXE_BATTLE, but is listed first.
Is anyone else waiting obsessively for some hint of a release for the multi-z-level view thing? I jump to the thread as fast as I can anytime I see another post has been made.
Christ, this looks great.
I assume you will be able to the adjust the shadow between layers?
Somewhat unrelated, but would it be feasible to read the world tile information like you're doing here but during embark? In order to show some sort of topography like that as a preview during embark? This would have a lot of possibilities. Also could do stuff like surface level only prospect findings from embark (or if you want a "cheat" a bit, full depth prospect findings), etc. if you can read tiles at that point in the game.If you're thinking of pre-embark prospect, that only reads the layers - the actual map isn't generated until the site is loaded for the first time (although it should be possible to display the map of a fortress being reclaimed).
Using a 1x1-pixel tileset to get a tiny version of the current map you play on, and display it simultaniously in the lower right cornerSo, like a top-down isoworld? That would look nice. Certainly more useful than the current map.
(or some other area where it fits well)Why not replace the current minimap?
What do you mean?Each layer is surrounded by a small, soft, black outline. Can you switch that off?
Why not replace the current minimap?The current minimap is in a menu that automatically cuts off a large portion of the screen.
Each layer is surrounded by a small, soft, black outline. Can you switch that off?
but obvious problem is that there may be no downramp at the edge.Oh yeah, true. Didn't think of that. Guess I'll wait for a release and experiment a bit.
I was thinking about doing something with downramps instead of additional shadows, but obvious problem is that there may be no downramp at the edge.
I think the idea mentioned above was to shade a down-ramp at the midpoint between the levels it joins. Not sure exactly how that would look, but it sounds intuitive enough to convey the ramp's purpose. (Edit: Hacking a gradient into the renderer is probably a bad idea from an FPS perspective.)I was thinking about doing something with downramps instead of additional shadows, but obvious problem is that there may be no downramp at the edge.
What about only making the ramps slightly darker, cliffs would stand out and it would look smoother?
In any case, my sense is that the plug-in depends on DFHack but not on anything specific to v34.11... so once there is a DFHack for the next DF release, updating the plugin is a simple recompile, correct?Yes, assuming nothing (major) changes about the renderer.
I was experimenting much with different ways to render shadows/rams/fog (even dynamic shadows that change depending on their position relative to point of view), and I agree that ramp rendering could be better. I like how it looks, but ramps (both up and down) are effectively belong to the lower level - creature can't stand on a downramp. So they should be rendered as such. But now I feel it's taking too long already and I will try to release it as soon as possible as is, then we'll see.That's probably the better solution anyway. Letting all the tileset guys play around with it will reveal what works and what doesn't faster anyway.
I was experimenting much with different ways to render shadows/rams/fog (even dynamic shadows that change depending on their position relative to point of view), and I agree that ramp rendering could be better. I like how it looks, but ramps (both up and down) are effectively belong to the lower level - creature can't stand on a downramp. So they should be rendered as such. But now I feel it's taking too long already and I will try to release it as soon as possible as is, then we'll see.That's probably the better solution anyway. Letting all the tileset guys play around with it will reveal what works and what doesn't faster anyway.
If I render ramps as belonging to the bottom level (effectively not rendering downramps at all), it looks like this, but I don't like it much for some reason.Yeah, I don't like it either. It looks wrong somehow. What if you render ramps as belonging to the top level (as seen in the original screenshots) but draw the shadow on top of the ramps?
Can you make a version of this for DFHack r5?
Will you be updating the current plugin for DFHack r5 (http://www.bay12forums.com/smf/index.php?topic=139553), or leaving that for the next release (or later)?That said, what platform are you on? I can try building for OS X, although mifki will probably beat me to it. :)
Can you make a version of this for DFHack r5?Will you be updating the current plugin for DFHack r5 (http://www.bay12forums.com/smf/index.php?topic=139553), or leaving that for the next release (or later)?That said, what platform are you on? I can try building for OS X, although mifki will probably beat me to it. :)
If I render ramps as belonging to the bottom level (effectively not rendering downramps at all), it looks like this, but I don't like it much for some reason.Yeah, I don't like it either. It looks wrong somehow. What if you render ramps as belonging to the top level (as seen in the original screenshots) but draw the shadow on top of the ramps?
If I render ramps as belonging to the bottom level (effectively not rendering downramps at all), it looks like this, but I don't like it much for some reason.Yeah, I don't like it either. It looks wrong somehow. What if you render ramps as belonging to the top level (as seen in the original screenshots) but draw the shadow on top of the ramps?
Can you make a version of this for DFHack r5?Will you be updating the current plugin for DFHack r5 (http://www.bay12forums.com/smf/index.php?topic=139553), or leaving that for the next release (or later)?That said, what platform are you on? I can try building for OS X, although mifki will probably beat me to it. :)
No need to build anything, just update -r3 to -r5 with any hex editor ;)But I'll upload a new package soon myself.Done.
And yes, I hate to have to build things for several different platforms...
I also noticed a display bug in the worldgenerator screen. Its nothing major, just wanted to let you know.
Also, on the create new world screen, half of the text is in one tileset, and half is in the other.
I did some tests with item subtypes. I got it working, and will post an item tileset probably tomorrow, if there is any interest.
[TILESET:Overrides - Weapons.png:Overrides - Weapons.png]
[OVERRIDE:210:I:WEAPON bla bla:::2:0]
[TILESET:Overrides - Armors.png:Overrides - Armors.png]
[OVERRIDE:210:I:ARMOR bla bla:::3:0]
I ask because I saw the # [OVERRIDE:Tile:Kind:Id:Type:Subtype:Tileset:NewTile] that has the "Tileset" as a second last argument, so I assume I can add multiple ones. If yes, how would that be done? How are they sorted? Alphabetically how they appear in the folder? Anyway, this is awesome. Thank you so much, I wanted a functionality like this for a long time, even asked Toady directly if he could do that... ^^
Tried again with the r5 binary, but it still crashes the whole game as soon as I try putting different tilesets in font and graphics_font. :(
[BUILDING_WORKSHOP:TEXTWILLBETEXT]
[NAME:Workshop of Magical Testing]
[NAME_COLOR:7:0:1]
[BUILD_LABOR:ARCHITECT]
[BUILD_KEY:CUSTOM_X]
[DIM:4:3]
[BLOCK:1:0:0:0:0]
[BLOCK:2:0:0:0:0]
[BLOCK:3:0:0:0:0]
[TILE:0:1:224:224:32:32]
[TILE:0:2:224:224:32:32]
[TILE:0:3:32:32:32:32]
[COLOR:0:1:7:0:0:7:0:0:0:0:0:0:0:0]
[COLOR:0:2:7:0:0:7:0:0:0:0:0:0:0:0]
[COLOR:0:3:0:0:0:0:0:0:0:0:0:0:0:0]
[TILE:1:1:32:32:32:32]
[TILE:1:2:32:32:32:32]
[TILE:1:3:32:32:32:32]
[COLOR:1:1:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:1:2:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:1:3:0:0:0:0:0:0:0:0:0:0:0:0]
[TILE:2:1:32:32:32:32]
[TILE:2:2:32:32:32:32]
[TILE:2:3:32:32:32:32]
[COLOR:2:1:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:2:2:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:2:3:0:0:0:0:0:0:0:0:0:0:0:0]
[TILE:3:1:53:54:55:56]
[TILE:3:2:69:70:71:72]
[TILE:3:3:85:86:87:88]
[COLOR:3:1:7:0:0:7:0:0:7:0:0:7:0:0]
[COLOR:3:2:7:0:0:7:0:0:7:0:0:7:0:0]
[COLOR:3:3:7:0:0:7:0:0:7:0:0:7:0:0]
I would seriously consider just enforcing text mode for all of worldgen, embarking, and legends mode - tilesets are almost never designed with those in mind, so a pure ASCII view would make more sense there.I second that.
@Meph - I look forward to the vanilla tiles :)Once I have something, I will make a new thread in the Tileset/Graphics section. :)
I would seriously consider just enforcing text mode for all of worldgen, embarking, and legends mode - tilesets are almost never designed with those in mind, so a pure ASCII view would make more sense there.
Am I missing tiles?Well, if you want to use the text-tileset for worldgen maps, you have a lot more. And it depends on the names of items. If a modder has a reaction name with '=, *, (), {}' in the name, then you need to have those of course.
Yeah, just checked, there are some more that are used in text in vanilla. 'V', 'n', 'æ', '"' and probably some more that I missed.QuoteAm I missing tiles?Well, if you want to use the text-tileset for worldgen maps, you have a lot more.
And it depends on the names of items. If a modder has a reaction name with '=, *, (), {}' in the name, then you need to have those of course.True.
Very nice meph. Thank god I my work is a bit simpler with a symbolic tileset like CLA.Thats not even the issue. ;)
Vanilla DF = 104 items. Masterwork DF = 1446 items. Thats whats slowing me down. My item_food file alone has almost twice as many entries as all vanilla items together. :DJesus Christ.
1000 overrides as in: 1000 new tiles, or 1000 items that will be overwritten? Because the item number can be much, much higher than that. One siege with 100 units, 12 items on each body, thats already 1200 items on the map. Long lasting forts might have 100.000 items lying around.
How did this went from text to Masterwork tilesets :S?Mifki released two functionalities so far. 1. splitting between text and graphics. 2. overwriting specific tiles with custom tiles. I just made use of the latter.
So it's faster if there are less items with particular id in game, or less overrides for particular tile, and so on.I havent noticed any issues. But I can spam a few thousand overridden items and have another go, see if anything changes.
As you can see, I copied the image of a demon skull thing into this tileset. The workshop above it made up of the 12 tiles that have this image, so the ingame workshop will look exactly like the demon skull on the picture. If I could overwrite a specific tile of the workshop with a specific overwrite tile. Could you please give one example in which you replace all tiles on one workshop with other tiles? It would help so much.
[TILESET:Building.png:Building.png]
[OVERRIDE:53:B:WORKSHOP_CUSTOM:WORKSHOP_CUSTOM:0:4:53]
[OVERRIDE:54:B:WORKSHOP_CUSTOM:WORKSHOP_CUSTOM:0:4:54]
[OVERRIDE:55:B:WORKSHOP_CUSTOM:WORKSHOP_CUSTOM:0:4:55]
[OVERRIDE:56:B:WORKSHOP_CUSTOM:WORKSHOP_CUSTOM:0:4:56]
[OVERRIDE:69:B:WORKSHOP_CUSTOM:WORKSHOP_CUSTOM:0:4:69]
[OVERRIDE:70:B:WORKSHOP_CUSTOM:WORKSHOP_CUSTOM:0:4:70]
[OVERRIDE:71:B:WORKSHOP_CUSTOM:WORKSHOP_CUSTOM:0:4:71]
[OVERRIDE:72:B:WORKSHOP_CUSTOM:WORKSHOP_CUSTOM:0:4:72]
[OVERRIDE:85:B:WORKSHOP_CUSTOM:WORKSHOP_CUSTOM:0:4:85]
[OVERRIDE:86:B:WORKSHOP_CUSTOM:WORKSHOP_CUSTOM:0:4:86]
[OVERRIDE:87:B:WORKSHOP_CUSTOM:WORKSHOP_CUSTOM:0:4:87]
[OVERRIDE:88:B:WORKSHOP_CUSTOM:WORKSHOP_CUSTOM:0:4:88]
[OVERRIDE:56:B:WORKSHOP_CUSTOM:WORKSHOP_ANY:0:4:56]
[OVERRIDE:69:B:WORKSHOP_CUSTOM:Workshop:0:4:69]
[OVERRIDE:85:B:WORKSHOP_CUSTOM:WORKSHOP:0:4:85]
you can override bins, use a text tileset for the 'x' and use a graphical tileset for stairs.That's what I did.
Mh.. I always imagined up/down-stairs as circular stairs.Spoiler: Like this (click to show/hide)
[OVERRIDE:53:B:Workshop:WORKSHOP_ANY:0:4:53]
[OVERRIDE:54:B:Workshop:WORKSHOP_CUSTOM:0:4:54]
[OVERRIDE:55:B:Workshop:WORKSHOP:0:4:55]
[OVERRIDE:56:B:WORKSHOP:WORKSHOP_ANY:0:4:56]
[OVERRIDE:69:B:WORKSHOP:WORKSHOP_CUSTOM:0:4:69]
[OVERRIDE:70:B:WORKSHOP:WORKSHOP:0:4:70]
[OVERRIDE:71:B:WORKSHOP_ANY:WORKSHOP_ANY:0:4:71]
[OVERRIDE:72:B:WORKSHOP_ANY:WORKSHOP_CUSTOM:0:4:72]
[OVERRIDE:85:B:WORKSHOP_ANY:WORKSHOP:0:4:85]
[OVERRIDE:86:B:WORKSHOP_CUSTOM:WORKSHOP_ANY:0:4:86]
[OVERRIDE:87:B:WORKSHOP_CUSTOM:WORKSHOP_CUSTOM:0:4:87]
[OVERRIDE:88:B:WORKSHOP_CUSTOM:WORKSHOP:0:4:88]
He already released it, you twaddlebat.He did? For r5? Dang, how'd I miss it?!
Maybe try BUILDING?The B stands for building, just like the other had I for item. There is no BUILDING token in building_type.h or buildins_others_id.h.
Also, is it possilbe to have the items specified by id instead of number?
But then it breaks when you add new stuff or change the order.
The order of the items in the raws. Lets say I add a new weapon to the top of the item_weapon.txt. Suddenly the whip is not weapon 0, but weapon 1, because the new weapon is weapon 0. All graphics will be wrong after that. Weapon n will be Weapon n+1.But then it breaks when you add new stuff or change the order.
What breaks? Are we all talking about the same thing?
All other dfhack scripts and plugins need a line in the dfhack init to work. "Rendermax light" or "something enable" or just the scripts name. But TwbT loads all the time, as long as the .dll is active.Seconded. The conflict with the Stonesense overlay makes this particularly painful, as I'm committed to using isometric graphics to bring in new players. Once TwbT can be toggled it's going in the Starter Pack, but until then I can't leave newbies to crash.
Could you add an on/off switch? When the .dll is added it doesnt automatically start, but needs a "TwbT enable" in the dfhack init or dfhack command window, and a "TwbT disable" would turn it off?
a golden cookie for the first person to put out a fully icon-ized default/ASCII type variant tileset using this. I tried myself, but very quickly got overwhelmed / realized that I'm not actually a good pixel artist.
All other dfhack scripts and plugins need a line in the dfhack init to work. "Rendermax light" or "something enable" or just the scripts name. But TwbT loads all the time, as long as the .dll is active.
Could you add an on/off switch? When the .dll is added it doesnt automatically start, but needs a "TwbT enable" in the dfhack init or dfhack command window, and a "TwbT disable" would turn it off?
a golden cookie for the first person to put out a fully icon-ized default/ASCII type variant tileset using this. I tried myself, but very quickly got overwhelmed / realized that I'm not actually a good pixel artist.I'm already working on it, though I won't have icons for every little thing. I want to keep it simple. I don't think the female sign and the amulet need separate icons, and '≈' is enough for all the things it currently represents, too.
I'm now finishing setting up an automatic build server that will produce binaries for all platforms when I make changes. Spent several days on choosing the best software for this, but I really don't like the part of development process where I need to write change logs, make packages, upload them... And it was good to learn about all this software.Are you planning to add your code to dfhack repository?
Once it's done, there will be packages available for the current version, and for multilevel rendering (ok for testing/playing, but without guarantee of not being broken sometimes). I possibly will fix some things in the current version, like error checks and a command to enable/disable the plugin while I'm making multilevel stuff ready for a release.
Are you planning to add your code to dfhack repository?Please do this!
I'm now finishing setting up an automatic build server that will produce binaries for all platforms when I make changes. Spent several days on choosing the best software for this, but I really don't like the part of development process where I need to write change logs, make packages, upload them... And it was good to learn about all this software.Are you planning to add your code to dfhack repository?
Once it's done, there will be packages available for the current version, and for multilevel rendering (ok for testing/playing, but without guarantee of not being broken sometimes). I possibly will fix some things in the current version, like error checks and a command to enable/disable the plugin while I'm making multilevel stuff ready for a release.
Well mostly i'm asking for the "planning" part. I think it would need changes e.g. currently it does not work if anything else overwrites renderer (afaik crashes with rendermax plugin).
Hmm that is strange. Sounds like it could be on rendermax's side...Well mostly i'm asking for the "planning" part. I think it would need changes e.g. currently it does not work if anything else overwrites renderer (afaik crashes with rendermax plugin).
Btw, I wrote some time ago, it doesn't crash with rendermax trippy and other modes except light, so maybe it's not about overriding renderer. I'll try to investigate later.
Are you planning to add your code to dfhack repository?
I don't know. I'll make my repository public, and then it can be added to wherever you want, but I possibly prefer to work and mess with things in my own place.
This thread contains some of the most exciting developments since I started playing DF. Amazing work, mifki.It is kind of sad that the most exciting developments are simply being able to display different materials and items with different symbols... and viewing the map...
This thread contains some of the most exciting developments since I started playing DF. Amazing work, mifki.It is kind of sad that the most exciting developments are simply being able to display different materials and items with different symbols... and viewing the map...
But it's still true. I agree. Awesome stuff.
*pokes Toady in the ribs in the direction of a room full of people willing to collaborate directly on graphics*
(not that other updates aren't awesome, but this basic stuff is just SO limiting and SUCH low hanging fruit, it is frustrating how we could do 5x as much cool stuff as this without hacking in indirectly)
That was Baughn and he did not disappear. In fact he offered to write a new graphics engine for DF a few months ago, but he needs source code access (obviously, otherwise you cant code on it), and (obviously again), Toady did not give access.
I think we can categorically exclude that possibility, O finder of quotes-within-quotes-that-use-completely-different-words-to-describe-a-topic.That was Baughn and he did not disappear. In fact he offered to write a new graphics engine for DF a few months ago, but he needs source code access (obviously, otherwise you cant code on it), and (obviously again), Toady did not give access.
Was there a thread I missed?
I am perfectly fine with the changes you are doing at the moment. :)
Especially non-square text (will make playing without more ttf feasable), the multi-z-level viewing (finally people dont embark on flat lands only) and the override tiles for custom workshops. These three are certainly the most versatile.
A override for creatures based on caste level would open up lots of new options for modders as well.
Okay now I feel dumb... I put the .h files where all the other .h files were, and put the .dll file (with its .so sibling) where all the other .dll files are, but twbt doesn't show up when I ls inside DFHack. I can load twbt without error, but nothing happens.
Probably missing something really really basic about DFHack.
[FONT:]
[FULLFONT:]
[GRAPHICS_FONT:]
[GRAPHICS_FULLFONT:]
You add the tileset name you want to use for text to the first two.[FONT:Obsidian_16x16.png]
[FULLFONT:Obsidian_16x16.png]
[GRAPHICS_FONT:Phoebus_16x16.png]
[GRAPHICS_FULLFONT:Phoebus_16x16.png]
[TILESET:Override Tileset - Example1.png:Override Tileset - Example1.png]
[OVERRIDE:88:I:BIN:BIN::2:0]
Now you make a beautiful masterpiece of a pixelated bin on that top-left spot. It should be 16x16 pixels, because thats what both Phoebus and Obsidian use for their sets. If you make it larger or smaller, it will still work, but look blurry ingame.
You can use a 24x24 pixel tileset, as long as its still 16x16 tiles. Yes. :) As long as the pixel dimension of the tilesets meet, nothing gets blurred.Now you make a beautiful masterpiece of a pixelated bin on that top-left spot. It should be 16x16 pixels, because thats what both Phoebus and Obsidian use for their sets. If you make it larger or smaller, it will still work, but look blurry ingame.
But you can use a 24x24 tileset, and then avoid blurriness with 24x24 graphics tiles, right?
What I need at this stage is an r5 version that does not crash with 2D print modeThat will not be possible, except if Toady One changes all the graphic code.
I disagree until mifki tells me otherwise, although I can see why you misunderstood: what I meant is a simple check that stops the plugin gracefully with 2D printmode, and loads the plugin with STANDARD/etc. What we have now is a crash with 2D, and it's not good for me, because I can't mix the graphics modes in the same pack.QuoteWhat I need at this stage is an r5 version that does not crash with 2D print modeThat will not be possible, except if Toady One changes all the graphic code.
Include? The whole thing is wide open on github already.Yep, missed the second branch, thanks for the tip
There will be no support for non-square text in the near future, sorry. I don't know how to do that to achieve what you want.Hmmm.
The tiles aren't square. The text tiles in the above images are 16x16 top, 16x13 bottom.That's what I said. Graphic tiles are square, text is not. Pic is taken from page 6 (http://www.bay12forums.com/smf/index.php?topic=138754.msg5367134#msg5367134)
Its smaller, but the same amount of tiles for text are present. This means that words cut off at the same space they would be before. Even if it looks smaller, there is no more text. A "goblin swordgoblin car" is still a "goblin swordgoblin car", instead of a carpenter. Especially in the tradescreen that might cause issues.Well, it's not causing any more issues than already exist! Narrower menus are both more readable and show more of the (square-tiled) map. The trading screen is particularly awful, but Toady has said that fixing it is a post-July priority, so I wouldn't invest much effort in fixing it at the moment.
@mifki: Just letting you know that twbt.2.11-r5 doesn't load on 10.7.5.Spoiler (click to show/hide)
@mifki: Just letting you know that twbt.2.11-r5 doesn't load on 10.7.5.Spoiler (click to show/hide)Big ooops :)
And by the way it's the code that fixes trade screen (on OS X only) :) But I forgot it uses the only thing incompatible between r3 and later releases.
Try latest build from http://build.mifki.com
It also shouldn't crash with wrong PRINT_MODE.
Also on that page there is now first working build of multilevel rendering version. Copy shadows.png to data/art folder. Consider it beta - works, but no settings to configure rendering, no optimisations, and likely bugs. Doesn't load on Windows with r5 for some weird reason.It's beautiful! Also it works with rendermax light. Thank you a lot!
Also on that page there is now first working build of multilevel rendering version. Copy shadows.png to data/art folder. Consider it beta - works, but no settings to configure rendering, no optimisations, and likely bugs. Doesn't load on Windows with r5 for some weird reason.
Can you post screenshot and try without other plugins?
I can only see one extra level (for a total of 3), too. r4, windows.r5, os x, I see ten
One!? It should show up to 10 levels and I see them on win r4 with my own eyes :)
Another thing, DF crashes when zooming far out with mousewheel.Mifki: Warmist fixed a similar problem with https://github.com/warmist/dfhack/commit/a088219b3e78df749e0ad5b229da1a8042bb59ec (I'm not sure how useful this is if you're not subclassing renderer).
Another thing, DF crashes when zooming far out with mousewheel.Mifki: Warmist fixed a similar problem with https://github.com/warmist/dfhack/commit/a088219b3e78df749e0ad5b229da1a8042bb59ec (I'm not sure how useful this is if you're not subclassing renderer).
I can upload a save, but its heavily modded when it comes to raws. But its certainly one zlevel extra, not ten.
What OS are you running it on?
Here the data/init and data/art folder as well: Download (https://www.dropbox.com/s/hfpy82xfdfcnock/data.7z)
The tilenumbers for those might change depending on the tileset people use. Can you make this an override option?
That looks like a heavily zoomed version with less than 80 tiles width! And tiny text. :)
I just set map tiles to be bigger to better show difference.But you show less than 80 tiles, which is amazing, because df usually has a hardcoded limit. People with low resolutions can not display bigger tiles. With this, it seems that they can. People could now easily make 32x or 64x tilesets.
The game already supports having differently-sized creature graphics (Fortbent's ASCII release uses 64x64 graphics for a few creatures with the vanilla 16x16 curses file for everything else).Yes, but lets say your netbook/laptop can only have a resolution of 1024. Thats 12.8 pixels per tile. Because DF displays 80 tiles width minimum. If you want to see a fully zoomed in 64x64 tile, you would need a resultion of 5120 pixels. Or you window and cut off part of the game, which you can never scroll to. Mifkis screenshot looks like he could display less than 80 tiles, making larger tiles possible for people with smaller resolutions.
Aaaaaand my idea worked!Spoiler (click to show/hide)
That looks like a heavily zoomed version with less than 80 tiles width! And tiny text. :)
It's independent rendering of map and everything else, so two different tile sizes can be set. I just set map tiles to be bigger to better show difference.
Shadows and fog will be configurable (shadow image, size, fog colour and density).
I didn't understand the problem with caverns though.
Thats already possible. Use a text tileset for the number 1-7, and make differently shaded water tiles on the graphical tileset in their places. :)
I plan to do this myself, so I did check ;)Thats already possible. Use a text tileset for the number 1-7, and make differently shaded water tiles on the graphical tileset in their places. :)
Oh, awesome. Thanks!
Downloaded the latest MW (thanks Meph), tried out the multi level rendering on an existing fort. Looks great, my fps went from ~40-45 to a steady 13 though.
Still, looks really good.
Its the logical reason for the blue coloration. It comes from humidity and the wavelength of sunlight, bla blub. It makes sense in hills and forests. But it makes no sense in caves.
Even some dfhack screens like advanced stocks have hardcoded max item name length and don't benefit from smaller font size.. Arrrgh!
Even some dfhack screens like advanced stocks have hardcoded max item name length and don't benefit from smaller font size.. Arrrgh!
This will probably be counted as a bug - or at least an issue to improve. I suggest reporting this as broken wherever you find it.
I'm trying to optimise things but still it's rendering (not OpenGL I mean but from world to symbols) of up to 10 times more, depending on the size of visible area on lower levels.
Also on that page there is now first working build of multilevel rendering version. Copy shadows.png to data/art folder. Consider it beta - works, but no settings to configure rendering, no optimisations, and likely bugs. Doesn't load on Windows with r5 for some weird reason.I can confirm that multilevel (3.11) isn't working on Windows 7, dfhack-r5. Error message. (https://i.imgur.com/Gzz04py.png)
Also on that page there is now first working build of multilevel rendering version. Copy shadows.png to data/art folder. Consider it beta - works, but no settings to configure rendering, no optimisations, and likely bugs. Doesn't load on Windows with r5 for some weird reason.I can confirm that multilevel (3.11) isn't working on Windows 7, dfhack-r5. Error message. (https://i.imgur.com/Gzz04py.png)
Did you make these? They're awesome!Spoiler: Phoebus 16x16 text tileset for TWBT (click to show/hide)Spoiler: Spacefox 16x16 text tileset for TWBT (click to show/hide)
Did you make these? They're awesome!Spoiler: Phoebus 16x16 text tileset for TWBT (click to show/hide)Spoiler: Spacefox 16x16 text tileset for TWBT (click to show/hide)
...I ask because there's a bunch of stuff that only comes up rarely, like a '#' in the dfhack comand-prompt, which could do with an absolutely-pure tileset in whatever font. How hard would it be to do this?
Will this change in the future?
Wow, this is awesome. A rather amusing side-effect of this plugin is that I can safely replace the '.' character with '!' in the menus to give a Jolly-Bastion-enabled Dwarf Fortress a maddening level of jolliness in all game text. I might try an all-caps, only-exclamation-point mod of JB for the menu text, heh heh...
EDIT: Now, imagine Billy Mays is reading every in-game menu.
(http://i.imgur.com/EcJoeyQ.png)
Spoiler: Phoebus 16x16 text tileset for TWBT (click to show/hide)Spoiler: Spacefox 16x16 text tileset for TWBT (click to show/hide)Spoiler: Dawnfortress 32x32 text tileset for TWBT (click to show/hide)
Anybody know what is the name of the font used in Mayday, Obisdian and Ironhand? Or the name of the tileset the letters were used from?
I would be eternally grateful if you'd do a Phoebus version for the Guybrush font (when selected in the Phoebus tileset assembler)
As i do it right now, i just use the Phoebus tileset assembler to make a .png with Full Clear Punctuation and Text, but the problem is that the numbers still have a background.
Creature graphics are only working 1 z-level above the creature, above that they are just letters.
Will this change in the future?
I think so. I just forgot to account for "depth" when checking override conditions.
I'm going to implement nice map zooming that now won't affect text tiles.How much more graphics improvements can one plugin hold??? Just, wow. I look forward to it.
I'm going to implement nice map zooming that now won't affect text tiles.In the meantime, I checked the r5, 3.12 version and it crashes to desktop just like 3.11 did. :'(
"The procedure entry point <blah> could not be located in SDL.dll"
As recommended by GavJ, I'd like to suggest that you work on tile swapping features in play. This would work on the lines of having a general tile for trees which can then be swapped for a more descriptive tree tile. We thought it could be useful for braille keyboards and seemingly other applications.
As recommended by GavJ, I'd like to suggest that you work on tile swapping features in play. This would work on the lines of having a general tile for trees which can then be swapped for a more descriptive tree tile. We thought it could be useful for braille keyboards and seemingly other applications.
Not sure I understand what exactly you want.
Creature graphics vanish when viewed from 2+ z levels. This only happens inside the fort, but not outside. Couldn't test caverns for now. multilevel 3.12 osxSpoiler (click to show/hide)
Creature graphics vanish when viewed from 2+ z levels. This only happens inside the fort, but not outside. Couldn't test caverns for now. multilevel 3.12 osxSpoiler (click to show/hide)
I'm getting that outside as well. Specifically, everything looks dead from 2 levels up.
Multi-level liquids is also only showing the bottom level, instead of the top, so you can't really tell how deep the top level is.
Any hope for a Linux build (or building instructions)?
dfhack: attempting to hook in
Loading bindings from data/init/interface.txt
Resetting textures
Can't load plugin /Users/user/Desktop/Dwarf fortress/Macnewbie/Dwarf Fortress/hack/plugins/twbt.plug.so
Looks like you are using r4 libraries instead of r5. This is from the binary/Users/vit/Downloads/dfhack-r4/build/library/libdfhack.1.0.0.dylib
In your init.txt set FONT and FULLFONT to the font you want to use for map tiles, and GRAPHICS_FONT and GRAPHICS_FULLFONT to the font for text. This will change to the other way round in future.is not respected, it takes text tile set from FONT variable like the old one did.
dlopen(/Users/fricy/Applications/Macnewbie_8.6a/Macnewbie/Dwarf Fortress/hack/plugins/twbt.plug.so, 2): Symbol not found: __ZN2df6global16cursor_unit_listE
Referenced from: /Users/fricy/Applications/Macnewbie_8.6a/Macnewbie/Dwarf Fortress/hack/plugins/twbt.plug.so
Expected in: /Users/fricy/Applications/Macnewbie_8.6a/Macnewbie/Dwarf Fortress/hack/libdfhack.1.0.0.dylib
in /Users/fricy/Applications/Macnewbie_8.6a/Macnewbie/Dwarf Fortress/hack/plugins/twbt.plug.so
Can't load plugin /Users/fricy/Applications/Macnewbie_8.6a/Macnewbie/Dwarf Fortress/hack/plugins/twbt.plug.so
twbt-nextgen-4.14 osx-r5Code: [Select]dlopen(/Users/fricy/Applications/Macnewbie_8.6a/Macnewbie/Dwarf Fortress/hack/plugins/twbt.plug.so, 2): Symbol not found: __ZN2df6global16cursor_unit_listE
Referenced from: /Users/fricy/Applications/Macnewbie_8.6a/Macnewbie/Dwarf Fortress/hack/plugins/twbt.plug.so
Expected in: /Users/fricy/Applications/Macnewbie_8.6a/Macnewbie/Dwarf Fortress/hack/libdfhack.1.0.0.dylib
in /Users/fricy/Applications/Macnewbie_8.6a/Macnewbie/Dwarf Fortress/hack/plugins/twbt.plug.so
Can't load plugin /Users/fricy/Applications/Macnewbie_8.6a/Macnewbie/Dwarf Fortress/hack/plugins/twbt.plug.so
I'm using the r4 version. Ask me anything that might help.
Yep, they renamed this field in r5, next build will be ok. Can you try with r3 or r4 in the meanwhile? I'm puzzled with the previous message from falcn that this version does nothing :)
Yep, they renamed this field in r5, next build will be ok. Can you try with r3 or r4 in the meanwhile? I'm puzzled with the previous message from falcn that this version does nothing :)
Well, the r3 version does things, only not very useful yet. :)
-graphics_font is the text, and font is the tileset in this version. (this will change back?)
Can you set font and graphics_font to font/graphics tilesets with distinct different sizes and post a screenshot?
so there will be a build with different tile sizes to try on WindowsCool. Anything you want to have tested?
I'm puzzled with the previous message from falcn that this version does nothing :)
Interestingly, code from g_src is exactly what's used on Linux (not surprising) and OS X, but on Windows some functions slightly differ, like some arguments are missing or memory allocation is done differently. Spent hours trying to find why version 4 doesn't work on Windows... But finally found the problem, so there will be a build with different tile sizes to try on Windows, and also multilevel version fixed for r5.
Both are using Phoebus_16x16.png + ShizzleClean.png from twbt archive (256 × 320).
init.txt is the same.
As recommended by GavJ, I'd like to suggest that you work on tile swapping features in play. This would work on the lines of having a general tile for trees which can then be swapped for a more descriptive tree tile. We thought it could be useful for braille keyboards and seemingly other applications.
Not sure I understand what exactly you want.
So eh, what's your verdict?
A feature to hit a hotkey and have it switch in game to a different group of overrides. The suggested use was so that people on a braille keyboard could have, for instance, all creatures be one tile icon, and then hit a key and have them all now represent the individual creature types so that you can hierarchically zoom in so to speak to different levels of detail as needed only.
But it would be useful presumably for all sorts of cool things other than blind player accommodation.
As recommended by GavJ, I'd like to suggest that you work on tile swapping features in play. This would work on the lines of having a general tile for trees which can then be swapped for a more descriptive tree tile. We thought it could be useful for braille keyboards and seemingly other applications.
Not sure I understand what exactly you want.
So eh, what's your verdict?
A feature to hit a hotkey and have it switch in game to a different group of overrides. The suggested use was so that people on a braille keyboard could have, for instance, all creatures be one tile icon, and then hit a key and have them all now represent the individual creature types so that you can hierarchically zoom in so to speak to different levels of detail as needed only.
But it would be useful presumably for all sorts of cool things other than blind player accommodation.
Just for clarity though, will the multilevel version also have non-square tileset functionality, or do I have to download another build for that? What exactly does nextgen do? I'm a bit confused^^
Eventually there will be single version with all features. I wasn't sure non-square tiles are possible to implement nicely, and even now there's a chance that DF2014 will contain some significant code changes that will make non-square tiles impossible. So there's a separate nextgen branch with non-square tiles but with some things like multilevel rendering missing for now.
There's new build of multilevel branch, 3.15, that fixes shadows rendering in some situations, has new "multilevel" command to control number of levels, see readme, and is compatible with r5 on Windows.
Sky is fixed in 3.16. Also I'm aware that mapshot produces corrupt image on Windows, have no idea why :)
Also there's a build of nextgen branch (with non-square text tiles) that works on Windows. However on r5 only it makes dwarfmonitor plugin crash the game.
For me, mapshot produces a very corrupt image (the game zooms out correctly for a second to encompass the entire map, but the .tga file looks like a completely distorted broadcast image or sth like that. Screen: http://i.imgur.com/svQyKzF.jpgWorks ok on OSX
When I went up to a z-level in the sky where no layers would be rendered at all, Dwarf Fortress crashed.
Massive optimization idea: /snipAFAIK the graphics engine (and maybe dfhack too) already runs on a second core, so: no, it wouldn't give the performance advantage you expect. The proper way to do multilevel rendering is proposed in this thread (http://www.bay12forums.com/smf/index.php?topic=139477.0), the big problem is that it requires Toady's support, and he is not into the problem at the moment, so the only way to achieve the sameish result is to do it with dfhack. :(
Sky is fixed in 3.16. Also I'm aware that mapshot produces corrupt image on Windows, have no idea why :)
Also there's a build of nextgen branch (with non-square text tiles) that works on Windows. However on r5 only it makes dwarfmonitor plugin crash the game.
Damn, you're quick.
QuoteMassive optimization idea: /snipAFAIK the graphics engine (and maybe dfhack too) already runs on a second core, so: no, it wouldn't give the performance advantage you expect. The proper way to do multilevel rendering is proposed in this thread (http://www.bay12forums.com/smf/index.php?topic=139477.0), the big problem is that it requires Toady's support, and he is not into the problem at the moment, so the only way to achieve the sameish result is to do it with dfhack. :(
I am 99% sure that neither dfhack nor the graphics engine runs on a second core.As I said, I'm not sure about dfhack running on a second or third core, but graphics does utilize multithreading. (http://www.reddit.com/r/IAmA/comments/1avszc/im_tarn_adams_of_bay_12_games_cocreator_of_dwarf/c9179ax)
This can be easily observed with Windows Task Manager, as I'm having a Quad-Core CPU and the dwarffortress.exe process constantly takes up 25% cpu (unless paused). dfhack does not have a seperate process at all.
I am 99% sure that neither dfhack nor the graphics engine runs on a second core.DFHack and the graphics engine run in separate threads, not separate processes. CPU usage of these threads is negligible, although you may notice an increase when moving around the map rapidly, for example. DFHack suspends DF when performing most tasks, so you won't usually see more CPU usage than DF when running something like 3dveins. I'm not sure how to determine this on Windows, but on OS X and Linux, DF uses 8-9 threads on the main menu and around 14 when using DFHack. (You can also test this by typing in the DFHack console when loading a game - DF won't respond, but the console will.)
This can be easily observed with Windows Task Manager, as I'm having a Quad-Core CPU and the dwarffortress.exe process constantly takes up 25% cpu (unless paused). dfhack does not have a seperate process at all.
Edit: After reading some threads in the forum, it seems that everyone is claiming that graphics already use a second core, but as I mentioned before, I have never ever seen DF.exe exceed 25%, which would contradict this statement.
As I said, my idea was to use twbt to make the screen renderer in the game process render NOTHING and instead having the screen rendering done by a seperate process which can run on a different cpu core. Seeing as the screen rendering takes ~10% of the total 25% available, this could potentially almost double fps in any scenario.
Not sure if this has been reported yet, but creature sprites are not displayed across z-levels. It uses creature tiles, when shown on a different z level:
On the r5 multilevel Linux version, it will not render past one additional z-level. That is, multilevel 0 and multilevel 1 work, but nothing above that.Did you check your d_init for the tile entries of SKY and CHASM? Which numbers do you have? It should be 32 for sky and 0 for chasm.
Did you check your d_init for the tile entries of SKY and CHASM? Which numbers do you have? It should be 32 for sky and 0 for chasm.
As I said, my idea was to use twbt to make the screen renderer in the game process render NOTHING and instead having the screen rendering done by a seperate process which can run on a different cpu core. Seeing as the screen rendering takes ~10% of the total 25% available, this could potentially almost double fps in any scenario.
The problem, as I said, is in synchronisation. You don't want a dwarf to appear twice on screen because while your rendering thread was rendering tile by tile, another thread moved that dwarf to another tile. That's why rendering thread pauses main loop while it's rendering, and this will have to be done regardless of whether it's a separate thread, process, whatsoever.
As I said, my idea was to use twbt to make the screen renderer in the game process render NOTHING and instead having the screen rendering done by a seperate process which can run on a different cpu core. Seeing as the screen rendering takes ~10% of the total 25% available, this could potentially almost double fps in any scenario.
The problem, as I said, is in synchronisation. You don't want a dwarf to appear twice on screen because while your rendering thread was rendering tile by tile, another thread moved that dwarf to another tile. That's why rendering thread pauses main loop while it's rendering, and this will have to be done regardless of whether it's a separate thread, process, whatsoever.
What if you have one piece of code that's synchronous with the main loop, which puts tile update events in a queue? Then the renderer can consume the queue asynchronously. It may lag a little, but there should be no problems with double-rendering.
Unless you mean that the main loop flattens all of that out, effectively copying the tree of display-relevant structures over so it's immutable from the render thread's perspective? Is it the paint or the what-and-how-to-paint calculations that consume the time? I assumed the latter, and that just pushing the draw-command stuff to another thread wouldn't win very much at all.
It's more that, yeah. By "tile update events", I meant creating new objects that only contain information needed by the renderer. E.g. a goblin's death might cause two events to be queued: "remove creature from tile" and "add new corpse object to tile". I guess that requires the render to keep a lot of internal state, though... maybe not a great idea. I wonder how expensive it would be to just copy all the data-relevant structures, like you said.
Ah, Thank you (maybe that should be linked in the readme?)
As recommended by GavJ, I'd like to suggest that you work on tile swapping features in play. This would work on the lines of having a general tile for trees which can then be swapped for a more descriptive tree tile. We thought it could be useful for braille keyboards and seemingly other applications.
Not sure I understand what exactly you want.
So eh, what's your verdict?
A feature to hit a hotkey and have it switch in game to a different group of overrides. The suggested use was so that people on a braille keyboard could have, for instance, all creatures be one tile icon, and then hit a key and have them all now represent the individual creature types so that you can hierarchically zoom in so to speak to different levels of detail as needed only.
But it would be useful presumably for all sorts of cool things other than blind player accommodation.
Well, theoretically it's possible of course. Not sure about creatures though, as they're handled differently and overrides don't do anything with creature tiles currently.
Yyyyyup.
Basically so that we can use, for example, 24px icons in a 1680px resolution.
Well, that's what the "nextgen" branch is for. It's already more or less working as you see on the screenshot, you can try. The only thing there's no way on Windows to dynamically zoom graphics tiles like I already implemented for OS X, so tileset needs to be resized beforehand.
The screen very visibly redrew and readjusted itself whenever I moved the K-cursor, so the epileptic flickering made it absolutely obnoxious to play, but it did work!
Oh holy crap, I thought that's a mockup!
Well, off to work I go then!
Mifki, any chance alpha blending will be implemented instead of a solid background colour? Things like trees in this new update could look pretty damn good with it.
Mifki, any chance alpha blending will be implemented instead of a solid background colour? Things like trees in this new update could look pretty damn good with it.
Blend what with what, is this about multilevel rendering?
Yeah multilevel (although terrain/item on same tile with transparency would be awesome too...).
Can your plugin see the terrain, creatures and items separately, or does it just get "DF wants a pound sign in these colors at x,y,z"?Yeah multilevel (although terrain/item on same tile with transparency would be awesome too...).
Currently all levels are rendered into the single buffer (from which they then rendered onto screen with OpenGL), so there's nothing to blend right now. It's possible to render above ground levels into separate buffers and render independently with blending, but I'm not sure trees worth spending additional [cpu] resources. At least until I see what can be achieved this way.
What I'd really want is to render items/buildings independently from terrain so maybe I'll try to do this later.
Can your plugin see the terrain, creatures and items separately, or does it just get "DF wants a pound sign in these colors at x,y,z"?
If the stack can be separated, that allows for a lot of really interesting effects like cluttered workshops looking cluttered, multiple creatures piled into a tile, or a "tooltip" that shows the contents of a container.
So, is it safe to not understand anything that goes on in this thread and just wait for the next version of dfhack?
I can't seem to get this plugin running on my Ubuntu system.
I'm using Masterwork-DF (5.10), and I enabled item graphics in the beginning, but I have neither Item graphics nor multi-level view.
Is there a common issue I should be aware of?
Hey mif, is there a chance you could hijack the way the ramp icons are displayed? (to make it dependant on their surrounding terrain)?
That's fantastic (and I'm really glad you got the shadows working, they help A LOT).
This is the slopes graphics I'm hoping to use BTW http://goblinart.pl/files/DF/slopes.jpg
That's fantastic (and I'm really glad you got the shadows working, they help A LOT).
This is the slopes graphics I'm hoping to use BTW http://goblinart.pl/files/DF/slopes.jpg
Can you explain a bit about this image?
EDIT: okay, here we go.
Can you make it possible to have a separate font on the minimap and/or the world map (Worldgen, embark, etc.)?
I'll carefully read your message and possibly will try to implement it, but the first thing that comes to my mind (well came a while ago when I was going to replace standard ramp tiles with something) is that sometimes there might be no slope at the edge. So if we use shaded slopes that don't require additional shadows and definitely need to draw a shadow when there's no slope, how will it look?
Can you make it possible to have a separate font on the minimap and/or the world map (Worldgen, embark, etc.)?
I can. It mostly depends on whether anyone is going to make all these separate fonts, otherwise I wouldn't bother.
Can you make it possible to have a separate font on the minimap and/or the world map (Worldgen, embark, etc.)?
I can. It mostly depends on whether anyone is going to make all these separate fonts, otherwise I wouldn't bother.
Can you make it possible to have a separate font on the minimap and/or the world map (Worldgen, embark, etc.)?
I can. It mostly depends on whether anyone is going to make all these separate fonts, otherwise I wouldn't bother.
I can't speak for actually making these, but it would be a pretty amazing touch if it were possible and someone made it. Either way this project is already hands-down my favorite community DF addon.
Which version do you use? Any issues?
That's fantastic (and I'm really glad you got the shadows working, they help A LOT).
This is the slopes graphics I'm hoping to use BTW http://goblinart.pl/files/DF/slopes.jpg
Can you explain a bit about this image?
You know, while trying to make a mock-up of this system in use, I realized it wouldn't work! Back to the drawing board...
EDIT: okay, here we go.
(http://goblinart.pl/upload/mockup2.jpg)
Now I do realize this is a bit of a huge change from what the DF display is currently about, but I also believe it makes the terrain display much clearer.
Apart from your typical occlusion, here's what needs to be done (most of it by the tileset maker):
-flat ground needs to be kept around 75% brightness
-ramps facing south need to be at 100% brightness
-ramps facing west and east - 40% and 60% (could both be 50% but it's better to differentiate)
-ramps facing north - 25%
In the following rant, I'm only talking about terrain (ground, ramps, walls, constructions etc.). Objects and creatures are a completely different subject.
I believe it's a huge distraction right now that neighbouring flat ground tiles can vary in brightness greatly. Now that we're nearing full graphics support (thanks to you and Warmist), it is imperative that both brightness and saturation are taken into account to help differentiate between flat ground, ramps and walls.
While the material (and the presence of grass) can currently GREATLY influence the brightness of a tile, I believe they should be kept close to the values listed above.
Here's my proposal on a partial set of grassy ramp icons + the normal flat ground in the middle (some additional ramp icons might be necessary for the more complex "ramp neighbourhood" situations).
(http://goblinart.pl/upload/ramps2.jpg)
It doesn't include any special graphics, the only thing that changes is the brightness (value) of the texture. But in the mockup above you can see that it provides a very clear representation of the terrain.
Creature and object icons are a bit of a problem with this, because the ground beneath them doesn't get displayed. For that reason, their tile background should be kept close to the flat ground brightness - see: http://goblinart.pl/upload/mockup3.jpg
Does the nextgen branch work on windows with dfhack-r5?
This really looks like the kind of thing that would probably best be done with an actual 3d visualizer.
I'll get back to you on that.
This really looks like the kind of thing that would probably best be done with an actual 3d visualizer.
I'll get back to you on that.
It probably would, but will that help us in making it work as part of the main DF display?
How I can get multi-level view? Plz help, I've searched through entire thread and didn't get it. Any step-by-step guides?
Moved all files, but nothing. Also, it was said that the pack already includes this plugin.
Win 7 6.1. service pack 1.
Never used console before. What should I write and and where can I find these arrows?
To be clear, this doesn't work for v 40.xx yet, right (because it needs dfhack)?
One big improvement for adventurer mode multi-level would be not rendering 10 levels below you, but 5 below and 5 above, or whatever you end up configuring. Don't know if that's feasible but it would make navigating hilly regions a much better experience.
Another huge improvement would be in using any of the look/view/query/talk/target type commands, where if there is nothing under the cursor on the current Z-level, it checks if there is anything to interact with below the Z-level that the view is on. So for instance I could view what equipment some approaching goblins have without having to jump my view down 5 levels.
Well, it doesn't support multilevel in adv mode at all currently, when I'll work on it, I'll keep your idea in mind.
I was thinking about this too, but I'm not sure it's possible to do.
The problem with rendering levels above you is that you'd not be able to see into houses because of their roofs and similar. I'm not sure how you'd program it to intelligently choose what to show and what not.
Oh, just chuck the whole thing and use a first-person interface! ;)The problem with rendering levels above you is that you'd not be able to see into houses because of their roofs and similar. I'm not sure how you'd program it to intelligently choose what to show and what not.
I would think that if you had a roof over your head it wouldnt render it (you inside a building) and if you did not have a roof over your head it would render the roofs...which also prevents you from magically seeing inside without going inside.
Though a better way to do it would be probably if there is a roof within 4x4 tiles of you dont render them...or even more fancy would be if you can see a tile then there is no roof rendered above it...so if you were looking into a doorway you can still see inside without being inside
The problem with rendering levels above you is that you'd not be able to see into houses because of their roofs and similar. I'm not sure how you'd program it to intelligently choose what to show and what not.For a start, simply giving the player a key to toggle the behavior would be enough. Beyond that, you could check if there's a non-sky tile above the player and disable rendering of upper levels entirely or in a radius around the player.
The problem with rendering levels above you is that you'd not be able to see into houses because of their roofs and similar. I'm not sure how you'd program it to intelligently choose what to show and what not.
I would think that if you had a roof over your head it wouldnt render it (you inside a building) and if you did not have a roof over your head it would render the roofs...which also prevents you from magically seeing inside without going inside.
Though a better way to do it would be probably if there is a roof within 4x4 tiles of you dont render them...or even more fancy would be if you can see a tile then there is no roof rendered above it...so if you were looking into a doorway you can still see inside without being inside
The problem with rendering levels above you is that you'd not be able to see into houses because of their roofs and similar. I'm not sure how you'd program it to intelligently choose what to show and what not.For a start, simply giving the player a key to toggle the behavior would be enough. Beyond that, you could check if there's a non-sky tile above the player and disable rendering of upper levels entirely or in a radius around the player.
sounds familiar >.>
Also on that page there is now first working build of multilevel rendering version. Copy shadows.png to data/art folder. Consider it beta - works, but no settings to configure rendering, no optimisations, and likely bugs. Doesn't load on Windows with r5 for some weird reason.I can confirm that multilevel (3.11) isn't working on Windows 7, dfhack-r5. Error message. (https://i.imgur.com/Gzz04py.png)
The big thing stopping me from using TwbT at all though is the incompatibility with stonesense and the always-on bit. Compatibility would be great, but I'd settle for the ability to disable the plugin to avoid crashing.
Just an FYI, I've added proper OpenGL and TwbT compatibility to Stonesense overlay. I've verified that it does not crash when used with TwbT 3.0 ("multilevel").
I thought that vmethod hackery was because mifki is using gcc to compile plugins? If you are using msvc your compiler does all the work.
Well manually reading vmethods from vtables instead of just using inheritance. Including custom assembly to call said methods instead of just calling them (like rest of dfhack does it). I though that it's because of different calling conventions used in gcc and msvc.
Hey, I seem to have a slight problem with the plugin. I'm running the DF starter pack thingy with Phoebus' graphics, and... well, the volcano looks like this:Anybody know how to fix this, or what causes it?Spoiler (click to show/hide)
multilevel fogcolor <r> <g> <b> command sets fog colour. Default is 0.1 0.1 0.3.
multilevel fogdensity <d> command sets fog density. Default is 0.15.
I get the same effect in the middle of the volcano, with lava on the current level and every level below.You're right. Now that you mention it, it does show up at the magma see too, and imho it's kind of useful for obsidianizing to see how deep the magma is. So I'm a bit clueless how this can be solved satisfactorily.
A good start might bemaking the magmapainting the roses red?
I found another thing that's kinda fucked:Actually, I find it much easier to read on my 15" screen than "normal" version.
I get the same effect in the middle of the volcano, with lava on the current level and every level below.
As far as I know, "Open Space" just means "there isn't a wall or floor here".
and the bluish splotches. I have no idea where those spots come from, there's nothing below except for unrevealed tiles.maybe unrevealed water?
Is there any chance of ramps being fixed? Currently all ramps render as up rams and that is very misleading in some cases (that together with the "magma bug" is why I use multilevel only for screen shots)
It would be best if ramps always rendered as down ramps except for ramps on the current level.
When actually playing the game, there should at least be a sharp difference between the active z-level and the other z-levels, to minimize confusion and mistakes.
When actually playing the game, there should at least be a sharp difference between the active z-level and the other z-levels, to minimize confusion and mistakes.
There are commands to adjust fog density, colour, and shadow colour/opacity, so you can adjust as you like. Or you have other ideas how to increase difference between levels?
I think double or triple would be about right.Fog is currently linear with regard to depth, right? Could add extra contrast between z = 0 and z = 1.When actually playing the game, there should at least be a sharp difference between the active z-level and the other z-levels, to minimize confusion and mistakes.There are commands to adjust fog density, colour, and shadow colour/opacity, so you can adjust as you like. Or you have other ideas how to increase difference between levels?
Any news or development around adventure mode support? I've had a couple of questions about that from the 34.11 starter pack, now that TwbT is on by default, and it would be nice.One big improvement for adventurer mode multi-level would be not rendering 10 levels below you, but 5 below and 5 above, or whatever you end up configuring. Don't know if that's feasible but it would make navigating hilly regions a much better experience.Well, it doesn't support multilevel in adv mode at all currently, when I'll work on it, I'll keep your idea in mind.
Another problem is that apart from the maps in fortress mode and adv mode (square tiles) and text (non-square tiles) there are also minimap, maps on embark screen and so on. Should they be in text? It's not a problem to have one more separate font for these areas but it still will be rectangular and sized as all text.
So basically I'd like to know how important non-square text is and whether the community is ready for some inconveniences like incompatibility (likely temporary) with some plugins that this functionality may cause.
As long as we can have a different tile SIZE for the interface, I don't much care if it's square or non-square.
So basically I'd like to know how important non-square text is and whether the community is ready for some inconveniences like incompatibility (likely temporary) with some plugins that this functionality may cause.Personally, I don't care much for non-square text, but from what I see, there are quite some people that do.
As long as we can have a different tile SIZE for the interface, I don't much care if it's square or non-square.
No difference, everything said above is true just for different tile sizes.
I guess I really need to get onto making a proper map visualizer then.
Isoworld already kinda half does it.
I think one or two of the artists mentioned that they'd be willing to do map-specific tilesets. That might work better as a series of overrides rather than a third font, since I don't see a way to shoehorn a third font into the init files.Another problem is that apart from the maps in fortress mode and adv mode (square tiles) and text (non-square tiles) there are also minimap, maps on embark screen and so on. Should they be in text? It's not a problem to have one more separate font for these areas but it still will be rectangular and sized as all text.
So basically I'd like to know how important non-square text is and whether the community is ready for some inconveniences like incompatibility (likely temporary) with some plugins that this functionality may cause.
Maps are maps are maps. Ideally, they'd take specific square tile sheets for map display only, but I'd settle for using the text rendering for those. The map screens have traditionally been horribly mangled by graphics packs due to their non-customizability, making them render right a big plus in favor of basic ASCII. That's what they were intended to look like in the first place, after all.
Text (mini)maps good, square special graphics (mini)maps better, not breaking shit best. I could give up some DFHack goodies for something like that, though.
Even if the font issues got resolved in the core game
Personally, I've always found the overview map to be of minimal use, but any innovation in the embark maps could be applied to the overview map basically for free.
I think I will provide a way to load third (let's call it auxiliary) font for embark and overview maps and then it's up to people to use it or not to use, to have non-square text (and overview map too, unfortunately) tiles or square. So it's going to be quite flexible.
Does TwbT work with 0.40.03?No. dfhack has not been updated yet.
And do all extra tilesets need to be 256 tiles tilesets?
Main branch version 3.31 got a new `colormap` command to change individual colors or reload colors.txt, see readme. Command to reload tilesets is expected later as well.Amazing.
Now it's possible to refer tilesets by id instead of ordinal number (old overrides.txt will still work).With 'id', do you mean the filename?
Colormap ManipulationCould you make an example with that? In which file does it go would be helpful to know as well. ;)
colormap <colorname> <r> <g> command changes display colours. Colour names are as in init/colors.txt without _R/G/B suffix. Components are in range 0-255. If no new values are provided, current values are printed.
colormap reload command reloads all colours from init/colors.txt.
With 'id', do you mean the filename?
Hang on a goddamn minute did I interpret you right? Are you suggesting that we can map actual distinctive RGB colors to ingame colors like sepia and rusty and amber instead of having to look at the nearest approximation on the 16-color palette?
Hang on a goddamn minute did I interpret you right? Are you suggesting that we can map actual distinctive RGB colors to ingame colors like sepia and rusty and amber instead of having to look at the nearest approximation on the 16-color palette?
Having fun with TWBT today...Spoiler (click to show/hide)
Don't worry Japa, as long as he doesn't try 3D terrain, my heart lies with you ;)Isnt that 3d terrain above? ^^
I discovered this thread recently and I think this is very impressing. Maybe someone should create a wiki-article about this plug-in.It would belong on the Utilities (http://dwarffortresswiki.org/index.php/DF2014:Utilities) page, but probably not until its feature set has settled down a bit. You know, right after it cures cancer and ushers in world peace.
A question for mifki: Wouldnt that isometric view require a new tileset and new sprites for pretty much everything?Good thing we already have that.
WOW O_O AMAZING! People that made it possible. Thank you! You're Awesome!*cough Stonesense (http://www.bay12forums.com/smf/index.php?topic=106497.msg5493475#msg5493475) can be played with dfhack r5 as well. So the isometric ingame view is not that new. ;)
When this plugin matures, There will be no more excuses for ppl to avoid DF!
Toady should get a huge wave of new players - a tsunami of donations!
But....stonesense....
So, about Stonesense and this.
I like Stonesense sprites. Having no limitations on tilesets, people made a lot of beautiful tile images. While DF tilesets are not that good (my personal opinion, no offence, tileset artists). I personally not interested much in isometric view and would be completely happy with 2d and better graphics. I hope we will get better tilesets as TWBT lifts some limitations, but in the meanwhile I thought why not just to try existing Stonesense sprites.
Stonesense is about beautiful view, but it's not very usable as the main interface to play DF for several reasons. So even if I decide to include isometric view in my plugin, it will be about simplicity and speed - definitely with less features and beauty that Stonesense, but completely playable and instantly switchable between 2d/iso. So it's not a direct competitor to Stonesense.
Disable rendermax, enable TWBT multi, I think that should work.
Hello!
It was suggested to me in another thread that I can access/disable the multilevel plugin of TWBT by replacing the version of twbt.plug.dll I currently have (from the MWDF windows download) with the latest (Assuming that to mean twbt 3.31) twbt.plug.dll.
In terms of rendering above - which I'm not sure is necessary - how about:
- take 'multilevel X'. For adventure mode use 0.5*X=Y levels, rounding down
- render current level,
- render Y levels below
- iff there is only open space above the adventurer, render Y levels above
This works well outside, and deals with buildings and caverns - at worst it simply flips between rendering above and not. Anything else gets very complex with special cases and odd rendering effects; I typed and deleted four half-formed ideas as possible extensions but I think they're a topic best left for later.
Hello!
It was suggested to me in another thread that I can access/disable the multilevel plugin of TWBT by replacing the version of twbt.plug.dll I currently have (from the MWDF windows download) with the latest (Assuming that to mean twbt 3.31) twbt.plug.dll.
So what exactly do you want, just disable multilevel?
Anyway, it seems you copied twbt.plug.dll for a different version of dfhack than you have.
Oh no, wrong version just won't load, so it's something else, sorry. Ok, I'll check it.
Oh no, wrong version just won't load, so it's something else, sorry. Ok, I'll check it.
Alright, so as it turns out I was using the wrong version; I thought MWDF came with DFHack r3, but I was informed it comes with R4.. I plugged R4 in, and it loaded fine, no errors. Apologies for the waste of time Mifki!
I just had an idea. Could dwarves flashing with arrows/injuries be replaced with a modified dwarf sprite that doesn't flash?
1) Overriding the archery target causes (q)uerying stockpiles to show the archery target rather than the X from the tileset. Overriding the bin (same tile#) doesn't cause any issues.
2) Is it possible to override siege engines? They're included in building_type.h, but the type is in siegeenginetype.h, and beyond that I don't know how to specify which of the multiple tiles to override.
3) How does overriding workshops work? for example, tile 127 is animal trap, mountains, and part of the mechanic's workshop. i've already overriden the animal trap, but I don't think you can override mountains so that has to stay in the tileset, meaning part of the workshop would need to be overriden.
[OVERRIDE:127:B:WORKSHOP_MECHANIC:Workshop::xxx:xxx]flip the 2 workshop parts (WORKSHOP:WORKSHOP_MECHANIC) but yeah, just tested and that works, changes the bottom right tile as expected.
should work, doesn't it?
Eventually there will be support for one more separate font for world maps because main tileset doesn't work well there anyway.
flip the 2 workshop parts (WORKSHOP:WORKSHOP_MECHANIC) but yeah, just tested and that works, changes the bottom right tile as expected.
[OVERRIDE:127:B:WORKSHOP_MECHANIC:Workshop::0:48]
[OVERRIDE:88:B:ARCHERY_TARGET:ArcheryTarget::0:48]
Edit: Forget about it. I figured it out. Will post results shortly. The solution is [OVERRIDE:tile you want to have overwritten:B:workshop id as written in the raws:Workshop:this argument has to be empty:tileset number:new tile number]
Mifki. Its an ingame screenshot. It works.
I'll try to implement proper support for custom buildings today or on the weekend.
Oh. :-[
I did notice that it overwrites other tiles with the same number in custom workshops, but I thought I could circumvent that by using unique tilenumbers for each building. I didnt realize it would affect vanilla workshops as well. I just tested, it does. Now I made myself sad.
I will still finish writing the example, because it will be helpful after this:QuoteI'll try to implement proper support for custom buildings today or on the weekend.
[PERMITTED_BUILDING:BLACK_ALTAR_ORC]
[PERMITTED_BUILDING:TINKERER_ORCISH]
[BUILDING_WORKSHOP:BLACK_ALTAR_ORC]
[NAME:Black Altar]
[NAME_COLOR:7:0:1]
[BUILD_KEY:CUSTOM_SHIFT_X]
[DIM:4:4]
[WORK_LOCATION:2:2]
[BLOCK:1:0:0:0:0]
[BLOCK:2:0:0:0:0]
[BLOCK:3:0:0:0:0]
[BLOCK:4:0:0:0:0]
[TILE:0:1:11:12:32:32]
[TILE:0:2:27:28:32:32]
[TILE:0:3:32:32:32:32]
[TILE:0:4:32:32:32:32]
[COLOR:0:1:7:0:1:7:0:1:0:0:0:0:0:0]
[COLOR:0:2:7:0:1:7:0:1:0:0:0:0:0:0]
[COLOR:0:3:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:0:4:0:0:0:0:0:0:0:0:0:0:0:0]
[TILE:1:1:32:32:32:32]
[TILE:1:2:32:32:32:32]
[TILE:1:3:32:32:32:32]
[TILE:1:4:32:32:32:32]
[COLOR:1:1:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:1:2:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:1:3:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:1:4:0:0:0:0:0:0:0:0:0:0:0:0]
[TILE:2:1:32:32:32:32]
[TILE:2:2:32:32:32:32]
[TILE:2:3:32:32:32:32]
[TILE:2:4:32:32:32:32]
[COLOR:2:1:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:2:2:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:2:3:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:2:4:0:0:0:0:0:0:0:0:0:0:0:0]
[TILE:3:1:0:1:2:3]
[TILE:3:2:4:5:6:7]
[TILE:3:3:8:9:10:11]
[TILE:3:4:12:13:14:15]
[COLOR:3:1:7:0:1:7:0:1:7:0:1:7:0:1]
[COLOR:3:2:7:0:1:7:0:1:7:0:1:7:0:1]
[COLOR:3:3:7:0:1:7:0:1:7:0:1:7:0:1]
[COLOR:3:4:7:0:1:7:0:1:7:0:1:7:0:1]
[BUILDING_WORKSHOP:TINKERER_ORCISH]
[NAME:Orcish Tinkerer]
[NAME_COLOR:7:0:1]
[BUILD_KEY:CUSTOM_SHIFT_Y]
[DIM:4:4]
[WORK_LOCATION:2:2]
[BLOCK:1:0:0:0:0]
[BLOCK:2:0:0:0:0]
[BLOCK:3:0:0:0:0]
[BLOCK:4:0:0:0:0]
[TILE:0:1:11:12:32:32]
[TILE:0:2:27:28:32:32]
[TILE:0:3:32:32:32:32]
[TILE:0:4:32:32:32:32]
[COLOR:0:1:7:0:1:7:0:1:0:0:0:0:0:0]
[COLOR:0:2:7:0:1:7:0:1:0:0:0:0:0:0]
[COLOR:0:3:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:0:4:0:0:0:0:0:0:0:0:0:0:0:0]
[TILE:1:1:32:32:32:32]
[TILE:1:2:32:32:32:32]
[TILE:1:3:32:32:32:32]
[TILE:1:4:32:32:32:32]
[COLOR:1:1:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:1:2:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:1:3:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:1:4:0:0:0:0:0:0:0:0:0:0:0:0]
[TILE:2:1:32:32:32:32]
[TILE:2:2:32:32:32:32]
[TILE:2:3:32:32:32:32]
[TILE:2:4:32:32:32:32]
[COLOR:2:1:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:2:2:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:2:3:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:2:4:0:0:0:0:0:0:0:0:0:0:0:0]
[TILE:3:1:16:17:18:19]
[TILE:3:2:20:21:22:23]
[TILE:3:3:24:25:26:27]
[TILE:3:4:28:29:30:31]
[COLOR:3:1:7:0:1:7:0:1:7:0:1:7:0:1]
[COLOR:3:2:7:0:1:7:0:1:7:0:1:7:0:1]
[COLOR:3:3:7:0:1:7:0:1:7:0:1:7:0:1]
[COLOR:3:4:7:0:1:7:0:1:7:0:1:7:0:1]
[TILESET:MDF 24x - Overrides Buildings.png:MDF 24x - Overrides Buildings.png]
[OVERRIDE:0:B:BLACK_ALTAR_ORC:Workshop::5:0]
[OVERRIDE:1:B:BLACK_ALTAR_ORC:Workshop::5:1]
[OVERRIDE:2:B:BLACK_ALTAR_ORC:Workshop::5:2]
[OVERRIDE:3:B:BLACK_ALTAR_ORC:Workshop::5:3]
[OVERRIDE:4:B:BLACK_ALTAR_ORC:Workshop::5:16]
[OVERRIDE:5:B:BLACK_ALTAR_ORC:Workshop::5:17]
[OVERRIDE:6:B:BLACK_ALTAR_ORC:Workshop::5:18]
[OVERRIDE:7:B:BLACK_ALTAR_ORC:Workshop::5:19]
[OVERRIDE:8:B:BLACK_ALTAR_ORC:Workshop::5:32]
[OVERRIDE:9:B:BLACK_ALTAR_ORC:Workshop::5:33]
[OVERRIDE:10:B:BLACK_ALTAR_ORC:Workshop::5:34]
[OVERRIDE:11:B:BLACK_ALTAR_ORC:Workshop::5:35]
[OVERRIDE:12:B:BLACK_ALTAR_ORC:Workshop::5:48]
[OVERRIDE:13:B:BLACK_ALTAR_ORC:Workshop::5:49]
[OVERRIDE:14:B:BLACK_ALTAR_ORC:Workshop::5:50]
[OVERRIDE:15:B:BLACK_ALTAR_ORC:Workshop::5:51]
[OVERRIDE:16:B:TINKERER_ORCISH:Workshop::5:4]
[OVERRIDE:17:B:TINKERER_ORCISH:Workshop::5:5]
[OVERRIDE:18:B:TINKERER_ORCISH:Workshop::5:6]
[OVERRIDE:19:B:TINKERER_ORCISH:Workshop::5:7]
[OVERRIDE:20:B:TINKERER_ORCISH:Workshop::5:20]
[OVERRIDE:21:B:TINKERER_ORCISH:Workshop::5:21]
[OVERRIDE:22:B:TINKERER_ORCISH:Workshop::5:22]
[OVERRIDE:23:B:TINKERER_ORCISH:Workshop::5:23]
[OVERRIDE:24:B:TINKERER_ORCISH:Workshop::5:36]
[OVERRIDE:25:B:TINKERER_ORCISH:Workshop::5:37]
[OVERRIDE:26:B:TINKERER_ORCISH:Workshop::5:38]
[OVERRIDE:27:B:TINKERER_ORCISH:Workshop::5:39]
[OVERRIDE:28:B:TINKERER_ORCISH:Workshop::5:52]
[OVERRIDE:29:B:TINKERER_ORCISH:Workshop::5:53]
[OVERRIDE:30:B:TINKERER_ORCISH:Workshop::5:54]
[OVERRIDE:31:B:TINKERER_ORCISH:Workshop::5:55]
This looks enormously exciting, but frankly, I am a moron, and all the set up required here is incredibly opaque to me. I followed the tutorial, but it didn't seem to have any effect.
I realize this is still early in development, but is there any way this could be streamlined and implemented in the DF starter pack down the line?
Overrides by tile type added also.
Overrides by tile type added also.
Good news, all of it, but uh what's this about? What do you mean by a tile "type"?
That is a long list...
Did you see my suggestion about material-specific overrides, or checked if something like it is possible? A different tile for rock walls, metal walls, wood walls and glass walls for example.
is it possible to make it so that for the multi z-level viewing when you make it past 15 z-levels you can make it switch to the default vanilla tile rather than the black one.
If only Toady would open-source the rendering of the game. :/
One big plus of completely replacing game rendering is ability to render floor and objects independently, so you would see real tiles behind them. It would greatly improve graphics I think.
Hi mifki, since I haven' t really followed DF much this year, I'd just like to inquire on the status on TWBT with regards to the latest version. It has the potential of truly revolutionizing DF's graphics, and I'd like to use it for my set (Obsidian) for the 40.06 update, but I'm not really sure if it's ready for mass release yet. I have some questions:I am just gonna chime in and answer what I can.
1) This requires DFHack to function, correct? And from hints here and there, I'm guessing DFHack hasn't yet been updated to 40.06?
2) Would using this mean that switching graphics quickly using programs like LNP becomes impossible?
3) I also noted that one problem TWBT had earlier was that BG colors were not supported, is this still true? Or was that a misunderstanding regarding the fact that some DF tiles do not use BG colors at all?
Apologies if these have been asked before, but the thread is now quite long and it's a bit confusing browsing all of it with little context. Basically the question I have now is: is it ready? :P It would be a huge undertaking to make my set compatible with TWBT, and I'd rather not start half-baked and have to do it all over again, heh. It would be so worth it though. Amazing job so far!
Yesterday I did a quick test and confirmed that TwbT works fine with 0.40.01.
It's been working since 0.40.01:Yesterday I did a quick test and confirmed that TwbT works fine with 0.40.01.
It's been working since 0.40.01:Yesterday I did a quick test and confirmed that TwbT works fine with 0.40.01.
Well, to avoid confusion - it CAN work. Twbt relies on some binary patches and addresses that are not part of dfhack, so they will have to be adjusted for another df version. What I meant with that message is that DF code used by twbt didn't change in 0.40 and that my test build of dfhack and twbt worked fine. Once dfhack for 0.40 is publicly available, I'll release twbt for the same DF version.
As much as I appreciate your hard work and having multi-level rendering again, I'm still looking forward to the nextgen branch pulling itself back together. I got spoiled early by that magic independent tile size rendering.
Version 4.42 got support for 0.40.08
I've developed a weird issue. Whenever I switch to full screen mode, the game instantly minimizes. If I time it right, I have just enough time to punch F11 while the screen is still up to restore windowed mode, but it's otherwise unusable.I think that's an SDL bug. (http://www.bay12games.com/dwarves/mantisbt/view.php?id=7638)
Figuring it had something to do with the ghost of the minimum grid size haunting the plugin, I tried using the small default tilesets. No change.
error: #error Linux not supported yet
Would it be possible to have more textures connect like the walls already do? I figure some things would benefit from this (tree roots, leaves, ore veins, etc).
Running 3.35 on 40.08, I get really bad lag (multi-second) when I'm placing something like a bridge and hover the mouse over an area that is on a lower z-level, even just one level. Window 8.1, fast machine, though only getting about 40fps because of an enormous canyon that two rivers are dumping into.
I have a few questions. In 34.11 PeridexisErrant LNP r63+ idk if it showed up before then. Twbt supposedly allowed creatures in cages to use the image from raws/graphics/ which I saw on a quill18 youtube video. In the 40.08 version they don't?
Next question is can you use the overides.txt to designate tiles for tree_branches? I'm making a mod for the spacefox tileset and I like the spacefox mine cart tracks but they just don't work as tree branches. So someone Joist or fricy changed the spacefox train tracks to phoebus's ones which look pretty nice as the branches. I was wondering can you use a third tileset for those cart tracks or even place those cart tracks onto the text tileset so it can just call to that one to use them for the branches. I'd honestly like to take them from a third set though so that I can add other things to the third one that I feel are missing, A for the farmers workshop being one, but I just include that fix in the twbt pack anyways since the A in text is already taken care of.
The twbt next generation file doesn't allow non twbt versions to be played without crashing the game on startup. twbt-nextgen-4.43-win for example. Haven't tested the other version since more files are in it :P and I wasn't really playing just testing changes to a mod. That said deleting the twbt file lets the game run, with the mouse query file not making conflicts I guess. There is no error log.
a little off-topic but i am really looking forward to dfhack getting stable for DF2014 and then the "text will be text" plugins gets hopefully integrated in the windows OS (DF starter pack) version of DF.
TwbT is out for 40_08 with dfhack-r2, if you're going that way.
Make Starter Pack, can confirm - it's the dfhack plugin Text will be Text. It should be back soonish once we have dfhack for 40_09.
if you watch the first episode you'll see that for the ducimvel LP serise he does not use the masterwork mod but the starter pack. the graphic pack / tileset he uses is the "phoebus_twbt_fricy" version.
http://youtu.be/gmKCvSJVwOw?t=9m15s
I wonder is there anyway to make it so that when you create a new world/ press start playing it doesn't use the text files graphics. Just a minor nuisance.
Did you post a list of your planned features somewhere? I havent checked this thread in a while, and there isnt anything in the first post. But I did see you saying somewhere that there is no way to override creatures, so I assume that caste-specific creature sprites is among the impossible requests by now?
Then recently I was trying to do one interesting thing that I'll show soon
DFHack for 40_10r1 is released! I tried downloading it manually and applying it to a LNP of 40_10r1, ported over my primary folder's settings/saves, and then followed the process to get TWBT working, but DFHack spits out this error:
http://imgur.com/wE1yfuA (http://imgur.com/wE1yfuA)
If I knew how to modify .dll files I would just try to update whatever line it says it is for and see if it still works, but I imagine it might be more complicated than that (And I don't know how to modify .dll )
DFHack for 40_10r1 is released! I tried downloading it manually and applying it to a LNP of 40_10r1, ported over my primary folder's settings/saves, and then followed the process to get TWBT working, but DFHack spits out this error:
http://imgur.com/wE1yfuA (http://imgur.com/wE1yfuA)
If I knew how to modify .dll files I would just try to update whatever line it says it is for and see if it still works, but I imagine it might be more complicated than that (And I don't know how to modify .dll )
I'm pretty sure that as a binary plugin, TWBT needs to be re-compiled for this version of DFHack. A script will work that way, but not a binary plugin.
Is it possible for you to make the transparency an optional feature, by using commands to enable/disable it?
I'll update TWBT with support for 0.40.10 later today.
I'll update TWBT with support for 0.40.10 later today.Oh, I thought that was finished. ^^ Ignore me then. ;)Is it possible for you to make the transparency an optional feature, by using commands to enable/disable it?
Wow, not so fast! It's not yet finished, there are problems with colours, I don't know yet how to implement required binpatches on Windows, and you're already asking to make it optional :)
Will anyone have a version of this + tilesets set up and ready to play?I made a vanilla version with multizlevel, font tileset and tilesets for all items for 34.11, and MasterworkDF has it, also 34.11. But I think you wont have to wait long till PeridexisErrant has this for 40.x in his Starter Pack. :)
Will anyone have a version of this + tilesets set up and ready to play?These are the currently working sets. (https://github.com/fricy/DFgraphics/tree/twbt) Click on the name of the tileset and download zip on the next page.
Will anyone have a version of this + tilesets set up and ready to play?I made a vanilla version with multizlevel, font tileset and tilesets for all items for 34.11, and MasterworkDF has it, also 34.11. But I think you wont have to wait long till PeridexisErrant has this for 40.x in his Starter Pack. :)
The ones I made are 24x24. They downscale automatically to 16x if your normal tileset is 16x. I picked 24x because they still look good when downscaled (16x) or upscaled (32x). If you want to see them in 24x, just make a 24x version of the tileset you use (phoebus, ironhand, whatever), thats it. I think there are even some 24x ascii sets on the wiki.
To be clear: The new item override tiles for armors, weapons and so on is the stuff I made. Nothing else. And some tests with buildings, but nothing released.
Yeah, kinda. If you know how to use photoshop/gimp and keep the transparency and use a rescaling algorithm that doesnt blur it. If you just want to have a try, here is an older MDF tileset that I made with 24x for testing. You also need 1920x resolution on your screen if I am not mistaken, otherwise it gives you nothing. ^^Spoiler (click to show/hide)
There also was a utility floating around for rescaling stuff... and I think thistleknot posted a link to another one somewhere (?) but I really cant remember where.
Did you do the font tileset as well? Check the init? And like I said, your native solution must be at least 1920 pixel wide. With 1280 you have enough for 80*16. But for a 24x tileset you need 80*24=1920.
Go from fullscreen to window mode, it should show full zoom instantly. (until you touch anything^^)
I don't understand the purpose behind this 80 tile limit. Why is it there? Why can't we zoom in as far as we want?Ask Baughn or Toady. ^^
Does the 80-column limit only apply when using certain tile sizes? When using the default tileset, 80 columns is the minimum (and is also defined here (https://github.com/Baughn/Dwarf-Fortress--libgraphics-/blob/master/g_src/g_basics.h#L6)).
Does the 80-column limit only apply when using certain tile sizes? When using the default tileset, 80 columns is the minimum (and is also defined here (https://github.com/Baughn/Dwarf-Fortress--libgraphics-/blob/master/g_src/g_basics.h#L6)).
I don't understand your question. When we say limit we mean minimum.
Ah, that makes sense - I assumed "limit" meant "minimum".Does the 80-column limit only apply when using certain tile sizes? When using the default tileset, 80 columns is the minimum (and is also defined here (https://github.com/Baughn/Dwarf-Fortress--libgraphics-/blob/master/g_src/g_basics.h#L6)).
I don't understand your question. When we say limit we mean minimum.
4.49 will be in the starter pack from tonight.
is there a (new) way to zoom in? if i try to zoom in then it just increases the size of the menue-fonts.
(http://s1.directupload.net/images/140831/temp/b7qhzikq.png) (http://www.directupload.net/file/d/3731/b7qhzikq_png.htm)
is there a (new) way to zoom in? if i try to zoom in then it just increases the size of the menue-fonts.
(http://s1.directupload.net/images/140831/temp/b7qhzikq.png) (http://www.directupload.net/file/d/3731/b7qhzikq_png.htm)
keybinding add Shift-O "twbt tilesize smaller"
keybinding add Shift-P "twbt tilesize bigger"
Feel free to recommend a better keybind, I just added the first keypair that didn't seem taken.However note that 4.xx is not compatible with stonesense and rendermax and probably won't be until I find time myself to make patches for them. I mean obviously 4.xx has more features and I'd like more people to use it, but some may be unhappy.Last time I checked rendermax wasn't working with 40.x. For stonesense there's an opengl compatibility fix, I think it's already in the windows version.
Latest SP has 4.48.is there a (new) way to zoom in? if i try to zoom in then it just increases the size of the menue-fonts.
(http://s1.directupload.net/images/140831/temp/b7qhzikq.png) (http://www.directupload.net/file/d/3731/b7qhzikq_png.htm)
Yes, but according to mifki you need twbt-nextgen 4.49 (https://github.com/mifki/df-twbt/releases), I'm not sure which one is in the Starter Pack. Try this, and upgrade the plugin if necessary.
My temp. solution is to add these lines to dfhack.init:Code: [Select]keybinding add Shift-O "twbt tilesize smaller"
Feel free to recommend a better keybind, I just added the first keypair that didn't seem taken.
keybinding add Shift-P "twbt tilesize bigger"
Feel free to recommend a better keybind, I just added the first keypair that didn't seem taken.
Last time I checked rendermax wasn't working with 40.x. For stonesense there's an opengl compatibility fix, I think it's already in the windows version.
is there a (new) way to zoom in? if i try to zoom in then it just increases the size of the menue-fonts.
(http://s1.directupload.net/images/140831/temp/b7qhzikq.png) (http://www.directupload.net/file/d/3731/b7qhzikq_png.htm)
Yes, but according to mifki you need twbt-nextgen 4.49 (https://github.com/mifki/df-twbt/releases), I'm not sure which one is in the Starter Pack. Try this, and upgrade the plugin if necessary.
My temp. solution is to add these lines to dfhack.init:Code: [Select]keybinding add Shift-O "twbt tilesize smaller"
keybinding add Shift-P "twbt tilesize bigger"
Feel free to recommend a better keybind, I just added the first keypair that didn't seem taken.However note that 4.xx is not compatible with stonesense and rendermax and probably won't be until I find time myself to make patches for them. I mean obviously 4.xx has more features and I'd like more people to use it, but some may be unhappy.Last time I checked rendermax wasn't working with 40.x. For stonesense there's an opengl compatibility fix, I think it's already in the windows version.
/ninja'd
I *think* you just need to copy those three into \hack\plugins using the 40.10r1 versions, but might be best to wait for an answer from mifki or fricy.is there a (new) way to zoom in? if i try to zoom in then it just increases the size of the menue-fonts.
(http://s1.directupload.net/images/140831/temp/b7qhzikq.png) (http://www.directupload.net/file/d/3731/b7qhzikq_png.htm)
Yes, but according to mifki you need twbt-nextgen 4.49 (https://github.com/mifki/df-twbt/releases), I'm not sure which one is in the Starter Pack. Try this, and upgrade the plugin if necessary.
My temp. solution is to add these lines to dfhack.init:Code: [Select]keybinding add Shift-O "twbt tilesize smaller"
Feel free to recommend a better keybind, I just added the first keypair that didn't seem taken.
keybinding add Shift-P "twbt tilesize bigger"However note that 4.xx is not compatible with stonesense and rendermax and probably won't be until I find time myself to make patches for them. I mean obviously 4.xx has more features and I'd like more people to use it, but some may be unhappy.Last time I checked rendermax wasn't working with 40.x. For stonesense there's an opengl compatibility fix, I think it's already in the windows version.
/ninja'd
thanks for the quick answer, how do i update the starter pack to use 4.49? i have downloaded the 4.49 win package from your link and extracted it. in the zip-archive were 3 folder (two for 40.10 called r0 and r1) and a bunch of files. in the folders are mousequere.plug.dll, resume.plug.dll and twbt.plug.dll ... where should i put the files (and which are needed^^). also are there any other steps (editing of files) needed?
is there a (new) way to zoom in? if i try to zoom in then it just increases the size of the menue-fonts.
(http://s1.directupload.net/images/140831/temp/b7qhzikq.png) (http://www.directupload.net/file/d/3731/b7qhzikq_png.htm)
Yes, but according to mifki you need twbt-nextgen 4.49 (https://github.com/mifki/df-twbt/releases), I'm not sure which one is in the Starter Pack. Try this, and upgrade the plugin if necessary.
My temp. solution is to add these lines to dfhack.init:Code: [Select]keybinding add Shift-O "twbt tilesize smaller"
Feel free to recommend a better keybind, I just added the first keypair that didn't seem taken.
keybinding add Shift-P "twbt tilesize bigger"However note that 4.xx is not compatible with stonesense and rendermax and probably won't be until I find time myself to make patches for them. I mean obviously 4.xx has more features and I'd like more people to use it, but some may be unhappy.Last time I checked rendermax wasn't working with 40.x. For stonesense there's an opengl compatibility fix, I think it's already in the windows version.
/ninja'd
thanks for the quick answer, how do i update the starter pack to use 4.49? i have downloaded the 4.49 win package from your link and extracted it. in the zip-archive were 3 folder (two for 40.10 called r0 and r1) and a bunch of files. in the folders are mousequere.plug.dll, resume.plug.dll and twbt.plug.dll ... where should i put the files (and which are needed^^). also are there any other steps (editing of files) needed?
thanks, worked finally. thank you sir :).
Edit: its also quite convenient being able to increase menue font and graphic tiles seperately.
thanks, worked finally. thank you sir :).
Edit: its also quite convenient being able to increase menue font and graphic tiles seperately.
Just curious, why do you need to zoom menus in and out, and not just choose a size of text font that suit you once?
sometimes smaller text is better (trade menues, etc.) and sometimes bigger ones suit me more for readability.
more info on the crashing , its crashing in game (not on the main menu screen when you start eg: create world/ play etc) and only when i'm making font too small. (about 8 clicks in the rotation of the mouse wheel) tried it getting bigger and doesn't seem to crash. Hope this helps
Man, I have to say that this ability to show fewer than 80 tiles is just insanely awesome. I have spent the past hour trying to find a way to expand the phoebus16x16 tileset into 32x32 or larger so that I can (when desired) zoom in and just see things more clearly, but unfortunately it is never a perfect extrapolation. Does anyone know of any 24x24 or 32x32 graphics packs that have been 'perfected'? I can't imagine a lot of time has been spent on this until now, since it probably wasn't even possible to use, but...
Is it possible to bind "twbt tilesize more" and "twbt tilesize less" to control + mousewheel up/down? In the past I used control + mousewheel to control all zooming, but now I am very happy with the size of fonts in the game, and would like to just control graphical zoom. I see in the dfhack.init lots of keybindings, but none reference the mousewheel, so I don't know how it would be written, if its possible.
Thanks!
Is it possible to bind "twbt tilesize more" and "twbt tilesize less" to control + mousewheel up/down? In the past I used control + mousewheel to control all zooming, but now I am very happy with the size of fonts in the game, and would like to just control graphical zoom. I see in the dfhack.init lots of keybindings, but none reference the mousewheel, so I don't know how it would be written, if its possible.
Thanks!
Is it possible to bind "twbt tilesize more" and "twbt tilesize less" to control + mousewheel up/down? In the past I used control + mousewheel to control all zooming, but now I am very happy with the size of fonts in the game, and would like to just control graphical zoom. I see in the dfhack.init lots of keybindings, but none reference the mousewheel, so I don't know how it would be written, if its possible.
Thanks!
oh hey arumba, love your DF LP :). well it seems that the mousewheel is bound to "mouse 4" and "mouse 5" so i think ctrl+mouse 4 and ctl+mouse 5 should to the trick, but don't quote me on that, am no modder^^.
No, the mousewheel is not a valid target for dfhack custom keys. First idea was a number key, but no luck, those don't work either.Is it possible to bind "twbt tilesize more" and "twbt tilesize less" to control + mousewheel up/down? In the past I used control + mousewheel to control all zooming, but now I am very happy with the size of fonts in the game, and would like to just control graphical zoom. I see in the dfhack.init lots of keybindings, but none reference the mousewheel, so I don't know how it would be written, if its possible.Tried many iterations using "keybinding add Ctrl-mouse 4 twbt tilesize more" as the base. Dfhack keeps spitting back "Invalid key spec" errors.
I wonder why it's not possible to bind anything except "A-Z, or F1-F9, or Enter" (as dfhack says). Arrow keys with some modifiers would be the natural choice for zoom, or numbers maybe.This only works in the main menu, once you load a world CMD-scroll behaves like regular scroll.
But on OS X it doesn't matter, as multiscroll plugin adds zoom in/out with Cmd+scroll up/down.
What? Twbt 4.xx + multiscroll and no zoom on cmd+scroll?Exactly. It works on the title screen, but not in the game.
What? Twbt 4.xx + multiscroll and no zoom on cmd+scroll?Exactly. It works on the title screen, but not in the game.
Trackpad on an old macbook white, no three finger gestures. Tried with USB wireless mouse, same. Well, not exactly the same, the mouse scroll is erratic, but that may be due to the mouse.Are you using trackpad or mouse?What? Twbt 4.xx + multiscroll and no zoom on cmd+scroll?Exactly. It works on the title screen, but not in the game.
i'll post it here too because it didn't happen to me before and so it might be twbt related but in my current game after i load my save withint a couple of ingame days i get a crash. dwarf fortress has never crashed on me before.I tested on mac with Peredixiserrant's settings, no crash here. I let it run until the end of the month.
i'll post it here too because it didn't happen to me before and so it might be twbt related but in my current game after i load my save withint a couple of ingame days i get a crash. dwarf fortress has never crashed on me before.I tested on mac with Peredixiserrant's settings, no crash here. I let it run until the end of the month.
I suspect the crash is more to do with the "phantom" siege on the map: right after loading I get an announcement that a siege has arrived, but no units arrive on the map. Since you haven't mentioned a siege, I think that's where the game is crashing for you.
The thing is, unfortunately, apart from Meph's set of custom graphics for items, so far nobody created any tileset/graphics to make use of twbt features to change graphics for buildings/items/tiletypes. With 0.40 it became even more important because at least trees sharing graphics with other objects look like shit. Yes, there are some issues with changing tiles for workshops, but I see a lack of artists interested in creating graphics for twbt in the first place. Once there are any, I'll find a way to change all workshop tiles as well.
Thanks for all possible bug reports. I'm playing almost only on OS X, no crashes here, maybe it's something Windows-specific. I'll now run couple games on Windows trying to reproduce the crashes.
I was getting consistent crashes trying to load a game with 4.49 but not 4.48, but 4.48 was ctd'ing at the end of manual saving. Removing the twbt plugin, overwriting the other two plugins twbt alters with stock dfhack versions, and commenting out the multilevel entries in the dfhack.ini removed all crashes. This is with 40.10. I went back to playing for awhile so the crash logs have cleared. I may have time to reproduce it tomorrow.
Well, crashes may be random - harder to reproduce and still need to be fixed...
Obviously twbt has nothing to do with sieges, but they're fun. Recently bunch of goblins appeared early in game, then a werebeast came and killed goblins, turned back into a dwarf and ran away. Everybody are happy.
I've had a lot of reports of problems with 4.49 including apparently random crashes. I'm going to re-release with 3.37, which I can still reliably crash by zooming out as far as possible. I'm not sure what's causing the other crashes, but
Many of the complaints are coming from the changed zoom behaviour in 4.xx - people would find it much more intuitive to zoom the map, and have commands to resize the menu. Switching that would help a lot.
Someone creating a complete graphics set designed from the bottom up to work with TwbT would also be great, but I suspect that'll have to wait for Mike Mayday to get back.
I've had a lot of reports of problems with 4.49 including apparently random crashes. I'm going to re-release with 3.37, which I can still reliably crash by zooming out as far as possible. I'm not sure what's causing the other crashes, but
Many of the complaints are coming from the changed zoom behaviour in 4.xx - people would find it much more intuitive to zoom the map, and have commands to resize the menu. Switching that would help a lot.
Someone creating a complete graphics set designed from the bottom up to work with TwbT would also be great, but I suspect that'll have to wait for Mike Mayday to get back.
I've had a lot of reports of problems with 4.49 including apparently random crashes. I'm going to re-release with 3.37, which I can still reliably crash by zooming out as far as possible. I'm not sure what's causing the other crashes, but
Many of the complaints are coming from the changed zoom behaviour in 4.xx - people would find it much more intuitive to zoom the map, and have commands to resize the menu. Switching that would help a lot.
Someone creating a complete graphics set designed from the bottom up to work with TwbT would also be great, but I suspect that'll have to wait for Mike Mayday to get back.
well to be honest, zooming in with the current twbt plugin is kinda wonky, but i have high hopes that we will get there eventually :).
is there a way (sorry for being a noob) to report what zomn levels i have them set at and then set the default zoom levels for text and for tiles etc. so that i don't have to zoom manually each time I re-start DF
is the w and h the number of tiles across,up/down
"twbt tilesize <w>(width) <h>(height)" Should be "twbt tilesize <32> <32>" exactly like that " included.
Oh really, I just thought that since other things in dfhack used them and his thing didn't work. Maybe he updated his starter pack to r4, they went back to the old twbt version 3.xx in it, is that command useable in that one?
# temp fix for tile set resizing
# "twbt tilesize <tilewidth> <tileheight>"
"twbt tilesize 32 32"
keybinding add Shift-O "twbt tilesize smaller"
keybinding add Shift-P "twbt tilesize bigger"
the latest windows download 4.49, + starter pack 40.10r3. The twbt version seems to be 4.49 in that one but I overwrote it anyways.
just not my day :(
What a coincidence, mine just collapsed while cleaning objects after saving, apparently due to a virtual address read/write error. But uh, this .dmp is about half a gigabyte in size. Can I help find anything specific before I start torrenting this lump of dump?
Right clicking with mousequery used to move the game map in the direction you right clicked, it seems somewhat broken now with TWBT. You can right click and go north or west, but east and south do not work.
Edit: Also, using Box select mode while placing walls and things seems to restrict the game to 16x16 tilesize. I am playing on 24x24, and the cursor goes back to 16x16 while trying to place a wall.
Right clicking with mousequery used to move the game map in the direction you right clicked, it seems somewhat broken now with TWBT. You can right click and go north or west, but east and south do not work.
Edit: Also, using Box select mode while placing walls and things seems to restrict the game to 16x16 tilesize. I am playing on 24x24, and the cursor goes back to 16x16 while trying to place a wall.
What version of twbt are you using?
4.48, I didn't update to 4.49 because of the problems i saw in the LNP thread.
4.48, I didn't update to 4.49 because of the problems i saw in the LNP thread.
Doesn't matter, so it's 4.xx.. Did you install provided mousequery.plug.dll as well?
here's a minicrashdump file http://www.mediafire.com/download/ed43u7fc5mh33y9/Dwarf_Fortress.exe.11180.dmp
I really hope this helps
I know ... i know i said i was going to bed , but i'm too excited ;)
4.48, I didn't update to 4.49 because of the problems i saw in the LNP thread.
Doesn't matter, so it's 4.xx.. Did you install provided mousequery.plug.dll as well?
Yes, I installed all three of the plugins in the download, mousequery, twbt, and resume.
LOL I'm in Australia .. and your about 2 hours ahead of me( i think) so... i think you're in Fiji. or Kiribati - Gilbert Islandshere's a minicrashdump file http://www.mediafire.com/download/ed43u7fc5mh33y9/Dwarf_Fortress.exe.11180.dmp
I really hope this helps
I know ... i know i said i was going to bed , but i'm too excited ;)
Thank you! It's 1:30am here (guess where I am), so I also need to sleeep...)
LOL I'm in Australia .. and your about 2 hours ahead of me( i think) so... i think you're in Fiji. Kiribatihere's a minicrashdump file http://www.mediafire.com/download/ed43u7fc5mh33y9/Dwarf_Fortress.exe.11180.dmp
I really hope this helps
I know ... i know i said i was going to bed , but i'm too excited ;)
Thank you! It's 1:30am here (guess where I am), so I also need to sleeep...)
the latest windows download 4.49, + starter pack 40.10r3. The twbt version seems to be 4.49 in that one but I overwrote it anyways.
The latest Starter Pack is 40_10 r4, which comes with TwbT 3.37 - it might be worth updating.
People who're getting crashes with TWBT 4.xx, read this.
Crash dumps are disabled by default on Windows, so if you're willing to help, download this file http://tmp.emsisoft.com/fw/crash_dump_settings_use_only_on_vista_and_later.zip
unpack and open enable_mini_crash_dumps.reg file. This will import settings into your registry to enable crash dumps.
Then, when DF crashes, go to C:\Users\Public\CrashDumps folder, find latest subfolder that have dwarf fortress in its name, and upload it for me. This will greatly help.
What ever is in the readme you can override, there's no max number of tiles you can override, you can use more than 10 tilesets withh 256 16x16 tiles in it for example. You can go over 256 tiles within a tileset with twbt from what I read so don't let that limit you.
What ever is in the readme you can override, there's no max number of tiles you can override, you can use more than 10 tilesets withh 256 16x16 tiles in it for example. You can go over 256 tiles within a tileset with twbt from what I read so don't let that limit you.
I must be going mad. I swear the readme file said "look at overrides.txt" and the overrides.txt file said "look at the readme" earlier today.
Here's a link to a dropbox folder with some crash evidence and my entire game install as of the reproduced crash. It's all yours. Disabling and deleting the twtb plugin does not cause a crash upon loading.
https://www.dropbox.com/sh/9qdwpw8j2irhd78/AAC2emKKb2BGxpFLmuYLEe1sa?dl=0
My OS: Windows 7 x64
side note: the version of twbt for Masterwork mod worked quite well on my computer
People who're getting crashes with TWBT 4.xx, read this.
Crash dumps are disabled by default on Windows, so if you're willing to help, download this file http://tmp.emsisoft.com/fw/crash_dump_settings_use_only_on_vista_and_later.zip
unpack and open enable_mini_crash_dumps.reg file. This will import settings into your registry to enable crash dumps.
Then, when DF crashes, go to C:\Users\Public\CrashDumps folder, find latest subfolder that have dwarf fortress in its name, and upload it for me. This will greatly help.
What ever is in the readme you can override, there's no max number of tiles you can override, you can use more than 10 tilesets withh 256 16x16 tiles in it for example. You can go over 256 tiles within a tileset with twbt from what I read so don't let that limit you.
I must be going mad. I swear the readme file said "look at overrides.txt" and the overrides.txt file said "look at the readme" earlier today.
It could be like that before, now I moved all documentation for 4.xx branch into readme file https://github.com/mifki/df-twbt/blob/nextgen/README.md
As for limits, there's a limit on the number of tiles - they must fit into one OpenGL texture, but it's very large, I believe at least (2048*2048)/(16*16)=16384 tiles of 16x16 size.
What ever is in the readme you can override, there's no max number of tiles you can override, you can use more than 10 tilesets withh 256 16x16 tiles in it for example. You can go over 256 tiles within a tileset with twbt from what I read so don't let that limit you.
I must be going mad. I swear the readme file said "look at overrides.txt" and the overrides.txt file said "look at the readme" earlier today.
It could be like that before, now I moved all documentation for 4.xx branch into readme file https://github.com/mifki/df-twbt/blob/nextgen/README.md
As for limits, there's a limit on the number of tiles - they must fit into one OpenGL texture, but it's very large, I believe at least (2048*2048)/(16*16)=16384 tiles of 16x16 size.
The documentation said unlimited ::). I can't reproduce any of these crashes, I tried both zooms and even saved and no crashes. I made new maps and all that still nothing. It's like it knows I enabled that mini crash dump, perhaps dfhack/twbt is the beginning of skynet. :o
(...)I can't reproduce the crashes either, maybe it's related to video hardware or some software like antiviruses, I have no ideas atm.
Right clicking with mousequery used to move the game map in the direction you right clicked, it seems somewhat broken now with TWBT. You can right click and go north or west, but east and south do not work.
Edit: Also, using Box select mode while placing walls and things seems to restrict the game to 16x16 tilesize. I am playing on 24x24, and the cursor goes back to 16x16 while trying to place a wall.
Interesting, I can reproduce the problem quite easily. By toggling 'box select' on and off, it forcing the game cursor to treat the map like its 16x16, even if its not. Even when you're not trying to build walls, while that setting is on it affects everything. Suddenly trying to designate plants or trees has the same issue. Go in and disable box select and the problem goes away.
Right clicking with mousequery used to move the game map in the direction you right clicked, it seems somewhat broken now with TWBT. You can right click and go north or west, but east and south do not work.
Edit: Also, using Box select mode while placing walls and things seems to restrict the game to 16x16 tilesize. I am playing on 24x24, and the cursor goes back to 16x16 while trying to place a wall.
Interesting, I can reproduce the problem quite easily. By toggling 'box select' on and off, it forcing the game cursor to treat the map like its 16x16, even if its not. Even when you're not trying to build walls, while that setting is on it affects everything. Suddenly trying to designate plants or trees has the same issue. Go in and disable box select and the problem goes away.
I can go all directions with right click until I press tab and get rid of the right side menu. I can still go north/left when that menu is gone. It's probably something to do with my computer screen not being the right size for the 24x24 graphics so it doesn't recognize I am at the edge of the screen. Interestingly enough I can't go right or down with 24x24 tilesize, if I left click it goes all directions.
The tiles don't minimize to 16x16 though when I turn on the mousequery box for digging or building walls/ chopping trees/ gathering plants. I did notice that following the dwarf was off a bit too.
Here's what I mean:
http://youtu.be/bxzoRUdDEzY
That's pretty interesting. In 16x16 mode you only have that one x but in 24x24 you have both and it uses that small x not the resized 24x24 one you'd think it would which is weird.
I tested it on 40.08 r3 and it doesn't show that box in the non twbt version. (printmode:2D really the only change there, the files still exist within dfhack)
It does turn on when twbt is active. It's still the double x's when you have a 24x24 zoom with the dfhack.init twbt tilesize 24x24 thing. Works normally without twbt active in standard mode. In 40.08, I think that's relevant at least we know it isn't dfhack but the twbt pluggin.
Don't have a place to send it...http://dffd.wimbli.com/ (http://dffd.wimbli.com/) or www.dropbox.com (http://www.dropbox.com) are good places.
QuoteDon't have a place to send it...http://dffd.wimbli.com/ (http://dffd.wimbli.com/) or www.dropbox.com (http://www.dropbox.com) are good places.
QuoteDon't have a place to send it...http://dffd.wimbli.com/ (http://dffd.wimbli.com/) or www.dropbox.com (http://www.dropbox.com) are good places.
Already handled via email...
Minor 'bug', or perhaps just a rare situation that was overlooked: When using Multilevel, and trying to place floor using the dfhack 'open placement' option, you cannot actually place things openly with the mouse because it clicks through to the lower levels. You can still do it with the keyboard, but I wonder if its possible to suppress clicking through layers only while placing floors/walls with open placement on?
One thing I'd suggest, is to move FONT and FULLFONT definitions to the overrides.txt from the init.txt. That'd make it easier to fall back to non-twbt rendering.Seconding this.
One thing I'd suggest, is to move FONT and FULLFONT definitions to the overrides.txt from the init.txt. That'd make it easier to fall back to non-twbt rendering.
I'm actually working on that functionality right now for PE's Starter Pack.One thing I'd suggest, is to move FONT and FULLFONT definitions to the overrides.txt from the init.txt. That'd make it easier to fall back to non-twbt rendering.
It works differently there, I guess he could probably have it call graphics like it does with the init if he wanted to though.
The graphics packs are at most 4-5mb. It'd be nice if the launcher had an option like some torrents do where you can download only certain files (so you'd download the main pack and then in the \LNP\Graphics you'd just choose what packs you wanted. (I so want this in the one launcher for mods pack, in this section)
Or the starter pack can just add a option to edit the init.txt to change Printmode:Standard to Printmode:2D, because that would be easier. It already edits other stuff in those files why not add that to it to? Since it turns twbt off just as well as what you suggest.
Simply changing the ".plug.dll" or ".plug.so" extension to something else is enough to disable TwbT (e.g. "twbt.disabled.dll) - changing PRINT_MODE to 2D has other side effects (such as disabling rendermax, which requires STANDARD or another OpenGL-enabled print mode).
Tested 4.51 and it gets the same save loading crash. It was worth a try.
https://www.dropbox.com/s/ewps7fqxh7ezwbz/Dwarf%20Fortress.exe.5052.dmp?dl=0
Did you try stonesense overlay?
Tested 4.51 and it gets the same save loading crash. It was worth a try.
https://www.dropbox.com/s/ewps7fqxh7ezwbz/Dwarf%20Fortress.exe.5052.dmp?dl=0
Thanks.
Does it crash if you execute "multilevel 0" in console before loading a game?
[OVERRIDE:88:T:ConstructedStairUD:3:88]
Is it an error in override command that somehow magically working, or there are more kinds available?Tested 4.51 and it gets the same save loading crash. It was worth a try.
https://www.dropbox.com/s/ewps7fqxh7ezwbz/Dwarf%20Fortress.exe.5052.dmp?dl=0
Thanks.
Does it crash if you execute "multilevel 0" in console before loading a game?
Multilevel 0 does not cause the crash, but that disables half of what twtb is.
Overrides for tile types
[OVERRIDE:Tile:T:Type:Tileset:NewTile]
Tested 4.51 and it gets the same save loading crash. It was worth a try.
https://www.dropbox.com/s/ewps7fqxh7ezwbz/Dwarf%20Fortress.exe.5052.dmp?dl=0
Thanks.
Does it crash if you execute "multilevel 0" in console before loading a game?
Multilevel 0 does not cause the crash, but that disables half of what twtb is.
tiny bug:
after using "twbt tilesize w h" command tiles get resized, but graphics from overrides is ignored until map is moved. (for example, for a moment beautiful up-down stairs made by superradish become ugly X again)
And a question I asked there[1] before I realized this is actually the thread for such questions:
is there a way to make overridden constructions, like say up-down stairs, use proper sprite from overrides while designated, instead of default?
Also, fbo in [2] is using following override command, with Kind set to T, while [3] says, it must be either B or I.Code: [Select][OVERRIDE:88:T:ConstructedStairUD:3:88]
Is it an error in override command that somehow magically working, or there are more kinds available?
[1] http://www.bay12forums.com/smf/index.php?topic=142892.msg5633476#msg5633476
[2] http://www.bay12forums.com/smf/index.php?topic=142892.msg5623895#msg5623895
[3] https://github.com/mifki/df-twbt/blob/master/dist/overrides.txt
tiny bug:
after using "twbt tilesize w h" command tiles get resized, but graphics from overrides is ignored until map is moved. (for example, for a moment beautiful up-down stairs made by superradish become ugly X again)
[OVERRIDE:186:I:DOOR:DOOR::map:81]
[OVERRIDE:186:B:DOOR:Door::map:82]
So the Q on screenshot is a door lying on the ground, the R is built door, and that strange snake-like sprite to the top-left from Q is wood door being hauled by a dwarf.
tiny bug:
after using "twbt tilesize w h" command tiles get resized, but graphics from overrides is ignored until map is moved. (for example, for a moment beautiful up-down stairs made by superradish become ugly X again)
maybe related issue: I replaced wooden door tile (186) with another, for both building and item, but while a wooden door is hauled it shows old icon.
(http://s21.postimg.org/jha7zrzjb/Strange_Door_2.jpg)
with overrides as follows:Code: [Select][OVERRIDE:186:I:DOOR:DOOR::map:81]
So the Q on screenshot is a door lying on the ground, the R is built door, and that strange snake-like sprite to the top-left from Q is wood door being hauled by a dwarf.
[OVERRIDE:186:B:DOOR:Door::map:82]
Tested 4.51 and it gets the same save loading crash. It was worth a try.
https://www.dropbox.com/s/ewps7fqxh7ezwbz/Dwarf%20Fortress.exe.5052.dmp?dl=0
Thanks.
Does it crash if you execute "multilevel 0" in console before loading a game?
Multilevel 0 does not cause the crash, but that disables half of what twtb is.
Sure, but that helped to localise the problem.
It crashes somewhere in Nvidia driver which doesn't like some of my OpenGL code while other drivers, even other Nvidia versions, work fine. So it's hard to find what's wrong as I can't reproduce the problem.
Can you try again, this time with multilevel enabled, but disabling fog with "multilevel fogdensity 0" before loading a game?
multilevel 5
multilevel shadowcolor 0 0 0 0.4
multilevel fogcolor 0.1 0.1 0.3
multilevel fogdensity 0
Tested 4.51 and it gets the same save loading crash. It was worth a try.
https://www.dropbox.com/s/ewps7fqxh7ezwbz/Dwarf%20Fortress.exe.5052.dmp?dl=0
Thanks.
Does it crash if you execute "multilevel 0" in console before loading a game?
Multilevel 0 does not cause the crash, but that disables half of what twtb is.
Sure, but that helped to localise the problem.
It crashes somewhere in Nvidia driver which doesn't like some of my OpenGL code while other drivers, even other Nvidia versions, work fine. So it's hard to find what's wrong as I can't reproduce the problem.
Can you try again, this time with multilevel enabled, but disabling fog with "multilevel fogdensity 0" before loading a game?Code: [Select]multilevel 5
multilevel shadowcolor 0 0 0 0.4
multilevel fogcolor 0.1 0.1 0.3
multilevel fogdensity 0
This setting loads. No immediate crash. Multilevel is working. Not well, but working.
Could I put in a request for someone that knows how the spacefox tileset graphics are used to represent world generation tiles to.. fix it?
I, like I imagine most people who are using the lazy newb pack right now, am using Phoebus graphics for the game area, and spacefox 'text' for the text in game. While generating a world though it uses the spacefox tileset to represent the graphics. These graphics are... weird to me, and mean nothing at all. It also presents us with a fairly unique opportunity to overhaul the way the map looks. Instead of having weird symbols for human, elf, goblins, etc, we could have.. actual things that look like towns. They wouldn't need to be logical *anywhere* else, since with this default LNP configuration they would only be used for world generation.
Does this make sense? I'm just tired of seeing things like cabinets and pink wool. What the heck does that even mean? It's such a terrible immersion breaker.
If I had any idea what these icons meant in the first place I'd try to modify my spacefox tileset .png myself, but.. I really don't understand them.
It would be very nice if levels above current and levels below current could have different shading settings. It would make it much more apparent what the altitudes of various levels were relative to current.
But it doesn't show levels above current at all. It's planned for adventure mode only.
But it doesn't show levels above current at all. It's planned for adventure mode only.
Haven't played that much with multilevel view. But I think having a small range of levels show both above and below current level would be a very useful mode. Something like 2-3 levels up and down from current. I have often built above ground walled and moated areas backing into a hill side. Being able to view a slope above and below current would be very useful in such cases for getting all the walled areas well sealed across the slopes.
The problem is that then you can't see things on the current level that are under a ceiling. It would need to be a toggle, and might just be easier all around if you just moved up a couple a levels to take a bird's-eye view. Multilevel view enables that already.
Since there are no binaries for nextgen on Linux I tried building it from source (it failed) before I noticed the following in dungeonmode.hpp:I know people really hate being asked this question, but is there any ETA as to when support for Linux will be added? Is there any technical constraint that'd make Linux support non-trivial?Spoiler (click to show/hide)
Thanks to BigD145 and Grumalg who confirmed that two major crashes have been fixed now.
Fixes for smaller issues coming soon.
Is all you said.
FYI: I updated the Obsidian graphics pack to 40.x (https://github.com/fricy/Obsidian/releases), and noticed that the next-branch version can't handle the animated grass which is a trick based on the ALT_TILE feature. On the master branch this works correctly.
You can't override by material, so I don't know what you're trying to do with subtypes)Engravings are stored in a list elsewhere. Fun fact. If you modify the coordinates of the engravings in the list, you can have engraved anything.
Detailed (engraved) tiles don't seem to have a separate tiletype, maybe it's possible to add support for them somehow else, don't know yet.
What other small things I promised in the last few days I forgot?
One thing I'd suggest, is to move FONT and FULLFONT definitions to the overrides.txt from the init.txt. That'd make it easier to fall back to non-twbt rendering.Seconding this.
Some more icons for items would be awesome. I noticed while arrows and most weapons look great, quivers still look like a chest. That makes sense, right? It's a box that you wear on your back, afterall >.<I found one beautiful 48x quiver icon here: (http://www.zeldawiki.org/images/0/03/Giant_Quiver_Icon_TP.png)
[TILESET:Override - 48x - Quiver.png:Override - 48x - Quiver.png:QuiverTileSet]
[OVERRIDE:146:I:QUIVER:QUIVER::QuiverTileSet:0]
Hmm? You don't want to make it 48x16 it will look like poop, you can do 16x16 and it looks ok, it certainly won't be that quality. 24x24 is a little better than 16. Still it's a pain in the ass with that license.that "x" was actually a "*" like multiplication.
You can override them with this.Phoebus uses a few minecraft tree and sapling tiles.
[OVERRIDE:146:I:QUIVER:QUIVER:(nothing here as their is no subtype I think):2 #of tileset 0 is font, 1 is graphic tileset/main one/2 is the override with weapons:# of quiver icon]
(http://i.imgur.com/UGlzO.png)
Minecraft to save the day? Idk how I found that 16x16 image so easily. But it also adds buckets of water/lava/milk/empty buckets, but I think you can't change their looks based on what they hold. Like bars Q_Q.
I had other options for you to choose but they were all copyrighted. I don't want to go make a minecraft forum account just to ask if I can share the images.. This one doesn't seem to be though. 32x32.Spoiler (click to show/hide)Spoiler: link to the packs site (click to show/hide)
Idk about this one.Spoiler (click to show/hide)
I think taking images from minecraft besides say the original texture quiver is a bad idea, the buggers copyright/license everything. Though for personal use it doesn't matter.
That's no different from what I said, you said it'd be 768 pixels and only with 48x16 could it ever be that. 16x48 isn't so bad but still there's no reason not to have it even.
But if it is, adding it is easy:Edit: To clarify, Erendir is referring to creating a (48*16)*(48*16) image containing this tile (in one cell of a 16*16 grid of 48*48 tiles), rather than creating a 48*16 version of this tile (see below for a better explanation).
1.resize the file to be 48*16=768 pixels in width and height
Is that suppose to show me the difference in what he said and what I said and that I'm wrong? It'd be nice when you did those quote posts you said stuff in it....I'm not sure really how your math is working.
1. Main function is to use separate fonts (tilesets) for map tiles and for text.
Quote1. Main function is to use separate fonts (tilesets) for map tiles and for text.
How does this work exactly?
If I set [FONT] and [FULLFONT] to a tff file and then [GRAPHICS_FONT] & [GRAPHICS_FULLFONT] to a tileset I get this error on DF launch:
(http://i.gyazo.com/78d9283f51142c6c1916ed63d1101036.png)
However:
(http://i.gyazo.com/398e5a9f1c29afbea6577de837444399.png)
As you can see, the font is indeed present at the right location.
Any advice?
Crash dump from 4.55 (DF 40.10)
http://dffd.wimbli.com/file.php?id=9663
Only TrueType rendering uses .ttf files. Everything else is in that .png format, just like those pink tile sheets. For examplé. (http://dwarffortresswiki.org/index.php/List_of_user_character_sets)
You need to set [FONT] and [FULLFONT] to a tileset, too. Just a tileset that uses readable fonts as tiles (not a coffin as "O", a staircase as "X", levers as "ó"/"ò", a bag as male sign, etc).
I redid CLA for the punctuation earlier today: https://imgur.com/A0rDv9m
@Mifki - any idea when the nextgen branch might update for 40.11? I'm keen to try it out again now that it sounds like most of the bugs have been fixed :)
I redid CLA for the punctuation earlier today: https://imgur.com/A0rDv9mHuh? Why don't you just use Myne or Haowan? CLA is just based on them anyway, and these are what I use for TWBT text.
I redid CLA for the punctuation earlier today: https://imgur.com/A0rDv9mHuh? Why don't you just use Myne or Haowan? CLA is just based on them anyway, and these are what I use for TWBT text.
It didn't occur to me to check it against Myne, and I didn't know about Haowan :PI see. I would suggest to just use Myne or Haowan (there are only two or 3 tiles difference, none of which appear in the interface IIRC) if you want a text tileset for twbt together with CLA. That would also fix the 'X' still being stairs in the "text-friendly CLA" you posted above. If I find some time and finalize a CLA version to be used with twbt, I'll post it anyway. The tiles are pretty much finished (I don't change that much), I just need to write the text files and test it extensively.
I'm trying to understand what CLA stands for but can't figure it out. One of the only remaining issues that is bugging me these days is how for instance on the manager interface it shows a red X for orders not yet validated, and a green... weapon rack? for validated? Any idea how to correct that? This also shows up in the uniforms and equipment interface of the military pages.The weapon rack uses a checkmark character, so any tile set that makes it look more weaponracky will also change the manager's check and the badlands on the world map.
Cursor can't be replaced atm. But you can just replace the cursor (X) in the main tileset for your twbt version.Thanks.
If you downloaded twbt and looked at the readme you'd see everything you can override.
Doors already take the color of the material that are used to make them if you made the door correctly in the tileset. Idk if you can have more than the 2 doors though.Wooden, metal and rock doors have different tiles, no? As far as I understand, these are hardcoded. Anyway, I'll just check the readme.
You could probably do it that way, if you wanted them to use different leaves. In the raws you just set them to another tile and then you use that tile in the overrides for them. Since the overrides only override the tile they are told to + w.e you tell them to override.Yeah, but can I do it without changing the raws?
I'm trying to understand what CLA stands for but can't figure it out.You mean the letters C, L and A? It doesn't stand for anything.
Hmm wood doors from the raw should be 186 which is a wall upwards tile.
[OVERRIDE:186:B:DOOR:Door::UDStairsTS:197]
[OVERRIDE:186:I:DOOR:DOOR::UDStairsTS:197]
A new Crash dump, definitely from the automaterial plugin this time ;).
http://dffd.wimbli.com/file.php?id=9670
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?
[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.
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 (http://www.bay12forums.com/smf/index.php?topic=139553.msg5655714#msg5655714), 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:QuotePlugin twbt was not built for this version of DFHack.
Plugin: 0.40.12-r1, DFHack: 0.40.11-r1
Just change .11 to .12 in cmakelist.txt in dfhack root folder.
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.
Can't load plugin /home/int/games/df/df_linux/hack/plugins/twbt.plug.so
If I had my druthers, I'd like to see regular mousewheel events captured and eaten while sending twbt tilesize bigger | smaller commands to DFHack console instead, and convert Ctrl-mousewheel events by removing the Ctrl part and passing them on to DF.
You should be able to adjust the controls to your own liking by adjusting the DF keybindings and adding a keybinding for the TwbT size commands to dfhack.init - though I'm not sure if dfhack can bind commands to the mousewheel (and don't have time to check right now).
Personally I'd use "[/]//{/}" as the zoom set, but practically anything should work.
Currently it supports any combination of Ctrl/Alt/Shift with F1-F9, or A-Z.
DFHack is pretty limited in keybinds per it's docs:QuoteCurrently it supports any combination of Ctrl/Alt/Shift with F1-F9, or A-Z.
So neither your desired keys nor the mousewheel is supported for keybinds. Using Win API hooks as I described above would allow *any* user input to be used and interpreted any way desired.
Personally I'd use "[/]//{/}" as the zoom set, but practically anything should work.
Personally I'd use "[/]//{/}" as the zoom set, but practically anything should work.
Those are probably fine on a US keyboard, but they'd be a pain on e.g. Danish: http://en.wikipedia.org/wiki/File:KB_Danish.svg (http://en.wikipedia.org/wiki/File:KB_Danish.svg)
Everything else from the default DF keybindings works well enough despite being tailored for US already, so it would be best to avoid adding too many special characters in order to preserve that.
Sheesh - How do you get along without [, ], {, and } ? Every programming language I know uses those character extensively...
Just so you can feel the pain... :) (http://upload.wikimedia.org/wikipedia/commons/a/a8/KB_Hungary.svg) And that's the standard, osx adds it's own twist too.Sheesh - How do you get along without [, ], {, and } ? Every programming language I know uses those character extensively...Personally I'd use "[/]//{/}" as the zoom set, but practically anything should work.Those are probably fine on a US keyboard, but they'd be a pain on e.g. Danish: http://en.wikipedia.org/wiki/File:KB_Danish.svg (http://en.wikipedia.org/wiki/File:KB_Danish.svg)
Everything else from the default DF keybindings works well enough despite being tailored for US already, so it would be best to avoid adding too many special characters in order to preserve that.
Just so you can feel the pain... :) (http://upload.wikimedia.org/wikipedia/commons/a/a8/KB_Hungary.svg) And that's the standard, osx adds it's own twist too.Sheesh - How do you get along without [, ], {, and } ? Every programming language I know uses those character extensively...Personally I'd use "[/]//{/}" as the zoom set, but practically anything should work.Those are probably fine on a US keyboard, but they'd be a pain on e.g. Danish: http://en.wikipedia.org/wiki/File:KB_Danish.svg (http://en.wikipedia.org/wiki/File:KB_Danish.svg)
Everything else from the default DF keybindings works well enough despite being tailored for US already, so it would be best to avoid adding too many special characters in order to preserve that.
Nice discussion, but it turns out that dfhack already intercepts ALL events (including mouse wheel). "Keybindings" command is what is limited and supports only some keys. So of course I'd prefer to have support for binding any input events to commands in dfhack rather than to deal with this in twbt.
Support for additional keys in keybindings should be manageable. Any suggestions? (Special characters, like '[' and '{', would be more of a challenge, but the mousewheel and F10-F12 should be simple enough.)
Edit: The mousewheel appears to use SDL_MouseButtonEvent, which makes combinations with modifier keys difficult to handle.
It's easy to bind to mouse events with modifiers in DF, but DFHack's "keybinding" command only handles SDL::KeyboardEvents, and allowing a combination of mouse and keyboard events would require rewriting a significant portion of it.Edit: The mousewheel appears to use SDL_MouseButtonEvent, which makes combinations with modifier keys difficult to handle.
I just tried it with DF's interface.txt. I changed [BUTTON:0:4] and [BUTTON:0:5] to [BUTTON:2:4] and [BUTTON:2:5]. It worked; mousewheel no longer zooms but ctrl-mousewheel does. W00t, no more accidental zooming!
Support for additional keys in keybindings should be manageable. Any suggestions? (Special characters, like '[' and '{', would be more of a challenge, butthe mousewheel andF10-F12 should be simple enough.)
Edit: The mousewheel appears to use SDL_MouseButtonEvent, which makes combinations with modifier keys difficult to handle.
I just tried it with DF's interface.txt. I changed [BUTTON:0:4] and [BUTTON:0:5] to [BUTTON:2:4] and [BUTTON:2:5]. It worked; mousewheel no longer zooms but ctrl-mousewheel does. W00t, no more accidental zooming!
I'll probably try to add support for binding mouse events into dfhack then.
It works very well in Adventure Mode, except for one small problem. When jumping/falling/etc, the screen turns black. I don't know if it's known or not but no harm done with just mentioning it. It kinda turns jumping into a guessing game.
Does resetting the zoom (F10 by default) change anything?
I don't see why the next gen can't use the graphics set instead of the text set like the old gen, only the people who are playing acii will ever want to see the text on the map/ embark map.
I know what happens.
Plugins that draw something in the map need to be updated to be compatible with twbt, that's easy to do for actual plugins but for Lua scripts... I need to think.
In short, in nextgen there's a separate buffer for map tiles, so plugins that draw something over the map must draw into that buffer instead of the original DF buffer.
I know what happens.
Plugins that draw something in the map need to be updated to be compatible with twbt, that's easy to do for actual plugins but for Lua scripts... I need to think.In short, in nextgen there's a separate buffer for map tiles, so plugins that draw something over the map must draw into that buffer instead of the original DF buffer.
I'm purely guessing here, but you might want to put intercept code into screen_paintTile() in dfhack/library/LuaApi.cpp, and a similar hook somewhere in Ruby.
Obviously this would mean folding some code into the main dfhack distro.
Or some hook code inside Screen::paintTile in dfhack/library/modules/Screen.cpp or inside Screen::doSetTile?
I've gotta say, I don't like the idea of you requiring custom-patched versions of other plugins.
Is the source of these modified plugins available?
There's actually more scripts that write to the screen than plugins, as that's the preferred way of making a gui in dfhack.
Can people change the version twbt loads from the source code? It may be helpful for those who build unofficial dfhack and want to play twbt before the official one is released, since so far no one else has figured out how to change what version twbt would load with.There was confusion when this all went down between me and what fricy was saying regarding source being available (I thought he was talking about TwbT not being available but he was referring to something else). As long as the TwbT source is out there (and it is per the OP - I didn't realize it at the time), we can build it and specify the DFHack build - that part is done in the CMakeList file.
Pretty sure it is done in twbt.cpp though there was nothing saying r1, so why didn't it work for them on r0...
Can people change the version twbt loads from the source code? It may be helpful for those who build unofficial dfhack and want to play twbt before the official one is released, since so far no one else has figured out how to change what version twbt would load with.r0 is in the makefile. The problem with compiling it for newer versions is that the memory addresses it needs to work are not in symbols.xml used by dfhack, but hardcoded into the plugin itself. Those adresses change with every version, and mifki needs to reverse engineeer df to compile. When the adresses are updated compiling is trivial if you know how to.
Pretty sure it is done in twbt.cpp though there was nothing saying r1, so why didn't it work for them on r0...
ah.Can people change the version twbt loads from the source code? It may be helpful for those who build unofficial dfhack and want to play twbt before the official one is released, since so far no one else has figured out how to change what version twbt would load with.r0 is in the makefile. The problem with compiling it for newer versions is that the memory addresses it needs to work are not in symbols.xml used by dfhack, but hardcoded into the plugin itself. Those adresses change with every version, and mifki needs to reverse engineeer df to compile. When the adresses are updated compiling is trivial if you know how to.
Pretty sure it is done in twbt.cpp though there was nothing saying r1, so why didn't it work for them on r0...
@mifki: btw isn't it possible to add these to the df structure tools, so finding them could be automated? Not that I'd know how to do that. :)
@salitus: ninj'd: I was referring to mifki's updated dfhack plugins (https://github.com/mifki/df-twbt/tree/nextgen/plugins) which I couldn't locate/compile at the time.
Can people change the version twbt loads from the source code? It may be helpful for those who build unofficial dfhack and want to play twbt before the official one is released, since so far no one else has figured out how to change what version twbt would load with.There is a version string contained in the compiled plugin, which is compared to the version string used to compile DFHack when the plugin is loaded - if they don't match, DFHack will refuse to load the plugin.
Pretty sure it is done in twbt.cpp though there was nothing saying r1, so why didn't it work for them on r0...
#define DFHACK_PLUGIN(plugin_name) \
DFhackDataExport const char * version = DFHACK_VERSION;\
DFhackDataExport const char * name = plugin_name;\
DFhackDataExport Plugin *plugin_self = NULL;
@mifki: btw isn't it possible to add these to the df structure tools, so finding them could be automated? Not that I'd know how to do that. :)
DFHack 40.13-r1 is out ;)
He committed the last pile of .13 changes not even an hour ago. Jesus, have a little patience.
Yep, 3.43 has support for 0.40.13-r1.
I decided to make some internal changes so the nextgen branch will be later.
Looks that way.Yep, 3.43 has support for 0.40.13-r1.
I decided to make some internal changes so the nextgen branch will be later.
is 3.43 a dev build that requires [compiling] dfhack to compile?
Yep, 3.43 has support for 0.40.13-r1.
I decided to make some internal changes so the nextgen branch will be later.
is 3.43 a dev build that requires [compiling] dfhack to compile?
Uh, your build server looks slightly fucked. Did you change something?
What am i doing wrong?Assuming this is with Macnewbie: check df/data/init/init.txt to see if you have [FONT:Spacefox_16x16_text.png] defined there instead of duerer_ascii_15x15.png. If yes, then this is most likely a bug with Pylnp. I tried reproducing this error, but couldn't corrupt the init, so it may have to do with something you did. Can you explain what you did before you got this?
What am i doing wrong?
What am i doing wrong?Assuming this is with Macnewbie: check df/data/init/init.txt to see if you have [FONT:Spacefox_16x16_text.png] defined there instead of duerer_ascii_15x15.png. If yes, then this is most likely a bug with Pylnp. I tried reproducing this error, but couldn't corrupt the init, so it may have to do with something you did.
Can you explain what you did before you got this?
installed dfhack with twbt, created new world and realised that map drawn with graphic set. Installed space fox to double check.
installed dfhack with twbt, created new world and realised that map drawn with graphic set. Installed space fox to double check.
Why did you expect the map not to use graphics set?)
Indeed, there are two branches of twbt - main which draws world map with graphics font, and nextgen which draws all these screen with text font (but it's not available for 0.40.13 yet). This may be confusing if you weren't following twbt development, but it doesn't matter, I hope to finish what I'm doing tomorrow and there will be only one version (and with support for 0.40.13).
installed dfhack with twbt, created new world and realised that map drawn with graphic set. Installed space fox to double check.
Why did you expect the map not to use graphics set?)
Indeed, there are two branches of twbt - main which draws world map with graphics font, and nextgen which draws all these screen with text font (but it's not available for 0.40.13 yet). This may be confusing if you weren't following twbt development, but it doesn't matter, I hope to finish what I'm doing tomorrow and there will be only one version (and with support for 0.40.13).
Ok, got it. awaiting next release :)
Half of people complained that it's in graphics in one branch, another half complains that it's in text in another branch...I know that feeling oh so well. ^^
Sounds like a perfect bay12 motto. ;-)QuoteHalf of people complained that it's in graphics in one branch, another half complains that it's in text in another branch...I know that feeling oh so well. ^^
installed dfhack with twbt, created new world and realised that map drawn with graphic set. Installed space fox to double check.
Why did you expect the map not to use graphics set?)
Indeed, there are two branches of twbt - main which draws world map with graphics font, and nextgen which draws all these screen with text font (but it's not available for 0.40.13 yet). This may be confusing if you weren't following twbt development, but it doesn't matter, I hope to finish what I'm doing tomorrow and there will be only one version (and with support for 0.40.13).
Ok, got it. awaiting next release :)
But anyway, why do you not want graphics font there?
Half of people complained that it's in graphics in one branch, another half complains that it's in text in another branch...
QuoteHalf of people complained that it's in graphics in one branch, another half complains that it's in text in another branch...I know that feeling oh so well. ^^
Originally I wrote a small plugin because I was tired seeing coffins instead of zeroes and all that stuff. It has greately evolved since then. Requires OpenGL PRINT_MODE (STANDARD or VBO). Some functions may not work or have issues in Adventurer Mode. See readme for all details.
Quick question: does twbt support VBO print mode?
Does that mean you are switching to the next gen as the only twbt? It's better than the old gen besides for the map, after I saw someone using the starter pack and having graphics on the embark map I was switching between old and next gen during embark and playing. The newest one (4.61) didn't have any crashes when I was playing it I think.
Is anyone elses screen going 1 layer down when they press v or k and <-- --> arrows. This could be a twbt problem since someone has posted about this happening a day or so ago but back in 40.12. I know it didn't happen in the next gen branch of 40.11 I was playing previously, since I skipped 40.12.
Nope it is a 3.41+ old gen bug. Just tested it on 40.11 to be sure and it happens. Though not 100% of the time which is even weirder. It may be caused by twbt conflicting with the partial mouse controls because turning mouse control off seems to fix it. Yeah I'm 100% sure it's a conflict between twbt and partial mouse control or partial mouse control dislikes standard printmode...
I think mifki's plan is to have a separately specified map font, which would probably involve bringing the font settings into the overrides file somehow.QuoteHalf of people complained that it's in graphics in one branch, another half complains that it's in text in another branch...I know that feeling oh so well. ^^
Then better make in an option if possible ;)
I think mifki's plan is to have a separately specified map font, which would probably involve bringing the font settings into the overrides file somehow.QuoteHalf of people complained that it's in graphics in one branch, another half complains that it's in text in another branch...I know that feeling oh so well. ^^
Then better make in an option if possible ;)
If that happens, some can use their text font for maps, others their graphics font for maps, and still others a map-specific font (if anyone actually makes one).
Why didn't you try and download it when he posted that it was released earlier? He lives in New Zealand so it is going to be hours till he sees that message. He was still on for a hour after your first post though.
Uh, your build server looks slightly #$#$%#. Did you change something?
It looks slightly preparing for the next major version. Old releases are on github.
TWBT setting gives me a crash on game start. TWBT_LEGACY working. Win7 crash dump and related files.
http://dffd.wimbli.com/file.php?id=9777
Problem signature:
Problem Event Name: APPCRASH
Application Name: Dwarf Fortress.exe
Application Version: 0.0.0.0
Application Timestamp: 5419c537
Fault Module Name: MSVCR100.dll
Fault Module Version: 10.0.30319.1
Fault Module Timestamp: 4ba1dbbe
Exception Code: c0000005
Exception Offset: 00001fc8
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1035
Additional Information 1: 4887
Additional Information 2: 4887a021f243e72fa919d7245388904c
Additional Information 3: f675
Additional Information 4: f675b9c0c8b4f63dc48841cb7e8c72cf
TWBT setting gives me a crash on game start. TWBT_LEGACY working. Win7 crash dump and related files.
http://dffd.wimbli.com/file.php?id=9777
TWBT setting gives me a crash on game start. TWBT_LEGACY working. Win7 crash dump and related files.
http://dffd.wimbli.com/file.php?id=9777
same situation, but if I disable the multilevel command in my dfhack.init it does not crash.
I got one of those too. Jerking the multilevel rendering from off straight to 5 knocked it down, but then I tried upping it in increments. Worked just fine.
5.12 should fix this crash
As recommended by GavJ, I'd like to suggest that you work on tile swapping features in play. This would work on the lines of having a general tile for trees which can then be swapped for a more descriptive tree tile. We thought it could be useful for braille keyboards and seemingly other applications.
Not sure I understand what exactly you want.
So eh, what's your verdict?
A feature to hit a hotkey and have it switch in game to a different group of overrides. The suggested use was so that people on a braille keyboard could have, for instance, all creatures be one tile icon, and then hit a key and have them all now represent the individual creature types so that you can hierarchically zoom in so to speak to different levels of detail as needed only.
But it would be useful presumably for all sorts of cool things other than blind player accommodation.
Well, theoretically it's possible of course. Not sure about creatures though, as they're handled differently and overrides don't do anything with creature tiles currently.
If i were to make a suggestion thread asking for the creatures bit to be sorted, what exactly should i ask for?
Box select isn't working on automaterials plugin but it is also broken on vanilla dfhack too.
That appears to be a DFHack problem, although I'm not experiencing it (0.40.13-r1). What platform and DFHack build are you using?
That appears to be a DFHack problem, although I'm not experiencing it (0.40.13-r1). What platform and DFHack build are you using?
Quietust caught an unnoticed conflict in symbols.xml that was causing this (and other construction-related problems) - try making this change (https://github.com/DFHack/dfhack/issues/338#issuecomment-56739172) to <DF>/hack/symbols.xml.
As recommended by GavJ, I'd like to suggest that you work on tile swapping features in play. This would work on the lines of having a general tile for trees which can then be swapped for a more descriptive tree tile. We thought it could be useful for braille keyboards and seemingly other applications.
Not sure I understand what exactly you want.
So eh, what's your verdict?
A feature to hit a hotkey and have it switch in game to a different group of overrides. The suggested use was so that people on a braille keyboard could have, for instance, all creatures be one tile icon, and then hit a key and have them all now represent the individual creature types so that you can hierarchically zoom in so to speak to different levels of detail as needed only.
But it would be useful presumably for all sorts of cool things other than blind player accommodation.
Well, theoretically it's possible of course. Not sure about creatures though, as they're handled differently and overrides don't do anything with creature tiles currently.
If i were to make a suggestion thread asking for the creatures bit to be sorted, what exactly should i ask for?
Eh, know it's been a while but I'd like to bump this. So you need to be able to override creature tiles?
It's fixed in 5.12, the version in the lnp is 3.41 and doesn't use TWBT printmode anyways or it shouldn't because he just "made" that starting with 5.10 or so.
If anything, the bleeding edge is in far better shape than the final iterations of version 3.
If anything, the bleeding edge is in far better shape than the final iterations of version 3.
good to know -- downloading now, I'll take it for a spin. I suppose I should wander over to the DF Starter Pack thread and make sure everyone knows there's a fairly major reproducible crash bug in the version of TWBT they're using and as configured/enabled by default. They might want to consider disabling that version of TWBT in the Starter Pack for the time being since it's no doubt causing all sorts of people to think DF itself is crashing, seeing as we're getting reports of it on the Mantis tracker now.
I'll check the save game attached to that bug report. I personally almost don't zoom out so maybe there's still a bug I missed.
It's in the development builds on the first page/ post. It doesn't have any bugs so far that I've found.
What your proposing is actually harder, the simple way. Load my 40.13 version that has the 3.41 and generate worlds. Then copy the saves over and apply the graphics/raws.
Might that also cause issues with the TwbT-compatible resume, automaterial, and mousequery plugins?
No problem with the problems or caused by them - I was just curious as to whether they might have problems if TwbT was removed or downgraded.
The auto zoom on event doesn't ever seem to get the right place though. Maybe because I have a 16x16 graphics set and a 10x15 text set?
Crash on (z)ooming to migrant arrival from (a)nnouncement. Might not be TWBT related but here are two crashes if you want to lake a look. The initial automatic zoom hasn't caused a crash.
Win7 64bit, DFSP 40-11r3(TWBT 5.12)
http://dffd.wimbli.com/file.php?id=9802
edit: The auto zoom on event doesn't ever seem to get the right place though. Maybe because I have a 16x16 graphics set and a 10x15 text set?
Quote from: muppet9876The auto zoom on event doesn't ever seem to get the right place though. Maybe because I have a 16x16 graphics set and a 10x15 text set?
I remember a problem with auto-moving map to center on something (zoom to location, follow a creature, maybe other) if tileset-size and TWBT-tileset-display-size were different (i.e. load game with any 16x16 tileset, use "twbt tilesize 32 32", follow a dwarf).
Rejoice!
In version 5.16 standard zoom commands affect map tiles and not text tiles when on the main dwarf mode or adventure screen. Also there's now "twbt tilesize reset" command (but standard reset zoom df command works too), and custom tile size is preserved when switching between windowed and fullscreen modes.
[OVERRIDE:34:B:WORKSHOP_CARPENTER:Workshop::leocean:16]
[OVERRIDE:61:B:WORKSHOP_CARPENTER:Workshop::leocean:17]
[OVERRIDE:93:B:WORKSHOP_CARPENTER:Workshop::leocean:208]
[OVERRIDE:176:B:WORKSHOP_CARPENTER:Workshop::leocean:209]
You can still use overrides for workshops, but if two tiles are the same, they will still be the same with overrides.Very nice I had no idea you could replace that stuff yet (I did see that stuff in the readme but I focused on items first). Instead of [OVERRIDE:176:B:WORKSHOP_CARPENTER:Workshop::leocean:209] you should probably be using [OVERRIDE:176:B:WORKSHOP_CARPENTER:Workshop::#:209] 0 is the font, 1 is the graphics_font, 2 is the overrides for weapons/armors normally then 3 up to 1000's is whatever you add. Just seems simpler that way, I think the tiles on it have to be 16 wide by 16 down (as in 256 tiles total but that doesn't restrict them to be 16x16 it just means you need 16 32x32 or whatever size you choose "tile images" per row).
Here is an quick example :Code: [Select][OVERRIDE:34:B:WORKSHOP_CARPENTER:Workshop::leocean:16]
[OVERRIDE:61:B:WORKSHOP_CARPENTER:Workshop::leocean:17]
[OVERRIDE:93:B:WORKSHOP_CARPENTER:Workshop::leocean:208]
[OVERRIDE:176:B:WORKSHOP_CARPENTER:Workshop::leocean:209]
(http://tof.canardpc.com/view/88e54ac6-5d89-4d6c-b0db-0733189dbfa9.jpg)
34 is the center top tile, 61 the top right, 93 the bottom and 176 are the three table tiles.
You can still use overrides for workshops, but if two tiles are the same, they will still be the same with overrides.
I prefer to use short names, it is more readable and I don't want to have to remember which number is which tileset.
Hi,
Sorry for my ignorance, I've been trying to figure out what to do with the 5.17 update file... there is a few files into it and whatever I do it doesn't fix the font while in the game. The right menu is still way too small. I thought this would fix it?
What should I do?
Thx.
I prefer to use short names, it is more readable and I don't want to have to remember which number is which tileset.
more important thing: I can copy-paste [OVERRIDE:34:B:WORKSHOP_CARPENTER:Workshop::leocean:16] in my overrides, and I can't do the same with [OVERRIDE:34:B:WORKSHOP_CARPENTER:Workshop::5:16] because 5 (or any number) is probably used by other tileset.
I prefer to use short names, it is more readable and I don't want to have to remember which number is which tileset.
more important thing: I can copy-paste [OVERRIDE:34:B:WORKSHOP_CARPENTER:Workshop::leocean:16] in my overrides, and I can't do the same with [OVERRIDE:34:B:WORKSHOP_CARPENTER:Workshop::5:16] because 5 (or any number) is probably used by other tileset.
Well 5 would be the tileset that is used there. It's written like this in the overrides.txt.
Loading additional tilesets
[TILESET:font.png:fullscreenfont.png:Id]
File names are relative to the data/art folder
Id is an arbitrary string to refer this tileset later
[TILESET:Vanilla DF - 24x - Items.png:Vanilla DF - 24x - Items.png:2] (this is mephs item overrides)
[TILESET:Spacefox_16x16LeoCeanOverrides.png:Spacefox_16x16LeoCeanOverrides.png:3] (then this is my extra set of overrides that override some more items and such)
If I wanted a fourth tileset (technically fifth) it'd be something like this.
[TILESET:FourthOverrides.png:FourthOverrides.png:4]
And as I said 0 is the font tileset (curses or w.e text, it can be same as 1 but these two rely on your init while the others rely on what's in the overrides.txt), 1 is the graphics font (phoebus/mayday/ so if you were taking things from the other ones you'd write it like this.
[OVERRIDE:34 (tile you want to replace):B:WORKSHOP_CARPENTER:Workshop::leocean (tileset that you want to use, # or the name it seems):16 (new tile you want to use)]
[OVERRIDE:Tile:Kind:Id:Type:Subtype:Tileset:NewTile]
Copy-paste following 2 lines into Your override.txt somewhere.
[TILESET:Override - 48x - Quiver.png:Override - 48x - Quiver.png:QuiverTileSet]
[OVERRIDE:146:I:QUIVER:QUIVER::QuiverTileSet:0]
!Attention!
Don't just copy-paste this into your override.txt!
You need to choose instead of 2 some unused number, specific to Your installation only!
0 is the font tileset
1 is the graphics font
other are free to choose, but You MUST avoid assigning a single number to different tilesets!
[TILESET:Override - 48x - Quiver.png:Override - 48x - Quiver.png:2]
[OVERRIDE:146:I:QUIVER:QUIVER::2:0]
@Mifki @LeoCean
I been using the lnp and today it did ask me to update, which I did. After that I wasn't able to use F12 like before in order to switch to TTF or otherway around.
After reading a little, apparently its related to TWBT. Tried to update it but wasn't really able to.
compare this:Code: [Select]Copy-paste following 2 lines into Your override.txt somewhere.
[TILESET:Override - 48x - Quiver.png:Override - 48x - Quiver.png:QuiverTileSet]
[OVERRIDE:146:I:QUIVER:QUIVER::QuiverTileSet:0]
with this:Code: [Select]!Attention!
Don't just copy-paste this into your override.txt!
You need to choose instead of 2 some unused number, specific to Your installation only!
0 is the font tileset
1 is the graphics font
other are free to choose, but You MUST avoid assigning a single number to different tilesets!
[TILESET:Override - 48x - Quiver.png:Override - 48x - Quiver.png:2]
[OVERRIDE:146:I:QUIVER:QUIVER::2:0]
other are free to choose, but You MUST avoid assigning a single number to different tilesets!
@Mifki @LeoCean
I been using the lnp and today it did ask me to update, which I did. After that I wasn't able to use F12 like before in order to switch to TTF or otherway around.
After reading a little, apparently its related to TWBT. Tried to update it but wasn't really able to.
If you want TTF, just disable twbt. There should be a switch in lnp somewhere I believe, but I don't know. To do this manually, just change PRINT_MODE to 2D in init.txt
@Mifki @LeoCean
I been using the lnp and today it did ask me to update, which I did. After that I wasn't able to use F12 like before in order to switch to TTF or otherway around.
After reading a little, apparently its related to TWBT. Tried to update it but wasn't really able to.
True, I did not read the whole 74 pages...
Clément you mind pming your overrides.txt so I can check out what you've done with some of the buildings and maybe the overrides tileset you are using. Or even post it here, we really should get a thread somewhere so people have a better place to talk about the overrides tilesets. :-X
TWBT no display patch
in the console, and DF runs without twbt enabled.I can only get this to work in TWBT_LEGACY mode. If I use TWBT, it printsCode: [Select]TWBT no display patch
in the console, and DF runs without twbt enabled.
I am using ubuntu 14.04.
Any help would be appreciated.
Now that we're getting closer and closer to something complete, let's move the goalposts! Have there been any news on the "hijack the color rendering" front? Any breakthroughs or major roadblocks?I'd move the goalposts somewhere closer, after noting that 5.17 and indeed TwbT is in general amazing.
Now that we're getting closer and closer to something complete, let's move the goalposts! Have there been any news on the "hijack the color rendering" front? Any breakthroughs or major roadblocks?I'd move the goalposts somewhere closer, after noting that 5.17 and indeed TwbT is in general amazing.
I've had a number of people ask about tiles for the world map (in worldgen and embark). If this could be a standard tile set defined in overrides.txt, that would be awesome - just drop in a specialist set once developed, or use a square text set, and default to the text tiles if it's not set.
Yeah, I mean that possibility that you (unwisely) flashed sometime in the past about rendering in-game colors according to their true RGB values instead of the closest approximate from the default 16.
But honestly, no rush. You've already fixed almost everything that's been pissing me off about the tiles and text.
I think I know how to do this but I asked couple times here to explain some things about colour tokens and to provide a savegame with various dyed items (it's where the difference should be visible, right?) for testing, but nobody helped.
I was doing some more experiments with workshop overrides. I made a special tileset with numbers to easily find tile number and foreground and background colors and inverted tiles. I replaced all 256 tiles for WORKSHOP_ANY with this tileset.
Here are the building steps for the carpenter workshop :
(http://tof.canardpc.com/view/3f5d13c4-356b-423a-a0af-d654ee6031cb.jpg)
The background tiles (here the grass) are overridden with workshop tiles. Is that the intended behaviour?
I've had a number of people ask about tiles for the world map (in worldgen and embark). If this could be a standard tile set defined in overrides.txt, that would be awesome - just drop in a specialist set once developed, or use a square text set, and default to the text tiles if it's not set.
Yeah, I saw people complained about text world map. Ok let it be the next thing to do. The only problem I'm afraid to tell you is that world map tiles will have the size of text tiles, so not square. Can't do anything about it. Otherwise it's quite simple.
I can't find what was bothering you, but I'll get on that save right away. What were you missing?
With the use of the names for tilesets (instead of numbers), that should make it very easy to copy/paste and otherwise manipulate the Overrides.txt from one install to another.
@LeoCeanQuoteTrue, I did not read the whole 74 pages...
Neither did I... I don't usually read pages before my first post, maybe a page a 2 ahead of that if I'm interest but I did say it was a post in reply to your question so me expecting you to have read it isn't to far fetched. :P That picture looks like the curse font because of that small window on the side but I can't be sure since I don't actually use phoebus often.
If you don't like the spacefox text "tileset" included in twbt you can use the 16x16 curse one like I said, it's the big font without added spacefox stuff and if you have 40.13 r1 or r2 there should be mayday/phoebus text "tilesets" in their LNP\graphics folders.
I mostly played with phoebus prior to DF2014, but like spacefox a lot. I just dont like those small font/caractere that goes with all the graphics on the R3.
Everywhere where I see colour tokens in raws, for example STATE_COLOR for inorganicSpoiler (click to show/hide)
and here POWDER_DYE for dyeSpoiler (click to show/hide)
I also see DISPLAY_COLOR token with approximated colour. So the colours are approximated already in raws, not in game? Which of these colour specifications the game actually uses? Or I understand it all wrong and these tokens do something different?
STATE_COLOR is used internally to decide the color when preferences and uniform assignments ask for it. It doesn't seem like it has an effect on what's displayed to the player. DISPLAY_COLOR handles that - I tried replacing the siltstone's DISPLAY_COLOR token with STATE_COLOR:ALL:AMETHYST and it just defaulted to material template stuff and eventually to just white on light gray when I ripped them out of the templates themselves.
What comes to dyes, the STATE_COLOR and DISPLAY_COLOR only apply to the powder itself, who knows what makes use of that info. The POWDER_DYE token is what decides the end result.
Maybe PeridexisErrant can help you better - you definitely just dislike some change because of twbt in the latest starter pack, but I still don't understand what exactly, and anyway I don't use starter pack launchers and all so I don't know what's the easiest way for you to get what you want.
I can only get this to work in TWBT_LEGACY mode. If I use TWBT, it printsCode: [Select]TWBT no display patch
in the console, and DF runs without twbt enabled.
I am using ubuntu 14.04.
Any help would be appreciated.
I can only get this to work in TWBT_LEGACY mode. If I use TWBT, it printsCode: [Select]TWBT no display patch
in the console, and DF runs without twbt enabled.
I am using ubuntu 14.04.
Any help would be appreciated.
I just tried on 14.04 and everything works fine. Are you sure you have different fonts for text and map specified in init.txt?
Thanks! I really appreciate all the work you do to keep this plugin working for everyone.
But for objects for which colour token is defined but DISPLAY_COLOR is used instead, things get more complicated as either raws will need to be updated, or I'll need to update material colours in memory (and probably to parse raws myself).I'm not sure how much information you have about an object, but if it's STATE_COLOR and pattern descriptions are in there then I think this is the lightest-weight approach.
Color name | Color token ID | Color token brightness |
AMBER | 6 | 1 |
AMETHYST | 5 | 1 |
AQUA | 3 | 1 |
AQUAMARINE | 3 | 1 |
I've had a number of people ask about tiles for the world map (in worldgen and embark). If this could be a standard tile set defined in overrides.txt, that would be awesome - just drop in a specialist set once developed, or use a square text set, and default to the text tiles if it's not set.
Yeah, I saw people complained about text world map. Ok let it be the next thing to do. The only problem I'm afraid to tell you is that world map tiles will have the size of text tiles, so not square. Can't do anything about it. Otherwise it's quite simple.
That's awesome! Shame about the size and shape, but thinking back it always was that way. I guess tile artists will have to be creative ;D
1. On load, scan through all of the DESCRIPTOR_COLOR objects and associate them with their closest display color based on the current color scheme.DF itself already does that for you when it parses the raws (because it uses STATE_COLOR for spatters and flows), so all you need to do is look at the the "color" and "bold" fields in descriptor_color.
I've had a number of people ask about tiles for the world map (in worldgen and embark). If this could be a standard tile set defined in overrides.txt, that would be awesome - just drop in a specialist set once developed, or use a square text set, and default to the text tiles if it's not set.
Yeah, I saw people complained about text world map. Ok let it be the next thing to do. The only problem I'm afraid to tell you is that world map tiles will have the size of text tiles, so not square. Can't do anything about it. Otherwise it's quite simple.
That's awesome! Shame about the size and shape, but thinking back it always was that way. I guess tile artists will have to be creative ;D
Tried now and can certainly say that graphics tileset squashed to the size of curses font looks like shit. So two options here - either use a different, more squary font as default text font. Or dynamically change text tile size to square on these several screens with world maps because there's not much text on them anyway. Or wait until someone makes a nice rectangular world map tileset, but I'm not sure that can be done.
troll:df-twbt-master$ make
c++ -std=c++0x twbt.cpp -o dist/0.34.11-r5/twbt.plug.so -DDFHACK_VERSION=\"0.34.11-r5\" -DDF_`echo 0.34.11-r5 | sed -e s/-r.*// -e s/\\\\.//g` -DTWBT_VER=\""5.xx"\" -I"/home/jbabcock/src/df-twbt-master/library/include" -I"/home/jbabcock/src/df-twbt-master/library/proto" -I"/home/jbabcock/src/df-twbt-master/depends/protobuf" -I"/home/jbabcock/src/df-twbt-master/depends/lua/include" -m32 -DLINUX_BUILD -O3 -L"/home/jbabcock/src/df-twbt-master/build/library" -ldfhack -shared
twbt.cpp:40:18: fatal error: Core.h: No such file or directory
#include "Core.h"
^
compilation terminated.
make: *** [dist/0.34.11-r5/twbt.plug.so] Error 1
Does anyone know of a twbt version compiled with gcc 4.8.3 or older? I can only find one compiled with 4.9.0. I installed the gcc-snapshot package, but I can't get twbt.plug.so to see it. It keeps coming up with /usr/lib/i386-linux-gnu/libstdc++.so.6, which is libstdc++.so.6.0.19. I tried putting the path to the snapshot lib directory in LD_LIBRARY_PATH, both at the beginning and the end, but apparently that is not how it works.
You'd just compile it with what is in the source file on the site not dfhack as I understand it. There is already a linux build though if you look at the development builds on the first page.That Linux build is built with GCC 4.9 and requires GCC 4.9 libraries. Some Linux distros (notably Ubuntu) do not have GCC 4.9 available in their package managers.
I'm a bit confused with overriding plants. It looks like PLANT:PLANT should cover single tile plants, and PLANT:LEAVES should cover leaves, but what about other growths?
HEART, FLOWERS, FRUIT, POD, BUDS, and BULB aren't listed in items_other_id.h How do I override them?
Does subtype only count plants that have that specific growth, or all plants?
For different growth stages, I assume I'd override the different tiles each stage uses with the same Id, Type, and Subtype, correct?
Thanks in advance. Sorry for the sheer number of questions.
You'd just compile it with what is in the source file on the site not dfhack as I understand it. There is already a linux build though if you look at the development builds on the first page.That Linux build is built with GCC 4.9 and requires GCC 4.9 libraries. Some Linux distros (notably Ubuntu) do not have GCC 4.9 available in their package managers.
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install g++-4.9
I personally don't know. There are definitely no LEAVES in 0.40 (but there's PLANT_GROWTH) item type. Probably plants need additional support in the plugin. You can figure out and I'll add it then.
So, it looks like you'd need the ability to specify the material in order to change the graphics for Fruits, Pods, Leaves, etc.
But when the plants are gathered you will use the item overrides then if you want them to look different than what they are set to in the raws.I'm okay with settling for that if I have to, but even then, it appears that they are differentiated solely be the material.
I want to know if it's possible to use TWBT to overides the fruit, polens, etc.. for the trees? Right now, i just use the main tileset without modifing the raws. But these tiles are kinda used on many place and i want to keep the raws modification to a minimal.
Is it possible to change the colors of a tiles with TWBT? Like the main tile color and the background one? If it's possible i have no clue how to do it.
In the older version i kinda used the original ascii for the font and a graphic set of different size. But now it seem that the tileset i use for font get upscale to the size of the graphic set. I don't if i do something wrong or it doesnt work for that version.
Thank you for your help, and mifki, you're genious for making that awesome plugin.
But I din't understand the last question, can you post a screenshot showing the problem?
Are you using the legacy rendering?
Are you using the legacy rendering?
I guess so, i currently use, [PRINT_MODE:TWBT_LEGACY].
Yep, that's it, change to TWBT.
Change these to zeroes WINDOWEDX WINDOWEDY.
Hm.. Aren't there any messages from twbt in dfhack console on start?
Actually even on your last screenshot I see that map tiles are square but text tiles are rectangular, so twbt sort of works.
Are you sure that's not what your text font is? Mayebe you replaced original curses font with something? Or there's another setting for zoom somewhere that I don't know about..
Since I don't do modding, I just don't know whether these override types allow to override everything you and other modders want or not. Likely not, so I can add other override types if someone figures out which df/dfhack data structures hold relevant data (yes, this would require some coding skills).
[TILESET:fallout.png:fallout.png:phoebus]
[OVERRIDE:186:T:ConstructedWallUD:phoebus:186]
Could you tell me if there is a possible way to discard the foreground color enforced by the game?
Has anyone built any sort of utilities for manipulating the Overwrites.txt?I think it might be easier to rope in all the files in a particular directory, the way raws are processed. Then you just have to decide on what to do with repeated entries (my vote would be for last-in wins).
Something like INCLUDE statements?
I'm almost thinking of a batch file that can concatenate multiple text files into the Overwrites file..
So I can pick:
Workshops_v1
Stairs
Workshops_v2
Trees
Numbers_v3
or any combination of those, as I'm working trying to build up the tile-set.
I'm borrowing from several different sets, trying to get something with the "right" feel for it...and it's awkward having to remember to update one master override file.
Well curently we replace the tile itself, but there is still foreground/background color forced, so if I wanted a colorful specific item most likely some dark material color would screw it up. So I guess it is impossible to overwrite specific items with white/black tile only (without tile colors)?
Something like INCLUDE statements?
Why don't you change material colour then? I mean that's the idea (in df, not mine) - tile colour is determined by its material.For example if I wanted a color of material still show up on the bars, that's why I asked :).
QuoteWhy don't you change material colour then? I mean that's the idea (in df, not mine) - tile colour is determined by its material.For example if I wanted a color of material still show up on the bars, that's why I asked :).
That can be accomodated by modding as well. I am mostly depressed that my nicely colored laser rifles look brown when made from copper :D.Ah yeah, the weapons. Yeah, it might be best if they are mostly using white as ingame color, so that the sprites retain their original color. Or at least keep a secondary color, like brown/wood for the handles.
That can be accomodated by modding as well. I am mostly depressed that my nicely colored laser rifles look brown when made from copper :D.Ah yeah, the weapons. Yeah, it might be best if they are mostly using white as ingame color, so that the sprites retain their original color. Or at least keep a secondary color, like brown/wood for the handles.
Idk I'd like very much to be able to have different colors for materials it'd really help for bars if it could work for weapons ;D.
Version 5.24 has support for overriding tile colours. Please see readme for details.Interesting
Note: Any of NewTile, NewFg and NewBg parameters may be empty to use existing values without changes, but at least on of them must be present.guess it's a typo
Version 5.24 has support for overriding tile colours. Please see readme for details.Interesting
UPD:QuoteNote: Any of NewTile, NewFg and NewBg parameters may be empty to use existing values without changes, but at least on of them must be present.guess it's a typo
basic question here: so if i want to code new override as described in readme, without colour change, i should type it according to syntax
[OVERRIDE:Tile:Kind:Id:Type:Subtype:Tileset:NewTile::], with two : at end, right?
I just had a cool idea. It will require quite a bit of dedication, but we could modify raws a bit and then make appropriate engravings as pictures!
A quick mock-up:
(http://i.imgur.com/VaDvNU8.png)
You think that the engraving can be identified? They can show anything in the descriptor file, plus an unlimited amount of procedually generated history.The creatures are always their letters, and the other shapes have a tile. So you could have all humanoid creatures to have a human-like ASCII tile replacement, quadruped creatures a similar form etc, and then just shuffle ASCII tiles for other shapes and voila. It definitely works.
I just had a cool idea. It will require quite a bit of dedication, but we could modify raws a bit and then make appropriate engravings as pictures!
A quick mock-up:
(http://i.imgur.com/VaDvNU8.png)
Oh lol, i secretly thought of the same thing. The problem of today is it won't properly work with floors, as tile overrides will hide your dwarves and animals even if you use graphic sprites
dwarves standing on stone floor are replaced by dimple cups, because i wanted to change "engraved image of dwarf with dwarves" tile
(http://i62.tinypic.com/287gkl5.png)
That's why i'm waiting for creature overrides
(http://i.imgur.com/VaDvNU8.png)For a moment I thought that it's showing containers with contents. Nevermind.
Oh lol, i secretly thought of the same thing. The problem of today is it won't properly work with floors, as tile overrides will hide your dwarves and animals even if you use graphic sprites
dwarves standing on stone floor are replaced by dimple cups, because i wanted to change "engraved image of dwarf with dwarves" tile
(http://i62.tinypic.com/287gkl5.png)
That's why i'm waiting for creature overrides
I didn't understand - is this some actual bug or just what you're thinking about?
[OVERRIDE:1:T:StoneFloorSmooth:text:3]
so tile 1 (dwarf) if found on smooth stone floor translates to tile 3. i don't consider it as a bug, i think it supposed to work this way. But, this situation limits my ability to override image of dwarves that may be engraved on smooth floor.Because currently it would require tons of overrides for all symbols possibly used in engravings and all possible floor and wall tile types, right? This is not elegant and may be quite slow.We can already use ENGRAVINGS_START_OBSCURED:NO, or toggle it in game (which makes me wonder if it's really necessary to have yet more graphics for engravings). The easiest would be to tell TWBT that it should use the same object replacement coordinates, but from a different (set of) tileset(s).
Oh, got it. I can fix this easily I think, just make overrides not affect tiles with creatures.I actually thought of making tiles for all engraving "types" at least.
However I didn't know you're trying to override engravings with current override system and was talking about providing some better way to handle engravings. Because currently it would require tons of overrides for all symbols possibly used in engravings and all possible floor and wall tile types, right? This is not elegant and may be quite slow.
It looks like you also have Graphics Sets in addition to tile sets. Delete the contents of raws/graphicsYou don't, you can just delete those contents from the save folder as well.
You may need to regen the world for it to take effect, though.
@Guolin I'll check and make sure it works correctly if you set GRAPHICS:NO in init.txtWait, what? twbt shouldn't work when graphics set to NO. if that so it uses only text set for everything
@Guolin I'll check and make sure it works correctly if you set GRAPHICS:NO in init.txtWait, what? twbt shouldn't work when graphics set to NO. if that so it uses only text set for everythingSpoiler (click to show/hide)
I just checked this, and found something i wasn't expecting: if you set GRAPHICS to NO, game will stop using map tileset, but overrides will still work. This may lead to some interesting results
Crash on Dwarf Fort launch, first line of reshape graphics appeared in dfhack console then CTD.
Win7 64bit, DFSP 40-11r3 TWBT set. 5.25
http://dffd.wimbli.com/file.php?id=9920
@Guolin I'll check and make sure it works correctly if you set GRAPHICS:NO in init.txtWait, what? twbt shouldn't work when graphics set to NO. if that so it uses only text set for everythingSpoiler (click to show/hide)
I thought so as well, but you see - people want to be able to use just two text fonts with different size, but not creature graphics. Deleting files isn't a good solution.
He complained that they showed up when he set graphics to on, so I imagine he turned on graphics deliberately, most likely to use an ASCII tileset. Deleting the creature graphics is the only way I know of to have one without the other. If he later changes his mind, they are easy to get back. Those creature graphics are included with the Phoebus graphic set. He can just download that and copy them back.
He complained that they showed up when he set graphics to on, so I imagine he turned on graphics deliberately, most likely to use an ASCII tileset. Deleting the creature graphics is the only way I know of to have one without the other. If he later changes his mind, they are easy to get back. Those creature graphics are included with the Phoebus graphic set. He can just download that and copy them back.
GRAPHICS setting does NOT affect anything other than creature graphics. It's not required for tilesets.
He complained that they showed up when he set graphics to on, so I imagine he turned on graphics deliberately, most likely to use an ASCII tileset. Deleting the creature graphics is the only way I know of to have one without the other. If he later changes his mind, they are easy to get back. Those creature graphics are included with the Phoebus graphic set. He can just download that and copy them back.
GRAPHICS setting does NOT affect anything other than creature graphics. It's not required for tilesets.
I turned on GRAPHICS setting so that I could get a different ASCII tileset for the map than the ASCII tileset for the menu. When it was set to NO the menu and the map shared the same tileset, which defeats the whole point of the plugin. :) Maybe I'm doing something wrong, I don't know. Please let me know if you need to look at any of my configuration files.
At this point, I have no idea how to do that, so I'd love it if you could point me the right way. :) I tried deleting the whole /raw/graphics folder, renaming the folder, deleting the contents - nothing worked. I've been sifting through the entire DF folder and can't find the graphics. I have LNP set to ASCII default graphics so that shouldn't be a problem.You need to delete the raw/graphics folder in the main DF folder and the copy of it made in the data/save/regionX folder. Reload your save and it should be nothing but pure ASCII.
If I knew how to compile DFHack plugins I'd even change the source myself.
At this point, I have no idea how to do that, so I'd love it if you could point me the right way. :) I tried deleting the whole /raw/graphics folder, renaming the folder, deleting the contents - nothing worked. I've been sifting through the entire DF folder and can't find the graphics. I have LNP set to ASCII default graphics so that shouldn't be a problem.You need to delete the raw/graphics folder in the main DF folder and the copy of it made in the data/save/regionX folder. Reload your save and it should be nothing but pure ASCII.
If I knew how to compile DFHack plugins I'd even change the source myself.
@Guolin I'll check and make sure it works correctly if you set GRAPHICS:NO in init.txtThere is nothing wrong, you just need to remove GRAPHICS definitions here.
We can already use ENGRAVINGS_START_OBSCURED:NO, or toggle it in game (which makes me wonder if it's really necessary to have yet more graphics for engravings).
No, you're doing it right. I need to make changes to support graphics:no. In the meanwhile you can just delete creature graphics if you want.
No, you're doing it right. I need to make changes to support graphics:no. In the meanwhile you can just delete creature graphics if you want.
I'm not happy with this change: right now I'm using the GRAPHICS:YES in all tilesets, even in ASCII - with an empty graphics config file. It's a workaround, so even when twbt is off, the game loads the correct tilesets, and with twbt I can load a secondary font for text. It's not ideal I know, but it works.
Since upgrading to r5 of the Starter Pack one of my saved games crashes every time you try to follow a creature while my other save game is working fine. If I change the print mode to anything other than TWBT it appears to work fine. Also, if I leave the window the default size on load it works fine (with TWBT) but if I maximise the window it it will crash. I've upgraded TWBT to 5.26 but this does not appear to change anything. I've been using the PyLNP launcher mostly but I've also tested it with the old launcher too. Windows 7, mid range x86 machine.
This game has used a few DFHack commands, digv, digtype and clean mostly so perhaps something has been corrupted. Do you guys think it is worth investigating? I'm happy to provide files if you want.
if (b == string::npos || e == string::npos || str.find_first_not_of(" ") < b)
continue;
If I understand correctly that means that you only accept spaces before the first '[', and something like that: Some text [TOKEN]
is a comment.I was writing a parser for overrides.txt and I wondered what exactly was a comment.
In the TWBT code, I found:Code: [Select]if (b == string::npos || e == string::npos || str.find_first_not_of(" ") < b)
If I understand correctly that means that you only accept spaces before the first '[', and something like that:
continue;Code: [Select]Some text [TOKEN]
is a comment.
Did I understand correctly?
Do you know if that is the same for other df files using the bracket tokens?
How about the transparent tiles?
I have a suggestion, it is possible to add way for some tiles to not use in game color but the tiles one's? Pretty much like what you can do in vanilla game with creature graphic. I'm currently trying to make a different graphic for every type of grass, but since you can use only 2 color, it is a little bit hard for me to get the real color i want. Kinda like a switch you could put on some overides to turn off in game color.
Isn't it what was being discussed recently and is already done? See readme for OVERRIDE command.
Isn't it what was being discussed recently and is already done? See readme for OVERRIDE command.
Ya, i did read the overides readme but all i see is that i can add new foreground color and background color. It's possible to just not use any color at all and color directly the graphic?
Pretty much like stonsesence does the grass. If it's already possible then mb but didnt see how to do it.
Isn't it what was being discussed recently and is already done? See readme for OVERRIDE command.
Ya, i did read the overides readme but all i see is that i can add new foreground color and background color. It's possible to just not use any color at all and color directly the graphic?
Pretty much like stonsesence does the grass. If it's already possible then mb but didnt see how to do it.
Doesn't it produce the result you want if you set the color to white (16:16) for an override?
UPD: (http://i59.tinypic.com/67pqoz.png) True. I didn't checked colour overrides, but game translates colour as-is for white tiles. The question is: are we able to detect tile's initial colour to make different overrides for different colours?
Why do you want this? I mean, it's pretty simple to implement but maybe checking some other tile properties would be better for your task?
Doesn't it produce the result you want if you set the color to white (16:16) for an override?
Why do you want this? I mean, it's pretty simple to implement but maybe checking some other tile properties would be better for your task?
mockup:
(http://i60.tinypic.com/2hp7uwz.png)
Look, there is two chairs. One made out of slate. Other made out of wood.
Suppose we have ability to detect tile colour and work with it. What can we do?
Step 1. Change colour of all trees to brown
Step 2. Change colour of all stones and copper to any-but-brown
Step 3. Cast override of tile #210, colour brown to tile <tile number> of tileset <tileset name>, colour "same as it was"
And now we have simple wooden chair and more decent not-wooden throne
(http://i60.tinypic.com/33dfvyr.png)
That's not an elegant solution, and i can't say i absolutely need it, but i think that there are people, who'd like to obtain such a technology.
I downloaded DF starterpack in this page
http://dffd.wimbli.com/file.php?id=7622
and unzip it,
and download latest version of override.txt from here
http://www.bay12forums.com/smf/index.php?topic=129219.120
and overwrite it.
and played DF.
"Text Will Be Text" is include three Functions.
1. separate fonts (tilesets) for map tiles and for text
2. Multi-level rendering
3. override tile numbers for buildings, items and various tile types.
Function 1 is work well.
Function 2 is also work well.
But, Function 3 doesn't work!!
It is only black square!!! not various item tile!!
■■■ It just appear like this shape!!!
What's wrong??
The chair thing would also be doable if overrides could be material (or material group) specific, which has been mentioned as a feature request before.
Also, I'd like to remind that generally I'm against using overrides for things that can be done in raws, like replacing colours for some materials and so on. Mostly because of performance issues of course, especially when overriding widely used tiles and/or using many overrides for single tile (so that it needs to check them all). If raw editing is undesirable, I can think of some commands to change raws in memory instead.
Also, I'd like to remind that generally I'm against using overrides for things that can be done in raws, like replacing colours for some materials and so on. Mostly because of performance issues of course, especially when overriding widely used tiles and/or using many overrides for single tile (so that it needs to check them all). If raw editing is undesirable, I can think of some commands to change raws in memory instead.
Uh oh, so having to many overides for the same tiles can really reduce the fps? Like a different overides for every type of grass?
Actually I didn't quite finish tiletype overrides - overrides by special dfhack tiletype attributes (material, shape, etc.) are planned, so for things like soil floor there will be one record instead of four (material - soil, shape - floor), and it will also work faster. Sorry you have to list them all separately at the moment.
Btw, you don't have to use numbers for tileset IDs, they can be any descriptive strings.
<snip>
Also, I'd like to remind that generally I'm against using overrides for things that can be done in raws, like replacing colours for some materials and so on. Mostly because of performance issues of course, especially when overriding widely used tiles and/or using many overrides for single tile (so that it needs to check them all). If raw editing is undesirable, I can think of some commands to change raws in memory instead.
Obviously overrides by tile colour are easy too (obviously - because I already have tile colour when processing a tile), but I need to think of a better way to configure overrides - OVERRIDE command becomes too long and complicated.
Can machinery tiles be overwritten?
I'd like to add another tileset for rollers and change the way axles and gears look.
I've mostly been looking for material based overrides to have entirely different tiles based on the material, which, sadly, I can't do through raws.
With OVERRIDE getting too long, would it be possible to break it down into multiple tags? Like this:
[OVERRIDE:tile]
[TYPE:type][SUBTYPE:subtype][NEWTILE:tileset:new tile][NEWCOLOR:new foreground:newbackground:new brightness]
That is, it would group each tile override together, then set the new tiles, colors, etc if it meets certain criteria. For instance
[OVERRIDE:210]
[KIND:I][TYPE:CHAIR][MATERIAL:WOOD][NEWTILE:2:0]
[KIND:I][TYPE:CHAIR][MATERIAL:INORGANIC:IRON][NEWTILE:2:1]
Would replace all Wood chairs (Material token may be incorrect, I'm not at a computer with DF) with the first tile in tileset 2, and all Iron chairs with the second tile in tileset 2.
Actually I didn't quite finish tiletype overrides - overrides by special dfhack tiletype attributes (material, shape, etc.) are planned, so for things like soil floor there will be one record instead of four (material - soil, shape - floor), and it will also work faster. Sorry you have to list them all separately at the moment.
Oh, that would be cool.Btw, you don't have to use numbers for tileset IDs, they can be any descriptive strings.
Oh, you mean that could use a word instead? I just did it the same way as Leocean, i thought that was the only way to do it.
Mifiki - cheers for your awesome work, really enjoying that multi level view rendering !Now, if it could also work for floors above the current one.. !!!
Mifiki - cheers for your awesome work, really enjoying that multi level view rendering !Now, if it could also work for floors above the current one.. !!!
keybinding add Shift-O "twbt tilesize smaller"
keybinding add Shift-P "twbt tilesize bigger"
Now this changes the tilesize zoom but not the font size for me.Well it would have to exclude tiles above the visible+unobstructed tiles on the current layer, but it would work great for adventuring in the hills.Mifiki - cheers for your awesome work, really enjoying that multi level view rendering !Now, if it could also work for floors above the current one.. !!!
That doesn't really work in any game, think of it as towns in a sense where you can see below but you can't build above your current z layer/level. That's not going to change because that's how the game is.
Any other clean, sharp font would work though and recommendations would be appreciated! :DStoryteller is pretty sharp (http://www.bay12forums.com/smf/index.php?topic=138697.msg5480326#msg5480326), but might not be what you're looking for.
Well you can go here https://github.com/fricy/Spacefox/tree/master/data/art and just download the spacefox_text one then go to your init.txt in Dwarf Fortress 0.40.xx\data\init and change the font and Fullfont to = [FONT:Spacefox_16x16_text.png], [FULLFONT:Spacefox_16x16_text.png].It worked like a charm, thank you so much! You have no idea how much this helped me!
Or go https://github.com/fricy/DFgraphics look up w.e tileset you are using and maybe there's a font set there for you to use, there is one for phoebus. There should be a way to change the font size, I forget what it is. I don't think its a twbt option though.
Storyteller is pretty sharp (http://www.bay12forums.com/smf/index.php?topic=138697.msg5480326#msg5480326), but might not be what you're looking for.Storyteller looks very interesting, not necessarily easy to read but I'll give it a try. Thanks!
Simple Mood (http://www.bay12forums.com/smf/index.php?topic=144897.0) with its big, fat letters might be?
Well it would have to exclude tiles above the visible+unobstructed tiles on the current layer, but it would work great for adventuring in the hills.Mifiki - cheers for your awesome work, really enjoying that multi level view rendering !Now, if it could also work for floors above the current one.. !!!
That doesn't really work in any game, think of it as towns in a sense where you can see below but you can't build above your current z layer/level. That's not going to change because that's how the game is.
I really like the font that shows up for a split-second when the mainscreen appears. Here is a screenshot from .13:Spoiler (click to show/hide)
I've mixed together parts of the Phsstpok tileset (another nice looking 24x one) with the Bisasam 24 to make these in large part because I'm using a 1920x1080 screen and just can't deal with the tiny fonts anymore.I'm in the same boat: I've got my old, trusty 24" TFT with 19020x1068 which still works great but a small serif font like Curse (aptly named! xD) tires my eyes out quickly.
Edit 2: dear armok, 19020x1068! What the hell kinda wraparoundtheroom screen is that?!?!?! (kidding, I know you meant 1920, presumably x1080, or is it actually x1068?Na, I just fatfingered that. It's a regular full HD TFT. =D
I was hoping to hear you'd hacked an Occulus into Geordi's visor.Edit 2: dear armok, 19020x1068! What the hell kinda wraparoundtheroom screen is that?!?!?! (kidding, I know you meant 1920, presumably x1080, or is it actually x1068?Na, I just fatfingered that. It's a regular full HD TFT. =D
I was hoping to hear you'd hacked an Occulus into Geordi's visor.If I managed that you would be looking at my Kickstarter page right now! =P
I suppose I'll have to...Do you need the df-structures for for finding 40.17 too? If not, pretty please? :)
New release. 0.40.17-r1 will probably be faster than 0.40.16-r1.
I suppose I'll have to...Do you need the df-structures for for finding 40.17 too? If not, pretty please? :)New release. 0.40.17-r1 will probably be faster than 0.40.16-r1.
5.33 is ready, for os x and win only for now.Thx. I get "TWBT: no display patch" in the console, except for in legacy mode. Should I be concerned?
5.33 is ready, for os x and win only for now.Thx. I get "TWBT: no display patch" in the console, except for in legacy mode. Should I be concerned?
:-*I'm busy working on another amazing project that I'm hoping to show soon.5.33 is ready, for os x and win only for now.Thx. I get "TWBT: no display patch" in the console, except for in legacy mode. Should I be concerned?
I know you're busy on the iPhone tool right now, but do you have any thoughts on how the map tilesets will work? I'm wondering if it'd be significant extra work to have a distinct setting for each of the fort mini-map, the embark map, the region map, and the world map. The last three are all using the same legend at different zoom levels, so it may or may not make sense to differentiate those. I have never been able to figure out what the hell is going on with the fort mini-map.
How about an embark screen font? Presumably it would be a square font. Few if any of the map symbols can be changed in mods, so they are stable. Only a few of the text-y characters are used on the map, just:I know you're busy on the iPhone tool right now, but do you have any thoughts on how the map tilesets will work? I'm wondering if it'd be significant extra work to have a distinct setting for each of the fort mini-map, the embark map, the region map, and the world map. The last three are all using the same legend at different zoom levels, so it may or may not make sense to differentiate those. I have never been able to figure out what the hell is going on with the fort mini-map.
It's not hard to do, in fact I already wrote couple times that I've tried but didn't like the result. The problem is that I can only (with reasonable effort) make world/mini map tiles the size of the text, i.e. rectangular rather than square. And normal map font squeezed to that size looked terrible. Of course I could just implement it and wait for artists to make proper tilesets, but I also was thinking about some other solutions for the embark screens, like to dynamically change text (and therefore world map tiles) back to square on those screens because there's not a lot of text and the map is more important. But nobody ever replied to these posts so I did nothing.
It seems that TwbT is conflicting with "tweak stable-cursor" (report (http://www.reddit.com/r/dwarffortress/comments/2ohcah/tweak_stablecursor_doesnt_work_in_fullscreen_mode/)).
I noticed sometimes an overridden bridge tile is not painted correctly.
This happens after the screen is scrolled, or after using < and > to change z-level.
If you move the cursor to the position and then move away, the glitch is gone(like the cursor forces a refresh).
/snipImho the curses_640_300 font in the starter pack is terrible, you can find some replacements on the wiki or here (https://github.com/Lazy-Newb-Pack/Lazy-Newb-Pack-Linux/tree/master/pack/LNP/tilesets), or make your own with this utility (http://www.bay12forums.com/smf/index.php?topic=140250.0). For Mayday use a 10x16, or 12x16 or 16x16 size for best experience. Legacy needs the font dimension to be the same as the map to avoid stretching, so for Mayday 16x16 is a must!
On normal TWBT mode the text is waaay too small on my monitor using the Mayday graphics pack.
TWBT legacy mode also looks terrible and strecthed
you can find some replacements on the wiki or here (https://github.com/Lazy-Newb-Pack/Lazy-Newb-Pack-Linux/tree/master/pack/LNP/tilesets)
Imho the curses_640_300 font in the starter pack is terribleAnother default font would indeed be appreciated, mifki. Something larger with clean sans-serif letters if possible, please. <3
Another default font would indeed be appreciated, mifki. Something larger with clean sans-serif letters if possible, please. <3
Oh sorry I forgot to mention I haven't tried that in the newest version. So maybe it has been fixed. Last time I saw that I'm still playing 0.40.13
..........
.wwwwwww..
..........
...ggg....
..........
..........
w = wall
g = bridge
..........
.wwwwwww..
..........
...gwg....
..........
..........
..........
.wwwgwww..
..........
...ggg....
..........
..........
Oh sorry I forgot to mention I haven't tried that in the newest version. So maybe it has been fixed. Last time I saw that I'm still playing 0.40.13
Now I can confirm the problem is still there.
How to reproduct it:
1) Override the bridge tiles (in my case, I use the same tile)
2) Build a raising bridge and raise it
3) Make sure there's a wall in the way where you are going to scroll the screen, for example:Code: [Select]..........
.wwwwwww..
..........
...ggg....
..........
..........
w = wall
g = bridge
If you press down arrow to scroll you screen, it will look like this:Code: [Select]..........
.wwwwwww..
..........
...gwg....
..........
..........
If you press up arrow to scroll you screen, it will look like this:Code: [Select]..........
.wwwgwww..
..........
...ggg....
..........
..........
Using > and < has similar effect if there are walls on different z-level.
I thought I've fixed an issue like this, but probably I didn't check/notice it specifically with bridges, I'll check.
wait, wait, wait, mifki you really solved it?!
I think you might eventually need to ignore DF's tile updates and just blit the whole map each frame. Is there a break-even point where the overhead of re-blitting unchanged tiles is equal to the overhead of jumping between updated locations?wait, wait, wait, mifki you really solved it?!
No, I didn't understand utunnels was talking about this case. Indeed, if tiles have all the same parameters, it won't update them.
Well, actually, if it's a real problem, I can think about more aggressive updates. They happen on a separate thread anyway, so probably it won't have that big impact on performance on current hardware.
Curse text is blurry, hard to read and tires my eyes quickly. The Phoebus font reads very well and if it's 16x16 that's okay for me. Any non-square font would be just as welcome if it's a clean font.Another default font would indeed be appreciated, mifki. Something larger with clean sans-serif letters if possible, please. <3
I don't provide any default font, so ask starter packs authors.
However why do you want to use square text font when one of the main plugin features is to allow non-square text?
I think you might eventually need to ignore DF's tile updates and just blit the whole map each frame. Is there a break-even point where the overhead of re-blitting unchanged tiles is equal to the overhead of jumping between updated locations?
Note that TWBT appears to be compiled with gcc 4.9+, and I get this error:Code: [Select]/lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /home/**/test/04019r2-x64/df_linux/hack/plugins/twbt.plug.so
Note that TWBT appears to be compiled with gcc 4.9+, and I get this error:Code: [Select]/lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /home/**/test/04019r2-x64/df_linux/hack/plugins/twbt.plug.so
How isolated is the logic for determining what part of the screen is the Dwarf map?
As in, how easy would it be to rip it out and use it for my own project :)
Would you reccomend using it for replacing the rendered dwarf map entirely with something completely different? (In my case, perspective)
Is the separate TWBT print mode a permanent solution? Has it ever been possible to use a 2D print mode along with twbt in the past?
Well, it could be interesting for those whose video card doesn't support OpenGL or wish to have TrueType fonts.
Also can TWBT be enable in VBO print mode?
Mifki, I have been away for a bit, but someone just told me that you found a solution for the "no ttf with twbt" problem, by using print-mode:twbt and allowed smaller text that way. No ttf, but thats not needed if you get small text anyway.
Awesome! Thank you for that addition. :)
I think TwbT only allows a different font size, not a different sidebar size (in other words, the sidebar will only take up less space if you use a narrower font - you won't be able to see more text in it).
time passes (about 2-3 hours)
Site still down :(
more time passes (about 8 hours)
its up again ;) thanks
I said it would take more time. But why do you need it - no new releases yet anyway..Some of the people here have a compulsive need to know the instant anything changes. You can identify these people by the worn-out F5 on their keyboards :)
win user here - 5.38 crashes on load for me.Legacy mode works, but the font is basically unreadableSpoiler (click to show/hide)
I got 5.40 on my tiny netbook, it does start up (Twbt overrides work) in the menu and world generator, but after loading a map and trying to play, it instantly crashes. I'm not sure if its multilevel or simply the poor netbook that is trying to do OpenGL. "Dwarf Fortress has stopped working", on Win7, vanilla df.
I imagine a feature like this would make some people squick a bit, but it could have it's practical applications. Prepared elephant brains, for example, would appear as actual brains instead of a generic meat item.
Interesting idea (however apart from some organs it's hard for me to recognise anything on your image:) ). I need to check how body parts are handled / rendered.
Ahk. Will do. Thanks :)
Oh, and I'm referring to the list in the TWBT readme.
How about the map tiles though?
Stable Cursor isn't working for me with DF 40.23 + DFHack 40.23-r1 + TwbT 5.40 (linux)
I copied the 4 plug.so files to /hack/plugins and ran the game. Everything seems to work as intended except for Stable Cursor.
What can I do to fix my problem?
Transferred from my thread (http://www.bay12forums.com/smf/index.php?topic=126934.msg5937368#msg5937368)
Some questions, I'm having trouble figuring out what Tile Types (df/tiletype.h) refer to. Is there anywhere where they are explained more in detail? For example what do the following tiles refer to?
FeatureBoulder, TreeCapFloor1, FrozenRamp, GrassDarkFloor1, Grass2StairD, SemiMoltenRock, TreeRootSloping, Waterfall, SoilWetFloor2, StoneWallWorn1
Additionally, water tiles don't seem to be listed, as well as several other things like smoke, sea foam, and levers Am I also correct in assuming that RiverE, RiverN, etc. and BrookE, BrookN, etc. refer to map tiles? Where are the map tiles defined, as well? Can they be overridden or do they still need to be merged with the main tileset? I'm referring to tiles like Moon, Highwood forest, Necromancer's tower, Elven forest retreat, Shrines, Hills, etc.
[lua]# ~df.global.world.raws.itemdefs
<world_raws.T_itemdefs: 0x019a5ccc>
all = <vector<itemdef*>: 0x019a5ccc>
weapons = <vector<itemdef_weaponst*>: 0x019a5cd8>
trapcomps = <vector<itemdef_trapcompst*>: 0x019a5ce4>
toys = <vector<itemdef_toyst*>: 0x019a5cf0>
tools = <vector<itemdef_toolst*>: 0x019a5cfc>
tools_by_type = <vector<itemdef_toolst*>[]: 0x019a5d08>
instruments = <vector<itemdef_instrumentst*>: 0x019a5dd4>
armor = <vector<itemdef_armorst*>: 0x019a5de0>
ammo = <vector<itemdef_ammost*>: 0x019a5dec>
siege_ammo = <vector<itemdef_siegeammost*>: 0x019a5df8>
gloves = <vector<itemdef_glovesst*>: 0x019a5e04>
shoes = <vector<itemdef_shoesst*>: 0x019a5e10>
shields = <vector<itemdef_shieldst*>: 0x019a5e1c>
helms = <vector<itemdef_helmst*>: 0x019a5e28>
pants = <vector<itemdef_pantsst*>: 0x019a5e34>
food = <vector<itemdef_foodst*>: 0x019a5e40>
[lua]# ~df.global.world.raws.itemdefs.toys
<vector<itemdef_toyst*>: 0x019a5cf0>
0 = <itemdef_toyst: 0x0f617eb0>
1 = <itemdef_toyst: 0x0f7805c0>
2 = <itemdef_toyst: 0x0f780640>
3 = <itemdef_toyst: 0x0dc148e0>
4 = <itemdef_toyst: 0x0f7848e0>
[lua]# ~df.global.world.raws.itemdefs.toys[2]
<itemdef_toyst: 0x0f780640>
id = ITEM_TOY_HAMMER
subtype = 2
base_flags = <BitArray<>: 0x0f78064c>
source_hfid = -1
raw_strings = <vector<string*>: 0x0f780658>
name = toy hammer
name_plural = toy hammers
flags = <BitArray<>: 0x0f78066c>
item_toy
[OBJECT:ITEM]
[ITEM_TOY:ITEM_TOY_PUZZLEBOX]
[NAME:puzzlebox:puzzleboxes]
[HARD_MAT]
[ITEM_TOY:ITEM_TOY_BOAT]
[NAME:toy boat:toy boats]
[HARD_MAT]
[ITEM_TOY:ITEM_TOY_HAMMER]
[NAME:toy hammer:toy hammers]
[HARD_MAT]
[ITEM_TOY:ITEM_TOY_AXE]
[NAME:toy axe:toy axes]
[HARD_MAT]
[ITEM_TOY:ITEM_TOY_MINIFORGE]
[NAME:mini-forge:mini-forges]
[HARD_MAT]
item_ammo.txt
0 [ITEM_AMMO:ITEM_AMMO_BOLTS]
1 [ITEM_AMMO:ITEM_AMMO_ARROWS]
2 [ITEM_AMMO:ITEM_AMMO_BLOWDARTS]
item_armor.txt
0 [ITEM_ARMOR:ITEM_ARMOR_BREASTPLATE]
1 [ITEM_ARMOR:ITEM_ARMOR_MAIL_SHIRT]
2 [ITEM_ARMOR:ITEM_ARMOR_LEATHER]
3 [ITEM_ARMOR:ITEM_ARMOR_COAT]
4 [ITEM_ARMOR:ITEM_ARMOR_SHIRT]
5 [ITEM_ARMOR:ITEM_ARMOR_CLOAK]
6 [ITEM_ARMOR:ITEM_ARMOR_TUNIC]
7 [ITEM_ARMOR:ITEM_ARMOR_TOGA]
8 [ITEM_ARMOR:ITEM_ARMOR_CAPE]
9 [ITEM_ARMOR:ITEM_ARMOR_VEST]
10 [ITEM_ARMOR:ITEM_ARMOR_DRESS]
11 [ITEM_ARMOR:ITEM_ARMOR_ROBE]
item_food.txt
0 [ITEM_FOOD:ITEM_FOOD_BISCUITS]
1 [ITEM_FOOD:ITEM_FOOD_STEW]
2 [ITEM_FOOD:ITEM_FOOD_ROAST]
item_gloves.txt
0 [ITEM_GLOVES:ITEM_GLOVES_GAUNTLETS]
1 [ITEM_GLOVES:ITEM_GLOVES_GLOVES]
2 [ITEM_GLOVES:ITEM_GLOVES_MITTENS]
item_helm.txt
0 [ITEM_HELM:ITEM_HELM_HELM]
1 [ITEM_HELM:ITEM_HELM_CAP]
2 [ITEM_HELM:ITEM_HELM_HOOD]
3 [ITEM_HELM:ITEM_HELM_TURBAN]
4 [ITEM_HELM:ITEM_HELM_MASK]
5 [ITEM_HELM:ITEM_HELM_VEIL_HEAD]
6 [ITEM_HELM:ITEM_HELM_VEIL_FACE]
7 [ITEM_HELM:ITEM_HELM_SCARF_HEAD]
item_instrument.txt
0 [ITEM_INSTRUMENT:ITEM_INSTRUMENT_FLUTE]
1 [ITEM_INSTRUMENT:ITEM_INSTRUMENT_TRUMPET]
2 [ITEM_INSTRUMENT:ITEM_INSTRUMENT_HARP]
3 [ITEM_INSTRUMENT:ITEM_INSTRUMENT_DRUM]
4 [ITEM_INSTRUMENT:ITEM_INSTRUMENT_PICCOLO]
item_pants.txt
0 [ITEM_PANTS:ITEM_PANTS_PANTS]
1 [ITEM_PANTS:ITEM_PANTS_GREAVES]
2 [ITEM_PANTS:ITEM_PANTS_LEGGINGS]
3 [ITEM_PANTS:ITEM_PANTS_LOINCLOTH]
4 [ITEM_PANTS:ITEM_PANTS_THONG]
5 [ITEM_PANTS:ITEM_PANTS_SKIRT]
6 [ITEM_PANTS:ITEM_PANTS_SKIRT_SHORT]
7 [ITEM_PANTS:ITEM_PANTS_SKIRT_LONG]
8 [ITEM_PANTS:ITEM_PANTS_BRAIES]
item_shield.txt
0 [ITEM_SHIELD:ITEM_SHIELD_SHIELD]
1 [ITEM_SHIELD:ITEM_SHIELD_BUCKLER]
item_shoes.txt
0 [ITEM_SHOES:ITEM_SHOES_SHOES]
1 [ITEM_SHOES:ITEM_SHOES_BOOTS]
2 [ITEM_SHOES:ITEM_SHOES_BOOTS_LOW]
3 [ITEM_SHOES:ITEM_SHOES_SANDAL]
4 [ITEM_SHOES:ITEM_SHOES_CHAUSSE]
5 [ITEM_SHOES:ITEM_SHOES_SOCKS]
item_siegeammo.txt
0 [ITEM_SIEGEAMMO:ITEM_SIEGEAMMO_BALLISTA]
item_tool.txt
0 [ITEM_TOOL:ITEM_TOOL_CAULDRON]
1 [ITEM_TOOL:ITEM_TOOL_LADLE]
2 [ITEM_TOOL:ITEM_TOOL_BOWL]
3 [ITEM_TOOL:ITEM_TOOL_MORTAR]
4 [ITEM_TOOL:ITEM_TOOL_PESTLE]
5 [ITEM_TOOL:ITEM_TOOL_KNIFE_CARVING]
6 [ITEM_TOOL:ITEM_TOOL_KNIFE_BONING]
7 [ITEM_TOOL:ITEM_TOOL_KNIFE_SLICING]
8 [ITEM_TOOL:ITEM_TOOL_KNIFE_MEAT_CLEAVER]
9 [ITEM_TOOL:ITEM_TOOL_FORK_CARVING]
10 [ITEM_TOOL:ITEM_TOOL_NEST_BOX]
11 [ITEM_TOOL:ITEM_TOOL_JUG]
12 [ITEM_TOOL:ITEM_TOOL_LARGE_POT]
13 [ITEM_TOOL:ITEM_TOOL_HIVE]
14 [ITEM_TOOL:ITEM_TOOL_HONEYCOMB]
15 [ITEM_TOOL:ITEM_TOOL_POUCH]
16 [ITEM_TOOL:ITEM_TOOL_MINECART]
17 [ITEM_TOOL:ITEM_TOOL_WHEELBARROW]
18 [ITEM_TOOL:ITEM_TOOL_STEPLADDER]
item_toy.txt
0 [ITEM_TOY:ITEM_TOY_PUZZLEBOX]
1 [ITEM_TOY:ITEM_TOY_BOAT]
2 [ITEM_TOY:ITEM_TOY_HAMMER]
3 [ITEM_TOY:ITEM_TOY_AXE]
4 [ITEM_TOY:ITEM_TOY_MINIFORGE]
item_trapcomp.txt
0 [ITEM_TRAPCOMP:ITEM_TRAPCOMP_GIANTAXEBLADE]
1 [ITEM_TRAPCOMP:ITEM_TRAPCOMP_ENORMOUSCORKSCREW]
2 [ITEM_TRAPCOMP:ITEM_TRAPCOMP_SPIKEDBALL]
3 [ITEM_TRAPCOMP:ITEM_TRAPCOMP_LARGESERRATEDDISC]
4 [ITEM_TRAPCOMP:ITEM_TRAPCOMP_MENACINGSPIKE]
item_weapon.txt
0 [ITEM_WEAPON:ITEM_WEAPON_WHIP]
1 [ITEM_WEAPON:ITEM_WEAPON_AXE_BATTLE]
2 [ITEM_WEAPON:ITEM_WEAPON_HAMMER_WAR]
3 [ITEM_WEAPON:ITEM_WEAPON_SWORD_SHORT]
4 [ITEM_WEAPON:ITEM_WEAPON_SPEAR]
5 [ITEM_WEAPON:ITEM_WEAPON_MACE]
6 [ITEM_WEAPON:ITEM_WEAPON_CROSSBOW]
7 [ITEM_WEAPON:ITEM_WEAPON_PICK]
8 [ITEM_WEAPON:ITEM_WEAPON_BOW]
9 [ITEM_WEAPON:ITEM_WEAPON_BLOWGUN]
10 [ITEM_WEAPON:ITEM_WEAPON_PIKE]
11 [ITEM_WEAPON:ITEM_WEAPON_HALBERD]
12 [ITEM_WEAPON:ITEM_WEAPON_SWORD_2H]
13 [ITEM_WEAPON:ITEM_WEAPON_SWORD_LONG]
14 [ITEM_WEAPON:ITEM_WEAPON_MAUL]
15 [ITEM_WEAPON:ITEM_WEAPON_AXE_GREAT]
16 [ITEM_WEAPON:ITEM_WEAPON_DAGGER_LARGE]
17 [ITEM_WEAPON:ITEM_WEAPON_SCOURGE]
18 [ITEM_WEAPON:ITEM_WEAPON_FLAIL]
19 [ITEM_WEAPON:ITEM_WEAPON_MORNINGSTAR]
20 [ITEM_WEAPON:ITEM_WEAPON_SCIMITAR]
21 [ITEM_WEAPON:ITEM_WEAPON_AXE_TRAINING]
22 [ITEM_WEAPON:ITEM_WEAPON_SWORD_SHORT_TRAINING]
23 [ITEM_WEAPON:ITEM_WEAPON_SPEAR_TRAINING]
Hmm...quick question. Is it possible to have different variations of a single tile spread randomly? Like how vanilla DF has grass variations of ,.`'?
Hmm...quick question. Is it possible to have different variations of a single tile spread randomly? Like how vanilla DF has grass variations of ,.`'?
Currently no. Easy to implement though. What do you want this for?
Hmm...quick question. Is it possible to have different variations of a single tile spread randomly? Like how vanilla DF has grass variations of ,.`'?
Currently no. Easy to implement though. What do you want this for?
Variation! :D I second this request. It would make boulders, tree leaves, water, and ground look less uniform and more natural.
Oh, I haven't even started thinking about it, but you're right, it can't be completely random because in that case image would change each time tile is updated on screen, eg. when scrolling map.
Instead of running random(3) every time, you can, for example, sum the coordinates and calculate the remainder after division by 3. if x+y+z = 124 = 1 mod 3, use 2nd tile. (maybe for more variation instead of x+y+z some other function can be used)
Oh, I haven't even started thinking about it, but you're right, it can't be completely random because in that case image would change each time tile is updated on screen, eg. when scrolling map.Instead of running random(3) every time, you can, for example, sum the coordinates and calculate the remainder after division by 3. if x+y+z = 124 = 1 mod 3, use 2nd tile. (maybe for more variation instead of x+y+z some other function can be used)
This specific proposal would lead to diagonal tiling in the XY plane. A pseudorandom function or hashing would help with that, at the cost of increased compute demand. I think it would still be worth it to find a reasonably lightweight way to avoid small-feature tiling, since a common use case will be grass, water, semimolten rock, etc in large blocks.
Currently no. Easy to implement though. What do you want this for?
Currently no. Easy to implement though. What do you want this for?
When I originally posted this idea, this is the image I had in mind:
(http://fc09.deviantart.net/fs70/f/2015/010/a/c/ground_example_by_dragondeplatino-d8dcitq.png)
Two grass tiles, and two dirt tiles. Each one has a simple 50/50 chance of being dispersed. Anything more than that, and the tiling effect would probably drain a lot of FPS (which isn't worth it for such a subtle effect). And as long as you pay careful attention to how you design your tiles, it's possible to "break the grid" with only two tiles.
How extensive is the tile overriding functionality?
Can you override graphics by material? Quality?
Is there a test map to see all the overrides?
Darwin? It does work for regular df hack 40.23 though, you can try it for your version.dfhack 0.40.23-r1 for OSX
Darwin? It does work for regular df hack 40.23 though, you can try it for your version.dfhack 0.40.23-r1 for OSX
most likely a stupid question but...
would it be possible to overwrite the "male" (caste 1, sex 1) graphics of dwarfs (most likely) with female ones if the dwarf is female (caste 0, sex 0) ?
or are these parameters not readable for this tool?
Yeah it's here http://do1.mifki.com:8810/dashboard;jsessionid=xeunpotjoogkf3aylctrcrw4 or Development Builds on the front page. Also there is a OSX starter pack here http://www.bay12forums.com/smf/index.php?topic=128960.0.Thanks Dwude
With an official DFHack release for 40.24 out, a new TwbT build would be awesome ;PKeep in mind that the Windows build is missing several offsets and several plugins won't work, so I don't recommend using it in a pack. It's more of a test release at this point, at least for Windows users.
Try version 5.41
Is there any chance to "fix" those small dorf icons in the z menu?
:P
Hmmm, I know the thing with the sliding tiles on the adventure mode travel map (where two adjacent tiles of the same type will blur together) is old, though interestingly it only happens at certain zoom levels, with a similar sort of weird diagonal hacking up of large text refreshes if I'm zoomed in too far.
Still getting a lot of instability though if I travel too far and then drop out of travel mode in the middle of a town.
A great beas the titan Snust
our people it for murder
vanqui glory in th
If you're using adventure mode, there are a number of problems with TwbT in it.
mifki: Any idea what's wrong with "tweak stable-cursor" in fortress mode?
Is there any chance to "fix" those small dorf icons in the z menu?
:P
What's wrong with them - that they are not square?
Soo I have run into an issue that is quite weird, when using TwbT and resizing my window above somewhere around 2052~ (roughly) horizontal resolution then the text starts acting weirdly. It goes from this: http://puu.sh/fG1RR/cace3ae44d.png to this http://puu.sh/fG1Ub/b054ab4614.png when it passes a certain width. I have been unable to find a way to prevent it and while it's playable it's quite annoying that the text is not as clear but rather weirdly pixelated.
Any ideas anyone?
I think that has to do with linear filtering in the inits. Switch it to NEAREST and it stops blurring the edges like that.
TWBT: no display patch
at the start andPlugin twbt has failed to shutdown!
when closing df.Is there a way to force dfhack to use a slightly outdated version of twbt?
You just need the latest version of the plugin, http://build.mifki.com/
Multilevel rendering is really a FPS killer to me now. For example, I'm playing a 1x1 map, there's a floor with some holes. I've already limited FPS to 50 and GFPS to 15. Without multilevel, the game runs normally, but if I use multilevel 5, FPS will drop to 20.
I tested some other floors. It seems, the speed depends on how many levels it actually renders. Even if there's only 1 hole on the floor and there are 5 z levels of open space below the hole, the game will be slowed down dramatically
It affect my fps but not gfps, strange. Maybe my fort is getting old, there are too many dead critters in the list.Multilevel rendering is really a FPS killer to me now. For example, I'm playing a 1x1 map, there's a floor with some holes. I've already limited FPS to 50 and GFPS to 15. Without multilevel, the game runs normally, but if I use multilevel 5, FPS will drop to 20.
I tested some other floors. It seems, the speed depends on how many levels it actually renders. Even if there's only 1 hole on the floor and there are 5 z levels of open space below the hole, the game will be slowed down dramatically
No real FPS issue here, but the real reason I keep turning it off is it makes it almost impossible to tell where traversable Z-drops are. This isn't so important in fortress mode, but it's incredibly annoying in adventure mode. The tiny amount of tint and perhaps drop shadowing? Nowhere near sufficient.
[OVERRIDE:37:I:FOOD:FOOD:0:2:15]
[OVERRIDE:37:I:FOOD:FOOD:1:2:16]
[OVERRIDE:37:I:FOOD:FOOD:2:2:17]
From TILESET:Vanilla DF - 24x - Items.png overrides prepared food, however it's in barrels or pots most of the time until they grab it to eat it. It's one of those.
I don't know if you can replace the activate screw pump tile I'd have to see what it looks like originally then with the override then while activate in both cases. But there's still only the one override in the readme so it may not be possible anyways.
Yeah, it's a bummer that it doesn't work as flawlessly with adventure mode as it does in fort mode since it is so useful for checking a keep at a glance for interesting loot. I wish I could toggle it.
Yeah, it's a bummer that it doesn't work as flawlessly with adventure mode as it does in fort mode since it is so useful for checking a keep at a glance for interesting loot. I wish I could toggle it.
You can set a pair of keybinds in the dfhack init - one to set multilevel to your preferred number of levels, and one for none.
If you've the spare keys you can of course put in several levels.
... feature request time! multilevel increment, decrement, and toggle commands - suitable for keybinding!
I mean toggle twbt since it's invaluable for stuff like scanning a keep for useful gear, but it glitches out a lot in travel mode and crashes a lot in forest retreats, but that's probably impossible since it's taking over the print mode entirely.Yeah, it's a bummer that it doesn't work as flawlessly with adventure mode as it does in fort mode since it is so useful for checking a keep at a glance for interesting loot. I wish I could toggle it.
You can set a pair of keybinds in the dfhack init - one to set multilevel to your preferred number of levels, and one for none.
I mean toggle twbt since it's invaluable for stuff like scanning a keep for useful gear, but it glitches out a lot in travel mode and crashes a lot in forest retreats, but that's probably impossible since it's taking over the print mode entirely.Yeah, it's a bummer that it doesn't work as flawlessly with adventure mode as it does in fort mode since it is so useful for checking a keep at a glance for interesting loot. I wish I could toggle it.
You can set a pair of keybinds in the dfhack init - one to set multilevel to your preferred number of levels, and one for none.
But you can always try to report glitches (better with a screenshot) and crashes)
[OVERRIDE:206:T:ConstructedFortification:4:206]
[OVERRIDE:206:T:StoneFortification:4:206]
[OVERRIDE:206:T:MineralFortification:4:206]
[OVERRIDE:206:T:LavaFortification:4:206]
[OVERRIDE:206:T:FeatureFortification:4:206]
[OVERRIDE:206:T:FrozenFortification:4:206]
I need to override fortifications. Do I need to change all those below? Or is there a simpler way?Code: [Select][OVERRIDE:206:T:ConstructedFortification:4:206]
[OVERRIDE:206:T:StoneFortification:4:206]
[OVERRIDE:206:T:MineralFortification:4:206]
[OVERRIDE:206:T:LavaFortification:4:206]
[OVERRIDE:206:T:FeatureFortification:4:206]
[OVERRIDE:206:T:FrozenFortification:4:206]
Is there a way to make use of fog effect to create day/night effect?
rendermax light
?Is there a way to make use of fog effect to create day/night effect?Code: [Select]rendermax light
?
I think it works if you switch twbt to legacy mode. With a serious fps penalty of course...
This will speed things up, and probably will be combined with a major rewrite to allow choosing tiles based on more parameters, like item/building fields, etc. (let's make animated machinery, huh), and full custom buildings of course. Not sure how all this will be configured though. And also I'm still hoping to implement the next and the last big thing I wanted about df graphics - multilayered rendering so that buildings/items don't completely hide what's beyond them.
Is it possible to use a larger picture to display the workshop?
For example, a 48x48 picture instead of 9 16x16 tiles. Maybe in the end it'll be come a 2D version of stonesense.
Yeah, but I'm already satisfied with current features.
Is it possible to use a larger picture to display the workshop?
For example, a 48x48 picture instead of 9 16x16 tiles. Maybe in the end it'll be come a 2D version of stonesense.
Yeah, but I'm already satisfied with current features.
÷═╕
o ~
~ o
What I mean is instead of replace the tiles of a workshop one by one, you use a single image for the entire workshop.
Oh I got another question: what are tile types for insect colonies? Currently they look exactly the same as wells.
Not sure how all this will be configured though.
Hmm. I might need to reorder PyLNP graphics code so we can have a default set, but overwrite the specific graphics pack... Minor change only.
Yeah, sounds good to me.
Does the tiles have to be 16x16 or we can still specify their size?
Ouch, for workshops there still will have to be a separate configuration somewhere - which tiles you want to be transparent, and what colours to use for each tile.Can you use alpha channels for transparency and multiple images per building? Image 0 is colored as-is, image 1 is tinted by the first building material, image 2 is tinted by the second material, etc. Keep that cool rectangular thing for animations. Just puts a bit of work on the artist to make sure things layer properly... you just need to provide a deterministic order in which the images are layered.
there isn't /that/ many buildings that use multiple materials, though. Off the top of my head, it'd only be useful for blacksmith and wellsIn vanilla, but I wouldn't want to make assumptions about mods. In my particular mod the custom buildings are made from three blocks of the same material, but others' might be more complicated and like to see that reflected on the screen.
there isn't /that/ many buildings that use multiple materials, though. Off the top of my head, it'd only be useful for blacksmith and wellsIn vanilla, but I wouldn't want to make assumptions about mods. In my particular mod the custom buildings are made from three blocks of the same material, but others' might be more complicated and like to see that reflected on the screen.
you can just drop whatever image files you want, no need to squeeze them into a single tileset image).
custom_foo_0.png is used as-is without any color manipulation. Transparent pixels show the floor.
custom_foo_1.png is laid on top, tinted by material 1. Transparent pixels show layer 0.
custom_foo_2.png is laid on top, tinted by material 2. Transparent pixels show layer 1.
there isn't /that/ many buildings that use multiple materials, though. Off the top of my head, it'd only be useful for blacksmith and wellsIn vanilla, but I wouldn't want to make assumptions about mods. In my particular mod the custom buildings are made from three blocks of the same material, but others' might be more complicated and like to see that reflected on the screen.
Well I was talking about a different thing. In vanilla buildings some of the tiles have fixed colours, some have material colours and some are transparent, right? There must be a way to specify this for custom graphics. On the other hand I don't want to lose the ability to just copy image of entire workshop and it will work without any any additional configuration.
you could always interpret some specific colours as something else.
Like, pure green = 00FF00 would be material colour, and blue = 0000FF transparent. Add more as needed :)
Just wanted to say that it is nice seeing you still further developing this. :)
I like that idea, just wish that there was a FOSS-compatible format that supported layers so you could compose everything in one window. As it is, I think you'd need to use GIMP or Illustrator, and manually export each layer as its own image.Was gonna say, pretty sure GIMP can export a layered png, just forgot what the lib was called, mng as mifki pointed out.
I don't think using some exotic file format is a good idea. Exporting layers to individual files is a trivial procedure (select-copy-switch to another file-paste), and there are actions (built-in and 3rd party) for Photoshop to do that automatically, and probably for other apps as well.If png and mng are supported by the same library it might (just might) be trivial to support both.
I know libpng has partial mng support, though I haven't checked how extensive that support is.From what I can find, .mng is designed for animated .png images, not multi-layer .png images. So just go with the the .png idea.
Libmng has full PNG support, since all PNG files are valid MNG files.
In any case, I can definitely foresee artists adding a "topcoat" image by giving it a layer number higher than any material actually used in the building. So long as that is handled gracefully (tinting with default material color of white is the same as not tinting at all, right?) then everyone will be happy.
What you described is what I'd expect for a general case, but an artist might want to also put an untinted layer (probably just tiny accents) on top of everything else. This is not really necessary since it could be handled with planning ahead on the transparency, it was more of turning graceful handling of an error (referencing a non-existing building material) as if it was a feature.In any case, I can definitely foresee artists adding a "topcoat" image by giving it a layer number higher than any material actually used in the building. So long as that is handled gracefully (tinting with default material color of white is the same as not tinting at all, right?) then everyone will be happy.
Didn't undestand this. I thought people would mostly want untinted base image at layer 0 and then add layers tinted with material colours and containing only smaller parts of the image. You're saying it will be the other way round?
I'm coming here first to start pinning down the source. Is it a problem in TWBT, dfhack or LNP?LNP. You should alert the author, r2 plugin is here. (http://do1.mifki.com:8810/dashboard)
Ta, will do.I'm coming here first to start pinning down the source. Is it a problem in TWBT, dfhack or LNP?LNP. You should alert the author, r2 plugin is here. (http://do1.mifki.com:8810/dashboard)
do i have to specifically generate one or is that output to a log somewhere?
do i have to specifically generate one or is that output to a log somewhere?
http://stackoverflow.com/a/2919398/991806
Thanks.
do i have to specifically generate one or is that output to a log somewhere?
http://stackoverflow.com/a/2919398/991806
Thanks.
So the core dump file is 1.3G...what should I do with it?
###########
# Weapons #
###########
# Whip
[OVERRIDE:47:I:WEAPON:WEAPON:0:2:77]
# Battle Axes
[OVERRIDE:47:I:WEAPON:WEAPON:1:2:78]
# War Hammers
[OVERRIDE:47:I:WEAPON:WEAPON:2:2:79]
# Short Swords
[OVERRIDE:47:I:WEAPON:WEAPON:3:2:80]
# Spears
[OVERRIDE:47:I:WEAPON:WEAPON:4:2:81]
# Maces
[OVERRIDE:47:I:WEAPON:WEAPON:5:2:82]
# Crossbows
[OVERRIDE:47:I:WEAPON:WEAPON:6:2:83]
# Picks
[OVERRIDE:47:I:WEAPON:WEAPON:7:2:84]
# Bows
[OVERRIDE:47:I:WEAPON:WEAPON:8:2:85]
# Blowguns
[OVERRIDE:47:I:WEAPON:WEAPON:9:2:86]
# Pikes
[OVERRIDE:47:I:WEAPON:WEAPON:10:2:88]
# Halberd
[OVERRIDE:47:I:WEAPON:WEAPON:11:2:87]
# Two-Handed Swords
[OVERRIDE:47:I:WEAPON:WEAPON:12:2:89]
# Long Swords
[OVERRIDE:47:I:WEAPON:WEAPON:13:2:90]
# Mauls
[OVERRIDE:47:I:WEAPON:WEAPON:14:2:91]
# Great Axes
[OVERRIDE:47:I:WEAPON:WEAPON:15:2:92]
# Large Dagger
[OVERRIDE:47:I:WEAPON:WEAPON:16:2:93]
# Scourges
[OVERRIDE:47:I:WEAPON:WEAPON:17:2:94]
# Flail
[OVERRIDE:47:I:WEAPON:WEAPON:18:2:94]
# Morning Stars
[OVERRIDE:47:I:WEAPON:WEAPON:19:2:95]
# Scimitars
[OVERRIDE:47:I:WEAPON:WEAPON:20:2:96]
# Training Axes
[OVERRIDE:47:I:WEAPON:WEAPON:21:2:97]
# Training Short Sword
[OVERRIDE:47:I:WEAPON:WEAPON:22:2:98]
# Training Spear
[OVERRIDE:47:I:WEAPON:WEAPON:23:2:99]
I'm working on a TWBT version of my new tileset, and I'm currently having an issue where nothing is getting overridden. I know TWBT is active, since multi-level rendering is working. PRINT_MODE is set to TWBT. I've checked un-overridden tiles with "createitem info" and the information it provides seems to match overrides.txt. The filename is TILESET matches the filename for the overrides. The override tile set is in the correct location (data/art) as is overrides.txt (data/init).
Is there anything else that could be blocking the tiles from being overridden?
The file's case matches the override.txt.
I've also changed it so they both use title case, but that hasn't had any effect.
Excuse me if this has been answered before, but is there some way to fix the issues with Twbt and the trees in 40.x?Is that Obsidian, and do the black rectangles animate?
I get things like this:
(http://i.imgur.com/Zg5WziX.png)
Or is this caused by something else? I'm using the newest DF version, newest Twbt version (I think) and print_mode:twbt_legacy.
I've set it to TWBT now (instead of legacy) and checked the version number, 5.42.
Any syntax or folder changes?I've set it to TWBT now (instead of legacy) and checked the version number, 5.42.
Unrelated to TwbT, you may want to update DFHack to r2 (and TwbT to .43) - there's a lot of nice stuff behind the scenes, including total encapsulation of mod-related DFHacks scripts in the raw folder; MW saves could potentially be portable!
Unrelated to TwbT, you may want to update DFHack to r2 (and TwbT to .43) - there's a lot of nice stuff behind the scenes, including total encapsulation of mod-related DFHacks scripts in the raw folder; MW saves could potentially be portable!Any syntax or folder changes?
Any syntax or folder changes?
[OVERRIDE:246:B:SCREW_PUMP:ScrewPump::NewTiles:3]
[OVERRIDE:37:B:SCREW_PUMP:ScrewPump::NewTiles:4]
I just had to change the tile number. First override replaces the inactive tile. Second override replaces the active tile.
Assuming you're referring to script_environment(), what scripts (if any) in the standard DFHack distribution are you using as modules? I'm planning on only allowing scripts that handle being used as modules to be accessed in this way, which would require a small change to these scripts.Any syntax or folder changes?
What worked before will still work in r2, but I started taking advantage of the new syntax to run scripts. It's quite better then the old way.
From a quick runaround in adventure mode on linux it is worth noting that the sliding tiles glitch didn't show up while traveling around and despite traveling/stopping in a forest retreat repeatedly it didn't crash, now if I could just figure out how to make it stop doing the am:0 am:5 am:0 am:26 spam in the terminal, looks promising though!
Ok, I will disable these messages.I would go with Max™'s suggestion and leave it as an option, and/or part of an exception handler if the plug-in knows it's in trouble.
Bug report: when viewing a screen in text mode, eg worldgen, item descrption, etc, 'reshape_graphics' is repeatedly printed to the console many times per second. Windows, DFHack 40_24 r3, TwbT 5.44
Ah, that's the culprit then.
https://github.com/lethosor/dfhack-scripts/blob/master/autoresetgrid.lua
It would be good to hide debug output in what are functionally release builds, but that's not a bug. Thanks for the explanation.
Why exactly is TwbT reallocating buffers if the screen size doesn't change, anyway?
I'm currently not using TwbT, so that much is unquestionably true.
Yeah, that's why I'm looking forward to a release with the am:0 reports turned off or as an optional -debug flag or something.
UNKNOWN CLASS 'ack21dfhack_lua_viewscreenE': vtable = 0xf7f66088
The "Unknown class" message (assuming it's in stderr.log) is a fairly harmless DFHack message.This is Dwarf Fortress, where "fairly harmless" means it takes several seconds to melt your skin off :)
The "Unknown class" message (assuming it's in stderr.log) is a fairly harmless DFHack message.Well, then it failed silently back to 2D mode when I tried to use TWBT_LEGACY in adventurer mode. Also, yeah, being able glance over at a little hammer icon on the ground and go "ah, toy for the hammerer", rather than get all excited when you see / and scroll down through the pile of stuff on top of it to find an extra-awesome ☼Adamantine War Hammer☼ sitting there instead of say, an axe, or sword, or spear... even a freaking dagger! I don't care, I keep one for hacking up carcasses anyways, why not have it made of candy?
Had an odd thought about some animation stuff that an added capability to TWBT would make possible...
Given that the game supports animated tiles, such as the native gem window color changing and the animated grass tiles some tileset makers have created, it occurred to me that mechanical components could be made to appear to rotate.
A waterwheel could have stripes that change position, an axle could have stripes (h) or dots (V), a gear assembly could have teeth that change position, a millstone could have radial stripes, etc.
That would give the appearance of rotation, but you'd really like to be able to turn it on/off depending on whether it's powered. If TWBT could do *conditional* tile overrides to replace the animated tile with a static tile when unpowered you'd have that.
Flip that lever and the parts start/stop rotating...
This conditional tile override ability may have other animation uses as well. Such as a workshop animated/static when Active/Idle.
I'm pretty sure DFHack is likely to already have the powered/unpowered and active/idle states accessible. Tilemakers doing animated tiles exist, is it possible TWBT could be made to do conditional overrides?
That's exactly my idea - add support for conditional overrides and animation. There would be images like
axle_vert.png
axle_vert-active.png <-- contains several frames for animation.
Now I just need to find time to finish this new version.
That's exactly my idea - add support for conditional overrides and animation. There would be images like
axle_vert.png
axle_vert-active.png <-- contains several frames for animation.
Now I just need to find time to finish this new version.
Excellent... I'd think that the normal tileset tiles being the animated ones and the overrides being the static version is advantageous because the animated ones then work normally for non-TWBT users transparently, but TWBT users gain the interactive animation ability. Tileset makers need only provide the static form separately (one frame of animation) for the override.
It might be necessary for TWBT to suppress the game's own attempts at animation to put its own nicer animations. Otherwise the waterwheel will wink in and out of its TWBT images.
With the next big DF release coming out in a month or two, my vote is to keep TwbT stable - and minimise
the pain of upgrading.
Actually... How hard would it be to merge TwbT into standard DFHack? Leaving TwbT alone means Mifki can focus on other projects like the UI server for df-ios, so it can act as a backend for Armok Vision 2 (and any other UI replacement).
Quote from: DFhack[DFHack]# /Applications/Macnewbie/Dwarf Fortress/dfhack: line 15: 181 Bus error DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"
logout
[Process completed]
This keeps on happening. Not only does it happen when I exit the game (a known error according to mifki), but also just randomly sometimes when I unpause. I'm running 10.6.8. It's really not fun to spend a half hour on designations then have the game quit unexpectedly without saving.
<...>
EDIT3: Disabled TWBT. This seems to have fixed it. I'll update this when the game has run for a year or two without crashing or it crashes.
EDIT4: Ok it was definitely TWBT causing the crashes. <...>
The thing is, unfortunately, apart from Meph's set of custom graphics for items, so far nobody created any tileset/graphics to make use of twbt features to change graphics for buildings/items/tiletypes. With 0.40 it became even more important because at least trees sharing graphics with other objects look like shit. Yes, there are some issues with changing tiles for workshops, but I see a lack of artists interested in creating graphics for twbt in the first place. Once there are any, I'll find a way to change all workshop tiles as well.Dragon de Platino is working on a Twbt set. :)
You did the thing!! I've been looking forward to this thing since you started this thing.
However, it really illustrates how few materials in the game actually have their own STATE_COLOR tags. Gemstones, specific product-type materials and not much else. Underground trees are all brown (the material template says so) while the actual logs and wooden products are all the usual color.
Bigger problem here is that tilesets are designed to make use of background and foreground colours, while if we take proper colour values from colour tokens, there will be only one foreground colour. For the background colour, we'll have to either leave it as is, or set to some fixed value (e.g. black or white).
I mean, since the game already contains all this colour information, I'd be happy to finally start using it instead of the limited 16 colour palette, but we'll need to think about compatibility with vanilla and whether there will be support from tileset authors, if required.
Sure proper colours missing from many materials, and also there's inconsistency in how colours are specified (for trees additional tag TREE_COLOR is used in few places). This all is solvable, including by using an external mat/colour db (thanks Japa, I'll take a look).
Bigger problem here is that tilesets are designed to make use of background and foreground colours, while if we take proper colour values from colour tokens, there will be only one foreground colour. For the background colour, we'll have to either leave it as is, or set to some fixed value (e.g. black or white).
I mean, since the game already contains all this colour information, I'd be happy to finally start using it instead of the limited 16 colour palette, but we'll need to think about compatibility with vanilla and whether there will be support from tileset authors, if required.
Sure proper colours missing from many materials, and also there's inconsistency in how colours are specified (for trees additional tag TREE_COLOR is used in few places). This all is solvable, including by using an external mat/colour db (thanks Japa, I'll take a look).
Bigger problem here is that tilesets are designed to make use of background and foreground colours, while if we take proper colour values from colour tokens, there will be only one foreground colour. For the background colour, we'll have to either leave it as is, or set to some fixed value (e.g. black or white).
I mean, since the game already contains all this colour information, I'd be happy to finally start using it instead of the limited 16 colour palette, but we'll need to think about compatibility with vanilla and whether there will be support from tileset authors, if required.
I would absolutely be in support of having this as an option. I am going to be designing my graphics set with this design philosophy (http://www.bay12forums.com/smf/index.php?topic=150753.msg6236880#msg6236880) in mind, and sacrificing background colors for unlimited foreground colors would be a godsend. Just earlier, I was trying out TWBT and struggling with how the plug-in colorizes objects. If I make my color scheme dark, then text looks good but tiles look faded. If I make my color scheme brighter, tiles look great but text looks washed out. Having a set of material colors independent of the color scheme would solve this problem and add a lot of flexibility to the set.
On a side note, when I was overriding GrassLightFloor and GrassDarkFloor, I noticed they're swapped. GrassLightFloor is the dark green grass and GrassDarkFloor is the light green grass. I'm not sure if that's a TWBT issue or one with DFHack, but I thought I'd just give a heads-up.
I'm not having any luck pulling up the http://do1.mifki.com:8810/ site, is it borked or link changed or just my end?
TWBT OVERRIDES
(Unknowns represented by ???)
ID:TYPE
(ORIGINAL TILE)
SUBTYPE
AMMO:AMMO
(47)
0 ITEM_AMMO_BOLTS
1 ITEM_AMMO_ARROWS
2 ITEM_AMMO_BLOWDARTS
AMULET:AMULET
(12)
???
ANIMALTRAP:ANIMALTRAP
(127)
???
ANVIL:ANVIL
(229)
???
ARMOR:ARMOR
(91)
0 ITEM_ARMOR_BREASTPLATE
1 ITEM_ARMOR_MAIL_SHIRT
2 ITEM_ARMOR_LEATHER
3 ITEM_ARMOR_COAT
4 ITEM_ARMOR_SHIRT
5 ITEM_ARMOR_CLOAK
6 ITEM_ARMOR_TUNIC
7 ITEM_ARMOR_TOGA
8 ITEM_ARMOR_CAPE
9 ITEM_ARMOR_VEST
10 ITEM_ARMOR_DRESS
11 ITEM_ARMOR_ROBE
ARMORSTAND:ARMORSTAND
(14)
???
BACKPACK:BACKPACK
(146)
???
BALLISTAARROWHEAD:BALLISTAARROWHEAD
???
???
BALLISTAPARTS:BALLISTAPARTS
???
???
BAR:BAR
(240)
???
BARREL:BARREL
(246)
???
BED:BED
(223)
???
BIN:BIN
(88)
???
BLOCKS:BLOCKS
(254)
???
BOOK:BOOK
(8)
???
BOULDER:BOULDER
(236) SAME ELEVATION
(249) LOWER ELEVATION
???
BOX:BOX
(146)
???
BRACELET:BRACELET
(153)
???
BUCKET:BUCKET
(150)
???
CABINET:CABINET
(227)
???
CAGE:CAGE
(19)
???
CATAPULTPARTS:CATAPULTPARTS
???
???
CHAIN:CHAIN
(179)
???
CHAIR:CHAIR
(210)
???
CHEESE:CHEESE
???
???
CLOTH:CLOTH
(167)
???
COFFIN:COFFIN
(48)
???
COIN:COIN
(36)
???
CORPSE:CORPSE
???
???
CORPSEPIECE:CORPSEPIECE
(253)
???
CROWN:CROWN
(230)
???
CRUTCH:CRUTCH
(194)
???
DOOR:DOOR
(15) GEM
(79) GLASS
(197) STONE
(186) WOOD/BONE
(240) METAL
???
DRINK:DRINK
???
???
EARRING:EARRING
(235)
???
EGG:EGG
(248)
???
FIGURINE:FIGURINE
(143)
???
FISH:FISH
(224)
???
FISH_RAW:FISH_RAW
(224)
???
FLASK:FLASK
(173)
???
FLOODGATE:FLOODGATE
(42) GEM
(88) STONE
(215) WOODEN/BONE
???
FOOD:FOOD
???
0 ITEM_FOOD_BISCUITS
1 ITEM_FOOD_STEW
2 ITEM_FOOD_ROAST
FOOD_STORAGE:???
???
GEM:GEM
(4) CUT/LARGE
(15) ROUGH/RAW
0 ONYX
1 MORION
2 SCHORL
3 LACE AGATE
4 BLUE JADE
5 LAPIS LAZULI
6 PRASE
7 PRASE OPAL
8 BLOODSTONE
9 MOSS AGATE
10 MOSS OPAL
11 VARISCITE
12 CHRYSOPRASE
13 CHRYSOCOLLA
14 SARD
15 CARNELIAN
16 BANDED AGATE
17 SARDONYX
18 CHERRY OPAL
19 LAVENDER JADE
20 PINK JADE
21 TUBE AGATE
22 FIRE AGATE
23 PLUME AGATE
24 BROWN JASPER
25 PICTURE JASPER
26 SMOKY QUARTZ
27 WAX OPAL
28 WOOD OPAL
29 AMBER OPAL
30 GOLD OPAL
31 CITRINE
32 YELLOW JASPER
33 TIGEREYE
34 TIGER IRON
35 SUNSTONE
36 RESIN OPAL
37 PYRITE
38 CLEAR TOURMALINE
39 GRAY CHALCEDONY
40 DENDRITIC AGATE
41 SHELL OPAL
42 BONE OPAL
43 WHITE CHALCEDONY
44 FORTIFICATION AGATE
45 MILK QUARTZ
46 MOONSTONE
47 WHITE JADE
48 JASPER OPAL
49 PINEAPPLE OPAL
50 ONYX OPAL
51 MILK OPAL
52 PIPE OPAL
53 AVENTURINE
54 TURQUOISE
55 QUARTZ_ROSE
56 CRYSTAL_ROCK
57 BLACK ZIRCON
58 BLACK PYROPE
59 MELANITE
60 INDIGO TOURMALINE
61 BLUE GARNET
62 TSAVORITE
63 GREEN TOURMALINE
64 DEMANTOID
65 GREEN ZIRCON
66 GREEN JADE
67 HELIODOR
68 PERIDOT
69 RED ZIRCON
70 RED TOURMALINE
71 RED PYROPE
72 ALMANDINE
73 RED GROSSULAR
74 PINK TOURMALINE
75 RED BERYL
76 FIRE OPAL
77 RHODOLITE
78 SPINEL_PURPLE
79 ALEXANDRITE
80 TANZANITE
81 MORGANITE
82 VIOLET SPESSARTINE
83 PINK GARNET
84 KUNZITE
85 CINNAMON GROSSULAR
86 HONEY YELLOW BERYL
87 JELLY OPAL
88 BROWN ZIRCON
89 YELLOW ZIRCON
90 GOLDEN BERYL
91 YELLOW SPESSARTINE
92 TOPAZ
93 TOPAZOLITE
94 YELLOW GROSSULAR
95 RUBICELLE
96 CLEAR GARNET
97 GOSHENITE
98 CAT'S EYE
99 CLEAR ZIRCON
100 AMETHYST
101 AQUAMARINE
102 SPINEL_RED
103 CHRYSOBERYL
104 OPAL_PFIRE
105 OPAL_REDFLASH
106 OPAL_BLACK
107 OPAL_WHITE
108 OPAL_CRYSTAL
109 OPAL_CLARO
110 OPAL_LEVIN
111 OPAL_HARLEQUIN
112 OPAL_PINFIRE
113 OPAL_BANDFIRE
114 DIAMOND_LY
115 DIAMOND_FY
116 EMERALD
117 RUBY
118 SAPPHIRE
119 DIAMOND_CLEAR
120 DIAMOND_RED
121 DIAMOND_GREEN
122 DIAMOND_BLUE
123 DIAMOND_YELLOW
124 DIAMOND_BLACK
125 SAPPHIRE_STAR
126 RUBY_STAR
GLOB:GLOB
(247)
???
GLOVES:GLOVES
(91)
0 ITEM_GLOVES_GAUNTLETS
1 ITEM_GLOVES_GLOVES
2 ITEM_GLOVES_MITTENS
GOBLET:GOBLET
???
???
GRATE:GRATE
(35)
???
HATCH_COVER:HATCH_COVER
(155)
???
HELM:HELM
(91)
0 ITEM_HELM_HELM
1 ITEM_HELM_CAP
2 ITEM_HELM_HOOD
3 ITEM_HELM_TURBAN
4 ITEM_HELM_MASK
5 ITEM_HELM_VEIL_HEAD
6 ITEM_HELM_VEIL_FACE
7 ITEM_HELM_SCARF_HEAD
8 INSTRUMENT
IN_PLAY:???
???
???
INSTRUMENT:INSTRUMENT
(168)
0 ITEM_INSTRUMENT_FLUTE
1 ITEM_INSTRUMENT_TRUMPET
2 ITEM_INSTRUMENT_HARP
3 ITEM_INSTRUMENT_DRUM
4 ITEM_INSTRUMENT_PICCOLO
LIQUID_MISC:LIQUID_MISC
(126)
(247)
???
MEAT:MEAT
(224)
???
MILLSTONE:MILLSTONE
(9)
???
ORTHOPEDIC_CAST:ORTHOPEDIC_CAST
???
???
PANTS:PANTS
(91)
0 ITEM_PANTS_PANTS
1 ITEM_PANTS_GREAVES
2 ITEM_PANTS_LEGGINGS
3 ITEM_PANTS_LOINCLOTH
4 ITEM_PANTS_THONG
5 ITEM_PANTS_SKIRT
6 ITEM_PANTS_SKIRT_SHORT
7 ITEM_PANTS_SKIRT_LONG
8 ITEM_PANTS_BRAIES
PET:PET
???
???
PIPE_SECTION:PIPE_SECTION
(124)
???
PLANT:PLANT
(3) DIMPLE CUPS
(5) QUARRY BUSHES, BLOSSOMS
(6) PLUMP HELMETS, LEAVES
(37) MISC. BERRIES
(58) STRAWBERRY, PRICKLE BERRY, FISHER BERRY, SUN BERRY, MISC. BERRIES
(111) WINTER MELON, WATERMELON
(152) VALLEY HERB
(159) ROPE REED
(231) PIG TAIL, CAVE WHEAT, LONGLAND GRASS, RAT WEED, HIDE ROOT, MUCK ROOT, BLADE WEED, SLIVER BARB
(232) SWEET POD, BLOATED TUBER, KOBOLD BULB
(250) PLANTS AT LOWER ELEVATION
???
PLANT_GROWTH:PLANT_GROWTH
???
???
POWDER_MISC:POWDER_MISC
(126)
(247)
???
QUERN:QUERN
(9)
???
QUIVER:QUIVER
(146)
???
REMAINS:REMAINS
(253)
???
RING:RING
(148)
???
ROCK:ROCK
(7)
???
ROUGH:ROUGH
???
???
SCEPTER:SCEPTER
(45)
???
SEEDS:SEEDS
(250)
???
SHIELD:SHIELD
(91)
0 ITEM_SHIELD_SHIELD
1 ITEM_SHIELD_BUCKLER
SHOES:SHOES
(91)
0 ITEM_SHOES_SHOES
1 ITEM_SHOES_BOOTS
2 ITEM_SHOES_BOOTS_LOW
3 ITEM_SHOES_SANDAL
4 ITEM_SHOES_CHAUSSE
5 ITEM_SHOES_SOCKS
SIEGEAMMO:SIEGEAMMO
(242)
(243)
0 ITEM_SIEGEAMMO_BALLISTA
SKIN_TANNED:SKIN_TANNED
(225)
???
SLAB:SLAB
(239)
???
SMALLGEM:SMALLGEM
(4) CUT/LARGE
(15) ROUGH/RAW
???
SPLINT:SPLINT
(159)
???
STATUE:STATUE
(234)
???
TABLE:TABLE
(209)
???
THREAD:THREAD
(237)
???
TOOL:TOOL
??? BOWL
??? MORTAR
??? PESTLE
??? CARVING KNIFE
??? BONING KNIFE
??? SLICING KNIFE
??? MEAT CLEAVER
??? CARVING FORK
??? POUCH
(8) NEST BOX
(13) LADLE
(22) HIVE
(147) CAULDRON
(153) WHEELBARROW
(158) STEPLADDER
(229) JUG
(236) HONEYCOMB
(238) LARGE POT
(254) MINECART
0 ITEM_TOOL_CAULDRON
1 ITEM_TOOL_LADLE
2 ITEM_TOOL_BOWL
3 ITEM_TOOL_MORTAR
4 ITEM_TOOL_PESTLE
5 ITEM_TOOL_KNIFE_CARVING
6 ITEM_TOOL_KNIFE_BONING
7 ITEM_TOOL_KNIFE_SLICING
8 ITEM_TOOL_KNIFE_MEAT_CLEAVER
9 ITEM_TOOL_FORK_CARVING
10 ITEM_TOOL_NEST_BOX
11 ITEM_TOOL_JUG
12 ITEM_TOOL_LARGE_POT
13 ITEM_TOOL_HIVE
14 ITEM_TOOL_HONEYCOMB
15 ITEM_TOOL_POUCH
16 ITEM_TOOL_MINECART
17 ITEM_TOOL_WHEELBARROW
18 ITEM_TOOL_STEPLADDER
TOTEM:TOTEM
(135)
???
TOY:TOY
(145)
0 ITEM_TOY_PUZZLEBOX
1 ITEM_TOY_BOAT
2 ITEM_TOY_HAMMER
3 ITEM_TOY_AXE
4 ITEM_TOY_MINIFORGE
TRACTION_BENCH:TRACTION_BENCH
(232)
???
TRAPCOMP:TRAPCOMP
(228)
0 ITEM_TRAPCOMP_GIANTAXEBLADE
1 ITEM_TRAPCOMP_ENORMOUSCORKSCREW
2 ITEM_TRAPCOMP_SPIKEDBALL
3 ITEM_TRAPCOMP_LARGESERRATEDDISC
4 ITEM_TRAPCOMP_MENACINGSPIKE
TRAPPARTS:TRAPPARTS
???
???
VERMIN:VERMIN
(123)
(125)
(177)
(249)
(250)
???
WEAPON:WEAPON
(47)
0 ITEM_WEAPON_WHIP
1 ITEM_WEAPON_AXE_BATTLE
2 ITEM_WEAPON_HAMMER_WAR
3 ITEM_WEAPON_SWORD_SHORT
4 ITEM_WEAPON_SPEAR
5 ITEM_WEAPON_MACE
6 ITEM_WEAPON_CROSSBOW
7 ITEM_WEAPON_PICK
8 ITEM_WEAPON_BOW
9 ITEM_WEAPON_BLOWGUN
10 ITEM_WEAPON_PIKE
11 ITEM_WEAPON_HALBERD
12 ITEM_WEAPON_SWORD_2H
13 ITEM_WEAPON_SWORD_LONG
14 ITEM_WEAPON_MAUL
15 ITEM_WEAPON_AXE_GREAT
16 ITEM_WEAPON_DAGGER_LARGE
17 ITEM_WEAPON_SCOURGE
18 ITEM_WEAPON_FLAIL
19 ITEM_WEAPON_MORNINGSTAR
20 ITEM_WEAPON_SCIMITAR
21 ITEM_WEAPON_AXE_TRAINING
22 ITEM_WEAPON_SWORD_SHORT_TRAINING
23 ITEM_WEAPON_SPEAR_TRAINING
WEAPONRACK:WEAPONRACK
(251)
???
WINDOW:WINDOW
(177)
???
WOOD:WOOD
(22)
???
ANY_ARMOR_GLOVES
ANY_ARMOR_HELM
ANY_ARMOR_PANTS
ANY_ARMOR_SHOES
ANY_ARTIFACT
ANY_AUTO_CLEAN
ANY_CAGE_OR_TRAP
ANY_CAN_ROT
ANY_COOKABLE
ANY_CORPSE
ANY_CRITTER
ANY_DEAD_DWARF
ANY_DRINK
ANY_EDIBLE_BONECARN
ANY_EDIBLE_CARNIVORE
ANY_EDIBLE_RAW
ANY_EDIBLE_VERMIN
ANY_EDIBLE_VERMIN_BOX
ANY_ENCASED
ANY_FURNITURE
ANY_GOOD_FOOD
ANY_IN_CONSTRUCTION
ANY_MELT_DESIGNATED
ANY_MURDERED
ANY_RECENTLY_DROPPED
ANY_REFUSE
ANY_SPIKE
ANY_TRUE_ARMOR
ANY_WEAPON
ANY_WEBS
Maybe you're right, mifki. For now, I'll just be defaulting to a subtype of 0 if I can't find any subtypes. If there's something I'm still missing at that point, I'll go ahead and ask here. Oh, but I still need to know what the tiles for bowls, mortars, pestles, carving knives, boning knives, slicing knives, meat cleavers, carving forks and pouches are. I can't find those items on the Tilesets page (http://dwarffortresswiki.org/DF2014:Tilesets) and I can't remember them off the top of my head.You can find these tile-numbers in item_tool.txt. Tools are the only items that can use a custom tile, which is why you can't find any mentioning of a hardcoded tile.
Also, I'm working on a tile overrides list as well. It's going much more smoothly because I don't have to worry about the subtypes, just what the original ASCII tiles where. I'll go ahead and share that once it's finished.
[ITEM_TOOL:ITEM_TOOL_MORTAR]
[NAME:mortar:mortars]
[VALUE:10]
[HARD_MAT]
[TOOL_USE:GRIND_POWDER_RECEPTACLE]
[TILE:150] ===============>>> YOUR TILE NUMBER!
[SIZE:100]
[MATERIAL_SIZE:1]
[CONTAINER_CAPACITY:1000]
You can find these tile-numbers in item_tool.txt. Tools are the only items that can use a custom tile, which is why you can't find any mentioning of a hardcoded tile.
Has zooming been fixed yet? I really like the idea of TWBT, but being off by half a screen when I zoom in is a pain in the ass - especially if I'm zooming because I want to find a specific dwarf in my dining room.
Of course it's possible, but it doesn't look like an universal solution to be enabled by default. As you can see, there have been discussions about colours here recently, and also some time ago when I announced the next major TWBT version with much easier configuration for overrides. I think soon I will release beta version with new overrides system and also add some options for tile colouring, at least to start a discussion about what we want to achieve with colours.
ID:TYPE
(ORIGINAL TILE)
SUBTYPE
AMMO:AMMO
(47)
0 ITEM_AMMO_BOLTS
1 ITEM_AMMO_ARROWS
2 ITEM_AMMO_BLOWDARTS
AMULET:AMULET
(12)
ANIMALTRAP:ANIMALTRAP
(127)
ANVIL:ANVIL
(229)
ARMOR:ARMOR
(91)
0 ITEM_ARMOR_BREASTPLATE
1 ITEM_ARMOR_MAIL_SHIRT
2 ITEM_ARMOR_LEATHER
3 ITEM_ARMOR_COAT
4 ITEM_ARMOR_SHIRT
5 ITEM_ARMOR_CLOAK
6 ITEM_ARMOR_TUNIC
7 ITEM_ARMOR_TOGA
8 ITEM_ARMOR_CAPE
9 ITEM_ARMOR_VEST
10 ITEM_ARMOR_DRESS
11 ITEM_ARMOR_ROBE
ARMORSTAND:ARMORSTAND
(14)
BACKPACK:BACKPACK
(146)
BALLISTAARROWHEAD:BALLISTAARROWHEAD
(17)
BALLISTAPARTS:BALLISTAPARTS
(220)
BAR:BAR
(240)
BARREL:BARREL
(246)
BED:BED
(233)
BIN:BIN
(88)
BLOCKS:BLOCKS
(254)
BOOK:BOOK
(8)
BOULDER:BOULDER
(7)
BOX:BOX
(11) LEATHER
(146) STONE/WOOD/METAL/GLASS
BRACELET:BRACELET
(153)
BUCKET:BUCKET
(150)
CABINET:CABINET
(227)
CAGE:CAGE
(19)
CATAPULTPARTS:CATAPULTPARTS
(220)
CHAIN:CHAIN
(179)
CHAIR:CHAIR
(210)
CHEESE:CHEESE
(37)
CLOTH:CLOTH
(167)
COFFIN:COFFIN
(48)
COIN:COIN
(36)
CORPSE:CORPSE
LOTS OF TILES
CORPSEPIECE:CORPSEPIECE
(253)
CROWN:CROWN
(230)
CRUTCH:CRUTCH
(194)
DOOR:DOOR
(15) GEM
(79) GLASS
(186) WOOD/BONE
(197) STONE
(240) METAL
EARRING:EARRING
(235)
EGG:EGG
(248)
FIGURINE:FIGURINE
(143)
FISH:FISH
(224)
FISH_RAW:FISH_RAW
(224)
FLASK:FLASK
(173)
FLOODGATE:FLOODGATE
(42) GEM
(88) STONE/METAL
(215) WOODEN/BONE
FOOD:FOOD
(37)
0 ITEM_FOOD_BISCUITS
1 ITEM_FOOD_STEW
2 ITEM_FOOD_ROAST
GEM:GEM
(4)
GLOB:GLOB
(247)
GLOVES:GLOVES
(91)
0 ITEM_GLOVES_GAUNTLETS
1 ITEM_GLOVES_GLOVES
2 ITEM_GLOVES_MITTENS
then TWBT would automatically try 229
And where would it take it from?
Anyway next version will not require tile numbers. If you didn't read last several pages, it's going to be as easy as placing a file like anvil.png in a folder, or ITEM_GLOVES_GAUNTLETS.png in gloves subfolder, and so on.
And where would it take it from?
The list I just showed you, of course. Though I guess that's irrelevant now.Anyway next version will not require tile numbers. If you didn't read last several pages, it's going to be as easy as placing a file like anvil.png in a folder, or ITEM_GLOVES_GAUNTLETS.png in gloves subfolder, and so on.
Please, please, please tell me there's still going to be support for sprite sheets...Working with separate image files sucks. For a lot of reasons.
Ahhh! So there's a configuration file that let's you specify the coordinates within an image and the image's location?
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.
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.
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.
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.
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.
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.
I don't get it. Are there any screenshots?
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.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.
I've also discovered another interesting quirk. And unlike the glitchy material colors, I don't think the next release will address this.
[CREATURE_GRAPHICS:WORM]
[DEFAULT:ANNELIDS:0:0:AS_IS:DEFAULT]
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.One way around this kind of thing is to make overrides for everything you can, and modify the default textures for those you can't. Hope this makes sense?
Toady One? I assumed BOULDER and ROCK were names the DFHack developers gave to the memory values.
See? This was exactly what I was talking about.
In DFHack, mined-out stone is called BOULDER while the pebbles you find in Adventure mode are ROCKs. If you swap out ROCK for BOULDER it should work. Oh, and make sure you do separate overrides for cinnabar/cobalt and bituminous coal since they use different tiles.
Hah, NewFg and NewBg were a requested feature as well, it's used when you have a colourful image for a tile and want to retain its colours instead of applying material colours.
I don't do that but I could see how it's useful. It seems like a bit of a cop-out to make all of your items the same color, though.
Quick question...
Along with support for animated buildings, is support for changing hard-coded workshop tiles in development? Like, so that you could eventually give every tile of a hard-coded workshop a unique graphic?
Your work is coming along great Dragon. Really looking forward to it.
Wouldn't TWBT be able to grab more information about each coordinate? So if a coordinate has for example, a dwarf and a floor on it, render the floor first then the dwarf on top. Or a coffin over a floor. Etc etc. A hierarchy list could be established based on what is more important to show on top. For example floor<item<dwarf. Would help the sprites blend together much much better.
Of course this requires the tileset to support it however with alpha transparency on the sprites.
But alas, it would render most older tilesets incompatible and wouldn't really work with ASCII graphics.
But once there's real transparency, how do we distinguish what pixels are transparent and what should show background colour?
But DragonDePlatino, your tileset has black background anyway, why are you so excited about transparency?
Fixes are coming along slowly, honestly, the DF Remote for iOS project is of higher priority for me now, as I need to release at least alpha/beta version asap.
PS. I think I know a way to make plant growth tiles and tree/shrub tiles customisable.
Fixes are coming along slowly, honestly, the DF Remote for iOS project is of higher priority for me now, as I need to release at least alpha/beta version asap.
I completely understand. Expanding the DF audience to mobile is a much bigger priority than marginal graphical improvements.
But once there's real transparency, how do we distinguish what pixels are transparent and what should show background colour?
Easy. Pure black is background and pure magenta is transparency. This could have a lot of applications, like letting you change the background color of a barrel based on what liquid is in it while still having transparency:
(http://orig02.deviantart.net/ff3e/f/2015/153/e/5/transparency_barrel_by_dragondeplatino-d8vs1ai.png)
The only downside is that you cannot have alpha blending for the background color. But it's a worthy tradeoff since you'll have your barrel sitting on a nice floor tile or grass tile.
Also, do tell. My current method of overwriting plants is changing them in the raws and then creating new overrides to reflect that. I'd be interested to see what you have in mind.
And also you can't use this colours if you need them in the actual image (especially black). But wait, there's still the alpha channel and it's not used at all your proposal. So maybe transparent pixels for transparency and magenta for bg colour?
Isn't this very limited because you can't specify tile numbers >255 in raws, so you won't be able to use different images for different plants? I was thinking I could make use of the colours that are specified for growth/plant tiles as well in raws to expand the tile number range. It becomes more difficult to configure so just in case people really want different tiles for different plants.
And also you can't use this colours if you need them in the actual image (especially black). But wait, there's still the alpha channel and it's not used at all your proposal. So maybe transparent pixels for transparency and magenta for bg colour?
That would work just fine too. The reason I suggested pure black (#000000) is because many pixel artists avoid that color. It is discouraged because it looks much better (http://www.bay12forums.com/smf/index.php?topic=129219.msg6268633#msg6268633) if you use other colors. So...how about magenta for the background and transparency for the transparency? I think that would fix the problem Meph is describing. That, or we could just ditch the background color entirely like you said.
One completely over-engineered solution would be to stack overrides, each one with an alpha channel, and each one with a declared color source (foreground, background, profession, as-is).
The question is, do we really need both background and foreground colours?
Am I missing something or isn't background color dynamic, as in "determined by stuff happening in the game"?Yes, that would happen.
Wouldn't removing background color from TWBT mean losing the information that is conveyed by the background color?
I'm not an artist or anything, I've just wondered since this discussion started.
Am I missing something or isn't background color dynamic, as in "determined by stuff happening in the game"?
Wouldn't removing background color from TWBT mean losing the information that is conveyed by the background color?
I'm not an artist or anything, I've just wondered since this discussion started.
This has been bothering me for a little while, so it could've been settled a year ago for all I know: Whenever the tilesets are a different size, the green X-cursor from mousequery that's supposed to follow the mouse pointer uses the X from the text tileset. This makes it either drag behind or overshoot the cursor more and more the further it gets from the top left corner.
It's a bother. Could it be fixed or, seeing it's not really vital, just disabled?
Which zooming problem do you mean?
Am I missing something or isn't background color dynamic, as in "determined by stuff happening in the game"?Yes, that would happen.
Wouldn't removing background color from TWBT mean losing the information that is conveyed by the background color?
I'm not an artist or anything, I've just wondered since this discussion started.
This has been bothering me for a little while, so it could've been settled a year ago for all I know: Whenever the tilesets are a different size, the green X-cursor from mousequery that's supposed to follow the mouse pointer uses the X from the text tileset. This makes it either drag behind or overshoot the cursor more and more the further it gets from the top left corner.
It's a bother. Could it be fixed or, seeing it's not really vital, just disabled?
Which zooming problem do you mean?
I didn't mean that one, though it is silly. No, I'm talking about the one where in Fortress mode you can select units from various menus to (z)oom to, but with TWBT it will zoom you to difficult-to-predict distances and directions away from the unit instead. You're guaranteed to be on the same Z-level, but that's not much help when you're trying to investigate (say) whether or not any of the clothes your military dwarves are wearing have forgotten beast dust on them. The fastest way to check is to zoom to each of your military dwarves in turn, but if one of them is in the dining hall, the zoom being off by even a couple tiles turns the whole thing into an exercise in frustration.
Are you sure you're using plugins (mousequery and couple others) provided with TWBT? That's exactly what they fix.
Which zooming problem do you mean?
I didn't mean that one, though it is silly. No, I'm talking about the one where in Fortress mode you can select units from various menus to (z)oom to, but with TWBT it will zoom you to difficult-to-predict distances and directions away from the unit instead. You're guaranteed to be on the same Z-level, but that's not much help when you're trying to investigate (say) whether or not any of the clothes your military dwarves are wearing have forgotten beast dust on them. The fastest way to check is to zoom to each of your military dwarves in turn, but if one of them is in the dining hall, the zoom being off by even a couple tiles turns the whole thing into an exercise in frustration.
Should be fixed in version 5.47.
I think the proper term here is: Oh, shit.
Yes?
Huh, I am not using them because they don't work. DFHack automatically disables them because they throw an error or something.This has been bothering me for a little while, so it could've been settled a year ago for all I know: Whenever the tilesets are a different size, the green X-cursor from mousequery that's supposed to follow the mouse pointer uses the X from the text tileset. This makes it either drag behind or overshoot the cursor more and more the further it gets from the top left corner.
It's a bother. Could it be fixed or, seeing it's not really vital, just disabled?
Are you sure you're using plugins (mousequery and couple others) provided with TWBT? That's exactly what they fix.
Huh, I am not using them because they don't work. DFHack automatically disables them because they throw an error or something.This has been bothering me for a little while, so it could've been settled a year ago for all I know: Whenever the tilesets are a different size, the green X-cursor from mousequery that's supposed to follow the mouse pointer uses the X from the text tileset. This makes it either drag behind or overshoot the cursor more and more the further it gets from the top left corner.
It's a bother. Could it be fixed or, seeing it's not really vital, just disabled?
Are you sure you're using plugins (mousequery and couple others) provided with TWBT? That's exactly what they fix.
If you want to I can take a look sometime in the next week to what error that was exactly.
The only error that can prevent them from working is incompatible dfhack/plugin version, which is strange. Anyway, can you try the latest version from https://build.mifki.com ?In the 5.47 the problem with misplaced X is gone.
I can confirm this. I've been doing some very light testing in Adventure Mode (start up a save, walk around a bit) and I've been getting very consistent crashes on the first fast travel of a session. I don't think it's a TWBT problem, though, because you cannot even override anything in the map.It is a TWBT problem. I've played ~100 adventure games since TWBT was released and this bug only happens when TWBT is enabled.
(It would be awesome if we could have separate text, map and worldgen tilesets BTW)
Was just thinking about something too. You mixed different tile sizes in those screenshots. Is it currently possible to do that and also use non square tiles? For example putting in a shrub that is 32x40 and overlaps the above tile? Or making walls slightly taller for a better fake isometric perspective?
I was thinking about this long time ago, technically it's possible, maybe I'll try and add it as an option.
Are we talking about this screen?Yeah that screen. Try it on a save that had other adventurers/forts. Those seem to crash more often that new saves.Spoiler (click to show/hide)
It works quite well for me, but I'll try on Windows later.
+1 from me. Larger monsters, especially megabeasts would be great, and spiky underground plants, and and and... ;)Was just thinking about something too. You mixed different tile sizes in those screenshots. Is it currently possible to do that and also use non square tiles? For example putting in a shrub that is 32x40 and overlaps the above tile? Or making walls slightly taller for a better fake isometric perspective?
I was thinking about this long time ago, technically it's possible, maybe I'll try and add it as an option.
items/weapon/sword_short.png
buildings/bed.png
buildings/bed-dorm.png
buildings/workshops/carpenter.png
inorganic/onyx.png
plants/asparagus-shrub.png
plants/asparagus-shrub-dead.png
plants/asparagus-picked.png
plants/asparagus-leaves.png
plants/asparagus-flowers.png
plants/asparagus-fruit.png
items/weapon/axe_battle = items,5,0 [=]
items/weapon/axe_great = items,5,1 [=]
items/weapon/axe_toy = items,5,2 [=]
items/weapon/spear = items,5,3 [=]
...
buildings/workshops/mason [222/=.=/=.=]
Something I found out today:
If you really don't want to allow TwbT to be unloaded, it might be better to detect SC_BEGIN_UNLOAD events in plugin_onstatechange and return CR_NOT_FOUND (CR_FAILURE would make more sense, I know; I'll probably change this in the next release). This is called at an earlier stage, before commands, lua functions, and other information has been cleared, so the plugin won't be considered "broken"/untouchable by DFHack.
I have good understanding what I want to do in the next version and how it all will be configured.
[OVERRIDE:247:T:SoilFloor1:3:25]
[OVERRIDE:247:T:SoilFloor2:3:26]
[OVERRIDE:126:T:SoilFloor3:3:27]
[OVERRIDE:126:T:SoilFloor4:3:28]
[OVERRIDE:247:T:SoilWetFloor1:3:33]
[OVERRIDE:247:T:SoilWetFloor2:3:34]
[OVERRIDE:126:T:SoilWetFloor3:3:35]
[OVERRIDE:126:T:SoilWetFloor4:3:36]
[OVERRIDE:247:T:SoilFloor1:3:25]
[OVERRIDE:247:T:SoilFloor2:3:26]
[OVERRIDE:247:T:SoilFloor3:3:27]
[OVERRIDE:247:T:SoilFloor4:3:28]
[OVERRIDE:247:T:SoilWetFloor1:3:33]
[OVERRIDE:247:T:SoilWetFloor2:3:34]
[OVERRIDE:247:T:SoilWetFloor3:3:35]
[OVERRIDE:247:T:SoilWetFloor4:3:36]
[OVERRIDE:7:T:SoilWall:3:38] (GemSet ocean walls)
[OVERRIDE:176:T:SoilWall:3:39] (Gemset clay walls)
[OVERRIDE:177:T:SoilWall:3:40] (GemSet sand walls)
[OVERRIDE:178:T:SoilWall:3:41] (GemSet Soil walls)
[OVERRIDE:30:T:SoilRamp:3:42]
[OVERRIDE:60:T:SoilStairU:3:43]
[OVERRIDE:62:T:SoilStairD:3:44]
[OVERRIDE:88:T:SoilStairUD:3:45]
[OVERRIDE:30:T:RiverRampN:3:46]
[OVERRIDE:30:T:RiverRampS:3:46]
[OVERRIDE:30:T:RiverRampE:3:46]
[OVERRIDE:30:T:RiverRampW:3:46]
[OVERRIDE:30:T:RiverRampNE:3:46]
[OVERRIDE:30:T:RiverRampNW:3:46]
[OVERRIDE:30:T:RiverRampSE:3:46]
[OVERRIDE:30:T:RiverRampSW:3:46]
[OVERRIDE:30:T:MurkyPoolRamp:3:47]
Mifki: Did you think about the caste specific graphics for creatures? It's the last major feature I can think of for Twbt and would give modders so much more freedom with races, and artists the option of making male/female creature sprites.
can this be the cause of some crashes? i'm playing with the winLNP.
so far i haven't found out why exactly it happens, but it was soon after the beginning of summer year 5...
it sounds logical as the game crashes always after some time, even if i didnt build the same structures/mined the same rooms. so, how can i avoid that?Generically, you can pave over saplings.
plant exterpate all
I'm using a graphics pack and it's really hard to see whether something is on my z level or the one below because it's only slightly darker if it's below. Is it possible to tweak this so that things on lower levels are much darker rather than just a tiny bit?
Was advised to post this here:I'm using a graphics pack and it's really hard to see whether something is on my z level or the one below because it's only slightly darker if it's below. Is it possible to tweak this so that things on lower levels are much darker rather than just a tiny bit?
e: Ah, seems like the multilevel layering thing is what I'm after. Hooray :)
Both DFhack and TWBT have awfully obtuse opening posts, don't they?
Answer, yes it's for the latest version of DF.
Easy option: Use Starter Pack. It's all pre-installed. Nothing more to do.
Standard option: Not using Starter pack:
1) Install DfHack. That has instructions someplace. Just remember it's not an installer, just a matter of copying the folders into the Dwarf Fortress main folder. Note that one file (SDL.dll) will be replaced - a backup is provided (SDLreal.dll).
2) Download TWBT plugin from git (opening post - latest release)
Copy the 4 .dll files from the archive (40.24-r3) and paste them into hack\plugins.
(The twbt.dll is the utility, the other 3 replace existing dfhack plugins for compatibility.)
Copy overrides.txt into data\init
Copy shadows.png into data\art
3) Change Print_Mode to TWBT in init.txt to activate it.
I'm experiencing some weird behaviour with TWBT. When I go on a workshop, set something to produce and set workflow constraints with 'alt+w', it opens the workflow screen, that's entirely black with the menu on the right side. Going out of that screen and back to DF, things sometimes get... erm... messy. Multiple tiles are rendered out of place and the more I move through z-levels, the more of a messy it gets. It takes some time to get back to normality, but I always save and load the game again, because I'm afraid it may crash. I do not have a SS of that right now (silly of me), but I'll provide one as soon as I can.
Edit:Spoiler (click to show/hide)
Pan around sometimes solves it, but sometimes makes it worse.
Edit 2: That might have something to do with mouse controls, also. When I get out of the workflow screen, the cursor isn't over the workshop anymore. And panning around only solves the thing if you move the weird rendered things in the screen to match their actual position.
I don't think there's a newer version of TWBT than 5.45? I looked on mifki's Github and the latest release is 5.45, and there had only been 5 commits since that release. I guess mifki is running from the latest compiled source but hasn't released a new general version yet?
Latest binaries are always at http://build.mifki.com
I don't think there's a newer version of TWBT than 5.45? I looked on mifki's Github and the latest release is 5.45, and there had only been 5 commits since that release. I guess mifki is running from the latest compiled source but hasn't released a new general version yet?
Latest binaries are always at http://build.mifki.com
Should I be distributing a newer version in the Starter Pack? My understanding was that the releases were stable, and the builds might not be.
I am using version 5.45, bundled with PyLNP. I just looked at mifki's Github and I see there have been 5 new commits since 5.45. One of them looked particularly interesting to me:
Fixed zooming to unit/building (https://github.com/mifki/df-twbt/commit/b0f590f4e1b8cd0e949383b6c5b0b04e53961215)
I have noticed that zooming is usually broken. If I zoom to a unit/building, it will end up looking at another tile on the Z level of the target building/unit.
OK, so now my question: is any of this related to the fixes mifki has made regarding "Fixed zooming to unit/building"? I thought the problem was only with mousequery, but maybe it is actually a problem in TWBT and it's possible to fix it in TWBT itself?
In my opinion, you ought to include some kind of additional version information if you're encouraging people to use non-release builds to make bug reporting/troubleshooting easier (DFHack obtains some git information when using CMake, although that might be harder to integrate into your build system).
My point is that if two builds are identified as, say, 5.47, it's difficult to tell them apart (although it's not an issue if you change the version number for every build; I'm not exactly sure what you do).
Should I be distributing a newer version in the Starter Pack? My understanding was that the releases were stable, and the builds might not be.
I thought most people were using builds from the build server (and you as well). I usually wait for positive feedback for new builds and then forget to make a Github release.
Should I be distributing a newer version in the Starter Pack? My understanding was that the releases were stable, and the builds might not be.
I thought most people were using builds from the build server (and you as well). I usually wait for positive feedback for new builds and then forget to make a Github release.
I'd be a lot happier redistributing from Github, FWIW. Downloading an unsigned binary from a website with certificate errors is one thing for personal use, and quite another to hand out to tens of thousands of people.
So it's this from now on?Should I be distributing a newer version in the Starter Pack? My understanding was that the releases were stable, and the builds might not be.
I thought most people were using builds from the build server (and you as well). I usually wait for positive feedback for new builds and then forget to make a Github release.
I'd be a lot happier redistributing from Github, FWIW. Downloading an unsigned binary from a website with certificate errors is one thing for personal use, and quite another to hand out to tens of thousands of people.
Ok, I've published a release.
I seem to have found a bug and narrowed it down to TwbT and the Phoebus texture pack in the R17 starter pack.That's TwbT 5.47 with Doren's Phoebus overrides, FYI. r16 was 5.45 and minimal overrides.
Normal:
https://drive.google.com/open?id=0B3Vnl7plZSmeZHFaZDFFR3JBU1E
Then when you move the screen around this happens:
https://drive.google.com/open?id=0B3Vnl7plZSmeZUI2YkV2dklaS2c
https://drive.google.com/open?id=0B3Vnl7plZSmeZDFqSzdiR1N3NUU
I have no idea on how to fix this. Also I did not have this problem with the R16 starter pack.
Just passing on a bug report - some overrides lead to images persisting even when the map is moved.I seem to have found a bug and narrowed it down to TwbT and the Phoebus texture pack in the R17 starter pack.That's TwbT 5.47 with Doren's Phoebus overrides, FYI. r16 was 5.45 and minimal overrides.
Normal:
https://drive.google.com/open?id=0B3Vnl7plZSmeZHFaZDFFR3JBU1E
Then when you move the screen around this happens:
https://drive.google.com/open?id=0B3Vnl7plZSmeZUI2YkV2dklaS2c
https://drive.google.com/open?id=0B3Vnl7plZSmeZDFqSzdiR1N3NUU
I have no idea on how to fix this. Also I did not have this problem with the R16 starter pack.
There's a recent discussion of this somewhere - it's because overrides specify different images for several tile types that the game normally displays with the same ASCII character. Therefore when moving, character doesn't change and I (and the original graphics code) don't update such tiles. It wasn't a problem before but probably now I'll add an option to always update all tiles that you can activate for affected tilesets (but we'll need to see how this affects gFPS).
There's a recent discussion of this somewhere - it's because overrides specify different images for several tile types that the game normally displays with the same ASCII character. Therefore when moving, character doesn't change and I (and the original graphics code) don't update such tiles. It wasn't a problem before but probably now I'll add an option to always update all tiles that you can activate for affected tilesets (but we'll need to see how this affects gFPS).
Makes sense. FWIW, I'll always leave that option on, because correct behaviour is much more important than the performance issue. But you can include this option in init script based on tileset, right (in launcher)?
DFHack r4 has been tagged and the binaries should be uploaded soon, so maybe a build for that?
Wasn't the needed changes to renderer merged into dfhack? Can't we merge in the mifki plugin fixes so that it would not need special releases for plugins?
I'm not sure what "changes to renderer" you mean. One way for TwbT to play nicely with other plugins is to allow it to hook into a few DFHack functions, which I've been meaning to do but I'm not sure what sort of impact on performance it would have.I mean I thought this was already added: https://github.com/mifki/df-twbt/blob/master/renderer_twbt.h#L63-L65
Doesn't TwbT do that already?
If you're referring to my changes, those are only internal changes to how TwbT modifies the behavior of other plugins - they should keep using the map tiles in the map.
New build is available for 0.40.24-r4. Needs testing on OS X due to some issues with compilers.
Also, I haven't updated the bundled plugins yet to include the latest changes form dfhack repo, if any.
New build is available for 0.40.24-r4. Needs testing on OS X due to some issues with compilers.
Also, I haven't updated the bundled plugins yet to include the latest changes form dfhack repo, if any.
Quick bump - any progress on updating the bundled plugins? Either way, it would be great to release on Github.
DFhack is out now. Does this need an update too?
DFhack is out now. Does this need an update too?
Yes, but it'll probably be a while.
Uh oh. Will do as soon as I get home tomorrow night, if everything goes well with dfhack compilation, etc.
Uh oh. Will do as soon as I get home tomorrow night, if everything goes well with dfhack compilation, etc.
Don't bend over backwards for some assheads on the internet, they'll quickly start expecting that as the norm.
(you're precious to us. thanks)
Uh oh. Will do as soon as I get home tomorrow night, if everything goes well with dfhack compilation, etc.
Don't bend over backwards for some assheads on the internet, they'll quickly start expecting that as the norm.
(you're precious to us. thanks)
Well, with DF updates as they are, you only have to come by once a year to release a new version. ;)Uh oh. Will do as soon as I get home tomorrow night, if everything goes well with dfhack compilation, etc.
Don't bend over backwards for some assheads on the internet, they'll quickly start expecting that as the norm.
(you're precious to us. thanks)
Well, you're right, but I'm known for abandoning projects once they're not as interesting for me as in the beginning, which isn't a good thing in general.
[thefunk@archenstein .df]$ ./dfhack
Gtk-Message: Failed to load module "canberra-gtk-module"
Loading bindings from data/init/interface.txt
[thefunk@archenstein .df]$ ./dfhack
Gtk-Message: Failed to load module "canberra-gtk-module"
Loading bindings from data/init/interface.txt
New window size: 1920x1080
Font size: 32x48
Resizing grid to 80x25
Resizing font to 24x36
Resetting textures
TWBT: version 5.53
TWBT: set PRINT_MODE to TWBT or TWBT_LEGACY in data/init/init.txt to activate the plugin
DFHack is ready. Have a nice day!
DFHack version 0.42.03-alpha1 (release)
Type in '?' or 'help' for general help, 'ls' to see all commands.
Plugin twbt has failed to shutdown!
[DFHack]#
Same silent crash as twbt/twbt_legacy.
Huh, I'm running it out of the .df42.3 and .df42.4 folders for dfhack/newest versionWait, does the latest build work with 42.04? It tells me it cannot load because it was made for dfhack 42.03
Any update for 42.04? :<
Here are my personal windows builds of TWBT and 0.42.04-alpha2. No guarantees of proper functioning or anything like that but it works for you then great. The full dfhack build includes some extra scripts related to my adventure mode regional teleport plugin.Spoiler (click to show/hide)
#define A_RENDER_MAP 0x08B93710
#define A_RENDER_UPDOWN 0x088FA210
#define NO_DISPLAY_PATCH
static patchdef p_dwarfmode_render = { 0x008404622, 5 };
static patchdef p_advmode_render[] = {
{ 0x083AC6DD, 5+7+5 }, { 0x083AC791, 5+7+5 }, { 0x083ACDAC, 5+7+5 }, { 0x083AD1DA, 5+7+5 }
};
static patchdef p_render_lower_levels = {
0x08E89BC0, 13, true, { 0x36,0x8b,0x84,0x24,0x14,0x00,0x00,0x00, 0x3e,0xc6,0x00,0x00, 0xC3 }
};
42.04 linux offsets below, seem to be working.Code: [Select]-snip-
Version 5.55 released with support for 0.42.04. Thanks to all contributors.Thank you.
#define A_RENDER_MAP 0x08B9B720
#define A_RENDER_UPDOWN 0x08901F00
#define NO_DISPLAY_PATCH
static patchdef p_dwarfmode_render = { 0x00840B502, 5 };
static patchdef p_advmode_render[] = {
{ 0x083B306D, 5+7+5 }, { 0x083B3121, 5+7+5 }, { 0x083B373C, 5+7+5 }, { 0x083B3B6A, 5+7+5 }
};
static patchdef p_render_lower_levels = {
0x08E92A20, 13, true, { 0x36,0x8b,0x84,0x24,0x14,0x00,0x00,0x00, 0x3e,0xc6,0x00,0x00, 0xC3 }
};
For people finding the required offsets: it would be amazingly useful if you could get the general form into the df-structures project. (for example, TwbT could be merged into the standard DFHack library).What exactly do you mean? These are general code replacement techniques and not pointer or function detours. Is that supported in native DFHack mods? If so, which ones?
I read that mifki struck some sort of agreement to not try to merge TwbT into dfhack because of how this mod works.
as i understand it, to get use of the dfhack automatic address scanning, one would need to define dfhack data structures for the map rendering functions and classes.Dfhack does not have "automatic address scanning". It has some tools/scripts/best practices/experienced hackers to quicker find addresses when new version appears but there is no hard requirement for automatic scripts (though it would help and even more if e.g. the original person that found that address moves on from dfhacking).
as i understand it, to get use of the dfhack automatic address scanning, one would need to define dfhack data structures for the map rendering functions and classes.Dfhack does not have "automatic address scanning". It has some tools/scripts/best practices/experienced hackers to quicker find addresses when new version appears but there is no hard requirement for automatic scripts (though it would help and even more if e.g. the original person that found that address moves on from dfhacking).
There is zero df functions (except for virtual ones) in dfhack because it's hard to keep track of their calling convention when full program optimization is on (which is on for df) and internal functions can be called with basically random calling convention. I think ragundo is trying to add one that would allow to export very detailed world maps like in legends mode but better. AFAIK he's done windows and linux already.
I personally am sceptical about adding functions into dfhack but only because i tried it once and was too lazy/unexperienced to have anything productive.
that's what i mean, the scripts somewhat automate finding the offsets.
and if the functions that twbt patches had data structure definitions, the scripts would find the offsets for new df versions easier.
https://dfhack.readthedocs.org/en/stable/library/xml/SYNTAX.htmlas i understand it, to get use of the dfhack automatic address scanning, one would need to define dfhack data structures for the map rendering functions and classes.Dfhack does not have "automatic address scanning". It has some tools/scripts/best practices/experienced hackers to quicker find addresses when new version appears but there is no hard requirement for automatic scripts (though it would help and even more if e.g. the original person that found that address moves on from dfhacking).
There is zero df functions (except for virtual ones) in dfhack because it's hard to keep track of their calling convention when full program optimization is on (which is on for df) and internal functions can be called with basically random calling convention. I think ragundo is trying to add one that would allow to export very detailed world maps like in legends mode but better. AFAIK he's done windows and linux already.
I personally am sceptical about adding functions into dfhack but only because i tried it once and was too lazy/unexperienced to have anything productive.
That's interesting. What does your script use?
That's interesting. What does your script use?
radare2 with the r2pipe Python API. It basically does all the steps described in the PATCHES.md file.
the patches compiled and seemed to not crash the game, although I only had time to look around and embark site and verify that zoom is working as intended. I need to learn how to install tilesets...
Some documentation about how to get TWBT installed properly would be nice to have. I can read the source and look at existing packs but its a massive pain, and I'm never sure I've done it the right way. As it is I just stuck a symlink in a develop branch dfhack's plugins dir, added it to plugins/CMakeLists.custom.txt, ran make install, set the rendering mode to TWBT, embarked a new fortress for a few minutes and called it a day.
Also is it normal that Hopper crashes a lot?
radare2 with the r2pipe Python API. It basically does all the steps described in the PATCHES.md file.Thx for your contribution!
the patches compiled and seemed to not crash the game, although I only had time to look around and embark site and verify that zoom is working as intended. I need to learn how to install tilesets...
I've added/merged all offsets for .05, but didn't make a build because I'm not sure if the develop dfhack branch is ok to use.Loads ok so far.
Quote...Thx for your contribution!
You can find some preconfigured 42.05 sets here (https://github.com/Lazy-Newb-Pack/DFgraphics), and optionally use PyLNP (https://bitbucket.org/Pidgeot/python-lnp/downloads) for installation.
edit:I've added/merged all offsets for .05, but didn't make a build because I'm not sure if the develop dfhack branch is ok to use.Loads ok so far.
ETA on a build that supports DFHack 42.05-alpha1 ?
Done, thanks to sv-esk for offsets.
Done, thanks to sv-esk for offsets.
Does TWBT need to be recompiled against the latest dfhack? I'm assuming it does.
done
done
[thefunk@archenstein .df]$ ./dfhack
Gtk-Message: Failed to load module "canberra-gtk-module"
Loading bindings from data/init/interface.txt
[thefunk@archenstein .df]$
Without the df window actually showing up or anything when I set print mode to twbt or twbt_legacy.dfhack: hooking successful
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
The program 'Dwarf_Fortress' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
(Details: serial 32 error_code 2 request_code 154 minor_code 3)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Can you try just dfhack+twbt, without other plugins (mousequery is ok)? You can temporarily move other .plug.dll files from hack/plugins to somewhere else and then put them back.
Can you try just dfhack+twbt, without other plugins (mousequery is ok)? You can temporarily move other .plug.dll files from hack/plugins to somewhere else and then put them back.i currently use the LNP 0.42.06-r02 with TWBT+dfhack+"mouse controls" (is that called mousequery?)
dm = require('gui.dwarfmode')
size_x = dm.getPanelLayout().map.width
size_y = dm.getPanelLayout().map.height
pos["x"] = df.global.window_x + math.floor(dm.getPanelLayout().map.width / 2)
pos["y"] = df.global.window_y + math.floor(dm.getPanelLayout().map.height / 2)
pos["z"] = df.global.window_z + df.global.world.map.region_z
Hi mifki, I have a question about some of the sorcery behind rendering the screen. When I useCode: [Select]dm = require('gui.dwarfmode')
size_x = dm.getPanelLayout().map.width
size_y = dm.getPanelLayout().map.height
in most modes, I get the size of map panel in tiles. But in TWBT mode the width seems to be much wider than the actual display, but otherwise acting normally (i.e., the reported width is higher when the minimap is suppressed). My wild guess is that the reported width is the panel's width in text tiles.
...
Any plans to release builds for the DFHack beta?
Any plans to release builds for the DFHack beta?
I'll test for a bit more tonight (still hasn't reproduced a single crash!), and will make a build then.
he didn't mention reporting back :PAny plans to release builds for the DFHack beta?
I'll test for a bit more tonight (still hasn't reproduced a single crash!), and will make a build then.
Got any problems? Because tonight is over already ;)
Exactly. New build is on http://build.mifki.com
so you're going to put it into the next LNP rc? :)Exactly. New build is on http://build.mifki.com
Could you cross-post to GitHub?
so you're going to put it into the next LNP rc? :)
Dirst cancels work: doing SnoopyDance.so you're going to put it into the next LNP rc? :)
Yep, new starter pack when I get home tonight.
I must sound like a broken record, but also looking forward to a build for stable DFHack.
It would be really nice if TwbT could be merged into the main DFHack repo, too - that would share memory research, ease bug reporting, and speed updates. I know there were some issues before, but I think at least some have been fixed.
On startup? That's something new.I think I fixed it. I had some legacy-files from older dfhack versions flying around that were moved to different sub-folders in the new version, thats why I didnt notice before.
Tried on two PCs today - does not crash! I'll keep trying...
What tileset/overrides are you using? Also, when disabling TWBT, are you setting print_mode to 2D or STANDARD - better set to STANDARD because 2D is too different. Maybe other plugins you're using interfering?
Thank you for the information, although it doesn't help much since I can't reproduce the problem on any of my computers. Maybe it's something video card-related. I will check my OpenGL code again to see if there's anything suspicious that might upset some video drivers. Can't think of other reason why it doesn't crash for me with the same save it would crash for sure for some other people.Crashes on both ATI Radeon HD 2400 and NVidia GeForce 660 (with latest available drivers). It's also not OS-related, i tried on WinXP and Win10. And it's not related with the workshop drawing arifacts, it still crashes with twbt redraw_all 1.
TWBT doesn't include any fonts itself, are you talking about starter packs (then you need to post in appropriate threads)? Or I didn't understand what you mean.
I think you might be looking for the DFGraphics Repository: http://www.bay12forums.com/smf/index.php?topic=155882.0
TWBT doesn't include any fonts itself, are you talking about starter packs (then you need to post in appropriate threads)? Or I didn't understand what you mean.I think you might be looking for the DFGraphics Repository: http://www.bay12forums.com/smf/index.php?topic=155882.0
TWBT's repository demonstratably includes fonts (https://github.com/mifki/df-twbt/tree/master/dist). I'm not "looking for the DFGraphics repository". If it's taboo to include new fonts in this repository, might I suggest removing the ones that are there? I'm confused as to why this is an inappropriate place to submit, if this is upstream and upstream includes fonts.
At any rate, apologies for the noise.
Those two fonts are included for historical reasons - when TWBT was new, people downloaded it and in case they didn't have any text tileset, I included one. I'm saying "one" while there are two files because at first TWBT required square text font, and I also included non-square one later when TWBT started to support non-square text tiles.
In short, these fonts are included as an example to make a self-sufficient distribution package, and I never meant to provide a "selection of fonts".
If you want your fonts to be included, that's not a problem, of course. I just doubt anyone using fonts from my package at all.
I'll see about making a DFGraphics pull sometime.
Is there a guide to find render_map address?
Is there a guide to find render_map address?
As well as to find all other addresses https://github.com/mifki/df-twbt/blob/master/PATCHES.md
Is there a guide to find render_map address?
As well as to find all other addresses https://github.com/mifki/df-twbt/blob/master/PATCHES.md
Thanks. Was lookin in the .cpp file (it contains half the instructions).
If anyone is interested the win 43.02 rendermap offset is:0xB1F140
Mostly playing around.Is there a guide to find render_map address?
As well as to find all other addresses https://github.com/mifki/df-twbt/blob/master/PATCHES.md
Thanks. Was lookin in the .cpp file (it contains half the instructions).
If anyone is interested the win 43.02 rendermap offset is:0xB1F140
What are you doing, if not a secret?
A youtuber that I watch seems to be having trouble with what I think might be a problem with tile overrides.
https://www.youtube.com/watch?v=fDbuQ8CnGm0 (https://www.youtube.com/watch?v=fDbuQ8CnGm0)
I thought I'd post it here because that is the conclusion that I jumped to. He is a great youtuber and is one of the ones that got me through the learning curve so I wanna try to help him as best I can.
A youtuber that I watch seems to be having trouble with what I think might be a problem with tile overrides.
https://www.youtube.com/watch?v=fDbuQ8CnGm0 (https://www.youtube.com/watch?v=fDbuQ8CnGm0)
I thought I'd post it here because that is the conclusion that I jumped to. He is a great youtuber and is one of the ones that got me through the learning curve so I wanna try to help him as best I can.
Lol. Thanks Rogue Yun. (I'm DasTactic on YouTube) I was just coming in here to post some more info...
Since recording I've hunted it down to the tileset overrides and that the game doesn't redraw the screen for tiles with the same basic ID. I'm using SpaceFox but this actually applied for all tilesets with overrides. If you have an ID that has been overridden for one tile (for example the floor of a workshop) and then move the screen (through z-layers or the X and Y) and there is supposed to be a basic tile of the same ID (eg. rough stone floor) then the override will still be active and place the overriden workshop floor tile where the rough stone floor tile should be.
Also it seems to work either way for walls and bridges yet I couldn't find a wall override in override.txt, only a bridge override.
I tried the following:
Commenting out the overrides, and that works but then you don't get the nicer graphics.
Resizing the tileset to be the same dimension as the replacement tileset but that didn't fix it.
Changing the target tileset referenced but the issue remains.
In the end I just changed the floor of the workshops to a less contrasting tile override and while it looks OK it doesn't solve the issue.
Thanks
Das
twbt redraw_all 0|1
that switches full screen redraws, does it help?Since recording I've hunted it down to the tileset overrides and that the game doesn't redraw the screen for tiles with the same basic ID.
Since recording I've hunted it down to the tileset overrides and that the game doesn't redraw the screen for tiles with the same basic ID.
You can use the command twbt redraw_all 1 (https://github.com/mifki/df-twbt#text-and-map-tilesets) to force tiles to be redrawn every frame, fixing this issue at some FPS cost.
Any news on this? I would really like to address this at some point to stop TwbT from breaking so many other tools, and to avoid the need for the separate automaterial/mousequery/resume plugins. I may be able to help with this in a week or two, if you need help, but there's an example for at least one of the relevant hooks in plugins/devel/color-dfhack-text.cpp.Hi, it's been a while, but I hope this hasn't been forgotten.Hi mifki, I have a question about some of the sorcery behind rendering the screen. When I useCode: [Select]dm = require('gui.dwarfmode')
size_x = dm.getPanelLayout().map.width
size_y = dm.getPanelLayout().map.height
in most modes, I get the size of map panel in tiles. But in TWBT mode the width seems to be much wider than the actual display, but otherwise acting normally (i.e., the reported width is higher when the minimap is suppressed). My wild guess is that the reported width is the panel's width in text tiles.
...
DFHack offers a way to hook into Gui::getDwarfmodeViewDims(), the C++ equivalent of getPanelLayout(). The problem here is twofold:
a) The Lua version calculates stuff itself, rather than calling the C++ function, which means it can't be hooked into.
b) TwbT doesn't actually hook into that function in the first place (it distributes a couple modified plugins instead)
I suspect that TwbT hooking in and making the Lua function delegate to the C++ function would solve the issue.
mifki: I'm kind of busy this week (hoping to get r1 done!), but feel free to stop by #dfhack or something and I can try to help with the hooks. As far as I remember, you'll only need to add a few functions to twbt.cpp, and that'll fix some issues with Lua scripts and eliminate the need to distribute automaterial/mousequery/resume. (There's an example in devel/color-dfhack-text.cpp if you want to play around with it - not sure if it provides an example of the getDwarfmodeViewDims() hook, but it should at least be similar.)
It appears to me that TWBT draws a map assuming the map tiles are sized like text tiles, which might be the root cause of the announcement-centering issue and the getPanelLayout() issue. Drawing only the required tiles (rounding up) might help a smidge with FPS as well. lethosor's idea might also eliminate the need for modified plugins, reducing your workload each release.
There's a commandCode: [Select]twbt redraw_all 0|1
that switches full screen redraws, does it help?
PS. I was watching one of let's play videos just the other day (which I don't usually do) and somehow it was yours haha.
i haven't had the time (and muse) to look into it again,
but when i set multilevel 0, it seemed to get rid of the "graphic artifacts" with fake workshop tiles and walls when moving the screen.
i'll test it some more and maybe that solves many crashes aswell.
my next suspect or causing crashes is the mousequery (aka "mouse controls") DFHack-Plugin, but without mouse i wouldn't play the game.
twbt redraw_all 0|1
thanks, i'll add it.Code: [Select]twbt redraw_all 0|1
should fix artefacts when moving screen
I don't really have detailed information, but I can provide some anecdotal information regarding crashes.
Most of my DF crashes (DF 42.06, DFHack 42.06r1, TWBT 5.61) seem to be related to multilevel rendering as well. In any case, I've yet to crash at multilevel 0, and they seem much reduced at multilevel 1. However, I can't seem to figure out how to get DF to automatically set multilevel 1 on startup, fiddling with DFHack init settings doesn't seem to have any effect. Most common crashes occurred during rapid repeated z-level changes, with second place going to accidental double-tapping of ESC (bringing up and canceling the options menu immediately).
Mind, my current hard drive is on the flaky side and really needs replacing, so I can't be sure they're not due to HD errors somehow.
If you installed DFHack and TWBT yourself, then multilevel view should be off by default. Just add a new line somewhere in DFHack.init that says "multilevel 1" (without the quotes).Mm. See, that's what I thought too, but it doesn't seem to be having any effect. Everything's self-installed, so... wait. What's this "onLoad.init" file doing here? Welp. Found the problem. Turns out GemSet includes an onLoad.init in the raw folder that sets multilevel settings.
Just wanted to let you know that dfhack has made a release for DF v.43.03
https://github.com/DFHack/dfhack/releases/tag/0.43.03-alpha1
Hope TWBT gets updated too. :)
mifki, is it okay to bundle Text Will Be Text with Lazy Newb Packs?
Don't mean to intrude, but any estimate when new version of twbt will come out? itching to dive in, but it is not the same without twbt.Just wanted to let you know that dfhack has made a release for DF v.43.03
https://github.com/DFHack/dfhack/releases/tag/0.43.03-alpha1
Hope TWBT gets updated too. :)
Ha! Neither me nor anyone else have made patches for 0.43 yet, it seems. Will do that on weekend.
Build is ready for 0.43.03-alpha1Thank you :)
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,
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.
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.
1920x1080
I really love TWBT but don't like having to wait for dfhack to update in order to use it. I don't use any of the other dfhack features. Is it possible to run TWBT without dfhack? Or run it in some way so that I don't need to wait for dfhack to update to the latest version?
Thanks very much for your help :).
No.
Although you could technically build DFHack and TwbT from source, if DFHack is too buggy to release, it's likely that TwbT will be unstable too.
Is there any way to fix DFHack menus/sidebars/dialogs showing the map display area as black when they are open?Besides disabling TwbT, not yet. I'm working on a way to let TwbT avoid breaking those, but it's not done yet. I might be able to get to it today or tomorrow, though.
A question/request: Would it be possible to split TWBT multilevel and TWBT overrides into two plugins?Both plugins would need to hook into the same rendering steps. I think that setting multilevel 0 effectively turns off that portion of the code. One could also disable overrides by not having an overrides file, though I don't know if that "disables" the feature in the sense of avoiding crashes associated with the override engine.
Yeah, I was thinking of enabling multilevel, but disabling the override tiles.
I was looking at installing more tilesets for MasterworkDF and I'm trying to come up with a good way to swap tilesets using TWBT, but the override tiles make it difficult... I have some unique ones per tileset, some that are always on, and other that should probably be disabled if you play with ASCII or an ASCII-like tileset.
I was really hoping to get GemSet to work, but its rather difficult. Tilesets, overrides, TWBT font tileset, creature sprites, different size (32x)... but that is another topic.
FWIW PyLNP handles separate overrides for each graphics pack, just as we handle different tilesets. It's not that hard to set up...Yes, I can create a override file for each set, using an empty one for each tileset that does not use overrides. I'll actually do that today, I'm working on installing Gemset, would have to do that anyway for it.
QuoteFWIW PyLNP handles separate overrides for each graphics pack, just as we handle different tilesets. It's not that hard to set up...Yes, I can create a override file for each set, using an empty one for each tileset that does not use overrides. I'll actually do that today, I'm working on installing Gemset, would have to do that anyway for it.
I just found it strange that you can't disable (unload?) the plugin or part of the plugin. The other dfhack plugins can be turned on/off on command, with TWBT it seems you have to close DF, remove the file, replace the automaterial/resume/mousquery plugins with the Non-TWBT versions, and restart DF.
EDIT: Slightly related to that: Is there are maximum number of override tilesets you can use? Does a high-number affect performance in a noticeable way? For example both the MasterworkDF mod and GemSet have 8 sets.
What is a use case for unloading TWBT? I could never understand that.Testing, looking for sources of crashes. I got a lot of reports from players about crashes that stopped when they started playing without TWBT. It would also help comparing the before/after look of overrides.
You don't need to replace automaterial/resume/mousquery plugins - TWBT versions work just fine without it.That's good to know, thanks :)
There's maximum number of tiles that would fit in one texture of maximum size supported by your GPU. For each tileset all its tiles are loaded, having tilesets with half of tiles empty/unused is bad. However, this limit is probably reachable on old GPUs only. As for the performance, a large number of overrides for a single tile number may affect performance.Ok. Guessed as much about the first part, the last part about "large number of overrides for a single tile number" is good to know, although probably a rare case.
QuoteWhat is a use case for unloading TWBT? I could never understand that.Testing, looking for sources of crashes. I got a lot of reports from players about crashes that stopped when they started playing without TWBT. It would also help comparing the before/after look of overrides.
I just found it strange that you can't disable (unload?) the plugin or part of the plugin.
@Mifki - I have multilevel as an optional setting in my pack, due to crash reports. This means I have to disable it in one init file, and conditionally enable it later. "enable multilevel" with it off by default would be a cleaner interface, and remove potential ordering problems.
I've opened an issue on Github (https://github.com/mifki/df-twbt/issues/48), but given that most of the modders are on the forums I though it would be worth cross-posting.
The DFgraphics group has a two-part feature request:This will allow modders to provide substantial extensions for various graphics packs, to give a native look to their new content. I'm working on some fairly major changes to PyLNP to support the other end of this, so some indication of whether you'll be able to help out (and a timeline if so) would be awesome ;D
- Support multiple overrides files, eg anything matching "overrides*.txt"
- Support item subtypes by name and generally discourage use of numbers as IDs
Maybe crashes are from people running low on RAM while using TwbT. (I'd guess that rendering more Z-levels at once requires more RAM.) Maybe 64-bit Dwarf Fortress will reduce the issues with users crashing.
Maybe crashes are from people running low on RAM while using TwbT.Considering my crash was barely 20 minutes from a fresh startup, I doubt it's a RAM issue. My game uses about 815MB and only very slowly increases, if at all. It's not LAA, but that'd really only be a problem during world generation. I've switched it anyway, never hurts.
Does the game crash randomly when you interact directly with it, or regardless of whether or not you're interacting with it?when i used 43.03-r04 LNP, it crashed randomly, but that meant also sometimes when i pressed keys too fast in sequence like b-w-l or b-C-w. deactivating multilevel only reduced the frequency of the crashes, but didn't get rid of it.
I ask because of this (https://www.reddit.com/r/dwarffortress/comments/56zi5f/psa_be_careful_with_multi_level_view_if_you_are/).Interesting.. I'll check if I have any pending designations around holes. Maybe that was indeed the cause of the random crash when I zoomed to a different level.
Oh, and I just remembered I added "twbt redraw_all 1" due to graphical issues. I think the crashing became more frequent after that, but I could be mistaken.Turns out that's exactly what's causing the silent crashes.
would it be possible to only force redraw for when the viewport is moved?Does the issue it fixes only occur when moving the viewport, or when any tile changes?
so it wouldn't have to redraw each and every frame, but only the moment it has to draw new tiles anyway.
DAOWAce, why are you still using 0.42.06? My new releases usually don't include plugins for older DF versions.
It only happens when moving the viewport IIRC.i see the same problem with multilevel=0 in Phoebus.
Das did a short video explaining the issue: https://www.youtube.com/watch?v=fDbuQ8CnGm0
Ok, I have found what's causing crashes.
This is fantastic news! Thanks for your perseverance.+1
Thanks for the update! To install this, I just drag all the files from the /twbt-5.66-osx/0.43.03-r1/ folder into the /df_osx/hack/plugins/ folder, right?
Do I need to also put /twbt-5.66-osx/realcolors.lua into the /df_osx/hack/lua/ folder?
Thanks for the help. I found some instruction for realcolors (http://www.bay12forums.com/smf/index.php?topic=138754.msg6235164;topicseen#msg6235164).
It looks installing the realcolors lua doesn't change anything in existing packs unless they are specifically modified to make use of it.
To make an item use its real color, it just needs to have its foreground color in its object file set to "100", right? And then all the background colors get displayed as normal.
Thanks for the help. I found some instruction for realcolors (http://www.bay12forums.com/smf/index.php?topic=138754.msg6235164;topicseen#msg6235164).so how do i use it then? and where do i get it?
It looks installing the realcolors lua doesn't change anything in existing packs unless they are specifically modified to make use of it.
To make an item use its real color, it just needs to have its foreground color in its object file set to "100", right? And then all the background colors get displayed as normal.
I've made some more crash fixes (hopefully) that need testing, both fortress mode and adventure mode are affected.The HTTPS-Auth is outdated. i cant open the links.
Build for 0.42.06 https://build.mifki.com/build/808
Build for 0.43.03 https://build.mifki.com/build/809
Thank you!
How else to test than to allow a lot of people to use them?Thank you!
Please don't distribute these two builds until they've been tested for some time.
DAOWAce, if you could update and play for some time with redraw_all and multilevel.
How else to test than to allow a lot of people to use them?Thank you!
Please don't distribute these two builds until they've been tested for some time.
DAOWAce, if you could update and play for some time with redraw_all and multilevel.
DAOWAce, if you could update and play for some time with redraw_all and multilevel.Oh wow, didn't expect a build for v42. Was just about to play again, so I'll definitely test it.
well, today i had the strangest bug: four downward stairs just vanished without any reason - or by some strange means smoothing stone removes stairs...If the stairs themselves are gone, you removed them. TWBT only changes graphics.
strange. i can't imagine a lazy stone detailer running for those 4 stairs in the corners while giving a f*** about the work otherwise.well, today i had the strangest bug: four downward stairs just vanished without any reason - or by some strange means smoothing stone removes stairs...If the stairs themselves are gone, you removed them. TWBT only changes graphics.
Carved stairs are easy to remove. Build stairs are "harder" to remove. They are protected from building over and stuff. Stuff like this confused me before you develop an intuition about how tiles vs constructions vs buildings vs zones vs room vs ... work (though digging through internals help).strange. i can't imagine a lazy stone detailer running for those 4 stairs in the corners while giving a f*** about the work otherwise.well, today i had the strangest bug: four downward stairs just vanished without any reason - or by some strange means smoothing stone removes stairs...If the stairs themselves are gone, you removed them. TWBT only changes graphics.
Is it even possible to remove carved stairs with [d-s] ?
Another suggestion: Make TWBT load 4 different color schemes. Spring, Summer, Autumn, Winter. Automatically change those upon the change of seasons.
Yeah, changing the color scheme on the fly isn't hard. See gui/settings-manager.So it could be easily automated with a script?
Another suggestion: Make TWBT load 4 different color schemes. Spring, Summer, Autumn, Winter. Automatically change those upon the change of seasons.
So it could be easily automated with a script?
Build for 0.42.06 https://build.mifki.com/build/808
Build for 0.43.03 https://build.mifki.com/build/809
I think most players forget that SoundSense can not only play music and sounds, but it can also trigger scripts by gamelog events. It already changes the music based on the season, so activating a script with each season wouldn't be an issue.No, Soundsense switches to a different season's music when it reads a season change announcement from gamelog.txt. It doesn't trigger anything in-game. Soundsense is an external program and doesn't communicate with DF/DFHack, unless something has changed recently that I'm not aware of.
No, Soundsense switches to a different season's music when it reads a season change announcement from gamelog.txt. It doesn't trigger anything in-game.
Soundsense is an external program and doesn't communicate with DF/DFHack, unless something has changed recently that I'm not aware of.
New release, r 39:
http://df.zweistein.cz/soundsense/soundSense_38_174.zip
http://code.google.com/p/df-soundsense/downloads/list
* Fixed small issues with dhhack script
* Added ability to call external tools, see executors/executor.xml file in soundsense directory for details. So far, it just starts dfhack script when game is loaded.
...I'd love to hear your suggestions on other potential uses! The only ones I've come up with so far are:
* Pausing and/or centering the screen for custom messages. (Limited usefulness as DF already allows this for announcements (http://dwarffortresswiki.org/index.php/DF2012:Announcement) through announcements.txt in the init folder. It might be useful for certain other gamelog messages, though.)
* Calling heritage.lua on dwarf child birth announcements for the Dwarven Heritage Project (http://www.bay12forums.com/smf/index.php?topic=112381.0)
* Calling a partycancel.lua script to automatically cancel parties as soon as they are announced. (See this post (http://www.bay12forums.com/smf/index.php?topic=122616.msg4033564#msg4033564) for details.)
Why is it hard to believe that a program can call a separate program or communicate with DFHack? This is not a new feature. Actually, it dates from February of 2013.Okay, I wasn't aware of that. It's not hard to believe that it's possible, but the documentation I remember about the soundsense-season script said that you needed to set up DFHack to run it on startup, without mentioning that Soundsense could do it. I'll check and see if that still needs to be fixed.
Colour palette is fully accessible in Lua. So while being a great idea, this has nothing to do with TWBT.
DFHack has "dfhack-run", which allows you to trigger anything from an external app. Soundsense's executor system does it's thing using this facility, so you can actually use Soundsense to start other external tools as well.Perfect! If you do manage to alter it, could you please send it to me? I will make the color schemes for it asap. :)
Back when I still used Soundsense regularly I (ab)used this in some creative ways :)Colour palette is fully accessible in Lua. So while being a great idea, this has nothing to do with TWBT.
I actually have a script (included in Rubble, see "Libs/Colors/Swap Palette") that loads save-specific colors.txt files from the raw (or save) directory when a world is loaded. I made this script to allow mods to use a custom color pallet without forcing the user to install one globally. It wouldn't be hard to modify this to perform seasonal switches without involving Soundsense at all.
[OVERRIDE:255:I:TOOL:TOOL:25:_MDF_overrides_1:248]
, but I cant make an override for the building. @Mifki - I've seen some good reviews for the experimental 5.70 build. Any plans for when that will go stable and be released on Github, or are there known problems?
[WINDOWEDX:40]
[WINDOWEDY:30]
[FONT:curses_vector_16x24.png]
[RESIZABLE:YES]
[FULLSCREENX:0]
[FULLSCREENY:0]
[FULLFONT:curses_vector_16x24.png]
[BLACK_SPACE:YES]
[GRAPHICS:NO]
[GRAPHICS_WINDOWEDX:40]
[GRAPHICS_WINDOWEDY:30]
[GRAPHICS_FONT:curses_square_16x16.png]
[GRAPHICS_FULLSCREENX:0]
[GRAPHICS_FULLSCREENY:0]
[GRAPHICS_FULLFONT:curses_square_16x16.png]
[GRAPHICS_BLACK_SPACE:YES]
[PRINT_MODE:TWBT]
Mode examples:
PRINT_MODE:2D
PRINT_MODE:TEXT
PRINT_MODE:FRAME_BUFFER
PRINT_MODE:PARTIAL:0
[SINGLE_BUFFER:NO]
[TRUETYPE:24]
As far as I can tell, this should be using the 16x24 font for the text (on the right hand side of the screen) and the 16x16 font for the map (the dwarfs and all that), correct? However, it's using the 16x24 font for both. What am I doing wrong? I'm using the latest LNP (returning player after a very long time not playing).
[GRAPHICS:NO]
... Thanks.Code: [Select][GRAPHICS:NO]
Change this to "YES".
Someone said that Text Will Be Text works with DF v0.43.05. Does the version of TWBT for DF v0.43.03 also work with DF v0.43.05? I was under the impression that it had to be updated for every release.
Thanks for clarifying that. Wasn't expecting to hear that answer from you, though.PE knows all about how all the bits and pieces of the DF ecosystem fit together, at least the ones that run on Windows.
I hope no foreign carnivores and destruents enter this ecosystem anytime soon :DThanks for clarifying that. Wasn't expecting to hear that answer from you, though.PE knows all about how all the bits and pieces of the DF ecosystem fit together, at least the ones that run on Windows.
I used to play with phoebus and today, first time in my dorf life, i tried to use different tileset. I tried spacefox, which uses sharp pixelated graphics and i realised that in twbt mode it becomes blurry antialiased mess. Everything is fine in 2D and twbt_legacy mode, so i came here to ask what exactly i am losing playing in legacy mode, or what should i do to prevent this unwanted antialiasing. Check spoiler to see the comparison. I guess normal TWBT mode rendering image in wrong resolution or smth.
Yeah, Fricy added "TWBT tilesize 18px" to Spacefox a year ago. I removed it 2 months ago from the repo, but that was on the version for DF v0.43.05.Ah, wonderful. Thank you.
To remove the hardcoded TWBT tilesize, delete the /LNP/graphics/Spacefox/raw/onLoad.init file from your Lazy Newb Pack. Then open the LNP launcher and switch graphics packs and then switch it back.
Is there any way to fix the adventure mode camp construction screen being black when TWBT is enabled?
It works fine when TWBT is disabled, however I cannot stand vanilla text.
Am I out of luck here?
Just install and cannot load TWBT :(
alpha1 let me load TWBT.
That's because the build of TwbT you're using only works with alpha1. Mifki (or someone else) usually puts up a new build fairly quickly after a release, though.
Soon I'll start working on updating TWBT for 0.43.05. It will be 64bit only I think as I'm not keen to find offsets for and support twice more versions.That's really good to know. Thanks for the info!
Oh, I didn't remember that it didn't support 0.43.05 yet. Will update that thread.I'm still not completely sure that they aren't compatible. He sounds pretty confident that it works.
Soon I'll start working on updating TWBT for 0.43.05. It will be 64bit only I think as I'm not keen to find offsets for and support twice more versions.So this means i really need my new Hardware and win7 the sooner the better :(
<global-address name='twbt_render_map' value='0x1408170b0'/>
Edit: i was stupid...Hey,A few years later Meph: here's a 2gb of sprites to cover ALL possible things in DF :)
<...>
Transparent is pretty good. Most stuff looks good against the forum's grey-colored backgrounds.Sry; can't find how to set that as default b/g in FFx 50.00.. I am in no way a webpage programmer/scripter
[CREATURE_GRAPHICS:CAT]
[DEFAULT:DOMESTIC:1:0:AS_IS:DEFAULT]
[CHILD:DOMESTIC:6:0:AS_IS:DEFAULT]
[ANIMATED:DOMESTIC:11:0:AS_IS:DEFAULT]
[TRAINED_WAR:DOMESTIC:1:5:AS_IS:DEFAULT]
[TRAINED_HUNTER:DOMESTIC:6:5:AS_IS:DEFAULT]
Soon I'll start working on updating TWBT for 0.43.05. It will be 64bit only I think as I'm not keen to find offsets for and support twice more versions.
Soon I'll start working on updating TWBT for 0.43.05. It will be 64bit only I think as I'm not keen to find offsets for and support twice more versions.
From my perspective, updates are more exciting than the alternative art systems - TwbT is the last component I need for a 43.05 pack (albeit with alpha DFHack). Is there an expected timeline, beyond "maybe soonish"? (I admit that this is my preferred schedule)
I've got TWBT working with 0.43.05 on OSX, even the multilevel rendering patch (which I don't remember how it works) worked as is. Probably Windows/Linux will require more work because of the new compilers.
There's a build on build.mifki.com for 0.43.05 Windows 64bit.
There's a build on build.mifki.com for 0.43.05 Windows 64bit.
Fantastic! Are you planning to do 32-bit versions as well?
Soon I'll start working on updating TWBT for 0.43.05. It will be 64bit only I think as I'm not keen to find offsets for and support twice more versions.
I noticed that the current TwbT build (Win64 0.43.05) appears to be built against DFHack 0.43.05-alpha3. I would really discourage using that version due to a number of issues (e.g. this (https://github.com/DFHack/dfhack/issues/1047)) that are likely to cause all sorts of strange behavior. It could affect TwbT directly, but even if not, that build is probably not a good one to target.
I was actually looking at https://github.com/mifki/df-twbt/commit/c96bdedd3cee372da2e734bcd46aeb2f9d0b0601, but it looks like that's changed, so never mind about that.I noticed that the current TwbT build (Win64 0.43.05) appears to be built against DFHack 0.43.05-alpha3. I would really discourage using that version due to a number of issues (e.g. this (https://github.com/DFHack/dfhack/issues/1047)) that are likely to cause all sorts of strange behavior. It could affect TwbT directly, but even if not, that build is probably not a good one to target.
When did you check? I thought I've rebuilt it against alpha4. Anyway, one last patch is left for osx version, and I'll build it again then.
I was actually looking at https://github.com/mifki/df-twbt/commit/c96bdedd3cee372da2e734bcd46aeb2f9d0b0601, but it looks like that's changed, so never mind about that.I noticed that the current TwbT build (Win64 0.43.05) appears to be built against DFHack 0.43.05-alpha3. I would really discourage using that version due to a number of issues (e.g. this (https://github.com/DFHack/dfhack/issues/1047)) that are likely to cause all sorts of strange behavior. It could affect TwbT directly, but even if not, that build is probably not a good one to target.
When did you check? I thought I've rebuilt it against alpha4. Anyway, one last patch is left for osx version, and I'll build it again then.
There's a build on build.mifki.com for 0.43.05 Windows 64bit.
Fantastic! Are you planning to do 32-bit versions as well?Soon I'll start working on updating TWBT for 0.43.05. It will be 64bit only I think as I'm not keen to find offsets for and support twice more versions.
I don't mind configuring my build system to produce 32bit builds as well I think, if someone is willing to find offsets. But I can't commit to supporting two architectures on regular basis myself.Did you ever see my post from August (http://www.bay12forums.com/smf/index.php?topic=138754.msg7143865#msg7143865). I listed 64-bit and 32-bit build info. I was considering updating again to latest of everything but my personal build was working for both architectures at least back then for most common things in adventurer mode.
Has any progress been made on the 64-bit linux build of TWBT? I tried following the instructions in PATCHES.md to find the offsets on my own, but I just can't seem to wrap my head around it. It doesn't help that my main linux box won't run hopper and I'm forced into an underpowered VM to run it.
This was posted in the masterwork forum today. I've never seen this before, but I've never reloaded dfhack from the console before.
Is that a mockup or functional?
Stuff like this is usually not useful per. se. interesting/beautiful/pleasing etc...Is that a mockup or functional?
Functional, although not sure yet how much useful.
Stuff like this is usually not useful per. se. interesting/beautiful/pleasing etc...Is that a mockup or functional?
Functional, although not sure yet how much useful.
Stuff like this is usually not useful per. se. interesting/beautiful/pleasing etc...Is that a mockup or functional?
Functional, although not sure yet how much useful.
Useful here = whether anyone is going to use it, for whatever reason.
DF's save and load features become increasingly unreliable and prone to crashing. Someone (lethosor) identified a workaround for the save issues: DFHack's quicksave (as well as DF's regular autosaves) still works reliably even as normal saves crash instantly.D'you mean 'crash' or d'you mean 'freeze'? If the latter I recommend simply leaving the game & doing something else for a while: the freezes clear up (IME, currently) after 30-40min RT
switching from Meph's Tileset to Phoebus) fixes the issues pretty much as surely as switching out of the TWBT print mode. This may not be a TWBT issue after all.Meph's tileset uses 24x24 tiles; Phoebus uses (IIRC) 16x16 tiles. I tried this swapout in my current fort & it did improve the framerate by a lot.. shame; I miss the detail Meph put into his set (but not the lack of some tiles) :(
DF's save and load features become increasingly unreliable and prone to crashing. Someone (lethosor) identified a workaround for the save issues: DFHack's quicksave (as well as DF's regular autosaves) still works reliably even as normal saves crash instantly.D'you mean 'crash' or d'you mean 'freeze'? If the latter I recommend simply leaving the game & doing something else for a while: the freezes clear up (IME, currently) after 30-40min RTQuoteswitching from Meph's Tileset to Phoebus) fixes the issues pretty much as surely as switching out of the TWBT print mode. This may not be a TWBT issue after all.Meph's tileset uses 24x24 tiles; Phoebus uses (IIRC) 16x16 tiles. I tried this swapout in my current fort & it did improve the framerate by a lot.. shame; I miss the detail Meph put into his set (but not the lack of some tiles) :(
2-I was also pointed to this (http://www.bay12forums.com/smf/index.php?topic=138754.msg5624349#msg5624349) post. Is it still relevant, and is there any interest in having a look at the crash dumps? I don't know how much of a game-changer the move to 64-bit was and how relevant old issues still are going forward.
I also don't think there will be anything to be found, but you seem to think it's at least possible, so I went ahead and uploaded one.
I played a bunch yesterday and am now having the issue again with the new tileset version.
I'm starting to think I'm just reaching a critical mass of something (whatever it is) which causes a crash, and the combination of that tileset and TWBT print mode is just the "heaviest" settings I've used so it triggers the problems first.
One extra thing I've noticed is when the problem begins to crop up, rebooting my PC and running DF without doing anything else beforehand seems to help for a while, then eventually that no longer works.
Crash dump is there: http://dffd.bay12games.com/file.php?id=12804
Update: The fort has reached the point where loading will also crash using the Phoebus tileset in TWBT mode. It works correctly in TWBT_LEGACY or 2D.
What about STANDARD mode? 2D isn't quite correct comparison.
Can you upload your save or share privately with me? I don't see how TWBT can affect loading, but if it looks like it does, I can try to investigate.
What about STANDARD mode? 2D isn't quite correct comparison.
Can you upload your save or share privately with me? I don't see how TWBT can affect loading, but if it looks like it does, I can try to investigate.
Of course, I go back to TWBT to see how it goes and it loads on the second try.
Previous experience suggests it'll happen again, I'll upload a save then.
I haven't had a chance to try Standard print mode, I'll be sure to take a look.
I'm not sure what sharing a save involves, though. Just zip the save's folder and upload that? Because there seems to be graphics stuff in them or something. The first time I switched out of Meph's tileset, I had an error that I was able to resolve thanks to this (http://www.bay12forums.com/smf/index.php?topic=126076.msg7263594#msg7263594) post, and I figure whatever artifacts caused the error are still in the save and would cause a problem if shared.
I've got a save that seems to crash reliably. Strangely, it's very early in the fort, less than one year in. The only thing different about this one is a small chunk of the map is ocean, and I have a lot of squares marked for future channeling.
???
Thanks. And I should use it with the latest Meph tileset, right?
Did I do something wrong?
Edit: I figured it might be simpler to just include the graphics in the zip, so I went ahead and re-uploaded the file in case it helps. If that was unnecessary, feel free to ignore it.
Actually, maybe you can upload entire DF folder (without other saves to reduce size)? I quickly tried on couple computers and it didn't crash so far, just want to make sure everything is the same, like plugins, dfhack.init and so on.
Update: I'm getting a crash at work too. The two machines probably don't have much in common besides running Windows 10.
Update: I'm getting a crash at work too. The two machines probably don't have much in common besides running Windows 10.
Oh well.. I still can't get it to crash neither on win7 nor on win10, both running in VMs though, I need to find a physical windows pc to try. At which point of loading a save does it crash?
Each release of TWBT supports one version of DF, which is listed on the release page. To work on an older version of DF, you'll need to use an older version of both TWBT and DFHack.
Each release of TWBT supports one version of DF, which is listed on the release page.
Support for DF/DFHack 0.43.05-beta1
I've published binaries for 0.43.05-beta2.
That's weird. Do the previous crashes still happen (i.e. once you reached the point where 2D crashed, did TWBT_LEGACY crash too)? How much memory is DF using once you load your fort?
This is 43.03, so a 32-bit version of everything. I suspect that this may be significant.
So why don't you try 64bit, or are you on a 32bit OS?
I'm honestly not sure what it is. My best advice would be to disable all of the plugins (really disable them, with the "disable -all" command, not through a pack), and then re-enable a few at a time until you find one that's crashing.
I'm using latest version of the PyLNP (starter noobpack).
I'm using version 5.84 included in version 0.43.05-r05 of the Lazy Newb Pack.
What version of TWBT is it (printed in dfhack console on launch)?
In addition, what specific version are you talking about here? "The latest" doesn't help, and "PyLNP" is a launcher included in multiple packs. A link to a specific pack and an actual version number would be helpful.
I'm using version 5.84 included in version 0.43.05-r05 of the Lazy Newb Pack.
Download https://github.com/mifki/df-twbt/releases/download/v5.84/twbt-5.84-win.zip, unpack and copy all dll files from 0.43.05-r1 folder to hack/plugins folder.
Thanks! This fixed both problems.I'm using version 5.84 included in version 0.43.05-r05 of the Lazy Newb Pack.
Download https://github.com/mifki/df-twbt/releases/download/v5.84/twbt-5.84-win.zip, unpack and copy all dll files from 0.43.05-r1 folder to hack/plugins folder.
So how do you use this, and does it work with 43.04?It works with (64-bit) 0.43.05. Few utilities worked with 0.43.04 at all.
Because nobody uses 32bit windows.
My google-fu is failing me and I can't seem to locate a guide for using TWBT.
I just saw an LP where someone changed the color modifications for displaying lower z-levels. I'd love to know how to do that, and learn about the rest of the amazing features I'm not using.
[FONT:jolly9x12.png]
[FULLFONT:jolly9x12.png]
[GRAPHICS_FONT:curses_square_16x16.png]
[GRAPHICS_FULLFONT:curses_square_16x16.png]
[FONT:jolly9x12.png]
[FULLFONT:jolly9x12.png]
[GRAPHICS_FONT:curses_square_16x16.png]
[GRAPHICS_FULLFONT:curses_square_16x16.png]
It should be the other way round - FONT is set to text font (curses), and GRAPHICS_FONT set to tileset you like. Unless that was intentional and you want to use JollyBastion as the text font.
Ok, so I'm in a real confusion about how this works. Let's say I'm using Phoebus 16x16 for the graphics_font and Curses 16x16 for the font. I'm testing with Phoebus right now because it's a default that came with the pack and is presumably tested and should work.
Certainly. I'll show how they look in both configurations. I'm using the PyLNP launcher to make these adjustments btw, if that helps at all with the troubleshooting.
When AdvFort is activated while using TWBT, everything becomes black, however movement is still a thing and is registered, it's just that there's no tiles.This is my view (I kid you not, that is in fact a name in the generated language)
When AdvFort is activated while using TWBT, everything becomes black, however movement is still a thing and is registered, it's just that there's no tiles.This is my view (I kid you not, that is in fact a name in the generated language)Spoiler (click to show/hide)
I just started fiddling around with tilesets, and I've found that the world map on the embark screen uses my text font rather than my graphics font. Is this inevitable, or is there a setting somewhere I can fix that with?
I've merged Next branch into master and added a check for transparent1px.png and white1px.png files, version 6.21 is available.
You have my respect for continuing development of this amazing plugin. But why was the check for transparent1px.png and white1px.png files needed? Will the plugin not function without those, no matter how a graphics set uses the TwbT plugin?
It'd probably help if you mentioned what screen capture utility you are using?
DF does have in-built recording capability (http://dwarffortresswiki.org/index.php/DF2014:CMV), though. Does this work? (Not that it working would fix the issue.)
1. If you have a graphic tileset enabled, disable it. Unlike .FDF-MAPs, the CMV movie format will not play nice with these, and will cause all sorts of strange output.
Having a lot of instability issues running TWBT + GemSet on 43.05 (Windows 10), Hard crash-to-desktop is very common.
Is there some kind of error log I can check when it crashes?
Here's how to enable crash dumps (I hope it still works on 10): http://www.bay12forums.com/smf/index.php?topic=138754.msg5624349#msg5624349
What's the TWBT version?
Mifki, quick question - can you cut a release to support DFHack 43.05-r3, or will we have to wait for DFHack on 44.xx?
Dumb question, but does bitness matter with the TWBT plugin? Does TWBT work with both 32-bit and 64-bit DFHack / DwarfFortress?It has to match DFHack and DF (so do all plugins). Also, Mifki only provides 64-bit builds and support.
Multi-layer rendering looks pretty awesome. It looks like no changes are needed to the main tilesheet so TWBT-Next packs will still work fine without TWBT installed. Is it okay to use your example files as a base for updating SpaceFox with with TWBT-Next support?
What are these two files used for? Do I need to include them in packs or make any changes to them for anything?Dumb question, but does bitness matter with the TWBT plugin? Does TWBT work with both 32-bit and 64-bit DFHack / DwarfFortress?
- transparent1px.png
- white1px.png
What are these two files used for? Do I need to include them in packs or make any changes to them for anything?
- transparent1px.png
- white1px.png
Linux patch is already in git. TWBT seems to work fine, but I did notice a few bugs while running dfhack, so don't expect a perfect experience.What bugs, exactly? Could you please report them in the DFHack thread or repo if they're DFHack-specific? (That's the reason that DFHack release was put up.)
What bugs, exactly? Could you please report them in the DFHack thread or repo if they're DFHack-specific? (That's the reason that DFHack release was put up.)
[OVERRIDE:240:I:TOOL:TOOL:23:furniture:0]
[OVERRIDE:240:B:30:Bookcase::furniture:0]
local function make_override(letter, object, other_vector, type_enum)
if object then
local type = object:getType()
local subtype = object:getSubtype()
for id,objects in pairs(other_vector) do
for _,other_object in ipairs(objects) do
if other_object == object then
print ('[OVERRIDE:<old_tile>:' ..
letter .. ':' ..
id .. ':' ..
type_enum[type] .. ':' ..
(subtype ~= -1 and subtype or '') ..
':<tileset>:<new_tile>]')
break
end
end
end
end
end
make_override ('I', dfhack.gui.getSelectedItem(),
df.global.world.items.other,
df.item_type)
make_override ('B', dfhack.gui.getSelectedBuilding(),
df.global.world.buildings.other,
df.building_type)
[OVERRIDE:<old_tile>:I:IN_PLAY:CABINET::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:I:ANY_FURNITURE:CABINET::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:I:CABINET:CABINET::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:I:ANY_GENERIC128:CABINET::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:B:IN_PLAY:Cabinet::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:B:ANY_ACTUAL:Cabinet::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:B:ANY_HOSPITAL_STORAGE:Cabinet::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:B:ANY_STORAGE:Cabinet::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:B:ANY_BARRACKS:Cabinet::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:B:CABINET:Cabinet::<tileset>:<new_tile>]
You should keep only the line with the "CABINET" id.
My overrides for bookcases in 43.05 (item and building):Code: [Select][OVERRIDE:240:I:TOOL:TOOL:23:furniture:0]
[OVERRIDE:240:B:30:Bookcase::furniture:0]
Edit: try this dfhack lua script. It prints overrides for the current selected item/building. It prints all possible ids, you should choose the most specific one.Code: [Select]local function make_override(letter, object, other_vector, type_enum)
if object then
local type = object:getType()
local subtype = object:getSubtype()
for id,objects in pairs(other_vector) do
for _,other_object in ipairs(objects) do
if other_object == object then
print ('[OVERRIDE:<old_tile>:' ..
letter .. ':' ..
id .. ':' ..
type_enum[type] .. ':' ..
(subtype ~= -1 and subtype or '') ..
':<tileset>:<new_tile>]')
break
end
end
end
end
end
make_override ('I', dfhack.gui.getSelectedItem(),
df.global.world.items.other,
df.item_type)
make_override ('B', dfhack.gui.getSelectedBuilding(),
df.global.world.buildings.other,
df.building_type)
Output example:Code: [Select][OVERRIDE:<old_tile>:I:IN_PLAY:CABINET::<tileset>:<new_tile>]
You should keep only the line with the "CABINET" id.
[OVERRIDE:<old_tile>:I:ANY_FURNITURE:CABINET::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:I:CABINET:CABINET::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:I:ANY_GENERIC128:CABINET::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:B:IN_PLAY:Cabinet::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:B:ANY_ACTUAL:Cabinet::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:B:ANY_HOSPITAL_STORAGE:Cabinet::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:B:ANY_STORAGE:Cabinet::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:B:ANY_BARRACKS:Cabinet::<tileset>:<new_tile>]
[OVERRIDE:<old_tile>:B:CABINET:Cabinet::<tileset>:<new_tile>]
local c = df.global.cursor
local tiletype = dfhack.maps.getTileBlock(c.x, c.y, c.z).tiletype[c.x%16][c.y%16]
print ('[OVERRIDE:<old_tile>:T:'..df.tiletype[tiletype]..':<tileset>:<new_tile>]')
to get the tile type under the cursor. I am not sure about the coordinate stuff, but it seemed to work well for me.I just wrote it, it is not a part of a bigger script. You can copy the code in a .lua file in your hack/scripts folder and run it.
You can also addCode: [Select]local c = df.global.cursor
to get the tile type under the cursor. I am not sure about the coordinate stuff, but it seemed to work well for me.
local tiletype = dfhack.maps.getTileBlock(c.x, c.y, c.z).tiletype[c.x%16][c.y%16]
print ('[OVERRIDE:<old_tile>:T:'..df.tiletype[tiletype]..':<tileset>:<new_tile>]')
I am still a newbie at dfhack/lua scripting (I mostly used it for debugging DT), it can surely be improved. I don't even know how the get the size of the vector to automatically find the best id instead of printing all of them.
No problem, go ahead.
A few more details about the id part. If I understand twbt code (https://github.com/mifki/df-twbt/blob/0237531caed1b77323f061abf21e0f32f7da3abb/tileupdate_map.hpp#L152) correctly, it look for every item/building in the other[id] vector. So, using the most generic id (IN_PLAY) would work, but for efficiency the smallest vector should be preferred. (Can you confirm that, mifki?) The improved script should look for the smallest vector containing a reference to the item/building and use only this id.
I made a script (https://gist.github.com/indivisible/93a30205d0c562302ca93b172a0d4eb7) that should make creating Linux version patches easier. Needs Python3.6, radare2 (https://github.com/radare/radare2) (I installed from git sources) and r2pipe for python (should be installable with pip)
I'll eventually reimplement overrides more efficiently which is now possible with the "Next" version, and override specification will be simplified too.
I really want to know exactly the meaning of this line... I am really interested in what you have planned "Next".
Hopefully this is the right place to mention this, but I'm having issues while using TWBT on the newest DF version (using the Alpha of DF Hack). When I set my game to play in a window and use TWBT, it cuts some off of the top and bottom of the window....it looks like about the size of the window title bar. I noticed this because the FPS counter gets blocked out.
If I change to TWBT Classic, 2D, etc then the screen fits in the window fine. TWBT works fine in full screen as well, it's only cut off in the windowed mode. I've attempted changing the init.txt to different values for the windowed mode and it doesn't correct the issue. Any ideas on what's going on? I can provide screenshots if you like.
Hi there again!
Have posted this problem a while ago, but looks like it's still here:
Humanoid (animal persons, dwarfs, humans etc) corpse overrides doesn't work in DF 0.42.06. Other corpses override fine. Problem exists at least from 0.42.05, but everything worked fine in 0.40.24. Tested it on mine Set, SpaceFox and GemSet using manual installation and LNP. These overrides didn't change since 0.40.24.
PS: removing [APPLY_CREATURE_VARIATION:ANIMAL_PERSON] from animal person "fixes" the problem.
Just to get this back to your attention:Hi there again!
Have posted this problem a while ago, but looks like it's still here:
Humanoid (animal persons, dwarfs, humans etc) corpse overrides doesn't work in DF 0.42.06. Other corpses override fine. Problem exists at least from 0.42.05, but everything worked fine in 0.40.24. Tested it on mine Set, SpaceFox and GemSet using manual installation and LNP. These overrides didn't change since 0.40.24.
PS: removing [APPLY_CREATURE_VARIATION:ANIMAL_PERSON] from animal person "fixes" the problem.
It's still true with the current version. I tested it on pets, works. Tested on civ-member, does not work.
I also tested TWBT-Next on vermin and pets. Sadly it doesn't work... no transparency, instead I get the usual black background. It would be fantastic if it would work on vermin, since they are tiny and move a lot... which makes the black background stand out the most.
https://github.com/mifki/df-twbt/releasesThat one doesn't fully work. Workshop overrides don't function, because the new display-case workshop messes things up. It breaks all workshop overrides, including custom workshops and the embark wagon.
It's a dfhack's fault, not twbt. We need to wait for a new dfhack update.https://github.com/mifki/df-twbt/releasesThat one doesn't fully work. Workshop overrides don't function, because the new display-case workshop messes things up. It breaks all workshop overrides, including custom workshops and the embark wagon.
Sorry if I was unclear. I'm looking for a fix for that issue.
That's great that you provided examples but makes difficult to quote:)
1. "Transparency on top of terrain features". I didn't quite understand what this means, sorry.
If an item that uses transparency, lets say a "spear" is on top of a floor tile that already shows an override, lets say a naturally grown "pig tail", then the pig tail does not show it's override tile, but the tile from the original DF tileset. It looks as if it was never overridden at all.
2. "Multilevel breaks transparency". This should definitely work, I'll check.
It might be that transparency works, but shows the background color of the open-space (which is solid black) on the current level, instead of the background of the tile below.
3. "Contaminants cancel overrides". Do contaminants change tile symbol? I thought they just changed colour, in which case I'm not sure why it breaks overrides.
They should only change color. I'm confused by this as well. I first saw it happen in trees, after leaves fell in autumn. Later I noticed the walls in a cavern, and the only difference with "a splatter of blood". Cleaning it resets it. No idea if all contaminants do this, or if it's only for specific tiles.
4. "Transparency in workshops". Workshop transparency is currently disabled. I think the reason for this was that I tried playing with it enabled and it was very very difficult to notice workshops on the grass. Of course it depends on tileset used and workshop type, but I thought it would be better to not make changes to workshop rendering at all rather than make it worse. Also, I sort of would expect workshops in RL to not be just objects placed on the ground and to have if not flooring but at least something which would make workshop tiles in game in turn have their own background. So we need some decision here or a way for tileset authors to control (and I guess for some other types of buildings too, stockpiles maybe).
Ok, and no problem at all. I think the best case would be to not make workshop tiles transparent.
A. I can simply make tiles for them with a nice background,
B. they look more distinct/clearer if they are set apart from the background color, and
C. DF already has a fully transparent tile for workshops, if people really want to it; for example for magma/water access underneath.
5. "Items on slopes". This is strange, I'll check it.
Tested it again, it falls under category 1. The item is on top of the slope. The slope already uses an override. Since an item using transparency is on top of an tile with an override, the override doesn't work anymore and shows the original tile in the background. Same case as in 1.
Can you upload the save you used to make these screenshots, including raw folder and art/init folders?
I used several different saves. Which cases do you want to look at? All five?
The limits question is more important. There's no fixed number, it depends on graphics card used. I think all currently used cards should support texture size 4096x4096 or at least 2048x2048. This gives 64 512x512 sheets or at least 16 sheets. It may seem ok then, but this also includes all creature graphics, so I really need to find a way to split tiles into several GPU textures and not worry about limits anymore.
WOW, the creature graphics too? For references: I have 5 civ-sheets which are almost the same size as a tileset, and 38 files with creature sprites for animals. So, 15-25 tilesets, 5 civ-sheets, 28 animal sheets. Just within the limit, especially considering the animal sheets are usually smaller than 512x512.
Here is a screenshot:Spoiler (click to show/hide)
If you fixed 1., do items that are carried fixed too? It was kinda the same bug... I noticed first with eggs/boulders, which share a tile number. No matter what I did, either eggs in nestboxes looked like boulders, or boulders carried by dwarves looked like eggs. Or both like boulders, or both like eggs. ^^
Always crashes on me when travelling
heads up, new DF-Hack version got released 20 min ago. An update would be superb.
heads up, new DF-Hack version got released 20 min ago. An update would be superb.
Updating TWBT takes some extra work. Anyway OSX patch is already upstream, I've made a PR for the linux patch, but no windows one yet AFAIK.
[OVERRIDE:236:B:WORKSHOP_KITCHEN:Workshop::_MDF_overrides_1:155:16]
but they dont work for custom workshops, like [OVERRIDE:164:B:WORKSHOP_CUSTOM:Workshop:GARDEN_SMALL_PLANT:_MDF_overrides_4:164]
I was away for several days, version 6.27 is available now for 0.44.03-alpha1
4. "Transparency in workshops". Workshop transparency is currently disabled. I think the reason for this was that I tried playing with it enabled and it was very very difficult to notice workshops on the grass. Of course it depends on tileset used and workshop type, but I thought it would be better to not make changes to workshop rendering at all rather than make it worse. Also, I sort of would expect workshops in RL to not be just objects placed on the ground and to have if not flooring but at least something which would make workshop tiles in game in turn have their own background. So we need some decision here or a way for tileset authors to control this…
…(and I guess for some other types of buildings too, stockpiles maybe).
The limits question is more important. There's no fixed number, it depends on graphics card used. I think all currently used cards should support texture size 4096x4096 or at least 2048x2048. This gives 64 512x512 sheets or at least 16 sheets. It may seem ok then, but this also includes all creature graphics, so I really need to find a way to split tiles into several GPU textures and not worry about limits anymore.
What are the Building IDs and Building Types for the new Pedestal and Display Case buildings?
[OVERRIDE:<old_tile>:B:DISPLAY_CASE:DisplayFurniture::<tileset>:<new_tile>]
I think stockpiles should definitely support multi-layered rendering. Someone was asking recently (https://www.reddit.com/r/dwarffortress/comments/7mql6g/biweekly_df_questions_thread/drw3js3/) about a way to make stockpiles invisible. And it looks like TWBT even allows stuff to be only partially-transparent. A partially-transparent stockpile might be nice.
Thanks. Works. I got the display case and pedestal to show an override. I combined the graphics, it looks like a display case on top of a pedestal ingame, I think that's a good compromise.
I tried the print-twbt-override script. For all custom workshops, including soap maker and screwpress, it shows old-tile:B:WEAPON_UPRIGHT:Workshop:23:new-tileset:new-tile, which is obviously not what it should show.
Seems there is still something wrong in the list of building IDs, either in dfhack, twbt or both.
Thanks. Works. I got the display case and pedestal to show an override. I combined the graphics, it looks like a display case on top of a pedestal ingame, I think that's a good compromise.
I tried the print-twbt-override script. For all custom workshops, including soap maker and screwpress, it shows old-tile:B:WEAPON_UPRIGHT:Workshop:23:new-tileset:new-tile, which is obviously not what it should show.
Seems there is still something wrong in the list of building IDs, either in dfhack, twbt or both.
Maybe I should go back to the first version when I printed every possible ID, letting the user choose the best one intelligently.Every possible sounds great!
I just realize that you don't need to know the subtype for the Pedestal and Display Case because they both have different original tiles, so they can have separate graphics without it.That is only partly correct. The buildings use the same tile. The tools use two different tiles. But the constructed display case and pedestal use the same tile, just inverted.
Does this new version also have the creature transparency you mentioned once?
Are you speaking of tiles or sprites? As in data/art or raw/graphics?Does this new version also have the creature transparency you mentioned once?
No, the required changes didn't get into alpha1. Also, we haven't decided what to do with creature backgrounds. Proper implementation (loading separate -bg images) will take time, and also probably won't be possible until I can use more than one texture, with potentially twice more images for creatures it definitely will exceed the max texture size.
Because adding creature transparency for vermin, which use tiles from data/art means that it adds no extra -bg images, since I already have one for the items, which are on the same tileset.
For creature sprites in raw/graphics, it would add lots of -bg files... but I don't think it's really necessary for them, since they dont use their tile numbers at all. They get their graphics from the graphics.txt files.
I might be misunderstanding, but I'm pretty sure the default ASCII tileset uses different tiles for these two buildings when they're constructed.I just realize that you don't need to know the subtype for the Pedestal and Display Case because they both have different original tiles, so they can have separate graphics without it.That is only partly correct. The buildings use the same tile. The tools use two different tiles. But the constructed display case and pedestal use the same tile, just inverted.
I double/triple checked, and Toady sneaked in a new feature for those... we were both right.I might be misunderstanding, but I'm pretty sure the default ASCII tileset uses different tiles for these two buildings when they're constructed.I just realize that you don't need to know the subtype for the Pedestal and Display Case because they both have different original tiles, so they can have separate graphics without it.That is only partly correct. The buildings use the same tile. The tools use two different tiles. But the constructed display case and pedestal use the same tile, just inverted.
Version 6.28 adds an option to hide stockpiles unless in [q], [p] or [k] mode. Enable with "twbt hide_stockpiles 1". Also requires "twbt redraw_all 1", which is required for tilesets that override terrain tiles anyway.
Vermin are units. And currently not transparent. If they die, they turn into remains, which are items. Or caught fish-vermin, those too. But the living, moving vermin can't use transparency atm.Because adding creature transparency for vermin, which use tiles from data/art means that it adds no extra -bg images, since I already have one for the items, which are on the same tileset.
But vermin are items not units, this new stuff doesn't affect them...
Version 6.30 has unit and workshop transparency support. Thanks to Toady for exposing the required methods of the unit class.
Enabled with "twbt unit_transparency 1" and "twbt workshop_transparency 1" commands.
Happy New Year!
Version 6.30 has unit and workshop transparency support. Thanks to Toady for exposing the required methods of the unit class.
Enabled with "twbt unit_transparency 1" and "twbt workshop_transparency 1" commands.
Happy New Year!
Oh, nice! Does version 6.30 use DFHack 0.44.03-beta1?
Thank you for your outstanding work.
I still do not understand - for creatures need to have a file -bg or not? Because it works without it.
I noticed that creature on overridden tiles is not displayed exactly as expected. Below is an example where a dwarf passes through a bridge, but in the background a sprite of wall is displayed.Spoiler (click to show/hide)
Version 6.30 has unit and workshop transparency support. Thanks to Toady for exposing the required methods of the unit class.
Enabled with "twbt unit_transparency 1" and "twbt workshop_transparency 1" commands.
However as it is now, there are two layers only - terrain and an item/building/unit(soon). So currently it can't be terrain then a semi-transparent stockpile, then an item. Maybe at some point I'll rewrite it to support rendering any number of tiles one on top of another (or at least three).
So if you have unit transparency enabled, when a dwarf walks over a tile while holding something, that tile will revert to the tile from the main graphics tilesheet. Is that right?Or if they walk over a plant. Or over an item. Or a corpse. Or a ramp. Walk around in a tree. Are in combat, on the same tile as another unit. Ride a minecart. etc.
So if I don't override any ground tiles except for the bridge, then the only time unit transparency causes the background to revert is when the unit walks on a bridge?
Vordak: Any tile using transparency, on top of another tile using an override, will lead to a display error for the override. Creatures on bridges, items carried, items on plants...Or if they walk over a plant. Or over an item. Or a corpse. Or a ramp. Walk around in a tree. Are in combat, on the same tile as another unit. Ride a minecart. etc.small price to pay.
Creatures don't require -bg because there's no easy way for me to implement loading of such files, so for now creatures just won't show bg colour. That's why unit transparency is disabled by default [until we confirm bg colour is not important].
I haven't noticed anything weird with the background color. But creatures don't usually use "add color" in the type of packs that would want to use creature transparency. Most of the "add color" graphics pack are going to be more ASCII-style packs that have mostly "black" floors.
C'mon guys I mentioned this above:Sorry, my mistake.Creatures don't require -bg because there's no easy way for me to implement loading of such files, so for now creatures just won't show bg colour. That's why unit transparency is disabled by default [until we confirm bg colour is not important].
Or maybe it only loads the parts that have graphics defined for them?
B:ANY_STORAGE:Bookcase::
B:UNK_V42_2:Bookcase::
You asked earlier about vermin transparency. Just wanted to say that I have no idea why they don't work. Creatures are fine, vermin on ground not. They show a solid black background. It works when they are dead, for example when a fisher catches them... I guess they count as items in that case.
Do you think ANY_CRITTER or ANY_EDIBLE_VERMIN would help?
I also can't seem to override build bookcases. The item is fine, but the constructed bookcase shows the original tile. When I use print-twbt-overrides, I get those values for it:Code: [Select]B:ANY_STORAGE:Bookcase::
B:UNK_V42_2:Bookcase::
That's with the newest windows build on dfhack beta.
Mifki, about the workshops... is there any chance to override their tiles based on x/y position?
If you do that, you lose the ability to "m" melt items.Mifki, about the workshops... is there any chance to override their tiles based on x/y position?
I had a similar issue, me and bear had... one of the ways around it was just to kick out all of the shops that you can writr your own reactions for with dfhack and implement custom buildings for it, rather easy for races where you already want to control all of the productions. Easiest to replace was the smelter... anyways design the building with every x,y having its own tile (i used 1-9) than override the custom workshop with the tiles you want, making workshops into artwork.
I:INSTRUMENT_STATIONARY:INSTRUMENT:#:
B:UNK_V42_3:Instrument::
(Sorry to bother you if this is pie-in-the-sky BS.)
Using Meph's tileset, I adjusted my dfhack init to include:
multilevel 15
multilevel shadowcolor 0 0 0 0.6
multilevel fogcolor 0.1 0.1 0.3
multilevel fogdensity 0.25 0 1
Shadows might be too dark for some and the fog is denser (fogcolor is vanilla) but I can always tell which level is which (I guess not being used to it I was having a hard time on adventure mode) and I also get the full 15 levels.
I have some examples below. Actually trying to use this might be a pain in the ass, but I think if some translucency could be achieved (better than what I can do overlaying images in GIMP, I was trying to lighten the overlay along with having the opacity lowered but that would mess up the whole picture, and my TWBT shadow settings on the overlays make this a little too dark to work) we might be able to have a sort of 2.5D DF.
Below I've posted the original start I'm using, then overlaid transparent versions of several levels (enough to reach the top of the trees) over the regular view, using 25%, 37.5%, and 50% opacity:I'm wondering if it might be easier to distinguish layers above from layers below if the layers above used white for the shadow and fog colors.Spoiler (click to show/hide)
Those look like pretty good settings. Do you know what the fogdensity numbers do exactly? I'm guessing the first number is either the fog density on the level below the active level, or it's the max fog density on the bottom layer. Maybe "start" is the fog level on the active level? And step is the number of levels you have to look down to see the maximum fog density?
I'm wondering if it might be easier to distinguish layers above from layers below if the layers above used white for the shadow and fog colors.
Core.h is part of DFHack. You would have to clone DFHack too and point the solution file to it somehow.
There's build-windows.bat file in which you can just set path to dfhack and its version.
There's build-windows.bat file in which you can just set path to dfhack and its version.
Ah, yep, thanks, got the vcxproj file set up with the paths and everything is good, I should have at least figured that out from the variables in the vxcproj file, sorry to trouble you.
Since you know way more about this than me, do you think it is possible (if I were to somehow gain the knowledge to do this on my own without bothering you) to render levels above you while having clickthrough to the current level?
The more I look at memory patching the more I realize that I have little hope of achieving this without being a huge pain the ass with more questions, but I'm willing to silently slog through it if it's possible.
Warmist, now all we need is rendermax in twbt for fancy lighting. Do it! :PI've tried to understand why it did not work, and what needed to be done to work and failed :|
Would be really hard to do, considering that most tiles above a fort are solid, unrevealed rock.
Hopefully this is the right place to mention this, but I'm having issues while using TWBT on the newest DF version (using the Alpha of DF Hack). When I set my game to play in a window and use TWBT, it cuts some off of the top and bottom of the window....it looks like about the size of the window title bar. I noticed this because the FPS counter gets blocked out.
If I change to TWBT Classic, 2D, etc then the screen fits in the window fine. TWBT works fine in full screen as well, it's only cut off in the windowed mode. I've attempted changing the init.txt to different values for the windowed mode and it doesn't correct the issue. Any ideas on what's going on? I can provide screenshots if you like.
A screenshot would help if possible.
Hopefully I did it the right way, I'm going to tell the post to alert me to replies this time. :-)
Did you change your "Font" tilesheet to Curses, or did it come that way? For some reason Meph also had its Font tilesheet changed to Curses in the latest starter pack. It looks like you're using Phoebus. Go into the "Customize" sub-tab of the "Graphics" tan and change your "Font" tilesheet to Jecobus_12x16.png (or something like that). That might fix the cropping issue.
is there a problem with taking twbt-rendered output and slapping calculated separately output of rendermax light engine on it as semitransparent mask of proper color (essentialy, just another tile override)?Warmist, now all we need is rendermax in twbt for fancy lighting. Do it! :PI've tried to understand why it did not work, and what needed to be done to work and failed :|
Not really, just a problem of it's two very separate plugins. I've already done some work so that rendermax could be moved to a module and used by any other plugin (probably it would only be useful for twbt though). Also i've started redoing the lighting engine calculations so not sure in what state i left it :?is there a problem with taking twbt-rendered output and slapping calculated separately output of rendermax light engine on it as semitransparent mask of proper color (essentialy, just another tile override)?Warmist, now all we need is rendermax in twbt for fancy lighting. Do it! :PI've tried to understand why it did not work, and what needed to be done to work and failed :|
Looking forward to next version of TWBT so I don't get stuck with random dudes hanging out at my next fort. I was looking around to try to get the values for patches.hpp myself but I can't find much using Cheat Engine to be able to tell.
This has them, although you'll still need to edit them into the header and then compile TWBT yourself. I'll create a PR sometime tomorrow.
I think redrawing is something that TWBT is doing anyway, and the "redraw all" command just makes it redraw more often than it normally does. Maybe the redraw all command isn't directly responsible for the crashes; maybe it just increases the chances for the crash condition to occur.
I think redrawing is something that TWBT is doing anyway, and the "redraw all" command just makes it redraw more often than it normally does. Maybe the redraw all command isn't directly responsible for the crashes; maybe it just increases the chances for the crash condition to occur.
I've already explained somewhere here, redraw_all makes it redraw all the tiles and not just with changed tile numbers/colours. I don't know why it crashes for farm plots, but in general it does all the processing on another thread which isn't very good, but doesn't slow down simulation and wasn't causing problems before. Probably reprocessing ALL tiles makes it more likely to crash. Or maybe it's something completely different.
Anyway, I'll try looking into this crash but then I'll take a break and think about rewriting TWBT because there's a number of things that I can't fix without architecture changes (namely, support for multiple GPU textures to get rid of the tilesheet limit, support for overriding all building tiles, optimisations, and eliminating of the possibility of the said thread synchronisation issues). I don't mean the break will necessarily be long but rather that I'll not make fixes or add new features to the current implementation.
Yep, version 6.33 is published now.
Version 6.34 is available for 0.44.05-r1.is it safe to just copy the newer DFHACK version into meph's pack and overwrite the existing one?
Version 6.34 is available for 0.44.05-r1.is it safe to just copy the newer DFHACK version into meph's pack and overwrite the existing one?
thanks, i'll wait until he adopts it in his pack.Version 6.34 is available for 0.44.05-r1.is it safe to just copy the newer DFHACK version into meph's pack and overwrite the existing one?
I think so, but better ask Meph, his "tilesets" are more than just tilesets, don't know what they may depend on.
Version 6.34 is available for 0.44.05-r1.is it safe to just copy the newer DFHACK version into meph's pack and overwrite the existing one?
Version 6.34 is available for 0.44.05-r1.is it safe to just copy the newer DFHACK version into meph's pack and overwrite the existing one?
Yep, I copied new dfhack replacing the alpha release, added twbt and everything looks fine.
mifki, if you don't mind me asking, why TWBT is not compiled/bundled with dfhack?
DFHack is ready. Have a nice day!
DFHack version 0.44.05-r1 (release) on x86_64
Type in '?' or 'help' for general help, 'ls' to see all commands.
Unit transparency enabled
[DFHack]# /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/df_osx v0.44.05/dfhack: line 15: 4849 Segmentation fault: 11 DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"
I got this just now in 6.34 with DFHack-r1 using Spacefox with TWBT unit transparency enabled after embarking in a freshly-generated smaller, short history world:Code: [Select]DFHack is ready. Have a nice day!
DFHack version 0.44.05-r1 (release) on x86_64
Type in '?' or 'help' for general help, 'ls' to see all commands.
Unit transparency enabled
[DFHack]# /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/df_osx v0.44.05/dfhack: line 15: 4849 Segmentation fault: 11 DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"
I tried re-embarking in the same world again with TWBT still on but without unit transparency enabled in Tergel, and it was fine. I tried re-embarking again with the original settings with the crash, and it worked fine. I'm not sure why it would have behaved differently the second time with the same settings in the same world. In all three attempts I embarked in the default location of the embark selection cursor.
Sorry if this is the wrong place to post. I'm running 10.7.5 Lion. Maybe it was just a freak occurrence, but I thought I'd mention just in case.
Process: dwarfort.exe [4849]
Path: /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/dwarfort.exe
Identifier: dwarfort.exe
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: sh [4843]
Date/Time: 2018-02-06 21:25:54.454 -0600
OS Version: Mac OS X 10.7.5 (11G63)
Report Version: 9
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGSEGV)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Application Specific Information:
objc[4849]: garbage collection is OFF
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff8cb58bca __psynch_cvwait + 10
1 libsystem_c.dylib 0x00007fff8a3e2274 _pthread_cond_wait + 840
2 SDL 0x0000000102dae52e SDL_CondWaitTimeout + 158
3 SDL 0x0000000102dae811 SDL_SemWaitTimeout + 93
4 dwarfort.exe 0x00000001010de6b2 0x100000000 + 17688242
5 dwarfort.exe 0x00000001010deac7 0x100000000 + 17689287
6 ??? 0x00007fff5fbfedf0 0 + 140734799801840
Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x00007fff8cb597e6 kevent + 10
1 libdispatch.dylib 0x00007fff88138786 _dispatch_mgr_invoke + 923
2 libdispatch.dylib 0x00007fff88137316 _dispatch_mgr_thread + 54
Thread 2:
0 libsystem_kernel.dylib 0x00007fff8cb5882a __kill + 10
1 libsystem_c.dylib 0x00007fff8a432cfa _sigtramp + 26
2 twbt.plug.dylib 0x0000000110818d26 unit_hook::interpose_fn_getGlowTile() + 166
3 ??? 0x0000000f00120021 0 + 64425689121
Thread 3:: com.apple.audio.IOThread.client
0 libsystem_kernel.dylib 0x00007fff8cb5767a mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fff8cb56d71 mach_msg + 73
2 com.apple.audio.CoreAudio 0x00007fff91364eb3 HALB_MachPort::SendMessageWithReply(unsigned int, unsigned int, unsigned int, unsigned int, mach_msg_header_t*, unsigned int) + 93
3 com.apple.audio.CoreAudio 0x00007fff91364f05 HALB_MachPort::SendSimpleMessageWithSimpleReply(unsigned int, unsigned int, int, int&, unsigned int) + 37
4 com.apple.audio.CoreAudio 0x00007fff9135e568 HALC_ProxyIOContext::IOWorkLoop() + 888
5 com.apple.audio.CoreAudio 0x00007fff9135e151 HALC_ProxyIOContext::IOThreadEntry(void*) + 73
6 com.apple.audio.CoreAudio 0x00007fff9135e00c HALB_IOThread::Entry(void*) + 78
7 libsystem_c.dylib 0x00007fff8a3de8bf _pthread_start + 335
8 libsystem_c.dylib 0x00007fff8a3e1b75 thread_start + 13
Thread 4:
0 libsystem_kernel.dylib 0x00007fff8cb58e42 __semwait_signal + 10
1 libsystem_c.dylib 0x00007fff8a394dea nanosleep + 164
2 libsystem_c.dylib 0x00007fff8a394bb5 usleep + 53
3 libfmodex.dylib 0x0000000102c45a40 0x102c41000 + 19008
4 libfmodex.dylib 0x0000000102cc6995 FMOD::SystemI::createSoundInternal(char const*, unsigned int, unsigned int, unsigned int, FMOD_CREATESOUNDEXINFO*, FMOD::File**, bool, FMOD::SoundI**) + 23205
5 libsystem_c.dylib 0x00007fff8a3de8bf _pthread_start + 335
6 libsystem_c.dylib 0x00007fff8a3e1b75 thread_start + 13
Thread 5:
0 libsystem_kernel.dylib 0x00007fff8cb58bf2 __psynch_mutexwait + 10
1 libsystem_c.dylib 0x00007fff8a3dd1a1 pthread_mutex_lock + 545
2 ruby.plug.dylib 0x000000010e1f673c _ZL13df_rubythreadPv + 3004
3 ruby.plug.dylib 0x000000010e1fa3aa tthread::thread::wrapper_function(void*) + 10
4 libsystem_c.dylib 0x00007fff8a3de8bf _pthread_start + 335
5 libsystem_c.dylib 0x00007fff8a3e1b75 thread_start + 13
Thread 6:
0 libsystem_kernel.dylib 0x00007fff8cb58df2 __select + 10
1 libdfhack.1.0.0.dylib 0x00000001025accb8 DFHack::Private::prompt_loop(tthread::recursive_mutex*, DFHack::CommandHistory&) + 536
2 libdfhack.1.0.0.dylib 0x00000001025abecc DFHack::Console::lineedit(std::string const&, std::string&, DFHack::CommandHistory&) + 364
3 libdfhack.1.0.0.dylib 0x00000001022ffb06 fIOthread(void*) + 582
4 libdfhack.1.0.0.dylib 0x00000001025ea1fa tthread::thread::wrapper_function(void*) + 10
5 libsystem_c.dylib 0x00007fff8a3de8bf _pthread_start + 335
6 libsystem_c.dylib 0x00007fff8a3e1b75 thread_start + 13
Thread 7:
0 libsystem_kernel.dylib 0x00007fff8cb58bca __psynch_cvwait + 10
1 libsystem_c.dylib 0x00007fff8a3e2274 _pthread_cond_wait + 840
2 libdfhack.1.0.0.dylib 0x00000001022fe7a3 fHKthread(void*) + 131
3 libdfhack.1.0.0.dylib 0x00000001025ea1fa tthread::thread::wrapper_function(void*) + 10
4 libsystem_c.dylib 0x00007fff8a3de8bf _pthread_start + 335
5 libsystem_c.dylib 0x00007fff8a3e1b75 thread_start + 13
Thread 8:
0 libsystem_kernel.dylib 0x00007fff8cb5847a __accept + 10
1 libdfhack.1.0.0.dylib 0x00000001025df0f5 CPassiveSocket::Accept() + 293
2 libdfhack.1.0.0.dylib 0x00000001024113a9 DFHack::ServerMain::threadFn(void*) + 377
3 libdfhack.1.0.0.dylib 0x00000001025ea1fa tthread::thread::wrapper_function(void*) + 10
4 libsystem_c.dylib 0x00007fff8a3de8bf _pthread_start + 335
5 libsystem_c.dylib 0x00007fff8a3e1b75 thread_start + 13
Thread 9:
0 libsystem_kernel.dylib 0x00007fff8cb59192 __workq_kernreturn + 10
1 libsystem_c.dylib 0x00007fff8a3e0594 _pthread_wqthread + 758
2 libsystem_c.dylib 0x00007fff8a3e1b85 start_wqthread + 13
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000104 rbx: 0x00007fff7648b960 rcx: 0x00007fff5fbfec38 rdx: 0x0000000000412000
rdi: 0x0000000103227d20 rsi: 0x0041200100412100 rbp: 0x00007fff5fbfecf0 rsp: 0x00007fff5fbfec38
r8: 0x0000000000000000 r9: 0x0000000000010068 r10: 0x0000000000000000 r11: 0x0000000000200202
r12: 0x0000000000412000 r13: 0x0041200100412100 r14: 0x0000000103227d40 r15: 0x0000000103227d38
rip: 0x00007fff8cb58bca rfl: 0x0000000000200203 cr2: 0x0000000100de6fb0
Logical CPU: 0
Binary Images:
0x100000000 - 0x1013c0fef +dwarfort.exe (??? - ???) <B82BFF69-29A8-9EC9-0FFA-C9A54FBDADFD> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/dwarfort.exe
0x1022e5000 - 0x10275ffef +libdfhack.1.0.0.dylib (??? - ???) <119E75FF-E643-3882-A10A-8DE365DD70E3> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/libdfhack.1.0.0.dylib
0x102c41000 - 0x102d25ff7 +libfmodex.dylib (??? - ???) <9BAFC1DE-619D-2294-56AD-DC481D9DEC73> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/libfmodex.dylib
0x102d80000 - 0x102dd7fff +SDL (1.2.14 - 1.2.14) <C726704D-C3D9-37D1-800E-9D92D9870EAE> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/SDL.framework/Versions/A/SDL
0x102dea000 - 0x102e21fff +org.libsdl.SDL-image (1.2.12 - 1.2.12) <2635DCDC-CE72-316B-89CB-E1D5AAD770C4> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/SDL_image.framework/Versions/A/SDL_image
0x102e29000 - 0x102e2cfff +org.libsdl.SDL-ttf (2.0.11 - 2.0.11) <9ACD8102-0778-39B4-B755-AE0BDC93252A> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/SDL_ttf.framework/Versions/A/SDL_ttf
0x102e2f000 - 0x102ed8fe7 +libstdc++.6.dylib (7.19.0 - compatibility 7.0.0) <CFD9F641-0D44-3221-A623-B35085CD9999> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/libstdc++.6.dylib
0x102fd7000 - 0x102feafe1 +libgcc_s.1.dylib (??? - ???) <87EC950D-7C3D-ECE5-829B-5C4AD5895901> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/libgcc_s.1.dylib
0x102ff6000 - 0x103091ff7 +freetype (2.6.3 - compatibility 2.6.0) <876EF565-AB93-3A07-AFAD-603F070320C1> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/SDL_ttf.framework/Versions/A/Frameworks/freetype.framework/Versions/2.6.3/freetype
0x1030a6000 - 0x1030d1fff +libprotobuf-lite.dylib (??? - ???) <9EA65832-99FF-3280-935A-ABEE6A971EE0> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/libprotobuf-lite.dylib
0x1030e7000 - 0x10312ffff +liblua.dylib (??? - ???) <E7207AA0-7614-3FF1-ABE5-6BECA80041FB> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/liblua.dylib
0x105dc3000 - 0x105dc7fff com.apple.audio.AudioIPCPlugIn (1.2.3 - 1.2.3) <F94D690D-3196-3B01-B798-09708367D28D> /System/Library/Extensions/AudioIPCDriver.kext/Contents/Resources/AudioIPCPlugIn.bundle/Contents/MacOS/AudioIPCPlugIn
0x105dcc000 - 0x105dd1fff com.apple.audio.AppleHDAHALPlugIn (2.2.5 - 2.2.5a5) <4EC4981B-68AE-357E-960F-3D4603A61E9F> /System/Library/Extensions/AppleHDA.kext/Contents/PlugIns/AppleHDAHALPlugIn.bundle/Contents/MacOS/AppleHDAHALPlugIn
0x1084e7000 - 0x1084f1fef libcldcpuengine.dylib (2.0.19 - compatibility 1.0.0) <4572AD1E-D1D1-3412-AFCC-D37037B1FAB5> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libcldcpuengine.dylib
0x1084f7000 - 0x1084faff7 libCoreFSCache.dylib (??? - ???) <0D155750-7910-32C5-8327-924FC1089442> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib
0x108600000 - 0x10874bff7 com.apple.audio.units.Components (1.7.3 - 1.7.3) <CAC75CC0-DAD7-3DD3-91CF-DDE8B19DEBDD> /System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio
0x10a1eb000 - 0x10a3a3fff GLEngine (??? - ???) <59179FEC-D0E2-38B3-BD49-765506A645AC> /System/Library/Frameworks/OpenGL.framework/Resources/GLEngine.bundle/GLEngine
0x10a3da000 - 0x10a534fff libGLProgrammability.dylib (??? - ???) <90390984-70BC-365C-AB3E-16C35C4240CB> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib
0x10a566000 - 0x10a594ff7 GLRendererFloat (??? - ???) <06CA5D0B-BC5F-3CC7-836D-A02F7DB92BE8> /System/Library/Frameworks/OpenGL.framework/Resources/GLRendererFloat.bundle/GLRendererFloat
0x10a59d000 - 0x10a5a6ff7 +add-spatter.plug.dylib (??? - ???) <2A6BB16E-E8CB-35FB-9A71-50F681CAAD4A> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/add-spatter.plug.dylib
0x10b000000 - 0x10b4aafef com.apple.driver.AppleIntelGMAX3100GLDriver (7.4.1 - 7.0.4) <E07535EE-C991-3475-9CF6-B52209E26BCA> /System/Library/Extensions/AppleIntelGMAX3100GLDriver.bundle/Contents/MacOS/AppleIntelGMAX3100GLDriver
0x10cfe3000 - 0x10cff5fff +autochop.plug.dylib (??? - ???) <271374F4-4627-36F8-BF5F-48522DF6AC34> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/autochop.plug.dylib
0x10d360000 - 0x10d376fef +3dveins.plug.dylib (??? - ???) <FB49F46E-AB42-37D7-B309-CACBC687CA28> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/3dveins.plug.dylib
0x10d380000 - 0x10d38bff7 +autodump.plug.dylib (??? - ???) <7BB28F82-1288-3567-B4AF-D3073AC11C2B> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/autodump.plug.dylib
0x10d392000 - 0x10d39aff7 +autogems.plug.dylib (??? - ???) <A887A653-D080-3CB1-AA50-6D934B249570> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/autogems.plug.dylib
0x10d39f000 - 0x10d3abfff +autohauler.plug.dylib (??? - ???) <4F464B1C-52B1-3FC8-8750-576C7F8BFECD> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/autohauler.plug.dylib
0x10d3b1000 - 0x10d3c2fe7 +autolabor.plug.dylib (??? - ???) <94903F44-B9BF-3856-A2DA-7723D431AA19> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/autolabor.plug.dylib
0x10d3c9000 - 0x10d3dbfff +automaterial.plug.dylib (??? - ???) <A1DFFFAF-02D6-3F7C-BEC3-460CA07FEC8E> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/automaterial.plug.dylib
0x10d3e4000 - 0x10d3eeff7 +automelt.plug.dylib (??? - ???) <2733AF2A-C0E7-392F-91F0-488F550B3CF2> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/automelt.plug.dylib
0x10d3f4000 - 0x10d3feff7 +autotrade.plug.dylib (??? - ???) <7371E915-0CDD-351F-B4BC-EA2515636370> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/autotrade.plug.dylib
0x10d404000 - 0x10d411ff7 +blueprint.plug.dylib (??? - ???) <AAEABE9E-4518-3E82-9C0F-3F4BB4C9926F> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/blueprint.plug.dylib
0x10d418000 - 0x10d425fe7 +building-hacks.plug.dylib (??? - ???) <6D255C9B-FF9D-340A-8974-7BA6922DA0BA> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/building-hacks.plug.dylib
0x10d491000 - 0x10d4b2fff +buildingplan.plug.dylib (??? - ???) <C6DC65D4-35AB-3E08-931F-FE7D0D82805E> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/buildingplan.plug.dylib
0x10d4c1000 - 0x10d4d0ff7 +burrows.plug.dylib (??? - ???) <8C98EA4F-3118-375A-A7B0-CD2E50FC61A8> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/burrows.plug.dylib
0x10d4da000 - 0x10d4e3ff7 +changeitem.plug.dylib (??? - ???) <0F9F51BA-4323-3074-B561-A8D72784D3B5> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/changeitem.plug.dylib
0x10d4e8000 - 0x10d4f1ff7 +changelayer.plug.dylib (??? - ???) <6C12F5BB-5793-33A6-B488-AA24D18DAAE3> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/changelayer.plug.dylib
0x10d4f6000 - 0x10d4fcff7 +changevein.plug.dylib (??? - ???) <93EAB02C-714F-3A00-AEF9-FDB8ECEEF63A> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/changevein.plug.dylib
0x10d700000 - 0x10d706ff7 +cleanconst.plug.dylib (??? - ???) <9BAB406A-69F9-3539-BA4F-2EE11BDBECC4> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/cleanconst.plug.dylib
0x10d70a000 - 0x10d711ff7 +cleaners.plug.dylib (??? - ???) <1248F386-36F1-3854-BA16-612AD950D5A0> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/cleaners.plug.dylib
0x10d715000 - 0x10d71cfff +cleanowned.plug.dylib (??? - ???) <D1EB4502-7C7C-3A0B-BCCD-50CF7A847287> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/cleanowned.plug.dylib
0x10d720000 - 0x10d72afff +command-prompt.plug.dylib (??? - ???) <86D069CF-8F27-3578-9162-8146A4495D2E> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/command-prompt.plug.dylib
0x10d731000 - 0x10d74aff7 +confirm.plug.dylib (??? - ???) <011EC786-9970-36A6-8D17-37C6FDC21286> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/confirm.plug.dylib
0x10d75b000 - 0x10d764fff +createitem.plug.dylib (??? - ???) <F09B04B6-E663-3D3D-8803-0086C9FDF7C0> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/createitem.plug.dylib
0x10d769000 - 0x10d770ff7 +cursecheck.plug.dylib (??? - ???) <8A340453-E0E5-3555-8793-FABB4EC353B1> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/cursecheck.plug.dylib
0x10d775000 - 0x10d77bff7 +deramp.plug.dylib (??? - ???) <2CADBC7D-1A23-3B8D-BBA2-211FA9F0DF33> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/deramp.plug.dylib
0x10d77f000 - 0x10d791fef +dig.plug.dylib (??? - ???) <EDF3B616-2A9E-3B07-A700-FF323DD9A865> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/dig.plug.dylib
0x10d79a000 - 0x10d7a3fff +digFlood.plug.dylib (??? - ???) <030930C1-86F5-3E47-AD72-A2371752CA3C> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/digFlood.plug.dylib
0x10d7a8000 - 0x10d7baff7 +diggingInvaders.plug.dylib (??? - ???) <0CFF57B2-DF5B-3E13-8DB4-6168226D506E> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/diggingInvaders.plug.dylib
0x10d7c4000 - 0x10d7e8fff +dwarfmonitor.plug.dylib (??? - ???) <14E0C960-E431-3826-B6F5-2E04D55CC213> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/dwarfmonitor.plug.dylib
0x10d7f8000 - 0x10d7fdff7 +title-version.plug.dylib (??? - ???) <E8CA9FBC-0BDE-3C83-B143-855B0865C07E> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/title-version.plug.dylib
0x10da60000 - 0x10da6aff7 +dwarfvet.plug.dylib (??? - ???) <05FB2940-786E-3DB6-8350-2F7824766AD4> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/dwarfvet.plug.dylib
0x10da6f000 - 0x10da7cff7 +embark-tools.plug.dylib (??? - ???) <F287BBBA-71B0-3F73-8C73-1F12C5AE0705> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/embark-tools.plug.dylib
0x10da85000 - 0x10da94fe7 +eventful.plug.dylib (??? - ???) <78E049BC-4F0F-3D0A-A6E5-C3EC564D4697> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/eventful.plug.dylib
0x10db02000 - 0x10db08ff7 +fastdwarf.plug.dylib (??? - ???) <0F187B1B-894F-3716-960F-E0BE9D5236C9> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/fastdwarf.plug.dylib
0x10db0b000 - 0x10db15fff +filltraffic.plug.dylib (??? - ???) <6877E60B-8828-3486-963B-988961E27672> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/filltraffic.plug.dylib
0x10db1a000 - 0x10db27ff7 +fix-armory.plug.dylib (??? - ???) <E63065CC-B798-3473-A16E-12C985FC776E> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/fix-armory.plug.dylib
0x10db2f000 - 0x10db36ff7 +fix-unit-occupancy.plug.dylib (??? - ???) <93DFBDA8-C010-39AE-9985-E4E5039498FE> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/fix-unit-occupancy.plug.dylib
0x10db3b000 - 0x10db43ff7 +fixveins.plug.dylib (??? - ???) <2A82AECF-DA40-392F-A8BB-23970438C983> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/fixveins.plug.dylib
0x10db47000 - 0x10db4dff7 +flows.plug.dylib (??? - ???) <084BFE5D-D578-3D90-BC8E-CF4DE8615CCF> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/flows.plug.dylib
0x10db51000 - 0x10db57fff +follow.plug.dylib (??? - ???) <7BB1E123-E5FE-36F6-A793-7E3B00573F0E> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/follow.plug.dylib
0x10db5b000 - 0x10db64fff +forceequip.plug.dylib (??? - ???) <6CFEA4DF-1C7D-3F17-9FAB-49F2BEE2F4C2> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/forceequip.plug.dylib
0x10db68000 - 0x10db8afef +fortplan.plug.dylib (??? - ???) <44E1630C-3AAB-3355-B7B9-730758D0F1A4> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/fortplan.plug.dylib
0x10db99000 - 0x10dba4ff7 +generated-creature-renamer.plug.dylib (??? - ???) <BCB01B1B-9EC3-367B-A352-F596BF009032> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/generated-creature-renamer.plug.dylib
0x10dba9000 - 0x10dbb1fff +getplants.plug.dylib (??? - ???) <D317A283-75FB-348B-8D5A-0455C3CE5CF2> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/getplants.plug.dylib
0x10dbc2000 - 0x10dbd4ff7 +hotkeys.plug.dylib (??? - ???) <D4D38B12-3D6A-3837-99B7-C5058767BCD9> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/hotkeys.plug.dylib
0x10dbdc000 - 0x10dbe3fff +infiniteSky.plug.dylib (??? - ???) <72B1C3BB-CC58-3131-89F4-4B8E70905BAA> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/infiniteSky.plug.dylib
0x10dbe7000 - 0x10dbf0ff7 +jobutils.plug.dylib (??? - ???) <69CFCDEB-A358-300F-A07C-7DE1B62F267E> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/jobutils.plug.dylib
0x10dbf6000 - 0x10dbfcfff +lair.plug.dylib (??? - ???) <2A2296F7-8C3D-344F-9ABD-8E5DA51C47B8> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/lair.plug.dylib
0x10df00000 - 0x10df14fe7 +isoworldremote.plug.dylib (??? - ???) <D6FCC808-08BB-34DD-86FD-F402FA860191> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/isoworldremote.plug.dylib
0x10df20000 - 0x10df41fe7 +labormanager.plug.dylib (??? - ???) <A59769A4-975F-3C73-A5C8-773B8F9C46B1> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/labormanager.plug.dylib
0x10df4b000 - 0x10df5eff7 +liquids.plug.dylib (??? - ???) <49813051-B0C5-3A1B-BDA1-8A07FCA0F62A> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/liquids.plug.dylib
0x10df67000 - 0x10df77fef +luasocket.plug.dylib (??? - ???) <50C6AA97-5BCA-31A8-BFCF-B0B1B28AFBF3> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/luasocket.plug.dylib
0x10df81000 - 0x10dfa1fef +manipulator.plug.dylib (??? - ???) <D1270917-0F93-3772-8C48-57740E3877FA> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/manipulator.plug.dylib
0x10dfb0000 - 0x10dfb6ff7 +misery.plug.dylib (??? - ???) <78872F53-2830-36FD-A2EA-5F24DA1A198C> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/misery.plug.dylib
0x10dfba000 - 0x10dfc2fff +mode.plug.dylib (??? - ???) <3D0D3A97-4A20-3772-AAD0-5A833637B6C3> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/mode.plug.dylib
0x10dfc6000 - 0x10dfcffff +mousequery.plug.dylib (??? - ???) <A7270621-2419-3A3F-AA0F-FA8BBA396DAF> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/mousequery.plug.dylib
0x10dfd7000 - 0x10e00cff7 +orders.plug.dylib (??? - ???) <0E040385-A117-3A86-BFA1-ECA045268CA9> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/orders.plug.dylib
0x10e020000 - 0x10e026fef +pathable.plug.dylib (??? - ???) <34529DA2-47C2-3F64-97CA-306C3E36DF03> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/pathable.plug.dylib
0x10e02a000 - 0x10e033ff7 +petcapRemover.plug.dylib (??? - ???) <1F6FA963-DE64-30FF-9E44-EF358769B3F4> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/petcapRemover.plug.dylib
0x10e038000 - 0x10e040ff7 +plants.plug.dylib (??? - ???) <22023E6F-B296-30F3-A5F8-0F7AE5C75DFC> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/plants.plug.dylib
0x10e045000 - 0x10e04dfe7 +power-meter.plug.dylib (??? - ???) <B8CD2CCD-45FF-32F0-ACA6-B5A7E14787D4> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/power-meter.plug.dylib
0x10e053000 - 0x10e05fff7 +probe.plug.dylib (??? - ???) <5221A97C-B353-3920-ACBB-5A2FF7478E71> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/probe.plug.dylib
0x10e065000 - 0x10e074ff7 +prospector.plug.dylib (??? - ???) <A5ADA72F-32E7-301D-88C8-3D7F196A36FF> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/prospector.plug.dylib
0x10e07b000 - 0x10e081ff7 +regrass.plug.dylib (??? - ???) <2617CA7C-F563-3CE5-A4D2-1AF23236EA97> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/regrass.plug.dylib
0x10e085000 - 0x10e133fe7 +RemoteFortressReader.plug.dylib (??? - ???) <AB86968A-0266-30CF-A2E4-1A79440FB164> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/RemoteFortressReader.plug.dylib
0x10e188000 - 0x10e19afef +rename.plug.dylib (??? - ???) <68416229-1000-39C1-BF40-FBEC3E2FB59D> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/rename.plug.dylib
0x10e1a5000 - 0x10e1c7fef +rendermax.plug.dylib (??? - ???) <1821B0C2-70E9-343B-A813-E1799131B549> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/rendermax.plug.dylib
0x10e1d6000 - 0x10e1dcfff +resume.plug.dylib (??? - ???) <5B313FCC-4355-361B-B2E6-4BDE6EF5C639> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/resume.plug.dylib
0x10e1e0000 - 0x10e1eafff +reveal.plug.dylib (??? - ???) <9F0ED655-3EFB-307F-9EDB-2C419BEFD2D9> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/reveal.plug.dylib
0x10e1ef000 - 0x10e1fefff +ruby.plug.dylib (??? - ???) <8B7B2CB8-1715-376A-8E1C-4D030DE53425> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/ruby.plug.dylib
0x10e206000 - 0x10e2cdff7 com.apple.ruby (1.8.7.72 - Ruby-1.8.6.287) <FD14B4A3-AA99-334F-A9D8-F46E6136BAB6> /System/Library/Frameworks/Ruby.framework/Ruby
0x10e3e6000 - 0x10e3f3fff +seedwatch.plug.dylib (??? - ???) <7CAE168F-B978-3119-9976-D6B52949600E> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/seedwatch.plug.dylib
0x10e500000 - 0x10e533fe7 +search.plug.dylib (??? - ???) <B9E03427-318D-3101-A647-91775402A3E8> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/search.plug.dylib
0x10e69d000 - 0x10e6a5fff +showmood.plug.dylib (??? - ???) <72E634C6-CBB7-3B9B-BC28-FFD0ABDFEC6B> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/showmood.plug.dylib
0x10e6a9000 - 0x10e6c0ff7 +siege-engine.plug.dylib (??? - ???) <1BE86207-1C4F-3E3B-A986-BD39FDD24BA7> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/siege-engine.plug.dylib
0x10e6ce000 - 0x10e6ddfff +sort.plug.dylib (??? - ???) <9E779188-9EF1-3741-BA7F-1E755E04D12E> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/sort.plug.dylib
0x10e6e4000 - 0x10e6effff +steam-engine.plug.dylib (??? - ???) <E606DC79-52D3-34A4-B7AD-409B1CDB8248> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/steam-engine.plug.dylib
0x10e6f6000 - 0x10e6fcff7 +title-folder.plug.dylib (??? - ???) <B604EBAB-93D5-39E7-88AC-E98536B067B8> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/title-folder.plug.dylib
0x10ee3c000 - 0x10ee46ff7 +stockflow.plug.dylib (??? - ???) <58D23999-5E13-3239-8754-0DC160BE79ED> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/stockflow.plug.dylib
0x10ee4b000 - 0x10eeb1fff +stockpiles.plug.dylib (??? - ???) <E85436A8-6523-32CB-B2F0-59C2ABC362D9> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/stockpiles.plug.dylib
0x10eee6000 - 0x10eef2fff +strangemood.plug.dylib (??? - ???) <F87E14F6-A213-3C60-A1F0-C808EEF9335F> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/strangemood.plug.dylib
0x10f736000 - 0x10f74bfef +stocks.plug.dylib (??? - ???) <F6CB94BF-95F4-3234-93A9-1F3DD0E95C24> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/stocks.plug.dylib
0x10f756000 - 0x10f76aff7 +tiletypes.plug.dylib (??? - ???) <4128A479-C402-3576-A02F-41038C552F27> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/tiletypes.plug.dylib
0x10f773000 - 0x10f77aff7 +trackstop.plug.dylib (??? - ???) <05FB5C89-AAD1-32DE-BD27-23CA62425CBE> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/trackstop.plug.dylib
0x10f77e000 - 0x10f784fff +tubefill.plug.dylib (??? - ???) <82D217AF-6F27-3623-9DFD-307F314EBDFB> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/tubefill.plug.dylib
0x10f7e9000 - 0x10f7eeff7 +workNow.plug.dylib (??? - ???) <B0011F55-2D47-3094-B00B-CEA40EBE38E8> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/workNow.plug.dylib
0x1100c8000 - 0x1100e3ff7 +tweak.plug.dylib (??? - ???) <7EBA892E-E01F-30B7-9579-01A21A4D619B> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/tweak.plug.dylib
0x110600000 - 0x110615fe7 +workflow.plug.dylib (??? - ???) <CE1F21B7-6FBB-38D2-AB43-8B1249B11588> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/workflow.plug.dylib
0x11061f000 - 0x11064afef +zone.plug.dylib (??? - ???) <16FA39CC-36CC-3C13-8296-19114CCC1F0C> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/zone.plug.dylib
0x110804000 - 0x110830ff7 +twbt.plug.dylib (??? - ???) <6266B9C0-EC91-3AE7-B1B5-84EA5EBFEB81> /Applications/Lazy Mac Pack v0.44.05 dfhack-r1/*/twbt.plug.dylib
0x7fff69a67000 - 0x7fff69a9bbaf dyld (195.6 - ???) <C58DAD8A-4B00-3676-8637-93D6FDE73147> /usr/lib/dyld
0x7fff85d42000 - 0x7fff85e37fff libiconv.2.dylib (7.0.0 - compatibility 7.0.0) <5C40E880-0706-378F-B864-3C2BD922D926> /usr/lib/libiconv.2.dylib
0x7fff860a5000 - 0x7fff860bbfff libGL.dylib (??? - ???) <A4876AE9-DDFE-3B9A-874E-09BC29D46C39> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x7fff860bc000 - 0x7fff860bcfff com.apple.CoreServices (53 - 53) <043C8026-8EDD-3241-B090-F589E24062EF> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x7fff860bd000 - 0x7fff860befff libdnsinfo.dylib (395.11.0 - compatibility 1.0.0) <853BAAA5-270F-3FDC-B025-D448DB72E1C3> /usr/lib/system/libdnsinfo.dylib
0x7fff860f1000 - 0x7fff860f2fff liblangid.dylib (??? - ???) <CACBE3C3-2F7B-3EED-B50E-EDB73F473B77> /usr/lib/liblangid.dylib
0x7fff860f3000 - 0x7fff861fdfe7 libcrypto.0.9.8.dylib (0.9.8 - compatibility 0.9.8) <0E7A4F63-035E-3406-AE8C-8F9E3E47D2EE> /usr/lib/libcrypto.0.9.8.dylib
0x7fff8620c000 - 0x7fff8627cfff com.apple.datadetectorscore (3.0 - 179.4) <4AB32B7F-8EC2-327E-BAC8-80129AA36E7B> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
0x7fff8627d000 - 0x7fff862f8ff7 com.apple.print.framework.PrintCore (7.1 - 366.3) <C5F39A82-0E77-3AD6-906A-20DD2EE8D374> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x7fff862f9000 - 0x7fff863acff7 com.apple.CoreText (220.22.0 - ???) <A7A1096F-A211-3775-BA33-08FE98D27F08> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText
0x7fff863ad000 - 0x7fff863c4fff com.apple.MultitouchSupport.framework (231.4 - 231.4) <559C1AFB-E0B4-3D23-9189-18DE09C06FFE> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
0x7fff86c01000 - 0x7fff86c4ffff libauto.dylib (??? - ???) <D8AC8458-DDD0-3939-8B96-B6CED81613EF> /usr/lib/libauto.dylib
0x7fff86c50000 - 0x7fff86c94ff7 com.apple.MediaKit (12 - 602) <0C2CBEDA-412F-3DDF-9C74-44114E5E0DB9> /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit
0x7fff86c95000 - 0x7fff86ca2fff libCSync.A.dylib (600.0.0 - compatibility 64.0.0) <39E20909-68D8-3FB7-A089-A1866618E026> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
0x7fff8744c000 - 0x7fff87452ff7 libunwind.dylib (30.0.0 - compatibility 1.0.0) <1E9C6C8C-CBE8-3F4B-A5B5-E03E3AB53231> /usr/lib/system/libunwind.dylib
0x7fff87453000 - 0x7fff87537ff7 com.apple.CoreServices.OSServices (478.50 - 478.50) <3D6AA4EF-C601-36C7-8F3A-A00964F01759> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x7fff875b7000 - 0x7fff87651ff7 com.apple.SearchKit (1.4.0 - 1.4.0) <4E70C394-773E-3A4B-A93C-59A88ABA9509> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x7fff880e0000 - 0x7fff88134fff libFontRegistry.dylib (??? - ???) <60FF9C2C-5E44-3C49-8A08-F26101898F21> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
0x7fff88135000 - 0x7fff88143fff libdispatch.dylib (187.10.0 - compatibility 1.0.0) <8E03C652-922A-3399-93DE-9EA0CBFA0039> /usr/lib/system/libdispatch.dylib
0x7fff88144000 - 0x7fff8816cfff com.apple.PerformanceAnalysis (1.11 - 11) <8D4C6382-DD92-37A2-BCFC-E89951320848> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
0x7fff88344000 - 0x7fff8834afff IOSurface (??? - ???) <77C6757B-D357-3E34-9424-48F962B5CC9C> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
0x7fff8834b000 - 0x7fff88356fff com.apple.CommonAuth (2.2 - 2.0) <4F5302A5-867A-3F2E-9E4B-98FA011678F8> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
0x7fff88357000 - 0x7fff8835cfff libcache.dylib (47.0.0 - compatibility 1.0.0) <1571C3AB-BCB2-38CD-B3B2-C5FC3F927C6A> /usr/lib/system/libcache.dylib
0x7fff883ca000 - 0x7fff88425ff7 com.apple.opencl (2.0.19 - 2.0.19) <B05BF605-73B8-328F-A228-6FA59E1FC73A> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
0x7fff88452000 - 0x7fff884a4ff7 libGLU.dylib (??? - ???) <DB906997-0F70-3469-BA0E-2F1DDBEAD8D5> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x7fff884f9000 - 0x7fff884fdfff libdyld.dylib (195.6.0 - compatibility 1.0.0) <FFC59565-64BD-3B37-90A4-E2C3A422CFC1> /usr/lib/system/libdyld.dylib
0x7fff88557000 - 0x7fff8855bff7 com.apple.CommonPanels (1.2.5 - 94) <37C6540B-F8D1-355A-806C-F93D8FB522AB> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
0x7fff8855c000 - 0x7fff88b40fff libBLAS.dylib (??? - ???) <C34F6D88-187F-33DC-8A68-C0C9D1FA36DF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x7fff88c23000 - 0x7fff88dc3ff7 com.apple.QuartzCore (1.7 - 270.5) <19E5E0AB-DAA9-3F97-988C-D9A46AFB9C04> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x7fff88dc4000 - 0x7fff88df7ff7 com.apple.GSS (2.2 - 2.0) <C86012C5-B613-3199-B1B3-A1494EE5E43C> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
0x7fff88dfc000 - 0x7fff88e10ff7 com.apple.LangAnalysis (1.7.0 - 1.7.0) <04C31EF0-912A-3004-A08F-CEC27030E0B2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
0x7fff89b55000 - 0x7fff89ba9ff7 com.apple.ScalableUserInterface (1.0 - 1) <33563775-C662-313D-B7FA-3D575A9F3D41> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface
0x7fff89baa000 - 0x7fff89bcefff com.apple.Kerberos (1.0 - 1) <1F826BCE-DA8F-381D-9C4C-A36AA0EA1CB9> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
0x7fff89c15000 - 0x7fff89c16fff libDiagnosticMessagesClient.dylib (??? - ???) <3DCF577B-F126-302B-BCE2-4DB9A95B8598> /usr/lib/libDiagnosticMessagesClient.dylib
0x7fff89e6b000 - 0x7fff89eeefef com.apple.Metadata (10.7.0 - 627.37) <B9BEB598-B6F2-3BFF-A8F3-C3C87CD076AB> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x7fff89eef000 - 0x7fff89efaff7 libc++abi.dylib (14.0.0 - compatibility 1.0.0) <8FF3D766-D678-36F6-84AC-423C878E6D14> /usr/lib/libc++abi.dylib
0x7fff89efb000 - 0x7fff89efcff7 libsystem_blocks.dylib (53.0.0 - compatibility 1.0.0) <8BCA214A-8992-34B2-A8B9-B74DEACA1869> /usr/lib/system/libsystem_blocks.dylib
0x7fff89f8c000 - 0x7fff89f9fff7 libCRFSuite.dylib (??? - ???) <0B76941F-218E-30C8-B6DE-E15919F8DBEB> /usr/lib/libCRFSuite.dylib
0x7fff8a086000 - 0x7fff8a089ff7 com.apple.securityhi (4.0 - 1) <D0ABB03B-CEF9-39E0-A139-AA9484DBBC07> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
0x7fff8a08a000 - 0x7fff8a28cfff libicucore.A.dylib (46.1.0 - compatibility 1.0.0) <0176782F-9526-3905-813A-7A5676EC2C86> /usr/lib/libicucore.A.dylib
0x7fff8a29c000 - 0x7fff8a2f8ff7 com.apple.HIServices (1.21 - ???) <B012EE97-D1CD-3F4B-812D-9AC7E6852FE6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
0x7fff8a2f9000 - 0x7fff8a339fe7 libGLImage.dylib (??? - ???) <0B7DAB2B-F1C6-39C7-B864-61EF683B6656> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x7fff8a390000 - 0x7fff8a46dfef libsystem_c.dylib (763.13.0 - compatibility 1.0.0) <41B43515-2806-3FBC-ACF1-A16F35B7E290> /usr/lib/system/libsystem_c.dylib
0x7fff8a83f000 - 0x7fff8a8d5ff7 libvMisc.dylib (325.4.0 - compatibility 1.0.0) <642D8D54-F9F5-3FBB-A96C-EEFE94C6278B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x7fff8a8d6000 - 0x7fff8a92eff7 libTIFF.dylib (??? - ???) <CF2005B6-5C29-3DCF-BDC2-7DB114ECD7A1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x7fff8aab1000 - 0x7fff8aab1fff com.apple.Accelerate.vecLib (3.7 - vecLib 3.7) <C06A140F-6114-3B8B-B080-E509303145B8> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x7fff8aacf000 - 0x7fff8b6d5fff com.apple.AppKit (6.7.5 - 1138.51) <44417D02-6123-3FC3-A119-CE51BB4C3006> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x7fff8b6ff000 - 0x7fff8b929fe7 com.apple.CoreData (104.1 - 358.14) <6BB64605-8DA7-337D-A2AB-A3346A421CBD> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
0x7fff8b969000 - 0x7fff8b992fff com.apple.CoreVideo (1.7 - 70.3) <9A9D4058-9935-3B0A-B1A6-27EB78D02249> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
0x7fff8b993000 - 0x7fff8b99cff7 libsystem_notify.dylib (80.1.0 - compatibility 1.0.0) <A4D651E3-D1C6-3934-AD49-7A104FD14596> /usr/lib/system/libsystem_notify.dylib
0x7fff8bacd000 - 0x7fff8bde6fff com.apple.Foundation (6.7.2 - 833.25) <22AAC369-B63C-3C55-8AC6-C3ECBA44DA7B> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x7fff8bde7000 - 0x7fff8be52ff7 com.apple.framework.IOKit (2.0 - ???) <FE838BB6-D42E-3291-A1A0-6F53FC970261> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x7fff8be53000 - 0x7fff8bef4ff7 com.apple.LaunchServices (480.42 - 480.42) <A69F9426-05CE-3312-89FD-BC063DA66DBF> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x7fff8bf39000 - 0x7fff8c017fff com.apple.DiscRecording (6.0.4 - 6040.4.1) <F434B351-AE30-3D1B-9DAF-4581D080D2BC> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording
[…]
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 2
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 10535
thread_create: 0
thread_set_state: 0
VM Region Summary:
ReadOnly portion of Libraries: Total=198.1M resident=115.3M(58%) swapped_out_or_unallocated=82.8M(42%)
Writable regions: Total=714.3M written=610.3M(85%) resident=629.6M(88%) swapped_out=0K(0%) unallocated=84.8M(12%)
REGION TYPE VIRTUAL
=========== =======
(null) (reserved) 40K reserved VM address space (unallocated)
CG backing stores 6572K
CG image 12K
CG raster data 64K
CG shared images 3576K
CoreGraphics 16K
CoreServices 4432K
MALLOC 647.2M
MALLOC guard page 64K
MALLOC_LARGE (reserved) 2728K reserved VM address space (unallocated)
Memory tag=242 12K
Memory tag=249 156K
Memory tag=251 8K
STACK GUARD 56.0M
Stack 12.1M
VM_ALLOCATE 16.2M
__CI_BITMAP 80K
__DATA 57.4M
__IMAGE 528K
__LINKEDIT 57.6M
__TEXT 140.5M
__UNICODE 544K
mapped file 39.6M
shared memory 360K
=========== =======
TOTAL 1.0G
TOTAL, minus reserved VM space 1.0G
Version 6.34 is available for 0.44.05-r1.What are the changes to the previous version?
What specific offset? If you mean "missing display patch" that is a harmless warning.
#if defined(DF_03411)
#ifdef WIN32
void (_stdcall *_render_map)(int) = (void (_stdcall *)(int))(0x008f65c0+(Core::getInstance().vinfo->getRebaseDelta()));
#define render_map() _render_map(0)
#elif defined(__APPLE__)
void (*_render_map)(void *, int) = (void (*)(void *, int))0x0084b4c0;
#define render_map() _render_map(df::global::map_renderer, 0)
#else
#error Linux not supported yet
#endif
What specific offset? If you mean "missing display patch" that is a harmless warning.
Sorry I wasn't very clear. I'm talking about version 4.61, I know that works for win32 0.34.11-r5.
What specific offset? If you mean "missing display patch" that is a harmless warning.
Sorry I wasn't very clear. I'm talking about version 4.61, I know that works for win32 0.34.11-r5.
I think it's easier to take the last 32bit version (I think it's 5.70), find missing addresses as described in PATCHES.md and try to compile for 0.34.11, fixing errors due to df structures changes.
So, somebody recommended I suggest this on the forum thread -- are there plans to support a separate font for the embark screen/civilization map the same way there's a separate font for text and terrain? At the moment, the world map uses the same font as the text does, which means that text fonts have to be a bit of a compromise if you want one that looks good as a map (this is based on this reddit thread (https://www.reddit.com/r/dwarffortress/comments/85u542/introducing_runeset_the_ultimate_mapmaker_font/?st=jf1fwz9g&sh=eddec3a3)).
So, somebody recommended I suggest this on the forum thread -- are there plans to support a separate font for the embark screen/civilization map the same way there's a separate font for text and terrain? At the moment, the world map uses the same font as the text does, which means that text fonts have to be a bit of a compromise if you want one that looks good as a map (this is based on this reddit thread (https://www.reddit.com/r/dwarffortress/comments/85u542/introducing_runeset_the_ultimate_mapmaker_font/?st=jf1fwz9g&sh=eddec3a3)).
i support it too!So, somebody recommended I suggest this on the forum thread -- are there plans to support a separate font for the embark screen/civilization map the same way there's a separate font for text and terrain? At the moment, the world map uses the same font as the text does, which means that text fonts have to be a bit of a compromise if you want one that looks good as a map (this is based on this reddit thread (https://www.reddit.com/r/dwarffortress/comments/85u542/introducing_runeset_the_ultimate_mapmaker_font/?st=jf1fwz9g&sh=eddec3a3)).
Just adding that I too support that idea, considering that I made a map-only tileset as well.
I think redrawing is something that TWBT is doing anyway, and the "redraw all" command just makes it redraw more often than it normally does. Maybe the redraw all command isn't directly responsible for the crashes; maybe it just increases the chances for the crash condition to occur.
I've already explained somewhere here, redraw_all makes it redraw all the tiles and not just with changed tile numbers/colours. I don't know why it crashes for farm plots, but in general it does all the processing on another thread which isn't very good, but doesn't slow down simulation and wasn't causing problems before. Probably reprocessing ALL tiles makes it more likely to crash. Or maybe it's something completely different.
Anyway, I'll try looking into this crash but then I'll take a break and think about rewriting TWBT because there's a number of things that I can't fix without architecture changes (namely, support for multiple GPU textures to get rid of the tilesheet limit, support for overriding all building tiles, optimisations, and eliminating of the possibility of the said thread synchronisation issues). I don't mean the break will necessarily be long but rather that I'll not make fixes or add new features to the current implementation.
So what exactly needs to be done to update this for new versions of df/dfhack?Asking mifki nicely usually gets it done pretty quickly, but he's pretty good about keeping it updated.
also, any chance we can get the release zip folder structure matching what it should be so we can just drop it into the DF folder?I like the simple layout so I'm not having to open a bunch of nested folders to drag out the file.
I keep having to guess where to put the files.
Darn work. Don't employers know that there's Dwarf Fortress utilities to be made?
RiverRampE, RiverRampN, RiverRampNE, RiverRampNW, RiverRampS, RiverRampSE, RiverRampSW, RiverRampW
Is it possible to introduce such a distinction for all types of ground ramps?
Would it be possible for TwbT to export a function for turning on text mode with a possible need to reset the text mode when done for usage by DFHack scripts to allow those to produce their output as "real" text?There's already a "map" parameter to DFHack drawing functions that TWBT can use to distinguish between drawing to the map and drawing text. The latter is the default. I'm not sure what issues you're thinking of here.
My thought is that DFHack would export a function that did nothing if TwbT wasn't active, and would enable/reset text mode when TwbT was present. One usage of this would be to have the various DFHack widgets that produce text have their rendering functions enable text at the start and reset it at the end.
:You're completely correct, and I'm barking up the wrong tree up the creek without a paddle.Would it be possible for TwbT to export a function for turning on text mode with a possible need to reset the text mode when done for usage by DFHack scripts to allow those to produce their output as "real" text?There's already a "map" parameter to DFHack drawing functions that TWBT can use to distinguish between drawing to the map and drawing text. The latter is the default. I'm not sure what issues you're thinking of here.
My thought is that DFHack would export a function that did nothing if TwbT wasn't active, and would enable/reset text mode when TwbT was present. One usage of this would be to have the various DFHack widgets that produce text have their rendering functions enable text at the start and reset it at the end.
Version 6.42 is available.Does it include Japas recent changes?
twbt-6.42-win.zip is missing twbt plugin, it only has mousequery.
Edit: also the description says "Support for DF/DFHack-0.44.09-r1" but the tag is the patch for 0.44.10 (https://github.com/mifki/df-twbt/commit/822b3df3bb8f308405a3935c16805df1ae13fda3).
reproducible crashes.
You need a higher resolution. 1920/80=24. Your width is 1920, DF has a minimum of 80 tiles width. With a 32x32 tileset like mine, you should use at least a vertical resolution of 2560.Vertical -> horizontal, to avoid confusion.
You can try right clicking the DF.exe and click on"Disable Display Scaling on High DPI Settings" and try again.
My mistake, sorry.You need a higher resolution. 1920/80=24. Your width is 1920, DF has a minimum of 80 tiles width. With a 32x32 tileset like mine, you should use at least a vertical resolution of 2560.Vertical -> horizontal, to avoid confusion.
You can try right clicking the DF.exe and click on"Disable Display Scaling on High DPI Settings" and try again.
Why it's not working?
Overrides for material-specific walls at all.
P.S.:
Smooth walls are working.
"Probe" command?
diff --git a/patches.hpp b/patches.hpp
index 9c3a7ac..12a56ca 100644
--- a/patches.hpp
+++ b/patches.hpp
@@ -1210,7 +1210,26 @@ static void apply_patch(MemoryPatcher *mp, patchdef &p)
static patchdef p_render_lower_levels = {
0x1099fd0, 5, true, { 0x41, 0xc6, 0x00, 0x00, 0xc3 }
};
- #endif
+ #endif
+
+#elif defined(DF_04411)
+ #ifdef WIN32
+ #define A_LOAD_MULTI_PDIM 0x140aeaae0
+ #define A_RENDER_MAP 0x1408b9830
+ #define A_RENDER_UPDOWN 0x1406005d0
+
+ static patchdef p_display = { 0x1403a0d2b, 5 };
+
+ static patchdef p_dwarfmode_render = { 0x14035601a, 5 };
+
+ static patchdef p_advmode_render[] = {
+ { 0x14029c6cb, 5+5 }, { 0x14029c71c, 5+5 }, { 0x14029c766, 5+5 }, { 0x14029cc33, 5+5 }
+ };
+
+ static patchdef p_render_lower_levels = {
+ 0x140c37650, 9, true, { 0x48, 0x8b, 0x44, 0x24, 0x28, 0xc6, 0x00, 0x00, 0xc3 }
+ };
+ #endif
#else
#error Unsupported DF version
Windows 64 only, dwarf mode displays correctly (for what I've seen) and it does not crash immediately. I might try to do Linux 64 later.
/home/username/DF/dfhack_compile/4303/DF4303/df_linux/hack/plugins/twbt.plug.so: undefined symbol: _ZN6DFHack12findEnumItemERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiPKPKc
The "__cxx11" part indicates that the plugin is trying to use the C++11 ABI. Can you confirm whether TWBT itself is being compiled with "-D_GLIBCXX_USE_CXX11_ABI=0" (look at the make output)? CFLAGS probably won't work, because TWBT is written in C++ - try CXXFLAGS, maybe?The size is entirely arbitrary and can depend on many factors - there isn't a "right" size. Why doesn't it work? Anything in stderr.log?
Adding CXXFLAGS += "-D_GLIBCXX_USE_CXX11_ABI=0" after CFLAGS into makefile for twbt.plug.so results in another twbt.plug.so that doesn't work and is 8% too small.
Adding it to plugins' makefile does result in it appearing in output...of failure (note that it didn't appear in the output for main twbt5.7 make inst):That's a linker command, where -D arguments will do nothing. Can you paste the full make output? Alternatively, you should see the -D argument in the same command that's compiling .hpp/.cpp files.Spoiler: make inst in 5.7/plugins (click to show/hide)
Also question: I'm not sure what other angle I can answer from it if my last edit to previous post didn't answer it. Being sieged by undead is major part of the fort, and .04 combat changes change their nature?I missed that part of your last post, sorry. I wasn't aware of combat changes in 0.43.04. Is that a reported bug or something?
What settings did you set in init.txt? I don't think overrides make a difference.
It seems that whenever I try to embark with LNP 0.44.12-r01 with TWBT and Phoebus, DF crashes (i.e. the window just disappears, as DF crashes tend to result in when DFHack is used). Changing Print Mode to STANDARD seems to allow embarking. Curiously, I've had no issues with continuing fortresses (my old one, as well as a few DFFD bug investigation ones). I haven't yet tried to embark with STANDARD, save, and then try to play with TWBT.
Since it seems to be consistent, is there any investigation I can do to try to track down the issue? I've tried looking in the various log files in the DF directory without seeing anything I find suspicious.
On the off chance that it isn't reproducible on your end (with 68 and above as the vertical screen size), I'm happy to test things you suggest.
125*95 happens to be a size I'm happy with. I grew tired of resizing the window every time I started DF, and since the functionality is there to get the window to have the desired size from the start I decided to use it. I can use resizing as a work around, of course, in particular if it only is for the embark.On the off chance that it isn't reproducible on your end (with 68 and above as the vertical screen size), I'm happy to test things you suggest.
It doesn't crash so far, I'll test more. But why do you need to specify the exact size in init.txt? What if you just leave the default zeroes and resize the window as you want it afterwards?
There is no limit on overrides, but all textures combined should stay below 4096x4096 pixels.Hmm... Why It's not working?
I'm sure it was already offered, but none the less.
What if add support of different sizes of creatures sprites?
No this hasn't been proposed before (or I don't remember), but I was thinking about it - not only for creatures - and I'd like to do it.
The main problem is that before starting to work on it I'd want to be sure it 1. will get artists' support (I guess no problem with this), 2. will look good/won't hurt gameplay/will be accepted by players. It looks ok on bare ground in your examples, but can you make an example image with a real map/other objects around?
Also, remember/seen this? http://www.bay12forums.com/smf/index.php?topic=138754.msg7390751#msg7390751Saw many times, but only after you pointed out, I noticed that there is a multi-tile furniture)
I think they shouldn't extend downwards, like the 3x3 demon. Rather have the actual creature tile be the center-tile at its feet.
That way he still fits corridors, while looming over the Wall above him.
Same for hydra, cyclops and ettin.
This feature would also fit perfectly for items/bodyparts that are a bit larger... Like pikes or spears, Horns and tails.
And for giant-versions of animals. And it would give Players more info in one view = the creatures size. :-)
The question is, will we paint/design new sprites with the fitting size, or will twbt upscale the 32x32 sprites into new dimensions? Because after all, the creature tiles are still in a square grid in their graphics files.I hope that there will be separate .png files with each size category. It is understood that each creature will be processed in Photoshop separately with an individual scale - someone will be stretched to 120%, someone at 230%, - simple twbt upscale command can not do here. First, there will be a rough scaling, then there may be a redrawn sprites in the light of a larger area to draw - for example, an elephant, I did not just stretch it.
print-twbt-override is not part of dfhack or twbt. Except if someone has made a better version of it, you can find my old script here (https://gist.github.com/cvuchener/c176e7d0bee18e5c6c75c7ac5bded6f7) (don't trust it too much, it does not always choose the best id).He should have it, if he uses my tileset to look up things.
For those unfamiliar with the issue above: http://www.bay12forums.com/smf/index.php?topic=126076.msg7830622#msg7830622thank you. i have to bookmark that post.
and my response in the DFHack thread: http://www.bay12forums.com/smf/index.php?topic=164123.msg7848474#msg7848474
Try this:The problem was in a quantity of my overrides. TWBT needs loading screen.
[TILESET:TIER_5.png:TIER_5.png:tier5]
[OVERRIDE:234:B:STATUE:Statue::tier5:R:11:0:1:2:3:4:5:6:7:8:9:10:::INORGANIC:SANDSTONE]
[OVERRIDE:239:B:SLAB:Slab::tier5:R:5:11:12:13:14:15:::INORGANIC:SANDSTONE]
[OVERRIDE:234:B:STATUE:Statue::tier2:R:11:44:45:46:47:48:49:50:51:52:53:54]
[OVERRIDE:239:B:SLAB:Slab::tier2:R:5:55:56:57:58:59] - Why this crash entire game?
The version you posted shouldn't crash the game though, no idea why it would do that. Worst that should happen is no overrides for the sandstone statue/slab.
The problem was in a quantity of my overrides. TWBT needs loading screen.
Английский, к сожалению, не мой родной язык.The problem was in a quantity of my overrides. TWBT needs loading screen.
What exactly does it mean?
Английский, к сожалению, не мой родной язык.The problem was in a quantity of my overrides. TWBT needs loading screen.
What exactly does it mean?
Я провёл небольшое исследование и заметил связь вылетов и нагрузки на процессор во время загрузки текстур. Если нагрузка становится выше критической, то включается функция поиска зависающих приложений. DF не даёт отчёта (интро идёт после загрузки текстур), система паникует и вырубает DF.
Когда текстур 10-20 это не заметно, но если их тысячи?
Unfortunately, English isn't my naive language.
I did a small research and did notice a correlation between crashes and CPU usage when the textures are loading. If the CPU usage exceeds some critical boundary, a [OS] function starts, which looks for hanging applications. DF doesn't react [to OS request] (intro starts after texture loading), the OS panics and shuts DF down.
When there are 10 to 20 textures, it [the loading time] isn't noticeable, but what if there are 1000s of them?
I have slightly different experiences. When I first load a map (start a new fort, load a save, etc), the game hangs for 1-2 seconds (Windows claims it's unresponsive), but then proceeds as if nothing happened. It doesn't crash because of this, just hangs for a tiny bit.same. it even hangs for up to 5 seconds when embarking or loading a savegame in fortress mode. during that time if i hadnt closed DF completely, it shows the last screen TWBT showed (the latest active fort).
Bug report: I'm designing a tileset and I want to use some graphics from the default text tileset as placeholders for a release. If I create an override that uses the default 'text' tileset, DF silently crashes whenever these overridden tiles come into view.
Will be fixed in the next build.
E: NoMethodError: undefined method 'onstatechange' for DFHack:Module
eval:1:in '<main>'
Here are some examples of what you can do with Japas changes, just so you know the ingame effect it can have:This is just wow. Didn't expect it to get this far :).Spoiler: animated water (click to show/hide)Spoiler: animated semi-molten rock (click to show/hide)Spoiler: animated soap maker (click to show/hide)Spoiler: varied bars/blocks (click to show/hide)Spoiler: varied rock walls and boulders (click to show/hide)
Suffice to say, I'd really love to see these additions being maintained for future updates. ;)
Is there a way to debug twbt while running DF? I experience random CTDs while using Mephs tileset and they don't seem to be related to anything I do. Interestingly they dont happen if I turn display mode to standard deactivating twbt and I did not experience one if I turn redraw_all to 0 (but this can be a coincidence). stderr.log and all other output files do not mention anything after crashing.
[OVERRIDE:43:T:ConstructedFloor:_MDF_overrides_7:109::::INORGANIC:GOLD]
Will TWBT continue to be developed after the release of the "new" version of DF?
Will TWBT continue to be developed after the release of the "new" version of DF?
Tarn himself does the coding. No one else has access to the source code. Kitfox only does bureaucratic and PR things.that would be absolutely ACE!
For things like animations, which might be a bit of a stretch due to the high number of sprite, my hope is to convince Tarn to at least add the capabilities, and let the community figure out the rest.
Tarn himself does the coding. No one else has access to the source code. Kitfox only does bureaucratic and PR things.
The development of graphical DF is in too early phase now. TWBT gives more graphical content than "new" version. It don't have overrides and multilevel. There are so many tilesets are depending on TWBT. Please, don't stop updating.Tarn himself does the coding. No one else has access to the source code. Kitfox only does bureaucratic and PR things.
This worries me now. When I though someone experienced with creating modern game UI was going to do that, I was more confident it would be done, well, in a modern way and would include all the features we want. Partly because of the said experience, partly because it wouldn't take time from the game development itself and thus not be restricted by the time available.
I'll list all TWBT features again, can you tell which ones you have discussed with Tarn for inclusion in the new engine already? Or maybe the list will remind you to talk to him about something.
* Separate map/text tileset. Always requested but never implemented is a separate world map tileset.
* Multilevel rendering. On desktop, the top X levels are rendered and visible on screen. On iOS, all levels are visible but only the top X levels are updated, the others are shown in grayscale to indicate the tiles may be outdated.
* Overrides to display individual tiles for item types, subtypes and materials, with some support for animation and randomisation.
* Multilayer rendering - items, buildings and creatures have transparency and rendered on top of the ground tiles, not instead of them. Currently two layers only, ideally need to handle creatures on top of buildings (on top of the floor).
* Support for only parts of tiles to have material colour and parts have constant colour.
* Minor, but there's an option to hide stockpile backgrounds unless in [q], [p] or [k] modes.
* Exporting full size screenshot of fortress map as it's rendered by TWBT. Mentioning this because DF currently have map export, so that will need to be updated too.
Hey! Some of those features are already in the trailer, right?
I'm not a graphics guru by any stretch, but I read through and basically understand the SDL code, then produced the transparency/edging/etc. features that we have so far. I'll also be able to decouple the grid, do the fonts, etc. etc. There might be some bumps, but I think it's premature to panic.
edit: and when I say "do the fonts", I don't mean draw them myself, ha ha ha. Support. Support the text apart from the graphics with different grid sizes. Not sure I want to dive into more true type stuff, since that has been iffy and isn't my realm.
Every surface there was already allocated separately; the atlas is long gone apparently, and there isn't any large-scale swapping or binding. It just blits separate little surfaces from a non-texture-atlas catalog by index and coloration.
My plan is to release all of my code changes, just as I've been doing up to this point. The free Dwarf Fortress Classic Linux version will have the same folder as usual
Ok sorry then I got confused by your old statements (that you could not make changes to libgraphics because you didn't understand it or something else).
Every tile is drawn separately? Now I'm worried again because doing many drawing calls is one thing that's VERY bad with OpenGL. Of course it will work but at a cost of enormous CPU usage (which possibly will cause other problems with time).
That's great. Btw, what's the reason libgraphics is a separate binary on Linux only and compiled in on other platforms? If it were separate on all platforms, we could make changes/optimisations to it even without DFHack (as long as they don't need any additional game data of course).
Looks really like DF in agony now.TWBT is dead, DFHack is probably too, utilites and tilesets too. Terrifying.What?
This is how it works in the currently released version people play now. I'm not sure how the SDL blits work down where they hit OpenGL, and yeah, I'd anticipate them to be slow (given how texture binds have worked in my own side projects not in SDL), but I'm not changing it too much from how it currently works, and it's pretty fast there? Or has 44.12 been having trouble on some cards?
I just don't know how to set up a DLL properly on windows... I'm really tired right now (sorry! no sleep!) but there was some part of that which was quite irritating to get hooked up. On OSX I know absolutely nothing. For the process of the original ports, just getting it working on one OS was sufficient for everybody to work without having to see the rest of the code.
If the issue is that the current code is viewed as simply unfit for sale due to possible backlash, well, that's true of the entire game - it's a weird critter and people will have plenty of time to set their expectations based on what we've done for the last many years; we're going to improve it as well as we can with our resources before launch.
Yeah, I'm fine with doing a DLL if it works and isn't a long project, though the words "circular dependencies" fill me with some dread, ha ha ha.
Sorry if this post was a bit doom and gloom Toady, but I just wanted to share some brief fiscal talk while you were on the topic, not that im a expert or anything but i guess next time you meet up it'll give you some points to raise and check over.
Some buildings, like roads, civzones and bridges I consider to be "ground" tiles and are not transparent intentionally. While some others may be left out because I forgot about them, so let me know if there are buildings that need to be added to the list.Pls make everything may be transparent. The same glass and ice walls and floors, grates, grass would look much better with transparent and translucent areas.
note: the second occurance has a hash behind it that seems to be related to the dfhack commit versionYeah, it's the commit hash. It's the same for all builds of DFHack 0.44.12-r3, so you don't need to check stderr.log on other platforms. You don't really need to change this, though - only the first one is necessary for DFHack to load the plugin (the second will trigger a warning only).
- fresh install should say 0.44.12-r2-0-g315852a2
- alter this to 0.44.12-r3-0-g82f082d7 (for windows x64, if you use a different version, start up the game with the old TWBT plugin and new DFHACK, type die once the game started and you saw the error in the logfile and then check the file stderr.log in the dwarf fortress folder. the first line should look like this: DFHack build: 0.44.12-r3-0-g82f082d7. This is what you need to paste in the TWBT plugin)
Does anyone have any suggestions on a way to hack this to work on mac?It already supports macOS (and I've used it there): https://github.com/mifki/df-twbt/releases
Any idea if TWBT will be able to use overrides for the new Altar and Dice item_tools?Altars are implemented essentially the same way as bookshelves no? In that case they should.
Now that we have a great new dfhack update, looks like twbt is unhappy again. Any chance of a twbt update? or being so close to the next DF version, are we just going to wait it out? or is there a hack to get it to play nicely with r3?I hope so.. It'd be sad if r3 was sorta a lost version, without twbt..
You can also just use their tool id instead of numbers.Yes, please do this. The numeric IDs can change if people are using mods.
Hello,
Is there a way for TWBT v6.61 could work with DFHACK 0.47.XX? I have tried to copy files into data folder (in Peridexis Errant version) and when DFHACK runs, it says: "Plugin twbt was not built for this version of DFHack".
Shouldn't be to hard (even if a quick hack as a dfhack-init script). Just change the "using graphics" value. I'm too drunk to remember where it is but "gui/gm-editor df.global.ui" might show it...Can anyone give me a bit more direction than this? I'm still kinda lost on how to fix this.. Changing the graphics state doesn't seem to help, even if it's just for those screens, it seems to use text for either mode, while twbt is enabled.
This is what i see when i try to launch DF with the LNP and TWBT activated.
https://imgur.com/VQ37BuE
I can only seem to play it with print set to 2D. Anyone knows what it could be?
This is what i see when i try to launch DF with the LNP and TWBT activated.
https://imgur.com/VQ37BuE
I can only seem to play it with print set to 2D. Anyone knows what it could be?
Graphics drivers or lack of them
# Bookcases TODO
[OVERRIDE:240:B:BOOKCASE:::map:227:16:1::PLANT:TOWER_CAP:WOOD]
[OVERRIDE:240:B:BOOKCASE:::map:227:15:1::PLANT:FUNGIWOOD:WOOD]
[OVERRIDE:240:B:BOOKCASE:::map:227:7:1:WOOD]
[OVERRIDE:240:B:BOOKCASE:::map:227:9:1:IS_STONE]
[OVERRIDE:240:I:TOOL:TOOL:ITEM_TOOL_BOOKCASE:map:227:16:1:WOOD:PLANT:TOWER_CAP:WOOD]
[OVERRIDE:240:I:TOOL:TOOL:ITEM_TOOL_BOOKCASE:map:227:15:1:WOOD:PLANT:FUNGIWOOD:WOOD]
[OVERRIDE:240:I:TOOL:TOOL:ITEM_TOOL_BOOKCASE:map:227:7:1:WOOD]
[OVERRIDE:240:I:TOOL:TOOL:ITEM_TOOL_BOOKCASE:map:227:9:1:IS_STONE]
# Doors TODO
[OVERRIDE:186:B:DOOR:::map:197:16:1::PLANT:TOWER_CAP:WOOD]
[OVERRIDE:186:B:DOOR:::map:197:15:1::PLANT:FUNGIWOOD:WOOD]
[OVERRIDE:186:B:DOOR:::map:197:7:1:WOOD]
[OVERRIDE:186:I:DOOR:::map:197:16:1:WOOD:PLANT:TOWER_CAP:WOOD]
[OVERRIDE:186:I:DOOR:::map:197:15:1:WOOD:PLANT:FUNGIWOOD:WOOD]
[OVERRIDE:186:I:DOOR:::map:197:7:1:WOOD]
# Hatches TODO
[OVERRIDE:155:B::::map:155:16:1::PLANT:TOWER_CAP:WOOD]
[OVERRIDE:155:B::::map:155:15:1::PLANT:FUNGIWOOD:WOOD]
[OVERRIDE:155:B::::map:155:7:1:WOOD]
[OVERRIDE:155:B::::map:155:16:1:BONE]
[OVERRIDE:155:I::::map:155:16:1:WOOD:PLANT:TOWER_CAP:WOOD]
[OVERRIDE:155:I::::map:155:15:1:WOOD:PLANT:FUNGIWOOD:WOOD]
[OVERRIDE:155:I::::map:155:7:1:WOOD]
[OVERRIDE:155:I::::map:155:16:1:BONE]
- For objects that aren't in the raws (such as doors), I can't change the image of the object being carried on its way to being constructed. I figured out this was an ACTIVITY_ZONE, but I can't specify building types or materials, so that I can choose the right tiles and colors.
Is it possible to use a truetype font for text and a tileset for everything else, while still using TWBT and getting it's other features?Unfortunately not. Truetype is only supported in non-OpenGL print modes (e.g. PRINT_MODE:2D), and TWBT requires OpenGL (PRINT_MODE:TWBT is treated as STANDARD by DF).
I've been tested pre-release for 0.47.04 and found that random don't want to work on workshops.A pre-release of DFHack or TWBT? (This is the TWBT thread.)
https://github.com/thurin/df-twbt/releases/tag/0.47.04-r1I've been tested pre-release for 0.47.04 and found that random don't want to work on workshops.A pre-release of DFHack or TWBT? (This is the TWBT thread.)
What is "random"?
https://github.com/thurin/df-twbt/releases/tag/0.47.04-r1Oh, ok, I didn't know TWBT had that feature. (DFHack has a couple features with names like "random" too.) Thanks for clarifying.
Random sprites function, as like [OVERRIDE:111:B:WORKSHOP_STILL:Workshop::03:R:2:82:83:::IS_STONE]
twbt.plug.dll:00007FFA1EECCE67 sub ecx, r9d
twbt.plug.dll:00007FFA1EECCE6A js short loc_7FFA1EECCEC4
twbt.plug.dll:00007FFA1EECCE6C movsx eax, word ptr [rbx+0AAh]
twbt.plug.dll:00007FFA1EECCE73 mov r8d, cs:dword_7FFA2098573C
twbt.plug.dll:00007FFA1EECCE7A sub eax, r8d
twbt.plug.dll:00007FFA1EECCE7D js short loc_7FFA1EECCEC4
twbt.plug.dll:00007FFA1EECCE7F cmp ecx, [rdi+0D8h]
twbt.plug.dll:00007FFA1EECCE85 jge short loc_7FFA1EECCEC4
twbt.plug.dll:00007FFA1EECCE87 mov edx, [rdi+0DCh]
twbt.plug.dll:00007FFA1EECCE8D cmp eax, edx
twbt.plug.dll:00007FFA1EECCE8F jge short loc_7FFA1EECCEC4
twbt.plug.dll:00007FFA1EECCE91 movsx eax, word ptr [rsp+32h]
twbt.plug.dll:00007FFA1EECCE96 movsx ecx, word ptr [rsp+30h]
twbt.plug.dll:00007FFA1EECCE9B sub ecx, r9d
twbt.plug.dll:00007FFA1EECCE9E imul ecx, edx
twbt.plug.dll:00007FFA1EECCEA1 sub ecx, r8d
twbt.plug.dll:00007FFA1EECCEA4 add eax, ecx
twbt.plug.dll:00007FFA1EECCEA6 cdqe
twbt.plug.dll:00007FFA1EECCEA8 lea rdx, ds:0[rax*4]
twbt.plug.dll:00007FFA1EECCEB0 mov rax, cs:qword_7FFA20985718
twbt.plug.dll:00007FFA1EECCEB7 mov ecx, [rdx+rax] ;fires exception here
twbt.plug.dll:00007FFA1EECCEBA mov rax, cs:qword_7FFA1FD85700
twbt.plug.dll:00007FFA1EECCEC1 mov [rdx+rax], ecx ;or fires it here
i.e. when it tries to copy from one array to another. At the moment when it fires exception 0xC0000005, rdx stores negative value big enough for further instructions to try to access memory out of data segments.I've been working with Meph's tileset and TWBT to try and learn to make tiles in advance for the Steam version. For some reason, my ankylosaur tiles appear with a black background ingame, while my alvarezsaurs are properly transparent. Why is this?Spoiler (click to show/hide)
I've been working with Meph's tileset and TWBT to try and learn to make tiles in advance for the Steam version. For some reason, my ankylosaur tiles appear with a black background ingame, while my alvarezsaurs are properly transparent. Why is this?Spoiler (click to show/hide)
I found a few nice dino sprites that might help.Spoiler (click to show/hide)
The TWBT unit transparency doesn't work if the creature is standing on the same tile as another object that uses transparency. Maybe that was the issue. And mind that your sprites can be up to 96x96 for the Steam version, in case you want larger dinos. :)
[TILESET:bridge2.bmp:bridge2.bmp:6]
[OVERRIDE:205:B:BRIDGE:::6:4] lr =
[OVERRIDE:186:B:BRIDGE:::6:4] ud ||
[OVERRIDE:187:B:BRIDGE:::6:2] ur
[OVERRIDE:200:B:BRIDGE:::6:6] dl
[OVERRIDE:188:B:BRIDGE:::6:8] br
[OVERRIDE:201:B:BRIDGE:::6:0] ul
[OVERRIDE:43:B:BRIDGE:::6:4] floor
https://github.com/thurin/df-twbt/releases/tag/0.47.04-r1I've been tested pre-release for 0.47.04 and found that random don't want to work on workshops.A pre-release of DFHack or TWBT? (This is the TWBT thread.)
What is "random"?
https://dffd.bay12games.com/file.php?id=15160
Random sprites function, as like [OVERRIDE:111:B:WORKSHOP_STILL:Workshop::03:R:2:82:83:::IS_STONE]
... and get this message when DFHack starts:make sure there is a twbt.plug.dll in your "Dwarf Fortress/hack/plugins" folder. If not, you will need one, compiled for your dfhack version. I think the easiest way to get them in sync is to take a Lazy Newb Pack.
Can't load plugin twbt
DFHack is ready. Have a nice day!
DFHack version 0.47.04-r1 (release) on x86_64
Type in '?' or 'help' for general help, 'ls' to see all commands.
[DFHack]#
Not sure what to do!
Could you upload your stderr.log file from a run of DFHack that triggered this error? I'm not sure if any additional details will be in it, but they would be more likely to be printed there than to the console.
loading plugin twbt
Can't load plugin twbt
Version: v0.47.04 SDL win64
This plugin improves various aspects the game interface.[/color]
...
2. Multi-level rendering.
...
This plugin improves various aspects the game interface.[/color]
...
2. Multi-level rendering.
...
The above quote is from the O.P. in this thread.
Does Multi-level rendering happen automatically, or does it need to be turned on separately somehow?
(I successfully installed DFHack 0.47.04-r4 and twbt-6.xx-win64-0.47.04-r4, which appeared to load correctly. I set PRINT_MODE to TWBT as advised in init.txt) Then, upon creating a new world and embarking I'm not seeing the multi-level rendering. Using DF 0.47.04 game version with no mods and ASCII tileset. Sorry to be a pest, but I'm sure I followed all the instructions and such.
... Suddenly every time I pressed escape to exit menus, especially the Z menu, I get a black screen. The game is not frozen but the playing window turns pitch black. I can still see the rest of the game like the menu on the right, and the borders and such. And the game is running.
Here's an update to this post back in 2018 july (http://www.bay12forums.com/smf/index.php?topic=138754.msg7808729#msg7808729).
- Are you interested in helping to port TwbT into the main DFHack repo? With Mifki inactive, it would make maintainence and packaging a lot easier to have it all built and tested together.
Here's an update to this post back in 2018 july (http://www.bay12forums.com/smf/index.php?topic=138754.msg7808729#msg7808729).
Nice! Would you consider
- Hosting the download at https://dffd.bay12games.com/ ? It's dedicated hosting for DF, with no signup barriers and likely to outlast anything else the community uses ;)
- Are you interested in helping to port TwbT into the main DFHack repo? With Mifki inactive, it would make maintainence and packaging a lot easier to have it all built and tested together.
... Suddenly every time I pressed escape to exit menus, especially the Z menu, I get a black screen. The game is not frozen but the playing window turns pitch black. I can still see the rest of the game like the menu on the right, and the borders and such. And the game is running.
Same issue here, all the time. It doesn't happen if I set [PRINT_MODE:TWBT_LEGACY].
dfhack.onStateChange.twbt_rerender = function(event)
if event == SC_VIEWSCREEN_CHANGED and df.viewscreen_dwarfmodest:is_instance(dfhack.gui.getCurViewscreen()) then
dfhack.timeout(5, 'frames', function()
dfhack.screen.zoom(df.zoom_commands.zoom_resetgrid)
end)
end
end
@lethosor: It is not. I'd have to decide about git one way or another (mainly dithering which name I'd want people to see it under), but that's (basically) why. There's neat xkcd comic (https://xkcd.com/1445/) about this :)I would honestly suggest making a fork of TWBT, then (if you haven't yet) making a new branch off of the right commit and applying your changes there. GitHub has decent support for working with changes from multiple forks, which would make it easier for it to be merged upstream eventually, if desired.
... Suddenly every time I pressed escape to exit menus, especially the Z menu, I get a black screen. The game is not frozen but the playing window turns pitch black. I can still see the rest of the game like the menu on the right, and the borders and such. And the game is running.
Same issue here, all the time. It doesn't happen if I set [PRINT_MODE:TWBT_LEGACY].
The black screen bug on the main map with TWBT when exiting some menus such as Status (z) or Stockpile settings (s) seems to have been around for years, especially when calculation FPS dips down to or below graphics FPS.
This is the autohotkey script I use to deal with it. It basically sends "F12" a short time after you press ESC (1/10 of a sec), which forces a redraw of the main window just after the game exits the menu.
;---begin code---
#UseHook
#MaxHotkeysPerInterval 200
~Esc::
sleep, 100
Send {F12}
return
;---end code---
Here are some examples of what you can do with Japas changes, just so you know the ingame effect it can have:This is just wow. Didn't expect it to get this far :).Spoiler: animated water (click to show/hide)Spoiler: animated semi-molten rock (click to show/hide)Spoiler: animated soap maker (click to show/hide)Spoiler: varied bars/blocks (click to show/hide)Spoiler: varied rock walls and boulders (click to show/hide)
Suffice to say, I'd really love to see these additions being maintained for future updates. ;)
Current: West to East.
[OVERRIDE:55:T:RiverW:_MDF_overrides_9:S:16:240:241:242:243:244:245:246:247:248:249:250:251:252:253:254:255]
[OVERRIDE:55:T:RiverNW:_MDF_overrides_9:S:16:240:241:242:243:244:245:246:247:248:249:250:251:252:253:254:255]
[OVERRIDE:55:T:RiverRampW:_MDF_overrides_9:S:16:224:225:226:227:228:229:230:231:232:233:234:235:236:237:238:239]
[OVERRIDE:55:T:RiverRampNW:_MDF_overrides_9:S:16:224:225:226:227:228:229:230:231:232:233:234:235:236:237:238:239]
[OVERRIDE:55:T:MagmaFlow:_MDF_overrides_9:A:14:192:193:194:195:196:197:198:199:198:197:196:195:194:193]
Is there a way for an item to check for a CREATURE_MAT material without caring what king of creature it's from? I've tried CREATURE_MAT::WHATEVER and CREATURE_MAT:ANY:WHATEVER, but both give me "invalid material flag once the object comes on screen.
EDIT:
I attempted to override each part for each creature (so both regular and rotten eye, gut, stomach, heart, kidney, spleen, pancrea, muscle, liver, brain, lung, and gizzard, plus bone, skull, hair, hoof, horn, and shell for each of the games 750+ creatures, but unfortunately, TWBT throws an error for each creature/part combination that doesn't actually exist, so a simple spreadsheet formula isn't enough - I'd need a generator capable of actually parsing the raws. Also, either generating these errors or processing 21,000 overrides for a single tile creates noticeable lag, but the brute force method might be a no go.
EDIT EDIT:
I think I've made an override that works, but overriding every creature/part combination - it doesn't choke if their aren't a bunch of errors. However:
1. This doesn't seem to work on Forbidden Beasts, Night Creatures, or other procedurally generated creatures. Is there a way to override their body parts?
2. This won't work on modded creatures unless the mod specifically has overrides added for it
3. This is a lot of work, so I'm hoping there is a simpler way
[OVERRIDE:253:I:ANY:::_MDF_overrides_13:162:16:::CREATURE_MAT:POND_TURTLE:SHELL]
I was messing with it earlier trying to get it to work, but the closest I came was making all vermin remains from every creature look like turtle shells.[OVERRIDE:253:I:CORPSEPIECE:CORPSEPIECE::_MDF_overrides_13:162:16:::CREATURE_MAT:POND_TURTLE:SHELL] bodyparts
should work, but no.Also,
Is there a way to override skulls? It doesn't accept TOTEMABLE as a tag
What's the best way to determine why an object is not being overridden? I have a few cases where the original graphic is showing up where I seem to have an override with the right tile, kind, ID, and type.
MatFlag is a material flag (https://github.com/mifki/df-twbt/#material-flags), or empty to match any material.
Stock TWBT sadly doesn't overwrite sentient items: link (https://github.com/mifki/df-twbt/blob/master/plugin.hpp#L47), so skulls are excluded.
This is done because otherwise an unit that walks over corpse of their species will lose their graphics set tile in favour of their raw tile id.
:lua ~dfhack.matinfo.decode(dfhack.gui.getSelectedItem():getMaterial(), dfhack.gui.getSelectedItem():getMaterialIndex())
You could distinguish stuff like thirsty vs unhappy via tilesets tricks, i.e. using red/blue/magneta colourcoding for setting pixels for thirst/unhappiness/both, but that doesn't work in general.
How to make vermins overrides?If you've been seeing me using them, that's from using custom copy of TWBT for it compiled for 43.03 - in basic default TWBT, though, a vermin would most of the time treated like a terrain, so if you give your vermins unique tiles not used by other terrain you could override them by overriding all walkable terrain with that specific tile (assuming there's no overlap with other items or creatures).
I had done vermins this way but I don't like this because then I need to update all raws of creatures. Is there easy script to automatically change creature tiles?How to make vermins overrides?If you've been seeing me using them, that's from using custom copy of TWBT for it compiled for 43.03 - in basic default TWBT, though, a vermin would most of the time treated like a terrain, so if you give your vermins unique tiles not used by other terrain you could override them by overriding all walkable terrain with that specific tile (assuming there's no overlap with other items or creatures).
(gdb) bt full
#0 0x00007ffff5910fb7 in raise () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff5912921 in abort () at /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff6303957 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff6309ae6 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff6309b21 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff6309d54 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007fffa2342298 in renderer_cool::update_map_tile(int, int) () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/hack/plugins/twbt.plug.so
#7 0x00007fffa2344a0b in renderer_cool::display_map() () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/hack/plugins/twbt.plug.so
#8 0x00007fffa2346eeb in renderer_cool::draw(int) () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/hack/plugins/twbt.plug.so
#9 0x00007ffff664c6b0 in renderer_opengl::render() () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#10 0x00007ffff6649a88 in enablerst::do_frame() () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#11 0x00007ffff6649f71 in enablerst::eventLoop_SDL() () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#12 0x00007ffff664a6f2 in enablerst::loop(std::string) () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#13 0x00007ffff6645326 in main () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#14 0x00007ffff58f3bf7 in __libc_start_main () at /lib/x86_64-linux-gnu/libc.so.6
#15 0x000000000040970f in ()
Not surprisingly, turning off TWBT (but still running dfhack) does not cause a crash.(gdb) bt
#0 0x00007ffff5910fb7 in raise () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff5912921 in abort () at /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff6303957 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff6309ae6 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff6309b21 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff6309d54 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007fffa3a011bf in renderer_legacy::update_tile(int, int) () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/hack/plugins/twbt.plug.so
#7 0x00007ffff6646e4d in renderer::display() () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#8 0x00007ffff6649a7e in enablerst::do_frame() () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#9 0x00007ffff6649f71 in enablerst::eventLoop_SDL() () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#10 0x00007ffff664a6f2 in enablerst::loop(std::string) () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#11 0x00007ffff6645326 in main () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#12 0x00007ffff58f3bf7 in __libc_start_main () at /lib/x86_64-linux-gnu/libc.so.6
#13 0x000000000040970f in ()
Hi, I'm not sure if this is the right place to ask this question. I'm getting a crash when running the Linux Newbies Pack with TWBT. When running it with gdb, I get toCode: [Select](gdb) bt full
Not surprisingly, turning off TWBT (but still running dfhack) does not cause a crash.
#0 0x00007ffff5910fb7 in raise () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff5912921 in abort () at /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff6303957 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff6309ae6 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff6309b21 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff6309d54 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007fffa2342298 in renderer_cool::update_map_tile(int, int) () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/hack/plugins/twbt.plug.so
#7 0x00007fffa2344a0b in renderer_cool::display_map() () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/hack/plugins/twbt.plug.so
#8 0x00007fffa2346eeb in renderer_cool::draw(int) () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/hack/plugins/twbt.plug.so
#9 0x00007ffff664c6b0 in renderer_opengl::render() () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#10 0x00007ffff6649a88 in enablerst::do_frame() () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#11 0x00007ffff6649f71 in enablerst::eventLoop_SDL() () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#12 0x00007ffff664a6f2 in enablerst::loop(std::string) () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#13 0x00007ffff6645326 in main () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#14 0x00007ffff58f3bf7 in __libc_start_main () at /lib/x86_64-linux-gnu/libc.so.6
#15 0x000000000040970f in ()
Running in TWBT_LEGACY mode getsCode: [Select](gdb) bt
#0 0x00007ffff5910fb7 in raise () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff5912921 in abort () at /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff6303957 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff6309ae6 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff6309b21 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff6309d54 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007fffa3a011bf in renderer_legacy::update_tile(int, int) () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/hack/plugins/twbt.plug.so
#7 0x00007ffff6646e4d in renderer::display() () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#8 0x00007ffff6649a7e in enablerst::do_frame() () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#9 0x00007ffff6649f71 in enablerst::eventLoop_SDL() () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#10 0x00007ffff664a6f2 in enablerst::loop(std::string) () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#11 0x00007ffff6645326 in main () at /home/jcheng/Games/LinuxDwarfPack-0.47.05-r2/df_47_05_linux/libs/libgraphics.so
#12 0x00007ffff58f3bf7 in __libc_start_main () at /lib/x86_64-linux-gnu/libc.so.6
#13 0x000000000040970f in ()
Any idea what's going on?
tileupdate_map.hpp: In function ‘void write_tile_arrays_map(renderer_cool*, int, int, GLfloat*, GLfloat*, GLfloat*, GLfloat*, GLfloat*, GLfloat*)’:
tileupdate_map.hpp:162:61: error: invalid conversion from ‘int’ to ‘df::enums::items_other_id::items_other_id’ [-fpermissive]
auto &ilist = world->items.other[og.other_id];
~~~^~~~~~~~
In file included from /home/jcheng/pubprjs/dfhack/library/include/DataDefs.h:35:0,
from /home/jcheng/pubprjs/dfhack/library/include/DataIdentity.h:33,
from /home/jcheng/pubprjs/dfhack/library/include/DataFuncs.h:32,
from /home/jcheng/pubprjs/dfhack/library/include/PluginManager.h:36,
from twbt.cpp:43:
If you're able to compile TWBT from that fork, I'd recommend compiling a debug build so that you can get more information out of the GDB backtrace (if you aren't already doing this, that is).
Binaries are available at Ziusudra's link, but I strongly suspect your pack is using one of those already.
Adventure mode support definitely has gaps - that's probably one of them.
How to make bone, skin, clavs and other overrides? For some reason, using ANY just can't work.
Is there any way to get ID and type and material of any item in-game?How to make bone, skin, clavs and other overrides? For some reason, using ANY just can't work.
ANY isn't a valid ID and TWBT will ignore it, otherwise crashes occur like what used to happen in Meph's tileset.
Is there any way to get ID and type and material of any item in-game?How to make bone, skin, clavs and other overrides? For some reason, using ANY just can't work.
ANY isn't a valid ID and TWBT will ignore it, otherwise crashes occur like what used to happen in Meph's tileset.
Did it.Is there any way to get ID and type and material of any item in-game?How to make bone, skin, clavs and other overrides? For some reason, using ANY just can't work.
ANY isn't a valid ID and TWBT will ignore it, otherwise crashes occur like what used to happen in Meph's tileset.
there might be other ways, but check the dfhack 'probe' command.
Hi thurin, I notice you have some open PRs on your twbt fork (https://github.com/thurin/df-twbt/pulls) -- would you be willing to merge them?
What causes this when TWBT is activated?
The black screen bug on the main map with TWBT when exiting some menus such as Status (z) or Stockpile settings (s) seems to have been around for years, especially when calculation FPS dips down to or below graphics FPS.
This is the autohotkey script I use to deal with it. It basically sends "F12" a short time after you press ESC (1/10 of a sec), which forces a redraw of the main window just after the game exits the menu.
;---begin code---
#UseHook
#MaxHotkeysPerInterval 200
~Esc::
sleep, 100
Send {F12}
return
;---end code---
From what I remember, GFPS actually can't drop below FPS, due to how they are synchronized (although the number displayed in the FPS counter is calculated differently and smoothed, so you might sometimes see cases where GFPS is 1 above FPS, for instance).
Anyway, it's good to know that low FPS could be a cause of this. I think a more robust fix would be to detect viewscreen changes with an onStateChange event handler (watching for SC_VIEWSCREEN_CHANGED), because it wouldn't require changing keybindings or using external utilities. Something like this might work, if I'm understanding the issue correctly (it assumes the issue occurs when switching back to the fortress mode screen):Code: [Select]dfhack.onStateChange.twbt_rerender = function(event)
if event == SC_VIEWSCREEN_CHANGED and df.viewscreen_dwarfmodest:is_instance(dfhack.gui.getCurViewscreen()) then
dfhack.timeout(5, 'frames', function()
dfhack.screen.zoom(df.zoom_commands.zoom_resetgrid)
end)
end
end@lethosor: It is not. I'd have to decide about git one way or another (mainly dithering which name I'd want people to see it under), but that's (basically) why. There's neat xkcd comic (https://xkcd.com/1445/) about this :)I would honestly suggest making a fork of TWBT, then (if you haven't yet) making a new branch off of the right commit and applying your changes there. GitHub has decent support for working with changes from multiple forks, which would make it easier for it to be merged upstream eventually, if desired.
The black screen bug on the main map with TWBT when exiting some menus such as Status (z) or Stockpile settings (s) seems to have been around for years, especially when calculation FPS dips down to or below graphics FPS.
This is the autohotkey script I use to deal with it. It basically sends "F12" a short time after you press ESC (1/10 of a sec), which forces a redraw of the main window just after the game exits the menu.
;---begin code---
#UseHook
#MaxHotkeysPerInterval 200
~Esc::
sleep, 100
Send {F12}
return
;---end code---
Has anyone found an updated way to handle this? This solution works but I'd rather not have to use a 3rd party program. I love my multi lvl ASCII 47.05 but this black screen issue is driving me nuts. Doesn't happn with TWBT_Legacy but, that cause some other issues for me.
install-twbt-refresh
exit & save