View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007852 | Dwarf Fortress | Dwarf Mode -- Diplomacy | public | 2014-08-05 06:27 | 2014-09-09 09:29 |
| Reporter | Quietust | Assigned To | Toady One | ||
| Priority | normal | Severity | minor | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Product Version | 0.40.06 | ||||
| Fixed in Version | 0.40.12 | ||||
| Summary | 0007852: Dipscripts loaded in inconsistent order between platforms, results in meeting glitches | ||||
| Description | The various diplomat scripts (in data/dipscript) are loaded in an inconsistent order between platforms. As a result, if a game is saved during a meeting on one platform and then restored on another platform, it can result in the wrong meeting script being processed - for example, a comment on 0003295 mentioned that the Dwarven Liaison occasionally used the Elven Diplomat greeting and farewell texts. This is most notable when running the Windows version of Dwarf Fortress on Linux using Wine, and I've personally observed this behavior as far back as version 0.23. | ||||
| Additional Information | Dipscript orders in various environments: OSX, native: DWARF_LIAISON, ELVES_FIRSTCONTACT, ELVES_STANDARD, HUMAN_STANDARD, HUMAN_TRADE Linux, native: DWARF_LIAISON, ELVES_FIRSTCONTACT, ELVES_STANDARD, HUMAN_STANDARD, HUMAN_TRADE Win32, native: DWARF_LIAISON, ELVES_FIRSTCONTACT, ELVES_STANDARD, HUMAN_STANDARD, HUMAN_TRADE Win32, Wine: DWARF_LIAISON, ELVES_FIRSTCONTACT, HUMAN_STANDARD, HUMAN_TRADE, ELVES_STANDARD In my initial test, the Win32 version running in Wine was the only one that loaded the dipscripts in the wrong order - my guess is that it's a difference in filesystem enumeration order (which Wine possibly does differently). | ||||
| Tags | No tags attached. | ||||
|
|
So Wine doesn't load them in alphabetical order? Is that a bug with their implementation of whatever MSVC is producing with FindNextFile()? I have no idea how the emulator works or to what extent I should be patching to avoid the bugs in an emulator. Or is this a bug on my end? I can re-alphabetize the dipscripts by token after they are loaded, but I'm not sure if this is just the tip of an iceberg. |
|
|
The documentation for FindFirstFile and FindNextFile on MSDN state the following: FindFirstFile: "The FindFirstFile function opens a search handle and returns information about the first file that the file system finds with a name that matches the specified pattern. This may or may not be the first file or directory that appears in a directory-listing application (such as the dir command) when given the same file name string pattern. This is because FindFirstFile does no sorting of the search results. For additional information, see FindNextFile." FindNextFile: "The order in which the search returns the files, such as alphabetical order, is not guaranteed, and is dependent on the file system. If the data must be sorted, the application must do the ordering after obtaining all the results." I just did a test on a FAT16 volume (a USB flash drive) where I extracted the archive in reverse alphabetical order, and the dipscripts got loaded in the order HUMAN_TRADE, HUMAN_STANDARD, ELVES_STANDARD, ELVES_FIRSTCONTACT, DWARF_LIAISON, which would suggest that it's getting them in the order in which they exist on the filesystem. Doing the same test on an NTFS volume seemed to have no effect - presumably, NTFS always keeps its directory contents sorted alphabetically for quicker access times (e.g. so it can locate files by filenames using a binary search rather than a linear search). Under Wine, that API call is probably returning files in INODE order, which may not be alphabetical. For Linux and OSX, it looks like you're using glob() (in g_src/find_files_posix.cpp), and that automatically sorts results if you don't specify GLOB_NOSORT. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-08-05 06:27 | Quietust | New Issue | |
| 2014-08-26 05:47 | lethosor | Assigned To | => lethosor |
| 2014-08-26 05:47 | lethosor | Status | new => confirmed |
| 2014-08-26 05:48 | lethosor | Additional Information Updated | |
| 2014-08-26 09:56 | Toady One | Note Added: 0029660 | |
| 2014-08-26 09:56 | Toady One | Assigned To | lethosor => Toady One |
| 2014-08-26 09:56 | Toady One | Status | confirmed => feedback |
| 2014-08-26 20:02 | Quietust | Note Added: 0029706 | |
| 2014-08-26 20:02 | Quietust | Status | feedback => assigned |
| 2014-08-26 20:04 | Quietust | Note Edited: 0029706 | |
| 2014-08-26 20:08 | Quietust | Note Edited: 0029706 | |
| 2014-08-26 20:09 | Quietust | Note Edited: 0029706 | |
| 2014-08-27 05:25 | Quietust | Note Edited: 0029706 | |
| 2014-09-05 12:26 | Toady One | Status | assigned => confirmed |
| 2014-09-09 09:29 | Toady One | Status | confirmed => resolved |
| 2014-09-09 09:29 | Toady One | Fixed in Version | => Next Version |
| 2014-09-09 09:29 | Toady One | Resolution | open => fixed |
