Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[CatalystParadox]

As I said before, it's not like I'll be all that available for the next few days anyway.

[NCommander]

Hey, I haven't thought about Battlefailed in about a year so when I saw this as most recent post as annother cannon-fail-name
I figured it was time to update the old battlefailed OP to link to another offshoot. My eyes kind of glazed over near the end of Failcannon
and all I remember about Hellcannon is that they genned a new world and couldn't get either of the Battlefailed alchemy mods to work at first.
Since I'm not familiar with all of the new lore and legendary destruction, I'd just like to know in what way this is related to the other forts.
And maybe what stuff has happened while I wasn't paying attention.
Thanks.

We broke DF a few times in Hellcannon, and Horrorfailed hates Linux, apparently. We made some headcanon towards the end of the Hellcannon thread, but I'm not sure how much of that is going to make it into the story. If we can even have a story; the world seems very intent on fucking us over.

Ok, I'm a bit late to the party but ...

Its probably an issue with the remains of the graphics pack. The fort started with Phobius installed, and if it isn't fully removed it seems causes issues on DF/Linux (this caused me no end of grief with TAG's Spire of Armok (though that just caused DF to go haywire, it didn't bring my system crashing down).

Also, this fort has already descneded into madness faster than the last few. Add me to the turn list and to the dorfing list (profession: any engineering/red position if possible, else crossbow, else hammer :-)).

[ThatAussieGuy]

Yeah, I deeply apologise for the trouble having a graphics pack installed has caused.  _{I just liked it all looking pretty}

[NCommander]

Yeah, I deeply apologise for the trouble having a graphics pack installed has caused.  _{I just liked it all looking pretty}

I'm trying to sort the raws now. Can't figure out why it only craps out on Linux though (I'm not sure I have the most recent save, but it goes "Invalid Shape Definition", then DF aborts with all sorts of fun debugger crud).

EDIT: And fixed it. Playing through a month or two to make sure I actually fixed it for real. That was annoying. Its a bug in the Linux version of Dwarf Fortress caused by the additional raw files. WHoever added them didn't make them all lower-case. Not a problem for Win32/Mac which have case-insenstive filesystems. It blows the save straight to hell on Linux when run on a ext2 filesystem.

I don't think the Phobus pack was directly responsible (though I've had issues with it on Linux when not fully installed with the ASCII looking extremely 'odd').

SInce this is a real annoying fix and $#!@# annoying to do without being ON a Linux system, I'm willing to apply the changes to the save at the end of the current turn. Easiest thing to do is add me to the turn list immediately below Sinpwn with something like: NCommander - rawfix.). I'll download, fix the raws, resave (to make sure everything works properly), and upload without taking a turn.

[arclance]

I can confirm that that makes it work on Linux.
It is not a bug in the Linux version really, you could say it's a bug in ALL versions if it does not check if the raw file names match the ones in the save data.
You could also say it is a bug in the Windows version where is does not save the case sensitive raw names so it fails when the save is run from a case sensitive file system.
If the Windows version does save case sensitive raw names someone could have renamed the raw files after the world was generated and changed the case of a character in some of the raw file names which only causes problems when you run the save from a case sensitive file system.

[Mego]

I can confirm that that makes it work on Linux.
It is not a bug in the Linux version really, you could say it's a bug in ALL versions if it does not check if the raw file names match the ones in the save data.
You could also say it is a bug in the Windows version where is does not save the case sensitive raw names so it fails when the save is run from a case sensitive file system.
If the Windows version does save case sensitive raw names someone could have renamed the raw files after the world was generated and changed the case of a character in some of the raw file names which only causes problems when you run the save from a case sensitive file system.

They should be all lowercase, no? Regardless, lack of case-sensitivity isn't a bug in DF, it's an issue in Windows that Microsoft claims is better for users.

[Teneb]

NCommander, you can dl the save for fixing if needed be, I'll simply notify the next in line, Catalyst, when you're done.

Since Catalyst claims to be unavailable for the next few days, I'll wait and see if Sinpwn completes his turn. If by the time Catalyst is ready Sinpwn has yet to complete his turn I'll just skip him.

[arclance]

They should be all lowercase, no? Regardless, lack of case-sensitivity isn't a bug in DF, it's an issue in Windows that Microsoft claims is better for users.

