Quote:
Quote:
Originally posted by hrb2k
the higher the weight number, the file will be burned first. the lowest number will be burned last. so in most sorttxt files, the 1st_read.bin has a weight of " 1 ", which means it will it burned last on the disc since it has the lowest weight number.
|
Originally posted by Hacker999
I tried this and it worked. Except I did not use a dummy file since the game loads fast in the order that I put it in. You guys should try it.
And to think, all this time I was trying the complete opposite. 
|
This is how it's "supposed" to work. This is what I've been saying all along. However, it doesn't actually work properly like this. Hacker999, I'm sure it didn't just sort aphabetically, but I doubt it actually sorted it according to the sort.txt. Get a filelist of the new CD and make another sort.txt to see if it matches the one you used to make that CD. I almost garauntee that it's not the same.
Let me know what you find on that.
This brings me back to... is there way to make mkisofs sort files
accurately?
I use a sort.txt in my betas of Psilocybin Dreams 2.0. It works much better after being sorted, but it still doesn't sort accurately according to the sort.txt. For example: I have a trial version of MSR (speedster vs vx220) on that disc. I put my own music in there, but to keep the music from skipping, the *.afs file needs to be closer to the outside of the disc. I place it at a value of 1895 out of a total of 3824 files. It's after the midis, mpeg clips, and homebrew binaries, but before the rest of the DPWWW folder. The sound
DOES work properly because it
DOESN'T get placed too close to the center of the disc like it would if I didn't use a sort.txt, but it
DOESN'T place it where I actually dictated. This is just ONE example of how mkisofs doesn't sort accurately.
-Ex