Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
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.
Attached Files

- Relationships
duplicate of 0001428resolvedToady One Backup raws files (*.txt~, *.txt.bak) get parsed, causing mismatched IDs and crashes 

-  Notes
(0013722)
rofl0r (reporter)
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 (reporter)
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 (manager)
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 (reporter)
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 (reporter)
2010-11-12 17:20

btw, the crash is not on reclaim, but on abandon
(0013730)
Logical2u (manager)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (manager)
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.

- Issue History
Date Modified Username Field Change
2010-11-12 15:51 rofl0r New Issue
2010-11-12 16:17 rofl0r Note Added: 0013722
2010-11-12 16:45 Quietust Note Added: 0013724
2010-11-12 16:56 Logical2u Note Added: 0013725
2010-11-12 16:56 Logical2u Status new => resolved
2010-11-12 16:56 Logical2u Resolution open => no change required
2010-11-12 16:56 Logical2u Assigned To => Logical2u
2010-11-12 17:12 rofl0r Note Added: 0013728
2010-11-12 17:12 rofl0r Status resolved => needs feedback
2010-11-12 17:12 rofl0r Resolution no change required => reopened
2010-11-12 17:20 rofl0r Note Added: 0013729
2010-11-12 17:20 rofl0r Status needs feedback => assigned
2010-11-12 17:26 rofl0r Note Edited: 0013728 View Revisions
2010-11-12 17:26 Logical2u Note Added: 0013730
2010-11-12 17:34 rofl0r Note Added: 0013731
2010-11-12 17:55 rofl0r Note Added: 0013733
2010-11-12 18:37 rofl0r Note Added: 0013735
2010-11-12 18:46 Quietust Note Added: 0013736
2010-11-12 18:51 Quietust Note Edited: 0013736 View Revisions
2010-11-12 19:06 Logical2u Note Added: 0013737
2010-11-12 19:06 Logical2u Relationship added duplicate of 0001428
2010-11-12 19:06 Logical2u Status assigned => resolved
2010-11-12 19:06 Logical2u Resolution reopened => duplicate


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker