Post by: mifki on May 21, 2014, 06:34:48 pm
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. Some functions may not work or have issues in Adventurer Mode. See readme for all details.
1. Main function is to use separate fonts (tilesets) for map tiles and for text. Text and map font may also have different sizes. Map tiles can have any size, no requirement to have at least 80x25 grid anymore.
2. Multi-level rendering.
3. Allows to override tile numbers for buildings, items and various tile types.
4. `mapshot` command saves image of the entire map in full size.
5. "Multilayered" rendering where floor is visible behind buildings and items. (see here for details (http://www.bay12forums.com/smf/index.php?topic=163298.msg7395584#msg7395584))
6. Tiles can have parts that will and parts that will not be affected by material colour. (see here for details (http://www.bay12forums.com/smf/index.php?topic=163298.msg7395584#msg7395584))
7. "Multilayered" rendering for units too. (see here for details (http://www.bay12forums.com/smf/index.php?topic=138754.msg7660119#msg7660119))
8. An option to hide stockpiles (background, not items of course) unless in [q], [p] and [k] modes. (see here for details (http://www.bay12forums.com/smf/index.php?topic=138754.msg7660119#msg7660119))
Latest binaries are available from autobuild server (see below). There's no guarantee they will work on your OS, have any functions you expect, or even work at all. They're provided purely for people who want to test things as they're being developed rather than to wait. I read your error reports but don't expect them to be fixed straight away.
Spoiler: Screenshots (click to show/hide)
Home Page / Sources (https://github.com/mifki/df-twbt) -- Latest Release (https://github.com/mifki/df-twbt/releases) -- Development Builds (http://build.mifki.com) -- Report an Issue (https://github.com/mifki/df-twbt/issues)
Any ASCII tileset can be used as a text font, including the default "curses" one, or you can make you own text font with this tool (http://www.bay12forums.com/smf/index.php?topic=140250.0).
Post by: Putnam on May 21, 2014, 08:54:58 pm
Post by: Trapezohedron on May 21, 2014, 09:05:54 pm
Somebody needs to port this over to windows asap.
Post by: scamtank on May 22, 2014, 05:27:44 am
...Holy crap.
Post by: Meph on May 22, 2014, 05:39:12 am
Post by: Carsius on May 22, 2014, 07:29:09 am
...Holy crap.
Post by: mifki on May 22, 2014, 07:47:41 am
Just updated the plugin with correct support for more screens (embark, world gen, image export) and side menu modes (thx fricy for reminding). I'll try to make Windows build but things are so much more complicated there...
Post by: Warmist on May 22, 2014, 08:11:58 am
Post by: mifki on May 22, 2014, 09:13:18 am
Post by: Meph on May 22, 2014, 12:43:07 pm
Post by: scamtank on May 22, 2014, 12:52:55 pm
Does this have any DFHack prequisites? The few people I've seen test this report crashing.
Post by: Meph on May 22, 2014, 01:02:10 pm
Post by: fricy on May 22, 2014, 03:05:09 pm
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.
Post by: Warmist on May 22, 2014, 05:19:35 pm
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.
Post by: mifki on May 22, 2014, 08:50:51 pm
Just uploaded new package with minor fixes (not for Ctrl-S and Ctrl-M yet) and experimental Windows binary.
OS X version is tested with MacNewbie Pack ReBorn v0.8.4 on 10.9 and Windows version with PeridexisErrant's Dwarf Fortress Starter Pack r55 on XP and Win7.
fricy, what does this mean - "in windowed mode the graphics is blurred"?
As for TTF, yes, it would be ideal to separate graphics code on all platforms and do everything properly, but for now we have what we have. TTF rendering looks nicer than square font and allows longer text, but currently has problems with non-black "black" color (TTF background is always true black), not being used on some screens (I wonder why) and in text output by dfhack plugins. These are basically the reasons why I wrote this plugin. So I think people who are happy with TTF won't want this plugin so it's not a problem that they are incompatible.
Post by: scamtank on May 23, 2014, 03:52:21 am
Spoiler (click to show/hide)
It still feels a little unstable, though. Big saves crash on unpause with this on.
Post by: mifki on May 23, 2014, 04:32:39 am
As for crashes, I haven't experienced any so far, I'll try loading different saves, but possibly it depends on something else and not the save size.
Post by: Quietust on May 23, 2014, 07:46:43 am
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.
Similarly, the reason DFHack doesn't use TrueType is because it doesn't support it, and the reason we don't support it is because it's too damn buggy.
Post by: Meph on May 23, 2014, 09:33:07 am
So a graphic engine update is most likely not going to happen any time soon.
Post by: fricy on May 23, 2014, 10:18:17 am
/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.
@scamtank: Yepp, and yepp. Fuzzy edges, that we can't do anything for at the moment, just thought to mention it. Finding same size text and graphics tilesets is a bit hard at the moment, but I expect the artists to catch up with it once we get some momentum. This effectively doubles the available tiles, which is IMHO the biggest advancement since foreground/background/transparency tricks were invented.
And in other news I postponed pushing out the new Macnewbie as I ran into some unexpected crashes that may or may not be related to the plugin. I'm 99% that it's something else, but'll get back to you once I have a bit time to figure it out. I suspect the GL renderer, but it's a mystery as I was testing for hours yesterday without problems, and then it started crashing 9 times out of 10 when I decided it was stable enough. Frustrating. ???
Post by: Meph on May 23, 2014, 04:35:23 pm
Has anyone tried running this and Rendermax at the same time?
Post by: mifki on May 23, 2014, 04:59:46 pm
Originally I was going to make bigger modifications to rendering, one thing would be to implement real background+foreground rendering, so that floor tile with its material/color is rendered first and then object is rendered on top with its own material, not obscuring the floor completely.
But now at least there's no need for these bg/fg tricks, so that tileset creation should be easier. Also I was thinking that it may be possible to patch tile numbers somewhere in memory to remap objects using the same tile to different tiles as we now can use all letter/number tiles for something else. If it's not possible to statically remap objects, I can do that dynamically in the plugin, although it may be slow, need to check.
@fricy: you're on OS X so it's trivial to copy and email me crash log(s) to check.
Post by: Meph on May 23, 2014, 05:02:59 pm
And yes, you understood my question correctly.
Post by: mifki on May 23, 2014, 05:13:05 pm
I quickly tried rendermax with my plugin now and it crashes, partly because of how I override rendering methods, as Warmist noticed before. I'll look into this later.
Post by: Meph on May 23, 2014, 05:23:46 pm
Because that I could do in a few hours. Althouth I wont have access to my Pc for a week at least,.but I will let you know when I am available again. :)
Post by: mifki on May 23, 2014, 05:33:29 pm
Post by: Meph on May 23, 2014, 05:39:05 pm
For example all weapons and ammo shares one tile. It would be great, if the plugin would check the item type, and use different tiles for ammo or weapons. Checking for the sub-type would be even better, that way swords could look differently from axes, and shirts dont look like gloves that dont look like breastplates.
So my suggestion would be to read out the itemtype and allow different tiles for Item:Subtype. But I dont know if this is a valid suggestion or impossible.
Post by: Vattic on May 23, 2014, 08:49:27 pm
This looks really interesting.
Post by: fricy on May 24, 2014, 08:14:32 am
@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:
Code: [Select]
fix/cloth-stockpile enable
fix/feeding-timers enable
fix/growthbug enableand 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.The strange thing is that it doesn't crash every time, once-twice out of 10 launches it loads correctly. A few months ago I had the same problem with falconne's hotkeys plugin, and I couldn't find the cause at that time, others didn't see the crashes. Maybe it's only something with my mac, or only on 10.7.5. But it's not the twbt plugin, so at least we have that.
If you want to investigate I have uploaded the inits to dropbox (https://dl.dropboxusercontent.com/u/36491887/dfhack_inits.zip) for testing.
Post by: Vherid on May 24, 2014, 10:56:40 am
Post by: mifki on May 24, 2014, 11:02:43 am
Now plugin loads data/init/overrides.txt where you can specify additional tilesets to load and configure tile replacement based on item/building type (and possibly subtype but I don't know any values to try). See inside the package for some docs and sorry for any bugs, I'll go get some sleep :)
Post by: Meph on May 24, 2014, 12:46:36 pm
Post by: ag on May 24, 2014, 01:14:35 pm
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)
I seem to have read Baughn saying somewhere that adding too much stuff to objects makes the game crash or something, which slows down the possible rate of change. I may have an idea why this happens, and a very easy workaround would be to add some "char padding[256]" to the end of all global objects that baughn wants to grow, so that once Toady recompiles, enough space is reserved.
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 (http://github.com/DFHack/dfhack/blob/master/library/include/modules/Screen.h). 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.
Post by: GavJ on May 24, 2014, 03:17:29 pm
But since you're using memory access anyway, why base it off of text area versus graphics area???
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.
Or even, if somebody wants, using separate graphics for copper minecarts versus wooden (not just colors, separate graphics). Could set up a text file where people can just leave it blank if they want only graphics vs. text area, or they can write in whatever custom level of detail they feel like in whatever syntax is native/most convenient to write code for (they can figure it out, as long as the script makes it physically possible)
Post by: mifki on May 24, 2014, 06:09:39 pm
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.
I probably will add special handling of workshops, they have empty tiles that can't be overridden this way, but for non-empty it should work now.
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.
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. Again, as Warmist suggested before, there's another way to do what I'm doing, but I'll think about it later.
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.
However hooking the render method doesn't seem to be the appropriate way. The idea here is to hook the update_tile(x,y) method which is called only for changed tiles, so it is fast. I have no idea what you're suggesting to do in render() instead.
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.
That's what I did in the latest version (see my previous post), isn't it?
Post by: Vattic on May 24, 2014, 07:41:40 pm
Post by: mifki on May 24, 2014, 07:55:14 pm
Is there a way to give grass tiles a specific character and soil floors a different one?
Grass characters can be easily changed in raws plant_grasses.txt after setting VARIED_GROUND_TILES to YES. What this plugin allows is to use more tiles (numbers, letters) that are now free. However as far as I know there are some unused tiles even without any plugins if you need only couple.
But that's only for grass, in general no, this plugin looks only for items/buildings on a tile currently, however other tile attributes can be added, I think.
Post by: Vattic on May 24, 2014, 09:23:42 pm
Cheers.
Post by: ag on May 25, 2014, 02:11:05 am
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.
Manually means doing weird things, with hard-coded indexes that would break if stuff changed, or if another plugin did the same thing, and inline assembly, instead of a supported API.
What dfhack does is described here (http://github.com/DFHack/dfhack/blob/master/library/VTableInterpose.cpp).
Post by: mifki on May 25, 2014, 02:33:21 am
Post by: ag on May 25, 2014, 02:35:39 am
Anyway, these classes are not in dfhack, so it's pointless to talk about what would be possible to do if they were there.
The reason dfhack does not really define renderer classes other than the base one, is that in the linux version they are located in a separate library, so their vtable pointers are hard to specify. 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. However, when you are going that far, you might as well subclass the base class and implement vmethods normally.
Post by: mifki on May 25, 2014, 02:51:57 am
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.
Again, I agree that the way it's done in rendermax is possibly better. But I did it how it was easier and required less code, especially I didn't care about Windows and assembly code it would require. It was my right, wasn't it?
Post by: Taffer on May 25, 2014, 03:02:25 pm
Hopefully it can get accepted upstream.
Post by: PeridexisErrant on May 30, 2014, 07:25:08 pm
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?
Post by: palu on May 30, 2014, 08:23:29 pm
This is one of the most beautiful things i've ever seen. Maybe even better than rendermax....Holy crap.
Post by: Vherid on June 02, 2014, 10:58:39 am
Post by: fricy on June 02, 2014, 11:08:06 am
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?
Did you set up the init properly? You have to set PRINT_MODE to Standard, add a secondary tileset and set GRAPHICS to YES to see the changes. And make sure that you have dfhack-r3, AFAIK that's the only version it works with for now.
Post by: Vherid on June 02, 2014, 11:10:38 am
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.
Post by: Meph on June 02, 2014, 12:38:24 pm
Post by: fricy on June 02, 2014, 01:05:30 pm
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'll double check on Windows, but sounds strange, haven't seen anything like that. There are some bugs, but so far what I've seen is that it either shows the graphics tileset completely OR the text tiles.
EDIT: Double checked, I can see all profession sprites correctly. Would you mind posting a screenshot in case I misunderstand what to look for?
Spoiler: spacefox screenshot (click to show/hide)
Post by: Vherid on June 02, 2014, 02:06:27 pm
Edit: After messing with it for quite a bit, this is a really really cool thing and is definitely, possibly, the start of a bigger thing in the future when it comes to aesthetics.
Post by: CLA on June 03, 2014, 03:10:43 pm
EDIT:
So I tried to play around with it a little, but I can't seem to get the overriding to work.
The text/map separation works great and that's really nice.
But I tried to give up-down stairs a separate tile from bins, so I took the GRAPHICS_FONT/FULLFONT tileset and replaced tile #87 ('W') with a new graphic for bins.
Then added this line to data/init.txt:
[OVERRIDE:88:I:BIN:::0:87]
In game Bins still use tile #88 ('X', same as stairs).
I also tried 'BIN:BIN' as well as [OVERRIDE:88:0:87], neither of which work.
Any ideas?
Post by: mifki on June 03, 2014, 05:43:11 pm
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]
Post by: Meph on June 03, 2014, 06:05:50 pm
Does it still clash with Rendermax?
Post by: thistleknot on June 03, 2014, 06:09:34 pm
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
thank you!
Post by: mifki on June 03, 2014, 06:16:00 pm
Just saying that I am watching this with interest. :)
Does it still clash with Rendermax?
It crashes when used with rendermax light but works with other rendermax modes. So it's not a simple incompatibility of rendering hooks. I'm yet to investigate this.
Also, what's the current situation with dfhack versions? Should I add a windows binary for r4 to the package as well (as I understand, plugins have dfhack version hardcoded so it won't load with r4 now, right?)?
Post by: scamtank on June 03, 2014, 07:34:53 pm
Post by: mifki on June 03, 2014, 07:41:42 pm
Post by: Vherid on June 03, 2014, 08:12:53 pm
Ok I'll make a binary for r4 soon.
Would be greatly appreciated.
Post by: xeranes on June 03, 2014, 08:13:42 pm
Post by: bodgingbrom on June 03, 2014, 11:26:04 pm
Post by: mifki on June 04, 2014, 12:31:53 am
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.
Post by: mifki on June 04, 2014, 12:35:53 am
Mifki, do you have a bitcoin address I can send some donations to? This is amazing.
So far it was too easy to start accepting donations, especially compared to the great work of dfhack developers who made all this possible :)
No I don't have.
Post by: CLA on June 04, 2014, 01:59:29 am
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]
Can't get that to work either. Downloaded fresh version of df 0.34.11 for windows, downloaded dfhack r3, extracted. dropped twbt.dll (v2.0) in plugin folder. Added the two lines above to init.txt, changed the print mode to STANDARD (also tried VBO).
Started game, generated world, embarked, construct stone door.
Still uses tile 197.
placed (built) stone door somewhere, uses tile 197 as well.
text uses separate tileset without problems.
Post by: mifki on June 04, 2014, 02:11:03 am
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
Post by: PeridexisErrant on June 04, 2014, 02:30:31 am
While great for Spacefox, there are people who might be annoyed if it changes the pure ASCII they love...
Post by: mifki on June 04, 2014, 02:42:13 am
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).
Post by: CLA on June 04, 2014, 02:52:56 am
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
Oh duh, I'm such a fucking retard, I can't believe it. Thanks all working now.
Post by: PeridexisErrant on June 04, 2014, 03:03:20 am
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).
Cool, thanks. That's easy enough to check... I'll have a play around over the weekend after my exam tomorrow.
Post by: mifki on June 04, 2014, 09:00:32 am
Post by: milo christiansen on June 04, 2014, 03:50:59 pm
Post by: thistleknot on June 04, 2014, 08:15:23 pm
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.
THANK YOU!
Post by: thistleknot on June 04, 2014, 08:36:59 pm
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.
Post by: mifki on June 04, 2014, 09:49:48 pm
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.
Post by: thistleknot on June 05, 2014, 12:17:08 am
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.
to your question, yes
Post by: milo christiansen on June 06, 2014, 10:11:42 am
1) Items being carried by dwarves do not use their override tiles.
2) When scrolling the screen, if an overridden tile would be (without the override) the same as the tile that was in that location before the view was moved the tile is not updated to use the override (AFAIK this only triggers if the tiles are the same color and everything)
Other than those two bugs this is very cool! I am working on a ASCII compatible tileset that is fully graphical by virtue of overrides, so far it is working well and the results are great :)
Post by: mifki on June 06, 2014, 10:41:22 am
2. Unfortunately that's how it works (well, it's not bad actually, only for overrides) - if tile is the same, renderer's update_tile() isn't called because there's no need to redraw it, so I don't get a chance to apply overrides. Don't think anything can be done about this.
Post by: milo christiansen on June 06, 2014, 10:44:35 am
Post by: mifki on June 06, 2014, 11:19:37 am
Post by: Meph on June 06, 2014, 11:26:51 am
Post by: GavJ on June 07, 2014, 04:04:40 am
Post by: mifki on June 07, 2014, 07:33:58 am
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?
Post by: Meph on June 07, 2014, 07:35:14 am
Post by: mifki on June 07, 2014, 07:45:24 am
Post by: Meph on June 07, 2014, 08:28:11 am
Post by: GavJ on June 08, 2014, 02:43:56 am
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.
Post by: Putnam on June 08, 2014, 10:11:34 am
Post by: mifki on June 08, 2014, 05:26:46 pm
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.
Yes, I can make more colours available to use in raws.
Post by: Dirst on June 09, 2014, 10:30:33 am
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.
Post by: 0x517A5D on June 10, 2014, 12:34:29 pm
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.
[rant]
Shows the age of parts of the game code. Thirty-three years ago, the CGA video card drew text with 16 foreground colors and 8 background colors, at 80 characters by 25 lines. The EGA video card (thirty years ago) added the ability to have 16 background colors, and the VGA (twenty-seven years ago) let you choose any hue for your 16 colors.
Up to release 28.181.38f (in 2008), DF had a literal hardcoded 80x25 buffer organized exactly like the CGA did it, pairs of characters and colors in a 4000 byte array. It then used modern OpenGL to render this ancient technology.
What's changed? Well, we can customize the grid size now. And, um, limited Truetype support on Windows.
This is a sad state of affairs.
[/rant]
mifki, thank you for writing this plugin. peterix et al, thank you for the DFHack framework.
Post by: lethosor on June 10, 2014, 01:49:42 pm
What's changed? Well, we can customize the grid size now. And, um, limited Truetype support on Windows.Truetype works on all platforms.
Post by: Putnam on June 10, 2014, 01:59:40 pm
Post by: mifki on June 10, 2014, 05:23:03 pm
Anyway, the next plugin version will allow to use almost any number of configurable colours for fg/bg, and if you modify raws carefully, they will still be compatible with vanilla df because the original code uses the remainder of division, so you can use eg. 17,33,etc. for different colours that will all become just blue without the plugin.
Post by: CLA on June 11, 2014, 03:16:59 am
Post by: mifki on June 11, 2014, 04:01:33 am
Many other things are possibly too but I don't know yet how the configuration for this should look like because it's all different fields/flags in dfhack structures to check.
What are up/down-tiles?
Post by: Meph on June 11, 2014, 07:35:40 am
If you want something really difficult as a project, someone posted this mock-up in the suggestions thread for dfhack plugins:
Spoiler (click to show/hide)
Post by: PeridexisErrant on June 11, 2014, 07:56:41 am
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.
Post by: Warmist on June 11, 2014, 08:04:06 am
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.
Edit: other than using the "Offscreen" module i been working on, it might be possible just fake it with changing viewscreen z coordinate asking for render, reading it and combining to some buffer (though each layer would effectively divide the gfps)
Post by: mifki on June 11, 2014, 08:35:04 am
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)
Obviously I know what ramps are, just was confused that they weren't called just ramps :)
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.
Post by: mifki on June 11, 2014, 08:36:10 am
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.
Thanks, see some interesting suggestions there, plus have several ideas myself. Need to think and try some things now.
Post by: Meph on June 11, 2014, 08:56:07 am
Post by: CLA on June 11, 2014, 10:22:58 am
What are up/down-tiles?I meant up-down-stairs, sorry.
EDIT:
And yeah, if you look at your fort underground, it has little to no benefit. But if your fortress entrance is in a valley, and for having a better overview of the surroundings, it would improve fortress mode massively, I think. Not to mention Adventure mode.
Post by: Quarterblue on June 11, 2014, 12:11:31 pm
Post by: GavJ on June 11, 2014, 03:47:13 pm
Quote
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.
If you're ENTIRELY underground, then the algorithm would only kick in for a few dozen tiles here and there maybe where there are open pits downward, yeah? Depending on when you're intervening in the core code, this might still require checking every tile, but then doing nothing after that. So if the aboveground version is at all playable, then the lag totally underground should be fairly trivial by comparison (IF the aboveground is playable! Which may turn out to be a tall order).
Alternatively there could just be a toggle button. Lots of times, even above ground you might not care what's below (maybe you have a perimeter wall on your z level anyway) and want to turn it off even then most of the time, until a siege hits or whatever.
Post by: SalmonGod on June 11, 2014, 08:32:24 pm
Post by: mifki on June 12, 2014, 12:38:21 am
(http://i.imgur.com/arwvNDtl.png) (http://imgur.com/arwvNDt)
Post by: Freak2121 on June 12, 2014, 01:05:26 am
Post by: GavJ on June 12, 2014, 01:21:32 am
Post by: PeridexisErrant on June 12, 2014, 02:06:28 am
This thread just turns up one day; casually fixes the biggest problem with tilesets. And opens up the color gamut. And special tiles for various things. Then online play with tiles. Then multilevel stuff. And all that in less than a month!
Mifki, wizard doesn't begin to describe how cool this is.
Post by: mifki on June 12, 2014, 02:54:55 am
Btw, as I thought (and again I believe Warmist may have tried something like this already), it seems to be possible to render certain screens along the main screen on bigger displays - eg. like divide screen into several areas/tiles and have main screen in the largest tile and some other screens in other tiles always visible. Or have separate windows with different screens maybe. Don't know if this may be useful for anything though.
Another semi-working idea - the grid doesn't have to be uniform across screens and even on one screen:
(http://i.imgur.com/ML0beEcl.png) (http://imgur.com/ML0beEc)
Post by: CLA on June 12, 2014, 03:06:37 am
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.
Post by: Quarterblue on June 12, 2014, 03:25:43 am
Post by: scamtank on June 12, 2014, 07:19:43 am
Another semi-working idea - the grid doesn't have to be uniform across screens and even on one screen:Spoiler (click to show/hide)
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!
Post by: Warmist on June 12, 2014, 07:44:55 am
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).
Post by: Meph on June 12, 2014, 08:14:37 am
Post by: KillzEmAllGod on June 12, 2014, 09:34:23 am
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.
Post by: palu on June 12, 2014, 10:36:14 am
Post by: Footkerchief on June 12, 2014, 10:52:24 am
Post by: Dutchling on June 12, 2014, 10:57:45 am
Post by: knaveightt on June 12, 2014, 11:29:15 am
Post by: Vherid on June 12, 2014, 02:08:47 pm
Post by: tootboot on June 12, 2014, 05:17:25 pm
Post by: adamantinespork on June 12, 2014, 07:35:00 pm
Post by: PeridexisErrant on June 12, 2014, 07:57:44 pm
Post by: mifki on June 12, 2014, 08:15:56 pm
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.
It doesn't crash for me, but I can't investigate further right now, will do more tests later. And will add more error checks into the code.
Post by: mifki on June 12, 2014, 09:19:57 pm
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.
I actually wasn't planning to show z-levels above. I see some problems with it, and also such dynamic behaviour may be confusing for players. But maybe I'll try and see how it works.
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!
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 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?
There are some fixes and optimisations that have to be done before a public release.
I think in the first version it will look something like this (this was just a quick test, there are many rendering glitches):
(http://i.imgur.com/xL8RLx4l.png) (http://imgur.com/xL8RLx4)
Post by: Meph on June 12, 2014, 10:28:05 pm
Quote
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. :)
Post by: SalmonGod on June 12, 2014, 10:32:41 pm
Looks amazing. So many people will want to embark on mountains with that. :)
Seriously, mifki, this is game-changing stuff.
Post by: PeridexisErrant on June 13, 2014, 12:23:43 am
I would love an option to create unicorns while playing DF in a photorealistic VR space, plus strong friendly AI.
...here's hoping pics of a working plugin turn up later today, like all our other outrageous requests ;D
More seriously, that looks fantastic and I'm looking forward to a release.
Post by: SanderMarechal on June 13, 2014, 01:32:24 am
Post by: mifki on June 13, 2014, 01:39:21 am
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?
That .so is for OS X, no binary for Linux currently, sorry. I'll make it once the next version is ready.
Post by: scamtank on June 13, 2014, 08:42:36 am
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?
Post by: Meph on June 13, 2014, 09:20:28 am
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?
Post by: lethosor on June 13, 2014, 12:33:51 pm
Post by: Meph on June 13, 2014, 12:37:52 pm
Post by: petrov on June 13, 2014, 12:41:50 pm
Post by: mifki on June 13, 2014, 06:08:41 pm
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?
It depends on the maximum number of levels allowed and amount of darkening, both will be configurable.
Post by: sic8 on June 13, 2014, 11:27:01 pm
Is there any way to have transparent sprites so we can see what's under things? Would make the game beautiful with a good texture pack.
Post by: Aydjile on June 14, 2014, 07:05:58 am
Post by: Caz on June 14, 2014, 11:58:08 am
Post by: Meph on June 14, 2014, 02:20:10 pm
Quote
# 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
Could somebody point me towards the buildings_other_id.h and items_other_id.h ? And can I somehow specific a subtype, or specific tiles from buildings?
So not just WEAPON, but WEAPON:ITEM_WEAPON_SWORD_SHORT, WEAPON:ITEM_WEAPON_SWORD_LONG, etc.
As well as building tiles. A 3x3 workshop has 9 tiles, how do I specific which tile goes where?
Post by: Putnam on June 14, 2014, 02:33:36 pm
Post by: CLA on June 14, 2014, 02:54:50 pm
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 ?
Post by: Meph on June 14, 2014, 06:24:36 pm
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 ?
So all items are read the way they appear in menus/stockpiles... alphabetically from the raws. I will test this. :)
Post by: bodgingbrom on June 15, 2014, 10:46:14 am
I had a dream last night of the most amazing fort that I need to build, but in my dream, I could see all the Z levels below the camera. My mountain/ocean based dream fort was all the more beautiful when I could see my whale trap from above, and my sprawling above ground crops on the mountains.
I think it's safe to say that I love you mifki.
Post by: GavJ on June 15, 2014, 07:35:53 pm
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.
Post by: SalmonGod on June 15, 2014, 07:41:44 pm
Post by: Meph on June 15, 2014, 10:46:47 pm
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.
Post by: mifki on June 16, 2014, 06:29:02 pm
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.
Still several days to wait - need to do add more optimisations.
Any interesting savegames on dffd with multilevel landscapes/forts to test on and make beautiful screenshots? :)
Post by: GavJ on June 17, 2014, 06:16:40 am
Don't know of any highly-z-level-utilizing cliff forts for you, though.
Post by: mifki on June 18, 2014, 11:49:16 pm
(http://i.imgur.com/zcwZJ97l.png) (http://imgur.com/zcwZJ97)(http://i.imgur.com/M0FVFzjl.jpg) (http://imgur.com/M0FVFzj)
Post by: GavJ on June 19, 2014, 12:10:26 am
Post by: jocke the beast on June 19, 2014, 02:58:16 am
Thanks for doing *this* :)
Post by: CLA on June 19, 2014, 05:45:33 am
I assume you will be able to the adjust the shadow between layers? Because I expect tilesets to adjust to this and make the downramps look darker.
Post by: mifki on June 19, 2014, 06:15:13 am
Christ, this looks great.
I assume you will be able to the adjust the shadow between layers?
What do you mean?
Post by: lethosor on June 19, 2014, 06:16:24 am
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).
Post by: Meph on June 19, 2014, 06:33:03 am
More info here (http://www.bay12forums.com/smf/index.php?topic=121451.msg4203086#msg4203086).
Dont know if this is of interest, but since you are doing multiple tilesets already, maybe this is something that can be integrated. And your screenshots look very good, thats 10 zlevels on one screen, wow.
Post by: CLA on June 19, 2014, 08:11:15 am
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.
Quote
(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?
Post by: Meph on June 19, 2014, 08:15:31 am
Quote
Why not replace the current minimap?The current minimap is in a menu that automatically cuts off a large portion of the screen.
Before (old minimap)
Spoiler (click to show/hide)
After (new place for minimap)
Spoiler (click to show/hide)
Post by: mifki on June 19, 2014, 08:18:29 am
Each layer is surrounded by a small, soft, black outline. Can you switch that off?
Shadow texture is loaded from a file, so yes.
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.
Post by: mifki on June 19, 2014, 08:22:38 am
Post by: Meph on June 19, 2014, 08:24:36 am
Post by: PeridexisErrant on June 19, 2014, 08:28:53 am
Post by: CLA on June 19, 2014, 08:30:32 am
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.
Post by: Mayama on June 19, 2014, 08:55:51 am
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?
Post by: Dirst on June 19, 2014, 11:52:13 am
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?
By the way, awesome work mifki!
Post by: SIGVARDR on June 19, 2014, 01:41:04 pm
Post by: Dirst on June 19, 2014, 02:28:55 pm
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?
Post by: jwpartain1 on June 19, 2014, 03:10:06 pm
Post by: lethosor on June 19, 2014, 03:25:27 pm
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.
Post by: mifki on June 20, 2014, 04:18:53 am
Multilevel and twbt will still be the single plugin (currently with twbt itself, overrides, multilevel and a command to save full map image) for performance and organisational reasons - they all hook the same renderer methods and share some code.
Post by: mifki on June 20, 2014, 04:22:30 am
Post by: CLA on June 20, 2014, 05:22:46 am
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.
Post by: PeridexisErrant on June 20, 2014, 06:21:17 am
Post by: mifki on June 20, 2014, 06:29:35 am
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.
Yes, but they won't be able to change for example how I render ramps and where I render shadows.
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.
(http://i.imgur.com/VJruePhl.png) (http://imgur.com/VJruePh)
Post by: CLA on June 20, 2014, 07:20:15 am
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?
Post by: palu on June 20, 2014, 07:25:28 am
Post by: lethosor on June 20, 2014, 07:35:05 am
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. :)
Post by: palu on June 20, 2014, 07:51:26 am
Post by: mifki on June 20, 2014, 07:58:01 am
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 ;)
And yes, I hate to have to build things for several different platforms...
Post by: mifki on June 20, 2014, 08:01:40 am
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?
I tried, shadows over ramps look even worse, at least with this tileset/ramp image.
Btw, it doesn't make sense - tile either belongs to the top level or has shadow on it:)
Post by: Footkerchief on June 20, 2014, 08:39:25 am
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?
I think it looks bad because the edges are fuzzy and noisy-looking. I think displaying ramps as gradients is worth a try.
Post by: SalmonGod on June 20, 2014, 11:25:02 am
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...
Spoiler: Squee!! (click to show/hide)
Post by: Meph on June 20, 2014, 03:42:06 pm
I also noticed a display bug in the worldgenerator screen. Its nothing major, just wanted to let you know.
Spoiler (click to show/hide)
Post by: palu on June 20, 2014, 03:52:18 pm
Post by: Meph on June 20, 2014, 05:08:18 pm
Post by: palu on June 20, 2014, 05:09:19 pm
Post by: Meph on June 20, 2014, 05:11:43 pm
Post by: mifki on June 20, 2014, 05:55:18 pm
I also noticed a display bug in the worldgenerator screen. Its nothing major, just wanted to let you know.
Thanks.
Also, on the create new world screen, half of the text is in one tileset, and half is in the other.
Yes, there was a problem to determine which stage of the world gen is currently being shown, will try again later.
Post by: mifki on June 20, 2014, 05:57:48 pm
I did some tests with item subtypes. I got it working, and will post an item tileset probably tomorrow, if there is any interest.
Next version, once finally released ;), will allow to add overrides based on tiletype and designation.
Post by: Meph on June 20, 2014, 07:08:14 pm
I started on an overlay tileset for items. I started with a 24x24 pixel tileset, with 32x32 tiles. (768x768 pixels total). The 24x24 pixel downscale to the usual 16x16 pixel tilesets beautifully, and if people use higher-res tilesets, the items look even better. But I have a problem. The 32x32 tiles tileset got staunched heavily... it seems it has to be a tileset thats 16x16 tiles. Is that correct? That would mean I only have 256 tiles for overlays, which is not enough for the 1000 or so items I have. Is it possible for you to enable tilesets that have more tiles, or can I already use multiple tilesets?
Like this?
Code: [Select]
[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? So "Overrides - A - Weapons.png" would be 2, and "Overrides - B - Armors.png" would be 3, and so on?
I hope I am not explaining this too badly.
Post by: mifki on June 20, 2014, 07:34:46 pm
You can load as many tilesets as you want (there are some opengl texture size limitations though) with TILESET command, and yes, they will be 2, 3, etc. in order they appear in the config file (not alphabetically).
This could be better, I know.
I wonder how slow it will or will not be with 1000 overrides though :)
Post by: Meph on June 20, 2014, 07:48:09 pm
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.
My mod has 541 custom buildings, and 1446 items in total. At the moment. I havent even touched the overrides for buildings yet, I dont understand how that works on multi-tile workshops. The 190 weapons I have fit in one 256 set... but the tools will be difficult.
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... ^^
Post by: Footkerchief on June 20, 2014, 09:38:25 pm
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... ^^
What he'd say? He seemed open to it a long time ago (http://www.bay12forums.com/smf/index.php?topic=30114.msg485617#msg485617).
Post by: Meph on June 20, 2014, 09:52:24 pm
Here the MDF Mod melee weapon override tiles. Feedback appreciated. Most of them are from free to use fantasy tilesets I found with google, cropped, recolored and altered to fit. The '+' and '++' are from the mods upgrade system, 'superior' and 'legendary' versions of the same weapons. They are all 24x24 pixels, using tile #0-119.
(http://i.imgur.com/nzF0ipY.png)
There are a few weird ones, especially the gnomish high-tech weapons. Laser pistols and glue pistols, which are actually melee weapons, because their ranged attacks use itemsyndrome. They dont need quivers/ammo, so they are in this list.
Post by: Putnam on June 20, 2014, 10:44:35 pm
Post by: Meph on June 20, 2014, 11:38:15 pm
Done with the weapons. Now I have to test them all ingame, and probably recolor a lot of them. They all come with a pre-set color, but of course ingame the material color gets added, so I have to bleach most of them. Otherwise they might look too dark.
(http://i.imgur.com/f9OSBkq.png)
Some of the last ones are pretty bad... orcish society weapon kits, that take 2 or 3 weapons together. Ingame with 16x16 you will probably not be able to recognize the tile.
The 'R' stands for ranged, I added that to weapons people would otherwise not assume to be ranged weapons, like the ivy whip or mage staff.
The 'T' stands for training. I should probably recolor those to light-brown, since training weapons are always wooden.
EDIT: Ingame screenshot. As I thought, they are a bit dark. The darkest ones on the picture are made of steel. The light ones are silver/mithril. Brown is bronze/wood. The icons are compressed into 16x16 on the screenshot... with a 24x24 tileset they would look much better.
Spoiler (click to show/hide)
EDIT2: Multiple tilesets for different items do work. :) Here shields, buckler, round shield, kite shield, tower shield. In wood, mithril and steel. Also compressed to 16x16, shown with 200% zoom.
Spoiler (click to show/hide)
EDIT3: Last one for now. The actual tiles for the shields.
(http://i.imgur.com/zRqCdbf.png)
EDIT4: How are ballista bolts handled? Ballista ammo is a multi-tile object. And if multi-tile objects can be made, could this be used on creatures? You make 2 tiles for 1 creature. First tile is an overlay for the creature tile/sprite, while the second tile has a transparent background and goes above. Dwarves would only attack/hit the lower tile, and the upper tile would only be graphics... but it would be neat for megabeasts and other monsters. :)
Example:
(http://i.imgur.com/XAB4Pww.png)
Post by: PeridexisErrant on June 21, 2014, 02:09:39 am
Post by: mifki on June 21, 2014, 02:45:20 am
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. :(
Do you have PRINT_MODE set to STANDARD or VBO?
Post by: PeridexisErrant on June 21, 2014, 03:25:10 am
It's more-or-less working now, though there are some odd issues coming through occasionally: here's some pics (https://imgur.com/a/cCmBa)
- any dfhack interaction or popup, such as dfstatus or the new command-prompt, sets the whole screen to text. This then persists for some (mostly floor?) tiles until the view is moved several times. A similar thing happened when I used embark-tools when embarking, but I didn't take any screenshots.
- the pre-gen warning was half and half, for some strange reason
The interactions with dfhack are most problematic; since they're a lot worse for me than the readability of text and it's everywhere in the starter pack.
Post by: Meph on June 21, 2014, 03:50:14 am
Spoiler: Dark, No Background (click to show/hide)
Spoiler: Light, No Background (click to show/hide)
Spoiler: Light, with Floor Tiles (click to show/hide)
I cant offer any overwrides.txt because it will depend on your installation and raws. You will have to do those yourself. To replace the first weapon in the raws with the first item in the new tileset, the syntax is [OVERRIDE:47:I:WEAPON:WEAPON:0:2:0]. Interesting is only the 0:2:0. The first 0 is the first weapon in your raws, the 2 is the tileset number (as this is the third tileset you have after graphics and font, it has the number 2), and the last number is the tilenumber in the new tileset.
To replace the fifth weapon in the raws with the second weapon of the new tileset, the code would be: [OVERRIDE:47:I:WEAPON:WEAPON:4:2:1]
Hope someone can use those. At some point I will make the vanilla version anyway, once I have finished all the items. This includes armors, shields, instruments, and so forth.
Post by: mifki on June 21, 2014, 04:08:06 am
I will try to do that, but here comes another problem - dfstatus view is shown by a lua plugin and all such views share the same class, so if I don't switch to text mode for all of them, then fullscreen lua views (if they exist) will not be in text as well.
What other views apart from dfstatus not shown properly?
As for worldgen, again all these views (warning, parameters, worldgen with a map) are shown by the single view class and I didn't find a way to distinguish between them.
Post by: Meph on June 21, 2014, 04:32:10 am
I made a workshop, here the raws:
Code: [Select]
[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]
Now, this workshop I want to use with this tileset:
Spoiler (click to show/hide)
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.
Post by: PeridexisErrant on June 21, 2014, 04:32:53 am
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.
@Meph - I look forward to the vanilla tiles :)
Post by: Warmist on June 21, 2014, 04:34:41 am
There is also focus string, that tries to identify window and there is a field in some viewscreens that identify which sub-screen it is.
In lua it's "dfhack.gui.getFocusString(viewscreen)" it should be similar in c++.
Post by: Meph on June 21, 2014, 04:35:49 am
Quote
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.
Quote
@Meph - I look forward to the vanilla tiles :)Once I have something, I will make a new thread in the Tileset/Graphics section. :)
Post by: CLA on June 21, 2014, 05:20:39 am
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.
Seconded. Using the text tileset for map tiles was my plan anyway. The tileset you'd use for text has enough tiles for world map tiles too anyway. From the top of my head, there aren't any tiles that are used both in text and the embark screen world map anyway (Okay, except for the 'X' cursor and the up arrow is also used for conifer forests but that's not really a problem).
For text, you only need all the letters (including those with diacritics), punctuation, arrows and tile #219 for borders. Am I missing tiles?
Post by: Meph on June 21, 2014, 05:34:24 am
Quote
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.
Post by: CLA on June 21, 2014, 05:42:25 am
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.
Quote
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.
Still, a more or less ASCII-like map isn't too bad of a compromise.
Post by: Meph on June 21, 2014, 08:41:14 am
Preview: From top left to bottom right: Breastplate/Greaves/Gauntlets/Helm, Chainmail Set, Leather Set, Platemail Set, Set of Armok (special mod stuff from temples), Root Set (special mod stuff from Elves) with gnomish rocket boots, Clothing, different preview of hats (Hat Fortress, lol) with turban, head veil, hood, top hat, sombrero and chefs hat, and last part the succubus clothing. A mask, a corset, a thong and high(heeled) boots.
(http://i.imgur.com/8XbNzzI.png)
Again, three sets for people that want to use it:
Spoiler: Armor Items, dark (click to show/hide)
Spoiler: Armor Items, light (click to show/hide)
Spoiler: Armor Items, with background (click to show/hide)
Spoiler: Ingame Screenshot, 24x24 tileset... not statisfied with the background (click to show/hide)
Post by: PeridexisErrant on June 21, 2014, 08:49:00 am
Post by: Meph on June 21, 2014, 09:18:26 am
Without the floor background it looks much, much clearer. I am using a 24x24 version btw, I upscaled the 16x16 graphics tileset.
Spoiler (click to show/hide)
Post by: CLA on June 21, 2014, 09:31:57 am
Post by: Meph on June 21, 2014, 09:38:35 am
Very nice meph. Thank god I my work is a bit simpler with a symbolic tileset like CLA.Thats not even the issue. ;)
Just take a look at these two numbers: 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. :D
I opened this thread (http://www.bay12forums.com/smf/index.php?topic=139579.0), that way I can stop spamming around in here.
Post by: CLA on June 21, 2014, 09:53:14 am
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.
That reminds me, (probably a stupid question but I'm not particularly knowledgeable about dfhack and the raws) can we have separate graphics for a) the various Antmen castes and b) the various vermin creatures now?
Post by: Dutchling on June 21, 2014, 09:54:26 am
Post by: mifki on June 21, 2014, 10:24:47 am
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.
It's a bit trickier.. First, it reprocesses only tiles changed on screen. When map is scrolled, all tiles change, but otherwise most tiles are unchanged.
Then it checks the original tile number and if there any overrides for it. Then it gets a list of all buildings/items with the specified ids and checks their coordinates to match that tile and their types. So it's faster if there are less items with particular id in game, or less overrides for particular tile, and so on.
Post by: Meph on June 21, 2014, 10:26:04 am
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.
Mifki, here a couple of questions that popped up while testing.
- Ballista bolts. They are multi-tile. What happens to them?
- The fake-multi-tile creature idea I posted before. Possible?
- How to add override tiles to custom workshops?
- How to add override tiles to vermin? (I assume VERMIN:VERMIN:number in raws)
- To take up CLAs question: How to add caste specific override tiles to creatures? (this is a big one !!! Multi-race forts here we come.)
- Can CORPSEPIECEs be further identified somehow? A tooth should get a different tile than an arm lying around, or a leg, or a head.
- Can SKIN_TANNED be further identified somehow? Leather should look different from scale, or chitin, or shell.
- Broken ammo and ashes use the same tile in vanilla DF. I couldnt find any references in item_type.h. Can these be separated somehow? It always bothered me that they look the same.
- Up/Down-Stairs (the 'X' which is also text and bins)... can they be changed? I think this has been asked before, but I didnt see an answer. Guess its not that important, because you can override bins, use a text tileset for the 'x' and use a graphical tileset for stairs.
Sorry for such a wall of questions, but its exciting. So much can already be done. :)
Quote
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.
Post by: mifki on June 21, 2014, 10:30:36 am
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.
Well, I don't know. I didn't try to override tiles for custom workshops. Will they all have building id WORKSHOP_CUSTOM? If you give all its tiles different numbers you can add overrides for them and this building id.. I was going to make overriding tiles in workshops easier (by x/y coords) later...
Post by: Meph on June 21, 2014, 10:35:30 am
And I forgot the one and only, most important question of them all: Thinner text. Without TTF so many names are cut off, there must be a way to allow a square graphic tileset with a non-square text tileset. :-\
Post by: mifki on June 21, 2014, 10:41:15 am
Again, if map doesn't move, performance will not be affected. You can try to spawn large number of creatures that will move and cause tile updates.
You saw I experimented with different tilesizes for text and have some ideas for further experiments. But I really don't have much time and first need to finish what's already promised.
Post by: Meph on June 21, 2014, 10:56:09 am
I tested the workshops, it doesnt work atm. I used this code, which should fit to the raws/tileset I posted earlier. I guess custom workshop tiles do not work atm.:
Code: [Select]
[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]I also tried these three tags, none of which work.
Code: [Select]
[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]
Post by: CLA on June 21, 2014, 11:09:14 am
you can override bins, use a text tileset for the 'x' and use a graphical tileset for stairs.That's what I did.
(http://i.imgur.com/WrSvaYv.jpg)
Problem is, you're still left with the cursor having the same graphic as updown-stairs.
Post by: Meph on June 21, 2014, 11:14:49 am
Spoiler: Like this (click to show/hide)
Post by: CLA on June 21, 2014, 11:22:10 am
Mh.. I always imagined up/down-stairs as circular stairs.Spoiler: Like this (click to show/hide)
I prefer them the other way since in cp437, up stairs are <, down stairs > and up-down are X - or ><, in other words, an up together with a down stair.
Similarly, I like to have my up-down stair graphic be more or less identical to the up stair graphic together with the down stair graphic. That wouldn't really work with circular stairs.
Anyway, this is getting a bit off-topic. Sorry for that.
Post by: mifki on June 21, 2014, 11:22:41 am
Post by: Meph on June 21, 2014, 11:52:19 am
Code: [Select]
[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]
But I discovered something else. CLA or mifki, could you please confirm this, or correct me? I figured out why my items look so dark: There is no background color being applied.
(http://i.imgur.com/e0YFujw.png)
Post by: palu on June 21, 2014, 01:45:19 pm
Also, is it possilbe to have the items specified by id instead of number?
Post by: JRF2k on June 21, 2014, 02:21:02 pm
You've spoiled me now. I don't want to play without TWBT! :D
Post by: scamtank on June 21, 2014, 02:26:39 pm
Post by: JRF2k on June 21, 2014, 02:38:59 pm
He already released it, you twaddlebat.He did? For r5? Dang, how'd I miss it?!
I just started playing. :(
Post by: Razoric480 on June 21, 2014, 03:54:07 pm
A typical dwarf does any one of these things:
-Doing nothing
-Moving
-Hauling
-Doing a job
-Resting/sleeping/being unconscious
-Fighting
Throw in animated entities and it'd be quite the striking appearance.
Post by: Meph on June 21, 2014, 09:14:40 pm
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?
Currently you can only target by number. Might be that mifki adds/changes it to ID, but I really like the number thing. Made it super easy to write the override lines.
Post by: palu on June 21, 2014, 09:42:25 pm
Post by: Meph on June 21, 2014, 09:46:36 pm
Post by: mifki on June 21, 2014, 10:59:29 pm
But then it breaks when you add new stuff or change the order.
What breaks? Are we all talking about the same thing?
Post by: Meph on June 21, 2014, 11:13:20 pm
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?
If the new item is added at the bottom of the raws, everything is fine.
Post by: mifki on June 22, 2014, 01:25:37 am
Post by: Meph on June 22, 2014, 01:37:41 am
Post by: Meph on June 22, 2014, 04:19:27 am
Edit: I do have a request.
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?
I want to add it as an optional part to my mod, but the current setup makes it a bit difficult.
Post by: Meph on June 23, 2014, 04:35:36 am
Hardcoded tiles that could use new graphics:
Spoiler (click to show/hide)
Post by: PeridexisErrant on June 23, 2014, 04:44:47 am
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?
Post by: GavJ on June 23, 2014, 04:59:12 am
Post by: fricy on June 23, 2014, 05:09:34 am
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.
Milo's MLC tileset (http://dffd.wimbli.com/file.php?id=8648) is quite a step in that direction.
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?
Seconded, plus please add a check for the plugin, so it doesn't crash the game when it detects a non-opengl printmode. Until that I'm unable to include the plugin.
Post by: CLA on June 23, 2014, 05:31:00 am
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.
But the worst offenders (punctuation/text, bins/u-d-stairs/cursor, status indicators) and some useful ones (weapon types, armor) will get their own symbols. Most is already done, I'm just waiting for the new version of twbt and DF. Probably will do something with the new trees, too.
Post by: mifki on June 23, 2014, 05:59:55 am
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.
Post by: Warmist on June 23, 2014, 06:03:16 am
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.
Post by: PeridexisErrant on June 23, 2014, 06:29:28 am
Are you planning to add your code to dfhack repository?Please do this!
Post by: mifki on June 23, 2014, 06:31:04 am
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.
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.
Post by: Warmist on June 23, 2014, 06:40:16 am
Post by: mifki on June 23, 2014, 06:51:31 am
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.
Post by: Warmist on June 23, 2014, 07:06:00 am
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.
Post by: Clownmite on June 23, 2014, 08:27:30 am
Post by: Footkerchief on June 23, 2014, 08:30:55 am
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.
Just a note -- you could maintain a personal fork of the DFHack repo to work in, and use pull requests to submit your changes to DFHack. This is a common collaboration pattern.
Post by: falcn on June 23, 2014, 08:41:14 am
(http://i.imgur.com/ML0beEcl.png)
...and thank you for your hard work, things that TWBT does already are simply amazing. MultiScroll plugin is awesome too!
Post by: Warmist on June 23, 2014, 10:08:37 am
Probably you don't do the "protect/unprotect" dance on unload.
Post by: WillowLuman on June 23, 2014, 11:56:58 am
Post by: GavJ on June 23, 2014, 03:13:09 pm
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)
Post by: Sergarr on June 25, 2014, 05:57:08 am
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)
You know that SDL that is currently displaying graphics is not written by Toady? It was the other person who since then has disappeared. He was also planning to add these features in 2010.
Post by: Meph on June 25, 2014, 06:48:35 am
Post by: mifki on June 25, 2014, 07:11:48 am
Post by: Meph on June 25, 2014, 07:39:04 am
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.
Post by: Footkerchief on June 25, 2014, 09:06:54 am
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?
Post by: Meph on June 25, 2014, 10:01:06 am
Post by: Dirst on June 25, 2014, 03:24:21 pm
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?
Post by: mifki on June 25, 2014, 07:52:01 pm
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.
I'm not completely happy with this solution though.
I'll now add support for overrides based on tile types (and there's lot of them) and designations, and this will allow to override virtually everything. And I suppose you'll happily do this:) But that just doesn't seem right (mostly from the performance point of view of course) - first to render screen, then to re-render parts again for lower levels, then to apply overrides...
There's a known function (i.e. its address) that does map rendering (and it seems nothing else, but not sure). And Warmist has [incomplete] map rendering code in his offscreen module. It worth trying to combine these two things, but it's a very big work to implement our own map rendering to look like the original.
Post by: Dirst on June 25, 2014, 10:37:20 pm
Probably missing something really really basic about DFHack.
Post by: mifki on June 25, 2014, 10:41:01 pm
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.
See this post http://www.bay12forums.com/smf/index.php?topic=138754.msg5339685;topicseen#msg5339685 for the basic functionality. If you want overrides, copy overrides.txt to data/init folder and see instructions inside. You don't need to copy .h files anywhere.
Post by: Meph on June 26, 2014, 12:19:17 am
You copy any 2 tilesets of your choice from somewhere else into data/art.
You copy overrides.txt into data/init.
You copy twbt.plugin.dll into hack/plugins.
You open data/init and set PRINTMODE to STANDARD.
You find the four entries for tilesets in the init file:
Code: [Select]
[FONT:]
[FULLFONT:]
[GRAPHICS_FONT:]
[GRAPHICS_FULLFONT:]You add the tileset name you want to use for text to the first two.You add the tileset name you want to use for graphics to the last two.
Example:
You download Phoebus for graphics and Obsidian Soul for text. Make sure the names in the init fit the names of the .png or .bmp files in data/art, like this:
Code: [Select]
[FONT:Obsidian_16x16.png]
[FULLFONT:Obsidian_16x16.png]
[GRAPHICS_FONT:Phoebus_16x16.png]
[GRAPHICS_FULLFONT:Phoebus_16x16.png]Now you have text and graphics, but not yet item graphics. You have not yet used the overrides.txt. For this you need to make a new tileset yourself (or use tiles from other pixel artists), and make a third tileset, which you can name as you want. Lets assume that we only have one tile in that new tileset, a bin. And that you want to override the bin ingame, which is an 'X' with this new graphic.
You open a paint program, lets say Photoshop or Gimp.
You make a 16x16 tile png, 256pixel times 256pixels for a 16x16 pixel tileset with 16x16 tiles. The 16 tiles is a hardcoded limit, you need to do this. The pixels can be anything. If you want to make a 16x16 tile tileset with 24x24 pixels per tile, simply make a 384x384 png. Or a small 8x8 set would result in a 64x64 pixel png.
Once you have this file, you take the tile on the top-left, which is tile 0. The one next to it is tile 1, tile 2 and so on, till tile 255 at the very end. Note that it starts counting with 0, so you are always one number short.
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.
Now you save the file, calling it "Override Tileset - Example1.png", which can be any name you want. You put it into data/art.
You open overrides.txt in your data/init folder, and add this line:
Code: [Select]
[TILESET:Override Tileset - Example1.png:Override Tileset - Example1.png] Now it finds the new tileset. But it still needs to know what tile to overwrite with what, and especially only doing that for bins. That works with a second line, which looks like this: [OVERRIDE:Tile:Kind:Id:Type:Subtype:Tileset:NewTile]
OVERRIDE is the command, it will replace the tile with a tile.
Tile is the tilenumber of the item you want to replace. Bins use Tile '88'.
Kind is I, which stands for Item. Currently it only acceps I for item and B, for building.
Id is found in the item_type.h, which is just an info dump to help you find the right ids. In that case BIN
Type follows the same idea, items_other_id.txt shows you that in that case, its BIN as well.
Subtype you dont have for bins, so its nothing. Empty.
Tileset is the number of the tilesets you want to use. Obsidian is your text one, its 0. Phoebus is your graphics one, its 1, "Override Tileset - Example 1" is the third set you entered, so its 2. Again, counting starts at 0. You can add as many as you like.
NewTile is the new graphic tile the bin should take, in that case 0, because we used the top-left tile for it.
All in all that gives us:
Code: [Select]
[OVERRIDE:88:I:BIN:BIN::2:0]Now open DF while using Printmode:STANDARD and you are good to go. :)
Post by: SalmonGod on June 26, 2014, 12:30:08 am
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?
Post by: mifki on June 26, 2014, 12:32:32 am
Post by: Meph on June 26, 2014, 12:44:15 am
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?
Mifki: Thanks. :) If you want to copy/include it somewhere, feel free.
Post by: Dirst on June 26, 2014, 08:52:56 am
When I saw source code, header files and a makefile in the TWBT archive, you had me worried for a minute there.
Edit: The plugin was doing its thing just fine, it was just scaling my 9x16 font into 16x16 cells so I didn't recognize it. I'm also having a slapfight with my antivirus which keeps insisting that the Starter Pack Launcher and DFHack r5 are malware.
The in-game text has punctuation! Who knew? :)
Post by: fricy on June 27, 2014, 11:17:10 am
What I need at this stage is an r5 version that does not crash with 2D print mode, so I could package Meph's override graphics, and the legacy graphics too. Other override features will be handy, but what we have now is very nice, and I'd like to release it before we have a DF2014.
Post by: Meph on June 27, 2014, 11:23:08 am
Quote
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.
Post by: fricy on June 27, 2014, 11:31:35 am
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.
Post by: Meph on June 27, 2014, 11:40:41 am
Changing printmode makes much more sense.
Post by: falcn on June 27, 2014, 02:01:28 pm
Just imagine - readable text in DF! Unbelievable.
mifki, please, include the code in the next release.
Post by: scamtank on June 27, 2014, 02:05:42 pm
Post by: palu on June 27, 2014, 02:58:24 pm
Post by: falcn on June 27, 2014, 03:42:53 pm
Include? The whole thing is wide open on github already.Yep, missed the second branch, thanks for the tip
Post by: mifki on June 27, 2014, 06:58:36 pm
I'm planning to add proper checks to the current (non-multilevel) version so that you can include it in packs.
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. I have some ideas but first I need to finish with everything else.
Yes, source code is on github now, but I didn't announce this because it's in a very bad state right now, Windows version doesn't work at all yet. Once I have first working build, I'll announce that and you can test it.
Post by: falcn on June 27, 2014, 11:45:50 pm
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.
I was referring to this pic
(http://i.imgur.com/ML0beEc.png)
The text in the lower screenshot is more readable because letters are not square (yet the tiles are square!).
Maybe not as good as 2D/Truetype, but much better than what we have now.
Comparison (http://imgur.com/6U9Zbz3,QQg55LK#0) (press left/right)
Post by: GavJ on June 28, 2014, 01:00:04 am
Post by: falcn on June 28, 2014, 01:21:40 am
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)
Post by: Meph on June 28, 2014, 01:31:43 am
Post by: PeridexisErrant on June 28, 2014, 01:36:48 am
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.
Post by: Meph on June 28, 2014, 01:44:28 am
Post by: fricy on June 28, 2014, 01:46:43 am
Spoiler (click to show/hide)
Post by: mifki on June 28, 2014, 02:40:58 am
@mifki: Just letting you know that twbt.2.11-r5 doesn't load on 10.7.5.Spoiler (click to show/hide)
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.
Post by: mifki on June 28, 2014, 07:36:40 am
@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.
Post by: fricy on June 28, 2014, 08:17:06 am
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!
Post by: CLA on June 28, 2014, 08:18:02 am
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't get it to work on win7 64bit with r3 either.
(http://i.imgur.com/WNCaygk.jpg)
Edit: Yup, works fine with r4.
Post by: scamtank on June 28, 2014, 08:22:14 am
Great work, can't wait to see what you bring us next. I wouldn't mind deepening the shadows and seeing more than just one extra Z-level at a time.
Post by: Meph on June 28, 2014, 08:24:19 am
It shows one additional z-level. :)
Post by: mifki on June 28, 2014, 08:45:13 am
Post by: CLA on June 28, 2014, 08:55:08 am
Post by: mifki on June 28, 2014, 09:02:51 am
Post by: CLA on June 28, 2014, 09:13:35 am
Can you post screenshot and try without other plugins?
Spoiler (click to show/hide)
I'll try without other plugins in a moment.
Edit: Same thing with nothing but twbt in the plugin folder.
Another thing, DF crashes when zooming far out with mousewheel.
Post by: falcn on June 28, 2014, 09:24:38 am
I can only see one extra level (for a total of 3), too. r4, windows.r5, os x, I see ten
Post by: scamtank on June 28, 2014, 09:56:08 am
One!? It should show up to 10 levels and I see them on win r4 with my own eyes :)
The highest point on a snowy map:
Spoiler (click to show/hide)
I did away with the autoexec file, so nothing should be actively running interference. Tried it without any other plugins, too.
Post by: mifki on June 28, 2014, 10:07:37 am
Post by: scamtank on June 28, 2014, 10:12:25 am
Spoiler (click to show/hide)
This is the highest part of the thin stem of a tower that's much larger and wider at the top. Those shady bits are the only ones that are directly beneath the big observation deck.
Post by: lethosor on June 28, 2014, 10:17:51 am
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).
Post by: mifki on June 28, 2014, 10:21:36 am
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).
No, the code is just very dirty, like hardcoded 200 for map size, so it will crash for larger embarks when zoomed out :) So these are really not public versions currently, but people wanted to try..
Post by: Meph on June 28, 2014, 10:39:19 am
Post by: mifki on June 28, 2014, 10:47:13 am
I can upload a save, but its heavily modded when it comes to raws. But its certainly one zlevel extra, not ten.
That would be very helpful.
Post by: scamtank on June 28, 2014, 10:51:11 am
Post by: Meph on June 28, 2014, 10:59:37 am
Post by: scamtank on June 28, 2014, 11:05:35 am
Post by: mifki on June 28, 2014, 11:06:48 am
Post by: Meph on June 28, 2014, 11:11:03 am
Here the data/init and data/art folder as well: Download (https://www.dropbox.com/s/hfpy82xfdfcnock/data.7z)
Post by: mifki on June 28, 2014, 11:16:06 am
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)
As I thought, it's because SKY/CHASM is set to 178/250 instead of (default?) 32/0 in d_init. Will use correct values later..
Post by: Meph on June 28, 2014, 11:23:58 am
Post by: mifki on June 28, 2014, 11:25:49 am
The tilenumbers for those might change depending on the tileset people use. Can you make this an override option?
Yes, I mean I'll fix it and use the values from d_init later.
Post by: Meph on June 28, 2014, 11:33:34 am
Just wanted to let you know, I tested it again with the tile numbers you quoted and it works. Looks absolutely amazing, thank you. And Rendermax doesnt crash, either. It only displays the light on the currently active z level, but even so it looks good.
(http://i.imgur.com/mTqlcIa.png)
Post by: mifki on June 28, 2014, 11:38:11 am
(http://i.imgur.com/jfPf4vvl.png) (http://imgur.com/jfPf4vv)
(http://i.imgur.com/xH68Bnbl.png) (http://imgur.com/xH68Bnb)
And "camping at night in a forest" with rendermax also looks very nice indeed)
Post by: scamtank on June 28, 2014, 11:41:13 am
I also figured out how I accidentally killed it. If you don't "wake up" TWBT by using two different tilesets (either windowed or fullscreen mode), it doesn't activate the Z-level rendering either.
Post by: Meph on June 28, 2014, 11:41:28 am
The overlay shadow is a bit heavy on the blue I think. Neutral grey would fit better (?)
Edit: Without Rendermax is looks great on the surface, the misty blueish... but in the caverns its a bit off. The screenshots below are so dark because of Rendermax, your overlay shadow looks fine and very clear without Rendermax.
Spoiler: Cavern 1,2,3 and below. (click to show/hide)
The second cavern is supposed to be very blue, but 1 is green, 3 is gray and slade is black...
Post by: mifki on June 28, 2014, 11:50:42 am
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.
Post by: Meph on June 28, 2014, 11:56:50 am
Quote
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.
You know, this kind of detail:
Spoiler (click to show/hide)
Obviously unplayable if you zoom in that far, but for screenshots its pretty neat to have 64x tiles. 32x would be reasonable for both graphics and play I would assume.
Post by: scamtank on June 28, 2014, 12:05:57 pm
Spoiler (click to show/hide)
Post by: Putnam on June 28, 2014, 01:01:31 pm
Post by: Meph on June 28, 2014, 01:51:00 pm
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.
And the text of course. Which is super neat. :)
Post by: falcn on June 28, 2014, 03:41:36 pm
Aaaaaand my idea worked!Spoiler (click to show/hide)
Hooray for the KING!
You are awesome.
Post by: Actinide on June 28, 2014, 03:52:45 pm
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.
So I'm kind of dumb on this - is the fog/shadow per z-level or per tile? I'm wondering if it's possible to replace the 1..7 numbers for liquid depth with a flat color with variable lightness/alpha based on the number that would be rendered.
Post by: Meph on June 28, 2014, 04:27:52 pm
Post by: Actinide on June 28, 2014, 04:34:36 pm
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!
Post by: Meph on June 28, 2014, 05:03:38 pm
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!
Post by: Moridin920 on June 28, 2014, 09:11:32 pm
Still, looks really good.
Post by: mifki on June 28, 2014, 09:54:14 pm
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.
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.
Post by: mifki on June 28, 2014, 09:55:39 pm
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.
Oh, this.. Ok, I can have two different "fog" colours for above and below ground.
Post by: mifki on June 28, 2014, 11:36:20 pm
Post by: PeridexisErrant on June 29, 2014, 12:34:26 am
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.
Post by: mifki on June 29, 2014, 12:40:06 am
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.
Ok.
I'm just trying to understand is it worth working on separate text/graphic tile sizes, i.e. how many screens and other places would benefit from that.
Post by: scamtank on June 29, 2014, 01:14:04 am
How many screens are there in the game that'd benefit from being able to display more than one shape of tile, anyway? The main playing area (dwarf & adventure), the embark screen with the maps on it... what else?
Post by: mifki on June 29, 2014, 01:23:06 am
People were saying smaller font allows to see longer notifications.
dfhack screens can use full screen width - very helpful on labour management screen, on stocks screen (when it's fixed).
Trading screen is a big problem, I even made a patch to fix it on OS X.
What else?
Post by: Moridin920 on June 29, 2014, 01:46:30 am
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.
I'm pleasantly surprised to hear there's even any room for optimization, I figured it was just a function of rendering so many more things (like you said).
Is it possible to configure the amount of levels rendered? Could I tell it to render only say 3 levels beneath?
Post by: PeridexisErrant on June 29, 2014, 02:31:34 am
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.
Post by: mifki on June 29, 2014, 02:45:34 am
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)
I don't know what's wrong with it. It works with r5 on OS X, and this message doesn't seem to be about something I use explicitly in my code.
Post by: Putnam on June 29, 2014, 02:47:06 am
Post by: falcn on June 29, 2014, 02:53:23 am
Post by: Sergarr on June 29, 2014, 02:53:47 am
Anyway, great work here!
Post by: fricy on June 29, 2014, 04:03:48 am
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?
Post by: PeridexisErrant on June 29, 2014, 05:40:51 am
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?
Post by: fricy on June 29, 2014, 07:18:13 am
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?
Just a little photoshop hack'n'slash.
Phoebus was pretty easy, jut copy/paste tiles from Bisasam_16x16. Spacefox on the other hand...I used ComicSans to substitute the missing letters, and it's butt-ugly when zoomed in. Anyway it's just a temporary solution, I was using a pure 16x16 tileset, but because of the dfhack popup bug, when the screen reverts to the text tileset, I decided to make these to make the two tilesets as similar as possible, so the artifacts are less jarring.
The long term solution will be pure text tileset, 12x16 or 10x16, I expect mifki to tell us which works better when finished with the coding.
Post by: CLA on June 29, 2014, 07:18:58 am
Spoiler: note the axe and bin in the bottom left stockpile (click to show/hide)
Spoiler: looking from above (click to show/hide)
Will this change in the future?
Post by: mifki on June 29, 2014, 08:27:31 am
Will this change in the future?
I think so. I just forgot to account for "depth" when checking override conditions.
Post by: Baleur on June 29, 2014, 03:46:12 pm
Reading through 23 pages just to figure out how to simply get clear text in phoebus isn't !!FUN!! :P
1. Copy blahblah files.
2. Add to d_init.txt = blabla
3. Copy your favorite text tileset to blabla
edit: sorry im stupid, saw it :D
Post by: DrKillPatient on June 29, 2014, 04:53:32 pm
EDIT: Now, imagine Billy Mays is reading every in-game menu.
(http://i.imgur.com/EcJoeyQ.png)
Post by: Vherid on June 29, 2014, 05:32:50 pm
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)
All caps text, I can't believe I never thought of that.
Post by: Baleur on June 29, 2014, 07:07:52 pm
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.
Post by: Putnam on June 30, 2014, 09:39:16 am
EDIT: Holy crap you're using items.other for organizational purposes? That makes things way cooler. You can give separate tiles to dead playable races specifically, display recently dropped items differently and show melt designated items differently. You can even differentiate between murdered corpses and non-murdered corpses, as well as anything edible by kobolds (BONECARN) or whatever.
Post by: fricy on June 30, 2014, 11:09:15 am
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.
Spoiler: Phoebus with Guybrush font for TWBT (click to show/hide)
And I wasn't happy with the Spacefox text tileset, so here's a new one:
Spoiler: Spacefox 16x16 text tileset for TWBT (click to show/hide)
Post by: palu on June 30, 2014, 08:30:04 pm
Post by: lethosor on June 30, 2014, 08:38:19 pm
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.
Post by: palu on June 30, 2014, 08:52:19 pm
Post by: PeridexisErrant on June 30, 2014, 08:59:47 pm
Post by: mifki on June 30, 2014, 11:11:06 pm
Post by: PeridexisErrant on July 01, 2014, 01:11:35 am
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.
In the meantime, I checked the r5, 3.12 version and it crashes to desktop just like 3.11 did. :'(
Post by: mifki on July 01, 2014, 01:32:36 am
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. :'(
Crashes.. when?
Post by: PeridexisErrant on July 01, 2014, 01:48:16 am
Spoiler: details (click to show/hide)
Post by: mifki on July 01, 2014, 01:54:14 am
"The procedure entry point <blah> could not be located in SDL.dll"
Oh, this.. Yes, I have the same problem, and it's not fixed in 3.12 because I don't know how, it's weird message.
But it doesn't crash for me, just plugin isn't loaded.
Post by: Scoops Novel on July 01, 2014, 11:57:41 am
Post by: fricy on July 01, 2014, 04:01:02 pm
Spoiler (click to show/hide)
Post by: palu on July 01, 2014, 04:19:23 pm
Post by: mifki on July 01, 2014, 05:56:43 pm
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.
Post by: Quarterblue on July 01, 2014, 06:34:00 pm
Post by: GavJ on July 01, 2014, 07:08:05 pm
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.
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.
Post by: arbarbonif on July 01, 2014, 08:57:37 pm
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.
Post by: mifki on July 01, 2014, 09:12:33 pm
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.
Can you post an example screenshot (for the issue with liquids)?
Post by: mifki on July 02, 2014, 05:24:39 am
Any hope for a Linux build (or building instructions)?
Try 2.23 from http://build.mifki.com (it's the current stable version, without multilevel rendering).
Post by: falcn on July 02, 2014, 09:26:38 am
It won't load for dhhack-r5
Code: [Select]
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 binaryQuote
/Users/vit/Downloads/dfhack-r4/build/library/libdfhack.1.0.0.dylib
For dfhack-r3 it loads, but works like twbt-multilevel-3.12-osx - non-square tileset from distribution archive (ShizzleClean.png, 256 × 320) is rendered as square 16x16, and this part
Quote
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.
Post by: fricy on July 03, 2014, 04:30:13 am
Code: [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
Post by: mifki on July 03, 2014, 04:50:27 am
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
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 :)
Post by: scamtank on July 03, 2014, 04:52:10 am
That is to say, I'm already crashing it very regularly on game load (saved world and arena both).
Spoiler (click to show/hide)
The numbers in the DFHack console caught my attention. They were different on every attempt, but the overall pattern is the same. The first and the last of the long hex-style numbers were always identical.
Then I got the notion to really shut off features. Both FONT/GRAPHICS_FONT and FULLFONT/GRAPHICS_FULLFONT are the same now. The pattern shifted, but again stuck to the same order with slightly different numbers:
Spoiler (click to show/hide)
I'm using the r4 version. Ask me anything that might help.
Post by: mifki on July 03, 2014, 04:58:19 am
I'm using the r4 version. Ask me anything that might help.
Thanks but it just currently works only on OS X. Actually I really should disable builds for unsupported systems not to confuse people.
Post by: scamtank on July 03, 2014, 05:02:10 am
Post by: fricy on July 03, 2014, 05:30:12 am
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?)
-zoom only works on the edge of the screen, the rest of the tiles do not enlarge
-mouse positioning is off by a couple of tiles
if you use tilesets with different ratios:
-the map is resized correctly
-text tiles ?zoom in? - so essentially we can see the same ammount text as with square, only the letters are bigger. (I'm not sure about this one after a few tests, but that seems to be the case.)
Post by: mifki on July 03, 2014, 05:37:25 am
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?)
It's changed already, font is text, graphics font is graphics, as per readme file.
Mousequery positioning will be off until I make a special version of it that will take correct tile size from my plugin.
When game loads, press TAB, otherwise map doesn't take full space.
Otherwise it should be more or less playable.
Can you set font and graphics_font to font/graphics tilesets with distinct different sizes and post a screenshot?
Post by: fricy on July 03, 2014, 06:20:15 am
Can you set font and graphics_font to font/graphics tilesets with distinct different sizes and post a screenshot?
Ok, now I can see the difference in rows, but the width and the number of letters remains the same. 10x15 tileset looks quite promising. Sorry for the large images, imgur played a trick on me... :(
Spoiler: Depo and text (click to show/hide)
Spoiler: Joblist (click to show/hide)
Post by: mifki on July 03, 2014, 06:25:45 am
So it's easy to see that 10x15 font looks nicer, menu has smaller width leaving more space for the map, and on job list screen no text is truncated.
Post by: mifki on July 03, 2014, 08:23:20 am
Post by: Meph on July 03, 2014, 08:25:29 am
Quote
so there will be a build with different tile sizes to try on WindowsCool. Anything you want to have tested?
Post by: falcn on July 03, 2014, 09:48:11 am
I'm puzzled with the previous message from falcn that this version does nothing :)
I am as puzzled as you are.
Here are R3 and R5 running side by side.
(http://i.imgur.com/w3YsppZl.png) (http://imgur.com/w3YsppZ)
R3 is using twbt-nextgen-4.14-osx.zip, which is evident by absent multilevel at the moat.
R5 is using twbt-multilevel-3.12-osx.zip (4.14 won't load)
Both are using Phoebus_16x16.png + ShizzleClean.png from twbt archive (256 × 320).
init.txt is the same.
MD5 (Dwarf Fortress r3/hack/plugins/twbt.plug.so) = 8776e978ec438d1e04c5614a9c0f274f
MD5 (Downloads/twbt-nextgen-4-2/dfhack-r3/twbt.plug.so) = 8776e978ec438d1e04c5614a9c0f274f
Post by: molkemon on July 03, 2014, 10:28:02 am
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.
I will now spam f5 on your build repo until the update is out :D
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^^
Post by: mifki on July 04, 2014, 12:58:14 am
Both are using Phoebus_16x16.png + ShizzleClean.png from twbt archive (256 × 320).
init.txt is the same.
ShizzleClean is a bit tricky because it has the same 16px width as graphic tiles, but is taller so it requires bigger window to fit minimum 25 rows. On your screenshot it looks like window height is enough though.. But also it's retina, I don't know if it may cause any problems.
So, can you just try with, for example, curses_800x600.png from any ASCII tileset - it's small, so you will easily notice the difference?
Post by: Scoops Novel on July 04, 2014, 05:01:53 am
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.
Post by: mifki on July 04, 2014, 05:13:37 am
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.
Post by: Scoops Novel on July 04, 2014, 11:18:45 am
Post by: mifki on July 05, 2014, 12:38:03 am
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.
Post by: molkemon on July 05, 2014, 01:41:34 am
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.jpg
At the very bottom you can see a road I built into the mountain, and which is actually there, so it is actually doing something right... very weird
When I went up to a z-level in the sky where no layers would be rendered at all, Dwarf Fortress crashed.
That's it for now. Generally very nice, the main functionality is working nicely^^
Massive optimization idea: I am very bad at coding and what I say now is probably nonsense, BUT: as far as I understand how this works is that you look at the game memory to where what should be and then tell the renderer to render something different than it normally would. Now my idea: Would it be in anyway possible to take that same information from memory, replace it with basically NOTHING and instead use an external executable for rendering? So you make an executable which displays what should be rendered, it would look exactly like being rendered in DF itself, all input would be relegated to the df main executable. The advantage of this would be that the OS would automatically assign this second executable it's own cpu thread/core. And if you replace whatever DFs rendering should show with nothing, that should free up a LOT of cpu for the main exe to do other stuff (pathfinding etc), in theory drastically boosting FPS.
At least the part where you just replace all rendering with nothing/black squares should be somewhat easily testable just to look how much FPS would increase if rendering would not be done on the same cpu core.
Post by: scamtank on July 05, 2014, 03:18:01 am
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.
You're dear to us, don't forget that.
I can also confirm the sky crash. It happens from multilevel 1 to multilevel 15, on crowded mountain forts and fresh meadow maps. As soon as there's nothing on the same Z-level, it goes down.
Post by: mifki on July 05, 2014, 03:22:55 am
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. Please read readme, likely to contain bugs, blah blah... Oh, also for OS X there's a build of multiscroll-nextgen to complement twbt-nextgen.
Post by: scamtank on July 05, 2014, 03:26:14 am
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.
(http://i.imgur.com/aVhnrJ5.jpg)
Post by: fricy on July 05, 2014, 03:29:40 am
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
Quote
When I went up to a z-level in the sky where no layers would be rendered at all, Dwarf Fortress crashed.
Quote
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. :(
Post by: mifki on July 05, 2014, 03:30:06 am
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.
I don't want anyone to notice stupid mistakes I sometimes make in my code ;)
Post by: mifki on July 05, 2014, 03:36:51 am
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. :(
Actually I need to find the place in DF rendering code where it tries to render treetops and all such things for lower levels and disable it. Then I need to further optimise my code so that it renders the least possible area for each level. And then it would be quite close to what can be achieved with "proposed" way in most cases.
Post by: molkemon on July 05, 2014, 06:11:45 am
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.
Post by: fricy on July 05, 2014, 06:35:26 am
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.
Post by: lethosor on July 05, 2014, 07:27:49 am
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.
Post by: mifki on July 05, 2014, 07:41:28 am
First we need to distinguish between rendering of the current game screen into some buffer, including cpu-intensive rendering of the world map (let's call it screen rendering) and rendering of this buffer onto screen (which can be via OpenGL, text-only, "2D" mode, let's call it graphics rendering).
In the game there are two threads. On the second thread graphics rendering is performed along with some preparations, depending on the rendering mode. Also for example, overrides in my plugin are processed on this thread. In general this thread uses little CPU resources because most work is done by GPU.
However screen rendering is performed on the first thread, which also runs the game itself. Technically, graphics rendering thread sends a message to the main thread to call current screen's render() method. This is simply a synchronisation measure - world must not change while we're rendering it.
So, in short, it's multithreaded but that doesn't help much.
Post by: Meph on July 05, 2014, 08:52:57 am
(http://i.imgur.com/YlxYpkz.png)
Post by: molkemon on July 05, 2014, 08:55:37 am
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.
I also checked with process explorer, DF in windows uses 10 threads, most of them seem to do nothing at all though. One of the threads is being relegated to my ATI/AMD device driver, presumably that's the opengl rendering, it uses less than 1% cpu and also runs on a different core as mentioned before.
Post by: mifki on July 05, 2014, 09:10:06 am
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.
Post by: mifki on July 05, 2014, 09:39:21 am
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:
Try build 3.17.
Post by: mifki on July 05, 2014, 11:16:47 am
Post by: Meren on July 05, 2014, 11:59:49 am
Post by: Meph on July 05, 2014, 12:02:08 pm
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.
Post by: Meren on July 05, 2014, 12:15:36 pm
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.
That fixes it. Thanks! By default, they were set to 178 and 250. I didn't know I had to change them.
Post by: scamtank on July 05, 2014, 12:19:50 pm
Post by: lethosor on July 05, 2014, 12:41:14 pm
Post by: mifki on July 06, 2014, 08:44:50 am
And nextgen branch got multilevel rendering in 4.17.
Post by: Footkerchief on July 06, 2014, 09:44:31 am
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.
Post by: pingas on July 07, 2014, 01:05:38 pm
(http://i.imgur.com/W1YTcyu.png)
Post by: shaver on July 07, 2014, 02:41:07 pm
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.
This is the classic race-condition scenario. The render thread has references to objects that the main loop is mutating (such as removing goblins that die, or changing a dwarf's state so they no longer have a job pointer; these examples are unburdened by the specifics of the data structures, but I'm pretty confident that such pointer updates occur), leading to crashes and other fun.
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.
Post by: Footkerchief on July 07, 2014, 03:11:11 pm
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.
Post by: milo christiansen on July 07, 2014, 04:07:08 pm
Post by: lethosor on July 07, 2014, 04:27:21 pm
Post by: milo christiansen on July 07, 2014, 04:43:17 pm
(I assume these binaries are for r5?)
Post by: scamtank on July 07, 2014, 04:44:12 pm
Post by: milo christiansen on July 07, 2014, 04:46:22 pm
Post by: mifki on July 07, 2014, 05:16:05 pm
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.
Well, things could be done differently but for now it does't work this way, it's pointless to discuss this as it's unlikely to change anytime soon.
Ah, Thank you (maybe that should be linked in the readme?)
There was a link "automatic builds" in the first post, I now renamed it to "development builds" for clearness.
Post by: Scoops Novel on July 08, 2014, 11:34:37 am
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?
Post by: Mike Mayday on July 08, 2014, 04:27:28 pm
Is it just me or is obliterating the minimum of 80 horizontal tiles displayed the only thing left to do for a more or less proper full graphics support?
Post by: scamtank on July 08, 2014, 04:32:22 pm
(http://i.imgur.com/qkmc63E.png)
Post by: Mike Mayday on July 08, 2014, 04:52:54 pm
Basically so that we can use, for example, 24px icons in a 1680px resolution.
Post by: mifki on July 08, 2014, 05:01:48 pm
In 0.40.01 there are also many new configurable tiles for trees and new tiletypes, it's good twbt allows to utilise now unused tiles (eg. with letters) in graphics tileset for them.
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.
Post by: Descan on July 08, 2014, 05:11:20 pm
Post by: scamtank on July 08, 2014, 05:25:55 pm
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.
Yeah, that's not a mockup. I did that to genuinely give it the beans and see if it broke.
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!
Post by: mifki on July 08, 2014, 05:30:04 pm
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!
Hm, that shouldn't happen. I'll try to resize tileset and test specifically on Windows...
Post by: Mike Mayday on July 08, 2014, 05:53:16 pm
Well, off to work I go then!
Post by: mifki on July 08, 2014, 06:17:12 pm
Oh holy crap, I thought that's a mockup!
Well, off to work I go then!
And multilevel rendering was implemented after your mockup (at lease we think it was yours) :)
Post by: sic8 on July 08, 2014, 07:53:27 pm
Post by: mifki on July 08, 2014, 08:09:09 pm
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?
Post by: sic8 on July 08, 2014, 08:52:32 pm
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...).
With all the characters freed up in the graphics png due to TwbT and assignable tiles for trees in .40 there's plenty of room for gfx artists to make some beautiful stuff. If branches/leaves/trunks on different layers could have alpha transparency it would look even better.
Post by: Authority2 on July 09, 2014, 01:31:30 am
Post by: mifki on July 09, 2014, 05:03:14 am
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.
Post by: Dirst on July 09, 2014, 03:59:22 pm
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.
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.
Post by: mifki on July 09, 2014, 05:28:05 pm
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.
Currently plugin just uses original DF map rendering function - this is the easiest, straightforward and safe way if you just want to render several levels and merge them into one buffer for display.
Technically there's no problem not to use DF code for rendering at all and implement your own rendering. It's just a big work. Warmist has some map rendering code in his Offscreen module, maybe I'll try to squeeze it into my plugin and see what happens. Or maybe someone else will want to work on rendering.
Post by: Footkerchief on July 09, 2014, 05:51:50 pm
Post by: Dutchling on July 09, 2014, 06:03:34 pm
Post by: mifki on July 09, 2014, 06:07:48 pm
So, is it safe to not understand anything that goes on in this thread and just wait for the next version of dfhack?
It depends.. This plugin is not a part of dfhack)
Post by: Snaaty on July 10, 2014, 03:45:29 am
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?
Post by: mifki on July 10, 2014, 04:21:26 am
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?
What version did you download, are there any error messages in red in console when starting df?
Post by: mifki on July 10, 2014, 08:17:32 am
(http://i.imgur.com/MLMVZsZ.png) (http://imgur.com/MLMVZsZ)
Post by: Mike Mayday on July 10, 2014, 08:40:20 am
Post by: mifki on July 10, 2014, 08:46:51 am
Hey mif, is there a chance you could hijack the way the ramp icons are displayed? (to make it dependant on their surrounding terrain)?
I think yes, I'm checking surrounding tiles to draw shadows anyway..
Post by: Mike Mayday on July 10, 2014, 09:24:46 am
This is the slopes graphics I'm hoping to use BTW http://goblinart.pl/files/DF/slopes.jpg
Post by: mifki on July 10, 2014, 10:15:27 am
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?
Post by: mifki on July 10, 2014, 10:43:34 am
Post by: palu on July 10, 2014, 10:44:17 am
Post by: scamtank on July 10, 2014, 10:46:20 am
Post by: palu on July 10, 2014, 11:02:47 am
Post by: Mike Mayday on July 10, 2014, 05:03:05 pm
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
Post by: mifki on July 10, 2014, 06:06:44 pm
EDIT: okay, here we go.
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?
Post by: mifki on July 10, 2014, 06:10:53 pm
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.
Post by: Mike Mayday on July 10, 2014, 06:32:33 pm
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?
I actually believe shaded slopes require shadows too! In the mockup above, I think they help a lot to show different layers.
I'll do another mockup of the problem you're describing, we'll see how it looks.
Post by: Mike Mayday on July 10, 2014, 06:33:28 pm
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'm willing to do it, but only once everything is done for the main dwarf mode. So, a song of distant future.
Post by: Clownmite on July 10, 2014, 09:23:36 pm
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.
Post by: mifki on July 10, 2014, 09:40:58 pm
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?
Post by: Clownmite on July 10, 2014, 09:55:35 pm
Which version do you use? Any issues?
I used the version included in Masterwork for a bit, I hadn't had any issues but I haven't had much time to play lately. I'll likely put more time into it once DF2014 has stabilized a bit.
Post by: Rose on July 11, 2014, 01:41:18 am
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
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.
Post by: PeridexisErrant on July 11, 2014, 02:45:42 am
Post by: mifki on July 11, 2014, 03:37:00 am
Does the nextgen branch work on windows with dfhack-r5?
Yes, works for me.
dwarfmonitor plugin may crash the game though, haven't looked yet what happened to it in r5.
Post by: Mike Mayday on July 11, 2014, 03:51:14 am
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?
Post by: mifki on July 11, 2014, 08:59:09 am
Version nextgen-4.22 got the same, plus a command to adjust map tile size.
See readme for details.
Multilevel branch will become the main branch tomorrow. In preparation for that, multilevel rendering is now disabled by default, use `multilevel <0-15>` command to enable it.
Post by: Dirst on July 11, 2014, 10:09:01 am
This could be handled as a single override entry, a "flat ground" type character that picks up the colors of the underlying ramp and gets shaded as Mike illustrated. There are a couple more possibilities that need to be handled as well like single-tile pits.
I can also see a gradient that smoothly goes from the upper level's brightness to the lower level's brightness.
If the override is not present, then just go with the up and down ramps in the tileset.
Post by: Rose on July 11, 2014, 10:29:16 am
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?
That's the plan, yes.
[EDIT] Actually, to clarify, most likely the DF screen would be sent over to the visualizer, and merged there, so you play DF from the visualizer directly.
Post by: SMASH! on July 11, 2014, 12:14:22 pm
Post by: Mike Mayday on July 11, 2014, 04:46:09 pm
Post by: salithus on July 11, 2014, 08:59:08 pm
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?
Here's what I did (Windows 8.1 x64)
* Used DF Starter Pack to set my graphics to [16x16] Phoebus 34.11v05 for TwbT
* Downloaded twbt-multilevel-3.24-win.zip from http://do1.mifki.com:8810/dashboard
* Extracted zip.
* Moved twbt.plug.dll from \dfhack-r5 to DF\hack\plugins
* Moved shadows.png from \ to \DF\data\art
Spoiler: result (click to show/hide)
Post by: SMASH! on July 12, 2014, 01:09:12 am
Win 7 6.1. service pack 1.
Post by: mifki on July 12, 2014, 01:57:53 am
Moved all files, but nothing. Also, it was said that the pack already includes this plugin.
Win 7 6.1. service pack 1.
Any errors in red in the console when you start DF?
If you downloaded the latest package (3.24) you need to manually activate multilevel rendering by executing "multilevel 5" (or other number 1-15) in the console.
Post by: SMASH! on July 12, 2014, 02:10:56 am
Post by: mifki on July 12, 2014, 02:27:24 am
Never used console before. What should I write and and where can I find these arrows?
Download twbt-multilevel-3.25-win.zip from http://build.mifki.com (I just made some fixes there) and install the plugin, make sure you install the correct version for your dfhack release.
Then, when you launch DF, two windows will open - one for the game, and another with some text - it's the console.
Check if there any errors in red colour in the console. Then, load a game, go to some area where multiple levels should be visible, and in the console window write "multilevel 5" (without quotes) and press Enter.
Post by: SMASH! on July 12, 2014, 02:53:14 am
Post by: mifki on July 12, 2014, 09:41:32 am
Post by: Clownmite on July 12, 2014, 10:49:26 am
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.
Post by: mifki on July 12, 2014, 10:57:58 am
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.
Right.
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.
Post by: Clownmite on July 12, 2014, 12:26:14 pm
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.
Oh, I thought I saw some experimental adventure mode support earlier on in the thread. And yeah, I just realized changing the query tools are probably beyond the support of this rendering hack.
Post by: Vattic on July 12, 2014, 12:33:23 pm
Post by: SMASH! on July 12, 2014, 01:33:30 pm
Post by: dennislp3 on July 12, 2014, 02:42:35 pm
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
Post by: Dirst on July 12, 2014, 02:48:27 pm
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
Post by: dennislp3 on July 12, 2014, 02:51:01 pm
Post by: CLA on July 12, 2014, 03:16:46 pm
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.
Post by: dennislp3 on July 12, 2014, 03:19:15 pm
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 >.>
Post by: CLA on July 12, 2014, 04:39:15 pm
sounds familiar >.>
Hehe, I had the tab open for a while and didn't see (or bother to check) that you replied in the meantime.
Post by: KevinCathcart on July 12, 2014, 08:01:42 pm
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'd like to add a way to have a key toggle the overlay on and off, without having to fully start and close the stonesense plugin, but I wanted to release what I had in the interim. I do not plan to provide builds, but have submitted a pull request (https://github.com/DFHack/stonesense/pull/21) to have my update merged in.
Edit: Nextgen might not be properly supported. It is definitely the case that if tiles above or to the left of the main fortress view have their size changed, the overlay will not display right. I'll investigate some, and post my findings. Ideally there would be some way for TwbT to supply size information that stonesense could read. That would require some way for DFHack plugins to detect each other and share data, and I'm not sure that exists.
Lastly, my update is definitely not compatible with rendermax. It may crash, although my minimal testing simply had the display go crazy.
Post by: PeridexisErrant on July 12, 2014, 08:36:25 pm
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").
Wow. Things just keep getting cooler around here :D
Post by: mifki on July 12, 2014, 08:38:40 pm
I suppose stonse doesn't disable the game renderer and it continues to work hidden by the overlay? In this case I'll add a command to disable rendering, this will save significant amount of cpu resources.
I just addeda way to determine nextgen twbt is running yesterday and then other plugins may get tile sizes from it. I'll document this soon. However twbt changes tile size of map tiles, but tiles above and to the left has the usual size (renderer->dispx in case of opengl).
Post by: Vattic on July 12, 2014, 10:53:35 pm
Edit: I only mention this because there was mention of a similar problem with showing caverns without their roofs in the stonesense thread.
Post by: KevinCathcart on July 13, 2014, 02:29:26 am
Since that sounds like a longer term project, my code in the current form can still be compiled against r5, and used with DF2012. Mifki, since you have development environments for all three platforms set-up, perhaps you could create some builds of what I have for people to try? (https://github.com/KevinCathcart/stonesense/ branch OpenGL) I.E. a short term fork for those of us still playing DF2012 while Japa undertakes his stonesense restructuring. It sounds like there will not be a stonesense for DF2014 until that restructuring is complete, and I imagine it will take some time. Probably at least a few weeks, perhaps longer.
Also some technical details behind how my ssense overlay OpenGL mode works for mifki and others interested:
Spoiler (click to show/hide)
Post by: PeridexisErrant on July 13, 2014, 03:01:04 am
Post by: mifki on July 13, 2014, 03:57:53 am
Yes, I thought there might be a function for this in dfhack... However I see vmethod_pointer_to_idx on Windows uses some complex magic that I don't understand, so not sure what's better) But I'll consider using it anyway to get rid of some #ifdefs, thank you.
There are several ways of resolving incompatibility with the nextgen branch, I'll think about that later.
Post by: Warmist on July 13, 2014, 05:12:30 am
Post by: mifki on July 13, 2014, 05:35:01 am
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.
What are you talking about?
Post by: Warmist on July 13, 2014, 06:01:29 am
Post by: Mayama on July 13, 2014, 07:19:41 am
Post by: mifki on July 13, 2014, 08:13:18 am
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.
Ok, so...
In the first version (what was the main branch until recently) I was saving address of certain vmethods, and replacing them in the original renderer vtable with my functions - that was the easiest way because I needed only to hook 2 vmethods. Then, on OS X and Linux I can just call the original vmethods as normal functions because on these systems "this" pointer is just passed as the first function argument. However on Windows the calling convention for vmethods is different from normal function calls, so assembler code was required.
In the current version I use different approach. I made my renderer inherit from renderer_opengl, and I added several dummy vmethods to it. Then I copy entire vtable from the original renderer to my object except for vmethods I want to override, and set original addresses of overriden methods instead of those dummy vmethods. Finally I copy all data fields from the original renderer to my object and set my object as the renderer. Old renderer is not needed anymore. This allows me to call original vmethods without any tricks and doesn't require copying screen* fields between old and new renderers each time like you do in rendermax, and I got rid of assembler code (to make you happy:) ).
There's nothing wrong in doing this, dfhack is doing more terrible compiler-specific things with vmethods, including things I don't understand (as I'm not a C++ developer) like virtual_identity::get_vmethod_ptr and functions it calls.
Post by: Spectre Incarnate on July 14, 2014, 12:48:13 am
..about.
._.
Wait, w..ww.. what? WHAT?! NO WAY?! You're joking... this has to be a joke. April Fools? (No.. it's not April, ya dork.) Then this is real?!
Haha, I love how he's all "Hey guys, I did a thing" like it's no big deal, and we're all like...
Dancing on the Ceiling!
https://www.youtube.com/watch?v=OdQDXs75Ulo
Dude, do you have any idea how long we've all waited for more tileset support? (And for how dumb we all feel for not thinking of this?)
Mifki the Wizard Dwarf has come to the fort!! All hail Mifki!! You are my new five-letter god! To HFS with that Armok guy. >_>
Post by: Natti on July 14, 2014, 09:34:00 am
Spoiler (click to show/hide)
Post by: PeridexisErrant on July 14, 2014, 09:47:14 am
Post by: fricy on July 14, 2014, 09:51:04 am
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)
AFAIK that's intentional, the lava is lower than your current viewpoint, so there's a "fog" rendered above that makes it blueish. I'd say there's about 3-5 z-levels of air above the magma. You can use this commands in the dfhack window to change it:
Code: [Select]
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.
Post by: PeridexisErrant on July 14, 2014, 10:08:06 am
Post by: fricy on July 14, 2014, 10:24:05 am
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.
Post by: Footkerchief on July 14, 2014, 10:46:05 am
Post by: Natti on July 14, 2014, 10:48:26 am
Post by: salithus on July 14, 2014, 12:26:21 pm
A good start might bemaking the magmapainting the roses red?
couldn't help myself
Post by: scamtank on July 14, 2014, 12:29:31 pm
Spoiler (click to show/hide)
The weirdest thing is that only the descriptions of engravings in the fortress are mooshed to the side like this. Item descriptions, dwarf info and artifact textwalls are all fine. Thoughts?
Post by: falcn on July 14, 2014, 02:52:43 pm
I found another thing that's kinda fucked:Actually, I find it much easier to read on my 15" screen than "normal" version.
Try it fullscreen
(http://i.imgur.com/IVUhCNt.png)
Post by: mifki on July 14, 2014, 05:39:47 pm
I get the same effect in the middle of the volcano, with lava on the current level and every level below.
Are you sure? So if you look at this tile, it says "magma flow" and doesn't say "open space"? Sorry to ask, but so far I can't see anything wrong myself so far.
Post by: PeridexisErrant on July 14, 2014, 07:35:03 pm
It says both "magma 7/7" and "open space", so I'm not really sure what's going on.
Post by: mifki on July 14, 2014, 08:30:05 pm
Anyone knows the details how liquids work?
Post by: Footkerchief on July 14, 2014, 08:44:30 pm
Post by: mifki on July 14, 2014, 09:09:18 pm
As far as I know, "Open Space" just means "there isn't a wall or floor here".
This seems to explain things, thanks. I'll fix it soon.
Actually, I found a way to disable original df rendering of lower levels (treetops, liquid on lower level, etc.), so the code will get simpler in the the plugin (now I have to check for several symbols that can represent lower level tiles) and all such problems will be gone anyway, and the performance will be better.
Post by: mifki on July 15, 2014, 05:48:45 am
Post by: Natti on July 15, 2014, 06:05:12 am
Post by: fricy on July 15, 2014, 06:51:01 am
Spoiler: Bridge in construction, blinking (click to show/hide)
Spoiler: Rendermax lights seem to ignore z-levels, screenshots of the same area (click to show/hide)
EDIT: Additional testing: 3.24 works correctly, but 3.27 does not. These problems only happen with multilevel rendering enabled in the plugin, if I only play with overrides it works correctly.
Spoiler: Few more screenshots, different map: (click to show/hide)
Post by: mifki on July 15, 2014, 08:47:27 am
Post by: milo christiansen on July 15, 2014, 10:43:51 am
It would be best if ramps always rendered as down ramps except for ramps on the current level.
Post by: Hommit on July 15, 2014, 11:14:01 am
and the bluish splotches. I have no idea where those spots come from, there's nothing below except for unrevealed tiles.maybe unrevealed water?
Post by: mifki on July 15, 2014, 06:18:51 pm
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.
Magma bug is fixed.
I think the way I render ramps is better but I'm ready to discuss. My points are:
1. In real world there are no "down ramps" and "up ramps". Without multilevel rendering they just had to be rendered differently so that you can see where they lead. But why to use two symbols for one object with multilevel rendering?
2. More important, even in the game, as we know, there's no such object as "down ramp". Ramps belong to the lower level. There's a designation to remove up ramp, not down ramp (and if I ever make it possible to designate or otherwise select tiles from lower levels this will be important). And also, creature can't stand on a down ramp, once a creature steps onto a down ramp it belongs to the lower level. As a consequence, if I render all ramps as down ramps, creatures on these tiles won't be visible, and when moving they will disappear and appear only when moved to the next tile.
However if you provide a screenshot when my rendering is confusing, I may change my mind, or at least add a command to switch between "all ramps are down" and "all ramps are up".
Post by: Footkerchief on July 15, 2014, 06:30:36 pm
Post by: Phoebus on July 15, 2014, 06:46:01 pm
As for being misleading, ramps are not more misleading that any other tiles. The problem is that the current settings are optimized to create more attractive screenshots. There's only a subtle tint difference between z-level. It's pretty, but it's not easy to tell which z-level a tile is on.
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.
Post by: mifki on July 15, 2014, 06:55:07 pm
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?
Post by: Footkerchief on July 15, 2014, 07:51:55 pm
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?
Fog is currently linear with regard to depth, right? Could add extra contrast between z = 0 and z = 1.
Post by: PeridexisErrant on July 15, 2014, 08:05:43 pm
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?
Post by: PeridexisErrant on July 15, 2014, 08:37:33 pm
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.
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.
Post by: mifki on July 15, 2014, 09:35:36 pm
Honestly, I'm not working on adv mode now, but eventually I will. There are some difficulties with it, so the way of rendering above levels will be the least of them.
The most important thing I want to know now is about the branch with non-square text tiles.
Obviously it provides better user experience, has cleaner, better structured and faster code (because map rendering is separated), and I personally want to focus on this branch.
However there are some difficulties. First, special versions of some plugins will be required (at least mouse query, building plan, then rendermax again). I'll make versions that will work both with and without twbt, and will provide a way for plugin authors to know if twbt is running in this mode and get required data from it. But still this may cause some complications for players and package makers.
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.
Post by: Mike Mayday on July 16, 2014, 02:56:48 am
As for occlusion: I've found that an opacity of 25% for the fog one level below is quite enough, then an additional 15% for each level lower.
Post by: scamtank on July 16, 2014, 03:37:55 am
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.
Post by: mifki on July 16, 2014, 03:41:31 am
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.
Post by: CLA on July 16, 2014, 04:30:18 am
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.
On a related note, what I do care about a lot is that maps are square.
Post by: Rose on July 16, 2014, 04:32:38 am
Isoworld already kinda half does it.
Post by: Mike Mayday on July 16, 2014, 05:59:30 am
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.
In that case, break all you wish I say. Larger map tiles with smaller interface tiles are number two on my wishlist (number one, separate object tilesets, you've already completed, oh glorious one!).
Post by: CLA on July 16, 2014, 06:34:28 am
I guess I really need to get onto making a proper map visualizer then.
Isoworld already kinda half does it.
Isoworld is amazing, and I can't wait to see the new trees. Still, I think a map visualizer that runs inside DF would be better as top-down.
Post by: Rose on July 16, 2014, 06:45:06 am
Top-down isn't the best at showing elevations.
Post by: Dirst on July 16, 2014, 10:52:45 am
Does anyone have a handle on why the core game makes such odd distinctions? Even if the font issues got resolved in the core game, that would still leave plenty of scope for the multi-level visualization work that mifki has also done an amazing job tackling.
Post by: Dirst on July 16, 2014, 10:59:18 am
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.
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.
Post by: mifki on July 16, 2014, 06:01:59 pm
Even if the font issues got resolved in the core game
The biggest problem I see with TTF is that it must be done in a way accessible from dfhack/plugins (and now it's not), otherwise dfhack screens will be still in tiles.
Post by: mifki on July 16, 2014, 06:07:42 pm
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.
Post by: Mike Mayday on July 16, 2014, 06:17:38 pm
Post by: Clownmite on July 16, 2014, 10:25:13 pm
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.
And adventure mode quest map? On that note, there needs to be a plugin to just get that damn map out on the top level adv mode interface.
Post by: Phoebus on July 17, 2014, 04:23:01 pm
And do all extra tilesets need to be 256 tiles tilesets?
Post by: Meph on July 17, 2014, 04:30:36 pm
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?
Yes, although they can be any size when it comes to pixels. You can also make as many as you like.
Post by: milo christiansen on July 18, 2014, 01:38:28 pm
Really it would not be a problem if it was easier to tell levels apart, but the shading is too subtle for that.
Currently all ramps render as up ramps except for the ones on the very last z-level, which is a little confusing, not to mention ugly.
Post by: mifki on July 20, 2014, 08:07:32 am
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.
"Nextgen" branch below.
Version 4.29 has almost all optimisations I was going to do, now rendering is up to 2x faster than the main branch when many levels are rendered.
Now it's possible to refer tilesets by id instead of ordinal number (old overrides.txt will still work).
The same `colormap` command.
Resolved incompatibility with dwarfmonitor plugin on Windows that caused crash.
Now has binaries for r5 only.
Nextgen branch should now behave exactly as the main branch if map and text tilesets have the same size (in terms of compatibility with other plugins), at least until zoomed. So it will become the main version soon once I fix some random crashes.
Nextgen package now includes modified version of mousequery plugin that works correctly with different sizes for map/text tiles. It also supports live query function for lower levels and ability to select tiles on lower levels.
Also this mousequery version has support for click-and-drag for map scrolling. Enabled with command "mousequery drag <left|right>". This functionality can be used independently of TWBT and the code will be merged into dfhack once tested a bit.
Multiscroll plugin also updated for better compatibility with the nextgen branch.
Post by: CLA on July 20, 2014, 10:34:03 am
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.
Quote
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?
Post by: Meph on July 20, 2014, 03:10:42 pm
Quote
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.
Post by: scamtank on July 20, 2014, 03:27:07 pm
Post by: Dragoon209 on July 20, 2014, 04:05:11 pm
I am very interested in this plugin, but since I am not a very good artist, I thought I could contribute in another way.
I wrote a quick little utility to read through your raw files, and then generate export files with the item subtype numbers. Hopefully this helps somebody when they are crafting their overrides.txt file.
it was written in AHK, so unfortunately it is windows only. It isn't very complex, so I'm sure somebody with more knowledge than me could make it for something else.
The download for it is here: http://dffd.wimbli.com/file.php?id=9086 (http://dffd.wimbli.com/file.php?id=9086)
The download contains the source code, and a compiled EXE that should work for anybody on Windows XP - 8.1.
How To Use:
- Run the script or executable
- Point the dialog box to your RAW\OBJECTS folder.
- Point the next dialog box to the folder you would like the export files to be generated.
- Give the script the prefix you would like all of your export files to start with. For instance, 'ModName' would result in: ModName-Ammo.txt, ModName-Tools, etc
- Make awesome tilesets!
Example:
I want to add more instruments to the game. I create a new file called 'item_instrument_CustomAdded.txt', and populate it. I now have 2 raw files with instruments in them, item_instrument.txt (the default one), and item_instrument_CustomAdded.txt.
Spoiler: item_instrument.txt (click to show/hide)
Spoiler: item_instrument_CustomAdded.txt (click to show/hide)
Spoiler: Sample Export.txt (click to show/hide)
I tested this on masterwork mod partly because it has a complex raw load order with multiple files for item types, but mostly because he has already counted the item subtypes in his raw files, and it made it easy to check my work. :P
Thanks to Meph for help with figuring out how Dwarf Fortress loads files. Good luck if you ever try to add custom artwork to all of the Tools! I found 900+...
Hope this helps somebody! If you have any questions, feel free to PM me. I'll start a thread for it if need.
Post by: mifki on July 20, 2014, 05:24:59 pm
With 'id', do you mean the filename?
No, in OVERRIDE command, tileset previously was identified by number (in the order they added with TILESET command), but now TILESET has new Id parameter and OVERRIDE accepts that id. There's an example in overrides.txt :)
Post by: mifki on July 20, 2014, 05:31:39 pm
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?
Sorry no. It's just a command to adjust mapping of existing 16 colors to RGB and reload colors.txt - mostly for modders at the moment so see their changes without restarting DF. Later I hope there will be UI for players as well to select colormap in-game.
Meph, did this answer your question?
But anyway I promised to add support for more colours (and this will remove the 16-colour limit) and I will do that soon.
Post by: mifki on July 20, 2014, 05:57:08 pm
Post by: Footkerchief on July 20, 2014, 08:43:33 pm
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?
It's worth noting that those ingame colors already have real RGB values in the raws -- they just get down-converted to the 16-color palette.
Post by: Rose on July 21, 2014, 05:25:42 am
Post by: mifki on July 21, 2014, 09:38:31 am
Spoiler (click to show/hide)
Post by: scamtank on July 21, 2014, 10:01:13 am
Post by: Rose on July 21, 2014, 10:01:39 am
Post by: fricy on July 21, 2014, 10:03:44 am
Having fun with TWBT today...Spoiler (click to show/hide)
Senor Nonchalante strikes again? :)
I started testing the new versions, will get back with a report.
Post by: Mike Mayday on July 21, 2014, 11:26:08 am
/mifki, every goddamn day
Post by: Rose on July 21, 2014, 11:35:13 am
>:D
Post by: palu on July 21, 2014, 11:36:38 am
Post by: Mike Mayday on July 21, 2014, 11:44:02 am
Post by: Rose on July 21, 2014, 12:08:15 pm
Post by: Meph on July 21, 2014, 12:15:47 pm
Don't worry Japa, as long as he doesn't try 3D terrain, my heart lies with you ;)Isnt that 3d terrain above? ^^
Post by: Saram-61-97-kon on July 21, 2014, 01:00:45 pm
Post by: Dirst on July 21, 2014, 01:08:40 pm
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.
Post by: lethosor on July 21, 2014, 01:38:48 pm
Post by: Meph on July 21, 2014, 01:39:57 pm
Post by: Rip0k on July 21, 2014, 01:58:31 pm
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!
Post by: Rose on July 21, 2014, 02:10:29 pm
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.
Post by: Meph on July 21, 2014, 02:11:20 pm
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!
I am not saying that mifki isnt doing great work here, I am just stuck on this:
But....stonesense....
Edit: sniped by the very same. ;)
Post by: mifki on July 21, 2014, 05:33:53 pm
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 than Stonesense, but completely playable and instantly switchable between 2d/iso. So it's not a direct competitor to Stonesense.
Post by: therahedwig on July 21, 2014, 06:20:58 pm
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.
Yes, I like this :)
Besides, there's a lot of benefit to be had from sharing sprites here: TwbT iso will be able to use stonesense sprites, and people using twbt might be more motivated to make iso sprites... which then can be used in Stonesense :p (Because we still need a LOT of creature sprites!)
I myself have never had much interest in making a native tileset for Dwarf Fortress, not just because it is very limited, but also because I kept having the feeling I would not be able to do any better than all the others making tilesets, and I don't like reinventing the wheel, rather prefering to improve upon it. So hence my focus on stonesense graphics :)
Dwarf Fortress is a very big game to a pixel artist, you will see, that once TwbT gets to a certain stage, it will too much for a single artist as well. So I say we try to find a way to bundle our efforts while keeping in mind the different aesthetical needs of everyone.
Other than that, because it's my first post in the thread: Impressive job! :p
Post by: Linkeron on July 24, 2014, 04:16:15 pm
I'm on my second fort since coming back to DF for the third time. Sometime between the end of the last fort and the start of this one, multi-Z-Level rendering was disabled, and lighting was enabled. Also, I'm positive my last fort had full text and multi-Z-Level rendering, but no lighting. I had messed with graphical settings in the MDF GUI when I generated the world the new fort is in (Both printmode and the four tics underneath), but I didn't know entirely what I was doing at the time, and have since then tried to restore settings to Default on the MDF GUI via profiles (Only just a few minutes ago realized it didn't actually do it when I combed through MDF changelog and discovered Rendermax is the new default).
Aside from 'prospect all,' 'tweak fixmigrant,' and just now 'rendermax light,' I haven't issued any commands to dfhack since I downloaded it last. I'm the only person who uses this computer, so I know that's all that's been messed with.
To sum it all up...
-Last fort had full text and Multi-Z-Level rendering, no lighting
-New fort has lighting, no Multi-Z-Level rendering, no full text
-Messed with MDF GUI graphics settings when generating new forts world
-Since then have tried to restore defaults via MDF GUI profiles
-Didn't actually restore defaults, tried my best to do so myself but I don't know what defaults are.
-Read on MDF changelog that entering 'rendermax light' into dfhack enables "Item Graphics + Multi-z-Levels + Dynamic Lighting"
-Entered 'rendermax light' into dfhack, no change
-Hung my head in shame, posted this
Again, posting this on both MDF and TwbT threads since I have no idea what's at fault.
Post by: Putnam on July 24, 2014, 04:20:53 pm
Post by: Linkeron on July 24, 2014, 04:32:09 pm
Disable rendermax, enable TWBT multi, I think that should work.
EDIT: Fixed now! I assumed 'disable rendermax' also meant 'switch to 2D,' but that didn't make sense.
Post by: Authority2 on July 25, 2014, 06:11:39 am
Post by: mifki on July 25, 2014, 07:05:48 am
Post by: mifki on July 25, 2014, 07:06:27 am
Post by: Rose on July 25, 2014, 07:50:52 am
It's huge, though.
I was using it to test dyed items in stonesense
Post by: mifki on July 25, 2014, 07:52:40 am
Post by: lwCoyote on July 26, 2014, 08:46:18 pm
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.
When I do so, I get the following error
The procedure entry point
??0VMethodInterposeLinkBase@DFHack@@QAE@PAVvirtual_identity@1@HPAX1H@Z could not be located in the dynamic link library SDL.dll
I have zero idea what this means, or how to fix it. I didn't do anything to SDL.dll though. Help? I need my FPS back!
Post by: mifki on July 26, 2014, 10:02:03 pm
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.
Post by: mifki on July 26, 2014, 11:12:21 pm
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.
Found a problem here - if you stand near a building (but not inside) you won't see, where the door is...
Post by: lwCoyote on July 27, 2014, 12:13:30 am
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.
Just disable multi-level, yes. How can I figure out what version of DFHack I have? I didn't see anything about the version in the readme in the same directory, now in the DFHack window itself; in the plugins directory there was a readme that seemed to indicate that it is R3, so thats the version I ended up using
Post by: mifki on July 27, 2014, 12:27:07 am
Post by: lwCoyote on July 28, 2014, 06:05:53 pm
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!
Post by: mifki on July 28, 2014, 06:12:49 pm
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!
That's good. Anyway I couldn't check it yet - updated OS X to 10.10 beta and fucked up my Windows virtual machine...
Post by: Authority2 on July 28, 2014, 06:28:36 pm
Post by: Diton on July 28, 2014, 07:57:26 pm
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.
Post by: mifki on July 28, 2014, 10:23:07 pm
I just had an idea. Could dwarves flashing with arrows/injuries be replaced with a modified dwarf sprite that doesn't flash?
I'll check it, but I don't think it's possible with reasonable effort.
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.
I'll check these too. Possibly siege engines will require separate support. Better support for overriding workshops is planned as well, but in general
[OVERRIDE:127:B:WORKSHOP_MECHANIC:Workshop::xxx:xxx]
should work, doesn't it?
And specifically about tile 127 - it's used for mountains only on world map, right? Eventually there will be support for one more separate font for world maps because main tileset doesn't work well there anyway.
Post by: Diton on July 28, 2014, 10:57:39 pm
[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.
Awesome, that'll allow for a lot more flexibility on a bunch of the tiles.
Post by: mifki on July 28, 2014, 11:30:30 pm
flip the 2 workshop parts (WORKSHOP:WORKSHOP_MECHANIC) but yeah, just tested and that works, changes the bottom right tile as expected.
Hm.. I'll check this, it shouldn't be this way. I mean it works but maybe it just would replace this tile everywhere (if it were used somewhere else) because these values are just invalid at these places so it ignores them.
Post by: Diton on July 28, 2014, 11:57:27 pm
Here's my archery target override for another example, maybe that's what's causing the stockpile issue?
[OVERRIDE:88:B:ARCHERYTARGET:ARCHERY_TARGET::2:98]
Post by: Diton on July 29, 2014, 12:10:25 am
Possibly not due to anything twbt related, but some of the override tiles I've added show up really dark in game. Is there a way to fix that?
Post by: Diton on July 29, 2014, 12:10:45 am
Post by: mifki on July 29, 2014, 01:47:02 am
Code: [Select]
[OVERRIDE:127:B:WORKSHOP_MECHANIC:Workshop::0:48]
[OVERRIDE:88:B:ARCHERY_TARGET:ArcheryTarget::0:48]
definitely work. Note that id and type are case-sensitive. However there's a problem indeed with overriding X and cursor, I'll fix that.
And about tiles displayed dark - overrides don't change colors so they should be displayed exactly as if they were original tiles, including being darker than you see in your graphics editor, according to tile colouring rules.
Post by: Meph on July 31, 2014, 04:46:09 pm
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]
Edit2: I am an exceedingly happy person now.
(http://i.imgur.com/apGBcXk.png)
(these are 32x tiles, so they are compressed to 16x for the screenshot. They actually look twice as good uncrompressed.)
Post by: Roses on July 31, 2014, 06:25:48 pm
Post by: Meph on July 31, 2014, 06:28:07 pm
Post by: mifki on July 31, 2014, 06:33:03 pm
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]
As with Diton's case I doubt it works as expected. It should be able to understand only values from included .h files and not custom IDs from raws. It actually should ignore overrides with unrecognised values but currently main branch doesn't. So I think it works only because same tiles are not used in other workshops.
I'll try to implement proper support for custom buildings today or on the weekend.
Post by: Meph on July 31, 2014, 06:35:00 pm
Post by: mifki on July 31, 2014, 06:38:11 pm
Mifki. Its an ingame screenshot. It works.
I understand. Do you have the same tiles used in other workshops? What happens now is that it replaces specified tile in all buildings with Workshop type, just ignoring unrecognised id. Try using the same tile in two different workshops.
Post by: Meph on July 31, 2014, 06:49:30 pm
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:
Quote
I'll try to implement proper support for custom buildings today or on the weekend.
I hope you can find a way to make this possible. :) And not only because I would look like a fool, after writing a PM to four modders asking if they want sprites for their workshops. :D
Post by: mifki on July 31, 2014, 06:56:16 pm
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.
When it's done you will use something like
WORKSHOP_CUSTOM:Workshop:YOUR_WORKSHOP_ID
Again I remind that this values are case-sensitive. I'll add a check to ignore or print a message in case of unrecognised values, but right now using wrong values may lead to unexpected things as you see, sorry about this.
Post by: Diton on July 31, 2014, 06:58:08 pm
Post by: Meph on July 31, 2014, 07:03:53 pm
I hope they help other people to set something like this up, after mifki did the changes he just described. Both sprites are taken from Warcraft II: Orcs vs. Humans, by Blizzard. Copyright & TM.
Add to entity:
Code: [Select]
[PERMITTED_BUILDING:BLACK_ALTAR_ORC]
[PERMITTED_BUILDING:TINKERER_ORCISH]Add to any building file:
Code: [Select]
[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]The tileset, in my case the name is "MDF 24x - Overrides Buildings.png"
(http://i.imgur.com/RWCZe1R.png)
The entries in the overrides.txt. Mind that the "5" means that this is my fifth tileset in use. The number on your machine might very well differ.
Code: [Select]
[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]Note that the tiles are unique on both workshops, the tinkerer shares no tiles with the altar, otherwise it would get mixed up, as mifki described. Its not important anymore I guess, when he finishes the custom_id system.
The end result, ingame screenshot:
(http://i.imgur.com/txT7ArE.png)
You can easily change the black background to fit the grass, or constructed floor. This is just a quick example.
Post by: Lysabild on August 01, 2014, 12:25:51 am
Post by: mifki on August 01, 2014, 09:13:42 am
try version 3.32
see overrides.txt for correct syntax for custom buildings, it's not exactly as in your tutorial
Post by: yawa on August 01, 2014, 09:59:22 am
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?
Post by: fricy on August 01, 2014, 10:05:14 am
Quote from: yawa link=4.msg5532007#msg5532007 date=1406905162
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?
Most of this is already implemented in the v34.11 starter packs, and will be in 40.x once we have dfhack.
Post by: Meph on August 01, 2014, 11:21:31 am
yawa: Have a look here as well: http://www.bay12forums.com/smf/index.php?topic=139579.0 Its still for 34.11, but has all items. :)
Post by: Vattic on August 01, 2014, 05:54:34 pm
Spoiler: never mind (click to show/hide)
Edit: I had problems, a restart fixed them somehow.
Post by: Meph on August 02, 2014, 11:02:17 am
I was thinking about making a set for stone, wood, metal and glass walls, with the stone looking like the walls do currently, wooden ones look like pallisades, metal ones are solid sheets and glass one are thin, more like windows.
I know that doors look differently when you make them from these materials, so maybe there is some way to use the same mechanism for Twbt. (?)
Post by: Roses on August 02, 2014, 02:39:16 pm
Lastly, it has been awhile since I last looked at TWBT since I have been working on porting DFHack scripts, but has background color for items been talked about at all? Is it something that is possible?
Post by: Meph on August 02, 2014, 02:43:32 pm
Creature overrides cannot be done atm. Only items and buildings. I would assume that is might be possible if people play without creature sprites, instead using tiles.
I would like to second the idea that caste-specific creature graphics would be amazing.
Post by: mifki on August 03, 2014, 12:06:07 am
Post by: Meph on August 03, 2014, 04:08:01 am
I think that Twbt doesnt recognize transparency correctly on the tiles. Every transparent bit on a png is usually filled with the background color, the more transparent, the more vivid the color. TwbT tiles are always solid foreground, no background. This means that multi-colored items cant be done... and that the floor around the item will always take on the color of the item (or has to be made solid black, which doesnt fit so well ingame)
Post by: mifki on August 03, 2014, 08:08:35 am
Post by: mifki on August 05, 2014, 04:54:43 pm
Post by: Roses on August 05, 2014, 08:28:02 pm
Post by: Meph on August 06, 2014, 03:51:58 am
Post by: mifki on August 06, 2014, 05:11:28 am
(http://i.imgur.com/bhYVM2V.png)
Post by: Roses on August 06, 2014, 04:43:48 pm
Spoiler (click to show/hide)
Post by: mifki on August 06, 2014, 05:11:04 pm
In wiki (http://dwarffortresswiki.org/index.php/DF2014:Material_definition_token) it says "The color of objects made of this material which use both the foreground and background color: doors, floodgates, hatch covers, bins, barrels, and cages.", but I don't know whether this list is complete or just an example of such objects.
Anyway it's quite disappointing and I don't see any reason for it. There's a very small chance that this can be fixed with binpatching, I'll take a look later.
Post by: Meph on August 06, 2014, 05:28:55 pm
Next stop for Twbt: Caste-specific creature sprites (?) ;D
Post by: mifki on August 08, 2014, 08:24:43 am
Next plans are to fix mapshot command, more colours, better support for overrides by tile type, rendering of levels "above" in adv. mode, commands to manage overrides and tilesets from console, and 0.40.x support of course. That's apart from some OS X-specific things and thinking about web-based management console.
Post by: scamtank on August 08, 2014, 08:39:47 am
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"?
Post by: Meph on August 08, 2014, 08:43:23 am
Keep on doing what you are doing. The plugin is great, and I have gotten very good feedback on it. And thanks for including the init settings. :)
Post by: mifki on August 08, 2014, 09:55:23 am
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"?
List at the bottom here (https://github.com/mifki/df-twbt/blob/nextgen/README.md) - pretty much everything.
Next step could be complete custom rendering instead of overriding half of tiles, but I'm still unsure.
Post by: Meph on August 08, 2014, 10:02:30 am
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.
Post by: scamtank on August 08, 2014, 10:11:59 am
Post by: heydude6 on August 08, 2014, 10:12:29 am
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.
Post by: mifki on August 08, 2014, 10:22:11 am
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.
That's the thing - if it will access / allow to override basing on almost all object properties, it will be too close to implementing my own rendering (object type and material is what needed to determine tile symbol and colour). I mean it's not optimal (and therefore I don't like it :) ) if the game first renders screen and then plugin checks all the same properties of tiles/objects and re-renders them.
On the other hand it's still the easiest way, so I'll think about materials.
Post by: Meph on August 08, 2014, 10:22:59 am
Post by: mifki on August 08, 2014, 10:24:48 am
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.
Hm, that's what it should be doing actually. I'll check it. Can you post a screenshot?
Post by: mifki on August 08, 2014, 10:33:26 am
Post by: Rose on August 08, 2014, 10:37:23 am
Post by: mifki on August 08, 2014, 10:42:49 am
If only Toady would open-source the rendering of the game. :/
But why?
First, rendering involves accessing all internal data (tiles, objects, materials, ...), and he won't open all these internal structures.
Second, we have access to all of them via dfhack anyway, so how would making it "officially" open help?
Post by: Vattic on August 08, 2014, 12:16:17 pm
Post by: Clownmite on August 10, 2014, 12:19:21 pm
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.
That would be amazing.
Post by: shaver on August 10, 2014, 08:22:08 pm
Welp, putting Z-levels back to 15 didn't fix it. Sorry for the noise.
Post by: Obsidian Soul on August 10, 2014, 09:32:22 pm
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!
Post by: Meph on August 10, 2014, 09:44:57 pm
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!
1. Yes, it does require dfhack, and no, dfhack has not yet been released for 40.x. It wont take long according to the people working on it though.
2. Switching graphic sets is not affected by this. In fact, if you download MasterworkDF you can see the plugin in use, and I do include 25 tilesets and 12 font-tilesets in it, that you can easily mix as you like. The font-tilesets are made possible by TwbT. You can also enable and disable this plugin on the fly, while the game is running. No new worldgen is needed, and it works with any tileset.
3. Apparently some tiles/items do not support background colors. If mifki can circumvent it I dont know, but at this moment it is not possible.
Post by: lethosor on August 10, 2014, 09:54:12 pm
Yesterday I did a quick test and confirmed that TwbT works fine with 0.40.01.
Post by: mifki on August 10, 2014, 10:58:33 pm
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.
Post by: Footkerchief on August 10, 2014, 11:32:09 pm
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.
Yeah, I was really confused at the time.
Post by: mifki on August 15, 2014, 10:51:28 pm
Version 4.41 of nextgen branch has some serious optimisations and fixes for multiple visual issues, crash on Windows with multilevel rendering enabled is fixed, and also now showing standard up/down map views in adventure mode if multilevel rendering is not enabled.
Now I need to update it to DF 0.40, going to this in the next couple days.
Post by: mifki on August 16, 2014, 09:24:33 am
Post by: Vattic on August 16, 2014, 10:02:46 am
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).
Post by: scamtank on August 16, 2014, 12:30:05 pm
Post by: mifki on August 16, 2014, 07:51:49 pm
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.
What do you mean? In 4.41 I fixed all issues I was aware of, so it's better than ever. Just not for 0.40 yet, it takes more time to support new version than for the main branch.
Post by: scamtank on August 17, 2014, 02:14:43 am
Post by: Talvieno on August 17, 2014, 02:16:55 am
Post by: mifki on August 17, 2014, 07:17:40 am
Post by: PeridexisErrant on August 17, 2014, 08:07:30 am
Version 4.42 got support for 0.40.08
...and windows! Hope it works :)
Post by: mifki on August 17, 2014, 08:41:36 am
Post by: salithus on August 17, 2014, 10:24:21 am
And then you go and get it working while I'm sleeping :D
Post by: scamtank on August 17, 2014, 10:25:47 am
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.
e: Wow, look at all this egg on my face. I'm getting this problem even after completely removing TWBT from the equation! Sorry about that.
Post by: fricy on August 17, 2014, 10:36:22 am
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.
Post by: notfood on August 17, 2014, 10:38:47 am
Quote from: nextgen
error: #error Linux not supported yet
I'm sad...
Post by: mifki on August 17, 2014, 04:58:09 pm
Post by: notfood on August 17, 2014, 05:31:15 pm
Post by: mifki on August 17, 2014, 05:38:36 pm
Post by: mifki on August 17, 2014, 06:41:14 pm
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).
Many tiles would benefit from different images depending on neighbour tiles. I just don't know yet what the configuration for this would look like. Stonesense uses some xml-based language for this purpose, I haven't looked into details yet. Also performance problem would arise at some point.
Post by: Rose on August 17, 2014, 11:03:30 pm
Isowrld does it better, but is far more limited.
Post by: mifki on August 21, 2014, 05:34:52 pm
Post by: scamtank on August 21, 2014, 05:45:33 pm
Post by: shaver on August 21, 2014, 08:11:26 pm
Post by: LeoCean on August 22, 2014, 08:46:56 pm
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.
Also was there a big change between the overides in 34.11 to 40.08? Since the overides.txt I am using atm is from meph's overides for his item set. (I got it from a pack fricy uploaded or Joist) and it works fine on 40.08 besides for those creatures in cages not showing their "graphics". I tested it on 0.40.08r3 lazynewbpack which has twbt included in dfhack. The creatures (goblins) were already in cages though before I updated to that version which could be why that wasn't working.
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.
Post by: mifki on August 23, 2014, 04:45:30 am
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.
Are you sure this doesn't happen without twbt? I'll do more testing but so far I haven't seen anything like this.
Post by: mifki on August 23, 2014, 04:59:46 am
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?
There's no any support for creatures, and honestly I don't know anything about them, I mean, maybe something changed in 40.08, maybe it's something else.
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.
Nextgen branch allows to override tiles based on tile type, and I see new tile types for branches, twigs and all. So it should be possible to override them with nextgen branch right now (I'll update readme with these new tile types shortly). Of course it would be great to have special tile images for new trees.
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.
Hm... Which DF pack are you using?
Post by: LeoCean on August 23, 2014, 05:31:39 am
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.
The mention of the twbt pack as the source of the creature sprites.
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
https://www.youtube.com/watch?v=9smiimk34bY&list=UUbx1TZgxfIauUZyPuBzEwZg&feature=player_detailpage#t=1126
Shows goblin theifs + some creatures in the cages.
https://www.youtube.com/watch?v=9smiimk34bY&list=UUbx1TZgxfIauUZyPuBzEwZg&feature=player_detailpage#t=315
A few other goblins in cages. That's all from the 34.11 version, r63 of the pack or so I don't actually know which it goes up to r67 but that tileset isn't in that version.. Version r66 does have that pack so it could have been that instead of a way early version of r63.
I'm sort of thinking PeridexisErrant somehow added that feature to twbt with the starterpack idk, I didn't really play in 34.11 so my knowledge of that time is limited.
r67
- updated Dwarf Therapist to v22.0; improved roles and optimiser, many other tweaks
- using custom stonesense version that is compatible with TwbT
- changed all graphics settings for TwbT compatibility (except ASCII default)
- activated Text will be Text for all graphics packs (except ASCII default)
- updated TwbT to v3.31
r66
- changed line endings in hack/ruby/ruby-autogen to windows style, apparently Fricy's package was OSX-endings and causing some issues
- fixed growthbug syntax from dfhack tab
- updated TwbT to v3.28
- fixed TwbT item overrides
- with crashes resolved, added TwbT "multilevel 10" to dfhack.init and installed TwbT graphics by default
Post by: mifki on August 23, 2014, 07:04:21 am
Post by: mifki on August 23, 2014, 08:02:46 am
Post by: Spectre Incarnate on August 24, 2014, 09:31:29 am
Hey there, Mifki, would you mind checking out this thread? We have a question for you. Thanks!
Fixing Accented Letters in Names (http://www.bay12forums.com/smf/index.php?topic=142682.0)
Post by: LeoCean on August 24, 2014, 05:56:06 pm
Post by: mifki on August 28, 2014, 05:23:19 pm
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.
There were some issues with properly rendering worldgen and embark screens, ie. using graphics and text fonts in proper places.
Also, some people here requested these screens to stay text-only because the main map graphics doesn't work well for world map, and I kind of agree with that.
The final plan was to add support for a third font specifically for world maps, but because of aforementioned difficulties with these screens it hasn't been done yet.
Post by: Meph on August 28, 2014, 05:32:35 pm
Twbt tileset 1 ALT+1
Twbt tileset 2 ALT+2
Twbt tileset 3 ALT+3 (or even better ALT++ and ALT+- for going to next/previous in the list)
and so on, with the proper IDs for these tilesets declared somewhere in a text file, like the overrides.txt.
I know this is a bit special, and wouldnt work for switching from Ascii to Phoebus or Ironhand (different raws), but I think it would be quite interesting. There are so many ascii tilesets, and it would give them much more exposure, because people can look at them within a few seconds. Same thing for color schemes, if people could cycle through color schemes in a running fort, without closing the DF window, it would be much easier to find one you like, and much easier for people to spot differences between them.
And sorry I cant give any feedback on the unique building sprites yet, I was on vacation the last couple of weeks.
Post by: mifki on August 28, 2014, 05:38:00 pm
Post by: Meph on August 28, 2014, 05:42:08 pm
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?
Post by: mifki on August 28, 2014, 06:01:09 pm
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?
No, I didn't.
But I did say that know nothing about creature graphics - how it's configured, what's the problem with castes and so on. I just care much more about the look of in-game objects than about creatures. Maybe if you explain how the creature graphics works in df and what's the problem, I'll change my mind, but so far honestly I wasn't going to do anything creature-related.
Post by: Meph on August 28, 2014, 07:07:40 pm
Tl;dr: Civs could use castes to fake having other creatures as civ members, and males and females could look different.
Spoiler: Explanation and long text (click to show/hide)
Post by: mifki on August 28, 2014, 08:47:36 pm
Post by: Meph on August 28, 2014, 08:58:53 pm
I think the different domestic animals with male/female are much easier to do. They only use one sprite for each. Civ creatures do change their sprites quite often ingame, there would be a mix of caste and profession. Although I would be totally fine if it would be completely overwritten, for example CASTE:CIV:GOBLIN would always look the same goblin-like, no matter if he is a noble, woodcutter or mason. ^^
That being said, domestic creatures also use professions. They have default, hunt and war. Most artists never made hunt and war graphics however, so mostly its just one entry with default and one for child.
Example for animals:
Spoiler (click to show/hide)
Example for civs:
Spoiler (click to show/hide)
Post by: LeoCean on August 28, 2014, 09:04:04 pm
Spoiler: Weird graphic glitch (click to show/hide)
**Edit sort of found out why at bottom, kinda unimportant now** Meph do creatures in cages in your mod in 34.11 show up as letters or tileset images or do they use creature graphics like in the second post on this page. The only masterwork stuff I know of is silverdragonlords and I don't think he uses cages often. I could check with quills. Yeah they are.
http://www.youtube.com/watch?v=7g11iWu5uNQ&feature=player_detailpage#t=640 or this image
Spoiler: Animals in cages (click to show/hide)
What the heck do you guys use. :-\. PeridexisErrant says it is from twbt and of course it should work if you have [GRAPHICS:YES] on. But it isn't working for me so far in 40.08's twbt + dfhack. Maybe it was a different pluggin since mifki doesn't believe it's his twbt pluggin. And in regular dwarf fortress the goblins in cages just show up as the tileset image/ dead image.Edit** I may be wrong that it works as well in your version since I did notice they go back to being letters when their cages are "built" and not in the animal stockpile. It may be the same for the starter pack version. Edit 2** Well I just built a animal stockpile in this test game and my dwarves brought a goblin to that stockpile and it actually had the sprite. Why in the world would the game change the creature when it is in a built cage on the ground but not in a cage in a stockpile...
What it looks like in 40.08, so far..
Spoiler: Goblin + Giantess and Eiten (click to show/hide)
They should be using the phoebus goblin images they are set to when in cages and out (I'm pretty sure outside of cages they look normal) Of course there's probably something I'm missing I just don't know what it is. We'll see once 40.10 dfhack comes out and Peridexis includes twbt graphic sets if it finally works.
Edit: Dammit it seems I had this all wrong, even in vanilla df animals in cages in animal stockpiles use the graphics unless the cage is placed. So it is a dwarf fortress bug or something not yet in df, not something twbt added or didn't add. It took me awhile to actually learn that you had to slate the cage for removal to test this. (I'm pretty new) Anyways made a request to Toady to add a graphics option for dead animals/ "built" caged animals.
Spoiler: Animal stockpile/they show up (click to show/hide)
*Yeah it does make it easier to find, I was just so use to knowing where it was I forgot.
Post by: Meph on August 28, 2014, 10:46:21 pm
Post by: mifki on August 29, 2014, 03:59:49 am
Then recently I was trying to do one interesting thing that I'll show soon
Here it is, spot the difference) some colours are off, I know.
(http://i.imgur.com/Z47m2NG.png)
--
(http://i.imgur.com/akUzbDD.png)
Post by: fricy on August 29, 2014, 04:11:22 am
I see the background of the animal sprites changed too, but not yet to the underlying texture/color. Is that not finished yet, or...?
(One thing I don't understand is why (in vanilla) does the profession sprites have transparent background, while the animal sprites doesn't. Doesn't the game use the same logic to draw them?)
Post by: Meph on August 29, 2014, 04:15:18 am
Just kidding, looks like transparent tiles that still display the tile underneath. :) Which makes barrels see-through, because for reasons unknown Toady made them use the background color as foreground, its actually an inverted tile, but I guess that can be fixed by using a custom override tiles with Twbt for barrels. :)
Post by: mifki on August 29, 2014, 05:15:55 am
However there are some issues with colours and in general it requires more binary hacking (with quite much of it in twbt already), so I'm not yet sure that the result worth all the effort.
Post by: Hommit on August 29, 2014, 06:59:42 am
Post by: Arumba on August 29, 2014, 10:34:26 am
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 )
Post by: Dirst on August 29, 2014, 10:45:28 am
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.
Post by: Arumba on August 29, 2014, 10:47:26 am
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.
Well here's to hoping it can be recompiled soon >.< I cannot play without TWBT anymore. I really want to start using 40_10 due to the few improvements it makes over 40_08, but again, without TWBT... its just not going to happen >.<
Post by: LeoCean on August 29, 2014, 04:12:15 pm
I don't know why I couldn't notice those changes you made without looking at peoples posts. Looks very nice though.
Post by: Meph on August 29, 2014, 04:19:02 pm
That way people that use tilesets that work well with it can use the new transparency, but people using tilesets that are not optimised for it can still use the other features of TwbT without the transparency looking odd.
Post by: mifki on August 29, 2014, 08:52:51 pm
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 :)
Post by: SalmonGod on August 29, 2014, 11:56:21 pm
Post by: JoshuaRaven on August 30, 2014, 08:39:49 am
I'll update TWBT with support for 0.40.10 later today.
Looking forward to a 0.40.10-r1 release :-)
Post by: Meph on August 30, 2014, 09:12:34 am
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 :)
Post by: mifki on August 30, 2014, 10:54:13 am
Post by: scamtank on August 30, 2014, 10:58:46 am
Post by: Clownmite on August 30, 2014, 12:22:29 pm
Post by: Meph on August 30, 2014, 12:38:24 pm
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. :)
Post by: fricy on August 30, 2014, 01:41:57 pm
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.
Post by: Arumba on August 30, 2014, 06:39:24 pm
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. :)
Hey Meph, I've seen you post multiple times in this thread about having 24x24 or more graphics, yet everywhere I look online I only find 16x16 texture packs. Mind sharing where these higher res packs are located?
Also, not sure if I have just set something up improperly or not, but when I use Text will be Text, I cannot zoom in on the game interface. Zooming in or out increases/decreases the font sizes on screens, but has no impact on the tilesets used for graphics. Is this normal?
Post by: Meph on August 30, 2014, 07:16:55 pm
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.
Post by: Arumba on August 30, 2014, 07:45:10 pm
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.
When you say 'just make a set that's 24x', is it as simple as opening the file and rescaling?
Post by: Meph on August 30, 2014, 07:48:16 pm
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. Edit: Here it is: http://www.bay12forums.com/smf/index.php?topic=138935.0
Post by: Arumba on August 30, 2014, 07:50:39 pm
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.
I'll give it a go, I'm sure I can figure out where to go next if I need to learn more about photoshop.
Do you happen to have an answer on the rescaling graphics with zoom in/out with TWBT?
Post by: Meph on August 30, 2014, 07:52:29 pm
No idea about zoom. I think mifki did include/wants to include some way to show less than 80 tiles, so you can have small tiles for text and larger tiles for graphics, I saw it on a screenshot he posted, but havent seen it ingame myself.
Post by: Arumba on August 30, 2014, 08:06:43 pm
Post by: LeoCean on August 30, 2014, 08:39:22 pm
Spoiler: Masterwork's 24x24 Font (click to show/hide)
Post by: Meph on August 30, 2014, 08:41:07 pm
Go from fullscreen to window mode, it should show full zoom instantly. (until you touch anything^^)
Post by: Arumba on August 30, 2014, 08:49:33 pm
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 usually play the game windowed but fullscreen (at 1920x1080), so I suppose maybe that could be part of the issue. It's not a huge deal, but before using TWBT I remember being able to zoom in and have both the game window as well as the text screens get bigger or smaller. Was useful to check things out in more detail but a smaller area, and would be even better if zooming in just increased the graphics quality and didn't just stretch/fuzz the image.
Post by: Meph on August 30, 2014, 09:01:58 pm
If you are using 24x tiles now, they already reach the max of 80 tiles next to each other, effectively blocking you from zooming in even further. So if you would use 23x tiles for example, you could zoom in a tiny amount. Or if you use 12x tiles, you could zoom in a lot, but everything gets blurry quite fast. ;)
Post by: Arumba on August 30, 2014, 09:06:48 pm
Also, I just downloaded the newest LNP (40_10r2), and without having TWBT installed I can easily see what you mean by 16x16 being expanded kind of 'fuzzy' into 24x24. However, I am now completely convinced that my TWBT folder is completely locked at 16x16, without any capability of changing it. If I *could* get it to 24x24 I would be so happy.. >.<
Post by: Meph on August 30, 2014, 09:51:46 pm
Quote
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. ^^
Post by: mifki on August 30, 2014, 10:06:32 pm
3.xx branch of TWBT acts just like vanilla when it comes to tile size, limits, etc. so you have min. 80 columns limit and can't use large tiles on small screens. (The purpose of 80 column limit is quite understandable, you can't support any screen size on all game screens, so there should be some limit anyway, 80 is a standard).
4.xx branch of TWBT allows to use any tile size, no more min. 80 columns limit. By default tile size will match the size of the main graphics font (it means creature graphics and additional tilesets loaded for overrides will be resized to match it). But there's a command "twbt tilesize <w> <h>" that will resize any tileset to any size.
Oh yes there also commands "twbt tilesize smaller|bigger" that you can bind to shortcuts to zoom in and out.
Although version 3.xx is included in LNPs, I recommend to use 4.xx. There are no known major issues with it, and if there are I'd rather fix them and discontinue 3.xx branch.
Post by: lethosor on August 30, 2014, 10:09:39 pm
Post by: mifki on August 30, 2014, 10:12:49 pm
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.
Post by: Arumba on August 30, 2014, 10:22:24 pm
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.
Okay wow, so I tried using that and setting it to "twbt tilesize 64 64", and yes, holy crap, you can zoom in as far as you want. Very nice. I'll rebind a few keys to allow zooming in without tabbing to dfhack. Is there a way to specify the tilesize in init so that it is set properly on load? Can it be run before loading the fortress?
Post by: mifki on August 30, 2014, 10:25:50 pm
Post by: lethosor on August 30, 2014, 10:27:54 pm
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.
Post by: mifki on August 30, 2014, 10:30:05 pm
Done, version 4.49.
Post by: PeridexisErrant on August 31, 2014, 02:18:37 am
Post by: mifki on August 31, 2014, 02:33:48 am
4.49 will be in the starter pack from tonight.
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.
Post by: Xerberus on August 31, 2014, 08:19:10 am
(http://s1.directupload.net/images/140831/temp/b7qhzikq.png) (http://www.directupload.net/file/d/3731/b7qhzikq_png.htm)
Post by: mifki on August 31, 2014, 08:29:37 am
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)
Just several posts back or in the readme file. "There's a command "twbt tilesize <w> <h>" that will resize any tileset to any size. Oh yes there also commands "twbt tilesize smaller|bigger" that you can bind to shortcuts to zoom in and out."
Post by: fricy on August 31, 2014, 08:30:16 am
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
Post by: Rose on August 31, 2014, 08:34:10 am
Post by: salithus on August 31, 2014, 08:39:18 am
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"
Post by: mifki on August 31, 2014, 08:42:42 am
Feel free to recommend a better keybind, I just added the first keypair that didn't seem taken.
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.
But on OS X it doesn't matter, as multiscroll plugin adds zoom in/out with Cmd+scroll up/down.
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.
That fix won't help. However the problem is (I believe) only with the stonesense overlay that also doesn't work with 0.40 anyway.
Post by: Xerberus on August 31, 2014, 08:49:47 am
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
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?
EDIT: ok i added your keybindings to dfhack.init but they don't work :/.
Post by: salithus on August 31, 2014, 08:51:15 am
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?
Post by: mifki on August 31, 2014, 08:52:44 am
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?
Yep, just take all files from r1 folder and copy into DF\hack\plugins folder.
Post by: Xerberus on August 31, 2014, 09:04:40 am
Edit: its also quite convenient being able to increase menue font and graphic tiles seperately.
Post by: mifki on August 31, 2014, 09:07:58 am
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 suits you once?
Post by: Xerberus on August 31, 2014, 09:17:04 am
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?
well in previous versions you zoom-in the graphics and the menue fonts would increase too in size, so i had no real option there in terms of how zoomed in i want my game and how big i want the font, at least not with my limited knowledge of modding (which is none tbh).
it also doesn't annoy me to zoom in / out depending on which font-size i want (now seperately), sometimes smaller text is better (trade menues, etc.) and sometimes bigger ones suit me more for readability.
Post by: BlueSteelAU on August 31, 2014, 09:24:56 am
Post by: mifki on August 31, 2014, 09:29:00 am
sometimes smaller text is better (trade menues, etc.) and sometimes bigger ones suit me more for readability.
that's what I wanted to know, thanks.
Post by: BlueSteelAU on August 31, 2014, 09:35:22 am
Post by: mifki on August 31, 2014, 09:37:35 am
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
Thanks, I'll check it soon.
Post by: BlueSteelAU on August 31, 2014, 09:44:24 am
Post by: Arumba on August 31, 2014, 09:45:58 am
I'm just imagining how much better this game will look when a few things happen.
#1 - Even at 24x24 instead of 16x16.. you have SO much more room for clarity on a tile, that nearly every tile in game presently could be redone for more visual acuity.
#2 - If possible... I wonder if the buildings could be made better. Like.. Most buildings use 9 tiles, and I don't know how it is drawn really, but if 9 tiles at 24x24 pixels were used, that's a lot of damn pixels available! The buildings could look less... crap. Like.. actual buildings. Instead of having a 3x3 grid with 4 random icons on them that mean nothing to me, it could be a complete building.
Am I the only one thinking about this?
Post by: fricy on August 31, 2014, 09:56:11 am
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...
I don't know about perfect, but these are resized to 24x24:
http://dffd.wimbli.com/file.php?id=8891
http://dffd.wimbli.com/file.php?id=8851
DON'T use the object folder and the inits from these, because they are outdated (40.02), but the sprites should be ok. For resizing pixelart take a look at the Tileset resizer. (http://dffd.wimbli.com/file.php?id=4542)
Post by: BlueSteelAU on August 31, 2014, 10:00:23 am
Post by: LeoCean on August 31, 2014, 10:15:29 am
1) You should notice when you zoom in more and more in phoebus tiles that they become more and blurry/less defined.
2) You could try spacefox from the starter pack, it already includes twbt if i am not mistaken, and it may be possible depending on your .png editor to make the images resize so that they aren't blurry. They are pretty clear when zoomed in unlike most in phoebus. You'll probably just want to change the water tiles as I've no idea if I want to make those plain grey or w.e squares or phoebus bright ones. The pack isn't suppose to be based off phoebus after all.
3)My monitor can only dream of being 1920x1080 so I don't bother with making 24x24 tilesets. I couldn't test them anyways. Just give it a shot on the twbt version and see if you like how the buildings turn out. With the 16x16 so you don't waste your time editing it if you don't like it.
Ah fricy if they do use that they won't be able to have the updated animals that were introduced and added to those files in 0.40.0x-0.40.05. Small price to pay though. Plus the raws for graphics were changed to add animals.. (phoebus did update the sprite tilesets too)
Those creatures will just show up as C, E, and so on ingame. Since they won't have a graphics sprite in the raw\graphics folder.
Post by: mifki on August 31, 2014, 10:45:47 am
Post by: Arumba on August 31, 2014, 10:47:59 am
Thanks!
Post by: Xerberus on August 31, 2014, 10:50:25 am
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^^.
Post by: mifki on August 31, 2014, 10:56:09 am
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!
I don't know why dfhack doesn't allow to bind to mousewheel. I implemented mousewheel zoom on OS X in a separate plugin, but I don't know how to do that on Windows, so I can't help with this.
Post by: Arumba on August 31, 2014, 10:56:47 am
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^^.
Tried many iterations using "keybinding add Ctrl-mouse 4 twbt tilesize more" as the base. Dfhack keeps spitting back "Invalid key spec" errors.
Oh, and I hope I can remember how to play DF properly so the youtube videos are better >;)
Edit: For crying out loud, how do you reference Page Up/Down? Why is this thing so hard to work with?
Edit2: Oh, and thinking about it more, couldn't the vanilla exe building tiles be replaced with overrides?
Post by: fricy on August 31, 2014, 11:05:45 am
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.
Post by: mifki on August 31, 2014, 11:13:49 am
Post by: fricy on August 31, 2014, 11:19:27 am
What? Twbt 4.xx + multiscroll and no zoom on cmd+scroll?Exactly. It works on the title screen, but not in the game.
Post by: mifki on August 31, 2014, 11:23:48 am
What? Twbt 4.xx + multiscroll and no zoom on cmd+scroll?Exactly. It works on the title screen, but not in the game.
Are you using trackpad or mouse?
Post by: fricy on August 31, 2014, 11:47:35 am
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.
Post by: Xerberus on August 31, 2014, 01:00:38 pm
Spoiler (click to show/hide)
here is my current save folder:
http://www.mediafire.com/download/i76p53byyfc7m92/region1.rar
i am using the spacefox tileset (the one included in the starter pack) and i updated the pack with the 4.49 twbt update (the three .dll files) and added two keybindings to dfhack.init...nothing more.
Edit: because somebody already said that he was also crashing, i didn't zoom in / out while the crash was happening. at the time around the crash i ordered my dwarves to build a mechanics workshop, to create rock crafts. my farmers were also doing their usual stuff, but maybe its related to a missing tile (idk).
Edit2: ok tried phoebus tileset now, getting crash either way :/.
Post by: fricy on August 31, 2014, 01:32:41 pm
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.
Post by: Xerberus on August 31, 2014, 01:50:58 pm
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.
ah sorry, i thought about also telling that but i didn't think it would've anything to do with it. those "phantom sieges" like you call it i get pretty often since the 40.x releases of DF. i get the announcement that a vile force has arrived (undead), they actually are on the map but as soon as you unpause the walk away. like i said, since DF 2014 i get this in every game i play but never had a crash.
did you test my save? like i said i used the new .dll files because i couldn't zoom in, maybe something introduced a crash correlating with these phantom sieges and with the new files. but the crash usually happends some minutes after this phantom siege.
Edit: ok i used a freshly extracted version of the starter pack 40.10 r3 and used the save file, no crash this far and i am further than i was before. atm i got my first migrant wave and the phantom siege happened as always, undead appearing...undead gone.
so the only things different from the standard version i use now and the one giving me those crashes are:
- the three .dll from twbt-nextgen-4.49-win/0.40.10-r1
- adding
Spoiler (click to show/hide)
Spoiler (click to show/hide)
- me decreasing the population cap to 150 and the child cap to 50:1000 in the DF starter pack launcher (i didn't edit / change the strict_pop_cap as i read in some other thread)
i don't know what the problem is, i will try to add the new .dll in and look if these give me crashes, then adding they keybindings. my only problem now is that the game works again but i can't zoom in. i am using 1920 x 1080 and the dwarves and everything else is too small for me to really enjoy it -.-.
Edit: maybe i should also mention that i used soundsense before but as far as i know it only reads the gamelog, so it shouldn't be causing this crash....right? i used the newly extracted DF starter pack version, replaced the three .dll with the new ones regarding the twbt plugin and added the keybindings again, this time at the top row of the "generic dwarv mode" row and added "# zoom in function" as a comment (call me superstitous). so far no crash, but currently i am playing without soundsense.
Edit2: on an off-note, i just got another "phantom siege", ONE undead corpse appeared and then just vanished again. are sieges slightly bugged atm? with the 40.10 r1 starter pack i got no sieges for around 2 years and then over 100 undead corpses arrived at the end of the second year. currently in my DF-playthroughs its either too calm and then gets too brutal^^.
Post by: Arumba on August 31, 2014, 02:46:40 pm
The game also frequently crashes after saving. The save process completes, thankfully, but it happens more times than not. Reloading the game and loading in again works fine.
A few days ago I could reproduce a crash by using multilevel and rapidly changing Z-layers, but that seems to have been fixed.
Post by: LeoCean on August 31, 2014, 03:41:10 pm
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.
:O Did you not see my custom made tool sets for spacefox, they aren't the best but they look like they fit some of the shops. I was to annoyed with seeing A or O or , or . or anything that wasn't a graphic. I need to switch the A to A though (in the twbt version I made it a farmers tool set, the text font will overwrite anything but any creatures that use that tile when they are dead or if they didn't have a graphic, or are caged) and have the farmers workshop override that if possible. Could really just make counter tops for the workshops if that is/ was supported. It's very easy to do after all. made the bowyers shop have a customized bow graphic. It'd be nice to replace counter tops in those shops, that don't look like walls. Maybe even a floor tile.
I'm really just going to use phoebus mine cart tracks for the branches in the override.txt for now, once I get to it. Then I will probably make some sort of branch looking thing. So that normal minecart tracks will be the older spacefox version which look like mine cart/train tracks. I still haven't got into the meat of it because Arumba made me get into gal civ 2 again, and I'm to busy playing that atm to dive into twbt stuff. Also no ones commented on the damn water tile change or the up/down stair I made so I'm stuck (which is a twbt thing).. The overrides.txt looked confusing to me before but I'm pretty sure I understand it now. I just used mephs old twbt stuff that I found somewhere for now.
As for your work on the see through back background, it's probably best that you just require a certain color or w.e for it to show the tile behind. It isn't that to change some of the backgrounds to work with it, instead of you trying to make it work with all kinds of backgrounds. Like how it changed the color of the barrel in that image but made the top of the door see through. If you want to make a way for the animals in cages to use the graphic raws like they probably should be I'd love you <3. It shouldn't be hard for toady to do.. :'(
Trees are a little more difficult because there's so many images they use and for now the walls are alright, in spacefox at least. Might give them a rounder tile so they look like tree trunks. It still requires the starter pack to allow overwrites of the overrides.txt as you cannot expect new players to know this or look at information to figure out how to do it at least for the starter pack.
Post by: mifki on August 31, 2014, 05:11:32 pm
Post by: Xerberus on August 31, 2014, 05:27:22 pm
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.
after my last post i played about an hour further with my save and no crash. after i re-extracted the DF starter pack, copied in the new .dll files and added the keybindings (this time at another position) i had no other crash thankfully. but i had another phantom siege with one single undead unit appearing and then instantly disappearing from the map. like i said, i had those at several occassions and i don't know if this is a bug or duo to the new army movement feature this are just some troops that happen to walk through my area with no intent of actually attacking me. in my last fort before this (version 40.10 r1 starter pack i think) i had 2-3 phantom sieges and then a 100-undead siege which killed me. so sieges seem to work, just the phantom sieges are kinda irritating, they happen often quite early in the game and i get scared (hey, seven dwarves with no real setup against an invasion is scary).
Post by: mifki on August 31, 2014, 05:34:52 pm
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.
Post by: BigD145 on August 31, 2014, 05:58:20 pm
Post by: mifki on August 31, 2014, 06:11:45 pm
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.
If you manage to reproduce crashes on game load again, can you upload the save?
Post by: Xerberus on August 31, 2014, 06:13:37 pm
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.
well you had a goblin siege and a werebeast came, i had a bunch of goblin invaders in one of my last game and one of them was a werecat :D. it killed two goblin and bit two others.....so what is more FUN than a goblin siege and a werebeast? goblin invaders that are werebeasts :D.
another fun one was that i got an undead siege and a minute later an undead siege happened at the same time, they killed each other :D.
Post by: PeridexisErrant on August 31, 2014, 07:03:13 pm
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.
Post by: Xerberus on August 31, 2014, 07:08:38 pm
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 :).
Post by: mifki on August 31, 2014, 07:12:06 pm
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.
Sure. As I said, I'll do more testing on Windows soon.
Also I'll check if it's possible to make the default df zoom bindings to zoom the map with twbt.
Post by: mifki on August 31, 2014, 07:12:39 pm
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 :).
What exactly do you mean?
Post by: BlueSteelAU on August 31, 2014, 10:35:14 pm
Post by: mifki on August 31, 2014, 10:48:39 pm
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
You can add a line with "twbt tilesize <w> <h>" command to the dfhack.init script, it's only for map tiles though.
Post by: BlueSteelAU on August 31, 2014, 10:54:29 pm
Post by: mifki on August 31, 2014, 11:01:28 pm
is the w and h the number of tiles across,up/down
It's tile size, the default is 16 16.
Post by: BlueSteelAU on August 31, 2014, 11:24:00 pm
Post by: LeoCean on August 31, 2014, 11:38:29 pm
Post by: mifki on August 31, 2014, 11:44:07 pm
"twbt tilesize <w>(width) <h>(height)" Should be "twbt tilesize <32> <32>" exactly like that " included.
NOOOOO! Without <> - it's just a way to tell that they are parameters.
Post by: LeoCean on August 31, 2014, 11:48:50 pm
Post by: mifki on August 31, 2014, 11:59:35 pm
Post by: PeridexisErrant on September 01, 2014, 12:04:53 am
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?
If you have the 40_10 r4 pack, that uses TwbT 3.37 specifically to avoid confusion over resizing commands.
Post by: mifki on September 01, 2014, 12:10:46 am
Post by: BlueSteelAU on September 01, 2014, 12:31:54 am
"twbt tilesize <32> <32>"
"twbt tilesize <64> <64>"
and got unknown command
I then tried
"twbt tilesize 32 32"
"twbt tilesize 64 64"
and no change in initial display size that i noticed :( still small in size )
Post by: LeoCean on September 01, 2014, 12:36:13 am
I think what he meant with the zoom was that it only zoomed in the side menu without the command. While regular df zooms in/out both.
Post by: BlueSteelAU on September 01, 2014, 12:45:48 am
Post by: LeoCean on September 01, 2014, 12:50:21 am
Spoiler (click to show/hide)
That's what I'm getting are you placing it at the bottom of dfhack.init located Dwarf Fortress 40_10 Starter Pack r3\Dwarf Fortress 0.40.10. My screen isn't that big though. If I zoom out (for me it's [ or ] since I like peridexis keybinds and mousewheel to scroll z levels)
Post by: BlueSteelAU on September 01, 2014, 01:00:47 am
Code: [Select]
# 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"
Post by: LeoCean on September 01, 2014, 01:02:35 am
Interestingly a mean kobold thief that usually ran away on these tests chased a camel and a horse and killed the camel when it caught it lol. The phantom army bug is likely because it is to early in the save for a army to attack you so Toady probably wrote some code to make them leave or vanish when they try to lay siege that early.
Mines this,
#######################################################
# Apply binary patches at runtime #
#######################################################
twbt tilesize 32 32
keybinding add Shift-O "twbt tilesize smaller"
keybinding add Shift-P "twbt tilesize bigger"
and it loads all those tiles to 32x32 ingame, not on pre/embark though.
Post by: BlueSteelAU on September 01, 2014, 01:24:00 am
I just tried yours and on loading a game it crashes as son as i pres f1 or move on the screen.
I start a new game and I get the small tileset still. and when i try to move on the screen it crashes
just not my day :(
Post by: LeoCean on September 01, 2014, 01:25:23 am
I did get a crash when I used shift p or o to zoom all the way out and then back in really quick though. I didn't get a crash when I did it using the regular zoom function which zooms the texts to the right --->.
Post by: BlueSteelAU on September 01, 2014, 01:26:10 am
yes
Post by: BlueSteelAU on September 01, 2014, 01:27:47 am
Post by: BlueSteelAU on September 01, 2014, 01:29:56 am
when i pressed f1 after scrolling around a bit
Post by: LeoCean on September 01, 2014, 01:30:45 am
Well you may want to save if you do anything risky that may end up in a crash :D. Probably don't want to zoom in or out very fast either. Lol, I pressed f1 and let it run awhile and it didn't crash idk to say.
Post by: BlueSteelAU on September 01, 2014, 01:45:19 am
" , i've tried with phoebus and space fox (however they are spelled) and no diference either (apart from the looks that is. lol still crashing
Post by: LeoCean on September 01, 2014, 01:52:09 am
Post by: PeridexisErrant on September 01, 2014, 01:53:50 am
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.
Post by: mifki on September 01, 2014, 03:14:16 am
just not my day :(
Not mine either, can't reproduce any of these crashes...
Post by: mifki on September 01, 2014, 06:30:16 am
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.
Post by: scamtank on September 01, 2014, 07:00:06 am
Post by: mifki on September 01, 2014, 07:02:46 am
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?
Oh then better to use enable_mini_crash_dumps.reg file :) and wait for the next crash.
Post by: Arumba on September 01, 2014, 07:49:53 am
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.
Post by: BlueSteelAU on September 01, 2014, 07:51:08 am
Because
1. able to resize text and tilesets separately
2. able to resize tileset larger without stretching vertically because you go past the 80 characters across the window
3. I seem to like the multiview feature (set to 5) at least in the earlier release
4. able to set a default tileset <tilewidth> <tileheight>
How the hell did i ever used to play without this???
well on the earlier release my window had to be 3132*1080 (yes i have 2 monitor setup) and had to flip the window size every time I had to read a full screen of info eg: unit screen, and then back up to 3132*1080 when playing normal game. The tilesets and whole game experience (apart from the current crashes in newest release) is massive emergence into the game. I can actually see the details in the graphics and shadows when i Zoom right in so that the play area takes up a full monitor screen and the commands section is on the other monitor.
BTW setting up the crash_dump stuff now, I'll get back to you tomorrow its 10:45pm here now and haven't had much sleep the last 48 hours
Post by: mifki on September 01, 2014, 07:55:38 am
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?
Post by: Arumba on September 01, 2014, 07:57:01 am
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.
Actually, I'm not 100% sure.. is there a way to check in game what version it is? I downloaded the newest version but I can't 100% remember if I installed it or not. I don't think I did.. but maybe?
Edit #2: I tested it out by using the commands 'twbt tilesize more' and 'twbt tilsesize less', they did not work. Since this was the major change listed from 4.48 to 4.49 I am almost certain I am using 4.48.
Post by: mifki on September 01, 2014, 08:10:07 am
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?
Post by: BlueSteelAU on September 01, 2014, 08:12:39 am
I really hope this helps
I know ... i know i said i was going to bed , but i'm too excited ;)
Post by: Arumba on September 01, 2014, 08:14:48 am
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.
Post by: mifki on September 01, 2014, 08:29:25 am
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 ;)
Thank you! It's 1:30am here (guess where I am), so I also need to sleeep...)
Post by: mifki on September 01, 2014, 08:30:42 am
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.
Ok, I'll check it, thanks.
Post by: BlueSteelAU on September 01, 2014, 08:52:13 am
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...)
Post by: mifki on September 01, 2014, 08:59:32 am
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...)
Wow, these places came to your mind but not NZ?
Anyway, it's not clear what happened from your crash dump, I'll investigate it tomorrow.
Post by: BlueSteelAU on September 01, 2014, 09:04:00 am
Post by: BigD145 on September 01, 2014, 11:33:05 am
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
Post by: LeoCean on September 01, 2014, 11:47:49 am
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.
NEVERRRR, if I cared about not crashing I would though. I'm only doing tests for my graphics pack so it doesn't really matter if it crashes.
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.
I know you won't see this for awhile but is there anyway to turn that off afterwards? I barely have room on my computer as it is, and I'd rather not have things taking up to much space :D. So I'd install this for now but want to get rid of it later.
Post by: BenLubar on September 01, 2014, 02:54:39 pm
Post by: LeoCean on September 01, 2014, 03:03:23 pm
Post by: BlueSteelAU on September 01, 2014, 03:20:20 pm
Post by: BenLubar on September 01, 2014, 04:15:08 pm
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.
Post by: mifki on September 01, 2014, 04:58:48 pm
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.
Post by: mifki on September 01, 2014, 05:03:38 pm
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
Thanks, but you didn't enable (or didn't upload) crash dump as I instructed in this post:
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.
Post by: BigD145 on September 01, 2014, 06:37:59 pm
Post by: LeoCean on September 01, 2014, 08:42:30 pm
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
Weird I got rid of the twbt tilesize 16 16 (just for lols and also cause it is easier to change that way) and then saved that dfhack.init. Then loaded df, no crash. I added it back into the dfhack.init at twbt tilesize 18 18. (which I was using last night for a little while) and it crashed while loading the save game. Loading df after that produces no crash I'm gonna try this again to see if it's reproduce able. Well not by 100% certainly at least.... It didn't crash the next time I tried. I'll try a few more.
Post by: mifki on September 01, 2014, 08:48:13 pm
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
Ok I'll change it to "virtually unlimited":)
But did it crash before on your machine? I can't reproduce the crashes either, maybe it's related to video hardware or some software like antiviruses, I have no ideas atm.
Post by: LeoCean on September 01, 2014, 08:50:04 pm
Post by: BenLubar on September 01, 2014, 09:20:48 pm
Post by: Rose on September 01, 2014, 09:23:09 pm
Post by: Capsicum on September 01, 2014, 09:32:02 pm
(...)I can't reproduce the crashes either, maybe it's related to video hardware or some software like antiviruses, I have no ideas atm.
A null result isn't much help, but I haven't experienced any crashes either. I have tried using tilesets from 16-64px and subjected them to a lot of rapid zooming with no crashes to show for it. Win8.1/i5/HD4000.
Post by: Arumba on September 01, 2014, 09:52:53 pm
Post by: mifki on September 01, 2014, 10:20:39 pm
Later today I'll fix it, will look into Arumba's problem with mouse, and will likely fix problem with following a dwarf.
Post by: LeoCean on September 01, 2014, 10:24:57 pm
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.
Post by: mifki on September 01, 2014, 10:32:12 pm
Post by: Arumba on September 01, 2014, 10:43:48 pm
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.
I think you misunderstood, the tiles themselves don't go down to 16x16 with box select mode on while designating walls. The tiles stay 24x24, but the cursor itself is reduced to 16x16, and it shows a smaller X designation while still showing the 24 x 24 X designation.
Here's what I mean:
http://youtu.be/bxzoRUdDEzY
Post by: mifki on September 01, 2014, 11:07:11 pm
Here's what I mean:
http://youtu.be/bxzoRUdDEzY
So it's in automaterial plugin and not mousequery. Ok, thanks!
Post by: LeoCean on September 01, 2014, 11:09:02 pm
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.
Post by: mifki on September 01, 2014, 11:16:48 pm
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.
Well thanks for the investigation... But as I said, these are expected issues - twbt 4.xx uses a separate screen buffer and separate variables to store tile size. So plugins not updated to be compatible with twbt will draw things ("X" in this case) in wrong places, with wrong size, etc. leading to various weird effects that I'm actually not interested in because I'll just fix them once I know what plugins need fixing and once I have time.
Post by: Grumalg on September 02, 2014, 04:18:46 am
Unhandled exception at 0x60BE32A6 (twbt.plug.dll) in Dwarf Fortress.exe.12392.dmp: 0xC0000005: Access violation writing location 0x376E0040.
Sounds like it might be useful to have a temp debug version with error handlers in all your functions that report in stderr.log who had the problem till you figure out what's happening.
I also note that map zoom (using shift O and P as discussed in this thread) seems to take a lot of keypresses to make much difference in zoom level. Having a 'stepsize' setting to adjust how much each keypress changes map zoom level could be useful.
Post by: mifki on September 02, 2014, 04:28:47 am
I'll add stepsize option, thanks.
Post by: Grumalg on September 02, 2014, 04:42:27 am
Post by: Meph on September 02, 2014, 06:39:31 am
Quote
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.
Post by: Grumalg on September 02, 2014, 06:41:58 am
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...
Post by: mifki on September 02, 2014, 06:53:12 am
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...
Haven't received yet(
Post by: Grumalg on September 02, 2014, 07:55:58 am
zipped it up smaller and resent it, looked like it went fine this time.
Post by: BigD145 on September 02, 2014, 11:30:19 am
Post by: Arumba on September 02, 2014, 08:59:41 pm
Post by: mifki on September 02, 2014, 09:37:25 pm
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?
Good point, thanks.
Post by: fricy on September 03, 2014, 06:00:30 am
Post by: CLA on September 03, 2014, 08:00:05 am
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.
Post by: LeoCean on September 03, 2014, 03:31:57 pm
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.
Post by: salithus on September 03, 2014, 03:48:55 pm
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.
Post by: lethosor on September 03, 2014, 04:05:07 pm
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).
Post by: LeoCean on September 03, 2014, 05:34:28 pm
You'd think there'd be a way to get twbt and rendermax to work together, that'd be pretty neat.
Post by: lethosor on September 03, 2014, 05:36:06 pm
Post by: mifki on September 03, 2014, 06:15:22 pm
There's version 4.51 available, it fixes problems with mousequery plugin (mostly related to scrolling, eg. with right click) and includes automaterial plugin compatible with twbt. Also it possibly fixes some crashes, but unlikely all of them. Anyway it would be good if people who had crashes could try it.
Post by: BigD145 on September 03, 2014, 09:35:33 pm
https://www.dropbox.com/s/ewps7fqxh7ezwbz/Dwarf%20Fortress.exe.5052.dmp?dl=0
Post by: mifki on September 04, 2014, 12:18:08 am
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?
Post by: Timeless Bob on September 04, 2014, 02:00:12 am
Post by: Rose on September 04, 2014, 04:22:48 am
Post by: PeridexisErrant on September 04, 2014, 05:40:23 am
Did you try stonesense overlay?
Wouldn't that be incompatible with [printmode:standard]? Or am I misremembering?
Post by: Rose on September 04, 2014, 07:18:49 am
Post by: BigD145 on September 04, 2014, 09:31:31 am
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.
Post by: Erendir on September 04, 2014, 10:41:55 am
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
Post by: LeoCean on September 04, 2014, 04:23:29 pm
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.
I think you misunderstood him, he likely meant if you set it to multilevel 0 does it still crash, as he may be thinking it has to do with multilevel.
@Erendir
Did you even look at the post you took that image from? Since I made that stair image that you used. His version is based off of the phoebus set you are using in that picture but you are using a modified spacefox stairset that becomes a up/down stair.
T for tile? It isn't a building or a item.
Quote from: 4.49 readme
Overrides for tile types
[OVERRIDE:Tile:T:Type:Tileset:NewTile]
Post by: mifki on September 04, 2014, 04:46:09 pm
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?
Post by: mifki on September 04, 2014, 04:52:09 pm
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
I'll check it, thanks.
1. Yep, forgot about the designation time. May be tricky though, I'll take a look.
2. It's supported in 4.xx only, so it's documented here https://github.com/mifki/df-twbt/blob/nextgen/README.md
Post by: Erendir on September 04, 2014, 06:24:23 pm
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]
[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.
Post by: mifki on September 04, 2014, 06:39:48 pm
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]
Yes, I know. I tried to fix it once, but items being hauled are rendered some special way, so it didn't work. Still on my todo list though.
Post by: BigD145 on September 04, 2014, 07:33:27 pm
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 0This setting loads. No immediate crash. Multilevel is working. Not well, but working.
Post by: mifki on September 04, 2014, 07:57:10 pm
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.
What do you mean 'not well'? It obviously doesn't have the fog, or something else is wrong?
Anyway, again it's just to help me solve the crash, now I know that the fog code is causing it.
Thank you.
Post by: Arumba on September 04, 2014, 09:00:45 pm
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.
Post by: mifki on September 04, 2014, 09:23:34 pm
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.
Perfectly makes sense. I actually wrote several times that eventually there will be support for a separate font for world maps. Until someone can modify 'text' font to have better world map tiles, if it's possible to do that still keeping letters/numbers/punctuation intact.
Post by: LeoCean on September 04, 2014, 10:56:51 pm
As for Arumbas problem you already know how to edit the tilesets can't you edit the phoebus tileset then copy the spacefox text over that? Then name it phoebus_text. Honestly I dislike how the world generation uses the text.png so I do world gens with twbt off.
I actually like these fonts a little more than the current spacefox ones.
https://www.youtube.com/watch?v=h4AWFbwB0lA&list=UUHJM-Vd74Egk1xvGp4BHWBA
Cabinets/house thing/ even spacefox smooth stone/grates? are humans and the pink cloth are goblins (these should be similar to phoebus)... I forget what the necro towers are but they are easily distinguishable. Elves usually look like elves but are Capital accented I in the text font's. I think. Then humans are AE/ae in text fonts. It really doesn't help that spacefox_text tileset hasn't been updated for a long time.
Mifki did you take down 4.51? It isn't in the latest builds on the first page though I'm pretty sure I saw it there when you released it at first.
Post by: mifki on September 04, 2014, 11:48:40 pm
Post by: LeoCean on September 05, 2014, 12:30:06 am
I tried overriding dark pits that represent goblins, using [TILESET:Spacefox_16x16_text.png:Spacefox_16x16_text.png] is that the correct way you'd do it or can you not override that tileset. None of the Dark pit variations I tried were recognized, even used legend viewer to make sure I was spelling it correctly. I guess it requires that in the df/tiles.h file to change it anyways, adding :0 after the last .png made it think I was duplicating the text font, at least that's what dfhack told me.
Post by: fricy on September 05, 2014, 07:26:41 am
Post by: Grumalg on September 05, 2014, 06:42:54 pm
Thanks :)
Post by: mifki on September 05, 2014, 07:15:21 pm
Fixes for smaller issues coming soon.
Post by: mifki on September 05, 2014, 09:11:47 pm
(http://i.imgur.com/OAwk8y0.png)
Post by: Grumalg on September 06, 2014, 01:32:47 am
Post by: mifki on September 06, 2014, 03:41:57 am
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 the current at all. It's planned for adventure mode only.
Post by: Grumalg on September 06, 2014, 04:17:43 am
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.
Post by: Dirst on September 06, 2014, 08:28:36 am
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.
Post by: Grumalg on September 06, 2014, 09:01:30 am
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.
I think there should be a single level/multilevel toggle for many other reasons. If such a toggle existed, it'd still be less keystrokes (one) to solve the ceiling issue than changing current level 2 or more times.
Post by: LeoCean on September 06, 2014, 06:08:17 pm
http://www.bay12forums.com/smf/index.php?topic=2891.msg47881#msg47881
Post by: Nopenope on September 06, 2014, 08:49:28 pm
Spoiler (click to show/hide)
Post by: mifki on September 07, 2014, 03:08:13 am
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)
Probably I'll do it for 0.40.11 once dfhack is available.
I wrote about this several times, it's just hard for me to update for all systems for each df version, so I was waiting until updates aren't so often.
Post by: mifki on September 07, 2014, 10:23:01 pm
"multilevel fogdensity" command now accepts 3 parameters - density start step, defaults are "multilevel fogdensity 0.15 0 1" (actually these two new parameters are optional)
start parameter controls how dense the fog is on the next z-level after the current one
step parameter controls difference between z-levels
So, to achieve result similar to shown on the previous page, where there's a big difference between current and the next z-levels and little or no difference between next z-levels, try "multilevel fogdensity 0.15 4 0.1"
"twbt tilesize" command now accepts +xx or -xx parameter to make tiles xx pixels bigger or smaller accordingly.
+ some OpenGL optimizations
Post by: LeoCean on September 07, 2014, 11:16:58 pm
[OVERRIDE:240:I:BAR:BAR:0:3:241]#iron Is what I tried, plus the 0 goes up to 21. (the # shouldn't invalidate the code since it is after it) I know the 3:241 is correct (since I also have my stairs on the same tileset), I'm guessing it's the subtype that is wrong? I've tried "iron bars" IRON, IRON BAR, IRON BARS.... I've no idea. **Edit: This changed all those graphics so I know it works sortof [OVERRIDE:240:I:BAR:::3:241] #iron. ***Edit: [OVERRIDE:240:I:BAR:BAR::3:241] #iron does the same as the one before so it's definitely the subtype but I've no idea what it'd be.
I wonder is it possible to change animal "tiles" that are called for from the main tileset but overriden by the overrides. It seems that would be the easiest way to "override creatures". I'm pretty sure you could then make them use those tiles for different castes.
Are engraved walls like this StoneWallWorn3? Or are they not supported, I see smoothed walls.
Post by: mifki on September 08, 2014, 05:22:01 am
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.
Changes in version 4.54:
Fixed an issue with overrides not being applied after changing tile size.
Made mouse clicks over an empty area change z-level only if SHIFT key is pressed. I found this annoying myself and also this was to fix a problem with inability to use box select mode of automaterial plugin with mouse over an empty area.
What other small things I promised in the last few days I forgot?
Post by: LeoCean on September 08, 2014, 11:12:50 am
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.
This maybe?
Post by: Arumba on September 08, 2014, 11:47:58 am
Post by: LeoCean on September 08, 2014, 12:10:19 pm
[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.
Post by: Rose on September 08, 2014, 12:36:54 pm
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.
Post by: fricy on September 08, 2014, 01:38:13 pm
What other small things I promised in the last few days I forgot?
Well, you haven't promised anything, but...:
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.
Post by: LeoCean on September 08, 2014, 01:53:37 pm
Mifki I read back around page 40 that you were adding something to change colors in a tile? Has that been added? Would someone be able to use those to tell the bars apart?
Post by: Erendir on September 08, 2014, 04:54:50 pm
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)
License is this: http://zeldawiki.org/Zelda_Wiki:GNU_Free_Documentation_License
I'm not 100% sure if everyone can use it (like for streaming DF Let's play for example)
But if it is, adding it is easy:
1.resize the file to be 48*16=768 pixels in width and height,
2.add this in overrides.txt:
Code: [Select]
[TILESET:Override - 48x - Quiver.png:Override - 48x - Quiver.png:QuiverTileSet]
[OVERRIDE:146:I:QUIVER:QUIVER::QuiverTileSet:0]
Post by: LeoCean on September 08, 2014, 05:14:20 pm
Post by: Erendir on September 08, 2014, 07:09:25 pm
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.
Post by: LeoCean on September 08, 2014, 07:21:04 pm
Post by: palu on September 08, 2014, 09:15:36 pm
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.
Post by: LeoCean on September 08, 2014, 09:53:14 pm
The first image in that is the original imageset I think.
Post by: lethosor on September 08, 2014, 09:57:33 pm
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
Post by: LeoCean on September 08, 2014, 10:07:20 pm
Post by: salithus on September 08, 2014, 10:13:16 pm
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.
lethosor was pointing out with bold that doesn't really pop out on the standard theme very well, that Erendir specified that the image would be 768x768 ("768 pixels in width and height").
Your posts indicate you think the width:height ration would be 16:48 or 48:16, neither of which were what Erendir intended.
Post by: LeoCean on September 09, 2014, 12:54:13 am
Post by: Erde on September 10, 2014, 08:12:50 am
Quote
1. 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?
Post by: scamtank on September 10, 2014, 08:18:34 am
Post by: CLA on September 10, 2014, 08:19:58 am
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?
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).
Post by: muppet9876 on September 10, 2014, 12:41:46 pm
http://dffd.wimbli.com/file.php?id=9663
Post by: mifki on September 10, 2014, 04:56:44 pm
Crash dump from 4.55 (DF 40.10)
http://dffd.wimbli.com/file.php?id=9663
I don't see any mention of twbt or other plugins in the crash log. Can't be completely sure since there's no debug info for DF though. But if Toady accepts crash dumps, you should probably send him this one. I'll check z-level scrolling with twbt as well anyway.
Post by: LeoCean on September 10, 2014, 05:33:45 pm
#METAL INDUSTRY
workflow amount BAR//COAL 500 250
workflow amount BAR//COAL:coke 500 250
workflow amount BAR//INORGANIC:COPPER 50 25
workflow amount BAR//INORGANIC:SILVER 50 25
workflow amount BAR//INORGANIC:IRON 50 25
workflow amount BAR//INORGANIC:BRONZE 50 25
If anyone has a big fort with lots of stuff they want to upload so I can test the override graphics I've been working on that'd be great.
Spoiler (click to show/hide)
Those are the one's I've got completed + some others I didn't write into the overrides file yet, just have to write the overrides for them(easiest part) and make sure they are working and look decent, plus a bit more editing of some of them. Then work on the tree branches and stuff which I'll probably do later, in a way it's easier than that stuff but it's a lot more than that stuff.
Post by: Erde on September 11, 2014, 03:54:04 am
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).
Thanks a bundle. A shame, but I guess it is a lot better than nothing. I was hoping to get rid of these odd tileset letter oddities shown below by using a truetype font with a tileset.
(http://i.gyazo.com/aaa2a13526a41c67404746869b6a660a.png)
Post by: Meph on September 11, 2014, 03:58:00 am
Try this one as your font tileset:
Spoiler (click to show/hide)
Post by: PeridexisErrant on September 11, 2014, 04:03:47 am
@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 :)
Post by: mifki on September 11, 2014, 04:26:15 am
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 :)
Going to do this now, and for 40.12 probably)
Post by: CLA on September 11, 2014, 08:42:09 am
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.
Post by: PeridexisErrant on September 11, 2014, 09:23:55 am
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's an exact copy of CLA, except that the shaded squares look odd in text so I replaced them with a period, comma, and apostrophe. It didn't occur to me to check it against Myne, and I didn't know about Haowan :P
Post by: CLA on September 11, 2014, 10:07:54 am
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.
That reminds me
@mifki:
Can we already use separate tilesets for the following:
* bin, cursor, up/down stairs
I know bin and u/d stairs already worked, but what about the cursor?
* doors of various materials
* all the new tree tiles you can specify in the init files
and if so, what about specific trees? Say you want to have different leaves for deciduous and coniferous trees. Would you need to change the raws (so spruce leaves uses tile #123, and apple leaves use tile #456), and then assign them to a different tileset with twbt, or could you skip the raw changes and define, say, TREE:SPRUCE:LEAF or whatever to use #123 on tileset X and TREE:APPLE:LEAF to use tile #456 on tileset Y solely through overrides.txt without touching the raws?
Post by: LeoCean on September 11, 2014, 11:27:28 am
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.
If you downloaded twbt and looked at the readme you'd see everything you can override.
Post by: Arumba on September 11, 2014, 11:48:44 am
Post by: Dirst on September 11, 2014, 12:59:12 pm
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.
The fix is for the manager screen to use the text font, which I thought it already did. I just don't really notice the shape of those symbols on the manager screen, the color tells me what I need to know.
Post by: CLA on September 11, 2014, 01:33:04 pm
Quote from: LeoCean
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.
Quote
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.
Quote
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?
The point being, if I could, I wouldn't have to maintain two separate sets of raws for a twbt and a non-twbt version.
Quote from: Arumba
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.
Post by: muppet9876 on September 11, 2014, 01:59:19 pm
http://dffd.wimbli.com/file.php?id=9670
Post by: LeoCean on September 11, 2014, 02:02:43 pm
I'm pretty sure you'd need different raws if you wanted to have different leaves for the trees, it's not really that much of a problem because it'd only be a few files you'd have to change and it doesn't hurt save games.
Hmm wood doors from the raw should be 186 which is a wall upwards tile. Then 197 is the normal door. Then metal doors are 240.. 216 are door designations. (which I thought were the metal doors) You may be able to override all of those tiles, I'm not sure. If I actually had a map where I had those doors I'd check but I don't.
Post by: Erendir on September 11, 2014, 02:37:34 pm
Hmm wood doors from the raw should be 186 which is a wall upwards tile.
wooden door is inverted 186, and it's looking strange, so I'm using this:
Code: [Select]
[OVERRIDE:186:B:DOOR:Door::UDStairsTS:197]
[OVERRIDE:186:I:DOOR:DOOR::UDStairsTS:197]
Post by: mifki on September 11, 2014, 05:27:23 pm
A new Crash dump, definitely from the automaterial plugin this time ;).
http://dffd.wimbli.com/file.php?id=9670
Yep, this time it's me, thank you.
Sorry, I'm so tired lately, just don't use versions from autobuild server in any packs until I release new 4.xx version officially.
Post by: mifki on September 12, 2014, 06:10:17 am
Can we already use separate tilesets for the following:
* bin, cursor, up/down stairs
I know bin and u/d stairs already worked, but what about the cursor?
* doors of various materials
* all the new tree tiles you can specify in the init files
and if so, what about specific trees? Say you want to have different leaves for deciduous and coniferous trees. Would you need to change the raws (so spruce leaves uses tile #123, and apple leaves use tile #456), and then assign them to a different tileset with twbt, or could you skip the raw changes and define, say, TREE:SPRUCE:LEAF or whatever to use #123 on tileset X and TREE:APPLE:LEAF to use tile #456 on tileset Y solely through overrides.txt without touching the raws?
There's a secret [CURSOR:tileset:tile] command but I don't recommend to use it and probably will remove it because it can replace only the original game cursor, but there's number of plugins that draw their own pseudo cursors with hard-coded 'X' and it's impossible to track and replace all of them. So I'd recommend to use X in the main tileset as a cursor and override it for bins/stairs.
Up/down stairs can be overridden in 4.xx only with an override by tiletype (see readme if didn't use it before).
Spoiler (click to show/hide)
Leaves are not items, but there are tiletypes for tree parts, so it's possible to override them in 4.xx only. And yes, you'll have to assign different tiles in raws if you want different tiles for different plants (and you can't use numbers >255 of course).
Spoiler (click to show/hide)
In general, I'm not experienced in raws and other modding things, so again I recommend reading the readme from 4.xx version, all three override types are documented there with lists of possible values. Some other override types are planned, but if you have any ideas, feel free to write them. One of the things I do NOT want to do is to deal with materials in twbt.
Ah yes, version 4.57 fixes the crash in automaterial plugin, it was a bug in original plugin that just didn't lead to a crash without twbt.
Post by: CLA on September 12, 2014, 07:54:43 am
[trees and stairs/bins]I'll do that. It's good enough.
Quote
In general, I'm not experienced in raws and other modding things, so again I recommend reading the readme from 4.xx version, all three override types are documented there with lists of possible values. Some other override types are planned, but if you have any ideas, feel free to write them. One of the things I do NOT want to do is to deal with materials in twbt.Yeah, I read the readme in the meantime. Thanks for clarification.
As for suggestions, after ctrl+f'ing my TODO list for TWBT on the readme, I'm left with one item:
* engraved floor / status icon (injury) / Bauxite
Ideally, I'd move engraved floors to a separate tileset, so I don't have to change the raws for Bauxite.
Post by: mifki on September 12, 2014, 08:07:36 am
Post by: Eko on September 12, 2014, 08:49:17 am
I am wondering if there's a way to make tiles transparent. I'm looking at making pathable water transparent, instead of obscuring workshops and stockpiles underneath.
The issue that I have right now is that the background color of water is hardcoded to blue, which means no matter what I make the tile, there's that opaque background that I can't get rid of. Would there be any way to add a special token or something in the overrides to not draw the background color at all?
I know I found (somewhere...) a list of all the possible tokens for things that can be overridden, and I'm sure it isn't had to override only certain levels of water, but for the life of me, I can't find it again.
Post by: mifki on September 12, 2014, 08:59:39 am
Several pages ago I was experimenting with rendering things in several layers so that you see what's really behind items, buildings, etc. but that's very difficult to implement and far from being finished.
Post by: Eko on September 12, 2014, 09:14:42 am
It only renders the top-most tile no matter what, so if there's water on top, it isn't visible. Ok, I understand now.
Now I have to see if I can strip out the water rendering code, code cave a routine to only draw if >3 water in a tile.
Thanks for the help.
Post by: mifki on September 12, 2014, 10:28:27 am
In general, now I (again) hope I've fixed all major bugs and issues with 4.xx and included plugins.
Post by: notfood on September 12, 2014, 10:37:23 pm
Post by: salithus on September 12, 2014, 10:40:56 pm
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
Post by: mifki on September 12, 2014, 11:16:21 pm
Post by: salithus on September 12, 2014, 11:29:53 pm
Just change .11 to .12 in cmakelist.txt in dfhack root folder.
worked like a champ once I fixed my init (had FONT twice instead of FULLFONT). thanks!
Post by: int_ua on September 12, 2014, 11:52:04 pm
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.
Quote
Can't load plugin /home/int/games/df/df_linux/hack/plugins/twbt.plug.so
Ok, it worked. Just had to edit Makefile:
Spoiler (click to show/hide)
Found it, multilevel 5
Post by: PeridexisErrant on September 13, 2014, 07:58:43 pm
One thing that struck me as odd though was that the vanilla zoom commands change the text, and console commands change the map zoom level - it seems much more intuitive to have it the other way around both because the text is changed in much more obvious ways and because users generally want to leave the text tiles at their default size. Given that I got similar feedback when I briefly had the next gen branch in the starter pack a while ago, would you consider changing it? It's one of those minor-but-major UI issues...
Post by: mifki on September 13, 2014, 10:48:29 pm
Post by: Grumalg on September 14, 2014, 02:05:11 am
See: http://msdn.microsoft.com/en-us/library/windows/desktop/ms632589(v=vs.85).aspx
Edit: fixed typo
Edit 2: 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.
Post by: PeridexisErrant on September 14, 2014, 04:18:49 am
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.
Let's start by assuming that TwbT zooms the map-tiles with console commands, and the text-tiles with standard commands, and you're using keybindings that zoom DF with the mousewheel. This is the current vanilla state of affairs.
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.
Post by: Grumalg on September 14, 2014, 04:28:39 am
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.
DFHack is pretty limited in keybinds per it's docs:
Quote
Currently 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.
Post by: PeridexisErrant on September 14, 2014, 05:41:30 am
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.
...Bugger. Keybinding "bigger/smaller" to something should still be useful though - and if those commands changes the text and normal zooming the map tiles it'd be less of a problem.
I guess my proposal then is that the focus should be on a more general expansion of DFHack's keybinding capabilities, rather than hardcoding a one-OS workaround that matches specific keybindings. *touches wood* How hard can it be?
Post by: Grumalg on September 14, 2014, 06:34:19 am
The DFHack keybind limits makes choosing a sets of keys for map/text zooming a ugly issue, as DF uses so may keys that finding a set of binds that doesn't conflict with DF's keys within the DFHack keybind limits forces you to make non-esthetic choices.
I'm currently using shift-O and shift-P as was suggested earlier in the thread. This has side effects, as pulling a lever changes your map zoom (making a dirt road probably does too, though I've not tried it).
Thses keys do not auto-repeat in the TwbT/DFHack/DF combination, so holding them doesn't allow quickly changing map zoom level - it takes a bunch of keystrokes to change it much. Not sure if DF has these keys configured to not autorepeat or of DFHack is responsible for the lack of repeat - haven't looked. In any case, that's why I asked mifki to make the amount of zoom change/keystroke adjustable. He added twbt tilesize +<delta> | -<delta> to handle this.
Since DF natively supports the mousewheel for zooming everywhere, I felt remapping things so regular mousewheel for map zoom and Ctrl-mousewheel for text zoom would quickly be intuitive for many users. It would also be fairly easy to code. Much easier than having to create a full featured user defined keybinding system on his own. I doubt mifki will want to bite off that task.
That being said, it would still be easy to use mousewheel and/or a fixed known set of keys. The "[/]//{/}" set isn't a bad choice for a non-user settable fixed set of keys that doesn't conflict with DF.
While I'm speaking of the Win API, 'hooking' is a quite common technique and I'll be very surprised if the equivalent of this isn't available in OSX and *nix as well.
In windows terms you have to get the HWND of the target window to establish the hook on. Usually you can ask for it by the name of the window. Worst case takes enumerating the windows on the system to find it at initialization by means other than name.
Once you have it, the link I posted earlier shows how it's done - with code examples. I also should have mentioned that you don't need to pass any commands through DFHack console at all with this technique, you'll already be in your code with the necessary info to just call your own routines to act on input.
Post by: Pidgeot on September 14, 2014, 06:51:01 am
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.
Post by: PeridexisErrant on September 14, 2014, 06:55:44 am
That's whey I genuinely think the best solution is to zoom the map with whatever the standard zoom keys are (default: mousewheel), and just have the other commands given standard keybindings through dfhack. Clearly it would also be good to allow a wider range of keybindings through dfhack, but I think that should be a general goal rather than specific to TwbT. This would also help with localisation issues, since it would be as easy to change as anything else.
Post by: Grumalg on September 14, 2014, 07:56:04 am
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...
Post by: Pidgeot on September 14, 2014, 08:09:29 am
Sheesh - How do you get along without [, ], {, and } ? Every programming language I know uses those character extensively...
Why do you think I'm writing my LNP fork in Python :P (Also I have a macro keyboard so I can allow them to show up with just one keypress if I really need to)
They're still there, they're just not on the same key. (Some programmers switch to a US layout while coding just for this, I don't though...)
Of course I could use AltGr-8/9/7/0 even if those characters were used, but as you can see, that is already far less obvious how they map over than on a US keyboard
Post by: fricy on September 14, 2014, 08:12:13 am
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.
Post by: mifki on September 14, 2014, 08:20:22 am
Post by: Grumalg on September 14, 2014, 08:33:59 am
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.
<gets down on knees and thanks the God(dess) for having been born in the land of defaultia>
You still working on a 32x32 tileset(s)?
Waiting with baited breath for a good one...
Running at 2560x1440 on a 27" here as main monitor. Figure I'm gonna love a more detailed tileset.
Post by: Grumalg on September 14, 2014, 09:05:03 am
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.
What do you think the chances are for DFHack keybinding support to change?
It's your choice, but what I'm suggesting for the Win case likely amounts to 1-2 pages of code that's far simpler than most of your code. You'd hook in ahead of DFHack and transparently pass everything except the map/text zoom stuff.
<Shrug> hope one of you makes the changes... It'd make use of TwbT far simpler for the non-techy types and encourage wider use.
Post by: lethosor on September 14, 2014, 10:36:24 am
Edit: The mousewheel appears to use SDL_MouseButtonEvent, which makes combinations with modifier keys difficult to handle.
Post by: 0x517A5D on September 14, 2014, 12:11:52 pm
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.)
The number keys, please! (The main row, not the keypad.) It's low-hanging fruit, and I've wanted them for a long time.
Right now I'm looking at library/Core.cpp:parseKeySpec(), and it's very limited as to what it parses. And I'm thinking, how does DF itself translate the interface.txt file into actual keybindings? Somewhere, something's parsing [SYM:4:Equals] into Key=61, Mod=KMOD_ALT, can it be hijacked?
I'm also wondering if there should just be a way to stuff in the raw SDL::Key and modifiers, as found in SDL_keysym.h. So if a C++ coder wanted to trap, say, Ctrl-Alt-F15, she could just include that header file and use the symbolic name K_F15 with KMOD_CTRL|KMOD_ALT.
Edit:
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!
Post by: LeoCean on September 14, 2014, 12:15:43 pm
http://www.bay12forums.com/smf/index.php?topic=129219.msg5659262#msg5659262 New overrides.
Bug
#Alt 71 or 73 in tileset :88]
[OVERRIDE:88:T:ConstructedStairUD:3:88]
Is ok to write but,
[OVERRIDE:88:T:ConstructedStairUD:3:88] #(:88] Alt 71 or 73 in tileset) or #Alt 71 or 73 in tileset :88]
Causes a error (i.e it doesn't find tileset 88), this only happens on tile overrides and not building (B) or item (I) overrides. I was testing this on version 40.10 though so maybe it was fixed I don't think it would have been though. version 4.49 probably.
Post by: lethosor on September 14, 2014, 12:41:28 pm
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!
Post by: Grumalg on September 14, 2014, 01:19:52 pm
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.
Given the dicussion of international keyboard layouts earlier, it's pretty clear it won't be easy to satisfy everyone.
Unfortunately, for US style keyboards it's precisely the [/{ and ]/} keys that are one of the best pairs for a second zoom up/down pair that TwbT needs with minimal finger reaching and DF doesn't use them for anything. Non-US keyboard styles will want something else.
Since such a zoom is frequently used and one may be almost anywhere in DF when you want to use it, it's hard to find *any* alpha keys that won't conflict somewhere.
Function keys require an extra reach which isn't what you want for such a frequently used operation, though they are good for less frequently used actions - especially with modifier keys so they don't conflict with DF Hotkey locations.
I guess the best answer is 'everything you can support reasonably'. No one would complain about being able to use *every* key, but will settle for as much as you can give.
As many punctuation and 'special' keys as possible. All the shifted numeric row symbols. It's likely that even stuff like 'insert', 'delete', 'home', 'end', 'page up', and 'page down' may be useful to plugin writers and people wanting to bind command lines to keys as well - as they avoid alpha key conflicts.
It may also be useful to be able to tell DFHack to eat a bound keystroke and not send it on to DF after acting on it. Something like a flag/parameter that says eat this keystroke after you recognize it on the keybind command line setting up a bind.
This would allow people to say "I never use '.' One-Step or ';' Movies or '?' Help - if I bind them with key eating they won't also be sent to DF for action and I get a free extra key". I say this because of noting the useing shift-P and shift-O for map resize bindings as was suggested earlier in this thread both pulls a lever *and* resizes the map.
The mousewheel poses interesting problems because you'd like to be able to distinguish mousewheel and mousewheel+modifier key just like click and click+modifier key are useful when seperately sensed. If this can be handled, mousewheel+modifier key(s) might become useful to plugin writers for scrolling long lists for example.
Since DF uses mousewheel for zoom by default, I still think a very intuitive mousewheel use with TwbT would be for mousewheel to zoom the map and mousewheel+Ctrl would zoom the text. I map zoom a* lot* more frequently than I text zoom with TwbT, so normal mousewheel is a better fit to map zooming than text zooming.
This would require some coordination between DFHack and TwbT though as you'd need to be able to suppress normal mouse wheel operation from getting to DF after it was used to TwbT map zoom and recognize mousewheel+Ctrl must be stripped of the Ctrl modifier before being sent to DF as a normal mousewheel action.
I'm an old fart, and I haven't been coding for a living for a bit over a decade. So I haven't dug into DFHack code as I never expect to be writing for it. So my comments are based on ergonomics and ease of use rather than knowing what's reasonably expectable to be possible.
Post by: Grumalg on September 14, 2014, 01:47:42 pm
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!
Sounds like the Ctrl-mousewheel side is solved :)
Post by: Freak2121 on September 14, 2014, 04:44:32 pm
Post by: mifki on September 14, 2014, 04:56:07 pm
Freak2121, thanks for the report, I'll take a look.
Post by: kr0pper on September 16, 2014, 12:30:28 pm
I'll probably try to add support for binding mouse events into dfhack then.
It's a good idea, I try to make navigation through main menu with mouse, but only way is external remapping utilities like autohotkey.
Post by: 0x517A5D on September 16, 2014, 01:42:26 pm
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.
Oh, that reminds me. I've had some wonky behavior from the guide-path script, and it just occurred to me that it might be due to TWBT. A bit of testing, and it looks happens when using TWBT-nextgen.
The bad behavior involves screen painting when the script jumps to a minecart stop. Often the fortress viewscreen turns nearly all black, displaying just a few symbols related to the minecart stop and route. Sometimes the viewscreen doesn't properly refresh after the jump to the new viewpoint, it just keeps showing the old invalid data with (again) a few symbols related to the stop and route. The viewscreen corruption persists even after other viewscreens are invoked (e.g. the 'z' Fortress Status screen).
Reproduction in Windows, DF 0.40.11, DFHack 0.40.11-r1, TWBT 3.41 and TWBT-nextgen 4.61:
- if necessary, delete the TWBT plugin. start the game, load a fort.
- use the Wiki's directions to set up a minecart hauling route that has a Z-level change. (You don't even need track to do that.)
- change the viewed Z-level away from both stops.
- press h to call up the hauling menu
- select the first stop of that route and press Enter to work on its settings.
- press Alt-P to invoke the gui/guide-path script.
- (If that doesn't work, you don't have the keybinding, so invoke it manually by going to the DFHack console window and type in 'gui/guide-path' and press Enter.
- press c to change the view to the current stop; press n to change the view to the next stop. Experiment with these until you understand what normal behavior looks like. Save your fort and quit the game
- install TWBT 3.41, reload the fort, and do steps 3 through 7 again.
- note that behavior has not changed, it is still correct.
- delete the TWBT plugin, install TWBT nextgen 4.61, reload, and do steps 3 through 7 again.
- This is the important part: note the screen corruption that occurs when c and n are pressed, and may occur when the Alt-P is pressed.
- Also note that screen corruption can also persist when you Esc, Esc, Esc all the way out to the main DF menu.
Oh, this was without tweaking the multilevel setting; it was set at default.
Post by: lethosor on September 16, 2014, 02:03:22 pm
Post by: 0x517A5D on September 16, 2014, 02:33:31 pm
Does resetting the zoom (F10 by default) change anything?
Good thought. Testing... no, it shows the same behavior. Also if I switch to/from fullscreen, it still has the same behavior.
Post by: LeoCean on September 16, 2014, 02:52:38 pm
Post by: mifki on September 16, 2014, 06:03:59 pm
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.
Post by: LeoCean on September 16, 2014, 07:34:47 pm
Here's a sort of map legend for the map tiles.
http://dwarffortresswiki.org/index.php/v0.34:Map_legend
http://dwarffortresswiki.org/index.php/DF2014:Map_legend
So when it becomes available to create a map tileset it shouldn't be that hard for people to whip one up, at least a rough draft.
Post by: mifki on September 17, 2014, 12:55:27 am
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.
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.
Post by: notfood on September 17, 2014, 10:52:22 am
Post by: Roses on September 17, 2014, 11:07:01 am
Post by: LeoCean on September 17, 2014, 11:54:28 am
I wonder why bamboo requires varied grass, even if you get rid of the 3 other numbers it still won't show them if you don't have varied grass on, and varied grass takes tiles that are used in other things that make them less refined for the things that are plain grass. If we could override grass tiles that may make it look better.
Post by: 0x517A5D on September 17, 2014, 02:21:00 pm
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.
Post by: mifki on September 17, 2014, 05:21:52 pm
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.
Me too. But I'm afraid twbt-nextgen is not popular enough for dfhack maintainers to welcome all the required changes to dfhack main code.
While not being the best solution, it's not a problem for me to provide modified versions of several plugins, and I didn't know that there are also scripts that draw on the map area.
Post by: lethosor on September 17, 2014, 05:38:56 pm
Post by: mifki on September 17, 2014, 05:51:10 pm
Is the source of these modified plugins available?
They're in the nextgen branch of twbt repo. But there's nothing interesting, just some hacks to make them compatible with twbt without modifying dfhack.
Spoiler (click to show/hide)
The proper way would be to add another parameter to functions that paint on screen and that return screen size - whether to use map buffer/size from twbt (if it's loaded) instead of the normal df buffer. Default that parameter to false (as most plugins draw text), and update plugins that draw on the map.
Post by: LeoCean on September 17, 2014, 06:44:26 pm
Post by: Rose on September 17, 2014, 11:18:45 pm
Post by: mifki on September 18, 2014, 02:06:37 am
There's actually more scripts that write to the screen than plugins, as that's the preferred way of making a gui in dfhack.
To screen doesn't necessarily mean on the map.
Post by: LeoCean on September 18, 2014, 11:01:15 am
Pretty sure it is done in twbt.cpp though there was nothing saying r1, so why didn't it work for them on r0...
Post by: salithus on September 18, 2014, 12:19:32 pm
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...
Post by: fricy on September 18, 2014, 12:26:44 pm
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.
Post by: salithus on September 18, 2014, 12:53:44 pm
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.
Post by: lethosor on September 18, 2014, 02:42:08 pm
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...
The code that actually embeds the version string in plugins is part of the DFHACK_PLUGIN macro:
Quote from: library/include/PluginManager.h
#define DFHACK_PLUGIN(plugin_name) \
DFhackDataExport const char * version = DFHACK_VERSION;\
DFhackDataExport const char * name = plugin_name;\
DFhackDataExport Plugin *plugin_self = NULL;
Post by: mifki on September 18, 2014, 05:10:19 pm
@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. :)
I was thinking about automating this process, at least for some time while changes in df are minor.
However it's not that difficult even manually - I spend more time downloading new releases for all platforms / copying configuration and all that stuff in order to test after I add support for new df version.
So probably now I will add required addresses to twbt but won't test on Windows / Linux.
Also I'll add a CMakeList file so that it will be possible to build twbt as part of dfhack.
Post by: PeridexisErrant on September 19, 2014, 08:32:18 pm
Post by: mifki on September 20, 2014, 12:59:50 am
DFHack 40.13-r1 is out ;)
Will do it today or tomorrow. Want to further automate my builds - it's getting a bit boring to update for each version.
Post by: LeoCean on September 20, 2014, 09:33:07 am
Post by: scamtank on September 20, 2014, 10:04:12 am
Post by: mifki on September 20, 2014, 10:08:52 am
I decided to make some internal changes so the nextgen branch will be later.
Post by: LeoCean on September 20, 2014, 10:12:03 am
He committed the last pile of .13 changes not even an hour ago. Jesus, have a little patience.
Well I did look at both the release and the development branch before I posted that (I'm pretty sure I didn't see changes). :P There was the chance he was still awake but it's very late for him.
Anyways thanks mifki.
Post by: thistleknot on September 20, 2014, 05:35:05 pm
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?
Post by: salithus on September 20, 2014, 05:46:38 pm
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?
Post by: mifki on September 20, 2014, 06:19:32 pm
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?
What? It's on my dev build server http://build.mifki.com but you don't need to compile it.
Post by: LeoCean on September 20, 2014, 07:22:02 pm
Post by: scamtank on September 21, 2014, 06:45:20 am
Post by: mifki on September 21, 2014, 06:48:58 am
Uh, your build server looks slightly fucked. Did you change something?
It looks slightly preparing for the next major version. Old releases are on github.
Post by: HaterSkater on September 21, 2014, 08:25:41 am
World creation in 40.08. Spacefox (text tileset) used as expected
Spoiler (click to show/hide)
World creation in 40.13. Map drawn with duerer (graphic tileset) with spacefox artefacts
Spoiler (click to show/hide)
same problem on embark screen
Spoiler (click to show/hide)
What am i doing wrong?
Post by: fricy on September 21, 2014, 08:44:35 am
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?
Post by: mifki on September 21, 2014, 08:52:12 am
What am i doing wrong?
What exact problem you're talking about?
On the second image I see some black artefacts, and on the third - last two columns of the world map use spacefox instead of duerer.
Or something else?
Post by: HaterSkater on September 21, 2014, 08:57:38 am
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.
That's not macnewbie, just plain dfhack. Though, same thing occurs in macnewbie too, but with two of my tilesets installed by default it was difficult to discover. The point is i was expecting text tileset to be used in worldgen/embark map. Fact that i found artefacts is coincidence :)
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.
Post by: mifki on September 21, 2014, 09:12:35 am
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).
Post by: HaterSkater on September 21, 2014, 09:17:59 am
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 :)
Post by: mifki on September 21, 2014, 09:22:15 am
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...
Post by: Meph on September 21, 2014, 09:27:28 am
Quote
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. ^^
Post by: fricy on September 21, 2014, 09:50:55 am
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. ^^
Post by: HaterSkater on September 21, 2014, 09:53:21 am
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...
Haha that so familiar :)
I'm standing for text on embark screen, because:
1. I'll be able to modify graphic set more freely since it's used only on main game screen
2. That gives me opportunity to incorporate map-specific signs in my pack. For example μ (crown in game / ruins on map) may be drawn as actual ruined city. And ramps may be redrawn as mountains, looking like on this map
Spoiler (click to show/hide)
Post by: fbo on September 21, 2014, 10:28:53 am
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 ;)
Post by: LeoCean on September 21, 2014, 12:30:19 pm
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.
Post by: Nopenope on September 21, 2014, 02:12:08 pm
Post by: LeoCean on September 21, 2014, 02:15:26 pm
Quote
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.
Yeah it's on the front page/first post of this thread.
Post by: Nopenope on September 21, 2014, 02:35:54 pm
Post by: LeoCean on September 21, 2014, 03:23:14 pm
Post by: Nopenope on September 21, 2014, 03:41:28 pm
Post by: mifki on September 21, 2014, 05:35:03 pm
Quick question: does twbt support VBO print mode?
TWBT replaces drawing code with its own, so there's no difference what's specified in init.txt It has to be any OpenGL-based mode so that the game creates OpenGL rendering class that the plugin expects.
But you're right, I see in the code I've added a check to accept standard mode only but forgot to change readme.
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.
There will be a single version that works as nextgen by default but can also be switched to legacy 3.xx mode.
Post by: LeoCean on September 21, 2014, 06:51:33 pm
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...
Just so you know the old gen has that issue if you hadn't seen the post in the lazy newb pack. The 40.11 version would of had your included twbt pluggins so they didn't fix it in the old gen or the old gen didn't load the fixes from those.
Post by: Dirst on September 21, 2014, 10:20:26 pm
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).
Post by: PeridexisErrant on September 21, 2014, 10:29:14 pm
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).
One immediate improvement in TwbT 4.xx would be to use 16x16 graphics tiles, 8x12 text, and 16x16 world map text.
Post by: mifki on September 22, 2014, 07:03:55 am
Important notes
Now there's only one version that can work as former "nextgen" branch or as former "stable" branch.
The plugin is now activated by setting PRINT_MODE to TWBT or TWBT_LEGACY in init.txt (probably this will change in future, I'm deciding where it's better to store configuration).
If PRINT_MODE is set TWBT but "nextgen" behaviour isn't available for your version of DF or your operating system, it will fall back to legacy mode.
There are no significant changes in DF code between versions, so I don't test updates that add support for new DF version on anything except OS X, so if it crashes just let me know.
Post by: scamtank on September 22, 2014, 07:07:02 am
Post by: scamtank on September 22, 2014, 11:33:54 am
Post by: LeoCean on September 22, 2014, 12:18:50 pm
Post by: BigD145 on September 22, 2014, 12:28:47 pm
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.
The dashboard has been throwing errors for a couple days.
Post by: LeoCean on September 22, 2014, 12:56:10 pm
Uh, your build server looks slightly #$#$%#. Did you change something?
It looks slightly preparing for the next major version. Old releases are on github.
Post by: scamtank on September 22, 2014, 01:24:25 pm
Post by: anachron on September 22, 2014, 02:03:25 pm
Post by: mifki on September 22, 2014, 11:22:54 pm
Post by: LeoCean on September 22, 2014, 11:54:13 pm
Post by: muppet9876 on September 23, 2014, 02:57:39 am
http://dffd.wimbli.com/file.php?id=9777
edit: 5.12, working great, no TWBT issues to report.
Box select isn't working on automaterials plugin but it is also broken on vanilla dfhack too.
Post by: Erde on September 23, 2014, 09:02:11 am
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 problem. On Win7 also.
Code: [Select]
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
Edit: also reported this on github for good measure.
Post by: Erde on September 23, 2014, 09:23:13 am
It seems to be dependent on dfhack files. I can see in the Visual Studio project file that $(dfhack) should tell the location of dfhack folder but can't find where this value is defined exactly.
Then I tried to just lump all the required header files and sub-folders from dfhack's include folder to the root of my work directory and compile it then, but got errors on some coreprotocol.pb.h nonsense (my late night memories are fuzzy) and then having to find those files from dfhack source and still etting errors of it couldn't find some protobuff google folder (which I also dumped to the root of the work directory) aragfgdf.
I even tried to compile twbt the same way as other dfhacks are compiled with it, but yeah, didn't work out (I learned quite a bit about CMake, though). xD
So could someone kindly tell me how this is setup?. Thanks. :D
PS: Please don't question my need to be able to do so. Just go with my word on it, ok? ;)
Post by: fbo on September 23, 2014, 11:37:05 am
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.
Post by: Erde on September 23, 2014, 12:27:39 pm
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.
This seems to be the case. Also, changing the multilevel value after the game has loaded leads to a crash.
Post by: scamtank on September 23, 2014, 12:30:34 pm
Post by: Erde on September 23, 2014, 01:17:26 pm
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.
I just tried the following:
multilevel 0 <- no crash
from 0 to 1 <- crash
from 0 to 2 <- crash
from 0 to 3 <- no crash and now can select any option from 0-5 without crash
Very odd.
Post by: mifki on September 23, 2014, 07:09:11 pm
Post by: Erde on September 24, 2014, 07:47:12 am
5.12 should fix this crash
Indeed it has on 5.12.
Thanks!
Post by: Scoops Novel on September 24, 2014, 10:14:08 am
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?
Post by: Erde on September 24, 2014, 11:39:28 am
Box select isn't working on automaterials plugin but it is also broken on vanilla dfhack too.
I notivced this too today. Not working with 5.12 nor with what is supplied with dfhack. Doesn't matter if box selection is made with mouse or keyboard, the designation to build the wall is never made. When box selection is disabled the wall construction works fine. Slowly. :D
Post by: lethosor on September 24, 2014, 12:55:21 pm
Post by: Erde on September 24, 2014, 01:33:50 pm
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?
Windows 7 running 0.40.13-r1. :/
Post by: LeoCean on September 24, 2014, 03:06:48 pm
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?
The one from the lnp most likely as I have that issue to, it does include twbt 3.41 but twbt shouldn't effect that.
Post by: lethosor on September 24, 2014, 03:14:24 pm
Post by: LeoCean on September 24, 2014, 03:26:38 pm
Post by: muppet9876 on September 24, 2014, 03:50:02 pm
edit: The edit to symbols.xml has it working, ty.
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.
Post by: lethosor on September 24, 2014, 04:12:53 pm
Post by: LeoCean on September 24, 2014, 04:33:47 pm
Post by: mifki on September 24, 2014, 10:51:19 pm
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?
After explanation how creature tiles work from Meph some time ago, now I have some thoughts about implementing creature overrides, but I don't have any time estimates at the moment.
Post by: Scoops Novel on September 25, 2014, 06:31:55 am
Post by: nomad_delta on September 25, 2014, 04:22:52 pm
I'm guessing mifki already knows about it, but figured I'd drop by and report it just in case.
I do love the mod, it's super awesome! I can't wait to start using multilevel view again once the crash thing is sorted out, but for now I'm happy at least having the other TWBT functionality.
Thanks,
--nomad_delta
Post by: LeoCean on September 25, 2014, 04:30:42 pm
Post by: nomad_delta on September 25, 2014, 04:45:40 pm
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.
Is version 5.12 actually ready for general use? I don't see it listed at all on the Releases (https://github.com/mifki/df-twbt/releases) page.
--nomad_delta
Post by: LeoCean on September 25, 2014, 04:58:27 pm
Post by: scamtank on September 25, 2014, 05:05:03 pm
Post by: nomad_delta on September 25, 2014, 05:15:43 pm
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.
Post by: PeridexisErrant on September 25, 2014, 07:11:47 pm
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 know, don't worry about that. I'll be doing some final testing of 5.12 integration later today.
Post by: mifki on September 25, 2014, 07:36:37 pm
Post by: nomad_delta on September 25, 2014, 08:20:28 pm
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 was happening for me even without zooming out, just going up several z-levels into the sky above the trees with multi-view enabled would cause it to crash on a fresh embark. I just installed the 5.12 version and am testing that though and no problems to report so far, although I haven't gotten too far into testing.
--nomad_delta
Post by: Kryxx on September 26, 2014, 08:08:08 pm
It's in the development builds on the first page/ post. It doesn't have any bugs so far that I've found.
I kind of disagree. PeridexisErrant put 5.12 into his latest pack.
When I world gen with Phoebus graphics, the world gen screen is 100% vanilla. It switches 2s after DF main screen loads. I can easily watch how the previous (3.41, I think is what was in previous packs), go from how it used to look to this. The font changes also.
If I set print mode to: TWBT_legacy it will convert part of the screen to use graphics, and leave the other section.
I've done this about on about 10 different worlds.
I like the other uses of TWBT but I don't want to view the world in the standard graphics. So what is wrong here or could be in conflict?
Someone said that it shouldn't be doing this, but it is.
Post by: LeoCean on September 26, 2014, 09:27:00 pm
Which I thought the new gen version was suppose to be graphics now or have a map tileset but I guess that isn't a thing that is happening yet? The font in the old gen was known I think, I knew about it at least. I don't think it was suppose to be in there. For now you can download the 3.41 version and use that until you are done with world gen then after the game saves on startup or you'll have to save anyways to close dwarf fortress you can just put the 5.12 version in dfhack/plugins. Since the 3.41 has some issues I believes, I can't really remember since I haven't used it in awhile.
Post by: Kryxx on September 26, 2014, 10:11:35 pm
I want the graphics. I'm using the latest version of PE's 40.13.R3 pack.
This included 5.12 of TWBT. However it's displaying the world gen part as text, doesn't matter if you leave the print mode as TWBT or use TWBT_Legacy it's always text for the world gen/creation.
It actually starts as graphics on load, for about 2s, then I watch it 'switch' to text. This tells me something isn't handling it right and switching it.
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.
However if that doesn't solve the issue of why it's needed or what is failing/incorrectly setup etc. I'm posting here because I don't know if it's a conflict setting with twbt?
This seems like it's a conflict somewhere or something isn't working right to display graphics.
Post by: mifki on September 26, 2014, 10:47:02 pm
Post by: Kryxx on September 26, 2014, 11:54:41 pm
I did.. and it looks like this.
http://imgur.com/7GoMtAx
2nd world gen
http://imgur.com/ExOexN6
So when DF loads I hit full maximize and that is why it displays that way. No zoom in or out.
So if I zoom in a lot.... I can get it to be 50/50.
http://imgur.com/OJzKmia
I can get it to split the screen this way 50/50. But the amount of wasted space... to view so little. I have an average widescreen (1900x1080) for a reason. To see more.
Is there a reason the whole right side in legacy is displayed as text? It wasn't this way in 3.41.
Post by: mifki on September 27, 2014, 01:26:22 am
Post by: LeoCean on September 27, 2014, 01:37:18 am
Quote
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.
I was actually proposing just copying and pasting twbt 3.41 over 5.12 till after world gen. It'd work until 40.14, all that's needed is the twbt pluggin in Dwarf Fortress 0.40.13\hack\plugins and what I said about copying and pasting the 5.12 twbt pluggin over it after world gen (once your embark has been loaded and you see your dwarves) you'll have to restart the game (not the save) for it to take effect.
Post by: mifki on September 27, 2014, 01:50:31 am
Post by: PeridexisErrant on September 27, 2014, 01:52:19 am
Post by: mifki on September 27, 2014, 02:08:54 am
Might that also cause issues with the TwbT-compatible resume, automaterial, and mousequery plugins?
The problem we're talking about is that legacy mode is just sort of broken, so no, it has nothing to do with normal mode or the plugins.
Or you've got some problem reports about plugins?
Post by: PeridexisErrant on September 27, 2014, 02:26:44 am
Post by: mifki on September 27, 2014, 02:33:12 am
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.
Oh, you mean will these plugins work ok without twbt? Yes, they should.
Post by: mifki on September 27, 2014, 03:31:02 am
Post by: muppet9876 on September 27, 2014, 01:06:22 pm
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?
Post by: Erendir on September 28, 2014, 04:32:08 am
Quote from: muppet9876
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?
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).
Post by: mifki on September 28, 2014, 05:44:34 am
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?
Some weirdness in automaterial plugin. I added more checks so it shouldn't happen in 5.14.
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).
Yeah, it's one of the things that are problematic with different tile sizes. I think I'll fix creature following, but I don't know how to fix zooming to announcement. However after (z)ooming you can just move cursor with arrow keys and the screen will move to the right place.
Post by: mifki on September 28, 2014, 08:01:42 am
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.
Post by: Vin on September 28, 2014, 09:53:40 am
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.
Thank you for your hard work!
Post by: muppet9876 on September 28, 2014, 02:42:55 pm
Win7 64bit, DFSP 40-11r3 TWBT 5.16, not forced any crashes on TWBT_LEGACY setting.
http://dffd.wimbli.com/file.php?id=9809
Forgot to put my dfhack init in the zip (just in case its relevant)
Spoiler (click to show/hide)
Post by: mifki on September 28, 2014, 04:14:20 pm
Post by: muppet9876 on September 28, 2014, 05:42:56 pm
Post by: Thormgrim on September 28, 2014, 11:29:54 pm
Post by: UristWoodie on September 29, 2014, 09:40:01 am
StarterPack PyLNP DF 40_13, R2
Created new image (72x72 pixels)
Added it to existing tileset (Vanilla DF - 24x - Items.png) and overwrote the top left 72x72 pixels, saved as Workshop1-24x.png.
overrides.txt:
Modified first line
[TILESET:Vanilla DF - 24x - Items.png:Vanilla DF - 24x - Items.png] to
[TILESET:Vanilla DF - 24x - Items.png:Vanilla DF - 24x - Items.png:2]
Added entries
[TILESET:Workshop1-24x.png:Workshop1-24x.png:3]
[OVERRIDE:Tile:B:WORKSHOP_CARPENTER::0:3:1]
Started DF, doesn't seem to make any difference. I'm guessing that I still need the original Tile ID# for the Workshop? Where can I get that?
(...and what else am I doing wrong?)
:'(
Post by: argh226 on September 29, 2014, 10:52:25 am
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.
Post by: Clément on September 29, 2014, 11:32:49 am
I didn't try workshop overrides but from what I understand you need one override for each tile.
You should read this post from meph (http://www.bay12forums.com/smf/index.php?topic=138754.msg5530509#msg5530509)
If I understand correctly, he modified the raws so that each tile of the workshop is different. Then the tile id will be what you wrote in the raws.
Edit: As scamtank said, this only works with custom building (soap maker and screw press, the others seem to be hardcoded).
Post by: scamtank on September 29, 2014, 11:40:12 am
This means that you can't really turn default workshops into bitmap puzzle pieces like you can with custom workshops. You can take the [ and make it a chair and turn all the ▓:s into tables and such, but not alter the overall arrangement.
Post by: UristWoodie on September 29, 2014, 12:01:03 pm
Thanks...so we cannot replace the OEM workshops at this time without considerable effort and remapping other objects. I'm hoping for some future change there, I think that would be a significant enhancement.
Post by: Clément on September 29, 2014, 12:30:58 pm
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.
Post by: UristWoodie on September 29, 2014, 01:42:40 pm
Post by: LeoCean on September 29, 2014, 01:47:13 pm
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.
Quote
You can still use overrides for workshops, but if two tiles are the same, they will still be the same with overrides.
Yes but instead of things that already exist someone could create a image for them.
Post by: Clément on September 29, 2014, 03:56:57 pm
UristWoodie, of course, you can use different tables (my main tileset is Mayday and those are LeoCean's) or whatever you want.
Post by: Erendir on September 29, 2014, 04:00:45 pm
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.
Post by: mifki on September 29, 2014, 04:39:32 pm
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.
You mean the font used for text (and right menu) is small or what?
Post by: LeoCean on September 29, 2014, 04:45:34 pm
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]
@Mifki/ @argh226 I think he is using the LNP and doesn't like the curse font it is currently using. He could just use the Spacefox_16x16_text.png font tileset that comes with twbt 5.17 and then change his Dwarf Fortress 40_13 Starter Pack r3\Dwarf Fortress 0.40.13\data\init init.txt file to [FONT:Spacefox_16x16_text.png], [FULLFONT:Spacefox_16x16_text.png] which is what I think he wants.
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
Post by: argh226 on September 29, 2014, 04:54:50 pm
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.
Post by: Erendir on September 29, 2014, 05:16:00 pm
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]
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]
Post by: mifki on September 29, 2014, 05:26:53 pm
@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
Post by: LeoCean on September 29, 2014, 06:08:11 pm
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]
I'm guessing the main point of that is
Quote
other are free to choose, but You MUST avoid assigning a single number to different tilesets!
I forget who wrote that but it wasn't me and it wasn't mifki (I know it was was when someone asked for more extensive overrides since at the time no one really created anything more than meph did). And my example is from a overrides.txt which you can download in the tileset area of Bay 12 Games Forum > Dwarf Fortress > DF Modding >, in the spacefox thread. The only ones who need to worry about such little technicalities are people who don't know what that stuff means as it is easily changed. Indeed this is easier to move to another overrides.txt of course you still need the "tileset png".
[TILESET:Override - 48x - Quiver.png:Override - 48x - Quiver.png:QuiverTileSet]
[OVERRIDE:146:I:QUIVER:QUIVER::QuiverTileSet:0]
But it doesn't matter if you create your own overrides.txt or use from a already created "set" and it's just cleaner to use numbers but still doesn't matter at all which way you do it. Neither is wrong.
Post by: argh226 on September 29, 2014, 07:35:34 pm
@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
Hi,
Ok. If I want to use that twbt like it should on the version 5.17... from the lnp which is 5.12 (I believe?) The Curse font, which doesn't appear to be with lnp how can I get it in ?
Thx :)
Post by: LeoCean on September 29, 2014, 08:07:31 pm
@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.
This pretty much says you are using that font, I just tested it myself and there's no way I'd use that small of a font.. You can always try the font's here Dwarf Fortress 40_13 Starter Pack r3\LNP\Graphics\ASCII default\data\art the curse series (you can use the one that says 16x16 if you just want bigger font). I understand why he wanted to use that small font but man it's hard to look at. To delete twbt you'd go to Dwarf Fortress 40_13 Starter Pack r3\Dwarf Fortress 0.40.13\hack\plugins and delete twbt.plug.dll. Then if you forgot how to change font sets look for my other post on the last page or 2 where I replied with the answer. 5.17 twbt (http://do1.mifki.com:8810/dashboard;jsessionid=aomk8ixzkgsxq91tcau045dd) includes the spacefox text but you'd still have to look at my earlier reply to figure out what to do with it.
Post by: argh226 on September 29, 2014, 09:28:53 pm
True, I did not read the whole 74 pages...
Here what I have :
http://imgur.com/2xlAEfi,BDy51DK
Picture 1 : stock like you said, right from http://dffd.wimbli.com/file.php?id=7622 (http://dffd.wimbli.com/file.php?id=7622)
Picture 2 : out of copying files from twbt 5.17 and twbt package (?) 3.43 with spacefox tileset
Although isn't quite good for my taste (I dont want to offend anyone) its font are bigger.
Post by: LeoCean on September 30, 2014, 12:34:24 am
Quote
True, 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.
Post by: Clément on September 30, 2014, 03:57:26 am
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
My overrides.txt is yours nearly unmodified. I just changed the tileset ids and commented out some lines. The carpenter workshop is the only workshop I did as a quick example for UristWoodie. But I thought about doing it some time ago and I had the tile numbers written in a file (with some errors, it is hard to see the difference between 176 and 177).
Post by: Lord Afabie on September 30, 2014, 04:34:30 am
Code: [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.
Post by: mifki on September 30, 2014, 05:07:37 am
I can only get this to work in TWBT_LEGACY mode. If I use TWBT, it printsCode: [Select]TWBT no display patchin the console, and DF runs without twbt enabled.
I am using ubuntu 14.04.
Any help would be appreciated.
This line is not actually an error.
I'll be able to test it on Linux tomorrow.
Post by: scamtank on September 30, 2014, 05:47:34 am
Post by: mifki on September 30, 2014, 06:18:11 am
Anyway, I just don't have enough time lately so it slowed down a bit.
Post by: PeridexisErrant on September 30, 2014, 06:34:05 am
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.
Post by: scamtank on September 30, 2014, 06:57:05 am
But honestly, no rush. You've already fixed almost everything that's been pissing me off about the tiles and text.
Post by: mifki on September 30, 2014, 07:15:09 am
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 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.
Also, feel free to remind me about other ideas, for example use orange colour for proposals. I'll create tickets for them on Github.
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.
Post by: Clément on September 30, 2014, 07:35:28 am
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?
Post by: scamtank on September 30, 2014, 07:42:45 am
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 can't find what was bothering you, but I'll get on that save right away. What were you missing?
Post by: mifki on September 30, 2014, 07:46:13 am
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?
Why not, they're part of the workshop, if I understood your question right. Actually the only problem with overriding "empty" workshop tiles is that the same tiles appear everywhere else, so I expect it to be very slow if you add an override for such a common tile number. Hm, this reminds me that there are still some optimisations possible in the override code. Also, I actually was going to provide a better way to override workshop tiles, because now if there are several similar tiles in a workshop you can't add different overrides for them, so ideally there should be parameters with coordinates (inside workshop) of a tile you want to override. These are plans for distant future though.
Post by: PeridexisErrant on September 30, 2014, 07:55:06 am
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
Post by: UristWoodie on September 30, 2014, 07:58:18 am
I just put in the 4-line set for the workshop..and interestingly, it did NOT override the images for the other table. Perhaps that's because
[OVERRIDE:176:B:WORKSHOP_CARPENTER:Workshop::Woodie:209]
(#176) is for a wooden table, and not stone one?
(waiting for a hauler to install the ashen table I just built to prove that)
Ok..the wooden table displays as a normal wooden table, not like the one in the Carpenters Workshop. :)
So...although it needs some tweaking, it seems like there's a pretty easy way to manipulate the basic workshops. Now that the SCIENCE is done, it's time to move on to the ART. 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. I'm thinking of additions to the PyLNP graphics tabs: TWBT-Overrides - select the override set you want, and LNP will copy over the art files, and put in the additions to the init file.
COOL!!
Post by: mifki on September 30, 2014, 07:58:54 am
I can't find what was bothering you, but I'll get on that save right away. What were you missing?
Thanks.
Everywhere where I see colour tokens in raws, for example STATE_COLOR for inorganic
Spoiler (click to show/hide)
and here POWDER_DYE for dye
Spoiler (click to show/hide)
I also see DISPLAY_COLOR token with approximated colour, oh well, for the dye there are three of them - STATE_COLOR, DISPLAY_COLOR and POWDER_DYE. 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?
Post by: mifki on September 30, 2014, 08:02:41 am
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.
Actually, I'll first use my new orange colour for proposals so that I don't forget it - I was going to add a way to include additional files with overrides to be able to install them individually. Basically, [INCLUDE:moreoverrides.txt] or maybe better [INCLUDE_FOLDER:] to include all files from a folder, if any.. hmm..
Post by: argh226 on September 30, 2014, 08:08:40 am
@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'm not familiar enough to play around with files from any tileset yet. I havent got any tutorial about this, so "my best guess" is what I use the most right now :)
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.
And right now I probably am mixing all that up togheter. 16x16 curse, twbt 5.17, R2 vs R3, phoebus vs spacefox and well... I might simply go back to R2 :P
Still, thanks for the support :D
Post by: mifki on September 30, 2014, 08:13:57 am
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.
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.
Post by: Clément on September 30, 2014, 08:18:00 am
This problem already exists in the vanilla game and I don't think it happens very often. So don't bother with it. And your coordinate suggestion is better as it allow the use of big images for workshop like UristWoodie wanted.
@UristWoodie 176 is not a table tile, it is the not-passable tile of several workshops (░). I used a table because of scamtank suggestion but you can use whatever you want.
Post by: scamtank on September 30, 2014, 08:18:10 am
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.
I think smuggling the STATE_COLOR values out into the open would be the ideal solution as far as usability goes.
Post by: mifki on September 30, 2014, 08:24:50 am
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.
Ok, so in short, if I make it possible to use more colours, then for dyes no changes required to raws - it should just approximate POWDER_DYE value to, say, 256 colours instead of 16. But for materials you'll have also first to define rgb values for additional colour indexes (again, 0-255 instead of 0-8) and then update DISPLAY_COLOR to make use of them, right?
Oh actually another question/problem - DISPLAY_COLOR defines background/foreground colours while colour tokens define only one colour...
Post by: scamtank on September 30, 2014, 08:47:28 am
If you're going to modify materials, keeping all the colors in one place (descriptor_color_standard.txt) would make sense.
e: Dang, didn't even consider the background thing. I need to think about this.
Post by: argh226 on September 30, 2014, 09:25:05 am
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.
Dont worry about it, I wasn't pointing it at you, but rather at my ignorance about the whole MOD community. I'll keep on reading and eventually will get a hang of it.
Until then I'll stick to my weird setup (see my 2 images, 1 or 2 pages back)
:)
Post by: Dirst on September 30, 2014, 10:22:57 am
For gems and hardcoded materials, the STATE_COLOR is generally compatible with the DISPLAY_COLOR and so on (except for liquid water which is displayed blue but colored "clear"). For bodyparts and bodily fluids, the STATE_COLOR is the only color defined.
Non-gem stones don't define STATE_COLORs at all, relying on the stone template which defines the solid STATE_COLOR as GRAY. This means a Dwarf with Gray as a favorite color is probably going to be perpetually happy, but it also means that the DISPLAY_COLOR, BUILD_COLOR, etc. are inconsistent with the STATE_COLOR.
It'd be possible to just display things in their STATE_COLOR and everything would work as expected. Except for stone. Which shows up fairly often in a typical DF game.
My suggestion would be to scope local display colors within materials, basically assigning the STATE_COLOR's rgb values to the closest display color. For example, an AUBURN material would set the closest display color (4:0 which is "red") to 111:53:26 and use that anywhere that red was called for. This conveniently side-steps the GRAY issue for stones if the display colors conflict with the STATE_COLOR, since that display color just doesn't get used anywhere.
There are a couple cases that need some thought. For example, one modder might display an AZURE material (0:127:255) as light blue and another as cyan and yet another as light cyan. The plugin would customize one of those display colors and leave the other two as defaults. Personally, I'd rather live with near-misses like that than try to code in a bunch of exception handling to second-guess the modders.
Post by: mifki on September 30, 2014, 05:28:40 pm
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).
Anyway, scam tank and Dirst, thanks for the explanation, I'll try the simple things first and then we'll see.
Post by: mifki on September 30, 2014, 09:54:19 pm
I can only get this to work in TWBT_LEGACY mode. If I use TWBT, it printsCode: [Select]TWBT no display patchin 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?
Post by: UristWoodie on September 30, 2014, 10:18:25 pm
OK, I've been playing with the default workshop types, and thanks to the pointers here (clement!), I've made good progress.
I switched from WORKSHOP_CARPENTER to WORKSHOP_MECHANIC, as it's easier to find mechanisms laying around in this fortress.
So..
[TILESET:Vanilla DF - 24x - Items.png:Vanilla DF - 24x - Items.png:Van24x]
[OVERRIDE:128:B:WORKSHOP_MECHANIC:Workshop::Van24x:41]
[OVERRIDE:128:I:TRAPPARTS:::Van24x:43]
Line 1 causes all item #128 (mechanisms) that are a part of a Workshop_Mechanic (notice the B type and BuildingID) to use tile #41 found in Tileset "Van24x" (defined in line 0). Note that this does NOT affect tile #128 that is used with just an item.
Line 2 causes all item #128 (mechanisms) that are placed as ITEMS with the ItemID "TRAPPARTS" (like a mechanism in a stock pile), to use tile #43 from tileset "Van24x". Note that this does NOT over-ride the Workshop definition, that continues to work as before.
If Line 2 is left in w/o Line 1, as you may expect, ITEMS placed outside a Workshop display the VAN24x override, and the BUILDING PART (#128) displays the base tileset tile.
I do not know what the performance implications are, I know someone expressed concern about that earlier.
I think the ID map that was posted above for the Carpenter is not quite right...I think it should be:
61 34 34
176 39 96
176 93 176
Thank you, and good night.
Post by: Lord Afabie on October 01, 2014, 12:15:39 am
I can only get this to work in TWBT_LEGACY mode. If I use TWBT, it printsCode: [Select]TWBT no display patchin 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?
I checked again. I'm getting the two fonts now (I don't know why it wasn't working before), but multilevel isn't working. It changes the down ramps to up ramps, but doesn't actually show any more levels.
Post by: mifki on October 01, 2014, 12:22:57 am
Post by: Lord Afabie on October 01, 2014, 12:27:17 am
Post by: mifki on October 01, 2014, 04:25:20 am
Thanks! I really appreciate all the work you do to keep this plugin working for everyone.
Try 5.19.
Post by: Lord Afabie on October 01, 2014, 03:13:03 pm
Post by: Dirst on October 01, 2014, 03:43:28 pm
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.
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. Internally, you'd end up with something like
| Color name | Color token ID | Color token brightness |
| AMBER | 6 | 1 |
| AMETHYST | 5 | 1 |
| AQUA | 3 | 1 |
| AQUAMARINE | 3 | 1 |
3. Apply all other fancy shading and stuff from multiview, etc.
4. Render the tile.
This misses out on patterns of close colors (e.g., amethyst and violet stripes) but those never rendered correctly to being with.
A quick test would be to make the render routing instantiate a local copy of the display color table and use that for rendering (without any changes due to the object's named color). If that kneecaps the FPS, then this is the wrong solution.
Edit: Forum's table tool is a tad finicky.
Post by: mifki on October 02, 2014, 03:45:08 am
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.
Post by: Quietust on October 02, 2014, 09:23:04 am
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.
Post by: muppet9876 on October 02, 2014, 10:16:58 am
Spoiler: Example of world map font (click to show/hide)
Tileset (http://dffd.wimbli.com/file.php?id=9842) and batch file for easier usage (TODAY!) with the Windows Starter Pack.
P.S. Before anyone mentions it, I really should have done the legend while I was doing it. Just can't summon the patience up to make one ... yet. The wiki (http://dwarffortresswiki.org/index.php/DF2014:Map_legend) will tell you what the colours mean. Maybe they're pictorial enough to make sense to you. :D
Post by: LeoCean on October 02, 2014, 01:50:33 pm
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.
There's a 16x16 cursefont are you saying the only font you can use is that 128x192 or the 160x192? The default installation comes with the 256x256 curse font set that is the same size as regular tile sets. Is the map tileset override even ready to be tested on 5.19?
@muppet I could live with the text before I could live with that map font you just shown, personal taste and all.
Post by: Max™ on October 03, 2014, 08:51:37 am
I ended up hacking together the most unruly mishmash of parts, as twbt by itself didn't want to work right, and then I had a fluke where spacefox worked right and it even let me use the bisasam derived fonts I prefer, but when I tried to reload it just kept spitting out the uh, LD_PRELOAD env stuff.
On a hunch I tried to use the LNP and it worked fine, but getting it to use twbt as I desired was a pain.
I finally ended up switching pieces over step by step until I found that one of the init.txt's in the spacefox set wasn't changed right, so I just removed that entirely and left the spacefox dwarves in, loaded up dfhack with the ./dfhack instead of using the .startlnp script, and bladow!
Spoiler (click to show/hide)
Now I get to share the adorable spacefox dorfs with the gf while telling her what awful horrible things have been happening to them due to my actions, hurray!
Oooh, I bet that multilevel thing will work too, hadn't even checked because the first map I loaded was that extreme cliff/river embark someone was looking for from the cookbook thread a couple pages back. Hard to see if multilevel works when the difference from the embark level to the bottom of the cliff is like 26 z straight down. :D
Anyways, love you folks, I'mma go grin as my cute little military dorfs hack up ...oooh, I bet the goblin overrides worked too!
Post by: LeoCean on October 03, 2014, 01:36:14 pm
As for the init if it wasn't loading twbt it's because the print mode wasn't set to :TWBT or TWBT_LEGACY. Unless it's a version before 40.13r3 then it needed :STANDARD.
Post by: Max™ on October 03, 2014, 10:54:17 pm
I decided to see if I could get the lazy newb pack working since I saw it said that it was working well on linux with some of the new versions, 5.19 and such, and I got it working with spacefox which was nice, but I'm not used to looking at the phoebus tiles so that was more of a tease than anything else.
I tried to just use the Bisasam tilesets while launching with the startlnp and was pleasantly surprised to see it not only did the awesome twbt thing, but it also kept the spacefox dwarf overrides. It got buggy though so I tried just pulling the df_linux folder out of the lnp as it was and callooh callay, I chortled in my joy, finally able to partake in the wonderful twbt experience!
You are right that the spacefox dwarf tiles zoom fine, it was just a habit from trying to get one tileset for everything to try and get it looking good zoomed or out.
Post by: mifki on October 07, 2014, 04:29:18 am
Post by: Rydel on October 07, 2014, 05:46:03 pm
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.
Post by: deepholedwarf on October 07, 2014, 06:21:45 pm
Failing that, do I need the dfhack source to compile twbt? Just running make on what I got from https://github.com/mifki/df-twbt/archive/master.zip gives this:
Code: [Select]
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
Post by: LeoCean on October 07, 2014, 06:52:33 pm
Post by: mifki on October 07, 2014, 06:56:33 pm
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.
Yes, you need dfhack to compile it.
What distro/version do you have?
I think I can include a binary built with 4.5.4 in my packages as well, I'll try it soon.
Post by: lethosor on October 07, 2014, 06:58:44 pm
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.
Post by: mifki on October 07, 2014, 07:08:32 pm
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.
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.
Post by: mifki on October 07, 2014, 07:21:15 pm
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.
On Ubuntu it's easy to fix
Code: [Select]
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install g++-4.9
Post by: Rydel on October 07, 2014, 08:21:44 pm
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.
It looks like all plant growths use use Id: PLANT, Type: PLANT_GROWTH, sUBTYPE: NONE, and then use the materiel to determine but the plant it is from and the type of growth.
For instance:
Purple Amaranth Leaves are Type: PLANT_GROWTH, Subtype: NONE, Material: PLANT:PURPLE_AMARANTH:LEAF
'Quarry Bush Leaves are Type: PLANT_GROWTH, Subtype: NONE, Material: PLANT:BUSH_QUARRY:LEAF
Blueberries are Type: PLANT_GROWTH, Subtype: NONE, Material: PLANT:BLUEBERRY:FRUIT
I assume the ID is PLANT, but dfhack's changeitem info doesn't list that part.
So, it looks like you'd need the ability to specify the material in order to change the graphics for Fruits, Pods, Leaves, etc.
Post by: LeoCean on October 07, 2014, 10:05:54 pm
# BRANCHES AND LEAVES
[OVERRIDE:172:T:TreeBranches:TILESET:24]
# TWIGS
[OVERRIDE:59:T:TreeTwigs:TILESET:29]
Figure out what that means based on the readme.
Seem to be the leaves you want based on this post http://www.bay12forums.com/smf/index.php?topic=144270.msg5708909#msg5708909, they are still changeable in the d_init.txt file anyways.
Quote
So, it looks like you'd need the ability to specify the material in order to change the graphics for Fruits, Pods, Leaves, etc.
These are in the raw\object raws, you can change them there to be what ever you want them to be. It hardly matters as of yet because they are just flavor till Toady actually makes the pods and fruits useable, unless a mod does that.
I'd assume if you want to change all the plants you'd just have to give them all different id's in the raws because as it stands if you do the plant_growth change any plant with that id that uses that id should change to be what ever you told it to change to if you did it correctly. But plants can have more than one Id based on their growth cycle.
You will also want to use the tile overrides not items as items are things that aren't "planted" on the ground but laying above it. Sort of like how buildings (chairs) are items when they haven't been planted. But plants would be tiles. 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.
Post by: Rydel on October 07, 2014, 11:09:52 pm
Quote
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.
Post by: Vanst7 on October 08, 2014, 03:57:50 am
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.
Post by: mifki on October 08, 2014, 04:42:54 am
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.
I answered just recently - the thing is that I'm a developer, not a modder. I added overrides by building/item/tile types - these were most obvious and easiest. 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).
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.
No, the original idea was to allow more tile images to solve the problem we all know - with single tile used for multiple things. But tile colour is determined by its material, why would you want to change the colour?
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.
Thanks.
But I din't understand the last question, can you post a screenshot showing the problem?
Post by: Vanst7 on October 08, 2014, 05:10:47 am
But I din't understand the last question, can you post a screenshot showing the problem?
Sorry, i'll try to be clearer.
I currently use those tileset. 2 of different size.
[FONT:curses_640x300.png]
[GRAPHICS_FONT:Bisasam_24x24.png]
But in-game the font looks like this:
Spoiler (click to show/hide)
I'm kinda sure in some version they were keeping their original size unless i was dreaming of this ^^.
I hope my explanation is better now.
Post by: scamtank on October 08, 2014, 05:11:45 am
Post by: Vanst7 on October 08, 2014, 05:14:45 am
Are you using the legacy rendering?
I guess so, i currently use, [PRINT_MODE:TWBT_LEGACY].
Post by: mifki on October 08, 2014, 05:26:50 am
Are you using the legacy rendering?
I guess so, i currently use, [PRINT_MODE:TWBT_LEGACY].
Yep, that's it, change to TWBT.
Post by: Vanst7 on October 08, 2014, 05:33:17 am
Yep, that's it, change to TWBT.
Actually, i did try TWBT too, it gives me the same result.
It was working before, when we had to put standard. Unless since that change, we have to configure the init in an other way?
Right now my init looks like that.
[WINDOWEDX:80]
[WINDOWEDY:25]
[FONT:curses_640x300.png]
[FULLSCREENX:0]
[FULLSCREENY:0]
[FULLFONT:curses_640x300.png]
[GRAPHICS:YES]
[GRAPHICS_WINDOWEDX:0]
[GRAPHICS_WINDOWEDY:0]
[GRAPHICS_FONT:Bisasam_24x24.png]
[GRAPHICS_FULLSCREENX:0]
[GRAPHICS_FULLSCREENY:0]
[GRAPHICS_FULLFONT:Bisasam_24x24.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]
Thanks for the help.
Post by: mifki on October 08, 2014, 05:37:59 am
Post by: Vanst7 on October 08, 2014, 05:44:04 am
Change these to zeroes WINDOWEDX WINDOWEDY.
Still the same. =/
If it can help, i'm currently using twbt-5.23 with DFHack 0.40.13-r1.
Post by: mifki on October 08, 2014, 05:48:47 am
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..
Post by: scamtank on October 08, 2014, 05:49:40 am
Post by: Vanst7 on October 08, 2014, 05:51:54 am
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..
Oh my god, i'm a dumbass. I'm really sorry about this. You're totally right. Somehow i chnaged that font but kept the same name. I'm really sorry about this. =X
Post by: Rydel on October 08, 2014, 08:02:27 am
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).
It looks like they're in the MaterialInfo struct, defined in Materials.h. MaterialInfo.getToken() returns the material as a string and MaterialInfo.matches(MaterialInfo) will compare two materials.
I'm not sure what all you need from it. Is there any specific functions you need?
EDIT: Fixed Quote tags
Post by: Deon on October 08, 2014, 12:46:38 pm
P.S. And a more important question if you might:
[TILESET:terrain.png:terrain.png:terrain] - this is supposed to load a terrain tile graphic set
[OVERRIDE:Tile:T:Dense grass:terrain:1] - this is supposed to override the grass tile with appropriate one
However it does not work. I also tried "stone stair down" as mentioned on the main page but it does not work either. What am I doing wrong?
P.S.
This is my latest attempt to replace ANY of the terrain tiles with the dwarf icon from square font:
[TILESET:curses_square_16x16.png:curses_square_16x16.png:3]
[OVERRIDE:Tile:T:"Dense grass":3:1]
[OVERRIDE:Tile:T:"dense grass":3:1]
[OVERRIDE:Tile:T:Dense grass:3:1]
[OVERRIDE:Tile:T:dense grass:3:1]
[OVERRIDE:Tile:T:grass:3:1]
[OVERRIDE:Tile:T:stone stair down:3:1]
[OVERRIDE:Tile:T:"stone stair down":3:1]
None of that seems to work though. Could you help please?
P.P.S. [OVERRIDE:Tile:T:GrassLightFloor1:1:1] does not work either. I tried different GrassLightFloor1/2/3/4
Post by: scamtank on October 08, 2014, 01:40:44 pm
Try [OVERRIDE:63:T:"stone stair down":3:1] instead.
Post by: Deon on October 08, 2014, 01:45:28 pm
Post by: Deon on October 08, 2014, 01:55:37 pm
Also it's not changing stone stairs to anything. I also tried [OVERRIDE:62:T:SoilStairD:1:3] for soil stairs, but it did not work.
To be sure, I've tested, and item overrides work properly. It's just that terrain that does not listen to me :'(.
Post by: scamtank on October 08, 2014, 02:04:25 pm
I don't know what else to tell you. For my own testing, [OVERRIDE:186:T:ConstructedWallUD:phoebus:186] worked just fine in overriding all the north-south brick walls. Maybe the single-digit tileset names are throwing the parser off?
Post by: Deon on October 08, 2014, 02:13:11 pm
Code: [Select]
[TILESET:fallout.png:fallout.png:phoebus]
[OVERRIDE:186:T:ConstructedWallUD:phoebus:186]
And this is how it looks in the game:
(http://i.imgur.com/kWpPDrA.png)
And the files are present:
(http://i.imgur.com/SWpAMms.png)
The item overrides definitely work (tested with MDF item tilesets).
Do you have any idea what else could be wrong? I am in despair :).
P.S. Can it be something with the PRINT_MODE? Mine is [PRINT_MODE:STANDARD]. Anything else to check?
Post by: LeoCean on October 08, 2014, 02:25:33 pm
Spoiler: Stair Overrides (click to show/hide)
You'd just use the U or the D for up and down instead of UD, someone else wrote that though.
39, 44, 46, 96 are the "rough floors" Idk what they'd be called though. Rough floors, unexplored underground*, various stones*, various grasses* is pretty much what all of those say.
I guess I really should care more what they do since I could change the raw stone floors to look more stoneish than grass lol. The being unable to make/get a frigging vampire has made me not play much dwarf fortress though.
Spoiler: Probably useful if you want to override the grass (click to show/hide)
Print_mode:STANDARD shouldn't allow mephs item overrides to work at least anymore. What version of twbt are you using is it before the 5.xx series? That'd be the only one it would work. **It should be working though if it isn't though.
Post by: Deon on October 08, 2014, 02:46:36 pm
Stairs don't work:
[TILESET:fallout.png:fallout.png:3]
[OVERRIDE:88:T:ConstructedStairUD:3:88]
[OVERRIDE:88:T:FeatureStairUD:3:88]
[OVERRIDE:88:T:FrozenStairUD:3:88]
[OVERRIDE:88:T:Grass1StairUD:3:88]
[OVERRIDE:88:T:Grass2StairUD:3:88]
[OVERRIDE:88:T:LavaStairUD:3:88]
[OVERRIDE:88:T:MineralStairUD:3:88]
[OVERRIDE:88:T:SoilStairUD:3:88]
[OVERRIDE:88:T:StoneStairUD:3:88]
[OVERRIDE:88:T:UnderworldGateStairUD:3:88]
(http://i.imgur.com/hw0SWwR.png)
Aaaand I use the top one compatible with 40.13. Which is v3.43
https://github.com/mifki/df-twbt/releases
Now that I see you mentoning 5.xx, I guess 3.43 is terribly outdated and does not have terrain tile support? So I am a big ol dufus? Which version should I use for 0.40.13 then? Enlighten me please :).
Post by: scamtank on October 08, 2014, 02:48:50 pm
Post by: LeoCean on October 08, 2014, 02:49:05 pm
Post by: Deon on October 08, 2014, 02:51:53 pm
P.S. Check this out, it looks right:
http://prntscr.com/4uaupf
I feel like it's the .dll version, or I may be missing something. Do I need to put the .h files which come anywhere? I thought they are just for listing.
P.S. I've put them in the init folder, but it does not help.
Post by: LeoCean on October 08, 2014, 02:54:40 pm
Mifki's development builds (http://do1.mifki.com:8810/dashboard)
Post by: Deon on October 08, 2014, 02:58:21 pm
Sorry for being a dummy, I just can't find a clear instruction or explanation (yet). :)
Post by: LeoCean on October 08, 2014, 03:00:22 pm
Post by: Deon on October 08, 2014, 03:02:45 pm
P.S. Got 5.23, set the mode to TWBT_LEGACY, but I get this:
Multilevel command is not supported.
(http://i.imgur.com/NdwCl2Y.png)
Is it not in for the build?
NOOOO!
It worked. I've changed the wrong init.txt :(. It can happen when you have a lot of DF modding folders opened.
Thank you so much!
Post by: LeoCean on October 08, 2014, 03:07:54 pm
Post by: Deon on October 08, 2014, 03:16:27 pm
Thanks a lot! :)
P.S. Absolutely amazing, just what I wanted.
(http://i.imgur.com/KAHo9ai.png)
Could you tell me if there is a possible way to discard the foreground color enforced by the game?
Post by: LeoCean on October 08, 2014, 03:53:43 pm
Post by: mifki on October 08, 2014, 03:55:15 pm
Could you tell me if there is a possible way to discard the foreground color enforced by the game?
What do you mean, discard?
Post by: Deon on October 08, 2014, 03:59:59 pm
Post by: UristWoodie on October 08, 2014, 04:02:39 pm
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.
Post by: Dirst on October 08, 2014, 04:09:26 pm
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.
Post by: mifki on October 08, 2014, 04:37:48 pm
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)?
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.
Something like INCLUDE statements?
It's planned https://github.com/mifki/df-twbt/issues/5
Post by: Deon on October 08, 2014, 04:49:58 pm
Quote
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 :).
Post by: LeoCean on October 08, 2014, 05:00:42 pm
Post by: mifki on October 08, 2014, 05:15:41 pm
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 :).
Technically it's not a problem to replace colour as well. I'm still not sure it's good to allow to change tile colour freely. I'll think about this, maybe some possible use cases will convince me)
Post by: Meph on October 08, 2014, 05:33:23 pm
Example:
Spoiler: Deons fallout mod (click to show/hide)
Another example: All constructed walls are of one color. Make that an option, and people will no longer go crazy of that microcline-orthoclase-obsidian-marble wall, but make their buildings and can toggle them to either show the original color, or a pre-set color for all walls, for a uniform look.
Post by: Deon on October 08, 2014, 05:39:09 pm
Post by: mifki on October 08, 2014, 05:48:28 pm
But ok, since I think it's quite easy to do, I'll add it to my todo list with an option to turn colour overrides on and off in runtime.
Post by: Meph on October 08, 2014, 05:50:12 pm
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.
Post by: mifki on October 08, 2014, 05:57:39 pm
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.
And now that's convincing enough. Let's say weapons can be painted so it doesn't matter what material they're made of:)
Post by: LeoCean on October 09, 2014, 12:19:23 am
Post by: mifki on October 09, 2014, 01:31:59 am
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.
Don't bars currently have colours based on their material?
Anyway, we were talking about overriding tile colour with a specific different colour, not about overrides based on tile material (what you want as I understand).
Post by: scamtank on October 09, 2014, 02:41:51 am
Post by: mifki on October 09, 2014, 05:33:07 am
Post by: Vanst7 on October 09, 2014, 06:38:02 am
Post by: HaterSkater on October 09, 2014, 07:53:23 am
Version 5.24 has support for overriding tile colours. Please see readme for details.Interesting
UPD:
Quote
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
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?
Post by: mifki on October 09, 2014, 08:21:10 am
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?
Sure a typo, thanks.
Of course you can omit trailing colons, so all existing overrides continue to work. I'll clarify this in readme.
Post by: Vanst7 on October 09, 2014, 09:11:14 am
Post by: mifki on October 09, 2014, 09:49:30 am
I'll better go get some sleep
Post by: UristWoodie on October 09, 2014, 12:50:13 pm
Post by: Max™ on October 10, 2014, 05:26:23 am
Spoiler (click to show/hide)
Spoiler (click to show/hide)
Post by: LeoCean on October 13, 2014, 08:20:45 am
Post by: Deon on October 13, 2014, 05:51:33 pm
A quick mock-up:
(http://i.imgur.com/VaDvNU8.png)
Post by: Meph on October 13, 2014, 10:20:39 pm
Post by: mifki on October 13, 2014, 10:48:43 pm
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)
Great idea!
Post by: Deon on October 14, 2014, 12:04:00 am
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.
The procedurally generated history has the "main" image based on the main object which works the same way.
Post by: HaterSkater on October 14, 2014, 01:26:42 am
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
Post by: mifki on October 14, 2014, 01:52:11 am
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?
Post by: int_ua on October 14, 2014, 03:25:32 am
(http://i.imgur.com/VaDvNU8.png)For a moment I thought that it's showing containers with contents. Nevermind.
Post by: HaterSkater on October 14, 2014, 06:29:15 am
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?
pic shows smooth stone floor area with dwarves standing on it, while overrides contains this line
Code: [Select]
[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.For example, i want to see image of heart instead of an image of dwarf on a floor. I'm coding new override as stated above and getting this:
(http://i62.tinypic.com/ae9qpu.png)
my engraving now shows hearts, but dwarves became hearts too, although they have graphic sprites
Post by: mifki on October 14, 2014, 07:16:47 am
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.
Post by: CLA on October 14, 2014, 09:54:52 am
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).
So, you would have an override for a bag, and a table, and a sword, and they're pointing to a tileset called TWBTitems.png and TWBTweapons.png. That's for normal display in game.
Then you add only one line, something like [OVERRIDE:ENGRAVING:*_engraving] and when engravings are visible, TWBT will search for TWBTitems_engraving.png and TWBTweapons_engraving.png, and use those tilesets for overrides of engravings, displaying a bag, a table and a sword.
If engravings are set to invisible, it will just use the overrides for engraved walls and floors.
Post by: Deon on October 14, 2014, 02:10:09 pm
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.
Post by: Guolin on October 14, 2014, 05:36:10 pm
However, when I turn the graphics on, some disgusting sprites for my dwarves and animals replace the default tileset:
(http://i.imgur.com/XjWN8Td.png)
Can anyone help me figure out how to make it so that I can have a different tileset for my map while not having graphical sprites replace my tiles? I installed LNP from scratch only a couple of days ago, and here are my init.txt settings:
Spoiler (click to show/hide)
For the lazy, here are just the relevant tilesets options:
Spoiler (click to show/hide)
Post by: Rydel on October 14, 2014, 05:40:23 pm
You may need to regen the world for it to take effect, though.
Post by: salithus on October 14, 2014, 05:41:48 pm
Post by: Deon on October 14, 2014, 05:50:43 pm
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.
Post by: mifki on October 14, 2014, 05:54:47 pm
Post by: HaterSkater on October 14, 2014, 06:01:07 pm
@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
Spoiler (click to show/hide)
Post by: mifki on October 14, 2014, 06:08:37 pm
@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.
Post by: HaterSkater on October 14, 2014, 06:14:10 pm
Post by: Guolin on October 14, 2014, 06:15:22 pm
Post by: mifki on October 14, 2014, 06:23:43 pm
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
Previously I was checking for GRAPHICS setting and refused to start twbt if it's set to NO, but then I thought why? and now I just need to fix one thing in tileset loading. Actually this setting doesn't disable anything inside DF except creature graphics so it doesn't break anything when set to NO.
Post by: muppet9876 on October 14, 2014, 06:28:24 pm
Win7 64bit, DFSP 40-11r3 TWBT set. 5.25
http://dffd.wimbli.com/file.php?id=9920
Post by: mifki on October 14, 2014, 07:40:09 pm
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
This doesn't seem to be twbt-related, it crashed somewhere in network code called from Ruby thread.
Post by: Rydel on October 14, 2014, 08:20:22 pm
@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.
Creature graphics are the only thing stored in raw/graphics, and they are self contained, so removing them doesn't affect anything else. If you don't want creature graphics, deleting the contents of that folder would be the way to get rid of them.
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.
Post by: mifki on October 14, 2014, 09:00:57 pm
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.
Post by: Guolin on October 14, 2014, 09:15:10 pm
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.
Post by: mifki on October 14, 2014, 09:35:17 pm
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.
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.
Post by: Guolin on October 14, 2014, 10:10:44 pm
If I knew how to compile DFHack plugins I'd even change the source myself.
Post by: Dirst on October 14, 2014, 10:18:11 pm
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.
Post by: Guolin on October 14, 2014, 10:36:06 pm
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.
Whoa, that worked perfectly. Thanks to all of you for replying, and good luck with this amazing plugin, mifki!
Post by: Deon on October 15, 2014, 12:01:05 am
@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.
Post by: Vanst7 on October 15, 2014, 02:00:12 am
Post by: mifki on October 15, 2014, 02:40:15 am
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 idea was to make engravings not to replace tiles but to draw them "inside" tiles, as in Deon's mockup.
Post by: fricy on October 15, 2014, 03:57:38 am
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.
Post by: mifki on October 15, 2014, 05:25:08 am
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.
Honestly, I don't understand the problems you people are talking about. So, here are possible cases and what I was thinking twbt would do in them:
graphics:no - twbt disabled
game is using font for everything, no creature graphics
/vanilla/
graphics:no - twbt enabled - font and graphics_font are the same
game is using font for everything, twbt provides overrides and multilevel (if enabled), no creature graphics
/vanilla + twbt goodies/
graphics:no - twbt enabled - font and graphics_font are different
font is used for text, graphics_font for map, no creature graphics + overrides and multilevel
/for those who want plain ascii but bigger or square font for map and smaller for menus/
graphics:yes - twbt disabled
game is using graphics_font for everything + creature graphics
graphics:yes - twbt enabled - font and graphics_font are the same
game is using graphics_font for everything, twbt provides overrides and multilevel (if enabled)
/probably most useless case/
graphics:yes - twbt enabled - font and graphics_font are different
font is used for text, graphics_font for map + creature graphics + overrides and multilevel
Which of these cases are causing problems?
Post by: fricy on October 15, 2014, 06:10:13 am
graphics:yes - twbt enabled - font and graphics_font are different
font is used for text, graphics_font for map, (optional creature graphics + overrides and multilevel)
/for those who want plain ascii but bigger or square font for map and smaller for menus/
graphics:yes - twbt disabled - font and graphics_font are different
game is using graphics_font for everything, (optional creature graphics)
/vanilla
With graphics set to yes I can provide a single config that always load the tiles set in graphics_font, but with twbt uses a secondary font for text.
If graphics mode is set to NO, in vanilla mode this will render everything with the "secondary" font instead of graphics_font, so clean fallback is not possible. Can be mitigated with a launcher option, but it adds confusion.
graphics:no - twbt disabled - font and graphics_font are different
game is using font for everything, no creature graphics
/vanilla/
Post by: mifki on October 15, 2014, 06:24:30 am
Post by: MichaelB on October 18, 2014, 05:54:27 pm
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.
Post by: mifki on October 19, 2014, 12:45:56 am
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.
Sure, if you provide savegame it would be much easier for me to reproduce and fix, thanks.
Post by: MichaelB on October 20, 2014, 04:29:59 am
http://dffd.wimbli.com/file.php?id=9956 (http://dffd.wimbli.com/file.php?id=9956)
Post by: mifki on October 21, 2014, 03:28:33 am
Post by: MichaelB on October 22, 2014, 04:27:12 am
Post by: palu on October 22, 2014, 09:38:22 pm
Post by: mifki on October 23, 2014, 06:23:18 am
Working on a very cool new thing, hope will be able to tell more soon.
Post by: Clément on October 23, 2014, 09:16:22 am
In the TWBT code, I found:
Code: [Select]
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: 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?
Post by: palu on October 23, 2014, 12:19:43 pm
Post by: mifki on October 23, 2014, 03:53:40 pm
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?
No it's not the same at least because when parsing init.txt DF just grabs any token starting on 2nd position not even checking for opening '['. For raws it's different. So I did it as I think it makes most sense - to allow to indent with spaces but everything not starting with whitespace or '[' is a comment (as well as everything after ']').
Post by: mifki on October 23, 2014, 04:48:49 pm
How about the transparent tiles?
On hold for now. It's more interesting for me than isometric view, but it requires much more hacking into DF (unless I find another way to do it) that there's no point to do this when DF versions are released often (nobody knew about this long delay after 0.40.13). We'll see what happens after 0.40.14.
Post by: Rydel on October 25, 2014, 05:06:19 pm
Post by: LeoCean on October 25, 2014, 06:05:40 pm
Post by: Dragoon209 on October 26, 2014, 11:36:45 am
I have a freeze bug that occurs after playing 20-30 minutes. I haven't found a trend yet, aside from the time. So far no matter what I am doing in game, even paused, it will just lock, and state Dwarf Fortress.exe is not responding. It only happens on one of the computers I play on, so it doesn't seem save specific.
Since this problem only occurs on one computer, I'm worried that providing a save is not going to be sufficient to solve the issue. Is there a debugging flag I could turn on to try and collect logs for it?
I'm using Starter Pack 40.13 r5, and I have already updated TWBT to 5.27 in an attempt to solve the issue.
I confirmed that it was TWBT causing the issue but changing the print mode to STANDARD, and playing for a few hours. During that time I had no issues. I changed the mode back to TWBT, and the crash came back.
Thank you for any help in advance! I will be happy to provide a save later today.
Edit: Save located at: http://dffd.wimbli.com/file.php?id=9979 (http://dffd.wimbli.com/file.php?id=9979)
Edit Edit: I have solved the problem. It seems that it was being caused by old AMD Graphics Drivers. Upgrading from 13.1 to 14.1 Seems to have corrected the issue. I was able to play for an hour and a half without issue.
Post by: Vanst7 on October 28, 2014, 12:55:12 pm
Post by: mifki on October 28, 2014, 04:07:04 pm
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.
Post by: Vanst7 on October 28, 2014, 05:48:06 pm
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.
Post by: mifki on October 28, 2014, 06:04:05 pm
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?
Post by: HaterSkater on October 28, 2014, 06:54:02 pm
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?
(http://lifeofbun.files.wordpress.com/2012/10/weird.png)
I think it shouldn't, but i'm gonna check it right now
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?
Post by: mifki on October 28, 2014, 07:50:34 pm
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?
Yep, that's how OpenGL works:)
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?
Post by: HaterSkater on October 28, 2014, 08:30:21 pm
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.
Post by: Vanst7 on October 28, 2014, 09:06:42 pm
Doesn't it produce the result you want if you set the color to white (16:16) for an override?
Ya, tiles keep their color like that but they are lighter then the tiles, one i tried the red became a lil bit pinkier, but making the tiles color darker kinda fixed that.
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.
That would be interesting, i could see myself using that for the leaves. In winter for when the leaves falls, i get brown leaves in the trees. With that i could make a tile that would look like branch instead.
Post by: Rydel on October 28, 2014, 09:09:23 pm
Post by: DWARFFRAWD on October 30, 2014, 02:54:29 am
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??
Post by: mifki on October 30, 2014, 03:17:54 am
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??
Are there any messages in dfhack console in red or yellow when you launch DF?
Can you also post a screenshot?
Post by: mifki on October 30, 2014, 03:26:59 am
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.
I now think I probably can support overrides by material for buildings and items relatively easily. But will this require listing all possible woods/stones/etc. separately in overrides configuration, or there's a better way? I'm not an expert in how materials work in df.
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.
Post by: Putnam on October 30, 2014, 03:29:12 am
Post by: Vanst7 on October 30, 2014, 03:54:17 am
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?
Post by: mifki on October 30, 2014, 04:05:03 am
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?
Well, it will just have to compare tile properties with each override, so yes, the more the slower (while overrides for different tiles are accessed by index so less overrides for more tiles don't slow things down). If you can send me your overrides configuration (even unfinished), I probably can think of some optimisations for real-life use case.
Post by: Vanst7 on October 30, 2014, 04:13:05 am
http://www.mediafire.com/view/6vms9y738eknt2y/overrides.txt
Post by: mifki on October 30, 2014, 04:23:32 am
Btw, you don't have to use numbers for tileset IDs, they can be any descriptive strings.
Post by: Vanst7 on October 30, 2014, 04:35:55 am
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.
Post by: DWARFFRAWD on October 30, 2014, 05:20:59 am
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??
DFHack is not problem. work well.
any red messages, yellow messages not appeared.
Post by: PeridexisErrant on October 30, 2014, 05:29:52 am
Post by: HaterSkater on October 30, 2014, 10:27:57 am
UPD: same with pressure plates, they are ^
Post by: Rydel on October 30, 2014, 10:46:39 am
<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.
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.
Post by: whitecold on October 30, 2014, 03:07:37 pm
I'd like to add another tileset for rollers and change the way axles and gears look.
Post by: HaterSkater on October 30, 2014, 03:22:35 pm
Can machinery tiles be overwritten?
I'd like to add another tileset for rollers and change the way axles and gears look.
There is IDs for axles and, i presume, other machinery, so it seems possible
Post by: mifki on October 30, 2014, 03:49:06 pm
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.
Yes, it's going to be something like this.
Post by: Max™ on October 30, 2014, 07:55:00 pm
Probably a reason this is dumb that I'm missing.
Post by: LeoCean on October 30, 2014, 09:09:52 pm
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.
I did it that way because that's how Meph did it and everyone else at the time did it, it was peer pressure :'(.... Either way is fine, I understand the merits of words instead of numbers, but will probably stick with the numbers.
As long as the material overrides don't cause to much fps loss it shouldn't be a problem and if it ends up in the end causing problems then it shouldn't be to hard to disable it. Someday Toady may get to 64 bit dwarf fortress so having it there would be nice and I just selfishly want to color all the bars different colors (or different shapes) so you can tell at a glance what they are. I imagine it's actually somewhat possible already with "tile magic" but that's......
Post by: Spacebat on November 04, 2014, 02:55:52 pm
Post by: mifki on November 04, 2014, 06:59:19 pm
Post by: PeridexisErrant on November 05, 2014, 10:32:09 pm
Post by: mifki on November 05, 2014, 11:01:43 pm
Post by: mifki on November 06, 2014, 06:40:32 am
Post by: kittyfluffins on November 06, 2014, 05:37:37 pm
Can you also briefly mention that you can remove graphics by deleting the files in raw/graphics and data/save/region1/raw/graphics?
I struggled for a good hour trying to figure this out (new to dfhack and modding). I just wanted a square ascii tileset with non-square text for readability ;-;
Sample:
In your init.txt set FONT and FULLFONT to the font you want to use for text, and GRAPHICS_FONT and GRAPHICS_FULLFONT to the font for map tiles, and GRAPHICS to YES (if you don't want graphics, remove the files in raw/graphics and data/save/region1/raw/graphics).
Also, amazing work. Thank you.
Post by: Max™ on November 07, 2014, 12:38:02 am
Post by: mifki on November 09, 2014, 05:04:32 am
Post by: Bloax on November 09, 2014, 11:18:54 am
Edit: As does fortress mode.
EditEdit: This is the Windows version, and people seem to notice it elsewhere too (http://www.bay12forums.com/smf/index.php?topic=126076.msg5794739#msg5794739).
Post by: mifki on November 09, 2014, 06:29:33 pm
Post by: Sergarr on November 09, 2014, 06:59:39 pm
Post by: Bloax on November 09, 2014, 08:40:16 pm
Post by: Max™ on November 09, 2014, 09:24:15 pm
Post by: 0ink3r on November 10, 2014, 03:22:25 am
Post by: Bloax on November 10, 2014, 03:45:31 am
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.. !!!
Post by: Max™ on November 10, 2014, 03:48:21 am
Post by: LeoCean on November 10, 2014, 03:19:15 pm
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.
Post by: Salmeuk on November 11, 2014, 03:15:19 am
Post by: Col_Jessep on November 11, 2014, 04:02:30 am
I tried to zoom in but that no longer changes text size. Googling brought up Shift+O/P. That didn't work either so I searched again and found:
Code: [Select]
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.1) What do I have to do to change the font size during the game?
When I zoom in in the mainmenu the font size sticks and the text is at least larger. It looks very fuzzy though:
Spoiler (click to show/hide)
2) Is there a way to change the font? 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'm using: Starter Pack 14.15r2 with PeridexisErrant keybinds and the Phoebus tileset.
I love TWBT, mifki. Multilevel is awesome, the fixes are very helpful but I'm in that age where the hair go gray and the eyes apply their own "soft" filter. I'm afraid an additional layer of text smoothing is a bit too much. ___,,,^..^,,,~___
Please help. Thanks in advance!
Post by: LeoCean on November 11, 2014, 04:30:34 am
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.
Post by: Bloax on November 11, 2014, 04:42:12 am
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.
Post by: Bloax on November 11, 2014, 04:46:18 am
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.
Simple Mood (http://www.bay12forums.com/smf/index.php?topic=144897.0) with its big, fat letters might be?
Post by: Col_Jessep on November 11, 2014, 05:02:28 am
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.
Monty Python maybe: https://www.youtube.com/watch?v=7lbX7VxlrJQ :D
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?
Post by: mifki on November 11, 2014, 05:08:34 am
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.
It's planned for adventure mode, I tried to implement it once but there were some difficulties, I don't remember, I need to try again.
Post by: Max™ on November 11, 2014, 11:55:37 am
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)
That looks A LOT like the bisasam set text to me, which I would recommend checking out, there are 16x, 20x, and 24x versions on the tileset repository as I recall.
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.
Spoiler (click to show/hide)
Spoiler (click to show/hide)
Seriously mifki, spore with me.
Post by: Col_Jessep on November 11, 2014, 01:33:07 pm
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.
The font I was looking for turned out to be the standard Phoebus font. Your tileset font looks almost identical. Can I mix 24x24 font with the normal Phoebus 16x16 tileset? Your font looks perfect!
Post by: Max™ on November 11, 2014, 02:26:06 pm
Here ya go: http://dffd.wimbli.com/file.php?id=10056
Should be a graphics folder with the 24x24 parts, can just remove the spacefox dorfs or swap in your own overrides of course, as well as the original bisasam and phsspthok parts I used plus my mixed version.
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?)
Post by: dennislp3 on November 11, 2014, 04:51:49 pm
Post by: Col_Jessep on November 11, 2014, 04:59:35 pm
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
Thanks so much for your help!
Now there is only to hope the next update doesn't shred it all again. Between my custom keybinds, embark profiles, RAW adjustments and now tileset fixes I'll be spending some time modding the mod to the mod of the mod... Modception! xD
Post by: Dirst on November 11, 2014, 05:02:47 pm
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
Post by: Col_Jessep on November 12, 2014, 06:29:07 am
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
Btw, that is one awesome idea! <3
Post by: PeridexisErrant on November 20, 2014, 12:26:17 am
Post by: mifki on November 20, 2014, 03:16:03 am
Post by: fricy on November 20, 2014, 03:28:31 am
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.
Post by: mifki on November 20, 2014, 03:35:51 am
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.
Yes, I need couple addresses from there.
Post by: mifki on November 20, 2014, 05:34:10 am
Post by: fricy on November 20, 2014, 07:24:27 am
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?
Post by: mifki on November 20, 2014, 07:37:18 am
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?
No. It's "lazy developer mode" activated - theoretically less optimised but you won't notice. I'm busy working on another amazing project that I'm hoping to show soon.
Post by: fricy on November 20, 2014, 07:45:27 am
:-*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?
Post by: scamtank on November 20, 2014, 08:58:21 pm
My money is on a combat AI hijacker and customizer now.
Post by: HaterSkater on November 24, 2014, 08:15:36 pm
(http://i61.tinypic.com/jv21s1.png)
This is copper door. It's made out of brown foreground and red background, well blended with tile magic.
So, what i'm asking is some king of tag (or maybe not tag), called like [FORCE_BACKGROUND] that will force game object to use background of its material taken from raws instead of black. I was thinking of altering metal colours for my tileset, to make them more like in real life. And such a tag may be really helpful to apply that smooth 2-colored gradient to weapons and other furniture, except just doors and barrels, thus making them more randomised. Is it possible, or maybe you are up to implement it in your material-based-overrides concept, you were talking about?
Post by: mifki on November 24, 2014, 08:48:32 pm
Post by: Dirst on November 26, 2014, 12:36:42 pm
Post by: mifki on November 26, 2014, 04:47:42 pm
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.
Post by: Rogue Yun on November 26, 2014, 11:50:39 pm
Could one by chance do a 16x16 pxl or 32x32 pxl all white image and use 1x1 pxl or 2x2 pxl tiles to generate the desired mini map? It might not be doable with the twbt plugin but perhaps there could be another plugin to do it.
I just made 32x32 tileset and ran it in dwarf fortress. This was the first screen when I started it :D It made me laugh out loud.
(http://s27.postimg.org/x6x4vgpnz/funny.png)
And here is what my current 2x2 embark fort looked like :P
(http://s11.postimg.org/gpbsnvwmp/test.png)
I would think something like this running real-time within dwarf fortress would be quite a strain on the cpu. Though it is kind of fun to watch 2x2 colored pixels moving around :D
Post by: Clément on November 27, 2014, 09:11:31 am
Post by: mifki on November 28, 2014, 05:03:33 am
Post by: mifki on December 04, 2014, 05:26:09 am
https://github.com/mifki/df-twbt/blob/master/PATCHES.md
Post by: Dirst on December 04, 2014, 03:25:33 pm
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.
" # + = ^ I î n V æ Æ (and X for the cursor)
plus a couple others if you want to worry about the Adventure Mode travel map. That handful could be differentiated on the map with overrides, allowing map stuff on the maps and text stuff elsewhere.
Post by: mifki on December 05, 2014, 07:22:35 am
Post by: rmblr on December 06, 2014, 06:03:39 am
When launching dfhack i'm getting Not found: data/art/curses_square_16x16.png
I am using libgraphics for 0.40.19 from https://github.com/svenstaro/dwarf_fortress_unfuck
Edit: Ok, it was a user error. I just hadn't installed everything correctly. Its working now, though some more installation docs would be useful. Made a pull request with build instructions: add build instructions to readme by Ramblurr · Pull Request #22 · mifki/df-twbt (https://github.com/mifki/df-twbt/pull/22)
Post by: Max™ on December 06, 2014, 02:24:06 pm
Post by: scamtank on December 06, 2014, 02:25:04 pm
Post by: lethosor on December 07, 2014, 11:33:22 am
Post by: mifki on December 07, 2014, 04:17:46 pm
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/)).
There are some issues with cursor "stability" when using TwbT in general (because the game doesn't know the correct map size). I'll check how it all works with this tweak (and without) and what can be done.
Post by: utunnels on December 08, 2014, 01:31:00 am
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).
Post by: Max™ on December 08, 2014, 02:05:54 am
Post by: mifki on December 08, 2014, 02:13:24 am
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).
I thought I've fixed an issue like this, but probably I didn't check/notice it specifically with bridges, I'll check.
Post by: utunnels on December 08, 2014, 02:14:56 am
Post by: Balgias on December 10, 2014, 06:17:51 am
"twbt tilesize 32 32" ( with and without quotes )
keybinding add Shift-O "twbt tilesize smaller"
keybinding add Shift-P "twbt tilesize bigger"
and trying to fiddle around with them have all resulted in absolutely nothing ! 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
(http://puu.sh/doLvR/e3de028d38.png)
Post by: mifki on December 10, 2014, 07:00:12 am
However this will result in blurry text anyway. To properly change text size, you should use a different (bigger) font, however I don't think there's a lot of them currently available. What is [FONT:] set to in your init.txt?
Post by: fricy on December 10, 2014, 07:03:12 am
/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
Post by: mifki on December 10, 2014, 08:15:14 am
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)
Oh, so there are actually text fonts of various sizes, cool!
Post by: Col_Jessep on December 10, 2014, 08:31:25 am
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
Personally I like the Phoebus 16x16 text font that is already in the Phoebus graphics set in the starter pack. Looks like this:
(http://i.imgur.com/5hULG4h.png?1)
PS: It's the Phoebus_16x16_text.png - just in case... =P
Post by: mifki on December 10, 2014, 08:45:34 am
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?
Post by: scamtank on December 10, 2014, 08:54:25 am
Post by: utunnels on December 10, 2014, 10:31:23 am
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 reproduce 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.
Post by: HaterSkater on December 10, 2014, 05:31:38 pm
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.
Yes, it was described before.
Plugin currently can't catch tile changes during scrolling or jumping between levels, if two different items/buildings/tiletypes found on same position on game screen natively share same tile with same colour (foreground and background)
It works this way, so you need to be careful. For example, avoid overriding area tiles, like floor, or grass
UPD:
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?!
Post by: mifki on December 10, 2014, 06:05:34 pm
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.
Post by: Dirst on December 10, 2014, 07:58:07 pm
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.
Post by: Col_Jessep on December 10, 2014, 08:14:46 pm
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?
My favorite feature is multilevel tbh. That's just so awesome! :D
Post by: mifki on December 10, 2014, 08:50:14 pm
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?
It's not about blitting, it's about updating OpenGL data for changed tiles (and with TWBT this also includes processing overrides, which is much slower than just updating OpenGL data). Actually I think I can do full screen updates when the map is moved, anyway most of the tiles change in this case. Yes, this seems to be the right thing to do.
Post by: lethosor on December 11, 2014, 03:36:17 pm
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
Post by: mifki on December 11, 2014, 03:53:36 pm
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
Yep. Should I just use 4.5 instead or provide builds with two versions?
Post by: lethosor on December 11, 2014, 07:07:13 pm
Post by: Rose on December 15, 2014, 12:01:06 am
As in, how easy would it be to rip it out and use it for my own project :)
Post by: mifki on December 15, 2014, 01:41:24 am
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 :)
There's a function is_text_tile() https://github.com/mifki/df-twbt/blob/master/tileupdate_text.hpp#L1 , but as I moved to completely separate map rendering and don't need this logic anymore, I didn't pay attention to its accuracy recently.
Post by: Rose on December 15, 2014, 02:33:03 am
Post by: mifki on December 15, 2014, 03:06:17 am
Would you reccomend using it for replacing the rendered dwarf map entirely with something completely different? (In my case, perspective)
Using what - my method, or that function (which alone isn't very helpful)?
I think the optimal way is to do how I'm doing it - disabling the original map rendering and doing whatever you want instead, at least it's better from CPU usage point of view. The only problem is that it requires some additional addresses to be located in df binary for each version. Otherwise you can use twbt code as a base, it handles all the patches and layout stuff.
Post by: Rose on December 15, 2014, 03:32:58 am
Post by: Nopenope on December 15, 2014, 10:47:18 pm
Post by: mifki on December 15, 2014, 11:08:35 pm
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?
Separate print mode is just a way to enable twbt. It requires OpenGL mode (STANDARD) and never worked in 2D. Theoretically, it should be possible to support 2D mode as well, but I don't see a reason to do that.
Post by: Nopenope on December 15, 2014, 11:22:33 pm
Also can TWBT be enable in VBO print mode?
Post by: mifki on December 15, 2014, 11:39:29 pm
Well, it could be interesting for those whose video card doesn't support OpenGL or wish to have TrueType fonts.
I was thinking about possibility to use multilevel rendering (obviously font-related functionality doesn't make sense with TTF) in 2D mode, but it's just too much work that not so many people need.
Also can TWBT be enable in VBO print mode?
VBO is just a variation of OpenGL and TWBT does it internally. That's the idea of having a separate print mode for TWBT - it's not working _in_ some mode, it replaces renderer, so it _is_ a mode itself.
Post by: Meph on December 19, 2014, 12:55:46 pm
Awesome! Thank you for that addition. :)
Post by: HaterSkater on December 19, 2014, 04:41:24 pm
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, that actual point of using ttf may be kinda different, cuz it allows you to use ttf font, that may not be monospaced, as tilesets are. If DF had better support of TTF (and even TWBT+TTF combo) before, i've decided to make normal font file, or choose existing, instead of making text tileset.
Not asking for it now, though, since i'm happy with the font i've finally developed
Post by: Meph on December 19, 2014, 04:49:33 pm
Post by: lethosor on December 19, 2014, 05:00:53 pm
Edit: Of course, if you're referring to text-based screens, a narrower font allows longer line lengths.
Post by: LeoCean on December 19, 2014, 05:09:51 pm
Post by: BlueSteelAU on December 21, 2014, 02:33:37 am
Post by: mifki on December 21, 2014, 03:31:01 am
EDIT. Uh oh, something went wrong. Looks like it will take some time.
Post by: mifki on December 21, 2014, 03:33:22 am
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).
Right, but also wide sidebar is more usable with narrower font because it doesn't take up half of the screen.
Post by: BlueSteelAU on December 21, 2014, 06:41:04 am
Site still down :(
more time passes (about 8 hours)
its up again ;) thanks
Post by: mifki on December 21, 2014, 08:06:26 pm
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..
Post by: nothingSpecial on December 22, 2014, 08:41:41 am
What can make the screen turn almost completely black?
Sometimes I see the glance of red in the intro (where title should go); I also have seen once multilayer shadow. But in the main menu screen is completely black. Windows, DF v 0.40.19, DFhack v 0.40.19-r1, TWBT v 5.37.
Post by: Dirst on December 23, 2014, 01:04:43 pm
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 :)
(More likely, BlueSteelAU wants to study changes in your code.)
Post by: Rydel on January 05, 2015, 09:11:04 pm
Could the archive include the relative folder structure, that way you could just drag an drop the whole thing, the way you can for dfhack or mods, instead of having to individually move each file. It's a small change, but when I first tried TWBT, I had trouble figuring out where each file went.
Post by: PeridexisErrant on January 05, 2015, 09:36:03 pm
Post by: Rydel on January 05, 2015, 11:01:55 pm
Post by: mifki on January 06, 2015, 03:56:51 am
I'll have to check changes made to mousequery and other plugins and merge them into versions included with twbt a bit later.
As for folder structure, 1. I just thought people are getting twbt primarily in starter packs, and then only updating if I release new version between starter pack releases. So I didn't actually care much about what's included in my package. 2. If you're installing manually, you'll have to configure it anyway (specify fonts and print_mode in init.txt), so just copying won't install it properly. 3. On OS X you can't merge folders by dragging/dropping them anyway. 4. In old days (and who knows, maybe sometime again) the package included builds for several df/dfhack versions, and I didn't want to duplicate all other files as well just to have df-like folder structure.
So.. I'll better add installation instruction in readme file instead.
Post by: vodi on January 06, 2015, 11:28:33 am
Spoiler (click to show/hide)
Post by: Dragoon209 on January 06, 2015, 01:04:30 pm
win user here - 5.38 crashes on load for me.Legacy mode works, but the font is basically unreadableSpoiler (click to show/hide)
Same issue, crash on first load of a new fort in a new world. I have tested the dev 5.39 build as well.
Attempting to use with the latest version of the starter pack, 40.23 r1.
Let me know if there is anything else I can provide that would be helpful!
Post by: mifki on January 06, 2015, 03:33:18 pm
try 5.40
Post by: PeridexisErrant on January 06, 2015, 04:12:09 pm
Post by: vodi on January 06, 2015, 04:36:10 pm
Post by: notfood on January 06, 2015, 11:49:54 pm
Post by: Meph on January 07, 2015, 02:15:27 pm
Post by: mifki on January 07, 2015, 03:54:54 pm
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 think the easiest would be to try 0.40.19 with 5.37 (https://github.com/mifki/df-twbt/releases) of your hardware.
Post by: DragonDePlatino on January 07, 2015, 04:02:30 pm
(http://fc00.deviantart.net/fs70/f/2015/007/9/d/body_items_by_dragondeplatino-d8czl59.png)
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.
Post by: mifki on January 07, 2015, 04:19:24 pm
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.
Post by: Meph on January 07, 2015, 04:45:52 pm
It is a very good idea though. A skull lying around should certainly look different from a teeth. :D
Post by: scamtank on January 07, 2015, 04:47:53 pm
Post by: DragonDePlatino on January 07, 2015, 05:12:47 pm
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.
Yeah...that's why I abandoned DawnFortress and am working on my new graphics set. A lot of DawnFortress' graphics were too muddy for even me to recognize. ):
Anyways, it seems a few people have been saying this isn't possible...A bit of a defeatist attitude if you ask me, but if this proves too difficult would it be possible to have at least the prepared organ (http://dwarffortresswiki.org/index.php/DF2014:Prepared_organs) graphics?
Post by: Meph on January 07, 2015, 05:21:37 pm
Prepared organs are all itemtype MEAT. Its the same as the bodyparts, but I'd wait for Mifki to say something. He knows more than anyone else, and even if it might not be possible now, he might include the functionality if its requested.
Post by: txtsd on January 07, 2015, 06:21:22 pm
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?
Post by: Rydel on January 07, 2015, 07:29:51 pm
Post by: Meph on January 07, 2015, 07:49:12 pm
Post by: Obsidian Soul on January 08, 2015, 07:33:47 am
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.
Post by: lethosor on January 08, 2015, 08:36:07 am
Edit: if you simply want to view tile types, "probe" should do the trick.
Post by: mifki on January 08, 2015, 08:59:26 am
Eg.
[OVERRIDE:88:T:"stone stair up/down":3:88]
Post by: Obsidian Soul on January 08, 2015, 09:22:02 am
Oh, and I'm referring to the list in the TWBT readme.
How about the map tiles though?
Post by: mifki on January 08, 2015, 09:32:42 am
Ahk. Will do. Thanks :)
Oh, and I'm referring to the list in the TWBT readme.
How about the map tiles though?
TWBT doesn't affect world/mini map (that's what you call map, right?).
Post by: lethosor on January 08, 2015, 01:36:18 pm
Edit:
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?
Edit 2: Ah, Gui::getViewportPos() is where the problem occurs - it returns df::coord(*df::global::window_x, *df::global::window_y, *df::global::window_z), so modifying any of those three globals will break stable-cursor.
Post by: LeoCean on January 09, 2015, 03:26:04 am
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.
FeatureBoulder, TreeCapFloor1, FrozenRamp, GrassDarkFloor1, Grass2StairD, SemiMoltenRock, TreeRootSloping, Waterfall, SoilWetFloor2, StoneWallWorn1 RiverE, RiverN, etc. and BrookE, BrookN, etc. refer to map tiles?
These are ingame tiles, not on the world map. Really you should just consider if the river or brook is going north it'd use RiverN for example, idk if that actually exists though but i do know that's what it'd be for. The other ones you asked about are pretty straight forward to the frozenRamp would be a ramp in the frozen biome featureboulder is the one in the main tileset that is called boulder (not the mined rock, just the boulder on the surface) For the grass you will notice in the raws they should use 4 different tiles there's light grass and dark grass and 2 kinds of each I believe, it's been awhile and I haven't actually edited those things for twbt someone else has though. You may find some info you are looking for here http://www.bay12forums.com/smf/index.php?topic=144270.0.
As for the map tiles you ask about here's a link http://dwarffortresswiki.org/index.php/DF2014:Map_legend, you can change some of those things but they need to be changed from the main tileset or I guess if someone were to use a font tileset it may work, I guess it'd be best if Toady added the ability to have another tileset for the map since you'd either need the main or text tilesets to have those edited tiles. It's possibly something dfhack could manage and twbt through it.
That wiki entry is only relevant for the acii version though some of that is changeable in the raws. He's calling embark map tiles map tiles I'd assume mifki.
Post by: Obsidian Soul on January 09, 2015, 05:05:31 am
On another note, where do I find out where the subtypes are listed? Meph seems to have a full list of all the weapons and clothing, for example. But I wonder where these were obtained. The raws? Mousequery, even on using "probe" on DFHack, don't seem to list items (just the underlying tiletype).
And yes, already knew about the previous functionality of the [world and embark] map tiles. I was hoping TWBT also separated them from the text. Since it hasn't, it's definitely on my wishlist for mifki/toady. :P
Also another on my wishlist : separate overrides for engraved walls and floors. :)
Post by: scamtank on January 09, 2015, 05:21:31 am
Post by: Obsidian Soul on January 09, 2015, 05:25:22 am
[OVERRIDE:Tile:Kind:Id:Type:Subtype:Tileset:NewTile:NewFg:NewBg]
Post by: mifki on January 09, 2015, 06:02:43 am
Code: [Select]
[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>
And so on. But subtypes depends on the order things defined in raws, so later I'll make it accept names instead of subtype numbers, otherwise it probably will cause problems with mods.
Post by: Obsidian Soul on January 09, 2015, 06:30:06 am
Code: [Select]
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]So I'm guessing the concept is the same then? With the subtype number for toys therefore being:
0: Puzzlebox
1: Toy Boat
2: Toy Hammer
3: Toy Axe
4: Miniforge
?
Post by: mifki on January 09, 2015, 06:54:46 am
For me it's just easier to start lua console ('lua' command) and then '~df.global.world.raws.itemdefs.toys[NUMBER]' (or armor, weapons, etc.) and see what that subtype means than to count definitions in raws.
Post by: Meph on January 09, 2015, 06:55:29 am
I already have a working override file you can use, its included in the LNP or here: http://www.bay12forums.com/smf/index.php?topic=139579.msg5398400#msg5398400
All you need to do is replace the tileset and put the tiles in the same places.
Post by: Obsidian Soul on January 09, 2015, 07:27:41 am
Meph, yep. Already examining those and Spacefox's overrides. :) Thanks for those. (btw, where in the raws are items defined, e.g. crowns, jugs, flasks, etc.?)
Post by: Meph on January 09, 2015, 07:37:02 am
crowns are a subtype of crafts, which are hardcoded and not accessable in the raws. You can create them in reactions with CRAFTS:CROWN but thats it, there is no file with them in it. Same for jugs, flasks... coins, mugs, backpacks, quivers, bags, and all the furniture. Its not in the raws.
Post by: Rydel on January 09, 2015, 12:14:01 pm
There is a program that will get a list of all the subtypes for each type at http://dffd.wimbli.com/file.php?id=9086
As a warning, the files have to follow a specific naming convention for the tools to work, so it may not work for all mods.
Post by: Obsidian Soul on January 09, 2015, 02:05:38 pm
Code: [Select]
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]
Cheers! :)
Post by: DragonDePlatino on January 10, 2015, 12:39:18 am
Post by: mifki on January 10, 2015, 01:30:18 am
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?
Post by: Obsidian Soul on January 10, 2015, 01:36:35 am
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.
Post by: mifki on January 10, 2015, 01:48:41 am
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.
Ok, I'll make it accept tile number range (xx-yy) in override specification instead of a single number.
Post by: Obsidian Soul on January 10, 2015, 02:06:47 am
Post by: Meph on January 10, 2015, 03:27:46 am
Post by: LeoCean on January 10, 2015, 06:04:40 am
Post by: mifki on January 10, 2015, 06:27:39 am
Post by: Erendir on January 10, 2015, 06:40:27 am
Like, for example, there is a boulder with 3 possible tiles. 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)
Post by: mifki on January 10, 2015, 06:53:51 am
Post by: PeridexisErrant on January 10, 2015, 07:19:37 am
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.
Post by: Erendir on January 10, 2015, 08:14:35 am
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.
You are right, but it was just an illustration of the idea. I experimented a little, and I like following function:
100*sin(997*x^3+993*y^5) mod N
(rounded somewhere on the way of course)
Spoiler (click to show/hide)
Post by: DragonDePlatino on January 10, 2015, 12:42:46 pm
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.
Post by: Bloax on January 10, 2015, 01:41:05 pm
Can you override graphics by material? Quality?
Is there a test map to see all the overrides?
Post by: Obsidian Soul on January 10, 2015, 04:10:44 pm
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.
It's also the same thing I did for my grass (before DF2014 turned my grass back into ugly ones :(). Those things that look like 3 green dots are variants to break up the pattern a bit. Good to see you're also explicitly defining grass ^^
Spoiler (click to show/hide)
How extensive is the tile overriding functionality?
Can you override graphics by material? Quality?
Is there a test map to see all the overrides?
You should download TWBT and read the readme. It lists most of the tiles that can be overriden. It doesn't include tiles that are overridden in the raws (plants, monsters, units), so it's currently limited to items (food, clothing, weapons, crafts, etc), tiletypes (terrain features, etc. including trees, water, etc.), and buildings (workshops, walls, etc.). Can't also override by material or quality, but to a limited extent you can override by subtype (I posted the list a few posts down).
To see it in action, I recommend downloading the starter packs/lazy newb packs and examine the existing sets there (the override codes are found in the init folder, while the graphics are in the graphics folder). Spacefox is currently the most overriden graphics set, I think.
Post by: Rydel on January 10, 2015, 05:41:12 pm
Post by: Meph on January 10, 2015, 06:39:56 pm
Post by: Rydel on January 10, 2015, 06:49:20 pm
Post by: Rose on January 10, 2015, 10:00:11 pm
In armok vision, I have things matched up with the different parts of the material name. (everything ending in leaf, for example)
Should be easy to port over.
Post by: Snergler on January 18, 2015, 12:31:26 pm
Post by: LeoCean on January 18, 2015, 02:17:59 pm
Post by: Snergler on January 18, 2015, 02:28:42 pm
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
Post by: Melax on January 18, 2015, 02:38:47 pm
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?
Post by: LeoCean on January 18, 2015, 06:16:50 pm
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
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.
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?
At the moment no.
Post by: Snergler on January 18, 2015, 08:53:51 pm
Quote
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
Post by: txtsd on January 22, 2015, 08:10:17 am
Post by: PeridexisErrant on January 24, 2015, 04:55:39 am
Post by: mifki on January 24, 2015, 05:53:22 am
Post by: scamtank on January 24, 2015, 06:30:25 am
Post by: lethosor on January 24, 2015, 06:51:06 am
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.
Post by: PeridexisErrant on January 24, 2015, 06:56:07 am
Post by: txtsd on January 24, 2015, 03:26:02 pm
Try version 5.41
stable-cursor is still broken.
Post by: Max™ on January 24, 2015, 09:47:16 pm
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.
Post by: utunnels on January 24, 2015, 10:24:58 pm
:P
Post by: mifki on January 25, 2015, 03:06:51 am
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?
Post by: mifki on January 25, 2015, 03:08:58 am
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.
Honestly, I don't know what you're talking about. When I have time, I'll spend some time in adventure mode and will check these two things. Well, the real problem is that I just even don't know how to play in adv mode.
Post by: Max™ on January 25, 2015, 02:36:24 pm
Sometimes convo gets chopped up diagonally, I think that means it is wrapping around weirdly due to the zoom.
Like instead of normal convo I will see this:
Code: [Select]
A great beas the titan Snust
our people it for murder
vanqui glory in th
Post by: lethosor on January 25, 2015, 04:51:17 pm
mifki: Any idea what's wrong with "tweak stable-cursor" in fortress mode?
Post by: mifki on January 25, 2015, 06:26:34 pm
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?
There's a lot of incompatibilities I believe. Since it's a frequently requested feature, I'll try to look into it today or tomorrow.
Post by: Max™ on January 25, 2015, 08:47:44 pm
Post by: utunnels on January 25, 2015, 09:32:48 pm
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?
I think it is OK to use normal font instead of graphics. They look too small unless you are using 16x16 font.
Post by: RaidSoft on February 09, 2015, 02:17:51 am
Any ideas anyone?
Post by: PeridexisErrant on February 09, 2015, 07:07:48 am
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?
Looks like resizing artefacts from zooming - does zooming out a step (in a fullscreen menu, to affect text) help at all?
Post by: RaidSoft on February 09, 2015, 07:20:30 am
It seems like the minimum size is too large or something thus causing it not to be 1:1 pixels.
Post by: mifki on February 09, 2015, 07:21:50 am
Post by: scamtank on February 09, 2015, 07:22:53 am
Post by: RaidSoft on February 09, 2015, 07:33:17 am
I think that has to do with linear filtering in the inits. Switch it to NEAREST and it stops blurring the edges like that.
It definitely helped it look better but it kind of looks like the text is getting resized to a size it's not really intended for, looks like this when in a maximized window with Nearest instead of Linear http://puu.sh/fGr9F/6695f1a8fb.png
Post by: scamtank on February 09, 2015, 07:36:00 am
Post by: Incantatar on February 10, 2015, 06:16:04 am
Code: [Select]
TWBT: no display patchat the start andCode: [Select]
Plugin twbt has failed to shutdown!when closing df.It does seem to work properly ingame. Are the warnings irrelevant?
Post by: mifki on February 10, 2015, 06:40:38 am
Post by: Max™ on February 11, 2015, 05:46:49 pm
Spoiler (click to show/hide)
Post by: LeoCean on February 11, 2015, 06:06:39 pm
Post by: lethosor on February 11, 2015, 06:16:31 pm
(Also, there is more than one currently-maintained pack, so asking if someone is using the "new starter pack" isn't particularly helpful for troubleshooting purposes.)
Edit: Right, it is an adventure mode-specific issue.
Post by: Max™ on February 11, 2015, 06:19:25 pm
Post by: Motsognirson on February 11, 2015, 08:26:07 pm
dfhack is spitting out:
Plugin twbt was not built for this version of DFHack.
Plugin: 0.40.24-r1, DFHack: 0.40.24-r2
I am running this on Linux, but I hope that won't be an obstacle.
(side note: I guess the installation for TWBT is what it says in the README + dropping twbt.plug.so into hack/plugins. Please correct me if this is wrong)
Thanks for the great plugin!
Post by: PeridexisErrant on February 11, 2015, 08:52:02 pm
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/
Post by: Motsognirson on February 11, 2015, 09:30:11 pm
You just need the latest version of the plugin, http://build.mifki.com/
Du'oh! That fixes it. By the way, I got that apparently fallacious error "TWBT:no display patch", which I notice mifki already noted in another post. TWBT seems to be working just fine anyway.
A thousand engravings in your honor, mifki and PeridexisErrant!
Post by: Baleur on February 12, 2015, 03:50:27 am
So one would be able to slightly see down to a lower Z-level through undug earth (for seeing the dining hall at Z-51 under your entrance stairway at Z-50 for example). If so, would be great to include a "density" modifier too, much like the fog modifiers, so the user could tweak the opacity as desired.
Basically, like the effect in this website.
http://mkv25.net/dfma/poi-13983-legendarydininghall1sttier
Is it possible to use dfhack with twbt overrides to change the vomit color?
Something along the lines of;
[OVERRIDE:WhateverTileWaterIs:T::VOMIT:1:WhateverTileWaterIs:ForegroundColor:BackgroundColor:]
1. Should it work with T as the type, or M for material? Or C for contaminant?
2. What is the tile number for water anyway (phoebus)? The raws dont show it under Blood etc.
Post by: utunnels on February 15, 2015, 06:44:55 am
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
Post by: CowThing on February 15, 2015, 03:33:34 pm
How do I replace the prepared food tile?
And how do I replace the active screw pump tile? I'm able to replace the inactive tile using SCREW_PUMP:ScrewPump, but I don't know about the active tile.
Post by: draeath on February 15, 2015, 04:16:38 pm
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.
Post by: LeoCean on February 15, 2015, 04:19:19 pm
[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.
@draeth It really isn't meant to be used in adventure mode but if you check the readme you can edit the shadows (which is how clear the lower layers are).
Post by: utunnels on February 15, 2015, 07:10:44 pm
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.
Yeah, sometimes it is hard to tell. z-0 and z-1 looks too similar sometimes, maybe it should add more shadows? I don't know.
But trees and waterfalls look really nice.
Post by: Rydel on February 15, 2015, 07:52:33 pm
Post by: LeoCean on February 15, 2015, 08:13:23 pm
multilevel shadowcolor -r- -g- -b- -a-
Set shadow colour. Components are in range 0-1. Default is 0 0 0 0.4
multilevel fogcolor -r- -g- -b-
Set fog colour. Default is 0.1 0.1 0.3
multilevel fogdensity <density> [<start>] [<step>]
Set fog density parameters. Default is 0.15 0 1
Add it to dfhack.init or extra_dfhack_init.init it doesn't really matter.
Post by: utunnels on February 15, 2015, 08:43:25 pm
Post by: Max™ on February 15, 2015, 08:48:43 pm
Post by: CowThing on February 15, 2015, 09:39:05 pm
[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.
Thanks, I tried it out, it seems [OVERRIDE:37:I:FOOD:FOOD:0:text:48] worked. It changed the food into a "0". But it seems like it only overrides when the dwarf has it on a table, when the dwarf is carrying the prepared food it's still a "%". But you're right that it's rarely seen, I just wanted to see how it works.
Post by: draeath on February 16, 2015, 12:07:57 pm
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!
Post by: LeoCean on February 16, 2015, 05:39:55 pm
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!
You can already type mutlilevel # in the dfhack console to include more levels or less.
Post by: lethosor on February 16, 2015, 06:27:43 pm
Post by: mifki on February 16, 2015, 06:58:54 pm
Post by: Max™ on February 16, 2015, 08:09:37 pm
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.
Post by: mifki on February 16, 2015, 08:15:53 pm
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)
Post by: Max™ on February 17, 2015, 03:45:16 am
But you can always try to report glitches (better with a screenshot) and crashes)
Spoiler (click to show/hide)
Spoiler (click to show/hide)
Plus uh, I was trying to see if I would crash in a goblin fortress... it was ridiculously low population for some reason, no trolls murdering gobs in the tower itself... and then... this, which isn't due to twbt I'm sure, but what the hell:
Spoiler (click to show/hide)
Post by: utunnels on February 18, 2015, 12:22:41 am
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]
Post by: LeoCean on February 18, 2015, 12:51:28 am
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]
Yes most of them, some of those won't ever be used but if you are overriding one why not all with the same thing unless you want them to be different.
Post by: Boltgun on February 25, 2015, 04:27:37 am
Post by: LeoCean on February 25, 2015, 04:40:10 am
Post by: utunnels on February 25, 2015, 05:23:31 am
Post by: fricy on February 25, 2015, 06:24:32 am
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...
Post by: mifki on February 25, 2015, 07:35:09 am
Post by: utunnels on February 25, 2015, 10:31:59 am
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...
Oh just found that topic.
It doesn't work well with multilevel rendering. But it looks really cool.
Post by: mifki on February 27, 2015, 11:47:37 pm
Post by: utunnels on February 28, 2015, 12:12:31 am
Post by: PeridexisErrant on February 28, 2015, 02:05:57 am
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.
Ah, of course. It's just not finished until you add animated machinery, custom buildings, and overlapping transparent tiles. I don't know why I ever thought otherwise :P
Post by: utunnels on February 28, 2015, 02:41:38 am
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.
Post by: Max™ on February 28, 2015, 04:09:09 am
Post by: LeoCean on February 28, 2015, 06:06:08 am
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.
You can split the image you want up into 16x16 pixels by however big the image is. Spacefox tileset has some overides in the starterpack that fricy added that shows how to edit building tiles.
Post by: Rydel on February 28, 2015, 08:20:17 am
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.
a 48x48 image is 9 16x16 tiles. If you put a 48x48 image on a grid of 16x16 tiles, you'll see it takes up 9 of them, and you don't have to do anything extra for it to work. Take my avatar for instance. It was designed as a single 128x128 image, but the Super Nintendo treats it as 256 8x8 tiles (Well, technically 143, since it doesn't count the blank tiles).
So, I guess what I'm saying is, could you elaborate on what you want changed, because I'm not following you.
Post by: utunnels on February 28, 2015, 08:45:50 am
What I mean is instead of replace the tiles of a workshop one by one, you use a single image for the entire workshop.
For example, a still has two o tiles and two ~ tiles, but I don't want those parts to be identical. If there a 3x3 area in the texture atlas, maybe I can write something like [OVERRIDE::B:STILL:::3:56:3x3]
Code: [Select]
÷═╕
o ~
~ oOr maybe a more simple solution, just use the position instead of tile index. For example, the upper left tile is 0,0, and the lower right tile is 2,2.
Post by: utunnels on March 01, 2015, 07:51:04 am
Post by: mifki on March 01, 2015, 08:30:54 am
What I mean is instead of replace the tiles of a workshop one by one, you use a single image for the entire workshop.
I don't know yet what the configuration will look like when I implement multi tile building overrides properly.
Oh I got another question: what are tile types for insect colonies? Currently they look exactly the same as wells.
Vermin are stored separately from tiles/buildings/items (and units), so currently you can't override tiles for this type of things.
Post by: mifki on March 03, 2015, 11:44:49 pm
Not sure how all this will be configured though.
A brilliant idea came to my mind - there will be no configuration at all! I will hardcode all the buildings and items (+support for custom workshops, item subtypes, etc.) together with some of their variations. These combinations will have names and you will just provide separate images like
data/art/tiles/door.png
data/art/tiles/door-locked.png
data/art/tiles/chest-empty.png
data/art/tiles/chest-full.png
data/art/tiles/bed.png
data/art/tiles/bed-dorm.png
and so on. That's easier for me to develop and for you to customise/install (for example images may be of any size, you can just drop whatever image files you want, no need to squeeze them into a single tileset image).
And also, any of these files will possibly contain several images for animation. Here, some spinning doors: (http://i.imgur.com/tMx2GJn.png)
(http://i.imgur.com/n6nD4le.gif)
Post by: PeridexisErrant on March 04, 2015, 12:00:13 am
Yep. A simple fix (https://bitbucket.org/PeridexisErrant/python-lnp/commits/380b2451de023319ad96416ce23a4d61e05e5475) to allow dirs as well as files, and avoid overwriting a file supplied by the graphics pack.
Post by: utunnels on March 04, 2015, 12:03:03 am
Does the tiles have to be 16x16 or we can still specify their size?
Post by: mifki on March 04, 2015, 12:10:07 am
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.
For pylnp yes, but for example if someone makes a new image for a workshop (and once it's that easy I hope more people will create custom building graphics), they will just need to upload one or two files and you download to that folder. While currently it has to be a whole tileset plus overrides spec that you need to add to your overrides.txt
Post by: mifki on March 04, 2015, 12:36:12 am
Yeah, sounds good to me.
Does the tiles have to be 16x16 or we can still specify their size?
Tiles have whatever size you zoom to.
For a 3x3 workshop you create an image of any square size, it will be automatically split into 9 pieces and resized to match your current tile size. If you provide a rectangular image instead, it will use its height to extract multiple square images and use them for animation.
Post by: mifki on March 04, 2015, 05:37:39 pm
Post by: Dirst on March 04, 2015, 11:36:29 pm
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.
Post by: Rose on March 04, 2015, 11:55:23 pm
Post by: Dirst on March 05, 2015, 01:47:14 am
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.
Post by: mifki on March 05, 2015, 02:05:45 am
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.
Post by: UristWoodie on March 05, 2015, 08:36:46 am
Multiple materials will make it interesting..like the Dyers workshop (with a bucket of one material, and a barrel of another?) Soap makers, well, tanner (IIRC).
Waiting patiently. And eagerly. Thanks Mifki!
Post by: Warmist on March 05, 2015, 09:24:17 am
Post by: Urist McGoombaBrother on March 05, 2015, 11:27:42 am
you can just drop whatever image files you want, no need to squeeze them into a single tileset image).
This. +1 from me. Absolute awesome work, especially when it works out as intended. Many thx for your effort.
Got some questions.
1) Is adding additional tiles also possible for stones/gems?
2) I created a sample file (16x16) for an unmined stone structure. How will I have to name this and where to put it in future versions of TWBT?
(http://i.imgur.com/UUK3QlB.png)
3) In the door example from you I found five different types of Gray. In the standard phoebus tileset there are a lot more. Some tiles even contain colours like red, green, etc. What effect do they have? How is defined for which parts of the tile the foreground or background colour of the underlying material is taken? How do you define transparency?
4) How to amend the material in the raw file to actual reference to the new tile? Here is an example of the material Arsenopyrite, I modded in. How to change it the way to use the a.m. custom new sample tile instead of tile [TILE:156]? Maybe [TILE:STONE_STRUCTURE_1.png]?
Spoiler (click to show/hide)
5) Will this be stonesense compatible?
Post by: Dirst on March 05, 2015, 12:17:35 pm
My suggestion was to allow both without using a configuration file off to the side.
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.
And so on. Some error-handling needed like different-sized images, and just use "white" if the artist calls for a higher-number material than was in the building.
Then the whole things is handed off to the multilevel renderer to get it fogged/shaded properly.
Post by: mifki on March 05, 2015, 03:40:05 pm
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.
Yep, I'll probably end up with something like this. But still there are problems.
Materials have two colours - background and foreground, and ideally I need to make use of both of them somehow..
Post by: Erendir on March 07, 2015, 07:14:59 am
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 :)
Post by: Meph on March 07, 2015, 08:19:22 am
Post by: Rydel on March 07, 2015, 10:53:15 am
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 :)
It's the game able to shade those colors? Then just having a pure color for it wouldn't work.
Multiple Layers would probably works best
Layer 0 is as-is
Layer 1 is material 1 background
Layer 2 is material 1 foreground
Layer 3 is material 2 background
Layer 4 is material 2 foreground
This would allow as-is colors, both the foreground and background colors of both materials, and proper transparency.
The layers should probably be together by material instead of foreground/background so graphics that only care about one material can just omit layers 3 and 4
Post by: PeridexisErrant on March 07, 2015, 05:57:15 pm
-0, -1bg, -1fg, -2bg, -2fg
Order of layering is fairly clear, as well as what each image is
Post by: Dirst on March 07, 2015, 07:23:19 pm
Post by: Rydel on March 07, 2015, 07:30:43 pm
http://www.libpng.org/pub/mng/mngdocs.html
Post by: mifki on March 07, 2015, 08:01:37 pm
Just wanted to say that it is nice seeing you still further developing this. :)
I thought you'd be one of the people interested in custom graphics for vanilla buildings and could tell what features you want - transparent/empty tiles, multiple materials, etc.
Also, by the way, in vanilla many buildings (including workshops) for some reason use only foreground colour and don't use background. Fg and bg colours are used only for limited number of buildings. It would be cool to support them for everything, but I'm not sure whether two colours per material are actually required and will be useful, or they exist only because of the limitations of vanilla tilesets and for ascii mode.
Thinking further, it would be cooler to support not just colours, but patterns for materials - and transparent pixels will be filled with that pattern, which may be one solid colour, two colours or anything else. IRL materials have either single "foreground" colour, or some multicolour pattern, eg. minerals. The only problem is that tiles are rather small so in reality it might not look as good as it sounds.
Post by: Max™ on March 07, 2015, 09:41:18 pm
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.
Post by: Dirst on March 08, 2015, 01:06:17 pm
Post by: mifki on March 08, 2015, 08:26:53 pm
Post by: Dirst on March 08, 2015, 08:49:14 pm
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.
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.
Post by: Rydel on March 09, 2015, 08:52:39 am
Libmng has full PNG support, since all PNG files are valid MNG files.
Post by: Dirst on March 09, 2015, 08:57:24 am
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.
Post by: utunnels on March 09, 2015, 09:03:20 am
Post by: mifki on March 09, 2015, 04:25:10 pm
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?
Post by: Dirst on March 09, 2015, 07:00:32 pm
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?
Post by: Wooster on March 10, 2015, 05:14:25 am
Plugin twbt was not built for this version of DFHack.
Plugin: 0.40.24-r1, DFHack: 0.40.24-r2
multilevel is not a recognized command.
I'm coming here first to start pinning down the source. Is it a problem in TWBT, dfhack or LNP?
Post by: fricy on March 10, 2015, 05:26:52 am
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)
Post by: Wooster on March 10, 2015, 08:22:46 am
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)
Post by: KingKaol on March 13, 2015, 12:35:43 am
I switched back to the original dfhack r2 plugin files and everything still works, no crashes. (I'm using TWBT for the multilevel view only, no graphics sets, so i don't know if those plugin files are necessary or not).
Post by: mifki on March 13, 2015, 01:23:34 am
Post by: KingKaol on March 13, 2015, 02:31:11 am
Post by: mifki on March 13, 2015, 02:43:09 am
do i have to specifically generate one or is that output to a log somewhere?
http://stackoverflow.com/a/2919398/991806
Thanks.
Post by: KingKaol on March 14, 2015, 06:42:07 am
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?
Post by: mifki on March 14, 2015, 07:26:35 am
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?
Doesn't it compress well?
Anyway, if you can't upload it somewhere, and if you have gdb installed, you can do "gdb libs/Dwarf_Fortress -c <dumpfile>" but I'm not sure if it will work that easy, don't remember what happened when I tried to debug DF dump last time.
Post by: KingKaol on March 14, 2015, 07:58:15 am
https://www.dropbox.com/s/ek3dfa0q0r6powo/core.tar.gz?dl=0
Post by: mifki on March 14, 2015, 08:08:44 am
Post by: Rydel on March 14, 2015, 08:25:31 pm
Is there anything else that could be blocking the tiles from being overridden?
Post by: mifki on March 14, 2015, 09:39:41 pm
Post by: Rydel on March 14, 2015, 09:46:03 pm
Here's the weapon section of my override. I'm testing with this, since the default embark includes an axe and a pick, plus I can easily make training axes/swords/spears
Code: [Select]
###########
# 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]
Post by: k9wazere on March 15, 2015, 09:32:48 am
I've never had DF crash like this before I started using the lazy newb pack, and it's always when I change z-level (otherwise game stability is rock solid for me). Happens several times per game year.
Post by: KingKaol on March 15, 2015, 10:12:28 am
automaterial.plug.so, mousequery.plug.so, and resume.plug.so
by the original files provided by the dfhack release (r2)
Post by: lethosor on March 15, 2015, 10:14:27 am
Post by: LeoCean on March 15, 2015, 12:00:17 pm
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?
Try adding the equivalent of this to it .
[TILESET:Vanilla DF - 24x - Items.png:Vanilla DF - 24x - Items.png:2]
#[OVERRIDE:Tile:Kind:Id:Type:Subtype:Tileset:NewTile]
[OVERRIDE:47:I:AMMO:AMMO:0:2:0]
[OVERRIDE:47:I:AMMO:AMMO:1:2:1]
[OVERRIDE:47:I:AMMO:AMMO:2:2:2]
As I'm pretty certain it requires that.
Post by: Rydel on March 15, 2015, 12:20:44 pm
[TILESET:rally_ho_twbt_1.png:rally_ho_twbt_1.png:2]
In order to make sure I didn't miss anything else, I've put the entire file up on pastebin: http://pastebin.com/r0Z9kGL2
Post by: LeoCean on March 15, 2015, 02:28:29 pm
Spacefox overrides (https://www.dropbox.com/sh/wbnkz8h0205njdj/AABJUDEJbn9dPEbdaZWkwATQa?dl=0)
Make sure you still have your copy though.
Post by: Rydel on March 15, 2015, 02:45:40 pm
Post by: LeoCean on March 15, 2015, 03:25:58 pm
Post by: Rydel on March 15, 2015, 03:31:51 pm
I've also changed it so they both use title case, but that hasn't had any effect.
Post by: mifki on March 15, 2015, 03:45:27 pm
Post by: LeoCean on March 15, 2015, 03:51:12 pm
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.
Try just renaming your item override tileset to Vanilla DF - 24x - Items like in the spacefox overrides (mephs overrides) then use the [Tilest: stuff from the spacefox overrides, not including the item overrides to see if that works. I'm pretty sure it's something to do with the name of the tileset you are using as the item overrides look correct.
Post by: Rydel on March 15, 2015, 04:14:10 pm
Post by: Uzu Bash on March 17, 2015, 04:40:09 am
Post by: Max™ on March 17, 2015, 08:43:07 am
Post by: Uzu Bash on March 17, 2015, 09:32:24 am
Post by: utunnels on March 22, 2015, 07:42:33 am
Post by: Meph on March 24, 2015, 08:13:06 am
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.
Post by: fricy on March 24, 2015, 08:29:23 am
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'm positive that only happens with Obsidian's animated grass, and it's caused by a bug in twbt (https://github.com/mifki/df-twbt/issues/18) with mapping stuff to tile 0. Workaround is here. (https://github.com/fricy/Obsidian/commit/adfdeaeee01c82cb02597809d2b0410a602c5e3f)
(edit: Are you sure that's legacy mode? I've only seen it using regular twbt mode.)
Post by: Meph on March 24, 2015, 08:42:59 am
I tried your fix, it worked perfectly. I had thought the animated grass for the culprit, and deleted all alt-tiles, tried again, and it did not fix it... so I thought it would be something else. Turns out it was the use of the tile:0, which you replaced with tile:255.
That did the trick, all good now. :)
Post by: PeridexisErrant on March 24, 2015, 05:19:42 pm
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!
Post by: Meph on March 24, 2015, 10:21:14 pm
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!
Post by: Putnam on March 24, 2015, 11:06:24 pm
Post by: PeridexisErrant on March 25, 2015, 12:57:41 am
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?
None required for things to keep working, taking advantage of new features would probably take some minimal changes to the areas where scripts call other scripts.
Post by: Boltgun on March 25, 2015, 03:46:28 am
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.
Also it allows to put scripts in the raw folder which is really good for succession games. The only part of a mod left outside the raws now is the speech text files.
Post by: CowThing on March 25, 2015, 05:40:55 pm
Code: [Select]
[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.
Post by: lethosor on March 25, 2015, 05:59:57 pm
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.
Post by: mifki on March 30, 2015, 04:25:46 pm
Post by: Max™ on March 30, 2015, 09:36:44 pm
Post by: mifki on March 31, 2015, 01:50:45 am
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!
I didn't do anything related to this, so not sure if it's really that good, unfortunately.
am:... values were for you (players) to report them if a screen is rendered incorrectly, like the map isn't hidden where it should. Probably it's time to remove them.
Post by: Max™ on March 31, 2015, 04:21:41 am
Edit: ok, the zooming can still give the broken text glitch, but it seems way more stable, I ran around in and out of travel mode, wandering through lots of different sites with folks running around, the sort of stuff I had to be leery of due to it crash, honestly if you disabled the am: reporting I'd be using it full-time instead of just in fort mode. So nice being able to walk into a mead hall or fortress storage room and tell what should be there at a glance again instead of having to scroll and check each square to look for the promising stuff.
Post by: mifki on March 31, 2015, 08:57:22 am
Post by: Dirst on March 31, 2015, 09:08:20 am
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.
Post by: PeridexisErrant on April 07, 2015, 05:55:12 am
Post by: mifki on April 07, 2015, 06:53:42 am
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
Isn't it because of some new screen refreshing plugin? It should print this when you resize window only. I will removing this debug message eventually, but it shouldn't be output repeatedly anyway.
Post by: PeridexisErrant on April 07, 2015, 07:32:31 am
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.
Post by: lethosor on April 07, 2015, 07:42:49 am
Post by: mifki on April 07, 2015, 10:27:29 am
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.
That script fixes some issues with TTF, doesn't it? And shouldn't be active in twbt mode then. Twbt will reallocate buffers and do something else every now and then which isn't food if it's not required.
I somewhat agree with you about debug messages but you see, otherwise we wouldn't know.
Post by: lethosor on April 07, 2015, 11:39:19 am
I don't think printing debug messages to the console by default is necessary, but it could be enabled by the user. Why exactly is TwbT reallocating buffers if the screen size doesn't change, anyway?
Post by: mifki on April 07, 2015, 12:28:00 pm
Why exactly is TwbT reallocating buffers if the screen size doesn't change, anyway?
Because previously this method was called only when grid size actually changes, so there was no need to check. And btw, if the (vanilla) code did nothing in case of no actual changes, the script wouldn't work, you know. I'll check and optimize the code once I'm at home, and again, without the debug messages, we wouldn't know that's required.
Post by: Antsan on April 13, 2015, 02:33:45 am
I guess this is due to the game being paused by the message from the console, which cannot be closed as input is ignored.
Post by: lethosor on April 13, 2015, 05:25:14 am
Post by: Antsan on April 13, 2015, 11:46:42 am
I thought I tried to do that. I'll have to check. I'm currently not using TwbT, so that much is unquestionably true.
Post by: Klisz on April 13, 2015, 11:58:19 am
I'm currently not using TwbT, so that much is unquestionably true.
Why are you posting this in the TWBT thread, then? ???
Post by: Antsan on April 13, 2015, 12:11:49 pm
Sorry for that.
Post by: lethosor on April 13, 2015, 01:59:49 pm
Post by: Robsoie on April 17, 2015, 05:26:14 am
Spoiler (click to show/hide)
Thank you very much for this, this multi layer rendering should definitively be an official feature, it makes the game so much more comfortable to play in adventure mode, i hope Toady will give it a try.
Such greatness !
Post by: Max™ on April 17, 2015, 06:29:11 am
Mead halls and stockpiles with the ability to see "ok there's some mail to check, and a great axe, and a waterskin" is amazing as well.
Post by: mifki on April 17, 2015, 09:15:36 am
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.
Removed them in 5.45, just for you)
Post by: Max™ on April 17, 2015, 06:42:16 pm
Heartchumifki
(http://i.imgur.com/TH44lmb.png)
Post by: LMeire on April 24, 2015, 01:38:21 am
Basically, while I was getting set up, I hit Shift-right while placing a mason shop and the game did this spike thing.
Spoiler (click to show/hide)
Post by: mifki on April 24, 2015, 04:36:03 am
Post by: Max™ on April 24, 2015, 05:44:52 am
Also, current version works great in adventurer mode, such happy, much overrrides, so z-levels, wow.
Post by: LMeire on April 26, 2015, 03:37:18 am
Post by: mifki on April 29, 2015, 05:37:17 am
Post by: Max™ on May 01, 2015, 02:30:11 am
The text does still get chopped up when zoomed in and talking to someone*, but honestly I am unable to worry about that because I can do wonderful things like identify the contents of a room at a glance and enjoy the chaos taking place below me as I leap from tree to tree. Smaller field of view also kinda reduces the ease of aiming jumps/tossed enemies a bit, which can be rather fatal for me, or less so for them, neither of which being desired.
Spoiler: *for reference (click to show/hide)
Post by: mifki on May 01, 2015, 05:37:27 am
Post by: Max™ on May 01, 2015, 10:39:37 am
Weird, TWBT_LEGACY doesn't give an error, just doesn't do anything different from normal 2D mode as far as I can tell.
Wait:
Code: [Select]
UNKNOWN CLASS 'ack21dfhack_lua_viewscreenE': vtable = 0xf7f66088Weird, like I said, it works just fine like it was 2D mode, so hey, failing gracefully to 2D mode beats the heck out of spewing garbled pixels and poofing I suppose.
Post by: lethosor on May 01, 2015, 01:49:17 pm
Post by: Dirst on May 01, 2015, 02:02:47 pm
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 :)
For a project that started off as not wanting zeros to look like coffins, this project has grown into something truly amazing... and it makes the game much more accessible to new players who aren't used to thinking in 2D slices of 3D spaces.
Post by: Max™ on May 01, 2015, 03:30:48 pm
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?
Post by: Grumalg on May 06, 2015, 08:06:47 pm
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?
Post by: mifki on May 06, 2015, 09:05:20 pm
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.
Post by: Grumalg on May 06, 2015, 09:46:32 pm
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.
Post by: mifki on May 06, 2015, 09:49:19 pm
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.
Oh, no, standard tileset can't be animated, it's only possible to animate grass.
Post by: Grumalg on May 06, 2015, 09:55:18 pm
Post by: Dirst on May 07, 2015, 10:20:08 am
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.
Bonus points if the waterwheel can have different animation sets based on the direction of flow.
Post by: PeridexisErrant on May 07, 2015, 10:30:16 am
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).
Post by: mifki on May 07, 2015, 05:15:50 pm
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.
New version uses a completely different approach, so game will not render items/buildings at all (those that are overridden).
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.
We're talking here about the next major version of twbt, which, of course will not replace the current stable version. Also, graphics code in DF doesn't change, so I don't expect any additional problems this time.
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).
The problem is not in merging (which I personally have nothing against), the problem is that additional reverse-engineering is required for each DF version. If anyone is willing to do that, they're welcome to, regardless of the location of the code. There's a step-by-step guide for finding required addresses in DF available for some time already.
Post by: lethosor on May 14, 2015, 08:01:11 am
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. <...>
Post by: Meph on May 16, 2015, 02:46:47 am
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. :)
Post by: mifki on May 16, 2015, 08:26:05 pm
Spoiler (click to show/hide)
Some tiles like bins and barrels will need to be adjusted, also not sure what happened to some floor tiles. But tables and chairs on the right and other furniture now all have different colours because they're made of different materials, and also copper/lead/zinc cages now seem to have more real-life colours.
Post by: Max™ on May 17, 2015, 12:27:45 am
Post by: mifki on May 17, 2015, 03:53:37 am
Post by: scamtank on May 17, 2015, 06:28:41 am
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.
Post by: Rose on May 17, 2015, 08:20:51 am
Post by: mifki on May 17, 2015, 06:35:55 pm
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.
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.
Post by: PeridexisErrant on May 17, 2015, 07:03:37 pm
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.
For all these reasons, I'd prefer to keep this off by default - it's also likely to make things more difficult for new players, by breaking the equivalence with so many screenshots.
Post by: DragonDePlatino on May 18, 2015, 12:07:14 am
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.
EDIT:
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.
Post by: mifki on May 18, 2015, 12:26:20 am
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.
As I said, it's already available in the latest TWBT build (from http://build.mifki.com), so you can try it out. It's not a special mode or something that needs to be enabled - you just specify bg/fg colour values >= 100 anywhere (either in raws or in runtime like the included realcolors.lua does, or in overrides.txt for overrides) and it will use colours from descriptor_color_standard.txt instead. And you can still have background colours. The problems we're talking about here are about automatically using material colours specified with colour tokens, and they don't apply if you're going to specify colours manually.
However what is the problem with colours and TWBT? The plugin shouldn't change any colours (unless told to).
EDIT: Back to the colour tokens, although it's a shame not to use the data already existing in raws, maybe it would be better to have a separate material/colour database that can be loaded independently of the raws, just like we have colors.txt for base colors. As Japa pointed out, I probably will write a script to load Stonesense colours in runtime, at least to see what happens.
Post by: mifki on May 18, 2015, 12:33:34 am
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 doubt anyone is using these values anywhere so it's quite possible they're swapped in dfhack and nobody noticed.
Post by: Max™ on May 18, 2015, 06:36:20 pm
Post by: mifki on May 18, 2015, 06:58:50 pm
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?
The original url is http://build.mifki.com, and that one is just where it redirected, until recently.
Post by: DragonDePlatino on May 18, 2015, 07:41:09 pm
Code: [Select]
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)
???And on another note, what is the purpose of the ANY_XXX IDs? I'm not sure where to fit those in.
Code: [Select]
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
Post by: mifki on May 18, 2015, 11:34:16 pm
ANY_* IDs I believe are exactly what their names suggest, but in general these are just all the values that exist in DF, they may or may not be useful for overrides.
Post by: Putnam on May 18, 2015, 11:57:05 pm
Post by: DragonDePlatino on May 19, 2015, 12:03:52 am
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.
Post by: Meph on May 19, 2015, 03:49:01 am
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.
Example:
Code: [Select]
[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]
Post by: DragonDePlatino on May 20, 2015, 10:35:12 am
(http://orig07.deviantart.net/a10f/f/2015/140/0/9/twbt_problem_by_dragondeplatino-d8u2n64.png)
If I try overriding something with a black foreground like a wooden barrel, it won't display properly. The gold/iron variants with yellow/gray foregrounds are displaying properly, but the wooden barrel is just a completely-black tile.
As a solution, what if TWBT automatically used the old background color for the foreground color if the old foreground color was black? TWBT can already do things like automatically remove background colors so I don't imagine this would be that difficult.
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.
And...noted! I really should have known this, considering that's where I got all of the subtypes from. ^^;
Post by: Button on May 20, 2015, 06:30:48 pm
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.
In case it's relevant, I usually play with 2/3 of the screen as screen, and the rightmost third as the command sidebar.
Post by: mifki on May 20, 2015, 06:36:56 pm
Post by: mifki on May 20, 2015, 06:37:45 pm
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.
You mean zooming to something/somebody? Sorry, no:(
Post by: DragonDePlatino on May 20, 2015, 07:10:15 pm
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.
A new update with easier overrides and better colors? Neat! And while we're at it, here's a suggestion...
Why not include a list of default values for the Tile parameter? Like, if you tried an override without a Tile parameter like [OVERRIDE::I:ANVIL:ANVIL::items:100] then TWBT would automatically try 229. This way, if a TWBT artist couldn't remember what a tile was or forgot the parameter, TWBT would do it's best to fix it. So far, I can confirm all of the following Tile values work in Vanilla DF:
Code: [Select]
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_MITTENSAlternately, you could just include this list once it's finished in the documentation. It'll save artists a lot of time. ;)
Post by: mifki on May 20, 2015, 07:51:39 pm
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.
Post by: DragonDePlatino on May 20, 2015, 08:14:09 pm
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.
Post by: mifki on May 20, 2015, 08:28:00 pm
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.
I didn't have the list before) Now I'll think about that.
Can't you just use some software that would extract separate tiles from your sheet?
The whole idea was to get rid of configuration files so that users can take any image from anywhere and of any size, drop it into a folder and it will just work. Especially handy for multitile workshops for which there will be a single image per building instead of configuring each tile. Also, there is support for animations, again you just include several frames in a tile image and no configuration necessary.
On the other hand, feedback from artists is also important, so I'm open for suggestions.
Post by: DragonDePlatino on May 20, 2015, 08:45:36 pm
1. If you decide you want to work in a size other than the default, you will have to go through each individual image and resize it. With sprite sheets, you can resize the image and it will update all of your sprites.
2. If you work with indexed color, you will manually have to go through thousands of images and apply your custom palette to each. With sprite sheets, you can update the palette of a single image and it will simultaneously update all of your sprites.
3. When you are open/saving files, you have to navigate to the file location for each file you want to find. With sprite sheets, everything is in the same file and you can see everything at a glance.
4. If you wish to use a resizing algorithm like hq2x or xBr to create higher resolutions for your graphics, you will have to go through each image and apply it. With a sprite sheet, you do one resizing operation and you're done.
With that being said, there could be a compromise. A long time ago, I did some graphical modding for UnNetHack (A NetHack mod). The vanilla game handles everything in a sprite sheet like this (http://nethackwiki.com/mediawiki/images/7/7c/Vanilla_tiles.png) but the modder designed UnNetHack to handle hundreds of separate image files. So I did pretty much what you said...I worked in a big sprite sheet, then wrote a Python script that dumped everything into separate images. For TWBT, there could be a sheet image in the uppermost directory and a small executable that splits the image into the files. The only problem with this approach, though, are the aforementioned animations. I'm not sure how those could be handled.
Alternately, I'd suggest an organizational approach like I did with DawnLike (http://opengameart.org/content/dawnlike-16x16-universal-rogue-like-tileset-v18), which had a huge number of animated sprites. Categorize all of the images into smaller sheets, and append a number onto the end of a filename if it's part of an animation. Some image-editing programs like ASEprite will even automatically turn that into an animated .GIF you can preview.
EDIT:
Oh! I've got an idea. For the first approach, you could have have a bunch of big sheets like Master0.png, Master1.png, Master2.png, etc. When you run the executable that splits the image up, it checks in Master1.png onwards if there are more frames for a tile. If the extra frames are transparent, the executable throws them out and snips the animation to a shorter number of frames.
(http://orig03.deviantart.net/cc3d/f/2015/140/3/3/twbt_example_by_dragondeplatino-d8u4y97.png)
Post by: mifki on May 20, 2015, 09:06:38 pm
I think it will be possible to support loading sprite sheets as well for those who want the. There will be a config file with mapping from names to coordinates.
Another thing, now there will be overrides not just for items/buildings but also for different states, like door, door-locked, well, well-dry, workshop/masons-working, workshop/masons-idle, etc. (each of them may or may not be animated). So we got rid of tile numbers, IDs and all that, and now there's just a list of identifiers for everything that can be overridden. And actually it's not a big difference whether to load images for this identifiers from corresponding files or from a sheet at given coords.
Post by: DragonDePlatino on May 20, 2015, 09:10:05 pm
The state overrides are also interesting. I haven't done any tile/building overrides yet so I'm not sure of the implications, but more flexibility is great.
Post by: mifki on May 20, 2015, 09:18:39 pm
Ahhh! So there's a configuration file that let's you specify the coordinates within an image and the image's location?
No, there's no at the moment, but will be if you and other artists need it.
Post by: The_Fool76 on May 20, 2015, 10:52:29 pm
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. 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. Mind you, in THIS community I suspect having to wrestle a config file might be considered a relaxing break from playing the game so that may be less of an issue.
Post by: mifki on May 20, 2015, 10:59:33 pm
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.
Post by: DragonDePlatino on May 20, 2015, 11:13:46 pm
This reminds me of when Minecraft switched from using a big texture sheet to individual files. I can absolutely say that working with multiple files VS one single one does slow down the workflow a bit. It also makes the task of making a new pack more intimidating to newcomers.
That said, I think having multiple files is ultimately the better way to go. It makes customizing the game a LOT easier for the end user.
I haven't played Minecraft in a while so I took the opportunity to check out one of these new-fangled "resource packs".
...Holy cow! 8o Texturing one of those looks like it'd be a nightmare! Sure, you've got all of those file names, but editing the big terrain.png was already hard enough. Minecraft's insanely popular compared to DF, though, so I wouldn't be surprised if there are tools to streamline the process. I can agree about the end user thing, though. When it comes down to it, the end users outnumber the artists by the thousands. :I
Anyway, I think it's decided now, it will use config file with identifiers to coords mapping and also look for individual files. Everyone will be happy.
Crikey! Do ya see it there? It's tha rare "internet agreement" in it's natural habitat!
...Joking aside, this is a very nice compromise. I wrote all of GemSet's raws from scratch so I wouldn't mind putting in a little extra work to get a nice setup.
Post by: mifki on May 20, 2015, 11:47:34 pm
Post by: PeridexisErrant on May 21, 2015, 05:00:49 am
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.
Post by: mifki on May 21, 2015, 05:08:51 am
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.
Post by: LeoCean on May 21, 2015, 08:51:36 am
Want one person's wall sprites an anther person's workshop sprites? Just copy the appropriate files over and go. With a sprite sheet they are stuck having to copy stuff using an image editor. Even a config file can be an issue as then they have to figure out how to properly merge the bits they want from one into the other.
Exactly this.
Anyway, I think it's decided now, it will use config file with identifiers to coords mapping and also look for individual files. Everyone will be happy.
Unless the overrides they are overriding have the same tilesheet name they wouldn't have to use a image editor if they are truely lazy. At that point the only copy and pasting is in the text file.. Anyways this is looking like it's going to be awesome, I haven't really been keeping up though.
Post by: DwarfCon5 on May 21, 2015, 12:14:43 pm
Post by: mifki on May 21, 2015, 05:16:53 pm
I don't get it. Are there any screenshots?
Spoiler (click to show/hide)
Post by: Dirst on May 21, 2015, 06:14:30 pm
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.
Post by: PeridexisErrant on May 21, 2015, 06:41:12 pm
The bits of the discussion you missed concerned getting the PyLNP mod manager to handle Stonesense content. Pretty much anything stored under raw/ can be handled with little or no effort for the starter-pack folks. It could be some dummy tag in the raws themselves, or more likely TWBT-specific files tucked under a subfolder.
The plan as I understand it is to check the data/art/ subdir for individual tiles, and if not found look for the data/art spritesheet and config file. Am I correct in this?
My proposal is to look for the file structure you've designed for data/art in the raws first (assuming first-on). Specifically, duplicate the logic and file structure for data/art/ in <savedir>/raw/twbt/, then the same in the main raw folder, then in data/art/, and finally the spritesheet in data/art/.
This means modded saves can overwrite particular sprites, saying "in this mod, <item> looks like <this> instead of the normal look". Storing data in the raw dir makes modded saves portable, enables conflicting mods in the same install, and a few other nice tricks. It's also easy for PyLNP and similar tools to handle - as long as files can be replaced atomically, which is the case for the new system (yes?) but not spritesheets. I thus suggest only allowing the new system in the raws.
Happy to discuss further, of course.
Post by: DragonDePlatino on May 22, 2015, 03:06:17 am
[OVERRIDE:7:I:BOULDER:BOULDER::items:28]
When I did that overwrite, it gave all of the dropped rocks (•) a tile. You'd think it would overwrite the big boulders (∞) but that's actually handled with the tile override StoneBoulder. Now it's time for me to do an override for ROCK and I have no idea what'll happen or what tile I'm looking for.
Post by: scamtank on May 22, 2015, 03:13:31 am
Post by: Max™ on May 22, 2015, 08:54:56 pm
Post by: DragonDePlatino on May 22, 2015, 09:45:23 pm
Post by: Max™ on May 22, 2015, 10:28:31 pm
Post by: DragonDePlatino on May 23, 2015, 01:04:55 am
Anyways, is it possible to overwrite PETs and VERMIN? I've been screwing around with overrrides like
[OVERRIDE:109:I:VERMIN:VERMIN::items:96]
[OVERRIDE:111:I:VERMIN:VERMIN::items:97]
[OVERRIDE:123:I:VERMIN:VERMIN::items:98]
[OVERRIDE:126:I:VERMIN:VERMIN::items:99]
[OVERRIDE:249:I:VERMIN:VERMIN::items:100]
And I can't seem to get it working. I've even tried a huge number of subtypes and nothing seems to work.
EDIT:
I've also discovered another interesting quirk. And unlike the glitchy material colors, I don't think the next release will address this.
(http://orig00.deviantart.net/9ad9/f/2015/143/0/5/twbt_siege_ammo_by_dragondeplatino-d8ueapw.png)
[OVERRIDE:17:I:SIEGEAMMO:SIEGEAMMO::items:129]
[OVERRIDE:196:I:SIEGEAMMO:SIEGEAMMO::items:130]
[OVERRIDE:174:I:SIEGEAMMO:SIEGEAMMO::items:131]
Siege ammo won't display properly! D: I'm positive that I'm targeting the right tiles, but I could only change the middle tile (the shaft). Does TWBT only target a single coordinate for each tile override? To get this working, I think you might need to check the tile left and right coordinates of an item if it is SIEGEAMMO.
Post by: mifki on May 23, 2015, 05:00:16 am
I've also discovered another interesting quirk. And unlike the glitchy material colors, I don't think the next release will address this.
The next release will definitely fix that because it uses a different approach to handle overrides. There's also a chance that I'll fix this before the next major release.
As for vermin, I don't remember all the details, but they're handled somehow completely different way in the game, so not affected by overrides. Eventually I'll look into this as well.
Post by: DragonDePlatino on May 23, 2015, 05:13:07 am
Code: [Select]
[CREATURE_GRAPHICS:WORM]
[DEFAULT:ANNELIDS:0:0:AS_IS:DEFAULT]Or would that not work because it would conflict with the existing tokens? You could try something like [TWBT_CREATURE_GRAPHICS] instead.
Post by: LeoCean on May 23, 2015, 08:36:05 am
It'd be nice if we could override creatures and get them animations though... Someday.. Especially when toady adds in multi tile creatures.
Post by: Meph on May 23, 2015, 11:02:51 am
Because a difference in male/female would be great, as well as castes like guilds, mages, etc.
Post by: Vattic on May 23, 2015, 01:40:53 pm
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?
Post by: DragonDePlatino on May 23, 2015, 02:10:29 pm
Post by: Klisz on May 23, 2015, 02:16:30 pm
Toady One? I assumed BOULDER and ROCK were names the DFHack developers gave to the memory values.
Nope, they're item types that can also be used in the raws for reactions (etc.) without DFHack.
Post by: Putnam on May 23, 2015, 02:17:33 pm
Post by: DragonDePlatino on May 23, 2015, 02:25:11 pm
EDIT:
Mifki, it seems I found another glitch? This might just be a normal part of gameplay, but I'll be reporting it just to be sure.
Spoiler (click to show/hide)
If you override several items of a single subtype, they won't display correctly if you stand in certain places. Here I've spawned all of the pants, but they only display correctly if I'm standing near the bottom. This glitch also happens if you spawn more items that use the same tiles. Shields might appear as pants if they're placed near them, for example.
Post by: Max™ on May 24, 2015, 05:18:11 pm
Post by: mifki on May 24, 2015, 07:22:03 pm
As for the next major release, for now I'm interested, what building states/flags you'd like to be able to provide custom images for.
For example, current list of what can be overridden is below (some buildings are just missing currently). Images for buildings or variable sizes (bridges, etc.) will be properly stretched and must contain parts for corners, edges and middle area.
Spoiler (click to show/hide)
Post by: Vanst7 on May 25, 2015, 12:01:31 am
[OVERRIDE:7:I:ROCK:ROCK::6:6]
Trying to overides mined stone but it doesnt seem to work. Anyone know what i'm doing wrong?
Post by: DragonDePlatino on May 25, 2015, 12:12:09 am
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.
Post by: Vanst7 on May 25, 2015, 12:18:44 am
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.
Oh, thats odd but it work perfectly, thanks.^^
Post by: DragonDePlatino on May 26, 2015, 09:42:35 pm
Spoiler (click to show/hide)
If you try overriding a tile, it will set the background to black regardless of what it was before. On the left is how soil looks in-game, and on the right is an edit I drew of how it should look. In both screenshots, the red tile is sandy clay loam and the yellow tile is yellow sand.
As a solution, I think there needs to be more override settings so the artist can fix this on a case by case basis. Here's my idea:
[OVERRIDE:Tile:Kind:Id:Type:Subtype:Tileset:NewTile:NewFg:NewBg:BgSwap]
The BgSwap parameter can have two settings. If you set BgSwap to 0, then TWBT will take the old BG and FG colors and use them for the override. If you set BgSwap to 1, then the BG and FG colors will be swapped for the override. You would set BgSwap to 1 for things like bins and barrels, which naturally have a black foreground and colored background. And for backwards-compatibility, if you do not specify a BgSwap parameter it will default to a value of 0.
Also, to keep things from being too complicated, the NewFg and NewBg parameters could be removed. I have done dozens of overrides but I have never used those parameters because if you set them, it will affect ALL of the possible colors of a tile. I could fix my soil problem by manually setting NewBg to something other than black, but that would affect the background color of all soils that use that tile. Again, for backwards-compatibility, if a NewFg and NewBg parameter are specified, TWBT would ignore them.
Post by: mifki on May 26, 2015, 11:20:18 pm
I just want to separate possible TWBT issues and DF specifics, like that for some items it uses bg/fg colours and for some only one colour, for unknown reason.
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.
Post by: DragonDePlatino on May 26, 2015, 11:54:24 pm
Spoiler (click to show/hide)
It seems to work just fine now. However, I still want to use overrides because glaciers, smoke and the minimap look like soil now. DX
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.
Post by: mifki on May 27, 2015, 12:42:08 am
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.
The game will mix you image colours with tile foreground colour and if you want your colours to stay as-is, you have to have white fg colour. If your tile image is complex and colourful, you'd want to sacrifice material colour information because mixed with non-white fg colour it would look like shit (or just too dark for some materials).
Post by: DragonDePlatino on May 29, 2015, 08:00:38 pm
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?
Post by: mifki on May 31, 2015, 10:39:29 am
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?
Hm, I thought it was clear that this is one of the main features of the next version.
Post by: sic8 on May 31, 2015, 07:05:48 pm
Has yourself or anyone figured out how to get transparency in? Is it possible? Would certainly look stunning with the new tilesets.
Post by: DragonDePlatino on May 31, 2015, 07:23:34 pm
I'm afraid I haven't figured out how to create alpha-transparent layers, though. When TWBT is doing multilayer rendering, I believe it takes the topmost tile of a coordinate and renders that. Alpha transparency would be pretty cool for things like smoke, though.
Post by: sic8 on May 31, 2015, 08:39:25 pm
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.
Post by: Max™ on May 31, 2015, 09:32:16 pm
Post by: DragonDePlatino on May 31, 2015, 10:15:46 pm
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.
That would change everything! You'd always be able to see what's under someone's feet! Tileset artists wouldn't have to put textures under their sprites! You could use any graphics you want for the floors without worrying about attribute clash (a.k.a big annoying squares)! IMO that would be a game-changer, even bigger than something like multilevel rendering.
But alas, it would render most older tilesets incompatible and wouldn't really work with ASCII graphics. I'd certainly be interested in seeing that once the building overrides and bugfixes are complete, though.
Post by: Klisz on May 31, 2015, 11:23:25 pm
But alas, it would render most older tilesets incompatible and wouldn't really work with ASCII graphics.
It could be optional.
Post by: DragonDePlatino on June 01, 2015, 03:42:44 pm
Post by: mifki on June 02, 2015, 06:17:39 pm
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.
Post by: DragonDePlatino on June 02, 2015, 06:38:12 pm
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.
But DragonDePlatino, your tileset has black background anyway, why are you so excited about transparency?
My graphics set has a black background because DF does not have proper transparency support. :)
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.
I completely understand. Expanding the DF audience to mobile is a much bigger priority than marginal graphical improvements.
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.
Post by: PeridexisErrant on June 02, 2015, 07:14:39 pm
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.
It's not just mobile though - the server can also be used as the backend for entire UI replacements on the desktop. As an example, this could eventually allow the entire game to be played through Armok Vision!
Post by: mifki on June 02, 2015, 08:05:07 pm
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.
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?
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.
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.
Post by: Meph on June 02, 2015, 10:13:15 pm
For example you make a bucket, background of the bucket is transparent, but slightly darker where the shadow of the bucket falls.
Post by: DragonDePlatino on June 02, 2015, 10:20:37 pm
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.
(http://orig14.deviantart.net/06d5/f/2015/153/c/6/transparency_barrel_2_by_dragondeplatino-d8vt15w.png)
That, or we could just ditch the background color entirely like you said.
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.
Let's see here.....Yup. There are about 455 instances of [GROWTH:PRINT] in the vanilla raws, so it would be impossible to fit everything in one tileset. Another idea would be to have a new set of overrides. You could specify a plant override like this:
[OVERRIDE:P:Plant:Subtype:Tileset:NewTile]
Plant would be something like ARTICHOKE and the subtypes would be the growths (in order). If you want to override a growth on the plant, you would just give a number. If you wanted to override a picked growth, you would add 100 to that number. So to override the picked flowers of an artichoke, you would try:
[OVERRIDE:P:ARTICHOKE:102:Tileset:NewTile]
If you leave the Subtype parameter blank it would override the [PICKED_TILE], how the plant looks if there are no visible growths on it.
Post by: mifki on June 02, 2015, 10:40:10 pm
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.
Ok, I'll try to make a test implementation of this, add transparency to some tileset (Spacefox since I use it myself) and we'll see how it looks.
Post by: Dirst on June 03, 2015, 05:18:51 am
Right now, is the fg color mixed into the whole image, or just in areas where the red, green and blue values are equal (ie, grayscale)? If the fg is mixed into everything, it may be necessary to ditch bg colors entirely or use a completely different tile set as a mask. If the fg is just mapped into x:x:x pixels, then the background can be mapped into x:0:x pixels. An artist who wants to use purple just needs to include at least a smidge of green in it.
Post by: Dirst on June 04, 2015, 07:34:01 pm
Post by: mifki on June 04, 2015, 08:51:55 pm
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? They were useful when we had 16 colours only and limited number of tiles, so we could employ tile magic to use the same tile for different objects/materials and so on. But now that we can have as many tiles and colours as we want (and use different tiles for different "material types" like constructed wall/soil wall/stone wall/...), maybe one colour will suffice?
On the other hand, the configuration is getting too complicated now anyway (look at the number of overrides in the new GemSet). So I'm thinking about a GUI where you could easily assign images to all available game features with preview, not caring about whether it will internally be tiletype override, item/building override, or will require changing tile numbers in raws. In this case, it could have a way to assign several images and stack them as you're suggesting. It would be not as terrible as if you had to configure such stacks in config files, that's what I'm saying.
Post by: DragonDePlatino on June 04, 2015, 10:02:54 pm
The question is, do we really need both background and foreground colours?
I vote to remove the background colors and simplify things for artists. Like you said, background colors are only useful from an ASCII perspective because they let you include more information in a tile. With SDL graphics and multi-colored tiles, background colors are not needed. I never used them, and sometimes disabled them entirely to make things visually cleaner (e.g. GemSet's rails). If anything, they keep graphics from being WYSIWYG and introduce more technical hurdles for artists (Huh, I drew a barrel but it's invisible in-game?!?)
Also, I think a GUI would be great. Have a little program for artists that lets them organize all of their graphics and see what they have drawn at a glance. There could be a file menu on the left and a bunch of image previews on the right. You know, like the BYOND Dream Editor (http://www.byond.com/docs/whitepaper/icon-editor-1.png). I don't even care if each image only has a single tile. It would be much simpler than the current system we have.
Post by: Antsan on June 05, 2015, 10:07:31 am
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.
Post by: scamtank on June 05, 2015, 11:01:00 am
It's a bother. Could it be fixed or, seeing it's not really vital, just disabled?
Post by: Meph on June 05, 2015, 12:09:30 pm
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.
Post by: DragonDePlatino on June 05, 2015, 12:51:58 pm
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.
Yes, but if transparency were added to sprites right after background colors were removed, it would result in little information loss. Take underwater creatures, for example. They have a blue background to communicate that they're in the water, but if they could be overlaid over a water tile with transparency, that would not be an issue.
(http://orig07.deviantart.net/9825/f/2015/156/f/7/twbt_background_transparency_by_dragondeplatino-d8w41ej.png)
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?
I've never experienced that issue but it sounds like it would be incredibly aggravating. Taking the X from the from the map tileset could be a problem, though, because some TWBT tilesets might use that. It would be nice if the mouse.png could be used for your cursor.
Post by: Button on June 05, 2015, 02:47:24 pm
It's keeping me from switching over to GemSet :(
Post by: Max™ on June 05, 2015, 03:33:27 pm
I'd love if the one that causes this was gone because I could use the gemset 48 without it happening:
Spoiler (click to show/hide)
Post by: scamtank on June 05, 2015, 03:35:57 pm
Post by: Max™ on June 05, 2015, 03:49:25 pm
Post by: Button on June 05, 2015, 03:58:55 pm
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.
Post by: falcn on June 05, 2015, 04:23:25 pm
Possibility to have readable font was the strongest point of TWBT for me (thank you mifki!)
http://imgur.com/xHZCEwO
Post by: Max™ on June 05, 2015, 06:57:24 pm
Post by: mifki on June 06, 2015, 06:10:09 am
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.
I don't know. Need to check all cases where background matters.
Post by: mifki on June 06, 2015, 06:11:35 am
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.
Post by: mifki on June 06, 2015, 06:12:55 am
(http://i.imgur.com/0jkPPiv.png)
(http://i.imgur.com/9a0AO0D.png)
Post by: Max™ on June 06, 2015, 06:39:36 am
Yes?
Post by: mifki on June 06, 2015, 08:09:06 am
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.
Post by: scamtank on June 06, 2015, 08:15:34 am
Are you sure you're using plugins (mousequery and couple others) provided with TWBT? That's exactly what they fix.
Yeah, I th
Actually, I just remembered that I overwrote it all with a recent DFhack compile. Carry on!
Post by: Meph on June 06, 2015, 11:52:32 am
And more importantly: Can this be used on creatures?
Post by: DragonDePlatino on June 06, 2015, 12:54:46 pm
Post by: Button on June 06, 2015, 05:03:29 pm
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.
<3
Post by: sic8 on June 06, 2015, 08:07:56 pm
I think the proper term here is: Oh, shit.
Yes?
Yep. Oh shit! This is great mifki. You have fixed my biggest peeve with DF gfx. Thank you!
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?
Post by: sic8 on June 06, 2015, 08:15:57 pm
Post by: scamtank on June 06, 2015, 08:22:12 pm
Post by: Antsan on June 07, 2015, 06:16:06 am
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.
Post by: mifki on June 07, 2015, 07:21:36 am
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 ?
Post by: falcn on June 07, 2015, 10:35:37 am
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.
Post by: ArmokGoB on June 08, 2015, 02:33:16 pm
Post by: DragonDePlatino on June 08, 2015, 03:08:33 pm
(It would be awesome if we could have separate text, map and worldgen tilesets BTW)
Post by: ArmokGoB on June 08, 2015, 03:21:52 pm
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)
Post by: Max™ on June 08, 2015, 07:10:15 pm
To test it try to travel out in the middle of nowhere, I'm pretty sure you'll be able to start and stop all day long, but if you go into a town and try to travel out it will probably crash you.
Post by: mifki on June 08, 2015, 09:32:46 pm
Spoiler (click to show/hide)
It works quite well for me, but I'll try on Windows later.
Post by: mifki on June 08, 2015, 09:37:52 pm
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.
Post by: sic8 on June 08, 2015, 10:11:40 pm
I was thinking about this long time ago, technically it's possible, maybe I'll try and add it as an option.
It would break up the monotony of 'square everything' for sure. Oversize creatures would be neat
Post by: ArmokGoB on June 08, 2015, 10:27:38 pm
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.
Post by: Meph on June 09, 2015, 01:01:15 am
+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.
Post by: Max™ on June 09, 2015, 03:43:44 am
Spoiler (click to show/hide)
On this screen:
Spoiler (click to show/hide)
If I enter and exit travel mode (typed crash mode, hah!) without moving and then travel it can work more reliably, but it pretty consistently seems to be from the zoomed in city/site map.
Ok, I'm pretty sure that the update from 5.45 to 5.47 did something because with 5.47 I can't even travel in the middle of nowhere.
Super special edit: ok, after checking both it looks like if I rest the first time I travel for at least 2 hours after that I can travel pretty safely.
Post by: mifki on June 09, 2015, 04:17:29 am
Post by: Max™ on June 09, 2015, 04:36:36 am
If I rest for an hour it starts to load the progress bar and then poops it's brains out.
If I rest for two or four or eight or whatever it does the usual progress bar/time change stuff.
If I jump into travel mode fresh off a loaded save it crashes pretty regularly, if I rest for an hour fresh off a loaded save it crashes pretty regularly, if I rest for two or four hours I can generally travel around safely until I get to a town, and then the second ro third time I try to enter the travel map I crash.
Post by: mifki on July 27, 2015, 09:44:43 pm
Most important, it will allow to effectively (from performance point of view) override everything. By everything I mean, in addition to tiletypes, items and buildings, it will be possible to specify different images for all unmined materials, gems, plants, growths, dead creatures, etc. - things that can have tile number/color changed in raws will not be limited to 256 base tiles.
No raw changes will be needed, the plugin will make the required modifications in memory.
Basic mode of operation will be based on folders/files structure named after raw IDs and other identifiers (plus suffixes for different states/flags), eg.
Code: [Select]
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
Also, there will be optional config file that will allow to "redirect" these pathnames to tiles in a sprite sheet, and additionally specify some options, for example colour mode (use bg/fg material colors, use fg colour only, use image as is) and transparency of tiles in workshops. Like this,
Code: [Select]
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/=.=/=.=]
The bad news is that I don't know when I will have time to work on this...
Post by: lethosor on July 27, 2015, 09:50:09 pm
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.
Post by: mifki on July 27, 2015, 10:00:24 pm
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.
It's not that I don't want it to be unloaded, for some reason last time I tried I just could not clean everything up so that it doesn't crash after unload, so instead I prevent it from being unloaded :)
But thanks, I'll try this method.
Post by: PeridexisErrant on July 27, 2015, 11:13:02 pm
I have good understanding what I want to do in the next version and how it all will be configured.
Sounds great! Re: timing - I think everyone is willing to wait! Releasing before the next big DF release cycle would allow people to get familiar before the big rush (eg DFHack 34.11-r5), but it's not a problem either way. ;D
Will these files be stored in the raw folder? If so, upgrading PyLNP to handle it all will be
Post by: Deon on August 23, 2015, 12:38:46 pm
Can you tell me, what is a tile type override for sand floor/walls/ramps/stairs?
(http://i.imgur.com/pw2q30c.png)
Also the 2nd arrow on that screenshot points to a grass-looking tile on loam. It's actually all loam, and when I move the screen, the "grass" tile becomes normal ground tile. Anyone else getting this visual bug?
Post by: DragonDePlatino on August 23, 2015, 05:02:09 pm
Code: [Select]
[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]
But if they have varied tiles turned off, then its...
Code: [Select]
[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]
And here's everything else having to do with soil:
Code: [Select]
[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]
One thing to note here is that these are GemSet overrides, and I edited my soil raws to have different tiles. I'm also a little out of the loop as far as TWBT goes, so this system might not work anymore. And yes, scrolling tiles not updating is a current bug that mifki is aware of.
Post by: Deon on August 26, 2015, 08:44:50 pm
Post by: Meph on August 29, 2015, 03:04:25 pm
Post by: Deon on August 31, 2015, 10:56:51 am
Post by: Boltgun on September 01, 2015, 03:50:31 am
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.
I'll be making sprites till the end of time, that would be awesome.
Post by: Meph on September 01, 2015, 04:51:36 am
Post by: Pvt. Pirate on September 08, 2015, 01:11:47 am
Post by: mifki on September 08, 2015, 01:57:46 am
can this be the cause of some crashes? i'm playing with the winLNP.
Yes, please do tell us when and how that happens.
Post by: Pvt. Pirate on September 08, 2015, 04:41:26 am
i have no clue what are known crashes caused by twbt.
if you want, i can upload the small world and savegame.
i wish there were an autosave setting to save each month instead of each season...
Post by: PeridexisErrant on September 08, 2015, 05:57:55 am
so far i haven't found out why exactly it happens, but it was soon after the beginning of summer year 5...
There's a decent chance that the culprit is plants growing into the space occupied by constructed walls (or other constructions) - check outdoors and in the caverns. This is a vanilla DF bug, BTW.
Post by: Pvt. Pirate on September 08, 2015, 06:51:11 am
Post by: Dirst on September 08, 2015, 09:04:32 am
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.
Post by: jaked122 on October 03, 2015, 09:23:04 pm
Code: [Select]
plant exterpate all
Post by: easykiln on October 04, 2015, 07:54:46 pm
Post by: meanjeans on October 11, 2015, 04:55:45 pm
Thanks!
Post by: Shonai_Dweller on October 11, 2015, 06:24:33 pm
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.
Post by: LeoCean on October 11, 2015, 10:45:18 pm
The Tilesets and Graphics section would be what you would be looking for if you wanted to see which tilesets make use of twbt. But the Starter pack would be the easiest way to play with it as it's already preinstalled and has many tilesets already. http://www.bay12forums.com/smf/index.php?topic=126076.0
Post by: Infinite Monkeys on October 13, 2015, 07:14:42 am
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 :)
Post by: mifki on October 13, 2015, 07:18:54 am
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 :)
https://github.com/mifki/df-twbt#multi-level-rendering
You can try "multilevel fogdensity 0.20" or 0.30 and so on, or play with other parameters.
Post by: meanjeans on October 13, 2015, 11:40:53 am
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.
Post by: BadLeo on October 18, 2015, 07:30:14 am
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.
Post by: mifki on October 22, 2015, 07:08:37 pm
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.
There are known issues with TWBT and custom dfhack screens, I'll check the workflow screen specifically.
Post by: TheBloke on October 30, 2015, 07:07:06 am
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 am using TWBT 5.45, with DFHack 40.24-r3, and I use many/most plugins including mousequery.
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.
I thought the reason was mousequery track. What I think happens is:
- DF zooms to the target unit/building
- After the zoom is completed, mousequery reads the mouse cursor position
- mousequery sets the active tile to be the current mouse position
- This moves away from the zoom location - so I am on the right Z level for the target, but never the right tile
At first I used to disable the whole mousequery plugin before zooming. But in my recent testing I have narrowed it down to being mousequery track specifically.
So now I bind these two hotkeys:
keybinding add Ctrl-Shift-B "mousequery track disable"
keybinding add Ctrl-Shift-M "mousequery track enable"
And any time I want to zoom I hit Ctrl-Shift-B, and when I am done I hit Ctrl-Shift-M.
it is a bit annoying, but at least I can use zooming and still have general mouse control!
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?
If I get this fix added to my TWBT, will I not have to disable mousequery any more? I have looked at the code in the commit but I don't really know anything about DF/DFHack so I don't really know what it's doing or what it fixes exactly. Maybe it's something completely unrelated to what I described above?
Though if it's not related to mousequery, my next question would be: what does it fix? Because when I disable mousequery, zooming seems to work just fine, every time?
Thanks in advance, and again for TWBT!
Post by: PeridexisErrant on November 01, 2015, 04:21:12 am
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.
Post by: mifki on November 01, 2015, 06:55:03 am
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 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.
Post by: scamtank on November 01, 2015, 10:30:54 am
Post by: lethosor on November 01, 2015, 11:16:47 am
Post by: TheBloke on November 01, 2015, 04:00:29 pm
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?
Short answer: Yes, this is exactly what this fix is for, and now that I have applied 5.47 zooming works properly with mousequery. Awesome, thanks mifki. I am very happy not to have to use hotkeys to disable/re-enable mousequery for every zoom I do!
Long answer: My original question was based on my failing to understand that mousequery is also written by mifki :) I thought it was part of DFHack, and that mouse-menu was the non-DFHack mouse plugin. Of course, both are.
So yes it was mousequery that was breaking zooming and the fix to it was for mousequery itself, which I had not noticed was actually part of/included with TWBT.
Got it now :) Thanks for the fix, mifki.
PeridexisErrant: In my opinion the fix to unit/building zooming makes it extremely worthwhile to include 5.47 in your pack. The broken zooming has bugged me since I started playing, to the point where I assigned shortcut keys to disable and re-enable part of mousequery which I ran before and after every zoom. Because I wanted to give up neither mousequery nor zooming, and thought that was the only way to fix it.
Post by: lethosor on November 01, 2015, 04:11:41 pm
Post by: TheBloke on November 01, 2015, 04:20:01 pm
Post by: mifki on November 01, 2015, 05:39:19 pm
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).
Don't undestand about additional version information.
Well, not that I'm encouraging people - in the time of active development I've configured the build server to help myself making binaries for three platforms, and people who followed the development knew where to get the latest version, this never was a problem. Honestly, I thought pack authors were taking latest builds too.
Post by: lethosor on November 01, 2015, 05:47:47 pm
Post by: mifki on November 01, 2015, 05:51:44 pm
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).
No, it increments version each build and github releases are published from the build server as well, so all version numbers should be unique.
Post by: PeridexisErrant on November 01, 2015, 05:57:17 pm
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.
Post by: mifki on November 01, 2015, 06:13:19 pm
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.
Post by: Meph on November 02, 2015, 01:39:44 pm
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.
Spoiler (click to show/hide)
Mifki, any update on caste-specific creature graphics? ^^
Post by: PeridexisErrant on November 08, 2015, 04:17:37 pm
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.
Post by: mifki on November 08, 2015, 04:33:13 pm
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).
Post by: PeridexisErrant on November 08, 2015, 04:37:20 pm
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.
DFHack r4 has been tagged and the binaries should be uploaded soon, so maybe a build for that?
Post by: mifki on November 08, 2015, 04:46:24 pm
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?
It's not that simple, as far as I remember the slowdown was quite significant if there's a lot of item overrides on screen (large stockpile) and you're just moving the cursor so most of the tiles don't change.
Cool, I'll make a build for r4 tonight or tomorrow.
Post by: mifki on November 12, 2015, 04:54:04 am
Also, I haven't updated the bundled plugins yet to include the latest changes form dfhack repo, if any.
Post by: PeridexisErrant on November 12, 2015, 05:08:32 am
There's a small change to automaterial to disallow constructing over constructions, but otherwise nothing substantial.
Post by: lethosor on November 12, 2015, 07:45:21 pm
Post by: Warmist on November 13, 2015, 02:14:32 am
Post by: mifki on November 13, 2015, 03:08:52 am
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?
No. We've discussed this with lethosor some time ago and more or less agreed what to do, but I haven't, my bad.
Post by: PeridexisErrant on November 13, 2015, 04:36:50 am
Post by: lethosor on November 13, 2015, 06:51:48 am
Post by: Warmist on November 13, 2015, 09:37:53 am
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
Although it could be extended so we could have more things like this (however unlikely).
Post by: lethosor on November 13, 2015, 08:28:38 pm
Anyway, here (https://github.com/DFHack/dfhack/pull/746) is some initial support for hooks. They're somewhat similar to vmethod hooks (and are uninstalled automatically when a plugin is unloaded if they're set up correctly). It only supports paintTile()/paintString() and related functions, but I didn't notice a significant performance difference even with my example plugin enabled, so supporting the other functions that TwbT needs to hook into shouldn't be hard.
Post by: ORCACommander on November 22, 2015, 10:01:42 am
Post by: lethosor on November 22, 2015, 12:25:08 pm
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.
Post by: mifki on November 22, 2015, 04:01:07 pm
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.
He's probably talking about the world map during embark.
Post by: PeridexisErrant on November 22, 2015, 11:54:34 pm
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.
Post by: mifki on November 23, 2015, 04:52:13 am
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.
Done.
Post by: TheBloke on December 12, 2015, 01:34:36 am
Two things:
First, thanks so much for adding redraw_all. Not sure when you added it but I only noticed it recently, and it has enabled me to use the latest Spacefox additions from LeoCaen, without 'bleeding' tiles all over the place. And I can't notice any significant slowdown at all. Very nice!
Secondly, what are your plans regarding TWBT update for v42? DFHack has now reached pre-release version v42.02-r0, and is fairly functional against DF v42.02.
Tonight I have updated TWBT patches.hpp for OSX and done a first compile of OSX TWBT for v42.02 and it seems to be working pretty well:
Spoiler (click to show/hide)
Currently it only supports fortress mode, due to some compilation errors relating to missing struct members in DFHack's viewscreens for adventure mode. I am guessing this is because DFHack's adventure mode support is not yet complete for v42 in the pre-release builds:
Spoiler: Compile errors I get relating to df::viewscreen_setupadventurest (click to show/hide)
In order to get a working build, I simply edited legacy/renderer_legacy.hpp and tileupdate_text.hpp and removed the conditional block if (IS_SCREEN(viewscreen_setupadventurest)). So this will totally break Adventure Mode I am sure, but it allows it to compile and it seems to work well in Fortress.
I am guessing this is an issue in the latest DFHack, missing some Adventure mode viewscreen methods that used to be there? Or perhaps they have been renamed, I have not yet checked.
Anyway, apart from that the resulting build appears to work well in fortress. I haven't yet tested the TWBT versions of automaterial, mousequery, etc, but don't anticipate any problems with those.
Tomorrow we're expecting/hoping v42.03 to come out so my plan was to wait until that comes out and then update patches.hpp again for 42.03, and then send you a pull request to your Github. I figure there's no point supporting v42.02 if .03 is very soon out, and Toady has indicated that it may well come tomorrow. (I don't know how long it will take DFHack to update to -03, but I figure it should probably be quick, and anyway is probably not a dependency on finishing the TWBT patches.hpp changes.)
Also I plan to do the Patches updates also for Linux, and hopefully Windows too. So I will try and submit them all to you at the same time. I also thought I might submit to you a quick little build script to make compilation a bit easier (I had to make a few edits to the Makefile which could be handled easier in a build script, like I am also working on for DFhack itself.)
Do you think you would then do a pre-release TWBT binary release? Or do you want to wait until DFHack is on a stable release and the Adventure mode issue is fixed?
Let me know your thoughts.
PS. Thanks so much for the documentation in Patches.md. Once I started to understand a bit about Hopper, it was very straightforward to follow your excellent instructions. I could not have done anything without that.
Post by: mifki on December 13, 2015, 03:36:55 pm
I will release a build for v42 if people think it's playable/stable enough already. It's just too much for me to patch/test for 3 platforms for each minor DF version.
Post by: TheBloke on December 13, 2015, 03:50:05 pm
I guess we will see how DFHack goes. Right now DFHack is kinda-sorta usable in 42.02 - some useful things work, many useful things don't work. And there may be random crashes.
But 42.02 itself has quite a lot of bugs, and 42.03 fixes a lot of these and so is much preferable for users.
The DFHack core guys have decided to delay updating for 42.03 until they have finished (or close to finished) for 42.02, so that they can see what changes from 02->03. I don't know how long that will take but I'm hoping a matter of a couple of days sort of timescale.
So we can't do finish TWBT for 42.03 yet until symbols.xml is updated for .03, and I don't think there's any point doing it for 42.02 because even though it has half-working DFHack, it also has a lot of DF bugs.
If 42.03 becomes working in DFHack soon (at least as well as it now works in 42.02) then I'm happy to do the three TWBT updates myself. I have already done the process once for OSX, and I started it for Windows just so I could check that I could do it. Not tried Linux yet but that looks like the easiest one. And I really like that Hopper on OSX can open the Windows, OSX and Linux executables, so I don't even need to use my Windows and Linux VMs except for testing at the end.
So yeah let's see what happens for 42.03 and if it is ready soon, I would like to do the patches and save you the work :)
Post by: RadGH on December 13, 2015, 04:21:48 pm
If we had to pick between 42.02 and waiting a bit longer for 42.03, you should go with 03!
If .04 came out tomorrow, I would be satisfied with .03 for awhile.
Post by: mifki on December 13, 2015, 04:24:40 pm
Post by: lethosor on December 13, 2015, 04:44:15 pm
Post by: TheBloke on December 13, 2015, 08:50:01 pm
So I think I don't need to wait for DFHack 42.03. I will have a go tomorrow at completing patches.hpp so we're ahead of the game and ready to go the minute DFHack is ready. (Won't be able to actually test it until DFHack is ready, of course.)
It's not hard: I looked up viewscreen_dwarfmodest and dungeonmodest in the 42.02 symbols.xml, found the third DWord to give me render(), and went to that address in both 42.02 and 42.03 executables. Then I just scrolled down in the 42.03 code until I found a procedure that looked (nearly) identical to the 42.02 version and was clearly the same procedure, offset. The offset for dwarfmodest's render() was +ca0 and for dungeonmodest it was +d00. So not too far to look (shame it wasn't the same though.) That gave me A_RENDER_MAP and pretty soon should give me A_RENDER_UPDOWN and I can use the same principle for the rest of patches.hpp I hope. I will look in more detail tomorrow.
Post by: Dibuk on December 26, 2015, 05:03:02 am
Post by: PeridexisErrant on December 26, 2015, 05:21:08 am
DFhack is out now. Does this need an update too?
Yes, but it'll probably be a while.
Post by: scenegg on December 26, 2015, 05:37:20 am
DFhack is out now. Does this need an update too?
Yes, but it'll probably be a while.
Gotta love TWBT. TheBloke said it will be either today or tomorrow.
Post by: TheBloke on December 26, 2015, 05:49:56 am
And to be clear, anything I put up is an unofficial release, and also it will almost certainly not work in adventure more due to a minor code re-write needed in that part for 42.03. mifki will need to look at that when he is available to do so.
But fort mode should work OK I hope.
Will update later when I can.
Post by: mifki on December 26, 2015, 05:58:39 am
Post by: Dibuk on December 26, 2015, 06:07:57 am
Post by: scamtank on December 26, 2015, 06:41:23 am
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)
Post by: PeridexisErrant on December 26, 2015, 07:06:52 am
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)
Amen, amen.
Post by: mifki on December 26, 2015, 05:14:51 pm
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.
Post by: Meph on December 27, 2015, 02:08:26 pm
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.
Post by: TheBloke on December 27, 2015, 09:15:47 pm
I've got OSX done and tested OK (including a quick test of adventurer mode, which mifki fixed last night), and am moving on to Windows next, with Linux last.
I will put some (unofficial) builds up in the next few hours.
So hopefully mifki won't have to do all updates from now on :)
Post by: mifki on December 28, 2015, 07:03:03 am
Post by: Herbalist on December 28, 2015, 09:41:55 pm
Post by: milo christiansen on December 30, 2015, 12:31:46 pm
Post by: Max™ on December 31, 2015, 12:48:27 am
Code: [Select]
[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]#
Post by: mifki on December 31, 2015, 01:38:17 am
Post by: Max™ on December 31, 2015, 02:14:41 am
Note that I think that is the right term but I am not 100% certain, I run ./dfhack from the terminal like usual and it just spits out the first part from code box above, the gtk-message:failed to load/loading bindings, and then nothing happens. No dwarf fortress process, no stderr, no errorlog, nothing in stdout, just splut, gone, if I use [PRINT_MODE:TWBT/TWBT_LEGACY/STANDARD] but 2D works and gives the "set print_mode" message.
Post by: mifki on December 31, 2015, 02:24:20 am
Same silent crash as twbt/twbt_legacy.
Then it's not twbt. Check your opengl drivers. Are you on Arch? There is a discussion about the same issue on Github in twbt repo.
Post by: Max™ on December 31, 2015, 03:09:50 am
Bleh, if I get rid of the libs in the folder like it says there then I get the .png not found errors.
Post by: forsaken1111 on January 03, 2016, 06:24:32 pm
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
Post by: Max™ on January 03, 2016, 07:05:20 pm
Post by: gasznak on January 10, 2016, 09:10:40 am
Post by: figment on January 10, 2016, 12:11:13 pm
Here is what I used for Windows in any case if that helps speed up testing.
Spoiler (click to show/hide)
Post by: PeridexisErrant on January 10, 2016, 05:08:51 pm
Any update for 42.04? :<
I would also love a windows build for DFHack 42.04 alpha2
Post by: figment on January 10, 2016, 06:15:02 pm
Spoiler (click to show/hide)
Post by: mifki on January 10, 2016, 06:44:50 pm
I believe when updating for a new DF version it either works (including multilevel rendering) or crashes straight away if some addresses are wrong, so no need to worry that much about proper functioning.
Post by: kikoman on January 12, 2016, 04:59:53 am
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)
Great work figment. It's working nicely on my 0.42.04 install. Thanks :)
Post by: utkonos on January 12, 2016, 08:13:16 pm
Post by: Rydel on January 12, 2016, 11:52:16 pm
Post by: nefariousD on January 13, 2016, 08:36:59 am
Post by: funkydwarf on January 13, 2016, 11:25:05 am
Just a standard hex editor to find the strings? Any recomendations for debian linux?
Id it just patches.mpp? doea the other patches.whatever file need it?
Little over my head but i feel this is a good next step after learning to compile, if someone could just help me with this little bit of info i will be off and running on my own again. Thanks!
Post by: mifki on January 13, 2016, 04:00:57 pm
Post by: topis on January 13, 2016, 04:20:19 pm
Code: [Select]
#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 }
};
Post by: funkydwarf on January 13, 2016, 07:28:03 pm
Ok off to the cave with hopper...
Thanks Topis! And of course mifki!
edit: apparently I saw and read something near the offsets, and now just found the further instructs about hopper and feel dumb
Post by: mifki on January 13, 2016, 07:41:05 pm
Post by: funkydwarf on January 13, 2016, 07:57:40 pm
Seems like a crazy cool tool though...and seems like its near magic and should be 10x its price. Under a hundred bucks for 3 licenses, holy cow!
Post by: Max™ on January 13, 2016, 11:43:12 pm
Post by: funkydwarf on January 14, 2016, 12:04:27 pm
Post by: HellishINC on January 15, 2016, 06:56:34 am
42.04 linux offsets below, seem to be working.Code: [Select]-snip-
How would one go about using this? I'm guessing you need to compile twbt yourself? I've never managed to build it myself.
Post by: mifki on January 15, 2016, 08:49:28 am
Post by: fricy on January 15, 2016, 10:27:58 am
Version 5.55 released with support for 0.42.04. Thanks to all contributors.Thank you.
Post by: funkydwarf on January 15, 2016, 06:18:09 pm
Post by: Rydel on January 15, 2016, 07:28:33 pm
Post by: lethosor on January 15, 2016, 07:53:34 pm
Post by: Rydel on January 16, 2016, 12:34:52 pm
EDIT:
How do I override tile in the Soap Maker? [OVERRIDE:<tile>:B:SOAP_MAKER:Workshop::<tileset>:<tilenum>] is giving an "invalid override specification" error.
Post by: figment on January 20, 2016, 02:28:45 am
Windows offsets that I found:
Spoiler (click to show/hide)
My current windows build. Same use at your own risk as last time.
Spoiler (click to show/hide)
Post by: scamtank on January 20, 2016, 04:45:24 am
Post by: topis on January 20, 2016, 08:57:32 am
Code: [Select]
#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 }
};
Post by: PeridexisErrant on January 20, 2016, 09:13:20 am
Post by: Kazimuth on January 21, 2016, 12:38:52 am
When I fullscreen from the main menu, sometimes it crashes, and sometimes it just doesn't work:
(warning: enormous image)
Spoiler (click to show/hide)
It should fill the entire screen, but instead the titlebar is still visible and there's arbitrary whitespace in the background. It also leaves a couple empty screens of whitespace, and prints "reshape_graphics" to the console multiple times.
When I fullscreen in adventure mode, sometimes it crashes, and sometimes the same failed-fullscreening happens.
This happens when using both TWBT and TWBT_CLASSIC. It doesn't happen when TWBT is disabled.
Post by: mifki on January 21, 2016, 01:21:11 am
Post by: Kazimuth on January 21, 2016, 03:58:58 am
Post by: figment on January 21, 2016, 09:39:47 pm
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 did a byte search algorithm for handling a similar issue for my teleport mod but probably only works for windows so is protected for that. Maybe there are similar general helper functions for linux/osx but I thought I read that mifki struck some sort of agreement to not try to merge TwbT into dfhack because of how this mod works. I was doing these updates for myself just because I like the mod so much but any investment in a generic update assumes that df will continue to be updated regularly and the work would be incorporated into dfhack.
Post by: mifki on January 21, 2016, 09:58:13 pm
I read that mifki struck some sort of agreement to not try to merge TwbT into dfhack because of how this mod works.
No, why. There are some changes need to be done on my side towards better interaction with dfhack and other plugins.
We've never discussed merging into dfhack though.
Btw, I need to check if for minor df updates these offsets can be found semi-automatically with byte search. Don't know why I haven't tried before.
Post by: topis on January 22, 2016, 09:28:25 am
Post by: Warmist on January 22, 2016, 03:58:57 pm
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.
Post by: topis on January 23, 2016, 01:50:06 pm
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.html
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.
Post by: endoftheline on January 25, 2016, 01:32:33 am
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.
Actually, the PATCHES file in TWBT describes a pretty OK procedure for finding the offsets, that works if automated too:
Spoiler (click to show/hide)
For Linux it reproduces the results for 40.24, 42.03-42.04 versions, and produces an OK looking patch for .05 too. I hope to get Win and OSX support working in a day or two and the finished script.
I'd appreciate any extra tips about finding those addresses in a cleaner, more robust way than described in the PATCHES file.
Post by: mifki on January 25, 2016, 04:04:01 am
Post by: mifki on January 25, 2016, 04:18:03 am
Post by: endoftheline on January 25, 2016, 05:54:44 am
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?
Post by: mifki on January 25, 2016, 06:05:29 am
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?
I'd like to write Hopper scripts to find offsets eventually. I've heard about radare2 of course, but never bothered to compile it for OS X and try. Hopper doesn't crash for me, but I haven't used it on Linux much.
There's nothing to install actually, just the plugin file and shadows.png to data/art folder (the latter isn't strictly required for it to work).
As for compiling, I build it separately from dfhack with my Makefile - just set correct paths to df and dfhack and probably change gcc version, and "make inst" will do the job. CMakeLists.txt was contributed by someone else.
Post by: fricy on January 25, 2016, 06:45:36 am
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...
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.
Post by: endoftheline on January 25, 2016, 10:52:27 am
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.
Thanks!
Also for anyone starting out like me: don't forget to add multilevel 6 or something like that into dfhack.init
This made me recheck the patch addresses like 3 times :)
Post by: funkydwarf on January 28, 2016, 01:08:42 pm
Post by: PeridexisErrant on February 01, 2016, 06:49:43 pm
Post by: mifki on February 01, 2016, 06:55:27 pm
ETA on a build that supports DFHack 42.05-alpha1 ?
Was waiting for the dfhack repo tag, will do once I get home.
Post by: mifki on February 02, 2016, 02:10:57 am
Post by: Rydel on February 13, 2016, 10:41:24 am
For furnaces, I can't find a way to override various Magma furnaces separate from the normal ones - only the Smelter has a _MAGMA option, and instead of a non-magma option, the only the other version is _ANY.
For custom workshops, I entered it the same way Meph listed it in his post on it, but I'm getting an invalid override specification on each one.
[OVERRIDE:150:B:SOAP_MAKER:Workshop::building:34]
[OVERRIDE:8:B:SOAP_MAKER:Workshop::0:134]
[OVERRIDE:240:B:SOAP_MAKER:Workshop::building:40]
Post by: Rose on February 13, 2016, 11:05:10 am
Post by: Rydel on February 13, 2016, 01:05:57 pm
Does anyone know about the Custom Workshop overrides? In another thread, Meph mentioned that how they work changed since he wrote his post, which would explain why mine are giving errors. How are custom workshops overridden now?
EDIT: Nevermind, if figured it out.
The lines should be [OVERRIDE:tile:B:WORKSHOP_CUSTOM:Workshop::tileset:newtile]. All the custom workshops share the same set of overrides.
Post by: mifki on February 15, 2016, 12:37:09 am
You should be able to specify a custom workshop code in place of *** above. E.g. SOAP_MAKER, SCREW_PRESS, etc.
Post by: Rochndil on February 15, 2016, 02:52:28 pm
I've been working on my compilation tileset, and just started testing my overrides. Most of them work just fine (once I got all the definitions coded properly), but I'm having trouble with my QUIVER and BACKPACK entries.
This one works fine:
[OVERRIDE:088:I:BIN:BIN::ovr:004] (though I need to find a better bin graphic, my art sucks)
These two do not:
[OVERRIDE:146:I:BACKPACK:BACKPACK::ovr:008]
[OVERRIDE:146:I:QUIVER:QUIVER::ovr:009]
They don't display incorrectly (wrong graphic, blank, etc.), they just default back to the main tileset (archers and soldiers carrying chests on their back is somewhat amusing). It's not an end-of-the-world thing, but I'm just not sure if I did something wrong, or if it's a bug of some kind. I tried to double-check the ID and Type, but the .h files referenced in the documentation don't seem to be part of the HACK source currently.
Any help or suggestions will be appreciated!
Rochndil, working on the MMO project...again. One of these years it'll actually be done!
Post by: Rydel on February 15, 2016, 03:17:31 pm
Post by: Rochndil on February 17, 2016, 09:55:36 am
Rochndil, who got to spend Sunday covered in mud and unable to wash (digging up and repairing house water line)...just like a dwarf!
Post by: PeridexisErrant on March 05, 2016, 12:50:42 am
Post by: mifki on March 05, 2016, 05:40:57 am
Post by: Nimrod on March 05, 2016, 06:00:00 am
Done, thanks to sv-esk for offsets.
Holy manure you are fast! Thank you very much! :D
Post by: PeridexisErrant on March 05, 2016, 06:03:22 am
Done, thanks to sv-esk for offsets.
Wow! Thanks mifki, and thanks sv-esk!
Post by: mifki on March 05, 2016, 06:46:26 am
Post by: Rochndil on March 06, 2016, 03:38:22 pm
I just confirmed (at least on my equipment) a repeatable bug. Install DF 42_06, gen pocket region, embark, looks fine. Add DFHACK, test same game, looks fine. Add TWBT (and minimal configuration to test), test, and within a few moments, the game will switch from rendered characters to colored bricks (one per character) for the entire interface. This takes from a few seconds to a minute or so to happen, but it does happen consistently. FWIW, TWBT seemed pretty stable with the previous test-build under 42_05. If you need any specific data/files/specs to check into this, please let me know. Tomorrow I'll re-test on my work PC.
Basic data:Windows 7x64, 8GB RAM, AMD 5770HD graphics.
Rochndil, who will have to continue development on 42_05 for the moment...
P.S. Checked the work PC today, and the problem does NOT occur. It's a good deal different, but neither system has had issues with DF before. Basic specs: Win10, 16GB RAM, Xeon processor, Nvidia GeForce 8800 GTS. It's not impossible my home system needs maintenance.
Post by: utkonos on March 06, 2016, 06:35:41 pm
Found a problem - 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.
Post by: jobywalker on March 10, 2016, 11:27:01 pm
Post by: necrotic on March 10, 2016, 11:58:04 pm
Does TWBT need to be recompiled against the latest dfhack? I'm assuming it does.
Yes, any compiled plugin for dfhack has to be recompiled for a new release.
Post by: mifki on March 11, 2016, 05:22:43 am
Post by: scamtank on March 11, 2016, 07:25:22 am
done
Thank,
Post by: Nimrod on March 11, 2016, 12:49:56 pm
done
Awesome, thank you!
Your plugin REALLY is a massive improvement for this game!
cheers
Post by: Max™ on March 11, 2016, 10:45:33 pm
Code: [Select]
[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.Oh wait, forgot to check stderr!
Code: [Select]
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.)
Post by: figment on March 12, 2016, 01:49:58 pm
Post by: Rochndil on March 12, 2016, 07:54:22 pm
I just got the few free minutes I needed to test the latest build(s) and the strange issue I posted about above did NOT happen again. I did also have the chance to de-dust my box and re-seated all the critical components, so there's no way to know if the problem was actually caused by a code issue or hardware problems on my end. BUT, seeing a bug go away is always a good thing, especially since I NEED TWBT to continue developing the mod(s) I'm currently working on. Keep up the awesome work, and if I encounter anything else worth reporting I'll post here.
Rochndil, poking and puttering away...
Post by: Uzu Bash on March 13, 2016, 03:19:42 pm
Then a 1 sentence install explanation ("unzip that there") would be sufficient, and the rest of your thesis would be read by those with an interest in development, and not as a forensic investigation into where the fuck these files go.
Post by: Rochndil on March 22, 2016, 09:48:03 am
While TWBT 5.58 seems to be working fine, it's throwing an error on the DFHACK screen:
Warning: Plugin automaterial compiled for DFHack 0.42.06-alpha2-0-g6fd904f, running DFHack 0.42.06-alpha1-10-g6fd904f
Warning: Plugin mousequery compiled for DFHack 0.42.06-alpha2-0-g6fd904f, running DFHack 0.42.06-alpha1-10-g6fd904f
Warning: Plugin resume compiled for DFHack 0.42.06-alpha2-0-g6fd904f, running DFHack 0.42.06-alpha1-10-g6fd904f
Warning: Plugin twbt compiled for DFHack 0.42.06-alpha2-0-g6fd904f, running DFHack 0.42.06-alpha1-10-g6fd904f
I just re-downloaded everything, and the error is consistent. Again, though, it doesn't seem to actually be causing any problems, so it may fall into the "acknowledge and ignore" category.
Since this seems to be a compilation/version compatibility issue, it would be helpful to include a download link to the DFHACK version the TWBT version was compiled for.
Rochndil, finally getting back to mod development...
Post by: Rose on March 22, 2016, 12:27:18 pm
Post by: Aussiemon on April 12, 2016, 05:24:39 pm
I'm
(http://i.imgur.com/5IuW12S.png)
I'm on 5.59, Windows 10 x64, Starter Pack 42.06 R2
EDIT: Here is a link to five DF minidumps: https://drive.google.com/open?id=0B2dQD-3xGxMtLXdfT2huYnJzSFU (https://drive.google.com/open?id=0B2dQD-3xGxMtLXdfT2huYnJzSFU)
3208 and 6788 are directly related to this issue, though the other three are also recent and might be useful too.
EDIT2: Here is the save: https://drive.google.com/open?id=0B2dQD-3xGxMtanVBUGk2V0pmVWc (https://drive.google.com/open?id=0B2dQD-3xGxMtanVBUGk2V0pmVWc)
Crash occurs when TWBT 5.59 is enabled in conjunction with DF Starter Pack, does not occur when TWBT is disabled. Crashing usually happens when trying to fill in the gaps at the base of the moat, along top side of fort, with shale walls.
Post by: mifki on April 12, 2016, 07:54:51 pm
Post by: Pvt. Pirate on April 13, 2016, 08:41:58 am
updating my OS soon anyway, so if it is because of XP, then ignore this report.
Post by: tapk on April 13, 2016, 09:24:33 am
Post by: mifki on April 13, 2016, 09:46:20 am
Post by: Pvt. Pirate on April 13, 2016, 10:55:03 am
Post by: Aussiemon on April 13, 2016, 11:36:30 am
I was able to recreate the original bugged save, fortunately, and it still crashes frequently when trying to build shale block walls at the bottom of the moat. I've attached two more saves below.
Save 1 - (Original) Post-bug (disabling TWBT and proceeding past the crash point fixed the issue):
https://drive.google.com/open?id=0B2dQD-3xGxMtanVBUGk2V0pmVWc (https://drive.google.com/open?id=0B2dQD-3xGxMtanVBUGk2V0pmVWc)
Save 2 - A bit before the point of crash (build shale block walls at bottom of moat and maybe try smoothing as well):
https://drive.google.com/open?id=0B2dQD-3xGxMtaVM2ZVFhV1NqMWM (https://drive.google.com/open?id=0B2dQD-3xGxMtaVM2ZVFhV1NqMWM)
Save 3 - Closer to the point of crash (proceed as above):
https://drive.google.com/open?id=0B2dQD-3xGxMtaEIyNGNBR3NqWXc (https://drive.google.com/open?id=0B2dQD-3xGxMtaEIyNGNBR3NqWXc)
Package 1 - The complete Dwarf Fortress folder with DXDiag.txt, save 2, and save 3 included.
https://drive.google.com/open?id=0B2dQD-3xGxMtaGF0SzQtdVBOaE0 (https://drive.google.com/open?id=0B2dQD-3xGxMtaGF0SzQtdVBOaE0)
Post by: mifki on April 14, 2016, 04:46:44 am
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?
Post by: Pvt. Pirate on April 14, 2016, 06:16:36 am
it could also be possible that this is caused by the mousecontrol plugin.
Post by: mifki on April 14, 2016, 06:20:21 am
Post by: Aussiemon on April 14, 2016, 05:49:19 pm
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.
Just tried with all plugins disabled and moved, with the exception of twbt, mousequery, and automaterial. Crash occurred similarly, this time when trying to place a door. I used STANDARD print type previously, not 2D.
Post by: Pvt. Pirate on April 14, 2016, 07:42:49 pm
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?)
that's where i got those crashes. the game runs at 20-30 fps most of the time and rarely gos down to or even below 10.
then out of nowhere when building walls, bridges, doors, tables etc. it crashes.
Post by: Kebra on April 16, 2016, 02:54:24 pm
I too face these crashes. It seems to happen more frequently when i build a lot fast. If it's related to doing commands fast or simply that i am building a lot; i don't know.
Are there logs i can find and give you? Some sort of verbose debug mode or similiar?
My eyes cry when playing with TWBT :)
Post by: Dirst on April 17, 2016, 06:49:18 pm
Code: [Select]
dm = require('gui.dwarfmode')
size_x = dm.getPanelLayout().map.width
size_y = dm.getPanelLayout().map.heightin 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.
I'm trying to get the coordinates of the center tile of the screen using something like
Code: [Select]
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_zbut it's off in TWBT mode. This might also be related to the odd centering behavior that others have noted.
Is there a spot accessible to Lua that reports if TWBT is active and the width of a TWBT map in tiles, or the widths of the graphics and text cells so that I can scale it myself?
Thanks, TWBT is an amazing tool, and I'd hate for my effort to not be compatible with it :(
Post by: PeridexisErrant on April 17, 2016, 07:49:11 pm
Post by: lethosor on April 17, 2016, 08:40:18 pm
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.)
Post by: mifki on April 18, 2016, 02:05:15 am
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.
Post by: Lamandus on April 20, 2016, 10:36:43 am
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.
Got any problems? Because tonight is over already ;)
Post by: Pvt. Pirate on April 20, 2016, 10:54:26 am
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 ;)
Post by: mifki on April 20, 2016, 04:39:41 pm
Post by: PeridexisErrant on April 20, 2016, 06:09:12 pm
Exactly. New build is on http://build.mifki.com
Could you cross-post to GitHub?
Post by: Pvt. Pirate on April 20, 2016, 06:52:35 pm
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?
Post by: mifki on April 20, 2016, 07:13:03 pm
Post by: PeridexisErrant on April 20, 2016, 09:01:08 pm
so you're going to put it into the next LNP rc? :)
Yep, new starter pack when I get home tonight.
Post by: Dirst on April 20, 2016, 09:14:12 pm
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.
Post by: mifki on April 20, 2016, 11:06:32 pm
Post by: illys on April 23, 2016, 01:48:32 am
Post by: MonkWho? on April 25, 2016, 10:06:02 pm
Post by: PeridexisErrant on April 25, 2016, 10:39:04 pm
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.
Post by: mifki on April 25, 2016, 10:52:05 pm
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.
There's a build on the build server. I know you don't like downloading it from there because of my self-signed cert, but I don't test new builds on all platforms and prefer someone to try them before I publish to GitHub as a "release".
Anyway, the latest build is now on GitHub.
Post by: Meph on April 30, 2016, 05:03:24 pm
Sometimes it does boot up without a crash and I can play and use TWBT without issues.
Post by: mifki on April 30, 2016, 09:39:16 pm
Post by: Meph on May 02, 2016, 12:38:06 pm
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.
It works now.
Post by: Trallic on May 11, 2016, 07:46:58 pm
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?
I've been having the same exact problem. In fact, I registered here tonight just to give this info after quite a few years of lurking around here.
Randomly crashing when - resizing the screen (very rare) , clicking to build a workshop, clicking to build wall/floor as well as moving the cursor to do either of those.
Originally I thought the wall/floor thing was my resizing the selection as I was moving the cursor as I seem to recall that happening once in a blue moon on earlier 4x versions. However, one particular day I crashed several times in a row trying to build the same workshop in the same tile. I even rebooted to see if maybe there was some unreleased memory hosing something up but it did not help. As a test, I built something else and went back to the original and was able to place it fine. In fact, it did not crash on me again for a few hours.
After switching back to Standard I have had 3 full, solid days of the game running without a single crash. In addition, framerates have been capped at 100 for almost the whole time.
Not to pile on, but I can also say that for the first time since I installed .06 I have not had the ghost/missing caravan problem. This one has been a major problem for me, either popping up immediately in the 2nd year or the 3rd.
I have tried TWBT and the Legacy option with the same crash problem. The starter packs r02/03/04 with tile set Phoebus all had the same issue. Plugins active are Other Automation plugins, Performance Tweaks and Workflow. I have turned them off and experienced the crashing.
I don't mess with the files or launch options too much and I had completely forgotten about TWBT. Part of the problem using the LNP I guess. Once I turned it off, all the problems stopped. I hope this is something that can be tracked down and fixed. I've become so used to seeing the game this way it's hard going back.
Post by: mifki on May 11, 2016, 08:52:19 pm
Post by: Pvt. Pirate on May 12, 2016, 08:07:37 am
some strange "graphic artifacts" show fake copies of tiles when moving the view. these artifacts stay even when switching zlevels up and down again. still occurs with "multilevel 0".
without TWBT and a square tileset/graphicset, the small menu takes up more than half of the width of my screen, rendering the game unplayable, the full menu would take up the whole screen, so TWBT has to work :)
and i'm using the LNP 42.06.r4.
Post by: Meph on May 12, 2016, 02:20:08 pm
Spoiler (click to show/hide)
Post by: tapk on May 12, 2016, 06:45:06 pm
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.
Post by: Taffer on May 19, 2016, 10:03:35 am
Post by: mifki on May 19, 2016, 04:10:15 pm
Post by: Rydel on May 19, 2016, 05:05:49 pm
Post by: Taffer on May 19, 2016, 10:46:25 pm
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 font tilesets (https://github.com/mifki/df-twbt/tree/master/dist). 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 tilesets, if this is upstream and upstream includes tilesets. (Spacefox_16x16_text.png, curses_800x600.png)
At any rate, apologies for the noise.
Post by: mifki on May 19, 2016, 11:10:59 pm
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.
Post by: Taffer on May 19, 2016, 11:14:21 pm
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.
That makes sense. I'll see about making a DFGraphics pull sometime. Oh, and apologies if I came across as rude, I didn't intend to be.
Post by: PeridexisErrant on May 19, 2016, 11:44:03 pm
I'll see about making a DFGraphics pull sometime.
Sorry I didn't jump in earlier; been very busy lately. For Starter Packs, it's better not to add anything to graphics packs -- take advantage of the LNP/Tilesets (https://bitbucket.org/Pidgeot/python-lnp#rst-header-tilesets) dir. Pull requests most useful against my repo (https://github.com/PeridexisErrant/starter-pack) and/or the LNP shared core (http://the LNP shared core).
Post by: Warmist on May 20, 2016, 02:00:32 am
Post by: mifki on May 20, 2016, 04:11:53 am
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
Post by: Pvt. Pirate on May 20, 2016, 05:52:51 am
Post by: Warmist on May 20, 2016, 05:59:38 am
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
Post by: mifki on May 20, 2016, 08:48:05 pm
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?
Post by: Warmist on May 21, 2016, 01:03:42 am
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?
At first i wanted to screenshot the map. But that needs image saving (and before that somehow forming the image). And i'm too lazy to do the opengl things you did.
Then i thought maybe i could do the multilevel render without patches (not sure i understand what they do). But got distracted.
Current thing i've done is a remote viewer + super simple http server mostly in lua. The best thing it does not move the players viewscreen. So you could have other players spying (and maybe issueing some orders?) to individual dwarves.
The code is in: code (https://github.com/warmist/dfhack/tree/twbt_experiments) + offsets (https://github.com/warmist/df-structures/tree/twbt_experiments)
Post by: Rogue Yun on May 22, 2016, 06:44:41 pm
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.
Post by: Das123 on May 22, 2016, 07:01:55 pm
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
Post by: mifki on May 22, 2016, 07:12:11 pm
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
There's a command
Code: [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.
Post by: PeridexisErrant on May 22, 2016, 07:43:33 pm
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.
Post by: mifki on May 22, 2016, 07:57:58 pm
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.
It shouldn't affect simulation FPS, I believe.
Post by: Dirst on May 22, 2016, 09:30:55 pm
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.
Post by: mifki on May 22, 2016, 11:44:54 pm
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.
Not quite. TWBT just calls the DF map rendering function, and that function uses window size in text tiles (because, well, DF doesn't have "text" or "map" tiles, so that's just df.global.gps.dimx/dimy values). In order to render the correct map size and position, TWBT temporarily adjusts these values to be window size in map tiles, renders map, and changes them back.
But when the game centres on an announcement location, it, again, uses window size in text tiles, while the map size is different, resulting in wrong centring. Since it happens inside DF code, there's not much we can do.
However, in some cases, for example, when you press a key to zoon to a unit, I, again, intercept that key, temporarily adjust window size to be the map size, pass the key to DF, and change it back. But this requires handling all cases separately (where possible at all). So if it doesn't centre properly in some cases, maybe I just need to add code for those cases.
On the other hand, if we're talking about DFHack code and map centring done in DFHack code, if any, then yes, doing what lethosor suggests will help.
Post by: Das123 on May 22, 2016, 11:57:27 pm
There's a commandCode: [Select]twbt redraw_all 0|1that 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.
Thanks Mifki and PerridexisErrant. That worked perfectly. :)
Post by: jecowa on May 30, 2016, 12:26:52 am
Here's a starting point:
- Do you play Dwarf Fortress?
- Does Dwarf Fortress ever crash while you are playing?
- If so, how often does Dwarf Fortress crash?
- If you get crashes, under which of these conditions does the game crash:
- While launching the game?
- In the middle of playing the game?
- While exiting out of the game?
- Have you happened to notice how much RAM Dwarf Fortress is usually using around the time that it crashes? If so, how much? (e.g. 400 MB, 1 GB, 1.6 GB, etc.)
- What is the size of your Dwarf Fortress world? (pocket, small, medium, large, etc.)
- What embark size do you use? (e.g. 5x5, 4x4, 3x3, 5x2, 1x1, 16x16, etc.)
- What operating system are you using? (e.g. Windows, Linux, Mac, etc.)
- Are you using the Lazy Newb Pack?
- What version of Dwarf Fortress are you using?
- Are you using DFHack? If so, what version of DFHack are you using?
- Are you using TWBT? If so, what version of TWBT are you using?
- If you are using DFHack, did you install it by yourself, or do are you using a DFHack that came preinstalled with the Lazy Newb Pack?
- If you are using TWBT, do you have multilevel rendering enabled? (i.e. The feature that lets you see more Z-levels at once.)
- What graphics pack and/or tileset are you using?
- Did you install the graphics pack / tileset yourself, or did you use the Lazy Newb Pack?
- Are you using any other mods with TWBT? If so, what are they?
Post by: lethosor on May 30, 2016, 04:10:03 pm
Post by: Pvt. Pirate on May 31, 2016, 04:07:02 am
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.
Post by: mifki on May 31, 2016, 04:21:44 am
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.
Code: [Select]
twbt redraw_all 0|1should fix artefacts when moving screen
Post by: Pvt. Pirate on June 01, 2016, 07:12:25 am
thanks, i'll add it.Code: [Select]twbt redraw_all 0|1
should fix artefacts when moving screen
Post by: utkonos on June 05, 2016, 03:43:20 am
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.
Post by: YetAnotherLurker on June 09, 2016, 08:18:13 am
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.
Post by: jecowa on June 09, 2016, 11:12:38 am
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).
If you are using the Lazy Newb Pack, then multilevel view is probably set to 5 or 6 by default. Depending on the version of the Lazy Newb Pack you are using, the name of the file you need to edit will vary a bit:
- Windows users: /starter pack/Dwarf Fortress/dfhack_PeridexisErrant.init
- Linux users: /0123412-x64/df_linux/dfhack.init
- Mac users: /MacNewbie/Dwarf Fortress/onLoadWorld.init
You will find a line that says something like "multilevel 5" or "multilevel 6".
Change that line to "multilevel 1".
Post by: YetAnotherLurker on June 09, 2016, 10:57:44 pm
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.
Post by: KirigStonebeard on June 11, 2016, 08:12:05 pm
Post by: Doohl on June 15, 2016, 04:58:09 pm
Post by: Meph on June 16, 2016, 09:47:22 am
https://github.com/DFHack/dfhack/releases/tag/0.43.03-alpha1
Hope TWBT gets updated too. :)
Post by: mifki on June 17, 2016, 08:25:31 am
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.
Post by: Thuellai on June 19, 2016, 07:03:10 pm
Not sure if it's a tileset problem or a TWBT problem, so figured I'd report the issue here. Already mentioned it to Rydel.
Post by: milo christiansen on June 21, 2016, 12:34:33 pm
AFAIK, this is caused by an undefined foreground color, probably in the material being used to make the bins. (then again, your case may may be a rare TWBT bug, but I doubt it)
Post by: Rydel on June 21, 2016, 04:38:02 pm
Post by: mifki on June 21, 2016, 04:46:36 pm
Post by: jecowa on June 23, 2016, 09:35:38 pm
Post by: mifki on June 23, 2016, 10:35:11 pm
mifki, is it okay to bundle Text Will Be Text with Lazy Newb Packs?
That's what has been done always so I don't see a reason why not.
Post by: jecowa on June 23, 2016, 10:45:15 pm
Post by: Erde on June 26, 2016, 08:36:44 am
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.
Post by: Fleeting Frames on June 26, 2016, 11:11:19 pm
Running ASCII, however, which mainly hurts grass on the first z-level going deeper (grass has natively varied tiles in hue, luminosity and appearance). Ramps are more clear - minecarts track are especially fun - if behaving slightly unexpectedly with downwards slopes (the vanilla multilevel).
I'll definitely mess around with settings a bit further, atm was pondering of something like harsher first step and multilevel 1 or 2. Then a hilly fortress dedicated to ramp romps....
But I was interrupted in my pondering by watching a badger pack migrate onto the embark, move and do their animal pathing counterclockwise spirals, into a cage trap.
That is so very awesome. Thank you.
Post by: mifki on June 28, 2016, 07:33:11 am
Post by: Meph on June 28, 2016, 07:55:41 am
Build is ready for 0.43.03-alpha1Thank you :)
Edit: Is there any way to change the style of walls depending on the material they are made of? I'd like to make wooden walls to look different from stone walls.
I only found the tile types:
Code: [Select]
ConstructedFloor, ConstructedFloorTrackE, ConstructedFloorTrackEW, ConstructedFloorTrackN, ConstructedFloorTrackNE, ConstructedFloorTrackNEW, ConstructedFloorTrackNS, ConstructedFloorTrackNSE, ConstructedFloorTrackNSEW, ConstructedFloorTrackNSW, ConstructedFloorTrackNW, ConstructedFloorTrackS, ConstructedFloorTrackSE, ConstructedFloorTrackSEW, ConstructedFloorTrackSW, ConstructedFloorTrackW, ConstructedFortification, ConstructedPillar, ConstructedRamp, ConstructedRampTrackE, ConstructedRampTrackEW, ConstructedRampTrackN, ConstructedRampTrackNE, ConstructedRampTrackNEW, ConstructedRampTrackNS, ConstructedRampTrackNSE, ConstructedRampTrackNSEW ConstructedRampTrackNSW, ConstructedRampTrackNW, ConstructedRampTrackS, ConstructedRampTrackSE, ConstructedRampTrackSEW, ConstructedRampTrackSW, ConstructedRampTrackW, ConstructedStairD, ConstructedStairU, ConstructedStairUD, ConstructedWallL2D, ConstructedWallL2U, ConstructedWallLD, ConstructedWallLD2, ConstructedWallLR, ConstructedWallLRD, ConstructedWallLRU, ConstructedWallLRUD, ConstructedWallLU, ConstructedWallLU2, ConstructedWallLUD, ConstructedWallR2D, ConstructedWallR2U, ConstructedWallRD, ConstructedWallRD2, ConstructedWallRU, ConstructedWallRU2, ConstructedWallRUD, ConstructedWallUD,I know its possible for doors, since they use different tiles in vanilla already, but I was wondering if you could somehow include this option for overrides.
Post by: Rydel on June 29, 2016, 07:34:16 am
http://www.bay12forums.com/smf/index.php?topic=138754.msg5771011;topicseen#msg5771011
http://www.bay12forums.com/smf/index.php?topic=138754.msg5771577;topicseen#msg5771577
I think there were concerns about this making the OVERRIDE token too complicated. A fix would be designing it to work as a block, the way ENTITY or CREATURE tokens do. That looks like it would be a fairly significant rewrite how how the overrides file works, but it would open the door for a lot of customization down the line.
Post by: Meph on June 29, 2016, 07:51:49 am
Yeah, I'm not sure how many people would actually use it, but I think that metal, stone and wood should somehow look different. I was mostly asking for a total conversion with playable elves... they should get naturally-grown tree/bush walls, not the blocky type. I would do it with workshops and inpassable tiles, but unfortunately they are see-through. A workshop-wall made out of bushes and trees would still allow invaders to look through (and I think shoot through) it.
Post by: jecowa on June 29, 2016, 07:39:16 pm
Spoiler: "shadows_32x.png" (click to show/hide)
Anyone can use it for anything, if they want. Higher-resolution shadows probably aren't going to provide noticeable visual improvements, thought.
Post by: Meph on July 08, 2016, 01:03:48 pm
The TWBT version for the 43.03-alpha dfhack did work, but the official release claims it is for another version. Aka TWBT is not working with the newest dfhack release.
Post by: lethosor on July 08, 2016, 04:57:46 pm
Post by: scamtank on July 08, 2016, 05:01:40 pm
considering how there's exactly two ways it can work, "just fine" and "instant crash", this is arguably for the convenience of the user
Post by: Meph on July 08, 2016, 06:09:28 pm
Post by: lethosor on July 08, 2016, 06:26:06 pm
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.
Post by: mifki on July 08, 2016, 08:54:41 pm
Post by: jecowa on July 09, 2016, 01:21:23 am
Post by: necrotic on July 20, 2016, 04:06:56 pm
Thanks for the notice. I didn't realize that you had to recompile every time DFHack released an update for the same version of Dwarf Fortress.
Thats the case for any compiled plugin to prevent potential issues with the different versions.
Post by: tapk on July 27, 2016, 05:56:34 pm
Post by: Drengor on July 31, 2016, 12:28:53 pm
When the graphics fail, it's basically just background colors. A screenshot is at http://imgur.com/a/Oe3sy .
Fortunately, resizing the window fixes it, turning it from a breaking bug into a nuisance. A screenshot after resizing is at http://imgur.com/a/fVNVe .
I can supply additional information as needed... Here is the basics...
Windows 7 SP1 x64
16G
SAPPHIRE Radeon R9 270X (2G)
Radeon Software Version 16.7.3
Here's the graphics portion of the init...
Spoiler (click to show/hide)
Post by: jecowa on July 31, 2016, 01:11:44 pm
Post by: Drengor on July 31, 2016, 02:28:14 pm
Post by: jecowa on July 31, 2016, 03:08:11 pm
Post by: mifki on July 31, 2016, 04:45:19 pm
1920x1080
Last time I played on TV in this resolution, it was fine, I'll test it again.
Post by: Russell.s on August 13, 2016, 11:26:19 pm
Thanks very much for your help :).
Post by: Rose on August 14, 2016, 06:40:05 am
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.
Post by: lethosor on August 14, 2016, 07:11:57 am
Post by: Russell.s on August 16, 2016, 12:00:12 am
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.
Okay, thanks you two. I'll just have to wait patiently for DFhack to reach the latest version before striking the earth!
Post by: milo christiansen on August 16, 2016, 12:26:26 pm
Post by: lethosor on August 16, 2016, 01:41:37 pm
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.
Post by: figment on August 21, 2016, 01:43:06 pm
Convert_magenta may be back but seems unused and possibly not a bool but int with value of 3 but since apparently unused it doesn't matter.
Spoiler (click to show/hide)
Post by: Meph on September 28, 2016, 09:31:42 am
Post by: Dirst on September 28, 2016, 12:11:00 pm
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.
Post by: Meph on September 28, 2016, 04:22:48 pm
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.
Post by: mifki on September 28, 2016, 04:25:58 pm
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.
It's not possible to split them, but I can add some options if you need, however I didn't quite get what exactly you want.
Post by: Meph on September 28, 2016, 04:45:15 pm
You can see multiple levels, you have two tilesets for the game/graphics and the menu/text; but the plugin ignores everything that's inside the overrides.txt in data/init.
The reason it would be useful (at least for me) is, that I soon have over 30 tilesets in my mod, but only one set of overrides. The graphic-style of the overrides fits some tilesets, but looks awkward with others. So I'd like to keep them for a few of the tilesets, but otherwise disable them.
Example:
Spoiler (click to show/hide)
It's an ASCII-style tileset, yet on the workshops some overrides are still active and show tiles from Phoebus. The solution for me would be to make 30 override files, or disable overrides when using that tileset.
Oh, and my usual request: Caste-specific creature overrides? Please? Male/Female sprites... different sprites for worker, warrior and queen bees/hornets/ants... cool custom races with multiple castes... ?
Post by: mifki on September 28, 2016, 05:35:38 pm
Creature overrides... yeah.. I started to work on a completely new TWBT implementation, and while it had many advantages like improved performance and greater flexibility, it turned out to be more difficult to implement and probably not worth it. I mean, I'm not actively developing it now, once I have time, I'll look into creature graphics again to understand whether it can be an addition to the existing creature graphics handling or would require reimplementing it completely.
Post by: Rydel on September 28, 2016, 10:22:35 pm
Post by: PeridexisErrant on September 29, 2016, 12:44:08 am
I'd also appreciate an interface more like standard DFHack plugins though, where you have to explicitly "enable $plugin" for anything to happen, and a single dylib can provide multiple commands. Separate commands for 'use text tileset', enabling multilevel, and using item sprites would be nice. Perhaps "enable twbt/multilevel/itemsprites" respectively?
Post by: Meph on September 29, 2016, 04:17:44 am
Quote
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.
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. The mod override file has about 1600 lines, the Gemset override file has 4000 lines.
Post by: mifki on September 29, 2016, 06:03:06 am
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.
You don't need to replace automaterial/resume/mousquery plugins - TWBT versions work just fine without it.
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.
Post by: Meph on September 29, 2016, 06:26:52 am
Quote
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.
Quote
You don't need to replace automaterial/resume/mousquery plugins - TWBT versions work just fine without it.That's good to know, thanks :)
Quote
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.
In the end I'll make overrides for each tileset, which will fix the issue I had.
Post by: PeridexisErrant on September 29, 2016, 09:09:29 pm
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.
You can always "unload twbt" (https://dfhack.readthedocs.io/en/stable/docs/Core.html#reload), or any other 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.
Post by: lethosor on September 29, 2016, 09:30:57 pm
I just found it strange that you can't disable (unload?) the plugin or part of the plugin.
Also, multilevel wouldn't have to be a separate plugin in order to support "multilevel enable|disable" syntax - things like mousequery and embark-tools do this already.
Post by: mifki on September 29, 2016, 10:39:24 pm
@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 don't understand the problem. There's "multilevel N" cmd with 0 to disable. And 0 is the default value.
Post by: DAOWAce on October 04, 2016, 05:00:02 pm
Game looks far better with multilevel (and my graphic pack [DungeonSet] kinda requires it to not have weird ASCII characters replace lower levels), losing it really sucks.
My game's crashed an unfortunate amount of times the last few times I tried to play DF. I always quit for a while afterward because it really sucks to lose ~30 minutes of work/progress. Maybe I'm going to have to grin and bear it just for the sake of not having my time wasted..
Edit: I disabled multilevel after loading.
My game still crashed after about 20 minutes of the client running. It froze when I attempted to zoom to a hotkey (which I did many times before) and then closed itself (silent crash; reports it in Windows event log but no popup saying it crashed).
Either multilevel isn't the problem, or setting it to 0 doesn't actually disable it fully.. at least if started with it enabled? No idea, hopefully someone can provide some insight into what the issue could be.
I'm still running the 0.42.06 version of the LNP, for clarity. (Don't want to risk upgrading my save..)
Post by: PeridexisErrant on October 10, 2016, 07:03:44 am
The DFgraphics group has a two-part feature request:
- Support multiple overrides files, eg anything matching "overrides*.txt"
- Support item subtypes by name and generally discourage use of numbers as IDs
Post by: mifki on October 10, 2016, 04:39:19 pm
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
Item subtypes by name would be good, but required a lot of code to handle all the item types. Multiple overrides files is easy and I will do that in first place. I just need to find time to get back to TWBT and do all this and other stuff.
As for the crashes, I mentioned before that the biggest problem here is that I can't reproduce them. I see many people reporting them, but I was really trying a lot, on different Windows machines and versions, and it crashed just couple times, and I even don't know if it's the same issue. I'd be happy to fix the crashes of course but it's difficult if I can't reproduce them at all.
Post by: jecowa on October 10, 2016, 04:52:18 pm
Post by: mifki on October 10, 2016, 05:01:43 pm
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.
No, it doesn't require more memory. It has to be something with synchronisation, maybe number of cores matter, I'll test it again on another laptop soon.
Post by: DAOWAce on October 11, 2016, 11:34:55 am
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.
I've disabled multilevel from initializing now (instead of disabling after the fact), so next time I decide to play, I guess I'll see if that did anything.
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. At any rate, it helps tremendously with my graphic set so I won't consider playing without it (bugged me for ages until I discovered the fix).
Edit: 6C/12T CPU (5930K). Forced DF to run on physical cores, because it's a game, and 99% of games have performance degradation if using virtual cores.
Post by: lethosor on October 11, 2016, 02:50:41 pm
Do the crashes tend to occur right when you attempt to do something in-game (i.e. does it crash right as you press or click something)? Or do they tend to happen when you're just leaving DF to run on its own?
I ask because of this (https://www.reddit.com/r/dwarffortress/comments/56zi5f/psa_be_careful_with_multi_level_view_if_you_are/).
Post by: Pvt. Pirate on October 11, 2016, 06:23:48 pm
on the other hand: in the 43.03-r07 LNP with multilevel 0, the game only crashed after excessive Alt-Tabbing.
Post by: lethosor on October 11, 2016, 08:05:54 pm
Post by: Pvt. Pirate on October 12, 2016, 04:47:37 am
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.
now with the 43.03-r07 LNP, it only crashed when switching to other windows frequently. although i haven't played that much with that version yet, it didn't crash for like 4 hours yesterday.
Post by: DAOWAce on October 12, 2016, 01:14:04 pm
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.
As for my other crashes, I honestly can't remember. Been playing a single fort on and off since .42 came out (my first one actually). I can vaguely remember the game seeming to crash when I did a zoom to a different z-level recently (within last month), but I'm not sure about the ones prior to those.
Edit: I remember another crash; it happened when I was saving the game (from the menu). Thought it was weird that the game closed immediately after the saving screen, then realized it probably crashed. Still saved though.
Post by: DAOWAce on October 13, 2016, 08:46:38 pm
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.
My game seemed to crash after a short amount of time after every reload. I ended up trying TWBT_LEGACY and progressed through just fine. Played for about 2 hours and saved.
Came back, switched to TWBT, played for about 10 minutes.. then crash about 12 seconds after a quicksave.
Reload.. 12 seconds, crash.
Went through my .init files changing stuff; after I removed the redraw_all command, the game progressed.
So.. something about it redrawing tiles is making it crash. This is a shame, as it gets rid of the nasty graphical issues with my graphic set (phantom tiles all over (https://www.youtube.com/watch?v=fDbuQ8CnGm0)). I guess my random crashes after long play sessions before finding this command were due to multilevel.
I suppose a save would help debug it, so: https://www.dropbox.com/s/dkud40cqkv5ooia/twbt%20crash%20dungeonset.rar
0.42.06-r04 LNP
DungeonSet (http://www.bay12forums.com/smf/index.php?topic=152766.0) graphics
'twbt redraw_all 1' in dfhack.init
Just load and wait about 12 seconds, will CTD.
Don't know if anything else is needed.
Post by: mifki on October 14, 2016, 08:41:58 pm
I believe it's caused by overrides and synchronisation on multi-core CPUs, there's indeed some not very good code which is unfortunately difficult to fix. DungeonSet has a LOT of overrides - almost 4000 lines, and with redraw_all=1 all map tiles are updated each frame increasing the chance of crash. I'll see what can be done here, but there's a chance it's not possible to fix completely without big changes to TWBT, unless it's just a mistake somewhere in the code.
And crashes caused by multilevel rendering seem to be a separate issue because I believe not everyone experiencing them have so many overrides, and also I recently had several crashes with the Remote plugin where there are no overrides at all. If anyone experiencing crashes when building something over empty tiles or something else multilevel-related that are easily reproducible, please share your saves.
Post by: Pvt. Pirate on October 15, 2016, 05:54:37 am
so it wouldn't have to redraw each and every frame, but only the moment it has to draw new tiles anyway.
Post by: Bumber on October 15, 2016, 10:55:02 am
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.
Post by: DAOWAce on October 15, 2016, 07:24:02 pm
Das did a short video explaining the issue: https://www.youtube.com/watch?v=fDbuQ8CnGm0
Post by: mifki on October 15, 2016, 09:47:02 pm
DAOWAce, why are you still using 0.42.06? My new releases usually don't include plugins for older DF versions.
Post by: DAOWAce on October 15, 2016, 10:32:45 pm
DAOWAce, why are you still using 0.42.06? My new releases usually don't include plugins for older DF versions.
I heard upgrading versions can break your game, so I'd rather avoid the chance of losing my save and starting over. (plus, I'm used to Workflow and don't know how the manager in v43 works or the consequences if it was randomly disabled)
Edit: Also, it's 2 versions behind the vanilla game and .04 had some pretty major bug fixes. Too bad it looks like the dfhack folks are going right to .05 with 64bit support. An alpha release is out and says 32bit support "should be" as good as usual, but I don't know if other plugins will work with it.
Post by: lethosor on October 15, 2016, 10:55:57 pm
That said, the workflow/manager change is a good point. I'm pretty sure workflow still works without issues, but I don't know how well it would play with the new manager.
Post by: Pvt. Pirate on October 16, 2016, 05:34:13 pm
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
It still occurs in the latest version.
Post by: mifki on October 16, 2016, 05:49:07 pm
TWBT processes overrides on a separate thread while the simulation is running. That's bad, but I expected it to cause problems only in rare case of some specific items/buildings being destroyed while TWBT is processing corresponding overrides. But now I saw this:
(http://i.imgur.com/cQVowRk.png)
The game reallocates block_index array for some reason while TWBT is processing tiletype overrides, and that's causing TWBT to access wrong address and crash. There are several ways to deal with this, I think (I don't want to process overrides synchronously and slow down the simulation), I'll try them soon.
Post by: PeridexisErrant on October 16, 2016, 06:26:42 pm
Ok, I have found what's causing crashes.
This is fantastic news! Thanks for your perseverance - it's obvious that tracking this down was not easy.
Post by: DAOWAce on October 16, 2016, 07:50:54 pm
This is fantastic news! Thanks for your perseverance.+1
If I knew any programming I'd offer to help, but all I can do is wish you good luck in fixing it!
Post by: jecowa on October 20, 2016, 02:45:19 am
Do I need to also put /twbt-5.66-osx/realcolors.lua into the /df_osx/hack/lua/ folder?
Post by: mifki on October 20, 2016, 03:35:40 am
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?
Yes.
You can copy realcolors and even try to use, but it's not related to the main twbt functionality.
Post by: jecowa on October 20, 2016, 04:39:14 am
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.
Post by: mifki on October 20, 2016, 06:51:02 am
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.
realcolors.lua is just a script (btw it should go to /scripts, not to /lua) that processes all materials and sets tile colours to be real material colours. Of course it doesn't change anything unless you run it.
Post by: Pvt. Pirate on October 20, 2016, 06:52:59 am
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.
Post by: mifki on October 20, 2016, 07:58:19 am
Build for 0.42.06 https://build.mifki.com/build/808
Build for 0.43.03 https://build.mifki.com/build/809
Post by: Meph on October 20, 2016, 08:36:58 am
Post by: Pvt. Pirate on October 20, 2016, 03:08:27 pm
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
Post by: mifki on October 20, 2016, 04:21:04 pm
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.
Post by: Meph on October 20, 2016, 05:28:12 pm
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.
Post by: mifki on October 20, 2016, 07:47:55 pm
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.
There were people who experienced crashes, I was hoping they could try.
But yeah, I don't mind, it's up to you.
Post by: DAOWAce on October 21, 2016, 03:51:56 am
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.
Also, Chrome complains about an invalid HTTPS certificate, but I could ignore it.
Edit: Played for about an hour just fine. Quit and tried the save that would crash in ~12 seconds, let that run for 30-40 minutes, no issues.
Unfortunately, I appear to have deleted the wrong folder and wiped my current save.. Lost 3 ingame years of playtime.. at about 20-40 calculation FPS (around 30-40 hours over the course of 4 days IIRC).. and I did a lot of manual tiletype changes with dfhack (for aesthetic reasons).
No recovery possible, did too many extractions of my 2 backups trying to figure out what happened (and Windows is garbage and never shadow copied the folder despite ample space; newest is from Oct 13).. and DF's autobackup option wasn't enabled (which I just now did).
I'm gonna just go out on a limb and say the update fixed the issue. This incident pretty much killed my will to play, so I won't be touching the game again for a few weeks.
Thank you for the fix, hope others report successfully as well.
Post by: jecowa on October 21, 2016, 05:20:56 am
Post by: Pvt. Pirate on October 21, 2016, 04:31:07 pm
Post by: Meph on October 21, 2016, 05:05:50 pm
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.
Post by: Pvt. Pirate on October 22, 2016, 01:56:53 am
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] ?
Post by: Warmist on October 22, 2016, 05:50:42 am
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] ?
Post by: Dozebôm Lolumzalìs on October 25, 2016, 01:37:02 pm
Post by: Meph on October 27, 2016, 02:53:40 pm
Aka:
Use font tileset 1 till embark selector.
Use font tileset 2 after embark selector.
Change is done automatically by TWBT.
Any chance for that?
Post by: PeridexisErrant on October 27, 2016, 05:33:23 pm
Post by: DragonDePlatino on October 27, 2016, 05:56:49 pm
Post by: Rydel on October 27, 2016, 06:05:36 pm
Post by: Meph on October 29, 2016, 06:51:52 am
Post by: Rose on October 29, 2016, 07:14:36 am
Another suggestion: Make TWBT load 4 different color schemes. Spring, Summer, Autumn, Winter. Automatically change those upon the change of seasons.
That might actually be possible as a separate plugin.
Post by: lethosor on October 29, 2016, 11:01:45 am
Post by: Meph on October 29, 2016, 11:02:50 am
Yeah, changing the color scheme on the fly isn't hard. See gui/settings-manager.So it could be easily automated with a script?
Post by: Thundercraft on November 01, 2016, 09:29:44 am
Another suggestion: Make TWBT load 4 different color schemes. Spring, Summer, Autumn, Winter. Automatically change those upon the change of seasons.
:o That would be awesome! That ability, alone, would get me to use TwbT.
So it could be easily automated with a script?
If that could be automated with a script, then it could be automated by SoundSense (http://www.bay12forums.com/smf/index.php?topic=60287). 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. (And it seems that SoundCenSe (http://www.bay12forums.com/smf/index.php?topic=159567) "parses the existing log" to retrieve the last season change when started up again.)
Build for 0.42.06 https://build.mifki.com/build/808
Build for 0.43.03 https://build.mifki.com/build/809
No build for 0.43.05 in the works?
Post by: mifki on November 01, 2016, 03:39:20 pm
Post by: lethosor on November 01, 2016, 04:26:23 pm
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.
Post by: Thundercraft on November 01, 2016, 05:25:14 pm
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.
Sir, you are mistaken. Granted, out-of-the-box, SoundSense does not trigger anything in-game. However, SoundSense does have the capability. As I said, most players are unaware of this. And that's because it's a feature which is not advertised and which hardly anyone ever uses.
Soundsense is an external program and doesn't communicate with DF/DFHack, unless something has changed recently that I'm not aware of.
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.
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.)
Post by: lethosor on November 01, 2016, 05:36:36 pm
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.
Post by: milo christiansen on November 01, 2016, 06:08:10 pm
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.
Post by: lethosor on November 02, 2016, 01:20:04 am
That script sounds pretty neat. It might be nice to have it in the DFHack repo once the seasonal change feature is done.
Post by: Meph on November 02, 2016, 06:16:29 pm
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.
Post by: milo christiansen on November 04, 2016, 11:43:37 am
Post by: Meph on November 06, 2016, 03:47:27 pm
Code: [Select]
[OVERRIDE:255:I:TOOL:TOOL:25:_MDF_overrides_1:248], but I cant make an override for the building. Same for track stops. Its a construction, but there seems to be no override for it.
Post by: Fleeting Frames on November 06, 2016, 05:57:32 pm
Same problem, nevertheless. I think the ≡ tile is also used for metal bars and metal doors.
Post by: PeridexisErrant on November 07, 2016, 05:29:17 am
Post by: mifki on November 07, 2016, 05:58:58 am
@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?
Nope, if it doesn't crash or at least less than before, well, consider it stable, I'll upload it to github.
Post by: Firnagzen on November 07, 2016, 10:23:27 am
Code: [Select]
[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).
Post by: jecowa on November 07, 2016, 10:27:46 am
Code: [Select]
[GRAPHICS:NO]Change this to "YES".
Post by: Firnagzen on November 07, 2016, 10:32:05 am
... Thanks.Code: [Select][GRAPHICS:NO]
Change this to "YES".
Post by: Firnagzen on November 07, 2016, 09:29:28 pm
Basically, I just want to use square ascii for the map tiles, and rectangular ascii for the text (it's much more readable that way) but the dwarfs are defaulting to the graphics. I've deleted dwarfs.bmp and edited out the entry in raw/graphics_example.txt, but they still show the default dwarf tileset instead of the ascii smileyface.
EDIT: I figured it out. Needed to delete it from the saves as well.
Post by: jecowa on November 12, 2016, 01:45:48 pm
Post by: PeridexisErrant on November 12, 2016, 09:12:21 pm
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.
Respectively: not yet, no, and correct.
Post by: jecowa on November 12, 2016, 10:41:40 pm
Post by: Dirst on November 12, 2016, 10:51:36 pm
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.
Post by: jecowa on November 12, 2016, 10:59:07 pm
Post by: Pvt. Pirate on November 13, 2016, 06:22:40 am
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.
Post by: Nelapsi on November 17, 2016, 06:36:36 pm
Spoiler (click to show/hide)
Post by: mifki on November 17, 2016, 07:09:24 pm
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.
Looks like you have "twbt tilesize" command hardcoded somewhere in your configs.
Post by: jecowa on November 17, 2016, 07:17:40 pm
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.
Post by: Nelapsi on November 18, 2016, 09:15:11 am
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.
Post by: ethanwdp on November 21, 2016, 11:38:56 am
It works fine when TWBT is disabled, however I cannot stand vanilla text.
Am I out of luck here?
Post by: mifki on November 22, 2016, 02:17:52 am
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?
I'll check it.
Post by: jecowa on November 23, 2016, 08:59:01 pm
On a thread about DFHack alpha2 (https://www.reddit.com/r/dwarffortress/comments/5ef715/dfhack_04305alpha2/dad4jhm/):
Quote from: Dasharg95
Just install and cannot load TWBT :(
alpha1 let me load TWBT.
Quote from: lethosor
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.
I don't know what to believe anymore.
Post by: mifki on November 23, 2016, 09:22:46 pm
Post by: lethosor on November 23, 2016, 09:28:45 pm
Post by: jecowa on November 23, 2016, 10:14:56 pm
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.
Post by: lethosor on November 23, 2016, 10:24:04 pm
Post by: Pvt. Pirate on November 24, 2016, 08:28:59 am
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 :(
i understand and respect your decision though.
Post by: Warmist on November 26, 2016, 07:27:04 am
Code: [Select]
<global-address name='twbt_render_map' value='0x1408170b0'/>
Edit: i was stupid...Edit: it's correct btw :)
Post by: Meph on November 26, 2016, 09:50:24 am
Any chance for more override options, or is it limited by internal DF tile-types?
Like different sprites for walls/floors depending on material. Wood/Stone/Gem/Metal.
Or body-parts (CORPSEPIECES) or meat, depending on part, like this:
Spoiler (click to show/hide)
Or caste-specific creatures graphics, for male/female sprites?
Or vermins? They are creatures, but the way DF handles their graphics, they can only use tiles from the original tileset, not creature sprites like all the other creatures. That makes it really tricky to give a sprite to all of them.
There are also text-only things ingame, like the sneaking indicator, animal tracks, depot-accessability, or low/medium/high traffic zones. Things that are essentially part of the UI, but displayed on the map.
I ask because I'm working on this tileset (http://www.bay12forums.com/smf/index.php?topic=161047.0) and I'm stumbling upon more and more little things that could be improved, if TWBT would allow it.
Post by: Warmist on November 26, 2016, 11:14:05 am
Hey,A few years later Meph: here's a 2gb of sprites to cover ALL possible things in DF :)
<...>
Post by: jecowa on November 26, 2016, 11:17:37 am
Post by: Meph on November 26, 2016, 11:25:01 am
See, I have a template with all the weapons, armors, items, professions, and I just need to copy the animal-man sprite underneath. Here the kestrel man as example:
Spoiler (click to show/hide)
Edit: Oh, and another question... TWBT know the position of the tiles it has to override, does it? Could it check neighbouring tiles, so that something like this can be done?
Spoiler (click to show/hide)
or to be more precise: Like this:
Spoiler (click to show/hide)
Post by: Snafu on November 26, 2016, 06:32:24 pm
Please change the background of that last from shocking pink!
Post by: jecowa on November 26, 2016, 06:51:47 pm
Post by: Snafu on November 26, 2016, 08:05:31 pm
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
Post by: Fleeting Frames on November 26, 2016, 10:45:51 pm
This shock image serves just as a tiling example, though. Both DF and FFx support transparency - the image backdrop actually is shocking pink. Thankfully, it is behind a spoiler, so you can just remain unspoiled.
Post by: mifki on November 27, 2016, 03:36:21 am
Currently TWBT is limited by tiletypes present in DF. I'm not even sure what there is what is not, there are definitely different types for some floor/wall materials but you'd better look yourself. The same for other stuff - mostly for performance reasons. For example building overrides require to specify tile number, building ID and building type because I naturally have tile number, look up overrides for it, then check all matching buildings from world.buildings.other[id] (that's why I need ID so that I don't check ALL buildings), compare their types and then find the one located on the current tile. Of course I can also check materials, neighbour tiles and whatnot, but that would require accessing more data structures, which can be slow, especially for complex tilesets that require updating all tiles each frame ("twbt redraw_all" option).
However, if you missed it, some time ago I started to work on a new version in which I was going to implement building/item rendering "the native way" (by interposing their rendering vmethods). This is faster and should allow to implement any custom building-specific logic (e.g. different tiles for locked/unlocked doors), and also a support for animated building/item images was planned. However I suspended the development because while being a great idea, it was a difficult for me to implement - one of the problems is that if I replace the default building rendering vmethod, I need to replicate all the existing rendering logic (like different tiles for door materials, animated machines, building construction stages, etc.), and tileset authors will need to provide tiles for all the situations. I'm neither sure I'm aware of all the logic that needs to be re-implemented, nor able to get all the required tiles myself.
If you're willing/able to help with these two problems, I can continue to work on that version again.
(I think the "text-only" things you mentioned are hardcoded, so there's not much I can do.)
Post by: Meph on November 27, 2016, 08:48:21 am
I can certainly provide tiles/sprites for everything, make a template for the other tileset authors, and test your builds, see if some tiles are missing. If there is anything I can do to help, you just have to tell me what.
From a players point of view, there are certainly some things that are more helpful than others. For example the tileset example above, with the grass/road that blends into each other... thats not very important. But distinguishing between male/female creatures at a glance, would be helpful. Or castes... like worker ants, soldiers ants and ant queen.
As a modder I often get requests by people that dont know modding, so the requests are about things either impossible or insanely difficult. I dont understand C++ much, so please excuse if my requests are a bit inane. ;)
Post by: mifki on November 27, 2016, 03:25:35 pm
I wasn't talking about coding, but rather tiles and checking that all the cases are handled correctly during rendering.
What exactly is missing from the existing creature graphics mechanism. Like, if there were another command supported in overrides file for creatures, [TILE:C:...], what the other parameters would be?
Post by: Meph on November 27, 2016, 04:14:25 pm
For creatures, the caste. Just like items have ITEM_TYPE:WEAPON and ITEM_SUBTYPE:ITEM_WEAPON_SWORD, creatures would be CREATURE:DWARF and CASTE:MALE. Most creatures have MALE and FEMALE.
But now that I think about it, in vanilla DF, the settings for creatures are this:
Code: [Select]
[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]Post by: jecowa on November 27, 2016, 11:36:15 pm
Also, will the native way get rid of the need to know the source ID numbers?
Post by: Rose on November 27, 2016, 11:51:40 pm
It would just have to match against any of these:
Spoiler (click to show/hide)
If TWBT did creatures, this would be a way of doing it.
Post by: Meph on November 28, 2016, 07:57:33 am
Post by: PeridexisErrant on November 29, 2016, 02:23:48 am
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)
The other thing I was wondering about is DFHack changes so you don't need to modify other plugins - issue #981 (https://github.com/DFHack/dfhack/issues/981) and so on. Is there any progress on this? (Maybe @Lethosor can answer?)
Post by: lethosor on November 29, 2016, 02:30:02 am
Post by: mifki on November 29, 2016, 04:03:54 am
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)
Honestly, I haven't looked at the 64bit binary yet. The VM I was using before for my build system was XP, so I just installed Win10 and VS2015 yesterday. I don't expect significant difficulties with finding offsets except for the multilevel rendering-related one - I don't fully remember how I found the function to patch for 32bit long time ago:( Theoretically, TWBT can support multilevel rendering even without that offset, but this haven't been done for a long time, not sure how well it works in this mode.
Post by: mifki on December 19, 2016, 10:46:23 pm
Post by: PeridexisErrant on December 20, 2016, 05:13:48 am
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.
That's great news nonetheless! Thanks for all your hard work :)
Post by: DanielCoffey on December 20, 2016, 06:18:45 am
Post by: gasznak on December 20, 2016, 12:20:11 pm
Post by: mifki on December 30, 2016, 05:51:06 am
Post by: PeridexisErrant on December 30, 2016, 06:13:04 am
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?
Post by: Warmist on December 30, 2016, 07:57:02 am
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.
Post by: lethosor on January 04, 2017, 12:45:10 am
Post by: mifki on January 04, 2017, 02:31:08 am
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.
Post by: mifki on January 04, 2017, 05:56:47 am
Post by: lethosor on January 04, 2017, 08:09:11 am
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.
Post by: mifki on January 04, 2017, 08:43:31 am
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.
That doesn't matter, the values are overwritten by the build system (see there's ?=).
Post by: lethosor on January 04, 2017, 10:58:55 am
Post by: mifki on January 04, 2017, 08:06:57 pm
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.
Post by: figment on January 14, 2017, 04:17:09 pm
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.
Post by: rmk on January 29, 2017, 10:34:04 pm
Spoiler: Phoebus_16x16_text (click to show/hide)
Spoiler: Phoebus_16x16_text_nonV (click to show/hide)
Post by: SMASH! on January 30, 2017, 12:19:47 pm
Post by: Lamandus on February 18, 2017, 04:57:32 pm
Post by: mifki on February 20, 2017, 05:14:47 am
Post by: Ygvir on February 20, 2017, 10:55:41 pm
Post by: mifki on February 20, 2017, 11:25:42 pm
Post by: Lamandus on February 21, 2017, 01:10:57 am
Post by: Enay on March 02, 2017, 12:05:56 pm
Post by: Sturmgeher on March 02, 2017, 06:27:34 pm
You got a nice plugin an to read about it is nice. But its not working and preventing me from using Df Masterwork.
I tried to solve the problem but failed.
The forum knows many threats about problems, they are dating far back.
I would like to know if there is a walk around.
DF crashes on starting the dwarf mode. dfhack gives an error on manually loading the plugin.
Log: Plugin twbt is broken - cannot be loaded
I tried other Versions od twbt but couldt get a hit.
I also found no option to simply put it off, but this maybe a problem for the masterwork-guys.
System is win 10 32bit, DF is 43.03 (Masterwork 1.23)
have a nice day
Sturmgeher
Post by: Rydel on March 02, 2017, 06:38:08 pm
Also, as a general Masterwork crashing thing, have you used Large Address Aware? That fixes a lot of crashing in Masterwork.
Post by: se5a on March 04, 2017, 12:21:31 am
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.
I'm in a similar boat, the instructions are not step by step enough for someone who's never done it before.
Post by: se5a on March 08, 2017, 12:58:50 pm
I'd like to get the meph tileset working on 05, but even the main menu is unreadable without twbt
Post by: Amostubal on March 10, 2017, 11:46:58 am
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 this normal?
It should be the last version of the DFhack for 43.03 x32 versions. the TWBT version in masterwork 1.23
I don't have experience in this, but I don't think the issue the player had was directly linked to this. I personally just thought it was working as normal, I don't think it would be a good thing to shutdown TWBT in the middle of a running game, but apparently this is the same message the player received from the same command right after loading the game, when TWBT shutting down and restarting shouldn't be an issue.
Post by: mifki on March 11, 2017, 05:07:05 am
This was posted in the masterwork forum today. I've never seen this before, but I've never reloaded dfhack from the console before.
TWBT does not support unloading.
Post by: mifki on March 14, 2017, 04:02:29 pm
(http://mifki.com/assets/uploads/Screen-Shot-2017-03-15-at-9.57.25-AM.png)
Post by: Rydel on March 14, 2017, 05:00:43 pm
Post by: milo christiansen on March 14, 2017, 05:20:09 pm
(good eye!)
This could be an interesting feature, depending on exactly how it works of course.
Post by: Pvt. Pirate on March 14, 2017, 05:39:48 pm
Post by: Rose on March 15, 2017, 04:24:46 am
Post by: mifki on March 15, 2017, 05:08:18 am
Is that a mockup or functional?
Functional, although not sure yet how much useful.
Post by: Warmist on March 15, 2017, 06:15:40 am
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.
Post by: Pvt. Pirate on March 15, 2017, 11:49:17 am
Post by: mifki on March 15, 2017, 03:19:46 pm
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.
Post by: Amostubal on March 18, 2017, 08:49:14 pm
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.
I find it wonderful.... the question is how it would look with other tilesets... and when can I watch my dwarves ride minecarts around my shooting gallery?
Post by: Nobak on April 01, 2017, 10:08:15 am
Essentially, over time as a fortress grows, 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.
However, the load issues also creep up and eventually it reaches the point where loading a fort without crashing is almost impossible. Unlike the save crashes, which happen instantly, load crashes happen at the very end of the loading process.
I'm guessing it's related to TWBT because I can get things working again if I change the print mode to TWBT_LEGACY.
Now, I don't expect older versions to be maintained on a project that is being graciously offered for free. Rather, I'm posting for two reasons:
1-I'm hoping to find out if anything is known about such an issue, or if anyone has any ideas to mitigate it. I could likely keep the fort going by switching to TWBT_LEGACY or switching out of TWBT altogether, but I'm hoping to avoid that.
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.
Update: After playing around with more things, it seems switching to a different graphics pack (in my specific tests, 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.
Post by: Snafu on April 01, 2017, 05:46:06 pm
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
Quote
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) :(
Post by: Nobak on April 01, 2017, 11:07:58 pm
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) :(
I did mean crash. "Dwarf Fortress has stopped running" and all that.
The good news is, it turns out updating the tileset from v1.1 to v1.3 solved my problem. This confirms it was not an issue with TWBT.
Post by: mifki on April 01, 2017, 11:08:55 pm
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.
Sure, honestly I don't think I'll see anything useful for this particular issue in crash dump, but I'm always willing to take a look when there's a chance it's a bug in TWBT.
Post by: Nobak on April 02, 2017, 09:46:24 am
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.
Post by: mifki on April 03, 2017, 10:35:09 pm
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.
Post by: Nobak on April 04, 2017, 09:40:56 pm
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.
Post by: mifki on April 04, 2017, 09:56:21 pm
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.
Yes, just the save folder is fine. Upload to DFFD or https://www.dropbox.com/request/1kBSSkNi46HiL5Ig2GKc
Post by: Nobak on April 08, 2017, 04:10:37 pm
Loading the save in TWBT mode has crashed 12 to 14 times in a row (with a reboot partway through since that sometimes helps). Meanwhile, it has a load success rate of 1 for 1 in each of TWBT_LEGACY, 2D and STANDARD modes.
It may be worth noting that the game also flat-out crashed mid-play not long after this save happened.
I guess I have compressed saves off so the save's pretty large even after zipping.
Save is there (http://dffd.bay12games.com/file.php?id=12821)
Post by: mifki on April 08, 2017, 09:28:13 pm
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?
Post by: Nobak on April 08, 2017, 10:23:20 pm
???
Thanks. And I should use it with the latest Meph tileset, right?
As it stands, I'm using the Phoebus tileset (not sure what version, but it came with PyLNP 0.43.03-r09), altered as described in jecowa's post that I linked.
I applied the fix when I was using Meph v1.1, so I copied files from that version.
It does seem to crash with Meph's tileset v.1.3 as well, though.
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.
Post by: vanatteveldt on April 09, 2017, 04:07:51 am
I run 43.05 on linux with 0.43.05-beta1 with Spacefox_16x16_0ther.png tileset. I did the following:
- download v5.77 from https://github.com/mifki/df-twbt/releases
- unzip to a temporary folder somewhere
- copy the .plug.so files from the 0.43.05-beta1 folder to df_linux/plugins
- copy shadows.png to data/art
I ran dfhack but the fonts still look weird and none of the plugins (twbt, multilevel) are available or could be loaded.
DFHack version 0.43.05-beta1 (release) on x86_64
[DFHack]# twbt
twbt is not a recognized command.
Run 'help' or '?' for the list of available commands.
[DFHack]# load twbt
Plugin does not exist: twbt
[DFHack]# multilevel
multilevel is not a recognized command.
Again, sorry for the obviously stupid question, but I didn't really find installation instructions anywhere... (and I don't think there's an LNP for .43.05 linux yet, right?)
Post by: PeridexisErrant on April 09, 2017, 04:24:02 am
Post by: vanatteveldt on April 09, 2017, 04:42:04 am
(using hack/plugins instead of dfhack/plugins)! I love the more detailed pictures of e.g. different parts of armour, although I have to say the { and ( are difficult to distinguish from each other now:
(http://i.imgur.com/wbCnP3g.png)
One other thing that seems weird is that sometimes rough floors are given a smoothed look, and then if I move over them they disappear. On workshops it seems that it wants to give them a polished look (probably to not look out of place, but sometimes doesn't properly do so until I mouse over them.
Spoiler: screenshots (click to show/hide)
Did I do something wrong?
Post by: mifki on April 09, 2017, 06:52:21 am
Did I do something wrong?
Try "twbt redraw_all 1" command. If that helps, add it to dfhack.init
Post by: vanatteveldt on April 09, 2017, 07:39:43 am
Post by: vanatteveldt on April 09, 2017, 08:49:41 am
On the stocks screen and the dfhack manipulator (therapist) screen there are a bunch of dwarfs drawn in a strange position. For the stocks I am guessing they should be in the position of the ASCII smiley face dwarfs, and maybe for manipulator they should go with the columns? In the stocks screen its mostly harmless, but in the manipulator screen it's annoying as it makes one row difficult to read:
Spoiler: screenshots (click to show/hide)
I'm using a tiliing window manager (i3), and I also noted that after installing twbt df starts with a half-empty window until I resize, so maybe twbt has my resolution wrong?
I tried resizing, full screen, making the window floating, changing zoom level and scrolling in the manipulator, and toggling the redraw_all, but the dwarfs pictures stay in place.
Post by: mifki on April 10, 2017, 04:03:45 am
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.
Post by: Nobak on April 10, 2017, 07:52:11 pm
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.
I've updated the file again.
At this point I think I'll also try and run it from work, to see first-hand how it behaves on a different machine.
Update: I'm getting a crash at work too. The two machines probably don't have much in common besides running Windows 10.
Post by: mifki on April 11, 2017, 10:01:59 pm
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?
Post by: Nobak on April 12, 2017, 08:15:21 pm
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?
At the very end, when it transitions to the actual game. The music changes to the in-game music for maybe half a second before it crashes.
Post by: Abalieno on April 17, 2017, 06:38:15 pm
PLEASE MENTION IT SOMEWHERE.
Post by: Rydel on April 17, 2017, 07:18:11 pm
IIRC, Windows isn't even the primary development platform
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.
Post by: mifki on April 17, 2017, 07:38:48 pm
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.
He's talking about 32/64 bit support, not versions.
Post by: Abalieno on April 17, 2017, 07:39:56 pm
Each release of TWBT supports one version of DF, which is listed on the release page.
No.
Quote
Support for DF/DFHack 0.43.05-beta1
It doesn't say it only supports the 64bit one, and one assumes it works on both.
Post by: waterphage13 on April 28, 2017, 03:53:50 pm
TWBTnext:
(https://pp.userapi.com/c837529/v837529146/34685/Q8xayeA04sA.jpg)
Normal:
(https://pp.userapi.com/c837529/v837529146/346a4/jyhx4KFlRfw.jpg)
Post by: mifki on April 30, 2017, 04:11:28 pm
Post by: Nobak on May 13, 2017, 08:52:07 pm
So whatever the issue is, I believe TWBT can be eliminated as a cause.
Post by: lethosor on May 13, 2017, 09:57:04 pm
Post by: Lamandus on May 14, 2017, 04:15:16 am
I've published binaries for 0.43.05-beta2.
well done, now you can do the same for the r1, I am afraid...
Post by: mifki on May 15, 2017, 05:02:06 am
Post by: Nobak on May 18, 2017, 09:08:20 pm
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?
I had not tried, but yes, TWBT_LEGACY still crashes. STANDARD also crashes. Turning off DFHack was my last ditch effort to keep the fort going. Hey, on the plus side that's helped me really realize just how many cool features it has.
With TWBT turned off, currently the memory is just under 1600 (1588) MB when it crashes.
With DFHack turned off, it reaches 1492MB on a successful load and seems to reach the 1500s eventually while running. The flip side of the load crashes, which is that saves other than quicksave failed most of the time, also does not seem to occur with my current configuration.
This is 43.03, so a 32-bit version of everything. I suspect that this may be significant.
I'm not personally looking to fix my situation, what I have now is good enough for me even though it's not optimal. But that was already how I felt before posting here, mostly hoping it might help out. So if you think it would be relevant to look into this situation in the DFHack thread, I can take it there.
Post by: lethosor on May 18, 2017, 09:25:03 pm
Post by: mifki on May 18, 2017, 11:24:17 pm
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?
Post by: Nobak on May 20, 2017, 04:30:26 pm
So why don't you try 64bit, or are you on a 32bit OS?
My main reasons are that I'm worried about the risk of having issues if I keep playing my current world on a newer version, and from what I've read it seems Dwarf Therapist doesn't work properly on 64-bit.
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.
Neither disable -all nor "disable -all" as commands seem to work, but I can disable each of them manually in the init file. Stonesense and Tweak won't disable though ("Cannot disable plugin: stonesense"). Regardless, that still crashed.
I then tried just commenting out everything in the 3 init files I found in my folder (I have additional dfhack and onMapLoad init files with PeridexisErrant's name), but that also still crashed.
Then I just renamed the hack/plugins folder entirely. Success! Saving also works. Guess I can create a new empty plugins folder and manually add the plugins one at a time and see how that goes.
Edit: The folder has 83 plugins. Loading the first 40 works, and loading the last 43 *also* works. Either there's a conflict somewhere, or I'm just seeing a re-hash of the last times I got things running again, namely that I'm just getting things to work by trimming down my game environment and freeing resources, without actually finding a root cause.
Final edit, hopefully: Putting everything exactly as it was before, but without stonesense in the plugins folder, seems to work. It does happen to be the plugin with the largest file though, so that could be a coincidence, especially since enabling TWBT is still causing a crash with that setup. And to be clear, I was not actually using stonesense.
Post by: lethosor on May 20, 2017, 07:12:29 pm
I'm kind of surprised that Stonesense would be crashing for you at that point, since the only things it should be doing that could cause crashes if you're not using it would happen at startup. I'll look at it again to see if there's anything obvious. I don't think its file size is that relevant, unless you're almost hitting 2 or 4 GB of memory usage by DF when it crashes.
Edit: it doesn't look like it should be doing anything when a world loads, which was my best guess as to why it could be crashing. Strange.
Post by: Nobak on May 21, 2017, 09:58:16 am
So I just looked up the documentation for every plugin so I could pick and choose those I want. It wasn't enough to get TWBT back, unfortunately, but I'm sure it will keep working longer on my next fort.
Post by: gasznak on May 24, 2017, 08:31:07 am
It removes floor tiles from workshops and places them randomly on the same level as the workshops.
It looks like this:
(http://i.imgur.com/WurPDYh.png)
Moving camera sometimes fixes it. Resizing windows sometimes fixes it. However, it's back as soon as I change to z-level or move my camera again.
After I turned off TWBT the problem was gone (although all the ingame text was illegible again).
I'm using latest version of the PyLNP (starter noobpack).
Please send help! ;D
Post by: mifki on May 24, 2017, 06:48:50 pm
Post by: lethosor on May 24, 2017, 06:59:06 pm
I'm using latest version of the PyLNP (starter noobpack).
Post by: Tabris on May 24, 2017, 09:30:13 pm
Spoiler (click to show/hide)
I'm using version 5.84 included in version 0.43.05-r05 of the Lazy Newb Pack.
Post by: mifki on May 25, 2017, 12:04:59 am
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.
Post by: gasznak on May 25, 2017, 09:02:02 am
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.
Sorry for that. Here are the details:
Dfhack console states that I'm using: TWBT: version 5.84
It was a part of latest LNP release 0.43.05-r05, which you can find here: http://dffd.bay12games.com/file.php?id=7622 (http://dffd.bay12games.com/file.php?id=7622)
Hope that is enough. :) If you have any further questions, let me know.
Post by: lethosor on May 25, 2017, 09:21:42 am
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.
Post by: Tabris on May 25, 2017, 12:00:57 pm
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.
Post by: lethosor on May 31, 2017, 09:31:58 am
Spoiler: mousequery (click to show/hide)
Spoiler: resume (click to show/hide)
This should hopefully help address some of the issues mentioned above in the future.
Post by: mross on June 14, 2017, 07:54:12 pm
Post by: lethosor on June 14, 2017, 10:45:18 pm
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.
Installation is fairly straightforward - you just need to copy the plugins into hack/plugins and the images into data/art. The rest isn't strictly necessary, but might be useful. There are some directions on GitHub (https://github.com/mifki/df-twbt), and more in a pull request (https://github.com/mifki/df-twbt/pull/58/files).
Post by: Lamandus on July 16, 2017, 06:50:53 am
Post by: mifki on July 19, 2017, 05:45:51 pm
Post by: Romeofalling on July 22, 2017, 02:44:36 pm
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.
Post by: Arcturus on July 27, 2017, 12:15:40 pm
EDIT : Nevermind I think I've figured it out.
It seems I'm missing a file called core.h, is this available?
Why didn't you make a 32 bit version? It's like just a couple clicks in visual studio and some waiting time.
Post by: Rose on July 27, 2017, 01:29:53 pm
Post by: lethosor on July 27, 2017, 02:11:56 pm
Post by: mifki on July 27, 2017, 04:01:56 pm
Because nobody uses 32bit windows.
Because Arcturus forgot about some clicks also required to find all the addresses for 32bit.
Post by: mifki on July 27, 2017, 04:02:46 pm
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.
There should be a ReadMe file in the package, or here https://github.com/mifki/df-twbt/blob/master/README.md
Post by: Moogie on August 05, 2017, 06:35:07 pm
I am using the
But ingame, the graphics still look like this (http://i.imgur.com/QpKLPHF.png), where periods are appearing as grey boxes. Am I missing a step? A few posts back, the creator mentions that installation is as easy as dropping the plugin files in the correct directories- which they are, by default, in the LNP. So I'm not really sure what to do from here. This is all a bit over my head, but I can follow technical instructions pretty well if anyone knows what's wrong and can guide me in the right direction.
Thanks for any and all help!
Post by: lethosor on August 05, 2017, 07:11:19 pm
You might not have set your print mode setting to TWBT (that should be in the launcher). TWBT should log something on startup if that's the case, but there could be another issue.
Post by: Moogie on August 05, 2017, 07:20:43 pm
I will say that the tileset I am using is very old (JollyBastion) and not supported for this version of DF, but my understanding of TWBT is that it shouldn't matter, since the whole point of it is to fix this problem with tilesets replacing their letters with graphics.
My settings in the raw:
[FONT:jolly9x12.png]
[FULLFONT:jolly9x12.png]
[GRAPHICS_FONT:curses_square_16x16.png]
[GRAPHICS_FULLFONT:curses_square_16x16.png]
Does this look correct?
--------
Just coming back to say I figured out the problem, I think. So because the Jolly Bastion tileset has no seperate text-only version, that's why it can't find certain letters/punctuation that aren't graphical tiles. In order to fix that I would somehow need to create a seperate file that only has the Jolly Bastion alphabet. I tracked down the font (SMW2: Yoshi's Island) and tried using the Font Generator Tool, but I couldn't figure out how to get it to use the Yoshi font that I had downloaded and installed onto my system. Maybe I need to reboot before it works, so I'll try it again tomorrow.
Anyway, all that is to say TWBT is working properly, I think? Problem appears to be user error. Sorry to trouble you. :)
Post by: mifki on August 06, 2017, 04:43:07 am
[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.
Post by: Fleeting Frames on August 06, 2017, 05:29:03 pm
Post by: Jerry The Hellbound on August 06, 2017, 06:04:03 pm
Post by: Moogie on August 06, 2017, 09:21:48 pm
[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.
Yes I wanted to use JollyBastion's font and graphics, but also wanted to avoid the common "fullstop = box" etc issues that graphical tilesets often have. But I misunderstood what the tool was capable of and didn't realise what I was trying to do was impossible.
--
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.
So If I do that (graphics = Phoebus, font = Curses) all the graphics look like basic ASCII and the ground looks like periods.
Spoiler (click to show/hide)
But if I use Curses for the graphics_font and Phoebus for the font, I get the tileset graphics, but the alphabet suffers from square-box syndrome.
Spoiler (click to show/hide)
So... I'm sorry if I'm doing something very stupid, but I really don't understand what I'm doing wrong here. Could some kind soul please guide me on how to get the nice graphics of Phoebus, including the smooth non-period floors because they hurt my eyes, but have a full set of working letters/punctuation for the text?
Post by: mifki on August 06, 2017, 11:36:21 pm
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.
Can you post your full init.txt and copy or screenshot of dfhack console?
Post by: Moogie on August 07, 2017, 03:03:02 pm
So here is font = curses, graphics = phoebus:
Spoiler: screenshot (click to show/hide)
Spoiler: init.txt (click to show/hide)
And this one is font = phoebus and graphics = curses:
Spoiler: screenshot (click to show/hide)
Spoiler (click to show/hide)
Thank you for taking a look :)
Post by: mifki on August 07, 2017, 05:21:05 pm
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.
GRAPHICS should be set to YES. It may be unclear (although logical - GRAPHICS_FONT is used only when GRAPHICS is YES), and in the next version (that is, Next, you can as well try it http://www.bay12forums.com/smf/index.php?topic=163298.0) it is not required.
Post by: Moogie on August 07, 2017, 06:18:02 pm
Thanks for the help, mifki. That solved the problem and now everything looks lovely. You're the best!
Post by: Jerry The Hellbound on August 11, 2017, 09:47:16 pm
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)
Post by: mifki on August 12, 2017, 05:40:58 am
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)
Sorry, all I can say now is that advfort isn't supported. I'll take a look once I have time.
Post by: Jerry The Hellbound on August 12, 2017, 07:20:35 pm
Post by: kotler on September 19, 2017, 07:28:55 pm
should I make bugreports about 5.x version, if 6.x version fixes problem ?
Black screen with dfhack plugins:
(1) gui/mechanisms: [q] on lever, then type `gui/mechanisms` in console (or [ctrl]+[m] by default in PyLNP)
(2) devel/unit-path: [v] on creature, then type `devel/unit-path` in console
problem actual for TWBT v.5.86. In TWBT.NEXT v6.20 all works fine
Post by: lethosor on September 19, 2017, 09:26:18 pm
Post by: mifki on September 20, 2017, 09:06:58 am
Post by: Clyybber on September 23, 2017, 05:25:17 am
Post by: Jazz Cat on October 03, 2017, 09:36:36 pm
Post by: mifki on October 03, 2017, 11:16:56 pm
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?
That's how it is at the moment.
Post by: Thundercraft on October 07, 2017, 03:55:07 am
More important than specifying why the mod was written, more important than detailing all the features, even more important than specifying what a mod does and what it is for, is how to actually use (i.e., install) it. This forum topic also lacks install instructions. The OP does say, "See readme for all details" and I find that rather ironic, considering...
Don't get me wrong, I love TwbT! It's amazing! I have deep respect for the effort and ingenuity it took to make this. But it would have be greatly appreciated if we were walked through how to install it. Not all of us are DFhack wizards who know intuitively how to use these files.
What I've been able to learn through trial and error (and examining TwbT-based graphics sets) is the following:
- This is not mentioned anywhere, but I believe that recent releases of TwbT are 64-bit only. I tried installing recent releases for 32-bit DFhack 0.43.05-r2, but the DFhack console always gives me the "Can't load plugin twbt" error and won't run. Though, I can get it to work for 64-bit DF/DFhack.
- The most important thing is to copy the twbt.plug.dll file into your /hack/plugins/ folder, making sure that you have the right version for your DF and DFhack. The download will have a folder with a name like "0.43.05-r2", which is the version of DFHack it was compiled for.
- Copy the .png images from the download's root folder into your /data/art/ folder. Actually, I do not believe that TwbT-based graphics sets like Dungeon Set (http://www.bay12forums.com/smf/index.php?topic=152766.0) or Meph Tileset (http://www.bay12forums.com/smf/index.php?topic=161047.msg7212189#msg7212189) use most of these .png files. However, recent TwbT releases do require transparent1px.png and white1px.png or it refuses to run, so those two are absolutely necessary.
- The readme does explain: "In your init.txt set FONT and FULLFONT to the font you want to use for text, and GRAPHICS_FONT and GRAPHICS_FULLFONT to the font for map tiles." That said, TwbT-based sets like Dungeon Set (http://www.bay12forums.com/smf/index.php?topic=152766.0) and Meph Tileset (http://www.bay12forums.com/smf/index.php?topic=161047.msg7212189#msg7212189) include a custom init.txt file, so that's normally not an issue if you use them.
- The readme does explain how the TwbT Override commands are used and says that these "are to be placed in data/init/overrides.txt file". But, again, TwbT-based sets include a custom overrides.txt, so it should be a non-issue if you're using TwbT with one. This means that if you copy over the overrides.txt from your graphics set with the one inside the TwbT download, it will completely fail to work! For this reason, it is wise to install TwbT first, then your TwbT-based graphics set.
- If you want to take advantage of TwbT's elevation feature (and I suspect that's most of us), then you will need to specify something like "multilevel 10" in a dfhack.init file in your DF root folder.
- Note: If installing your TwbT-based graphics set involves changing anything in your /raw/ folder and/or subfolders (such as /objects/) and you are continuing an existing save, then you will need to remember to make the same changes to the /raw/ folder and/or subfolders inside your saved games. Dungeon Set and Meph Tileset both does this. AFAIK, most graphics sets do change /objects/, such as the tiles used for creatures, so this affects almost everyone. In my case, since I'm also using Meph's Seasonal colors (http://dffd.bay12games.com/file.php?id=12563) addon, I also had several "colors" files in the root /raw/ folder to copy over. (At first, I was confused why the tileset was not displaying the colors like it did in earlier versions. Also, I needed "season-palette start" in my dfhack.init file.)
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?
Post by: mifki on October 07, 2017, 05:30:58 am
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?
Yes, they are required in most cases due to the way how rendering works now. And unfortunately they have to be separate image files (i.e. I can't generate them in memory) because they have to be loaded by the same DF internal functions that load all other tileset files.
Post by: Thundercraft on October 07, 2017, 08:44:49 am
Am I correct in believing this to be the fault of the plugin? If so, should this be considered either a bug, a known issue, or intentional? If this is an issue, are there plans to look into it?
Post by: Fleeting Frames on October 07, 2017, 08:49:27 am
Post by: Thundercraft on October 07, 2017, 09:07:53 am
It'd probably help if you mentioned what screen capture utility you are using?
The specific screen capture utility I tried was Greenshot (https://sourceforge.net/projects/greenshot/?source=directory). However, you seem to be misunderstanding:
- Dwarf Fortress has a built-in capability for screen capture. See the wiki article: Screenshot (http://dwarffortresswiki.org/index.php/Screenshot). As a test, I installed plain vanilla Dwarf Fortress fresh from the download and tried both [Print Screen] and [Alt] + [Print Screen], pasting the clipboard into Paint.Net. It works just fine, regardless, whether I have DF as Windowed or Fullscreen. The only time this did not work for me was when I was using Meph Tileset in Fullscreen mode.
- I also tried Greenshot (https://sourceforge.net/projects/greenshot/?source=directory), in desperation. Not even that would work with Meph Tilset installed and in Fullscreen. Maybe there is a screen capture utility out there, somewhere, that can capture DF with TwbT running in Fullscreen, but I doubt it. Regardless, no screen capture utility should be needed since DF already supports screen capture.
This is what Greenshot captured when I chose the "Capture window from list" option when I left DF + Meph Tileset in fullscreen, running in the background. (Click thumbnail for larger image.):
(https://s1.postimg.org/5b6k6g0q0b/Meph_Tileset_fullscreen_window_capture.png) (https://postimg.org/image/5b6k6g0q0b/)
Post by: Fleeting Frames on October 07, 2017, 10:10:15 am
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.)
Post by: Thundercraft on October 07, 2017, 10:52:50 am
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.)
I tried recording a CMV and playing the result. However, aside from the screen flashing a lot, the left-most panel - the one that displays the Meph Tileset - is a blank field of black. I then use the CMV Movie Editor (http://dwarffortresswiki.org/index.php/Utility:Dwarf_Fortress_Map_Archive#CMV_Movie_Editor) to watch the CMV. It was the same, except without the flashing.
Actually, I get the same result (field of black in left-most panel) when I record a CMV with Meph Tileset in Windowed mode.
Then I read this on the wiki in the Utility:Dwarf Fortress Map Archive (http://dwarffortresswiki.org/index.php/Utility:Dwarf_Fortress_Map_Archive#Uploading_a_movie) article, under the "Uploading a movie" heading:
Quote
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.
Since that's the case, now I'm wondering whether or not screen capture in Fullscreen will work with any graphics set, regardless of whether it uses TwbT...
Edit:
On thinking about this further, I recall how graphics sets modify a whole bunch of files in the /raw/objects/ folder, mostly to change the Tile for creatures and plants and such. Perhaps, when it does this, it changes all tiles to black so that the usual tile display method does not interfere with displaying the graphics set? Maybe that's why CMV movies won't record right with a graphics set?
Still, it seems strange that pressing [Print Screen] will capture the screen just fine in Windowed mode, but not in Fullscreen mode. I'd be nice if someone would test this out in Dungeon Set and some other graphics set so we can determine whether this is a TwbT issue, a Meph Tileset issue, or if it affects all graphics sets equally.
Post by: Breinhardte on November 13, 2017, 05:22:07 pm
Is there some kind of error log I can check when it crashes?
Post by: mifki on November 13, 2017, 06:01:52 pm
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?
Post by: Breinhardte on November 13, 2017, 07:56:02 pm
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?
Thanks!
TWBT, the latest version (I think) 6.21.
Post by: cltail on November 15, 2017, 08:57:50 pm
Spoiler (click to show/hide)
if you go into a separate menu or otherwise cause a reload of the screen it is fixed, but it is just far too annoying to deal with.
Edit: I had to restart my computer due to a nasty bug in another game, and it turns out that fixed my issue, which is odd because older versions of TWBT still worked fine.
Post by: PeridexisErrant on November 24, 2017, 05:31:23 am
Post by: mifki on November 24, 2017, 06:09:02 am
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?
I need to fix my build system after OS update and all, and I'll make it.
Post by: mifki on November 25, 2017, 05:05:25 am
Post by: jecowa on December 04, 2017, 12:15:25 am
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
Post by: lethosor on December 04, 2017, 01:31:24 am
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.
Post by: Amostubal on December 04, 2017, 05:31:44 am
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
Jecowa - Spacefox-next version he put in there is way incomplete compared to the fulll spacefox pack... and it really only changes a handful of things (switches, boulders, and a few others as a technical display) I went back and buffered all the other stuff usually in a spacefox folder, into a version I have in LDF. I meant to do the same for MMDF before I stopped production, just saying. I also thought about going back and doing all the masks for the other items but never got to it. Really I would love to see a spacefox-next that was complete.... but also a spacefox that didn't need so many overrides ( I know thats a lot to ask for ).
Post by: mifki on December 04, 2017, 03:07:53 pm
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
They're included in TWBT package. You shouldn't change them, consider them internal TWBT stuff.
Post by: jecowa on December 07, 2017, 07:02:02 pm
Post by: Lamandus on December 08, 2017, 09:29:52 am
Post by: endoftheline on December 08, 2017, 09:42:08 am
Post by: lethosor on December 08, 2017, 10:22:18 am
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.)
Post by: endoftheline on December 08, 2017, 10:32:59 am
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.)
Only one I've managed to isolate so far is getting divine metal as layer material in worldgen, but I've had 5 out of 100 worldgens crash somehow, which I haven't got around to reproduce yet. I'll submit the divine mat thing in a bit, I wasn't sure if develop was in good state enough yet to submit bugs for it.
Post by: Quietust on December 08, 2017, 05:51:50 pm
Post by: jecowa on December 09, 2017, 01:13:31 pm
To use, you have to switch your GRAPHICS_FONT to to "Phoebus_16x16_Next.png" or "Spacefox_16x16_Next.png". "Phoebus_16x16_4K.png" and "Spacefox_16x16_4K.png" will also do it too (they're just 200% nearest-neighbor upscales for people with hi-res displays.)
Post by: mifki on December 09, 2017, 07:47:27 pm
Post by: YetAnotherLurker on December 10, 2017, 02:35:29 am
Post by: jecowa on December 10, 2017, 03:36:31 am
I haven't tested, but here's the vanilla raws version of what Meph uses for the Bookcase:
[OVERRIDE:240:I:TOOL:TOOL:13:_overridesfile_:2]
I'm kind of suspicious about it being marked as "I" instead of "B", but it's not like I really understand how they work. And if that was wrong it probably would have been noticed before now.
I'm kind of curious about how to override the new Pedestal and Display Case if any has found the Overrides codes for either of them.
Post by: Clément on December 10, 2017, 04:12:48 am
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>]
[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.
Post by: YetAnotherLurker on December 10, 2017, 06:51:22 am
Post by: Amostubal on December 10, 2017, 11:27:03 am
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>]
Ooooohhhhhhh NICE!!!!!!!!!!
I need that, Is it apart of a large script or did you upload it somewhere? That needs to be a part of the DFHack or TWBT scripts.
Post by: Clément on December 10, 2017, 11:49:09 am
You can also add
Code: [Select]
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 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.
Post by: endoftheline on December 10, 2017, 05:27:49 pm
Post by: Amostubal on December 10, 2017, 08:26:50 pm
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.cursorto 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.
I will admit I got a little excited at first, Yeah I can see this needs a little more work. I can put it in the list of stuff I'm writing and see if I can get it up to working order, give it a full wrapper so you only need to make one call and have it display for whatever is selected. If you don't mind me jumping on the concept. It may take me a bit of time, I have many commitments, probably a week.
Post by: Clément on December 11, 2017, 05:38:17 am
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.
Post by: mifki on December 11, 2017, 06:05:33 am
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.
Right, please don't use IN_PLAY, that will be terribly slow (well, computers are fast now, so at least terribly inefficient). For all items/buildings there should be only one id (apart from generic ones) that in most cases named after item/building type, so it should be easy to find. As I understand, the problem is only with the new display furniture because its id is not named properly in dfhack yet.
I'll eventually reimplement overrides more efficiently which is now possible with the "Next" version, and override specification will be simplified too.
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)
That's cool, I was going to do that for a long time, maybe now I'll finally automate patching for other platforms as well.
Post by: Amostubal on December 12, 2017, 11:26:31 pm
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".
Post by: jecowa on December 13, 2017, 01:10:34 am
I really want to know exactly the meaning of this line... I am really interested in what you have planned "Next".
It's in the second screenshot of the OP:
Spoiler: screenshot example of TWBT-Next (multi-layer rendering) (click to show/hide)
Tips if you can't figure out what's going on in the screenshot:
- Look at what is underneath the chairs and the caskets.
- Also look at the color of the blades of the weapons on the weapons rack. Look at the color of the sheets on the bed and the color of the armor on the armor stand.
I'm really interested in those simplified Overrides. Those things are kind of hard for me.
Post by: Clément on December 13, 2017, 08:38:38 am
Post by: Acolyte on December 14, 2017, 10:29:18 pm
- Shane
Post by: point08 on December 15, 2017, 02:15:18 pm
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.
Post by: mifki on December 15, 2017, 04:15:23 pm
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.
Post by: Meph on December 16, 2017, 12:59:33 am
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.
Post by: jecowa on December 16, 2017, 09:03:04 am
Post by: mifki on December 16, 2017, 04:39:39 pm
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.
I'm not sure about corpses, need to investigate how it works at all. But vermin and pets should work, they're definitely among the classes I override rendering of to implement transparency. I'll check them.
Post by: Meph on December 20, 2017, 10:22:53 am
Post by: lethosor on December 20, 2017, 11:06:25 am
Post by: Meph on December 20, 2017, 11:31:28 am
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.
Post by: AikonCWD on December 20, 2017, 12:07:17 pm
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.
Post by: lethosor on December 20, 2017, 01:35:01 pm
Post by: Meph on December 20, 2017, 02:12:23 pm
Post by: mifki on December 20, 2017, 02:24:20 pm
Sorry if I was unclear. I'm looking for a fix for that issue.
Yeah, I remember. Try v6.26.
Post by: Meph on December 20, 2017, 03:49:38 pm
Edit: Tested it thoroughly, there are a few minor bugs, especially when several overrides happen on the same tile. I identified 5 sources, besides the "doesn't work on vermin/creatures":
Spoiler (click to show/hide)
Not sure if any of them can be fixed. They are not a big issue, I'm very happy with how most thing look ingame now. The only one that I see often ingame is when you make a stockpile over a plant... the stockpile sprite disappears and shows the plant instead, which looks a bit odd. But still works perfectly well as stockpile and reverts back once an item is put on the tile.
I once asked you about an upper limit on tilesets in data/art. Could you elaborate on that? How many sets it too many? I have 10 sets at 512*512px at the moment. I could easily get to 15, if I continue making things transparent.
Post by: mifki on December 21, 2017, 08:58:43 am
1. "Transparency on top of terrain features". I didn't quite understand what this means, sorry.
2. "Multilevel breaks transparency". This should definitely work, I'll check.
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.
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).
5. "Items on slopes". This is strange, I'll check it.
Can you upload the save you used to make these screenshots, including raw folder and art/init folders?
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.
Post by: Meph on December 21, 2017, 09:18:10 am
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.
Post by: mifki on December 21, 2017, 09:28:12 am
Post by: Meph on December 21, 2017, 10:33:10 am
I created a new save and replicated both bugs. It's DF 44.02 with the newest dfhack alpha and TWBT 6.26. When you open the save, you look right at it.
Here is a screenshot:
Spoiler (click to show/hide)
I would love to say that the "item on override tile" bug isn't really that bad, but... siege engines, machines and minecarts/tracks do look really odd due to it.
Post by: mifki on December 23, 2017, 06:13:41 pm
Here is a screenshot:Spoiler (click to show/hide)
I've fixed 1. - want to do some optimisations and will release a new version then. However, why do you need to override up-ramps at all?
And spatters in 2. seem to change tile symbol, you can see that if you disable TWBT. But the spatters on the right don't change tile. Don't know why, but that's the reason overrides don't work for the wall.
Post by: Meph on December 23, 2017, 08:49:34 pm
It also frees up more space in the main tileset, which can then be used for things that can't use overrides, like vermin or creature tiles.
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. ^^
Post by: mifki on December 24, 2017, 07:58:34 am
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. ^^
1. was about items on top of overridden terrain tiles. Carried items may be different, I need to check.
Post by: Evillee03 on December 25, 2017, 12:38:14 am
Post by: mifki on December 25, 2017, 01:47:29 am
Always crashes on me when travelling
Whick version (printer in dfhack console on launch)? Try the latest from https://github.com/mifki/df-twbt/releases
Post by: Lamandus on December 26, 2017, 12:34:33 pm
Post by: endoftheline on December 26, 2017, 12:39:57 pm
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.
Post by: Lamandus on December 26, 2017, 01:03:48 pm
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.
no sweat. I love what you do for the project and for the community. I am a modder myself (other games), users like me can be tireing, I don't want to be ^^ I am only afraid the new update (of DF-H) may fall under the radar (which rarely occures).
My fort right now takes enough time to let all those 200 visitors out again... so this can happen in ascii.
Post by: Meph on December 28, 2017, 06:13:51 pm
Anyway, it seems that they work for vanilla workshops, like
Code: [Select]
[OVERRIDE:236:B:WORKSHOP_KITCHEN:Workshop::_MDF_overrides_1:155:16] but they dont work for custom workshops, like Code: [Select]
[OVERRIDE:164:B:WORKSHOP_CUSTOM:Workshop:GARDEN_SMALL_PLANT:_MDF_overrides_4:164] Anything wrong in the syntax you could see? in this example, GARDEN_SMALL_PLANT is the workshop ID from the raws.
Post by: Clément on December 28, 2017, 07:08:20 pm
I guess you can work around that by changing the tiles in the raw with something not used by any other custom workshop.
Edit: Nevermind, there is a special case for custom workshop/furnace. I don't see what you did wrong then.
Edit2: Try running this dfhack script (https://gist.github.com/cvuchener/c176e7d0bee18e5c6c75c7ac5bded6f7) while selecting the custom workshop.
Post by: mifki on December 29, 2017, 02:17:01 am
Post by: jecowa on December 29, 2017, 03:01:24 am
I was away for several days, version 6.27 is available now for 0.44.03-alpha1
Oh, nice!
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…
What's the disadvantage of letting tileset authors control this? I think it would be nice to have the option. You could make a carpentier's shop with a saw-dust-covered natural floor (light-brown pixels spread out over whatever floor is beneath it.) I think people want transparent backgrounds. In Doren's workshop overrides in Phoebus, for example, he used the normal Phoebus smooth floor tile as the background so it would blend in better with the floors it would probably be used with most. Even though it makes workshops harder too see, I think it'd be cool to be able to have workshop tiles sitting on the grass. Having a tile floor out in the grass seems kind of strange. A partially-transparent background for workshops might be a nice middle-ground to have them be a bit more visible, but still have them blend in pretty good.
Spoiler: tilefloor workshop on grass (click to show/hide)
…(and I guess for some other types of buildings too, stockpiles maybe).
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.
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.
As it is, my laptop can't run three graphics packs: Meph, Mayday, and (I think) DungeonSet. But if I delete the creature graphics, it fixes it.
Post by: Meph on December 29, 2017, 03:06:58 am
Post by: jecowa on December 29, 2017, 03:35:14 am
What are the Building IDs and Building Types for the new Pedestal and Display Case buildings?
They both seem to use this:
Code: [Select]
[OVERRIDE:<old_tile>:B:DISPLAY_CASE:DisplayFurniture::<tileset>:<new_tile>]
Maybe a subtype will let you select a particular one.
Thanks to Clément for the spell.
Post by: Meph on December 29, 2017, 05:08:51 am
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.
Post by: mifki on December 29, 2017, 05:18:31 am
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.
Partially-transparent stockpile may be nice, right. 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).
But I can easily add an option to completely hide stockpile tiles unless in [q]/[k]/[p] modes.
Post by: mifki on December 29, 2017, 05:24:40 am
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.
Is it with 0.44.03 and the TWBT 6.27? For me with these versions your override for a screw press does work.
Post by: Clément on December 29, 2017, 05:50:01 am
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.
Or my script is not very good at picking the best ID. Maybe I should go back to the first version when I printed every possible ID, letting the user choose the best one intelligently.
Post by: jecowa on December 29, 2017, 05:56:48 am
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!
Post by: jecowa on December 29, 2017, 06:27:54 am
Post by: Meph on December 29, 2017, 07:43:27 am
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.
Mifki, I did indeed use the (slightly older) version 6.26 on 44.02. I downloaded and tested the new build, 6.27 for 44.03 and the issue is fixed. Everything is fine with the custom workshops. :)
Does this new version also have the creature transparency you mentioned once?
Post by: mifki on December 29, 2017, 08:33:16 am
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.
Post by: mifki on December 29, 2017, 09:24:40 am
Post by: Meph on December 29, 2017, 09:45:34 am
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.
Post by: mifki on December 29, 2017, 10:12:00 am
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...
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.
Still as all tiles they have foreground and background colours, and to be able to render bg colour, I need a -bg image. That's why I asked you whether bg colour is used for units (sprites) or not.
Post by: lethosor on December 29, 2017, 10:13:35 am
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.
Post by: Meph on December 29, 2017, 10:29:36 am
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.
The constructed pedestal/display-case takes on the tile of the item_tool:pedestal/display-case. In vanilla that's 139 and 227. In my tileset I use overrides for all tools, so they are all set to 255 to only use a single tile in the main tileset. That's why I assumed that the buildings use the same tile.
Post by: jecowa on December 29, 2017, 10:37:43 am
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.
Nice!
Where do I put these commands to enable it? I've tried typing in the Terminal window, but it says I can't do that:
[DFHack]# twbt redraw_all 1
twbt is not a recognized command.
twbt is a plugin but does not implement any commands
[DFHack]#
Edit: Oh, I figured it out; I have to set Print Mode to TWBT first. :P
Post by: Meph on December 29, 2017, 10:41:56 am
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...
Post by: mifki on December 29, 2017, 06:57:51 pm
Post by: Meph on December 31, 2017, 08:37:28 am
(https://i.imgur.com/EAvemGM.png)
If the vermin is on top of a floor, it does not work.
If the vermin is on top of another item, it does work, but shows the floor instead of the item.
Example above has a worm on the same tile as a nestbox, and voilà, the vermin has transparency.
Maybe it helps you figuring out creature transparency.
Post by: mifki on December 31, 2017, 07:57:52 pm
Enabled with "twbt unit_transparency 1" and "twbt workshop_transparency 1" commands.
Happy New Year!
Post by: jecowa on December 31, 2017, 09:45:17 pm
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?
Post by: mifki on December 31, 2017, 10:01:42 pm
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?
Yes.
Post by: Meph on January 01, 2018, 04:32:13 pm
Btw, is there any reason there are overrides for magma-smelters and magma-forges, but not for magma-kilns or magma-glass-furnaces?
Post by: Vordak on January 01, 2018, 05:06:48 pm
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)
Post by: jecowa on January 01, 2018, 05:30:44 pm
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)
Mifki figured out how to interact with creatures in TWBT?? I thought it was impossible?
Edit: Oh, here's the release notes for it:
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.
It's off by default, so I guess unit transparency has a similar drawback to transparency in workshop:
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).
Post by: Meph on January 01, 2018, 05:47:37 pm
Post by: jecowa on January 01, 2018, 05:56:28 pm
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?
Post by: mifki on January 01, 2018, 06:13:19 pm
However there's a limitation that only two layers are rendered - so for terrain - building - unit it will be either terrain - unit (6.30) or building - unit (6.31). Yes I uploaded version 6.31 to try and see the difference. Can't do anything about it until I implement rendering of all three layers. The same with items by the way.
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.
Post by: Meph on January 01, 2018, 06:22:35 pm
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?
Post by: Meph on January 01, 2018, 06:28:25 pm
The hardcoded workshops usually only offer 3-5 tiles to override, out of 9. The rest I can't touch with tile numbers. I did my best, and the results look like this:
Spoiler (click to show/hide)
Please look at the soap maker. It's the only one that allows replacing all 9 tiles. You see how large the difference is. It would make workshops so much clearer to spot and so much easier to design if all could be made like this.
Post by: jecowa on January 01, 2018, 06:41:31 pm
Spoiler: DragonDePlatino's workshops (click to show/hide)
Post by: jecowa on January 01, 2018, 07:32:25 pm
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.
Yeah, it doesn't seem that big of a deal if one of the items they are standing on becomes obscured. It's not going to be very visible anyway, and it's much better than the alternative of not having creature transparency at all.
Post by: Meph on January 02, 2018, 01:24:41 am
Spoiler (click to show/hide)
Edit: Did first tests with the -top and -bg files for creatures and workshops. It's amazing, thank you so much. :)
From my point of view, it adds three major improvements for the player/artist.
- Workshops can blend in better.
- Workshops can slightly alter otherwise identical tiles, by using different colors, mostly in the Dyers shop.
- Creatures blend in better, especially small ones. Now it's perfectly fine to make creatures that are only a few pixels large, since you don't have to cover that much boring background up.
Spoiler: Dyer and magma forges (click to show/hide)
Spoiler: Creature transparency (click to show/hide)
Edit: I just opened a test-fort and had a creature-graphics.png without any -bg file for it.... and the transparency still works. I just made the normal creature file transparent, without a background.
Seems that the -bg file is unnecessary for creatures. Just to put that out there. Would be nice of a second person to confirm. :)
Post by: jecowa on January 04, 2018, 05:30:36 pm
Post by: mifki on January 04, 2018, 05:51:11 pm
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].
Post by: jecowa on January 04, 2018, 07:28:02 pm
Post by: mifki on January 04, 2018, 07:48:31 pm
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.
Thanks, I thought about that too, it's all good then I hope.
Post by: jecowa on January 04, 2018, 07:49:35 pm
(https://i.imgur.com/S0tkQZF.png)
Tergel 16x with unit transparency enabled.
Post by: Meph on January 05, 2018, 01:53:06 am
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].
Post by: jecowa on January 05, 2018, 07:19:58 am
Spoiler: nwkohaku birds (click to show/hide)
Post by: Rose on January 05, 2018, 07:21:18 am
Post by: mifki on January 05, 2018, 07:33:27 am
Or maybe it only loads the parts that have graphics defined for them?
No, DF load function just loads all the tiles, it doesn't know at that moment which of them will be used. I mentioned this before but for map and overrides tilesets, the same for creatures. So yeah if you're editing the files anyway, it's worth compacting the tiles.
Post by: mifki on January 05, 2018, 06:45:32 pm
1. Hide stockpiles (background, not items of course) unless in [q], [p] and [k] modes. Enable with "twbt hide_stockpiles 1".
2. Optional workshop transparency (like for other buildings). Enable with "twbt workshop_transparency 1".
3. Optional unit transparency. Enable with "twbt unit_transparency 1".
4. Not new feature but I reminder that if there are rendering issues when moving the map, use "twbt redraw_all 1".
Post by: jecowa on January 05, 2018, 08:34:50 pm
Post by: simast on January 06, 2018, 08:43:07 am
Post by: Meph on January 06, 2018, 09:20:56 am
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.
Post by: mifki on January 06, 2018, 09:55:43 am
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.
Oh right, vermin they are completely separate and rendered separately... I guess I'll have to ask Toady to make it possible to intercept their rendering too like for units.
As for bookcases, I don't know, B:UNK_V42_2:Bookcase:: should work, I'll check tomorrow if it doesn't.
Post by: Meph on January 06, 2018, 10:13:48 am
The UNK_V42_2 did work, it was just an inverted tile using the background color... so it appeared solid black. DF sometimes does this, with bookcases, track stops, display cases. I solved it by forcing a different color. All good.
Btw, you could consider adding the print-twbt-override script in your download. It's extremely useful, there would have been zero chance to otherwise find out about UNK_V42_2. Or the traps... because I just found out that you can override individual trap types. Which is A: fantastic and B: no one has done that yet.
(https://i.imgur.com/Os9ylL5.png)
:)
Post by: Amostubal on January 06, 2018, 11:18:14 pm
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.
Post by: Meph on January 07, 2018, 04:00:15 am
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.
Post by: milo christiansen on January 07, 2018, 12:26:57 pm
See Libs/Melt Item (https://github.com/milochristiansen/rubble8/tree/master/std_lib/addons/Libs/Melt%20Item)
Post by: Meph on January 08, 2018, 12:20:00 pm
There are 4 instrument types: Keyboard, Wind, Stringed and Percussion. The IDs are procedually generated. The outputs of print-twbt-override are:
Code: [Select]
I:INSTRUMENT_STATIONARY:INSTRUMENT:#:
B:UNK_V42_3:Instrument::First one is the item, with a number for the sub-type. I saw that go up to at least 85 in my test-fort.
Second one is the constructed instrument. A subtype for that I can't figure out.
I could either do 4 sprites for the 4 types, or a random assortment that is applied to the procedually generated ones without actually fitting the description, but it would at least add nice visuals to the game.
Post by: Isher on January 08, 2018, 02:03:45 pm
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.
So thanks to you both (mifki for TWBT and Meph for the integration), I love being able to see lower levels and if I go high enough it's sortof 2.5D Dwarf Fortress. Tried stonesense overlay instead and it isn't super usable and I don't really like how it looks (I keep the visualizer up still on the side, I don't mean to denigrate it).
I've looked through the source code but I'm out of my depth, and I'm curious:
Is it theoretically possible to see levels that are higher than the current one, while allowing clickthrough to the current one of course? (with extreme transparency perhaps). I'm thinking just sortof a suggestion as to what is above the current level. I understand that in some mountain forts that many extra layers would combine to make certain areas unviewable so it'd probably need to be limited to a certain number of layers, but it would be nice to be able to see sortof a full view of what is going on.
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:
Spoiler (click to show/hide)
Post by: jecowa on January 08, 2018, 09:00:34 pm
(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.
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 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.
Multi-level rendering also took some getting used to. Seeing how wide the branches above are could be nice. And being able to see the land over the chasms would be nice too.
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)
Post by: Isher on January 08, 2018, 09:42:17 pm
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 think the first is the general density, the second is the fog level that it starts out at (0 for the first layer so no fog) and the last is the strength of intensity added to each step. 0.25 makes the fog denser, but you can lower the last value to have less variation between layers or increase it for more variation. I just wanted it to be more dense so I don't get as confused when trying to traverse layers.
Quote
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.
I wanted to try to convey that by lightening the layers I was adding but without spending an hour masking the tree layer it made the whole picture lighter so I just put it up as is. But yeah, I'd like to see some sort of clear-translucent vibe going for the layers above you, almost like the wireframe you'd get for some games when looking through a house or whatever. If it's at all possible I'd love to see mifki give it a shot if he's interested. If not, well, I've
Post by: Isher on January 09, 2018, 07:57:41 pm
Core.h is part of DFHack. You would have to clone DFHack too and point the solution file to it somehow.
I've moved files around and installed nuget packages and yadda yadda and I think if I can just point to my built DFHack (instead of moving its built files into the TWBT folder like a neanderthal) it'll solve some of this "wrong protobuf" version and all the other crazy hell that is raining down on my ability to build TWBT. I've pointed to dfhack-version.lib and SDL.lib correctly but still with the Core.h file missing and etc. Can anyone steer me in the right direction (pointing the twbt file to DFHack)?
Post by: mifki on January 09, 2018, 08:11:19 pm
Post by: Isher on January 10, 2018, 12:03:24 am
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.
Post by: Warmist on January 10, 2018, 01:42:35 am
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.
- You need to do something when game wants to render the game view, for that we use vmethod interposing: e.g. This gets called (instead) when fort-mode view is rendering (https://github.com/DFHack/dfhack/blob/master/plugins/rendermax/rendermax.cpp#L71)
- Set window to where you want to render (e.g. in this case z+1)
- In that function you need to call "df-render-map" function, which mifki found.
- Read the screen and save it(?)
- Call original vmethod to perform "real" render
- do something with saved screen (e.g. somehow blend the tiles?)
Sorry if it's not twbt-like i've looked into that code quite long ago and can't quickly find relevant examples.
Post by: Meph on January 10, 2018, 02:16:57 am
Post by: Warmist on January 10, 2018, 02:27:37 am
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 :|
Also currently i have mutilated the rendermax to make a opencl powered monstrosity (which worked btw) but then wanted MORE and now too lazy to put it back together...
Post by: Meph on January 10, 2018, 02:41:55 am
Post by: mifki on January 10, 2018, 03:18:09 am
As for rendering levels above, it should be easy to do, well, just modify twbt to render levels above as well and give them some transparency. However I'm not sure it will work well in general case - trees look fine but what about everything else?
Post by: Meph on January 10, 2018, 03:24:40 am
Post by: Warmist on January 10, 2018, 04:34:34 am
Would be really hard to do, considering that most tiles above a fort are solid, unrevealed rock.
That is easy: don't draw unrevealed tiles. The hard part is e.g. if it's dug out space. What then? You could make area around the cursor transparent but again...
Imho it needs some visual effect to make it useful.
Post by: Meph on January 10, 2018, 05:22:29 am
Post by: point08 on January 10, 2018, 12:19:47 pm
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.
I waited till the new starter pack just to be sure I wasn't messing anything up. Here are two screenshots in windowed mode (I couldn't get a screenshot using alt-prntscrn in full screen, but there is no problem in fullscreen).
I did these in spoiler tags since they're large images. This first one shows the 2D "control" shot with the FPS counter showing and no text being cropped out.
Spoiler (click to show/hide)
This is the TWBT windowed screenshot showing the top and bottom cropped. The bottom you can see the version number is cut, and on the top you can see the "Slaves to Armok" title and everything above it cropped.
Spoiler (click to show/hide)
Hopefully I did it the right way, I'm going to tell the post to alert me to replies this time. :-)
Post by: point08 on January 10, 2018, 12:34:49 pm
Quote
Hopefully I did it the right way, I'm going to tell the post to alert me to replies this time. :-)
I ended up having to zoom my browser to see the entire screenshot, the forum was cropping the right side of each (which was masking the missing words at the bottom right of the screenie)
Post by: Meph on January 10, 2018, 01:01:43 pm
For more reading: https://support.microsoft.com/en-us/help/3025083/windows-scaling-issues-for-high-dpi-devices
Post by: jecowa on January 10, 2018, 01:05:00 pm
Post by: point08 on January 10, 2018, 01:16:03 pm
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.
I didn't have that specific Font tilesheet, but I tried all of the other ones that come with LNP by default, and some were better about the cropping, but it existed in all of them.
Post by: Hommit on January 11, 2018, 08:44:45 am
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 :|
Post by: Warmist on January 11, 2018, 09:10:12 am
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 :|
Post by: Pvt. Pirate on January 12, 2018, 12:53:46 am
i got a problem with twbt's mousequery:
the "edge" feature only works on the left and the upper border, not on the right and lower border.
So the feature isn't fully broken, but maybe it now only works on 16:9 screens, but i use a 5:4 screen with 1280x1024 desktop and 1280x960 window.
Thanks for looking into this.
Post by: Meph on January 12, 2018, 12:24:25 pm
Post by: lethosor on January 12, 2018, 12:27:44 pm
Post by: Meph on January 12, 2018, 12:30:35 pm
Post by: Earth Striker Lurin on January 12, 2018, 09:12:08 pm
When I use that, it warns me that it wasn't built for this version. Does that mean it will use it despite the error message? Or does that mean it did not load the .dll's?
I normally don't care about such minor versions but this version solves some important bugs I was running into.
Post by: lethosor on January 12, 2018, 09:34:02 pm
Post by: mifki on January 13, 2018, 05:29:21 am
Post by: Novaris on January 13, 2018, 01:28:32 pm
(https://i.imgur.com/J5Ttlnf.png)
But when I move the view one step to the right using the arrow cursors of the keyboard the suddenly don't have a transparent background anymore
(https://i.imgur.com/cKSGgaf.png)
And when I enlarge the window X size, this effect happens earlier so it seems to have something to do with X window position of the tile
Y size change of the window doesn't affect it
Same issue, different scenario: two guys hauling, in this picture both are fine.
(https://i.imgur.com/9Ye0tKa.png)
After pressing arrow down key only one is fine:
(https://i.imgur.com/Cj2wPti.png)
After pressing it again, both are not transparent anymore:
(https://i.imgur.com/c0OkvjF.png)
Note: the grey bars to the left and bottom indicate the window border
Post by: jecowa on January 13, 2018, 03:45:22 pm
Post by: Novaris on January 13, 2018, 05:35:57 pm
Post by: mifki on January 14, 2018, 05:35:55 am
Post by: Meph on January 14, 2018, 07:42:44 pm
Was on windows, dfhack beta for 44.03 with twbt 6.31.
Post by: Isher on January 16, 2018, 02:53:56 pm
Post by: endoftheline on January 16, 2018, 03:11:10 pm
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.
http://dffd.bay12games.com/file.php?id=13429 (http://dffd.bay12games.com/file.php?id=13429)
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.
Note that I could only test the Linux patch, but the others look ok too.
Post by: Isher on January 16, 2018, 03:23:04 pm
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.
Thanks! I was trying to see about possibly rendering upper levels with a sort of transparent screen effect (I was able to render upper levels but the rendering effect is beyond me at the moment and I came to the conclusion it would probably look bad regardless) so I happen to have it in a compilable state.
Post by: jecowa on January 17, 2018, 01:27:58 am
Post by: mifki on January 17, 2018, 02:32:45 am
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.
Post by: Meph on January 17, 2018, 04:41:09 am
How likely is it that a new twbt would fix the "items being carried / items on items show no override" bug?
Enjoy your break. :)
Edit: 6.33 for 44.05 coming, or will you do that later too?
Post by: Isher on January 17, 2018, 09:09:36 am
Post by: mifki on January 17, 2018, 09:20:38 am
Post by: jecowa on January 17, 2018, 04:34:47 pm
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.
Rewriting sounds like a lot of work. Have you ever rewritten Text Will Be Text before?
Post by: Arcturus on January 31, 2018, 10:05:57 pm
Yep, version 6.33 is published now.
Great. I'm on x86 computer though. What exactly is in Core.h? Is it a common library file? I want to build a x86 version.
Post by: lethosor on January 31, 2018, 11:20:04 pm
Jecowa, he's rewritten parts of it before (e.g. the TWBT_LEGACY print mode is from before an earlier major change), but I'm not sure how this compares in scale to previous changes.
Post by: jecowa on February 01, 2018, 01:59:14 am
Post by: mifki on February 05, 2018, 02:50:33 am
Post by: Pvt. Pirate on February 05, 2018, 03:28:27 am
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?
Post by: mifki on February 05, 2018, 03:49:43 am
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.
Post by: Pvt. Pirate on February 05, 2018, 03:51:18 am
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.
Post by: falcn on February 05, 2018, 10:50:23 am
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?
Post by: mifki on February 06, 2018, 04:35:50 am
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?
TWBT is updated more often than dfhack, and also depends on additional addresses/patches that are not part of dfhack. So basically I'm happy with the way it is - I can release new features any time I want, don't need to worry about properly adding stuff that no one else needs to dfhack.
Post by: jecowa on February 06, 2018, 10:43:33 pm
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.
Post by: mifki on February 06, 2018, 10:53:53 pm
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.
It should've saved crash log. Check Console.app, I'm not sure where exactly, they changed the app in the later versions.
Post by: jecowa on February 06, 2018, 11:36:43 pm
Code: [Select]
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
There wasn't room for the last ~100 lines of binary data, but I'm guessing that's not needed anyway. It might also be worth noting that DF crashes on exit a lot for me, but this is not the error I normally receive for that.
Post by: Meph on February 10, 2018, 12:55:25 pm
Version 6.34 is available for 0.44.05-r1.What are the changes to the previous version?
Post by: jecowa on February 10, 2018, 01:13:23 pm
Post by: Meph on February 10, 2018, 01:18:12 pm
Post by: lethosor on February 10, 2018, 01:57:03 pm
Post by: Clément on February 12, 2018, 11:25:24 am
Post by: Lamandus on February 22, 2018, 03:16:34 pm
Post by: mifki on February 23, 2018, 03:05:07 pm
Post by: Vagabundo on March 03, 2018, 10:28:41 am
But at home I use an old laptop running ubuntu. The 4.xx series didnt have a version compiled against 0.34.11-r5 but I managed to figure out how to compile it, then I noticed the warnings. The render functions for that version weren't implemented. Looking at the sources there seems to be an offset there for there for the other os versions in the defines.
What is that offset? How do you find it? I'll give hacking the sources a shot.
Post by: lethosor on March 03, 2018, 05:58:59 pm
Post by: Vagabundo on March 03, 2018, 06:20:23 pm
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 was compiling it on Linux and saw some warnings. When I open some of the files I saw that the Linux code was never implemented for these version eg:
Code: [Select]
#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
#endifPost by: mifki on March 03, 2018, 07:35:41 pm
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.
Post by: Vagabundo on March 04, 2018, 04:37:49 am
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.
Brilliant, thanks for the advice. Just looked through PATCHES.md and it seems complicated, but doable - its been a long time since I messed around in assembly. I'll post back if I manage to get through it and let you know.
Post by: Lamandus on March 15, 2018, 01:11:46 am
Post by: mifki on March 15, 2018, 06:39:15 am
Post by: Lamandus on March 15, 2018, 12:50:38 pm
Post by: waterphage13 on March 19, 2018, 09:41:29 am
(http://www.imgzilla.ru/image.uploads/2018-03-19/original-3e6558d802bbf8d417212c9063f5c7f3.png) (http://www.imgzilla.ru/view-image/3e6558d802bbf8d417212c9063f5c7f3.png)
Post by: Pvt. Pirate on March 20, 2018, 05:06:09 am
http://www.bay12forums.com/smf/index.php?topic=169944.0
when tileset and graphicset tilesizes differ, the zooming doesn't work accurately enough, so it is impossible for me to link a bridge to a pressureplate: selecting the bridge zoomed next to it and it said "there is no valid building nearby" cancelling the process of linking, so i couldnt manually select the bridge.
this affacts all zooms from FB/migrant over unit lists to linking bridges to pressure plates (which works with levers for some unknown reason).
only zooms to the top left area are near enough, but most are 10-20 tiles off in a 3x3 embark.
Post by: Jazz Cat on March 21, 2018, 01:48:50 pm
Post by: Lamandus on March 30, 2018, 04:15:47 pm
Post by: ThoMeuhGal on March 31, 2018, 06:32:21 am
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 totally support this.
Post by: Meph on March 31, 2018, 08:37:41 am
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.
Post by: Pvt. Pirate on March 31, 2018, 10:03:05 am
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.
Post by: jecowa on April 01, 2018, 04:33:31 pm
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.
Maybe the upcoming improvements in the TWBT rewrite will make make a map tilesheet more possible.
Post by: se5a on April 02, 2018, 02:15:54 pm
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 keep having to guess where to put the files.
Post by: jecowa on April 02, 2018, 02:42:03 pm
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.
• The TWBT plugin file goes in the /Dwarf Fortress/hack/plugins/ folder.
• The two 1-pixel PNG files go in the /Dwarf Fortress/data/art/ folder.
• I think that's all that's needed – maybe put the shadows PNG into the art folder too just to be sure.
• The real colors script is optional, but it goes in the /Dwarf Fortress/hack/scripts/ folder. This lets you run the realcolors command to demo a TWBT feature that enables a larger color palette.
Post by: lethosor on April 02, 2018, 02:57:00 pm
Post by: Rahk on April 02, 2018, 04:02:51 pm
https://www.reddit.com/r/dwarffortress/comments/890jbk/unoffical_twbt_updated_for_dfhack04409alpha1/
Post by: se5a on April 02, 2018, 04:18:29 pm
Post by: mifki on April 02, 2018, 08:06:15 pm
Or likely tomorrow :(
Post by: mifki on April 04, 2018, 06:07:53 am
Post by: Lamandus on April 05, 2018, 07:51:53 am
Post by: lethosor on April 05, 2018, 09:45:51 am
Post by: mifki on April 05, 2018, 06:02:04 pm
Post by: Jazz Cat on April 05, 2018, 09:20:36 pm
Post by: Lamandus on April 06, 2018, 12:19:43 am
Darn work. Don't employers know that there's Dwarf Fortress utilities to be made?
Ikr? It is like deploying a legendary Fish Desector to the Army... uh...
Post by: mifki on April 06, 2018, 08:22:40 pm
Post by: Rose on April 17, 2018, 03:34:40 am
Post by: lethosor on April 17, 2018, 08:27:27 am
There is also a makefile and a visual studio project in the repository. Is something not working with those?
Post by: Rose on April 17, 2018, 08:31:49 am
As for why I need to build it, I want to add the ability to use raw tokens rather than indexes, so things don't break as soon as somebody adds a new workshop.
Post by: lethosor on April 17, 2018, 08:50:14 am
That sounds like a fun project. I've never built TWBT on Windows, though, so I'm afraid I can't help much there. The Makefile just needs paths to DF, DFHack source, and a DFHack version number (DF, DH, and DFHACKVER respectively) - maybe the Windows build system is similar?
Post by: Rose on April 17, 2018, 10:24:54 am
https://github.com/mifki/df-twbt/pull/74
This should make things a bit easier for the overrides.
Post by: PatrikLundell on April 20, 2018, 02:36:09 am
Post by: Vordak on April 25, 2018, 12:34:19 pm
Code: [Select]
RiverRampE, RiverRampN, RiverRampNE, RiverRampNW, RiverRampS, RiverRampSE, RiverRampSW, RiverRampWIs it possible to introduce such a distinction for all types of ground ramps?
Post by: lethosor on April 25, 2018, 12:36:46 pm
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.
Post by: PatrikLundell on April 25, 2018, 02:32:15 pm
: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.
Post by: Rose on April 28, 2018, 12:08:57 am
Post by: jecowa on May 05, 2018, 09:22:13 pm
Post by: funkydwarf on May 06, 2018, 03:23:57 am
Post by: Meph on May 06, 2018, 11:48:40 am
Spoiler: Wooden exterior / constructions (click to show/hide)
Spoiler: Wooden interior / furniture (click to show/hide)
Post by: endoftheline on May 08, 2018, 10:28:23 am
Linux Patch
Spoiler (click to show/hide)
Windows
Spoiler (click to show/hide)
OSX
Spoiler (click to show/hide)
Post by: mifki on May 11, 2018, 07:06:53 am
Post by: Meph on May 11, 2018, 07:55:44 am
Version 6.42 is available.Does it include Japas recent changes?
Post by: Clément on May 11, 2018, 08:02:37 am
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).
Post by: mifki on May 11, 2018, 09:39:52 am
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).
Oh, maybe Japa's changes to the project file caused this... will fix now.
Post by: Meph on May 11, 2018, 09:55:16 am
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. ;)
Post by: mifki on May 11, 2018, 10:03:17 am
I've updated the build (6.43 now), hope everything is ok now.
Post by: Lamandus on May 11, 2018, 10:34:09 am
Post by: mifki on May 11, 2018, 10:52:08 am
Keep in mind that now I'm merging almost without checking Japa's code. I'll do that once I have time, there are some things that I definitely want to change. Until then I'm mostly not familiar with the new code, direct your complaints to Japa, if any :)
Post by: Rose on May 11, 2018, 11:04:01 am
Post by: mifki on May 11, 2018, 11:09:39 am
reproducible crashes.
Want the easy part, huh?
Post by: Meph on May 11, 2018, 12:53:03 pm
Post by: Ice Cracker on May 16, 2018, 01:39:16 am
On my home computer (1920x1080), no issues. On my laptop (1920x1080) the top and bottom of my screen is cut off (top part more so than the bottom). https://imgur.com/a/1daPpZk This is what I'm seeing on my laptop at 1920x1080 with 1200x600 as my setting in the PyLNP interface. Resizing the window via click-and-drag doesn't help.
Switching to ASCII mode restores screen size. Other graphical sets are hit/miss on whether or not they're working right.
Anybody ever experienced this? Every solution I've found via google has not worked.
Post by: Meph on May 16, 2018, 02:29:15 am
You can try right clicking the DF.exe and click on"Disable Display Scaling on High DPI Settings" and try again.
Post by: Ice Cracker on May 16, 2018, 03:06:05 am
Post by: PatrikLundell on May 16, 2018, 06:04:07 am
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.
Post by: Meph on May 16, 2018, 08:54:40 am
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.
Post by: waterphage13 on June 28, 2018, 07:23:03 am
[TILESET:TIER_3_1.png:TIER_3_1.png:tier3-1]
[OVERRIDE:133:T:StoneWall:tier3-1:R:4:0:1:2:3:16:::INORGANIC:SANDSTONE]
[OVERRIDE:133:T:StoneWall:tier3-1:R:4:4:5:6:7:16:::INORGANIC:SILTSTONE]
[OVERRIDE:133:T:StoneWall:tier3-1:R:4:0:8:9:10:16:::INORGANIC:MUDSTONE]
[OVERRIDE:133:T:StoneWall:tier3-1:R:4:12:13:14:15:16:::INORGANIC:SHALE]
[OVERRIDE:133:T:StoneWall:tier3-1:R:4:16:17:18:19:16:::INORGANIC:CLAYSTONE]
[OVERRIDE:133:T:StoneWall:tier3-1:R:4:20:21:22:23:16:::INORGANIC:ROCK_SALT]
[OVERRIDE:137:T:StoneWall:tier3-1:R:4:24:25:26:27:16:::INORGANIC:LIMESTONE]
[OVERRIDE:133:T:StoneWall:tier3-1:R:4:28:29:30:31:16:::INORGANIC:CONGLOMERATE]
[OVERRIDE:137:T:StoneWall:tier3-1:R:4:32:33:34:35:16:::INORGANIC:DOLOMITE]
[OVERRIDE:133:T:StoneWall:tier3-1:R:4:36:37:38:39:16:::INORGANIC:CHERT]
[OVERRIDE:137:T:StoneWall:tier3-1:R:4:40:41:42:43:16:::INORGANIC:CHALK]
[OVERRIDE:132:T:StoneWall:tier3-1:R:4:44:45:46:47:16:::INORGANIC:GRANITE]
[OVERRIDE:132:T:StoneWall:tier3-1:R:4:48:49:50:51:16:::INORGANIC:DIORITE]
[OVERRIDE:132:T:StoneWall:tier3-1:R:4:52:53:54:55:16:::INORGANIC:GABBRO]
[OVERRIDE:131:T:StoneWall:tier3-1:R:4:56:57:58:59:16:::INORGANIC:RHYOLITE]
[OVERRIDE:131:T:StoneWall:tier3-1:R:4:60:61:62:63:16:::INORGANIC:BASALT]
[OVERRIDE:132:T:StoneWall:tier3-1:R:4:64:65:66:67:16:::INORGANIC:ANDESITE]
[OVERRIDE:131:T:StoneWall:tier3-1:R:4:68:69:70:71:16:::INORGANIC:DACITE]
[OVERRIDE:138:T:StoneWall:tier3-1:R:4:72:73:74:75:16:::INORGANIC:OBSIDIAN]
[OVERRIDE:134:T:StoneWall:tier3-1:R:4:76:77:78:79:16:::INORGANIC:QUARTZITE]
[OVERRIDE:134:T:StoneWall:tier3-1:R:4:80:81:82:83:16:::INORGANIC:SLATE]
[OVERRIDE:134:T:StoneWall:tier3-1:R:4:84:85:86:87:16:::INORGANIC:PHYLLITE]
[OVERRIDE:134:T:StoneWall:tier3-1:R:4:88:89:90:91:16:::INORGANIC:SHRIST]
[OVERRIDE:134:T:StoneWall:tier3-1:R:4:92:93:94:95:16:::INORGANIC:GNEISS]
[OVERRIDE:137:T:StoneWall:tier3-1:R:4:96:97:98:99:16:::INORGANIC:MARBLE]
Post by: mifki on June 28, 2018, 05:06:06 pm
Why it's not working?
What doesn't work - random tiles or overrides for walls at all?
Post by: waterphage13 on June 28, 2018, 09:05:36 pm
P.S.:
Smooth walls are working.
Post by: mifki on June 28, 2018, 09:55:33 pm
Overrides for material-specific walls at all.
P.S.:
Smooth walls are working.
Have you checked with "probe" command that StoneWall tiletype is the correct one?
Post by: waterphage13 on June 28, 2018, 10:12:26 pm
Post by: mifki on June 29, 2018, 05:22:09 am
"Probe" command?
Um.. yes.. "probe" dfhack command, which shows info about a tile - tiletype, material, etc.
Post by: waterphage13 on June 29, 2018, 02:01:11 pm
Post by: waterphage13 on June 29, 2018, 03:24:11 pm
P.S.:
New unworking textures was very bad.
Post by: Krutchen on July 01, 2018, 02:41:06 pm
Post by: Clément on July 05, 2018, 01:17:22 pm
Code: [Select]
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.
Post by: mifki on July 05, 2018, 04:16:58 pm
UPDATE: Version 6.50 is ready.
Post by: taleden on July 06, 2018, 09:35:03 am
Post by: waterphage13 on July 11, 2018, 09:28:36 pm
(http://www.imgzilla.ru/image.uploads/2018-07-12/original-a83da058e22f60ed2405781ffc4c49eb.png) (http://www.imgzilla.ru/view-image/a83da058e22f60ed2405781ffc4c49eb.png)
[OVERRIDE:251:I:WEAPONRACK:WEAPONRACK::tier2:71:::IS_STONE]
[OVERRIDE:251:B:WEAPONRACK:Weaponrack::tier2:71:::IS_STONE]
[OVERRIDE:251:I:WEAPONRACK:WEAPONRACK::tier2:72:::WOOD]
[OVERRIDE:251:B:WEAPONRACK:Weaponrack::tier2:72:::WOOD]
[OVERRIDE:251:I:WEAPONRACK:WEAPONRACK::tier2:73:::IS_METAL]
[OVERRIDE:251:B:WEAPONRACK:Weaponrack::tier2:73:::IS_METAL]
[OVERRIDE:251:I:WEAPONRACK:WEAPONRACK::tier2:74]
[OVERRIDE:251:B:WEAPONRACK:Weaponrack::tier2:74]
Post by: Fleeting Frames on July 14, 2018, 06:38:03 pm
Using unchanged 5.7-twbt from the repo (cloned) and 43.03-r1 dfhack unchanged from repo (cloned and built), compiles for twbt's resume/automaterial/mousequery fail with
Spoiler (click to show/hide)
And although make inst for twbt.plug.so itself succeeds, dfhack apparently can't load it, even after including the other plugins from 5.7 release from github (the twbt.plug.so there works fine though so no need to worry about that).
I'm probably missing something obvious, but searching this thread for libdfhack-version yielded no clues. I do have print mode set to twbt and do have shadows, transparent1x1 and white1x1 pixel files in data/art and realcolors.lua in scripts, so its not these though.
If it is not too much trouble, can (general) you please point out what I'm doing wrong here?
Post by: lethosor on July 14, 2018, 08:32:20 pm
But if you did that, I'm not sure what's going wrong. libdfhack-version is a small static library with version information, which was added to make DFHack incremental builds with version number changes much faster. However, it was added before 0.40.24-r3 (https://github.com/DFHack/dfhack/commit/0f77a1a578943ff131766d72d3d1607d3997ded9), so building TWBT against any DFHack version newer than 0.40.24-r2 should work fine, at least when it comes to -ldfhack-version. TWBT's makefile was updated around the same time to add -ldfhack-version.
Out of curiosity, is there a reason you're using TWBT 5 instead of 6? Somewhere along the 6.x branch (I think, or maybe later in 5.x), the three separate plugins were removed (mousequery was removed later) due to DFHack core changes making them unnecessary. Those core changes might not be in 0.43.03-r1, though, so then maybe TWBT 5 is necessary after all.
Can you paste the contents of stderr.log? If you can locate sections related to the 3 plugins and paste those, that would be even better.
Post by: Fleeting Frames on July 14, 2018, 08:58:18 pm
Unfortunately I can't paste the sections related to my own compiled 3 plugins in stderr when they don't compile.
Yeah, I noticed they were removed later. I'm using unchanged 5.7 in above post since that is the latest version for 43.03 (which my fort is on - would prefer not to upgrade) + I know the github one works. (Though if I get things to work I'll likely branch out from it or twbt-next - got the later to compile on 43.03 too, but failed to load that too.)
Post by: lethosor on July 14, 2018, 11:43:23 pm
Also, what GCC version are you using?
Post by: Fleeting Frames on July 15, 2018, 06:18:32 am
*peeks into CMakeOutput.log* gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10)
Ah, but I have installed 4.5, 4.5-multilib, 4.9, 5.4-multilib, lib32gcc-5-dev, libx32gcc-5-dev, lib32gcc-1 and 6.0.1(not a typo) packages. Can't find CMakeOutput.log, but I know twbt asks for 4.5+/4.8+ for next. Might that cause issues with 4.5 or 4.9 package used instead of 5.4?
E: Editing 5.7's makefile to use 4.8+ or 5.4+ fails to compile. Aw.
Post by: lethosor on July 15, 2018, 08:24:24 am
How exactly did it fail to compile? I don't think TWBT has ever lacked support for GCC 4.8, because of Linux using it. I'm not sure why 5.4 would fail to compile - it might fail to link, if you don't have the "-D_GLIBCXX_USE_CXX11_ABI=0" definition. Also, GCC 6.0.1 literally does not exist (https://gcc.gnu.org/releases.html), as I've mentioned before - maybe someone made up their own version number, in which case I don't know for sure what that is.
Post by: Meph on July 15, 2018, 09:13:33 am
Did you ever add the option to print the entire texture catalogue TWBT creates in one file?
Post by: lethosor on July 15, 2018, 09:35:59 am
Post by: Meph on July 15, 2018, 10:27:17 am
Post by: Fleeting Frames on July 15, 2018, 11:19:33 am
(I did get the ldfhack errors until I changed -m64 to -m32 when compiling twbt next branch for altered 43.03, but that's a different story - the 5.7 3 plugins' makefile already uses -m32, for whats it is worth.)
The plugins makefile set to 4.8+ or 5.4+ fails with
Spoiler: ldfhack missing errors (click to show/hide)
That seems to be exact same failure message attempting to compile plugins with makefile requiring 4.5+, however.
None of the files in 5.7's plugin folder have text D_GLIBCXX_USE_CXX11_ABI, however. Though adding at the end of CFLAGS line in their Makefile doesn't seem to do anything.
Mind, I'm not planning on doing anything with mousequery/automaterial/buildingplan, so they're a bit of side issue compared to the main plugin's compiled file failing to be loaded.
PS: Yeah, I've seen your message of it not existing before. And 43.03 because my Solstice Chronicle was done in 43.03. Would prefer to not upgrade partly due already having run an 43.05 fort, partly due the .04 combat changes before which I didn't get too much combat experience, partly due this seeming like an issue that should be easy to solve and partly due upgrading having caused bugs for other forts like the craziness of Ardentdikes in the past (all through .40).
(I might eventually do it to boost FPS thanks to Sethatos' reports, but the world won't be having any historical artifacts in that case.)
Post by: lethosor on July 15, 2018, 04:26:32 pm
Code: [Select]
/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?Also, why do you need 0.43.03?
Post by: Fleeting Frames on July 15, 2018, 05:50:50 pm
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):
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?
Post by: lethosor on July 15, 2018, 07:46:19 pm
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.
Quote
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)
Quote
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?
Post by: Fleeting Frames on July 15, 2018, 08:01:24 pm
Spoiler: Here's stderr.log again (click to show/hide)
Well, /home/username/DF/dfhack_compile/4303/DF4303/df_linux/hack/plugins/twbt.plug.so: undefined symbol: _ZN6DFHack12findEnumItemERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiPKPKc is exactly same as on last page.
Good to know size isn't determinator even for two compiles of exact same code. I've been trying 'em all anyway since 'maybe it'll work this time'.
I tried make inst -D_GLIBCXX_USE_CXX11_ABI=0 in twbt5.7/plugins folder, but it exited with "invalid option" and listing of non-invalid flags. Not sure where else you mean to place it?
The above in spoiler is the full make output in console; unlike with dfhack there's no CMakeOutput.log or the like that I can see in the twbt folder.
Not a bug but a feature. (Well, weapon trap crashes were fixed in 44.01 though but I don't plan on using any.)
Though some consider twisting to be too strong/other things too fragile and use mods like Sver's combat rework to weaken its effect.
Post by: lethosor on July 15, 2018, 08:08:11 pm
To clarify, by "commands", I meant the commands printed by make, not the command you're running. Make prints every command that it runs (usually starting with g++), and each of those lines should contain -D_GLIBCXX_USE_CXX11_ABI=0. If you run into further issues, can you please post all of those lines, not just the last one?
Post by: Fleeting Frames on July 16, 2018, 06:51:19 am
Spoiler: Alright, it shows up now (click to show/hide)
Resultant is slightly larger but not as much as release, ...And it loads and works!
Alright, now to try for the altered next and dfhack...And it works too!
|(https://i.imgur.com/PYNrSUJ.png)|
=D
(Though (whoops?) multilevel displays weirdly. Ah well, I guess I might convert latest twbt to 43.03 when the meantime fixed bugs annoy me/it crashes/I want unit transparency support/etc).
Now to load my 43.03 fort and dragonmaster's at the same time. Raw, data, init, save, scripts...
|(https://i.imgur.com/fokX5uJ.png)|
Going through things, everything in dfhack.init works...Ah, it seems my edited stamper.lua for 43.03 has blackspace for text. Well, can refactor it. All other tested guis seem to work, and at least some of the added changes such as dfhack.gui.getSelectedPlant, dfhack.units.getUnitsInBox or dfhack.buildings.getCageOccupants also seem to work. No crashes at least, which is definitely unexpected.
Alright. I didn't manage to make it crash so far, so I guess I can leave this here for others, if anybody else wants it:
linux: dfhack-43-03-r1 with twbt.plug.so from next branch (https://mega.nz/#!hsoSGKZS!hut3Kk5EymvXGgMRlb9gF-PP16A2IeJ9nZZ1sNGF2Xo)
Note that it doesn't include next's mousequery, but the default one (just like with 5.7, I couldn't get the plugin to compile. The changes are pretty substantial between the code of the two, so guess there will be bugs related to that as well).
Overall, thanks a lot lethosor, couldn't have done this without you.
E: Figured I could just compile twbt's mousequery alongside dfhack if I toss in renderer_twbt.h, so here's it as an experiment: above+mousequery(+some name changes) (https://mega.nz/#!t5YngCja!O0XsFG9hqnB7H_AjgLwS3L7KdjPtDMs46us5Bq48i9g)
Post by: lethosor on July 16, 2018, 08:12:40 am
Post by: MrSirLogan on July 21, 2018, 08:11:14 pm
Post by: lethosor on July 21, 2018, 08:36:27 pm
Post by: MrSirLogan on July 21, 2018, 08:47:55 pm
What settings did you set in init.txt? I don't think overrides make a difference.
I set the printmode to TWBT, and turned on the graphics and changed the resolution.
Post by: MrSirLogan on July 21, 2018, 10:39:57 pm
Post by: lethosor on July 21, 2018, 11:33:05 pm
Post by: PatrikLundell on July 26, 2018, 03:53:42 am
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.
Post by: mifki on July 26, 2018, 08:42:44 am
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.
You can post LNP settings screenshots or init.txt for me to reproduce the issue. Btw, the latest PE's LNP is r02, are you using old one or is it another LNP?
Post by: PatrikLundell on July 26, 2018, 09:34:33 am
OK, your answer made me look at what I've done to init.txt, and I tried reducing the window size from 125*95 which I used, to first 110 * 95 (still crashing) and 80 * 25 (which I think is default), which worked.
125 * 25 worked.
125 * 80 crashed.
125 * 70 crashed.
125 * 60 worked.
125 * 65 worked.
125 * 68 crashed.
125 * 67 worked.
Thus, it seems to be something with a large vertical screen size it doesn't like.
init.txt as it looks after the successful 67 test (I've used the LNP UI to change the values, not text editing):
Spoiler (click to show/hide)
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.
Post by: mifki on July 26, 2018, 11:28:54 pm
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?
Post by: PatrikLundell on July 27, 2018, 02:46:04 am
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?
It's annoying the issue isn't readily reproducible. The world I've used most of the time is a standard world gen pocket with 5 years of history (I've used it as a sand box for DFHack investigations, so I don't particularly care about its details). If I remember correctly, that world doesn't have any raw changes. If I remember incorrectly, it contains the ones I've made for my "real" world, which still shouldn't be important:
- Made banana yield wood (as it doesn't show up on embarks otherwise)
- Made goblins start on glaciers exclusively (to get them to spawn where I want them)
- Lowered (semi)megabeast attack triggers
- All civ siege triggers set to 1.
I made another attempt at a "real" embark with 125*67, and it crashed, so the next time I'll try default values for that.
Edit: I just tried starting with size (0, 0) and then resizing the window to about my desired size, and then embark in my pocket world, and it crashed. The purpose was to see if the initial size had anything to do with it, or if it's a matter of the screen size at embark, and as expected, it's the screen size at the time of embark that matters.
Edit 2: I've made my "proper" embark with a (0, 0) window size, saved, restarted DF with my desired size, and it works. Still, it would be good if the cause of the crashes can be identified.
Post by: Meph on July 29, 2018, 04:44:27 am
There are quite a few tiles for it that I dont know how to approach, like sneaking indicator, footsteps, smells, etc and others have no overrides, because they dont show up in the list of tiletypes.
Any help would be appreciated. I'm trying to make a adv-mode twbt tileset. Or at least look into the possibilities.
Post by: waterphage13 on August 14, 2018, 08:38:34 am
https://drive.google.com/file/d/1aMHaB0n_LkKQ1N8Bf1KweuWS3To_FnNi/view?usp=sharing
Post by: Meph on August 14, 2018, 09:00:32 am
Post by: waterphage13 on August 14, 2018, 09:03:32 am
There is no limit on overrides, but all textures combined should stay below 4096x4096 pixels.Hmm... Why It's not working?
Post by: waterphage13 on August 14, 2018, 09:53:54 am
Post by: Meph on August 14, 2018, 12:44:31 pm
Post by: Vordak on August 19, 2018, 08:30:59 am
What if add support of different sizes of creatures sprites?
At now every creature takes 1x1 tile. But for large creatures it is suggested that , for example, they use space 2х2, although in fact creature will be stand on 1x1 tile, other 3 tiles is fake and transparent.
Sprite of such a creature must always be in the foreground. If two of these are close, then the front should be one who stands to the left and above.
Below I will give illustrated examples of sizes. On left pic. you will see what it looks now, on center - that's how it is proposed, on right pic - tile (red) that really takes creature.
1) Size 1x2
(https://i.imgur.com/G98LcYH.png)
2) Size 2x2
(https://i.imgur.com/TSJdPDy.png)
3) Size 3x2
(https://i.imgur.com/KIx8Ioy.png)
4) Size 3x3
(https://i.imgur.com/GP8iRlC.png)
Upd. I understand that this is not so simple. Bujt t if it is implemented, it will be a real breakthrough
Post by: Rose on August 19, 2018, 11:02:43 am
Post by: Vordak on August 19, 2018, 03:41:54 pm
Post by: Vordak on August 19, 2018, 04:02:41 pm
Post by: mifki on August 19, 2018, 07:07:31 pm
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#msg7390751
Post by: Meph on August 20, 2018, 06:49:14 am
I will certainly make sprites for this feature, and can send you some more mock-ups later.
Post by: Vordak on August 22, 2018, 03:48:01 pm
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?
Sorry for the delayed response.
pic. 1 - elephant 3x2, yak 2x2, troll 2x2, hydra 3x3.
(https://i.imgur.com/fnLyBFJ.png)
pic. 2 - cyclops 3x3, ettin 3x3, hippo 3x2, demon 3x3, demon 2x2.
(https://i.imgur.com/iZiFcE2.png)
pic. 3 - yak 2x2, hippo 3x2, deer 2x2, demon 3x3.
(https://i.imgur.com/7LVKlmW.png)
pic. 4 - elephant 3x2, yak 2x2, hippo 3x2.
(https://i.imgur.com/f57Qa1W.png)
In general, the most illustrative example in a narrow corridor - creatures 2x2, 3x2 and not shown 1x2, in my opinion, fit perfectly. The main thing when drawing not occupy all tiles offered.
3x3 certainly does not look very well, especially the demon 3x3, which is stretched to the maximum possible area - 300% sized sprite. But hydra is 200% sized sprite, placed in center 3x3 area looks tolerant.
In pic. 4 can see that 2x2 not look very much(but not for me) in a vertical narrow corridor, but this is solved by drawing the sprite as far as possible to the left or transition to 3x2, where can draw sprite symmetrically.
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)
Post by: Meph on August 22, 2018, 04:24:27 pm
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. :-)
Post by: Vordak on August 22, 2018, 04:47:25 pm
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. :-)
This is generally conceived, for the fact that there was a plausible ratio of the sizes of dwarves and common creatures that often occur.
I.e it is assumed that the common lion will occupy 2x2 or 3x2, without taking up the entire area - the giant lion will occupy 3x2, but occupying more space\pixels.
3x3 is needed size - only when drawing on trying to minimize the use of 3 lower tiles.
Upd. left pic. - common lion, right pic. - giant lion
(https://i.imgur.com/CWyCcID.png)
Post by: Meph on August 23, 2018, 01:57:12 am
Post by: Vordak on August 23, 2018, 03:00:20 pm
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.
Post by: DragonDePlatino on September 02, 2018, 12:24:12 pm
Post by: lethosor on September 02, 2018, 12:25:53 pm
You can get a list with "@df.whatever_type" in the DFHack Lua interpreter (or just run lua with that expression as an argument, e.g. "lua @df.item_type").
Post by: Meph on September 03, 2018, 08:04:35 am
Post by: Clément on September 03, 2018, 08:58:32 am
Post by: Meph on September 03, 2018, 09:16:51 am
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.
Btw, could you make it print all ids on the tile?
For example when I check a corpse with items in the inventory, it says it looks at a weapon (because there is a weapon in the inventory). It would be more helpful if it outputs the ids for the corpse and all items individually.
Not super-relevant by now, but I wanted to mention it just in case it's an easy addition.
Post by: Clément on September 03, 2018, 09:55:34 am
Post by: Fleeting Frames on September 03, 2018, 10:28:39 am
Post by: Clément on September 03, 2018, 10:53:33 am
Post by: Fleeting Frames on September 03, 2018, 12:04:51 pm
Yeah I did that when needed to (expect used letters and/or wiki instead).
Post by: Meph on September 04, 2018, 07:12:32 am
Post by: Pvt. Pirate on September 06, 2018, 01:06:44 pm
copypastinging the mousequery.plug.so from the 44.09 just doesnt work - saying it were written for another version of dfhack.
the only thing that doesnt work is the scrolling on screenborder when not in any dmode or lmode or qmode.
i'll post this in dfhack and twbt support threads, because i remember something about twbt having its own version of mousequery.
Post by: lethosor on September 06, 2018, 04:22:31 pm
and my response in the DFHack thread: http://www.bay12forums.com/smf/index.php?topic=164123.msg7848474#msg7848474
Post by: Pvt. Pirate on September 10, 2018, 12:42:37 pm
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
Post by: waterphage13 on September 19, 2018, 03:35:39 pm
[OVERRIDE:234:B:STATUE:Statue::tier5:R:11:0:1:2:3:4:5:6:7:8:9:10::::SANDSTONE]
[OVERRIDE:239:B:SLAB:Slab::tier5:R:5:11:12:13:14:15::::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?
Post by: Meph on September 20, 2018, 02:13:02 am
[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.
Post by: waterphage13 on September 20, 2018, 05:14:08 am
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.
Post by: mifki on September 20, 2018, 05:59:28 am
The problem was in a quantity of my overrides. TWBT needs loading screen.
What exactly does it mean?
Post by: waterphage13 on September 20, 2018, 06:59:29 am
Post by: waterphage13 on September 20, 2018, 07:29:40 am
Английский, к сожалению, не мой родной язык.The problem was in a quantity of my overrides. TWBT needs loading screen.
What exactly does it mean?
Я провёл небольшое исследование и заметил связь вылетов и нагрузки на процессор во время загрузки текстур. Если нагрузка становится выше критической, то включается функция поиска зависающих приложений. DF не даёт отчёта (интро идёт после загрузки текстур), система паникует и вырубает DF.
Когда текстур 10-20 это не заметно, но если их тысячи?
Post by: Erendir on September 20, 2018, 08:53:57 am
Английский, к сожалению, не мой родной язык.The problem was in a quantity of my overrides. TWBT needs loading screen.
What exactly does it mean?
Я провёл небольшое исследование и заметил связь вылетов и нагрузки на процессор во время загрузки текстур. Если нагрузка становится выше критической, то включается функция поиска зависающих приложений. DF не даёт отчёта (интро идёт после загрузки текстур), система паникует и вырубает DF.
Когда текстур 10-20 это не заметно, но если их тысячи?
rough translation:
Quote
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?
Post by: DragonDePlatino on September 20, 2018, 09:19:15 am
If DF doesn't crash, then usually TWBT stops working and all onscreen tiles revert back to ASCII. I don't get these crashes when I remove overrides.txt or play Fortress Mode so presumably it's not an issue with raws. I do have a pretty mediocre APU though, so that might be the cause.
Post by: Meph on September 20, 2018, 09:38:59 am
Post by: Pvt. Pirate on September 20, 2018, 11:49:34 am
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).
Post by: DragonDePlatino on October 20, 2018, 10:42:23 pm
My temporary solution has been to create a copy of the text tileset and use that instead. It resolves the crashes, but it feels wasteful of texture space and makes things more difficult to maintain because any changes to the text tileset need to be duplicated in both files.
Post by: mifki on October 23, 2018, 04:08:13 pm
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.
Post by: mifki on October 28, 2018, 06:36:21 am
I've also finally fixed mapshot command!
(http://assets.mifki.com/t/mapshot_mountainbreed.png)
Post by: Fleeting Frames on October 28, 2018, 08:53:13 am
Post by: DragonDePlatino on October 29, 2018, 08:01:25 pm
Will be fixed in the next build.
Thanks for the fix! This'll be a big help in reducing the number of files to keep track of. Also the new mapshot features looks great. That will streamline creating tileset previews a lot.
Post by: DragonDePlatino on November 09, 2018, 03:45:36 pm
Code: [Select]
E: NoMethodError: undefined method 'onstatechange' for DFHack:Module
eval:1:in '<main>'And this is what the bug looks like. There should be no visible ASCII on this screen:
Spoiler (click to show/hide)
Post by: Meph on November 09, 2018, 06:58:30 pm
Post by: DragonDePlatino on November 10, 2018, 01:14:05 pm
Post by: Deon on November 15, 2018, 03:20:47 pm
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. ;)
Post by: Novaris on December 06, 2018, 11:24:34 am
Post by: mifki on December 06, 2018, 06:15:28 pm
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.
What OS are you using?
Post by: Novaris on December 07, 2018, 01:42:06 am
Version 1803
Build 17134.441
Game running on i7-7660U with 16GB and Intel IRIS Plus 640
Post by: Vordak on December 13, 2018, 01:21:12 pm
Introductory word.
For the desired result, I need, that floor tile to be completely drawn in -top.png file.
For example:
1) grass was always the same color(no shades depending on biome)
Post with grass illustrations (http://www.bay12forums.com/smf/index.php?topic=161047.msg7898940#msg7898940)
2) gold floor must took the color from -top.png, because even below string - happens unwanted colorization of gold color I have already drawn.
Code: [Select]
[OVERRIDE:43:T:ConstructedFloor:_MDF_overrides_7:109::::INORGANIC:GOLD]Description of the problem.
If the floor tile is present in -top.png, then is not visible on him blood, vomit, mud or other pollution types.
Petition.
Is it possible to do something so that pollution coloration to be ignoring the file -top.png for floors? Would like command, like twbt vomit_ignore floor_top 1 or something like that.
Upd. For grass everything is decided through changing GRASS_COLORS in plant_grasses.txt. But for Tile Types - MineralPebbles, StonePebbles, StoneFloor and SoilFloor - need 50% transparent tile in -top.png for a smooth color transition, which again creates a display problem with mud and other.
Upd.2.
My mistake - it is not work - blood/vomit not seen with forcibly specified foreground color.
Post by: waterphage13 on March 13, 2019, 12:12:13 pm
Post by: waterphage13 on March 13, 2019, 02:39:18 pm
Is there a way to fix this nasty thing when it low FPS?
Post by: mifki on March 13, 2019, 03:40:58 pm
Will TWBT continue to be developed after the release of the "new" version of DF?
I guess no as the will be no need for it.
Post by: voliol on March 13, 2019, 04:56:57 pm
Will TWBT continue to be developed after the release of the "new" version of DF?
Depending on how much of TWBT functionality is included in the graphics update for the steam/itch.io release, and whether that graphics update makes it to standard DF or not, TWBT could either be rendered obsolete in its entirety, or still be just as needed for non-steam/itch.io graphics.
Then again, if you're interested in DF with graphics you might as well play the version with the inbuilt fancy tileset, so TWBT might take a hit either way.
Post by: Meph on March 13, 2019, 09:32:34 pm
Post by: DragonDePlatino on March 14, 2019, 12:07:40 am
Post by: clinodev on March 14, 2019, 12:16:12 am
Now if we're REALLY lucky, they won't consider TWBT deprecated until there's an actual replacement!
*shudder*
Post by: mifki on March 14, 2019, 06:42:51 am
Of course it's a bit sad the story of TWBT will be over and forgotten eventually. But I started TWBT because I personally couldn't play with the graphics as it was back then (mainly the unreadable text due to single text/map tileset). Then I added more and more features, the second most important one for me being multilevel rendering. But the original intention was just to make the game visually not so painful - if it had better graphics back then, I would just play it (and wouldn't probably have done my other DF projects, but that's another question). So I'm certainly happy that now everyone will be able to just play the game with enjoyable UI - the goal is achieved, one way or another. I, too, can stop developing (TWBT) and start just playing, which I also will be happy to do.
I probably missed some of the discussion, but I didn't quite understand who's going to develop the new rendering code. Kitfox? To protect Toady's main code, will it be a separate library again, sort of a new libgraphics? Because I hope all of the current TWBT features will be available, and the new rendering engine will be updated from time to time unlike the current graphics code which was also done by a separate developer and hasn't been touched after that. If not, depending on how it's done, maybe it will be easier now to change/extend rendering? Even though I'll probably be happy with what the game will have out of the box, there will always be thing other people would want to see, for example, animations, which definitely won't be in DF for now as I understand.
The development and even, sadly, bugfixing isn't active enough lately due to the lack of time for all my online and offline projects. But surely I'll update TWBT until a version with new graphics is available.
Post by: ragundo on March 14, 2019, 09:09:46 am
Toady and Kitfox, you are hiring people for the music, and new tilesets, etc. Do the same with the graphics library.
Just my 5 cents
Post by: Meph on March 14, 2019, 11:06:59 am
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.
Post by: Pvt. Pirate on March 14, 2019, 11:17:57 am
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.
Post by: PatrikLundell on March 14, 2019, 11:22:14 am
Post by: mifki on March 14, 2019, 03:45:06 pm
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.
Post by: Shonai_Dweller on March 14, 2019, 10:43:49 pm
Post by: waterphage13 on March 15, 2019, 12:18:10 pm
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.
Post by: Heretic on March 15, 2019, 12:30:15 pm
Post by: Toady One on March 15, 2019, 02:14:45 pm
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.
Post by: mifki on March 15, 2019, 04:33:45 pm
Hey! Some of those features are already in the trailer, right?
Meph mentioned the screenshots they're showing were done in photoshop. But the trailer is a real game video then?
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.
That's good to hear really, although when talking about rendering thousands of tiles (and possibly multiple layers/elements for them), it's very important to optimise it properly. I'm afraid just using SDL (and not manually crafted OpenGL code) may not work (or CPU usage will be too high). Another problem is the number of different tile images that may not fit in one GPU texture anymore - so the texture switching needs to be done efficiently as well. The modern approach would be of course to use shaders that are perfect for rendering repeating grids (and nowadays there's no real need to worry about any hardware that might now support them or OpenGL in general). Please do run some tests so that any performance issues are apparent while it's not too late.
But first of all am I even right thinking that you ditched libgraphics code and replaced with all new game loop/rendering code? If not, what parts are you reusing?
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.
Some people may be unhappy without TTF but yeah it adds a lot of unnecessary complexity to the code I guess.
Post by: Toady One on March 15, 2019, 05:02:55 pm
I'm building on the old code currently - and I haven't found a reason to change the basic structure there yet (certainly there'll be extra grids etc. in time.) 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 (as the number of textures grows, pulling from that catalog might also need to be checked? Not sure what experiences people have had there if any.) It only refreshes tiles that are updated (though of course when you scroll, most tiles are changed, so you can't 100% rely on that - so it's important to make sure there aren't tons of layers used everywhere), and that carries over to multiple layers -- I just have a few extra flags to check on the refresh. There's *potentially* an optimization problem there, doing a few extra checks on the screen texture index arrays, but so far so good (that is, 100 FPS on my crappy computer, and I also get 100 FPS when I just draw every tile.)
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, with all the same files (and any new ones), and that'll be the same (basically) as the Steam code. My understanding is that the licenses from the contributors are in order - at the time, I requested BSD/MIT or equivalent/looser licenses, as I wanted anybody to be able to use the code in their projects, no matter if they were commercial or not, as a condition of using the code myself.
So yeah, I'm going to be sharing all of the new rendering stuff, in basically the same format as before, and between classic and steam it shouldn't be all that different. That's the plan anyway! Certainly if there are issues, hashing them out now rather than later is good.
Post by: mifki on March 15, 2019, 05:23:50 pm
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.
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).
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
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).
Post by: Toady One on March 15, 2019, 05:33:48 pm
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).
I didn't back then, since I hadn't looked at it and didn't have an expectation of being able to pick it up quickly, since I'd never used SDL before. Sorry if the way I stated that made people nervous. I won't say I understand all of it now yet either, but the overall processes are making more sense to me.
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).
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?
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).
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.
Post by: lethosor on March 15, 2019, 06:40:56 pm
Post by: Meph on March 16, 2019, 01:09:17 am
Looks really like DF in agony now.TWBT is dead, DFHack is probably too, utilites and tilesets too. Terrifying.What?
It's the same as any other large DF update. Utilities just need time to be updated too.
Tilesets are getting better. A lot.
Post by: mifki on March 16, 2019, 05:00:13 am
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?
Oh, right... you're doing it all via SDL, so you're working with 2D renderer/print_mode... In that case currently there's no OpenGL involved at all, it's all purely software rendering. Which has problems of 1. high CPU usage (on my system DF uses 70% of one core in that mode when paused compared to 14% in opengl mode) - you may not notice it especially if you're developing on desktop, but people won't be happy with their laptops getting hot because of an extra CPU core being 100% busy doing software rendering, or it will just become a bottleneck later as there will be significantly more rendering operations than currently is; 2. it's pretty limited so any effects are either not possible or again must be done manually in software. SDL2 supposedly can use hardware acceleration for certain things, but I don't know any details.
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.
What if we find a way to solve the problem with Windows build lethosor mentioned that doesn't require too much of your time, is there a chance you would make libgraphics a separate binary on all platforms (on OSX it shouldn't be a problem)? This would make life of DFHack and related projects much easier in general, and would also make my concerns above not so important as you'd be able to continue coding rendering the way you prefer and we'd be able to make an optimised version of the library which can be just used in place of the original one if needed.
Post by: Toady One on March 16, 2019, 09:28:53 pm
Going further would require something more dedicated, which we can't afford in advance if we go with the model we've used for the artists/music this time; up until now I've been relying on volunteers, but it doesn't seem proper to do that this time for any significant conversion for a Steam sale (naturally, my views on this are still forming; it's not an easy mental shift after so many years.) We'll see what we're up against; our minimum requirements are so similar to the current rendering code that I don't feel uncomfortable promising that. If certain possibilities (e.g. the minor animations mentioned in here etc.) increase the rendering cost too much, we'll have to shelve them for now, and then if the Steam sale works out, there should be less of an issue kicking it up a gear.
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.
Post by: FantasticDorf on March 17, 2019, 03:32:45 pm
Quote
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.
(Forgive me if I misunderstood anything regarding your statements) Naturally if you take other development titles like Minecraft for instance which have had a long amount of time in active development and a standard product release, the direct price of the title has inflated from 5€ during the early alpha relevant to the amount of content that has been added to it, given at the start of the product release it was a €20 price tag wheras since then it has rose to €23 at a stable present.
- Expected 20$ // 17€ price is positive estimation of where it would stand competitively in the open market at the moment from Kitfox's discord discussion and a signpost to what Steam views it *this all yet being decided however and may fluctuate i believe unless they've all sorted it out*.
- Other implications though that the scope of the game's plan might undermine the price if conservatively Steam views it as unfinishable or not even started which can undercut sales and the funding drive you required without far more people opening wallets (no shortage of those but still quantity doesn't trump quality in the long run).
- Its important to remember that DF is held in high regard and i think you should definitely be confident that it will be well recieved, yet open minded that big business might have other ideals contrary to your own to make it profitable for them as well and maximise the cut.
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.
Post by: clinodev on March 17, 2019, 04:43:28 pm
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.
Maybe not the optimal place for it given we're getting an open conversation between the dev who wants to add features we all want and the utility modder who's actually made those feature possible currently.
Post by: treehugger on March 26, 2019, 05:52:40 am
About a week ago I started having this strange issue while playing dwarf fortress. 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.
To me it looks like the game is zoomed out so I barely see a few pixels of color in the middle of the screen but often times its just black. This happens almost every time after exiting the Z menu. and from time to time other menus.
I suspect it must be something happening with TWBT or the tileset or a combination. I use TWBT print mode in lazy newb pack and truetype fonts set to NO. If I start the game with standard printmode then the problem goes away. I have also tried "twbt redraw_all set to 0 and 1" No difference.
It sort of started happening in the middle of a playsession and then progressively getting worse. In the beginning it just happened occasionally, but after a while I had to go in and out of the menu 3-4 times, before I figured out I could press F12 to redraw the screen.
Has anyone any idea what might be causing this?
Post by: Pvt. Pirate on March 27, 2019, 06:26:12 am
it happens on z menu and trademenu.
Post by: treehugger on March 28, 2019, 02:15:16 pm
Post by: mifki on April 29, 2019, 07:47:15 am
Also, it fixes map not being visible in couple of performance-related menus in adventure mode.
Post by: Pvt. Pirate on April 29, 2019, 11:16:18 am
Post by: Rose on April 29, 2019, 02:52:25 pm
Post by: Pvt. Pirate on April 30, 2019, 02:04:15 am
edit:
now with a 16:9 monitor, i can say the mousequery bug is not dependant on resolution.
Post by: Fleeting Frames on June 21, 2019, 01:06:28 pm
Now, onto Just TWBT Things....
While doing another update of DragonMaster's set + TWBT for 43.03, I ran into an odd bit (and an issue with backporting unit transparency): My wall/floor grates weren't transparent, ...as they shouldn't have been, looking at buildings.hpp (https://github.com/mifki/df-twbt/blob/master/buildings.hpp). However, adding the OVER1 and OVER1_ENABLE line for the two made it seem to work fine (saw the ground/water underneath, at least).
However, I recall mifki mentioned in TWBT next thread that transparency isn't supported for all buildings. Would I assume correctly there's a good reason why I should not to add a transparency override for each of the third of 54 building imports that are not added, other than trade depot?
E: I tried and discovered why it's generally bad idea for like half of them.
Bridge: Any item/building using transparency, below another item using transparency, is not rendered. So you'd have items have black background on top of bridges.
Civzone: Only displayed when one wants to see them. (Though there's argument for seeing what they cover.)
Constructions: Only used briefly, so using up cycles.
Nest, Dirt road, shop, plain window: rare/see above
Floodgate: Covers whole tile
Grates, farm plots, paved roads, water wheels, windmills, gem and glass windows though: Okay, sure, but YMMV: For example, if there's an item on top of windmill's southmost tile, it renders the un-overridden windmill tile (NS wall) if not using transparency, and the ground below if it is.
PS: Regarding map export, made easier with optional name shotname.png parameters for it - Can then do the export with a small script to run it on each/desired z-levels.
@Japa: Feelings, or linux instability Pirate mentions often.
Post by: mifki on June 28, 2019, 10:32:12 pm
Post by: waterphage13 on July 15, 2019, 02:08:31 pm
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.
Post by: Fleeting Frames on July 15, 2019, 02:40:33 pm
Bridges, depots, wagons, civzones, constructions, farm plots, floodgates, nests, dirt roads, shops, stockpiles, shops and generic windows I left out.
Thing is, any tile using transparency, on top of another tile using an override, will lead to override for the latter not being used (with the exception of natural underlying construction-type tiles, thanks to the fix to items on stairs).
So, even if your tileset doesn't use building transparency for a given building, it will still change game display behaviour if it is enabled for a given building.
So, if you built a bridge over a chasm and arrow lands on top - the arrow will have black background instead of wall/floor tile background.
Or maybe it landed on the windmill you built on grass floor. In this case, it shows the grass floor underneath instead of wall tile.
Or maybe new plants came in on your farm plot. Which would you rather see when it blinks into view, the farm plot tile on your map sheet, or the floor tile underneath?
Or maybe nestboxes, or dirt roads, or etc. are too rare/take whole tile so you don't want to waste additional cycles on them.
Furthermore, glass/ice walls and floors, normally, being transparent is somewhat nonsensical: the transparency displays the tile underneath, but there is nothing underneath a floor or wall.
Also, I noticed for some reason when both transparency and multilevel were on, the empty air floating buildings had their background use chasm/zeroth tile instead of the tile below, such as can be seen on this POI on dfma (https://mkv25.net/dfma/poi-33768-finickymaterialchoices-freedomtorestrictself). Doesn't happen with multilevel off, though, so...
Post by: vettlingr on September 17, 2019, 11:14:26 am
Me and several others have had a problem whilst using my tileset with the latest TWBT for dfhack 44.12-r2 (twbt 6.61)
Scrolling left and right does not preserve transparency, scrolling while up and down does.
I did not have this problem with the later (latest?) version for Dfhack 44.12-r1 (twbt 6.55?)
I use redraw, workshop and unit transparency 1 for all versions
Post by: Meph on September 17, 2019, 11:56:32 am
Edit: redraw_all still causes crashes. ^^
Post by: tatooine on January 21, 2020, 02:23:13 pm
Post by: Novaris on January 26, 2020, 06:46:45 am
if it works, a different story
if you want to test it, open the twbt.plug.dll in the plugins folder of dfhack in any text editor (I used Notepad++)
- search for the two occurances of 0.44.12-r2 and alter them to 0.44.12-r3
note: the second occurance has a hash behind it that seems to be related to the dfhack commit version
- 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)
then DF starts without complaining and TWBT is enabled
my fort runs since a while now with the new dfhack
Proof:
Spoiler (click to show/hide)
Post by: lethosor on January 26, 2020, 12:06:00 pm
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)
Post by: Novaris on January 26, 2020, 02:51:51 pm
Post by: lethosor on January 26, 2020, 03:29:25 pm
Post by: leemcd on January 26, 2020, 04:56:32 pm
Post by: lethosor on January 26, 2020, 11:06:38 pm
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
If you mean how to make it work with DFHack 0.44.12-r3 on macOS, Novaris's instructions would work there too, although you may have to use a different editor (I'd recommend a hex editor, personally, to avoid any issues that text editors may cause).
Post by: leemcd on January 27, 2020, 01:01:11 am
Post by: jecowa on January 31, 2020, 05:17:45 am
Post by: vettlingr on January 31, 2020, 06:20:45 am
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.
Don't know how dice are used, but custom tools can already be overridden.
Post by: Vordak on January 31, 2020, 06:24:43 am
In short, altar and dice are already working.
P.S. I was write too long, in substance it is duplicate of vettlingr's answer.
Post by: NikoKun on January 31, 2020, 10:37:11 pm
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..
Edit: I think I found one that works..
Post by: jecowa on February 16, 2020, 05:15:01 am
- altar - [OVERRIDE:<old_tile>:I:TOOL:TOOL:28:<tileset>:<new_tile>]
- die - [OVERRIDE:<old_tile>:I:TOOL:TOOL:29:<tileset>:<new_tile>]
Post by: Meph on February 16, 2020, 09:18:50 am
Post by: lethosor on February 16, 2020, 12:04:46 pm
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.
Post by: FrankVill on February 28, 2020, 04:17:50 am
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".
Post by: Erendir on February 28, 2020, 08:31:56 am
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".
There are few compatible versions out there, take a look at this (http://dffd.bay12games.com/file.php?id=13880) f.e.
The LNP thread (http://www.bay12forums.com/smf/index.php?topic=126076.5340) has some links (including the one above).
DFFD (http://dffd.bay12games.com) in general is a good place to look, as well as r/dwarffortress (https://www.reddit.com/r/dwarffortress/)
Post by: clinodev on February 28, 2020, 07:18:05 pm
Post by: PeridexisErrant on February 29, 2020, 12:36:22 am
Longer term it would make me very happy indeed if TwbT could be merged into upstream DFHack, that would simplify packaging and testing enormously even when we're not in recent-DF-update mode :D
Post by: Meph on March 11, 2020, 05:11:49 am
For example in my set the full line is [OVERRIDE:255:B:91:OfferingPlace::_MDF_overrides_2:204].
Hope that helps. :)
Post by: Nilsou on April 03, 2020, 06:07:23 am
Post by: waterphage13 on April 19, 2020, 07:04:09 am
P.S.:
I've changed all tiles of inorganic to 1.
P.P.S:
Forgot one stupid thing about overrides.
Post by: Fleeting Frames on April 20, 2020, 04:27:31 pm
Post by: NikoKun on May 20, 2020, 10:12:12 am
Without TWBT:
(https://i.imgur.com/cyQ5DVj.png)
With TWBT:
(https://i.imgur.com/44sFk9q.png)
Could be done via an optional setting, if it's one of those things not everyone wants. :/
EDIT: I tried using TWBT_LEGACY, but that only changes the gen-map, not the other maps, and that makes the menu resize when you zoom. There should be another TWBT_altmap or something for this.
Post by: Warmist on May 22, 2020, 12:08:17 pm
Post by: flbr on May 23, 2020, 10:28:42 pm
Never mind, I realized that wanderlust has special definitions of the tree tiles in its d_init.txt
Post by: NikoKun on May 24, 2020, 01:22:42 pm
Post by: NikoKun on June 14, 2020, 06:28:26 am
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.
Frankly, I'm kinda baffled that more people haven't noticed/mentioned this.. Multi-level rendering is great, but I'm not sure it's worth the trade-off of my map (and the map from exportlegends info) looking almost as bad as ascii.. There's GOT to be a way to fix this. Maybe there's a way to add an exception so TWBT isn't used for the Embark/Raid maps?
Post by: kirill_P on June 19, 2020, 12:06:52 am
https://imgur.com/VQ37BuE
I can only seem to play it with print set to 2D. Anyone knows what it could be?
Post by: Warmist on June 19, 2020, 03:57:48 am
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
Post by: kirill_P on June 22, 2020, 11:42:21 am
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
Theyre all up t date.
Post by: chandl34 on July 01, 2020, 05:07:05 pm
I've gotten a lot of these changed to the tiles and colors I want. However, I'm having trouble with tiles that are intended to use inverted colors. Inverted objects can have their colors fixed so they're no longer inverted, but there seems to be a few things you can't change.
These include:
- The placeholder image when a building is under construction. I can't differentiate this from a completed building, so they currently look the same.
- The selection highlight for buildings that have had their colors overwritten.
- 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.
- Similarly, the previous issue applies to items on a pedestal
Am I right that these are all issues I won't be able to fix, because they are hardcoded in?
Here is some of my overrides.txt:
Quote
# 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]
Post by: Fleeting Frames on July 02, 2020, 02:14:34 pm
Quote
- 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.
Actually, they're specifically excluded in default code to avoid conflict with other items on the tile.
Post by: rmblr on July 29, 2020, 03:03:09 am
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?
The game text is so much more readable with TTF, other font tilesets just don't compare.
Post by: lethosor on July 29, 2020, 12:08:54 pm
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).
Post by: waterphage13 on August 02, 2020, 12:22:45 pm
Post by: lethosor on August 02, 2020, 01:32:22 pm
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.)
What is "random"?
Post by: waterphage13 on August 02, 2020, 03:11:02 pm
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]
Post by: waterphage13 on August 02, 2020, 03:24:19 pm
(http://www.imgzilla.ru/image.uploads/2020-08-03/original-690650e55d57ea1a10d81414063d2ef7.png) (http://www.imgzilla.ru/view-image/690650e55d57ea1a10d81414063d2ef7.png)
Post by: lethosor on August 02, 2020, 05:46:51 pm
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]
I'm not familiar with how TWBT's random sprite feature is supposed to work (i.e. I don't know what's wrong with your screenshot), so I'll leave that for someone else to answer.
Post by: waterphage13 on August 03, 2020, 05:48:49 am
(http://www.imgzilla.ru/image.uploads/2020-08-03/original-77f38d1da792c4a3b4c658c8541eb7b3.png) (http://www.imgzilla.ru/view-image/77f38d1da792c4a3b4c658c8541eb7b3.png)
Post by: Shirasik on September 09, 2020, 06:39:41 pm
It correctly redraws everything if window gets resized or loses and regains focus.
Easiest way to reproduce this - is to set FPS_CAP lower than G_FPS_CAP in init.txt and use any fullscreen menu in game.
Doesn't happen in STANDARD or 2D modes, with or without DFHack, only in TWBT mode.
Post by: Shirasik on September 11, 2020, 05:10:38 pm
Code: [Select]
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.P.S.
Using PeridexisErrant's Starter Pack 0.47.04-r07
Post by: Shirasik on September 12, 2020, 07:20:28 pm
Post by: Enemy post on September 19, 2020, 09:43:07 pm
Spoiler (click to show/hide)
Post by: thurin on October 12, 2020, 07:58:16 pm
Post by: Meph on October 14, 2020, 01:24:17 pm
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. :)
Post by: Hypnopompic on October 18, 2020, 12:34:05 pm
With TEXTURE_PARAM:LINEAR, I get this color blur:
Spoiler (click to show/hide)
TEXTURE_PARAM:NEAREST gives, instead, this sort of pixel "overflow":
Spoiler (click to show/hide)
It's a bit of a bother, this one is honestly the most legible font I've used, but I haven't found a way yet to have it properly display in 21:9. Using [ and ] to resize never brings it back to a perfect 1 font pixel to 1 screen pixel. Curiously, trying to make the font smaller with [ stretches it, keeping the width and decreasing only its height.
The only "workaround" I've been able to find was upscaling the font: From the original 128x256 dimensions of the font, to a 192x384 and the issue doesn't appear anymore, but it makes the font massive, having the UI eat a lot of the screen while playing the game (and resizing down in-game again breaks the 1 font pixel to 1 screen pixel crispness).
Any idea of what could else I try?
For reference, this is the font when launching the game in (or less than) 16:9 FHD:
Spoiler (click to show/hide)
Post by: Enemy post on October 19, 2020, 12:41:05 am
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. :)
Thanks! That’ll be extremely helpful.
Post by: waterphage13 on November 08, 2020, 04:28:57 pm
Post by: waterphage13 on November 08, 2020, 07:08:37 pm
Post by: Dubya on November 12, 2020, 03:17:12 am
Code: [Select]
[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
returns a messed up shadow and not my tile. I've tried making the override image a .png and removed all transparency, but it still returns the shadow. My overrides that change tiles on the base 256x256 tileset work, but none that target a completely new tileset. I've looked at how others have set up their overrides and my file seems to be in the exact same format but it just doesn't work.
Post by: Dubya on November 13, 2020, 07:58:34 pm
Turns out that the canvas size of your override image NEEDS to match your base tileset canvas size. For instance, I was using a 48x48 image for my bridge overrides and my base tileset is 256x256, so I was getting a super zoomed in version of my 48x48 image ingame. It's obvious in retrospect, but not mentioned anywhere at all on the internet as far as I can tell. Glad to have figured this out, and such a stipulation should probably be mentioned in the base overrides file.
Post by: Uthimienure on December 26, 2020, 04:45:07 pm
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]
I tried adding TWBT to an existing fort by following these instructions:
Unzip and copy plugin file from the 0.47.04-r1 folder to your Dwarf Fortress hack/plugins folder.
Copy the transparent1px.png, white1px.png, shadows.png to your data/art folder.
... and get this message when DFHack starts:
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!
Post by: Erendir on December 27, 2020, 04:45:32 am
... 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!
Post by: Uthimienure on December 27, 2020, 09:32:42 am
Perhaps another approach...
I'm running unmodded 0.47.04 with DFHack 0.47.04-r1 because of random crashing using the pack.
My current setup doesn't crash.
What I want is just the multi z-level aboveground display from TWBT, that's all.
Post by: Clément on December 27, 2020, 09:37:21 am
Post by: lethosor on December 27, 2020, 12:45:27 pm
Post by: Uthimienure on December 27, 2020, 04:05:40 pm
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.
Certainly! Here's the link: https://dffd.bay12games.com/file.php?id=15362
Post by: lethosor on December 27, 2020, 08:56:42 pm
Code: [Select]
loading plugin twbt
Can't load plugin twbt
The only other possibility I could think of is that you have 32-bit DF and DFHack, but stderr.log also indicates that you have 64-bit DF (and therefore must have 64-bit DFHack too):
Code: [Select]
Version: v0.47.04 SDL win64
If redownloading TWBT as Clément suggested doesn't help, uploading a copy of hack/plugins/twbt.plug.dll might be useful. Do you have any antivirus software that could be quarantining this file? If not, my only other guess is that the plugin was simply built incorrectly somehow, but I don't understand how nobody else would have run into that issue. You are using an older version of DFHack, though - any reason you can't upgrade? I know there's a build of TWBT from the same source for 0.47.04-r3 currently (not r4 yet): https://github.com/thurin/df-twbt/releases/
Post by: Uthimienure on December 27, 2020, 09:12:17 pm
I do have 64-bit DF and everything else.
And it's no surprise Windoze is particularly unhelpful.
I'll start with a fresh install for my next fort anyway, so not the end of the world... or maybe do a fresh install, and if I get it working, then copy over my current fort to that.
Post by: thurin on December 28, 2020, 04:29:18 pm
https://github.com/thurin/df-twbt/releases/tag/0.47.04-r4
Post by: Uthimienure on December 28, 2020, 07:12:07 pm
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.
Post by: Ziusudra on December 28, 2020, 07:22:57 pm
https://github.com/mifki/df-twbt#multi-level-rendering
Post by: clinodev on December 28, 2020, 07:25:55 pm
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.
You can choose the depth of multilevel with the DFhack terminal command `multilevel #` where # is a number from 0 to 15. Generally people will place such a command in dfhack.init.
Post by: Uthimienure on December 28, 2020, 07:36:19 pm
Thanks guys, and if I had been more observant I would have found that github/mifki page right in the O.P.
*duh*
Post by: alef on January 02, 2021, 01:50:37 pm
... 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].
Post by: Libash_Thunderhead on January 06, 2021, 02:52:01 am
I guess I'd better setup a 64 bit virtual machine, but I want to try my luck first. :P
Post by: Rose on January 06, 2021, 03:27:10 am
Post by: Fleeting Frames on February 01, 2021, 02:11:23 pm
Spoiler: Feature tweaks (8) (click to show/hide)
Spoiler: Bugfixes (5) (click to show/hide)
Known issues:
Vermin altties (purring maggots in vanilla) aren't handled.
Overrides for items in trade depot and wagon (outside of center tile) aren't handled.
Packaged together with Dragonmaster's tileset (http://www.bay12forums.com/smf/index.php?topic=168704.msg8243085#msg8243085) and dfhack/DF, available for DL here (https://mega.nz/file/d5QwzByJ#TTEgtlvhZ73M8sQY57O2V4xcAsSn1YSpfiP8jGNIbwE)
E: Fixed -bg layer being included in main set in IBSHEET
Post by: PeridexisErrant on February 18, 2021, 06:50:36 am
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.
Post by: thurin on February 18, 2021, 08:27:00 pm
- 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.
i've started working on this with dfhack folks.
open to any fixes that are needed of course.
Post by: Fleeting Frames on February 19, 2021, 06:10:35 pm
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.
Alas, I never got my registration confirmation for dffd (or mantis), so I can't. Otherwise would use it, yeah.
As for the second, haven't really looked into how precisely to do it for several reasons that ultimately boil down to no:
43.03 repo: Would take some time to figure out to have future compilation take more time and I dunno anybody who plays 4303 and would get new release either. Pain for no gain to anyone.
main repo: If speaking of the above version of TWBT, it'd be easier (but still an exercise) to lift the code for features, rewriting it in places, but it's still a fair bit of effort on top of the technical downsides as with previous.
As the features as whole aren't 100% upsides either, especially with being about aesthetics, would probably have to add and test bunch of code for toggles. I'd also feel responsible to fix the known stability issues as well, tbh.
Still, I might do it if I would be actively using it and there was subsantial enough positive interest; it's not like these upload posts take 0 time either. Not sure, but I guess it could still take week+.
However as it is, though, already suffer enough from modder's curse. mikekchar inspired me a while ago to only code up stuff I'll personally actually proceed to use, as a way to limit the damnation. Not the worst ideas, I'd say, given my most popular DF creations have only been of use to handful of players.
Post by: lethosor on February 19, 2021, 06:52:46 pm
Fleeting Frames: is the source code with your changes publicly available (I might have missed a link)? The download appears to be just 64-bit Linux binaries for 0.43.03, which are useful for that specific version+platform but obviously aren't portable. I can't make any promises about help from my end, but if we do end up with a more-actively-maintained TWBT fork, it could be nice to have the ability to get some of those changes merged in as well (if you're okay with that).
Post by: Manadras on February 20, 2021, 02:29:53 pm
... 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---
Post by: Fleeting Frames on February 20, 2021, 06:52:12 pm
@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 :)
Post by: lethosor on February 20, 2021, 08:08:59 pm
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.
Post by: treehugger on February 23, 2021, 09:35:21 am
... 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---
Marvelous!! Thank you so much for this!
Post by: Rydel on March 22, 2021, 10:34:41 am
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. ;)
I'm getting back into the game and resuming work on my graphic set - is this animation feature in the current version of TWBT? If so, how do I use it? I think I see how to set up random tiles from Meph's set, but while he has the tiles for animation, it didn't look like he was using them.
Post by: jecowa on March 22, 2021, 05:00:54 pm
Examples from Meph Overrides.txt:
Quote
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]
There's more stuff for water and rivers in there if you checkout his overrides file.
Post by: Rydel on March 22, 2021, 08:15:43 pm
Post by: jecowa on March 22, 2021, 11:42:30 pm
Post by: Rydel on March 29, 2021, 07:03:25 pm
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
Post by: Rydel on April 02, 2021, 09:03:32 pm
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.
Post by: Fleeting Frames on April 02, 2021, 11:12:43 pm
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.
Post by: jecowa on April 02, 2021, 11:50:39 pm
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
I don't know if you can override individual parts of creature remains. Meph tried to get a special icon for turtle shells, but it doesn't work.
Code: [Select]
[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.I feel like something like
Code: [Select]
[OVERRIDE:253:I:CORPSEPIECE:CORPSEPIECE::_MDF_overrides_13:162:16:::CREATURE_MAT:POND_TURTLE:SHELL] bodyparts should work, but no.I think TWBT has been patched so that "ANY" is specifically ignored. I'm not sure if it ever did anything.
Some creature parts can be overridden, though. It looks like you need to specify for each creature based on Meph's overrides.txt (https://raw.githubusercontent.com/DFgraphics/Meph/master/data/init/overrides.txt). Search for "lever" to find the relevant section. Meph might have already done all the work creating overrides for creature guts in there.
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.
Not seeing any clue of that in Meph.
The overrides instructions (https://github.com/mifki/df-twbt/#overrides) list special rules for BONE and SHELL, but I don't understand:
Quote
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.
I don't understand why this is a problem more for skulls than other items. Same thing happens when creatures walk over vermin remains. I think the species doesn't matter as long as the raw id is the same.
What do I need to search for in the linked file to find the part that disables sentient items?
Post by: Rydel on April 03, 2021, 07:01:38 am
I have a line for pend turtle shells that doesn't throw an error, though my test fort didn't have any pond turtle shells to see if it actually works:
[OVERRIDE:253:I:CORPSEPIECE:CORPSEPIECE::corpse:136::::CREATURE_MAT:POND_TURTLE:SHELL]
Post by: Fleeting Frames on April 04, 2021, 04:06:55 am
You can see what materials it outputs for things with this line:
Code: [Select]
:lua ~dfhack.matinfo.decode(dfhack.gui.getSelectedItem():getMaterial(), dfhack.gui.getSelectedItem():getMaterialIndex())Looks like linked Meph's overrides.txt only overrides fresh and rotten meat?
As for skulls, I was thinking of (sentient) dwarf/goblin skulls, not chicken skulls. The link should have taken to Line 47; the disabling bit is bad_item_flags.bits.dead_dwarf = true;
Post by: Rydel on April 04, 2021, 06:29:06 am
Interestingly, when checking corpseparts, it doesn't return anything, but also doesn't give an error. It just gives the new line back. That would explain why the individual overrides aren't working and possibly why the BONE material flag isn't, but I'm not sure what to make of it being completely blank
EDIT:
Thought: Is there anything you can put in a material template raw to change the tile of that when used as a corpse part? I'm editing raws anyway, so that is on the table.
Also, is there anything I can put in the override file to suppress errors related to bad materials? My override file currently contains overrides for forgotten beasts and night creatures, when, depending on your world, might not have the associated organs, causing an error, so I'd like to be able to suppress those error when releasing it.
Post by: Rydel on April 11, 2021, 09:59:12 pm
I'm trying to override tracks, and due to weirdness with them displaying, I am trying to specify the color per material. However, overrides like the following keeps giving me "TWBT: invalid new fg track", even though track is in the tileset position:
[OVERRIDE:30:T:MineralRampTrackEW:track:88:6:7::INORGANIC:PUDDINGSTONE]
Post by: jecowa on April 12, 2021, 08:30:08 am
Post by: Rydel on April 12, 2021, 11:56:10 am
Post by: Rydel on April 19, 2021, 11:44:39 am
To be clear, I'm not just referring to editing the normal tileset, I'd like to, for instance, use completely different images for moods vs insanity.
Post by: jecowa on April 19, 2021, 12:40:19 pm
Post by: Fleeting Frames on April 19, 2021, 01:27:50 pm
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.
Post by: Clément on April 19, 2021, 03:41:00 pm
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.
Has someone ever achieved something like that? It seems much more difficult than the inverted tile trick. Too many colors are used, and the quality of the effect would depend on the palette. For the downward arrow, you have: brown (red+green) → hungry, blue → thirsty, gray (all colors) → drowsy, red → stressed, yellow (red+green again) → distracted. Exclamation mark is even worse with all the moods, breakdown, madness, …
Post by: Fleeting Frames on April 21, 2021, 09:37:24 am
Even with just designation vs depot vs blood-coated wall tiles, I ran into the issue where it designations were brown (albeit green designations looked pretty neat too) so they'd pick up unacceptably much from shared colour. Ended up with a dithered magneta-green that translates roughly as off-white when white is used but darker than than white square with red.
It's pretty hard to make it work beyond three of red/green/blue.
Post by: bumm3r on June 06, 2021, 07:24:50 pm
I also found that unlimiting my GFPS (by setting it to 0 in LNP) caused the issue to go away entirely. :)
Post by: Zlove89 on July 22, 2021, 09:19:06 pm
Post by: Ziusudra on July 22, 2021, 10:59:02 pm
Post by: waterphage13 on August 08, 2021, 04:20:56 pm
Post by: Freak2121 on August 09, 2021, 07:00:27 pm
Spoiler (click to show/hide)
Is this a known issue and is there a solution to it?
Edit 1: Silly me, some of the tiles in the font and map sets have outlines.
Post by: Fleeting Frames on August 10, 2021, 06:40:03 am
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).
Post by: waterphage13 on August 10, 2021, 09:25:31 am
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).
Post by: Dubya on August 23, 2021, 04:53:39 am
EDIT: found the problem, my custom workshop didn't have the correct values in the [COLOR:0:0:0:0:0:0:0:0:0:0:0] fields. I had forgot to change the first value past 0 for the different building stages.
Post by: vettlingr on August 27, 2021, 03:53:43 am
I would like to request an idea I have.
It would be cool to be able to use custom material groupings as a material flag/token like so:
[MATERIALGROUP:IGNEOUS_GRANULATE]
[INORGANIC:GRANITE]
[INORGANIC:DIORITE]
[INORGANIC:GABBRO]
[END]
Then apply it like so:
[OVERRIDE:205:T:MineralWallSmoothLR:6:142:::IGNEOUS_GRANULATE:]
[OVERRIDE:186:T:MineralWallSmoothUD:6:159:::IGNEOUS_GRANULATE:]
[OVERRIDE:200:T:MineralWallSmoothRU:6:173:::IGNEOUS_GRANULATE:]
[OVERRIDE:211:T:MineralWallSmoothRU2:6:126:::IGNEOUS_GRANULATE:]
[OVERRIDE:212:T:MineralWallSmoothR2U:6:190:::IGNEOUS_GRANULATE:]
That way you could limit the amount of override lines needed for materials that share the same override.
Post by: Fleeting Frames on August 28, 2021, 06:58:37 am
Post by: jcrabbit on August 28, 2021, 02:51:29 pm
Code: [Select]
(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.Running in TWBT_LEGACY mode gets
Code: [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?
Post by: ldog on August 28, 2021, 03:53:06 pm
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 fullNot 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?
I don't know enough to know what causes the crash, but if it is a new embark, try disabling it, loading up, saving, exiting, enabling it again (god knows I absolutely hate the way the game looks w/o TWBT). This is the usual solution on Windows, but it may work on Linux too. It doesn't always crash, and this doesn't always solve it, but probably worth a shot.
Post by: jcrabbit on August 28, 2021, 04:49:28 pm
Code: [Select]
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:
I suspect it's simply not stable on Linux at this point.
Post by: Ziusudra on August 28, 2021, 04:55:08 pm
Post by: jcrabbit on August 28, 2021, 05:09:35 pm
Post by: lethosor on August 28, 2021, 11:07:12 pm
Binaries are available at Ziusudra's link, but I strongly suspect your pack is using one of those already.
Post by: thurin on August 30, 2021, 12:23:22 am
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.
If using McArcady's Linux LNP, he builds TWBT (and pretty much everything else too) from source rather than using a prebuilt Release.
Post by: noomen on September 22, 2021, 08:22:20 am
I'm using Vanilla DF, with DFHack mainly for TWBT. However, when I "l" in order to see around me, that huge text (screenshot in link below) still appears even though TWBT is running. Any ideas?
I'm playing in adventure mode, if that makes any difference.
Thank you in advance.
https://imgur.com/a/WPsFp7g
Post by: lethosor on September 22, 2021, 08:17:30 pm
Post by: noomen on September 22, 2021, 09:27:33 pm
Adventure mode support definitely has gaps - that's probably one of them.
Any workarounds or alternatives to TWBT that you would recommend. I just would like to play adv mode, and later fortress mode, with normal size text.
Post by: noomen on September 23, 2021, 09:13:17 am
Post by: lethosor on September 23, 2021, 11:26:04 am
Post by: waterphage13 on January 23, 2022, 03:43:43 pm
Post by: thurin on January 28, 2022, 06:54:01 pm
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.
Post by: waterphage13 on January 29, 2022, 06:26:22 am
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.
Post by: thurin on January 29, 2022, 01:53:23 pm
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.
Post by: waterphage13 on January 29, 2022, 02:50:32 pm
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.
Post by: myk on April 08, 2022, 10:02:05 am
Post by: thurin on April 09, 2022, 08:44:51 pm
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?
Thanks for the heads up. Taking a look.
Post by: Deon on April 27, 2022, 02:52:47 pm
It's still impossible to have different graphics for different castes, while assigning different ASCII symbols is totally fine, correct?
Post by: Clatch on July 02, 2023, 11:52:42 pm
(https://i.imgur.com/Z0NaOgE.png)
What causes this when TWBT is activated?
Post by: Clatch on July 03, 2023, 07:50:15 am
What causes this when TWBT is activated?
Nevermind... I just referenced what was going on in Jecobus_10x16.png.
Post by: tnuhnivad on October 08, 2023, 08:25:23 pm
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.
Post by: blitz4 on December 11, 2023, 06:02:21 am
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.
I don't know the status of TWBT
I do know this script works perfectly. Thank you lethosor
Post by: blitz4 on December 11, 2023, 06:15:04 am
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.
Copy the script lethosor wrote above into a lua file, I called it install-twbt-refresh.lua
Save to hack\scripts\install-twbt-refresh.lua
Open dfhack-config\init\onMapLoad.init
Add one line at the bottom
Code: [Select]
install-twbt-refresh
exit & save