0003565: applying the raw changes for mayday's tileset results in butcherable Dwarfes after worldgen/embark

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