Hi, first up apologies if this is not the right place to log this, but I've found an issue with WillowTree v2.2.1.
At first I was getting "could not open save."- after googling a few solutions and ensuring WT wasn't in a path with "data" in it, and ensuring WT's data folder wasn't read-only, I decided to download the C# code and have a look.
Turns out the "Save Number" in my PC Borderlands save is 20483 (LittleEndian bytes: 3 80 0 0). The "NumericUpDown" control on WT's form is set to a max value of 9999 - clearly less than four bytes could potentially contain. I have no idea why my save number is so high - saves from some of my other chars are (usually) save number 1, even midway through playthrough #2.
Thought I'd bring this to the attention of anyone else suffering an unexplained "could not load save." error.
still new to SourceForge, grateful for any pointers on turning this into an official bug report / request.
Thanks,
Clumsy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting. I'd need a copy of the savegame to analyze the exact problem. Chances are the 3 80 0 0 is not actually the save number. There's could be some variable length data before it that WillowTree# is not properly analyzing or the savegame has experienced mass corruption like the start of the file being overwritten but the end not being written because the game was shut off abruptly in the middle. Broken savegames can be sent to me via email attachment at matt911@users.sf.net and I will perform a full analysis of them to hopefully fix any issues with opening them in an updated experimental revision (these are located in the "experimental" folder of the files area)..
About 3 times in the past the problem people sent me savegames that mass corruption and only on the Xbox. I've had reports that if the file is over 100k length on Xbox it can become corrupted. I have no idea if this is due to a limitation in Borderlands because the Xbox has strict memory management and only allocates 100k for the save file, due to an error in the third party x360.dll library that WT# uses to write Xbox packages, or due to an error in XTAF Explorer or Modio or other utility used to copy the Xbox files from the USB stick because enough people haven't followed up with me to give me info that I can use to narrow down the problem and I play on PC. I dont think a normal savegame would exceed 100k, but when people increase the number of inventory slots from 42 to 1000+ it happens. I have savegames on the PC that are over 1 MB in size with thousands of items that still work fine in game, but I have not tested the same thing on Xbox.
I haven't had any reports about that sort of corruption happening on the PC. Once there was a loading problem where the playthrough number was not 0 or 1 as WT# expects it to be, but instead it was 7F FF FF FF I think and otherwise the savegame was normal. I never got another report or example of that type of corruption though so I'm assuming it was caused by direct hex editing gone wrong since the character's money was the very next 4 bytes or previous 4 bytes in the savegame and it would make sense that someone might try to edit themselves in the maximum amount of money.
This is the first I've heard of an invalid save number. If the save number was legitimately 3 80 0 0 then the savegame should have been named SAVE8003.SAV. Probably WT# limits the save number to 9999 because the name of the savegame is SAVExxxx.SAV, so with four digits you can only go up to 9999. It turns out though that those digits in the filename are hexadecimal not decimal though so you could actually go up to SAVEFFFF.SAV possibly. The highest save number I ever tried to use was only around 0032 hex (50 decimal) though, so I don't know what the actual limitations of the game are.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I commented above about a file size issue someone had reported. I never really had a chance to test it before, but today I converted my most extreme savegame from PC to Xbox 360 and did a little bit of minor testing. It was over 1.1 MB in size. I killed some stuff and looted even more items in addition to the thousands of items already contained in the savegame then saved the game and copied the file back from the Xbox and loaded it in WT# and didn't notice any problems. If there is some kind of inherent size-related issue, I could not reproduce it using Modio 3.0 and WT# experimental revision 173.
This thread was not focused on the size issue and it was only mentioned in passing, but since I commented on it I thought I should pass along my own results that did not indicate a size problem on Xbox.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, first up apologies if this is not the right place to log this, but I've found an issue with WillowTree v2.2.1.
At first I was getting "could not open save."- after googling a few solutions and ensuring WT wasn't in a path with "data" in it, and ensuring WT's data folder wasn't read-only, I decided to download the C# code and have a look.
Turns out the "Save Number" in my PC Borderlands save is 20483 (LittleEndian bytes: 3 80 0 0). The "NumericUpDown" control on WT's form is set to a max value of 9999 - clearly less than four bytes could potentially contain. I have no idea why my save number is so high - saves from some of my other chars are (usually) save number 1, even midway through playthrough #2.
Thought I'd bring this to the attention of anyone else suffering an unexplained "could not load save." error.
still new to SourceForge, grateful for any pointers on turning this into an official bug report / request.
Thanks,
Clumsy.
Interesting. I'd need a copy of the savegame to analyze the exact problem. Chances are the 3 80 0 0 is not actually the save number. There's could be some variable length data before it that WillowTree# is not properly analyzing or the savegame has experienced mass corruption like the start of the file being overwritten but the end not being written because the game was shut off abruptly in the middle. Broken savegames can be sent to me via email attachment at matt911@users.sf.net and I will perform a full analysis of them to hopefully fix any issues with opening them in an updated experimental revision (these are located in the "experimental" folder of the files area)..
About 3 times in the past the problem people sent me savegames that mass corruption and only on the Xbox. I've had reports that if the file is over 100k length on Xbox it can become corrupted. I have no idea if this is due to a limitation in Borderlands because the Xbox has strict memory management and only allocates 100k for the save file, due to an error in the third party x360.dll library that WT# uses to write Xbox packages, or due to an error in XTAF Explorer or Modio or other utility used to copy the Xbox files from the USB stick because enough people haven't followed up with me to give me info that I can use to narrow down the problem and I play on PC. I dont think a normal savegame would exceed 100k, but when people increase the number of inventory slots from 42 to 1000+ it happens. I have savegames on the PC that are over 1 MB in size with thousands of items that still work fine in game, but I have not tested the same thing on Xbox.
I haven't had any reports about that sort of corruption happening on the PC. Once there was a loading problem where the playthrough number was not 0 or 1 as WT# expects it to be, but instead it was 7F FF FF FF I think and otherwise the savegame was normal. I never got another report or example of that type of corruption though so I'm assuming it was caused by direct hex editing gone wrong since the character's money was the very next 4 bytes or previous 4 bytes in the savegame and it would make sense that someone might try to edit themselves in the maximum amount of money.
This is the first I've heard of an invalid save number. If the save number was legitimately 3 80 0 0 then the savegame should have been named SAVE8003.SAV. Probably WT# limits the save number to 9999 because the name of the savegame is SAVExxxx.SAV, so with four digits you can only go up to 9999. It turns out though that those digits in the filename are hexadecimal not decimal though so you could actually go up to SAVEFFFF.SAV possibly. The highest save number I ever tried to use was only around 0032 hex (50 decimal) though, so I don't know what the actual limitations of the game are.
I commented above about a file size issue someone had reported. I never really had a chance to test it before, but today I converted my most extreme savegame from PC to Xbox 360 and did a little bit of minor testing. It was over 1.1 MB in size. I killed some stuff and looted even more items in addition to the thousands of items already contained in the savegame then saved the game and copied the file back from the Xbox and loaded it in WT# and didn't notice any problems. If there is some kind of inherent size-related issue, I could not reproduce it using Modio 3.0 and WT# experimental revision 173.
This thread was not focused on the size issue and it was only mentioned in passing, but since I commented on it I thought I should pass along my own results that did not indicate a size problem on Xbox.