Bay 12 Games Forum

That appears to be a similar problem, except with {{verminlookup/0}} instead of {{creaturelookup/0}}.
Edit: Not quite - it doesn't display the template size warning that the other two pages display. I suspect some sort of internal problem with DFRawFunctions in this case, but I'm not sure what's wrong with the pages you mentioned earlier.

Quote from: King Mir on August 23, 2014, 08:30:29 pm

Then yeah, the only way to fix this is with memory hacking, which means tools like TwbT.

This could be considered a bug though. If you file a bug report, maybe Toady will change it so that accented characters uppercase to their non-accented counterparts.

I thought the problem is that accented letters don't have capital versions defined. The better fix would be to actually capitalise accented letters when appropriate - an encoding that can do the lowercase should be able to produce the uppercase versions as well: á - Á, ö - Ö, û - Û etc.

The problem is that only Å, Æ, Ä, É, Ñ, Ö, and Ü are defined in CP437 and thus available to DF (see http://en.wikipedia.org/wiki/Cp437#Internationalization). Adding uppercase versions of other letters would most likely require rewriting DF's tileset support to allow more than 256 characters, which would not be easy.

[PRINT_MODE:x] in DF/data/init/init.txt
I recommend decreasing G_FPS_CAP (in the same file) if you're experiencing issues with larger screen grid sizes - the default is 50, but I usually don't notice a difference when it's set to 20-25.

The executables I get with PyQt are 11.5 Mb on Windows, 14.4 Mb on MacOS and 22 Mb on Linux (which surprises me, actually). They are not small by any means, but IMO also not extremely large.

Those sizes sound reasonable to me. I was probably doing something wrong, then.

Something that may work is using TkGui.withdraw() instead of sys.exit() when autoClose is enabled - this should hide the PyLNP window without exiting completely. I'm not sure how well this will work on all platforms, though - the launcher may remain open but invisible after exiting DF.

EDIT: exec* is not an option because utilities need to be launched after DF - so it's necessary to find a way to launch DF as an entirely stand-alone process, with its own terminal window. For Windows, I can use the start command; on OS X, I can use open. I haven't been able to figure out a useful possibility on Linux; I don't see a way to make Python do it directly, and I haven't been able to detect which terminal program the user is using to launch a new one. If anyone knows something I don't, I'm all ears.

Is there a reason for this? I think some utilities (DT?) check for DF on startup, but I don't know of any that exit immediately if DF isn't running (and either way, there's no guarantee which will finish launching first). Admittedly, exec() won't work with DFHack if PyLNP is launched without a terminal window, so it's not a complete solution.

Fake edit:

I tend to think that handling most cases is good enough, so my logic would be:
 - if someone wants to use DFHack on Linux, use xdg if that'll work.
 - otherwise make them configure it in the config, and don't spend time trying to make the launcher smart enough to help much.
 - if they can't do that, no dfhack through the launcher.

I think this would cover most people under the first point, and those not covered are probably able to finish setting that up themselves.  And the worst cast is they have to start DF manually to play with DFHack - hardly a disaster. 

It's worth mentioning that the current default is to not close the launcher when launching DF, which doesn't cause any problems with DFHack (until the launcher is closed, that is).

Quote from: Xerberus on August 20, 2014, 03:04:06 pm

Quote from: Bolland on August 20, 2014, 02:59:01 pm

Quote from: PeridexisErrant on August 19, 2014, 05:18:25 pm

I wouldn't call it normal, but it's a known and fairly harmless bug in the dfhack trade plugin. They're trying to keep up with the memory addresses, so sometimes there's minor incompatibility with Toady's changes. It should be fixed soon enough.

I hope it is. It's a royal pain when filtering to try searching for "ruby" and have all items that have r in them (most items) be unselected. It's tough to remember that some words have u or m in them, and not search for them. I'm looking forward to static DF again

i was never really using much of the dfhack commands in the DF2012 version but i do miss these little additions like search function, filtering and workflow (which lets you say i want always have 10-15 barrels for example). automation too much in games takes away the "game" element which consists of the user-input, but some things i don't want to do every 5 minutes. and searching row by row the entire trade screen to look for another anvil for example is just tedious and the search function is highly welcome here^^.

Workflow still works in-game if you use Alt-w when in Q-mode over a workshop.

I'm not sure what you mean - both workflow and the search plugin require DFHack, and both work in v0.40 (although the search plugin has a placement issue, as mentioned above).

I wouldn't call it normal, but it's a known and fairly harmless bug in the dfhack trade plugin. They're trying to keep up with the memory addresses, so sometimes there's minor incompatibility with Toady's changes. It should be fixed soon enough.

The problem isn't due to memory addresses changing - the problem is that Toady made the trade screen expand to the screen height, and nobody noticed and remembered to update the search plugin before DFHack was released. Anyway, this is a fix for the layout problem.

They don't - wagons only require a 3x3 path from a map edge to the depot. They do tend to come from the same direction in a single fort, however - this may be due to the location of their home civilization in the world.