wghost81

Why are you running install script from inside a game folder? You should unpack the distro to some other place, like your home dir, and run the install script from there. As for the line 230, it hasn't changed, so I don't know what's causing this error. BTW, I almost forgot it. If Anderkent hasn't changed this functionality, you should be able to specify your home dir and install dir as two parameters using command line: ./install-LW-OSX.sh /path/to/XEW/userfiles /path/to/XEW/install/dir

projectmercy, anything that changes jump offsets makes the mod incompatible with the other mods, which change the same function. If you want to make your mods compatible, plan your modifications so they fit the original memory size. Another trick is to use goto operator to jump out of the current part of the code into another one, execute a big chunk of the new code, and then jump back. If you place your new code in between return and EOS tokens, the rest of the function will look like it wasn't changed. We used this trick a lot with big functions and states with the lot of jumps. Example: if (something) { do something; } else { do something else; } This can be changed into: if (something) { goto new code; filler code to fit memory and size; "jump back here" } else { do something else; } ... return something; new code with lots of things; goto "jump back here"; EOSI certainly can include links and\or copies of wiki articles into UPKUtils. The thing is, it's not UPKUtils specific, but rather general information on handling bytecode. People were modding XCOM long before PatcherGUI, myself included. :smile: Those articles were created by the others and helped me a lot. And now I'm trying to give back to the community by updating them.

You can use regular forum view: http://forums.nexusmods.com/index.php?/forum/665-xcom-file-discussions/ The thing is, there's not that many players here, as this forums is intended for technical discussions. So it's unlikely that new LW players will see this warning. :)

dubiousintent, good, thanks. Might be better to move it to "Changing a big part of the script" section, though, after it's finished.

SmileTactician, it is possible then that you have different directory structure. As far as I remember, Anderkent had to change directories part of the original Linux script because of the differences in directory structure under Mac. You can open sh file with a notepad equivalent, look at the directories and compare them with your system. I don't have access to Mac, so I can't be more specific, sorry.

Thanks, dubiousintent, it looks great. I made minor changes to Extended Native tables: IMO, "61 < Extended Native Function token>" is confusing, as one might interpret it as 61 followed by 60 token. Upd: just noticed that || symbols have disappeared from the Expression column of the table for OrOr_BoolBool token. It probably has something to do with || being used by wiki as column separator.

http://forums.nexusmods.com/index.php?/topic/2407274-beta14-on-mac/?p=21457719

".pgui" extension is used for batch files. BEFORE/AFTER hex will not update jump offsets for you. And jump labels only work with REPLACEMENT_CODE. You can use HexToPseudoCode decompiler to obtain ready-to-modify code with all the jumps replaced with labels. In this case if you insert a new code inside some jump operator, Patcher will re-calculate and update all the jumps.

Critical update in v.7.2 (UPKUtils package): - fixed bug with some reference labels not generated properly by HexToPseudoCode. - added infinite loop detection in PatchUPK. Those aren't relevant for PatcherGUI users.

Thanks, dubiousintent! Here are the last corrections for the article, other than that it looks perfect. UnrealScript Code Table IMO, this text should be removed as it duplicates the information given above: Package.Class column of the table here should also be removed as it is empty. Also, for the sake of consistency, FToken header should be added above Dec and Hex columns. UnrealScript Code Table - Extended Native Functions Same as above section, I think this text should be removed entirely: And FToken header should be added above Dec and Hex columns. UnrealScript Code Table (continued) Same as above tables: FToken header should be added above Dec and Hex columns. Extended Native Function 0x61 Table It's note quite right. 2 byte NativeTableIndex (i.e. NTIndex) = 0x01 <FunctionToken 'x'> (i.e. 0x0100-0x01FF). And 2 byte Bytecode Value = <ExtendedNativeToken '0x61'> <FunctionToken 'x'> (i.e. 0x6100-0x61FF). Extended Native Function 0x62 through 0x6F Tables Same as above, but 0x02 and 0x62 (0x03 and 0x63, etc.). PrimitiveCast Tokens 0x38 Table This text should be deleted: Cast tokens are using one native cast function (token 38) and CastToken itself is a "parameter" for this function. Same way, FToken and NTIndex headers should be removed for this table.

Yes, but with no "or". If NativeTableIndex of the function is >255 this means that the function is an Extended Native Function and requires two tokens. No, this one is one byte of function token (38) + cast token. I think usage examples can explain this better. Like this: Cast tokens are used for primitive cast operations, i.e. if you need to convert int to float, for example, you need to use cast token. Cast tokens are prepended by primitive cast token 38. Example (int to float): 38 3F <IntVariable>I also think that repeating information about native table index at the beginning of each section should be replaced with usage examples. Like this: UnrealScript Code Table: values from this table are used directly, no additional prepending token is needed. Example (LocalVariable): 00 <LocalVariableReference>UnrealScript Code Table - Extended Native Functions: values from this table are never used directly, they are used as prepending tokens for calling extended native functions with indexes > 255. UnrealScript Code Table (continued): values from this table are used directly, no additional prepending token is needed. Function call follows this pattern: <Token> <Params> <EndFunctionParms>Example (GotoState): 71 <StateName> 16Extended Native Function 0x61 Table: values from this table require prepending 61 token before function token. Function call follows this pattern: <NativeFunction1> <Token> <Params> <EndFunctionParms>Example (Sleep): 61 00 <SleepTime> 16Extended Native Function 0x62 Table: values from this table require prepending 62 token before function token. Function call follows this pattern: <NativeFunction2> <Token> <Params> <EndFunctionParms>Example (CanSee): 62 15 <Pawn> 16 Extended Native Function 0x65 Table: values from this table require prepending 65 token before function token. Function call follows this pattern: <NativeFunction5> <Token> <Params> <EndFunctionParms> Example (IsZero): 65 DD <Vector> 16 Extended Native Function 0x69 Table: values from this table require prepending 69 token before function token. Function call follows this pattern: <NativeFunction9> <Token> <Params> <EndFunctionParms> Example (V2DSize): 69 DD <V2DSize> 16 Extended Native Function 0x6A Table: values from this table require prepending 6A token before function token. Function call follows this pattern: <NativeFunctionA> <Token> <Params> <EndFunctionParms> Example (Multiply_Vector2DVector2D): 6A 24 <Vector2D_A><Vector2D_B> 16 Extended Native Function 0x6F Table: values from this table require prepending 6F token before function token. Function call follows this pattern: <NativeFunctionF> <Token> <Params> <EndFunctionParms> Example (SetPhysics): 6F 82 <Physics> 16

