Print

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

[Rumrusher]

So just notice the entity animal token issue with migrants can be fixed with writing up a script that checks the new migrants for missing a population id... oh wait these units also don't have a historical figure id, hmm uhh I wonder if it's easier to just use spawn unit to create a historical figure id for these units then?

[lethosor]

I don't know if it matters for me to respond as well, but three data points is better than two right?

My original, faulty path was "D:\Gustav\detsomfallitfrånträden\övrigt\DF\df_44_12_win". As you can see I manage to score all three Swedish letters in there. In alphabetic order, even. Go me.

Running the commands you asked:

Code: [Select]

[DFHack]# lua print(dfhack.internal.getScriptPaths())
table: 0000026AE1010560

Sorry, I wanted printall, not print! (I didn't actually test it first). This is the one I'm more concerned about, really, so if you can double-check, that would be great.

Code: [Select]

[DFHack]# lua print(dfhack.filesystem.getcwd())
D:\Gustav\detsomfallitfrÕntrõden\÷vrigt\DF\df_44_12_win
Õ appears to be an O with a ~ over it.

å=Õ
ä=õ
ö=÷

I don't if you want to know what symbols they become, just continuing off of Lundell's musings, but anyway to get all the capital letters as well I moved the DF map to "D:\...\DF\Å\Ä\Ö\df_44_12_win

Code: [Select]

[DFHack]# lua print(dfhack.filesystem.getcwd())
D:\...\DF\┼\─\Í\df_44_12_win
Å=┼
Ä=─
Ö=Í

Yeah, the letters changing is weird. As Clement pointed out, it's probably something to do with the DFHack console using a different encoding (I think it uses CP437 like DF on Windows?). It's probably not the cause of the issue you were having, but it could be a related issue.

I tested it on Mac too.

path:
Applications\Älgstubben\Bäverdammen\Järvträsket\Lazy Mac Pack v0.44.12 dfhack-r2/Dwarf Fortress 0.44.12/

I can confirm that LNP won´t launch when there are common Swedish words in the path.

Changing "Games" to "Gämes" in my path to DF causes the LNP launcher to fail to launch.

I should clarify - I don't care at all about LNPs; I'm just interested in the DFHack issue (which is that running Ruby scripts from these paths doesn't work). I do have macOS and Linux systems available, but if you can test running just DFHack (without going through PyLNP) from a path with special characters, that would be great. PyLNP issues like the one you described should go here: http://www.bay12forums.com/smf/index.php?topic=140808.0

Note that I'm unable to copy/paste from the DFHack window

Yeah, Windows is a bit weird here, but you should be able to do it by right-clicking on the title bar of the DFHack console.

This command isn't working for me:

Code: [Select]

dfhack.run_command("modtools/force -eventType NightCreature")
The script is running (as the print command works), but nothing is happening for that line.

I am trying to get a random werecreature to spawn in fortress mode. Am I missing something in that code?

Does running "modtools/force -eventType NightCreature" in the DFHack console do what you expect?

[scriver]

Is this what you meant?

Code: [Select]

[DFHack]# lua printall(dfhack.internal.getScriptPaths())
1                        = D:\Gustav\detsomfallitfrÕntrõden\÷vrigt\DF\df_44_12_win/raw/scripts
2                        = D:\Gustav\detsomfallitfrÕntrõden\÷vrigt\DF\df_44_12_win/hack/scripts

[lethosor]

Is this what you meant?

Code: [Select]

[DFHack]# lua printall(dfhack.internal.getScriptPaths())
1                        = D:\Gustav\detsomfallitfrÕntrõden\÷vrigt\DF\df_44_12_win/raw/scripts
2                        = D:\Gustav\detsomfallitfrÕntrõden\÷vrigt\DF\df_44_12_win/hack/scripts

Yup! To explain further: these two folders are where DFHack will look for scripts. To work around some issues with special characters, it will remove the DF path from the beginning, but it has to match exactly (which it should, but if it doesn't, that could explain the issue you saw). However, it looks like this does match the DF path you posted earlier, so that rules out the specific problem I was thinking of:

Code: [Select]

[DFHack]# lua print(dfhack.filesystem.getcwd())
D:\Gustav\detsomfallitfrÕntrõden\÷vrigt\DF\df_44_12_win

[Clément]

I think it uses CP437 like DF on Windows?

On my system (french locale), it uses CP850 (it matches scriver case too). It is a DOS encoding, I guess it is there for compatibility with old console applications.

There is SetConsoleOutputCP that would let you change the console encoding (use it with GetACP to have the same encoding everywhere).

Another solution is to use the unicode API for windows calls, everything will be UTF-16 in this case (even the console).

There is still the ruby error, but I don't know how that part works.

[PatrikLundell]

In the short term (before Toady expands the character set with the Premium arc), it sounds like it would be appropriate for the DF console to use the same code page as DF does (CP437) to get the output to match what DF produces, but I suspect this is a pure display issue, while the path incompatibility issue lies elsewhere. I guess it would make sense to check the non Windows DFHack console for display issues while investigating this, but since we've got a Mac report of path incompatibilities as well (although no printed output has been provided, since it was requested after that report), the deeper issue is probably not tied to the console version.

When it comes to post Premium DF the suitable solution ought to depend on how DF is changed, which remains to be seen: as far as I can see, the output ought to match what DF displays as closely as possible. And, when at it, the DF color palette expansion will require something different from the current mapping if it should follow suit, and might even be expanded to support background color in the console.

[Clément]

Changing the windows console encoding is the easy fix, but you won't be able to display both paths (or error strings or whatever windows gives you) and df strings correctly. The best solution is to use unicode everywhere, but it will require more work.

Running dfhack on linux in a directory containing "éçà" does not generate any error (ruby or other).

[PatrikLundell]

Changing the windows console encoding is the easy fix, but you won't be able to display both paths (or error strings or whatever windows gives you) and df strings correctly. The best solution is to use unicode everywhere, but it will require more work.

Running dfhack on linux in a directory containing "éçà" does not generate any error (ruby or other).

When using the command scriver has issues with ("startdwarf 10")? I had no problems with DFHack itself with the funny path: DF started just fine when invoked directly, and the commands lethosor provided worked without issues. I assume it's scripts written in Ruby that get into trouble.

You can't easily differentiate between strings that originated within DF(Hack) from those that originated from buried calls to external functionality, unless you convert everything everywhere to use Unicode (or something else) at every interfacing function internally in DFHack and then convert it back to CP437 when feeding it to DF, and printing things as DF(Hack) perceives them is probably the least confusing option. String manipulation gets messy with variable size encodings as well.

[lethosor]

I think it uses CP437 like DF on Windows?

On my system (french locale), it uses CP850 (it matches scriver case too). It is a DOS encoding, I guess it is there for compatibility with old console applications.

In the short term (before Toady expands the character set with the Premium arc), it sounds like it would be appropriate for the DF console to use the same code page as DF does (CP437)

Interesting - my understanding was that it was supposed to use CP437 on Windows by default (at least, I have never seen complaints that printing CP437-encoded names from DF with accented characters to the console displays the wrong characters on Windows, while I've seen several complaints about the same issue on Linux/macOS). Can you double-check whether print(dfhack.TranslateName(some_unit.name)) displays the right characters in the Windows console?

[Clément]

Interesting - my understanding was that it was supposed to use CP437 on Windows by default (at least, I have never seen complaints that printing CP437-encoded names from DF with accented characters to the console displays the wrong characters on Windows, while I've seen several complaints about the same issue on Linux/macOS). Can you double-check whether print(dfhack.TranslateName(some_unit.name)) displays the right characters in the Windows console?

è from the unit name is displayed correctly, but the è from the path is displayed as Þ which is not part of CP437.
For reference, è is 0x8a is CP437 and CP850, but 0xe8 in CP1252. 0xe8 gives Þ in CP850, but Φ in CP437. You may just have been lucky because non-ASCII characters used in DF names are compatible between CP437 and CP850. Or CP437 may be the default for the US locale. I wonder what happens with other locales using different alphabets (like cyrillic, arabic, ...).

I thought there was a conversion with the DF2CONSOLE function, but apparently it is only for Linux.

When using the command scriver has issues with ("startdwarf 10")? I had no problems with DFHack itself with the funny path: DF started just fine when invoked directly, and the commands lethosor provided worked without issues. I assume it's scripts written in Ruby that get into trouble.

I did not test that, on Windows starting DF is enough to get the error messages. I'll try that later.

[lethosor]

You may just have been lucky because non-ASCII characters used in DF names are compatible between CP437 and CP850. Or CP437 may be the default for the US locale. I wonder what happens with other locales using different alphabets (like cyrillic, arabic, ...).

Oh, that's probably it, actually!

I thought there was a conversion with the DF2CONSOLE function, but apparently it is only for Linux.

It's defined to "do the right thing" on all platforms, which is specifically a no-op on Windows. Seems that we might need to adjust that. Thanks for the insight.

[Rumrusher]

hmm starting to wonder if it's possible for me to add retired adventurers to a site via workers and recruit them that way? like I recently poke around the recall workers list and notice it draws from the nemesis pool, but only if said nemesis has a unit id tied to them.

[Clément]

When using the command scriver has issues with ("startdwarf 10")? I had no problems with DFHack itself with the funny path: DF started just fine when invoked directly, and the commands lethosor provided worked without issues. I assume it's scripts written in Ruby that get into trouble.

No issue with startdwarf on Linux with a "é" and even a "𝄋" (U+1D10B) in the path. No error message in the console and I get the expected number of dwarf.

[Heretic]

That is scale of army coords?
As i can manually test it's look close to 1/3 of chunk.
But I absolutely not sure.
EDIT: Then i use this size it works mostly fine, but i'm still unsure.

[Heretic]

Another thing - need to teleport adventurer to world coords. How can i do it? teleport.lua work only inside one global tile for me.
okey, i found a solution - questport works fine. But i can't make it teleport for choosen numbers coords on global map, not by q-menu. Can somebody help please?