Updating wiki articles

[dubiousintent]

Thanks, dubiousintent!

 

IMO, these sections are obsolete, as manipulating the object's buffer is no longer needed.

Manipulating hex code

...

Locating a hex value within a function

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.

 

Okay, I'll drop them then.

 

-Dubious-

[wghost81]

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. :)

Edited March 29, 2015 by wghost81

[patsch192]

Hi.

 

to wghost81 :

Reading the "Hex editing upk files". Clear as a blue summer sky, even for a noob in modding like me. Bravo ! To be continued... :wink:

When ended, will you join it to "UPKUtils" set of files ?

Edited March 29, 2015 by pat_sch

[wghost81]

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. :)

[dubiousintent]

Updated the "Hex editing UPK files" article with wghost81's latest posted on the 29th.

 

@wghost81: It would be a big help if you could indicate here what sub-sections of the existing article you believe should be dropped when you post an update. Though I do think we have pretty much trimmed those out by now.

 

-Dubious-

[wghost81]

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.

[patsch192]

Hi.

 

wghost81, your file accessed by the link above is named "Hex-editing-upk-files.odt" without "d"... (I know, it's nothing... :wink: )

 

Thanks for the lessons !

Edited March 31, 2015 by pat_sch

[wghost81]

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

[dubiousintent]

@wghost81: I finally got the existing "Hex values XCOM Modding" tables split out and reformatted. However, I haven't added anything new from the ODS spreadsheet because I'm having a bit of trouble interpreting your "NativeTable" worksheet for the article. You have added "index" followed by the "hex" value for the index columns after the "Name" field. But the various names for the values (other than the native functions 0x60-0x6F) suggest they do not have "indexes". Their index is the same as their "token" value.

 

This seems to not really be an issue (just ignore the "index" value, which is not in the article tables) until we get into the extended native functions (0x60-0x6F) themselves. Then I start to see "index" values above 255/0xFF, such the 0x61 extended native function token, with function token: 0x00 (Name: sleep) index 256/0x100 (Expression: Sleep(time)). Is the 0x100 a different extended function because it's of the 0x100-0xFFF pattern? Perhaps an example referring back to the UnrealScript hex data format pattern would make this clear?

 

-Dubious-

[wghost81]

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.