Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003565Dwarf FortressDwarf Mode -- Embark/Setuppublic2010-11-12 15:512010-11-12 19:06
Reporterrofl0r 
Assigned ToLogical2u 
PriorityimmediateSeverityblockReproducibilityalways
StatusresolvedResolutionduplicate 
PlatformOSlinuxOS Version
Product Version0.31.17 
Target VersionFixed in Version 
Summary0003565: applying the raw changes for mayday's tileset results in butcherable Dwarfes after worldgen/embark
Description*no jobs can be assigned to the embarked dwarfes
*they have the "slaughter this animal" entry
*they use the tiles "H" or "S"
Steps To Reproduceapply the diff from https://github.com/rofl0r/df-mayday [^] on the linux version, gen a small world and embark.
Additional Informationi created another bigger diff with more context from DFG_31.16. here it is: https://gist.github.com/674915 [^]
same result, but this diff has so much context that the error is very likely not in the diff, but in the game.

additionally, a world genned with the applied patch will be way faster to generate (around 1/4 of the total time), and DF will crash when the fort is abandoned after the useless embark.
TagsNo tags attached.
Relationships
duplicate of 0001428resolved Toady One Backup raws files (*.txt~, *.txt.bak) get parsed, causing mismatched IDs and crashes 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-11-12 15:51rofl0rNew Issue
2010-11-12 16:17rofl0rNote Added: 0013722
2010-11-12 16:45QuietustNote Added: 0013724
2010-11-12 16:56Logical2uNote Added: 0013725
2010-11-12 16:56Logical2uStatusnew => resolved
2010-11-12 16:56Logical2uResolutionopen => no change required
2010-11-12 16:56Logical2uAssigned To => Logical2u
2010-11-12 17:12rofl0rNote Added: 0013728
2010-11-12 17:12rofl0rStatusresolved => needs feedback
2010-11-12 17:12rofl0rResolutionno change required => reopened
2010-11-12 17:20rofl0rNote Added: 0013729
2010-11-12 17:20rofl0rStatusneeds feedback => assigned
2010-11-12 17:26rofl0rNote Edited: 0013728bug_revision_view_page.php?bugnote_id=0013728#r5287
2010-11-12 17:26Logical2uNote Added: 0013730
2010-11-12 17:34rofl0rNote Added: 0013731
2010-11-12 17:55rofl0rNote Added: 0013733
2010-11-12 18:37rofl0rNote Added: 0013735
2010-11-12 18:46QuietustNote Added: 0013736
2010-11-12 18:51QuietustNote Edited: 0013736bug_revision_view_page.php?bugnote_id=0013736#r5291
2010-11-12 19:06Logical2uNote Added: 0013737
2010-11-12 19:06Logical2uRelationship addedduplicate of 0001428
2010-11-12 19:06Logical2uStatusassigned => resolved
2010-11-12 19:06Logical2uResolutionreopened => duplicate

Notes
(0013722)
rofl0r   
2010-11-12 16:17   
if you look at the diff in the second link, it is pretty clear that the bug is in DF. apart from enabling graphics mode and setting custom colors it only changes tile numbers all over the raws.
(0013724)
Quietust   
2010-11-12 16:45   
Are you certain that the patch succeeded without any errors, and that it did not leave any backup files behind (which would be parsed as duplicate raws, known to cause this sort of problem)?
(0013725)
Logical2u   
2010-11-12 16:56   
I'm closing this as there is NO indication that this is a problem with DF.

You're making modifications to the game, using an automated script - and apparently holding these scripts unchanged between multiple versions - and claim that it's a problem with DF and not one you introduced artificially?

Unless you can reproduce this on a clean, unmodified version of DF, please do NOT reopen this. It's not Toady's responsibility to make mods to the game work.

The crashing on reclaim is probably due to other bugs that cause reclaim crashes. The speed increase and the buggy dwarves are probably due to RAWs not getting loaded properly and entire species disappearing.
(0013728)
rofl0r   
2010-11-12 17:12   
(edited on: 2010-11-12 17:26)
have you looked at the diff ? IT IS ONLY CHANGING SOME TILE'S NUMBERS.

the diff applied perfectly on 0.31.17 [no conflicts]

it's 100% DF's fault here.
(0013729)
rofl0r   
2010-11-12 17:20   
btw, the crash is not on reclaim, but on abandon
(0013730)
Logical2u   
2010-11-12 17:26   
Sure, but if default DF works fine, then your diff causes this behaviour, then it's obviously the diff's fault. Hence why I asked you to reproduce it on a clean, unmodified version of DF.

Even if your diff is only changing tiles, if the problem can be tracked to the diff that means it's either a mistake in the diff - or it can be tracked back to something much more useful to Toady, as in a reproducible RAW mismatch due to modifying something's colour.

You've provided us with the 31.16 diff but is the 31.17 diff the same? I am guessing that Toady added a new critter/removed one and that is throwing something off.
(0013731)
rofl0r   
2010-11-12 17:34   
i guess toady just didnt test the graphics mode before releasing.

as i said the diff can be applied to 0.31.17 without a single warning. this means every region touched by the diff is exactly like it was before.
(0013733)
rofl0r   
2010-11-12 17:55   
update: when the world is generated on "vanilla", and the patch later applied (and raws transferred to region1), everything is ok.
(0013735)
rofl0r   
2010-11-12 18:37   
Quietust: you were right, for some reason the patch creates 3 file like creature_standard.txt.orig
when i delete those before worldgen, embarking succeeds.
but the worldgen itself is still much faster, and its offloading only 2000 units at the end compared to 7000 with vanilla
(0013736)
Quietust   
2010-11-12 18:46   
(edited on: 2010-11-12 18:51)
The .orig file creation is an entirely normal behavior for the 'patch' program - in the version I have (on FreeBSD), it's possible to change the way it names the backups, but it's not possible to disable their creation altogether.

In any event, that makes this a duplicate of 0001428.
(0013737)
Logical2u   
2010-11-12 19:06   
I can't explain the speed (is that even really a bad thing? If you have evidence beyond "less units" - ie, there are specific units missing from history, like say there are no frogs or elves, that sort of thing - please reopen this - it doesn't look like default world gen settings are being modified), but the backups getting parsed appears to have been the main problem and is definitely, as Quietust says, 0001428.