View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003565 | Dwarf Fortress | Dwarf Mode -- Embark/Setup | public | 2010-11-12 15:51 | 2010-11-12 19:06 |
| Reporter | rofl0r | Assigned To | Logical2u | ||
| Priority | immediate | Severity | block | Reproducibility | always |
| Status | resolved | Resolution | duplicate | ||
| OS | linux | ||||
| Product Version | 0.31.17 | ||||
| Summary | 0003565: 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 Reproduce | apply the diff from https://github.com/rofl0r/df-mayday on the linux version, gen a small world and embark. | ||||
| Additional Information | i 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. | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
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)? |
|
|
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. |
|
|
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. |
|
|
btw, the crash is not on reclaim, but on abandon |
|
|
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. |
|
|
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. |
|
|
update: when the world is generated on "vanilla", and the patch later applied (and raws transferred to region1), everything is ok. |
|
|
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 |
|
|
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. |
|
|
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. |
| 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 => 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 | feedback => assigned |
| 2010-11-12 17:26 | rofl0r | Note Edited: 0013728 | |
| 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 | |
| 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 |
