Hello! I'm pretty sure the hex error from Legends Viewer is the usual bug where dfhack stores non-printable data structures in historical figures, and then the export is 'toxic' to Legends Viewer. It's most common from workflow, but other tools use it too - I've arranged for a fix to be in the next version of dfhack but that's not helping yet.
Adding files individually sounds like a good way to test - but I think what's happening is it waits to have all four selected, then tries to load them and runs into the legends.xml problem. One part of the legends processing script removes problematic lines, so it's probably a good pick in this case.
Troubleshooting the processing script is trickier, because I know of more things that could go wrong! (just saw new post) Ok, latest version, that makes things a little easier. Are you using r51 or later of my starter pack? If so, there's a dfhack tool (exportlegends) bound to shift-A in legends mode which will export everything you need to run the Legends processor. You shouldn't need to do any pre-processing!
If the XML is coming out at 0B, that sounds like a problem... the way my processor 'cleans' the file is to copy every line that doesn't have the problem into a new file, then replace the old with the new. So either the whole file is corrupted, even the bits that aren't exported info, (about as likely as a new file spontaneously coming into existence) or I don't understand what's happening
.
So, given the small size of the XML, you've probably got to do it by hand.
No errors here:
<historical_figure>
<id>-567</id>
<name>autobutcher/watchlist/bird_owl_barn bileace the ace ace</name>
<appeared>0</appeared>
<birth_year>0</birth_year>
<birth_seconds72>0</birth_seconds72>
<death_year>0</death_year>
<death_seconds72>0</death_seconds72>
<breed_id>0</breed_id>
</historical_figure>
Tracking down the error takes us past autobutcher to workflow, specifically the <name> field which refuses to print here. If it did, there wouldn't be this problem...
<historical_figure>
<id>-565</id>
<name>`
' ash</name> ---from name to here is a single line of characters
<appeared>0</appeared>
<birth_year>0</birth_year>
<birth_seconds72>0</birth_seconds72>
<death_year>0</death_year>
<death_seconds72>0</death_seconds72>
<breed_id>0</breed_id>
</historical_figure>
And, while I was writing this, ... Bingo. Run the following as a batch file in the same folder as your legends file, and enjoy the lack of crashing viewer.
echo off
setlocal
Rem This script will 'clean' legends xml files for Legends Viewer, by deleting lines which contain the problematic character "SOH" (left by workflow on abandon).
FOR /L %%G IN (1,1,99) DO (
IF EXIST "%CD%\*region%%G*" (
set "region#=region%%G"
goto got_region
)
)
echo No legends XML found
pause
goto end
:got_region
set "SOH="/SOH/"" rem because findstr will take this in a variable but not directly, you'll need to add this yourself (where /SOH/ is)
FINDSTR /v /l %SOH% "%CD%\%region#%-legends.xml">"%CD%\%region#%-legends-cleaned.xml"
del "%CD%\%region#%-legends.xml"
rename "%CD%\%region#%-legends-cleaned.xml" "%CD%\%region#%-legends.xml"
:end
You can either use this, or open the xml in
Notepad++ (which shows non-printing characters/control characters as labelled black blobs) and do a find-and-replace to change them into spaces.
Author
Topic: Legends Viewer 1.13 (v40 Compatible) (Read 317806 times)