XSHAPE

[Daemonjax]

XCOM SHA Patcher for Executable (XSHAPE) v0.13b

ERROR(5)
USAGE: java -jar XSHAPE.jar -<verbose> <starting byte>
More information: http://code.google.com/p/xshape

 

 

I know this error code can show up when the ".uncompressed_size" files haven't been removed. Are there other situations that could result in this error code?

 

 

Here's the source code up to error code 5...

 

       if (args.length == 0) return 1;        

       if (!configFile.canRead()) return 2;        

       if (configFile.length() == 0) return 3;

       scan = new Scanner(configFile);

       while (scan.hasNextLine())
       {                        
           String line = scan.nextLine().trim();            

           if (line.isEmpty()) 
           {
               scan.close();
               return 4;
           }

           if (!isCompressed(line)) ++count;            
       }

       scan.close();  
       
       if (count == 0) return 5;        

 

Now here's the isCompressed function:

 

final static String   CFOLDER    = "XComGame\\CookedPCConsole\\";    
final static String   COMPRESSED = ".uncompressed_size";

static boolean isCompressed(String s) 
{ 
   return new File(CFOLDER + s + COMPRESSED).exists(); 
}

 

Note: The !'s mean NOT

 

If I missed something, it's not on the if (!isCompressed(line)) ++count; line, since isCompressed(...) can only return true for one reason.

 

You have to look at that while loop and think of a reason it would exit before incrementing the local count variable, but also a reason that would not return exit codes 1 through 4.

 

I can't think of any reason other than the uncompressed.size files existing.

 

 

Basically, the line: while (scan.hasNextLine()) would have to return false for a reasons other than:

1) bad arguments sent to XSHAPE.jar

2) config file can't be read

3) config file is empty

4) config file contains lines of whitespace

 

 

The only thing that comes to mind is if you have a filename added to the config file (whatever.ext), and you have that same filename in your cooked folder with .uncompressed_size added on to it (whatever.ext.uncompressed_size).

 

 

Did you add any files to the config file?

 

 

Here's the full source code: http://code.google.com/p/xshape/source/browse/trunk/XShape.java

 

All sanity checks except for 16 are in: static int runSanityChecks(...)

Edited November 2, 2012 by Daemonjax

[BlackAlpha]

I see. The error was reported by another user. I'll chalk it up as user error and I'll tell him to triple check for the uncompressed_size file.

 

On an unrelated note, I think I might have found a minor bug. This is how to reproduce it:

 

Inside (game folder)\XComGame\CookedPCConsole\

 

1. I remove "XComGame.upk.uncompressed_size".

 

2. I "forget" to remove "XComStrategyGame.upk.uncompressed_size".

 

3. I add a modified/uncompressed "XComGame.upk".

 

4. I add a modified/uncompressed "XComStrategyGame.upk".

 

5. I run XSHAPE and it shows 1 hash has been updated and it doesn't show any sort of error message about "XComStrategyGame.upk".

 

The problem here is that I'm a tech savvy guy, so when I see only 1 hash has been changed, I know something is wrong. But "regular users" don't know that. I think XSHAPE should somehow detect this error and show an error message.

 

For example, the program could assume all files added to XSHAPE.config need to be checked and when there's something wrong with one, it could show an error. The downside would be that the mod maker needs to edit XSHAPE.config to include all files that he has modified. And of course, it's more work for you. Pros are that when users screw up, they get an error message and they know what's up or they can ask for help and give us the error message.

 

This is if you only use XSHAPE without the new mod manager. No idea if it's worthwhile adding an error for that in the new mod manager.

Edited November 2, 2012 by BlackAlpha

[Daemonjax]

I see what you're saying, but I intended it that way for ease of use.

 

The idea is that you don't need to muck around with the config file unless you're adding files to it.

 

If at least one file listed doesn't have their .uncompressed_size, then it will continue without errors. With the -v option, you can see what it's actually checking, so I don't see a problem.

 

 

Anyways, I think it's better than the alternative.

 

We can agree to disagree. ;)

[BlackAlpha]

I see what you're saying, but I intended it that way for ease of use.

 

The idea is that you don't need to muck around with the config file unless you're adding files to it.

 

If at least one file listed doesn't have their .uncompressed_size, then it will continue without errors. With the -v option, you can see what it's actually checking, so I don't see a problem.

 

 

Anyways, I think it's better than the alternative.

 

We can agree to disagree. ;)

 

In my example, the V option doesn't show it checked the strategy.upk. I'm guessing it just skipped it entirely. But it's no big deal, anyway.

[Daemonjax]

In my example, the V option doesn't show it checked the strategy.upk. I'm guessing it just skipped it entirely. But it's no big deal, anyway.

 

Exactly. It skipped it because the .uncompressed_file exists.

 

One thing I could do is:

 

IF (filename).uncompressed_file exists AND (filename) is uncompressed then
   yell_at_user()

 

I don't think there's a fringe case where that would be a bad thing.

 

At that point, I may as well have XSHAPE take care of the .uncompressed_file for you. ;)

 

Consider it done in .20beta (since that would be an added feature, not a bugfix).

Edited November 2, 2012 by Daemonjax

[BlackAlpha]

Cool! :)

[BlackAlpha]

Just want to mention that I just had my first user that made that mistake. So it's definitely a good feature for the next version! :biggrin: Edited November 3, 2012 by BlackAlpha

[Daemonjax]

Turns out the .tfc files have the same header as compressed upk files. Gildor says they're actually uncompressed, so (if true) this would be the fringe case for compressed upk detection (though I could just make an exception for that file extension). ;)

 

Nevermind, they are compressed.

Edited November 4, 2012 by Daemonjax

[Adonnay]

I have some issues with XShape as well. I've downloaded the nationality selector mod and the no disappearing corpses mod. I apply them and run XShape (which comes up with no errors and 1 SHA Hash updated just fine), but the game crashes when I start it. The mods are working for other people so I'm a bit lost here.

 

Things I've done so far:

- started completely from scratch (i.e. let Steam redownload all corru.. err modified files)

- decompressed XComGame.upk (and only XComGame.upk) and moved it to the CookedPCConsole folder

- only applied the no decaying corpses mod (i.e. did NOT apply my DefaultGameCore.mod file, nor any other mod)

- removed all upk files from the config file but XComGame.upk

- ran XShape and got a nice success message

- Game crashes immediately at startup

 

 

Edit: Oh my, after two days of testing I found it out myself just after posting here. The issue was that I left the unpacked xcomgame.upk in the "unpacked" folder that was created by the decompress tool. The game loaded the unmodified .upk but with the exe modified for the modified .upk. That caused the crash. I should read the messages more carefully. I thought the popup was telling me that the XComGame.upk was now internally named xcomgame.upk (small letters), but it actually told me that there were two xcomgame.upk files. *facepalm*

[babyjebu5]

For some reason, it (EDIT: patcher.bat) can't find "java", which its not in the folder where this is being run (EDIT: the base folder, not the deeper win32 one), but I suppose that java not being there shouldn't matter since it ought to be in the system paths, so long as I have Java 1.7+ installed. So what else does this error indicate besides "install Java" since I have the correct release:

 

"Windows cannot find 'java'. Make sure you typed the name correctly, and try again."

 

(EDIT: see follow-up post, verified paths are set in the environment variables, but it doesn't seem to register that I did so - as the error continues after many restarts and command prompts, both elevated and not. I am baffled.)

Edited November 8, 2012 by babyjebu5