Print

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

[Roses]

Here's another question for those of you more knowledgeable about the gui programming. Right now I know how to put pictures and things onto the screen, but if I write text over them it appears as a black box with writing. Is it possible to make that box transparent so that you just see the text?

By "pictures and things", are you referring to tiles? You can't put text partially on top of other tiles.

I realize an image might have better portrayed what I was trying to say. This is what I mean by pictures.

If I were to place text over that picture it would show up with a black background and white text (or whatever color I used for the foreground and background). I was wondering if there was a transparent background pen color.

[lethosor]

Yeah, are you creating that picture out of tiles, like creature tiles? You can't put text tiles on top of graphical tiles (or any tiles on top of other tiles, for that matter). You can give text a "transparent" background of varying degrees (in fact, the vanilla tileset does this), but rather than showing another tile in the transparent parts, DF shows the background color you specify for that tile instead.

You might be able to get good results with text on a white background in the white parts of that image, though.

[Roses]

Ah, I see what you mean now. Was hoping to be able to make a cool visual out of something like this for my Bestiary/Herbiary/Journal

Spoiler (click to show/hide)

[PeridexisErrant]

Is anyone else interested in fuzzing DFHack?  I was inspired by this blog post, and a comment that the alphas would be more useful if people ran all the commands

I've put together a dead-simple example here, which just uses dfhack-run to call every command output by ls.  This discovered two plugins that crash DF when called from dfhack-run, and more than twenty scripts that give stack traces instead of anything useful when called in fort mode.  My basic principle is that it is always a bug when DFHack can crash DF, or when scripts give the user a traceback instead of an error message.

If this does seem useful or interesting, I'd be interested in trying to make it smarter (ie knowing what context is required, that arguments exist, etc).  This would be helped by some helper scripts on the DFHack side - eg 'return to main screen', or ways to discover what mode a script can be used in.  And of course if we find more bugs, someone will need to fix them...

[milo christiansen]

How about adding another set of "special comments", but instead of specifying that the script can be loaded as a module, or that is can be enabled, they would specify the game mode and possibly a set of allowable UI contexts?

Tagging existing scripts would be a pain, but once it's done it's done.

At some later date DFHack itself could possibly warn users or simply not allow scripts to be used in invalid (for that script) contexts. Doing this once in the script execution system would remove the need to do it over and over in individual scripts. Just a thought.

[Rumrusher]

Ah, I see what you mean now. Was hoping to be able to make a cool visual out of something like this for my Bestiary/Herbiary/Journal

Spoiler (click to show/hide)

you could play off the black and background with having the image be a giant inkblot that expands and reveals the ingame text and have the paper scroll out to show the other png doodles.

[Rose]

Have the center fade to a specific background color that's one of the available background colors in DF, and have the text have that background color.

[ab9rf]

My basic principle is that it is always a bug when DFHack can crash DF, or when scripts give the user a traceback instead of an error message.

Oh drat, that kiboshes the Ruby plugin then. It's fairly trivial to crash it, because Ruby code can access arbitrary memory pointers, and a segmentation error is an uncaught signal on Linux or uncaught exception on Windows, both of which lead to an immediate die. The Lua runtime seems to handle this a bit more robustly, with the exception/signal being confined to the Lua interpreter thread.

[PeridexisErrant]

My basic principle is that it is always a bug when DFHack can crash DF, or when scripts give the user a traceback instead of an error message.

Oh drat, that kiboshes the Ruby plugin then. It's fairly trivial to crash it, because Ruby code can access arbitrary memory pointers, and a segmentation error is an uncaught signal on Linux or uncaught exception on Windows, both of which lead to an immediate die. The Lua runtime seems to handle this a bit more robustly, with the exception/signal being confined to the Lua interpreter thread.

I meant something more like "when using a standard script or plugin in any way can crash DF, that's a bug" - of course if users get arbitrary code execution and access to memory it's possible to cause a crash.  While I'm certainly not a fan of crashes and would like a more robust ruby plugin, it's useful enough to keep anyway

[Warmist]

My basic principle is that it is always a bug when DFHack can crash DF, or when scripts give the user a traceback instead of an error message.

Oh drat, that kiboshes the Ruby plugin then. It's fairly trivial to crash it, because Ruby code can access arbitrary memory pointers, and a segmentation error is an uncaught signal on Linux or uncaught exception on Windows, both of which lead to an immediate die. The Lua runtime seems to handle this a bit more robustly, with the exception/signal being confined to the Lua interpreter thread.

Actually it does not. E.g. if you try to print values from global.world.units.bad[id] when they are really deallocated it crashes df. This is because all data access checking would incur too much of a penalty and you don't want to deep print everything anyway.
However lua has 0 pointer checks (e.g. you can't print a struct if it's pointer 0) also type checks, so you can't insert random crap into std::vector<unit> and so on.

[wooks]

Any chance either of these will work with current versions of DFHack/DF. Not really sure where I picked them up, but had them sitting around and thought they might be useful for some generational fort messing about...

I have no idea whether or not those scripts would still work. However, I do know that the current DFHack already has this functionality. Check the DFHack documentation for gui/family-affairs: "view, add, remove, or otherwise change romantic relationships". This includes a user-friendly interface and, among other things, it allows the user to force a marriage or divorce.

This appears to have issues finding dwarfs whom are stuck at the 'lover' stage.

[lethosor]

I'm putting up a build now to fix the issues with buildingplan/etc. that showed up in alpha3, as well as some other outstanding Linux issues. Right now, there are only OS X and Linux builds. If anyone's around that can do both Windows builds (and check them with devel/check-release), that would be much appreciated.

Edit: https://github.com/DFHack/dfhack/releases/tag/0.43.05-alpha4

Edit 2: Windows builds are up, thanks to ab9rf!

[scourge728]

So, can you show me how to use createitem to make dog bones?

[lethosor]

I believe those would have an item type of CORPSEPIECE, which isn't possible to create. createitem uses custom reactions, which don't support CORPSEPIECE items, so createitem blocks that item type. I think DF will crash if you try to bypass that.

[scourge728]

drat...