I have never seen a rule anywhere that says all raw files should have all lower case names.
I think it is a "Cross Platform Compatibility Bug" since saves are supposed to be cross platform compatible.

Toady could add code to the Windows version to stop this from happening, he would just need to change the way the names of the raw files are added to the binary save data.
It is possible the Windows version has that code already and this is all just due to someone modding the raw files after the world was generated.
Only Toady could tell us which way the Windows version works though.

[Mego]

They should be all lowercase, no? Regardless, lack of case-sensitivity isn't a bug in DF, it's an issue in Windows that Microsoft claims is better for users.

I have never seen a rule anywhere that says all raw files should have all lower case names.
I think it is a "Cross Platform Compatibility Bug" since saves are supposed to be cross platform compatible.

Toady could add code to the Windows version to stop this from happening, he would just need to change the way the names of the raw files are added to the binary save data.
It is possible the Windows version has that code already and this is all just due to someone modding the raw files after the world was generated.
Only Toady could tell us which way the Windows version works though.

Well, the OS should handle finding the file referenced in the code, anyway. The C function that opens a file for reading takes the filename and the mode and sends that information to the OS, and then the OS finds the proper file and gives it to the program. Again, the fault would lie in the OS, not the program.

[arclance]

Well, the OS should handle finding the file referenced in the code, anyway. The C function that opens a file for reading takes the filename and the mode and sends that information to the OS, and then the OS finds the proper file and gives it to the program. Again, the fault would lie in the OS, not the program.

I would say that is true, except when writing cross platform programs because you have to make allowances for the differences between the operating systems.
Just because the OS works a stupid way does not mean you should not work around that stupidity if possible.

I am also not talking about opening the files I am talking about storing their filenames without stripping out the case of the characters that make up those names.
You don't need to open the raw files at all to get a list of their filenames.
Just because on Windows "adsfgh" is the same as "aDsfGH" does not mean that if the file is named "aDsfGH" you should log it's name as "adsfgh".
Since Windows is not case sensitive it does not matter if you store case sensitive filenames for other operating systems to use.

[Mego]

I would say that is true, except when writing cross platform programs because you have to make allowances for the differences between the operating systems.
Just because the OS works a stupid way does not mean you should not work around that stupidity if possible.

C does. The C standard library is cross-platform. The same library that provides fopen, the function that you use to open files.

I am also not talking about opening the files I am talking about storing their filenames without stripping out the case of the characters that make up those names.
You don't need to open the raw files at all to get a list of their filenames.
Just because on Windows "adsfgh" is the same as "aDsfGH" does not mean that if the file is named "aDsfGH" you should log it's name as "adsfgh".
Since Windows is not case sensitive it does not matter if you store case sensitive filenames for other operating systems to use.

Umm... What?

Most likely, Toady has an array of strings declared in the code that contains the different filenames for the raws. DF iterates through that array, opening each file when it needs it (or keeping them open and making a hashtable that lets it pull file objects by filename). Even if Windows doesn't care about case in filenames, programs do. Those strings within the program will remember their case. It's just that, when "foo.txt" is send to Windows to open, if it sees "FOO.TXT" instead, the OS says good enough and opens it.

So, either the issue is Windows not recognizing the filenames, or nothing to do with the filenames at all.

[arclance]

Basically what I mean is that if a raw file has the name "RawFile.txt" that name should be stored in your example array as "RawFile.txt" not "rawfile.txt" so the correct file name ends up in the save file.
I don't know that the code does not work like that now, only Toady could tell you that.
If the code already works like that in the Windows version this was likely caused by someone changing the filenames of the raw files after the world was generated.

[CatalystParadox]

NCommander, you can dl the save for fixing if needed be, I'll simply notify the next in line, Catalyst, when you're done.

Since Catalyst claims to be unavailable for the next few days, I'll wait and see if Sinpwn completes his turn. If by the time Catalyst is ready Sinpwn has yet to complete his turn I'll just skip him.

Not unavailable, exactly, but I'd get in one or two micro-updates, tops.  I vote ya give him til Friday.

[NCommander]

I'll wait until Friday to see if there's an update. If not, I'll grab the save, fix it, then upload it again, else use the save Sinpwn owns.

(I'll write an 'update' describing this event for Battlfailed lore. Something about a penguin god or something :-)).

[Teneb]

Derp, hit "lock thread" by accident. All is well. Thanks Spish.