UhuruNUru, thanks, I'll check it with b15 to see if something was changed.

dubiousintent, thanks! I haven't added native table indexes to the original wiki table because I was trying to save some space. I'll try to explain how those indexes work. Actual size of the Native Table is 0x1000=4096 possible native functions. NativeTableIndex is the value in parentheses in unrealscript code. Example: // Export UObject::execNot_PreBool(FFrame&, void* const) native(242) static final operator(24) bool ==(bool A, bool B);By looking at this definition we can see that boolean equal-equal comparison operator is a native function with NativeTableIndex=242. Here is another example: // Export UObject::execMultiply_FloatVector2D(FFrame&, void* const) native(2513) static final operator(16) Vector2D *(float A, Vector2D B); This definition means that Vector2D multiply operator has NativeTableIndex=2513. In ods table NativeTableIndex is given in column D in dec and in column E in hex representation. So, every native function has its own unique index in between 0x000 and 0xFFF. Now let's look at how those indexes are represented in bytecode. Each "expression" in bytecode starts with token (or two tokens), which represent corresponding native function call: <ExtendedNativeToken> <FunctionToken>. If NativeTableIndex<256 (indexes from 0x000 to 0x0FF) then FunctionToken=NativeTableIndex and ExtendedNativeToken is entirely omitted. So, boolean equal-equal comparison operator with NativeTableIndex=242 is represented by one byte F2 in bytecode. If NativeTableIndex>=256 (indexes from 0x100 to 0xFFF) then both ExtendedNativeToken and FunctionToken present in the bytecode: <ExtendedNativeToken> = 0x60 + (0xF00 & NativeTableIndex) >> 2 <FunctionToken> = 0x0FF & NativeTableIndex So, Vector2D multiply operator with NativeTableIndex=2513 is represented by two bytes in bytecode: 69 D1. I.e. for indexes 256 (0x100) through 4095 (0xFFF) first byte is equal to one of the NativeFunctionX tokens (0x61-0x6F) and second byte is equal to rightmost byte of NativeTableIndex for this function. They could just use 2 bytes for each token, but this wouldn't be as effective as it is now, because in average each script would be twice as long.

pat_sch, thanks, I'll rename it next time. :)

dubiousintent, thanks! Perfect as always. It looks good for me now. I will indicate if some of the sections become obsolete with each update. Right now it's better to keep them where they are as it might take me some time to update the function re-scripting part. Thanks again for all your hard work on wiki articles, dubiousintent! It's much appreciated.

Long War forums. Bug reports, feedback, customizations and strategy. :)

Yes, you're right. But pure locale independent ASCII is 7-bit 128 characters set. I specifically restricted all the mod files to use locale independent ASCII symbols only, as those are the same in all code tables. I can remove this check, but it will potentially lead to people using unicode and/or locale-specific characters in text strings and this can cause the game to CTD, as unicode strings are handled differently in UE and XCOM is not using unicode in upk files. Using m_strCreditsPrefix is better anyway, as it was already defined as localized string. You can find usage examples by using "Search in classes" UEE feature: class'XGScreenMgr'.default.m_strCreditsPrefix $ strAmount

I've created a shared folder where I will be uploading all the updated files into: https://drive.google.com/open?id=0B5MAcyqYBx4dflgtNVRFYkVsMGRETW84TFozblRUODVxSzFPXzczSVVWc1VwWWJ4dk9SNUE&authuser=0 2pat_sch, dubiousintent is updating wiki article with new tutorials. He's doing a great job with editing, so the resulting document will be a way better than the original one. :)

I have finished "Changing a small part of the script" section. Note that this part references "Managing the skip tokens" part, which is still work in progress. Update: "Managing the skip tokens" part is ready. Since the size of the document is starting to drive GoogleDocs crazy, I will continue to work off-line. :)

SpazmoJones, unicode symbols are prohibited for I'm really bad with parsing user input. :) Only ASCII symbols are allowed. Use m_strCreditsPrefix variable instead. It's defined in XComStrategyGame.int and holds "spacebucks" symbol alone.

Thanks, dubiousintent! IMO, these sections are obsolete, as manipulating the object's buffer is no longer needed. Original article was created when UEE didn't have decompiled/disassembled tokens view, so modders had to practically repeat all the decompilation steps manually to locate a hex value inside the buffer. Although it's a good historical reference, leaving it as it is along with decompiled/disassembled tokens functionality mixes things up and potentially confuses readers.

dubiousintent, thanks!

Long War forum tree.

Long War is the mod (The Mod!), but not every mod is Long War. :wink: What I mean, if you want to leave some LW related comment, please, use LW forum tree. Or at least state specifically that you're talking about Long War. :wink:

Here's my first attempt on updating hex editing article: https://docs.google.com/document/d/1nCVBdUvEof8m4pjvFq2R9W5bDikwgay0ogy6OQiU0pY/edit?usp=sharing