Jump to content

Photo

Basic UPK Editing Trial - Hitting a Problem


  • Please log in to reply
15 replies to this topic

#11
raargharg

raargharg

    Newbie

  • Members
  • Pip
  • 11 posts

Thanks Ghost, getting closer and your resources / examples are helping a lot. 

 

Why isn't is possible to just use unreal script and recompile the upk rather than make hex changes? Is the tool not available to us? Specific to XCOM? UDK for Unreal 3 seems to be free, I'm just wondering if there's some trick they implemented so we can't mess with their script.

 

Edit: Nvm, guess they used a modified engine. There's gotta be a way to get them to release their tools. Somebody seduce them please.


Edited by raargharg, 29 November 2014 - 10:37 AM.


#12
jefeonwuka

jefeonwuka

    Newbie

  • Members
  • Pip
  • 14 posts
Then can you explain what this sequence of bytes is:
00 00 00 00 00 00 00 00 00 00 00 E8 00 00 00 98 
00 00 00 0F 35
It appears before what I am trying to input; the last 0F 35 is where my code would start. This is from the uninstall log.

The function being edited is XGHeadquartersUI.UpdateHeader in file XComStrategyGame.upk

Every code that I've seen which uses REPLACEMENT_CODE starts with the let and then the call. It doesn't start with the extra nulls or E8. If I'm supposed to include that, I would like to know what that is, especially since the other mod uninstall logs mark them as starting at REL_OFFSET=48, whereas my uninstall log marks REL_OFFSET=40. They also don't have that starting string of bytes.

I don't understand why there is this difference or what those extra bytes are. Simply explaining what REPLACEMENT_CODE is does not help in the slightest because that isn't the problem. If this code was standard I assume I would have seen it other places, which I haven't.

If adding the return code would solve this problem then that's fine but I don't think it will, I don't see why it'd add bytes at the beginning. Further, my code actually does have a return and EOS at the end. I don't know if you want me to add a second one.

The reason I am referring to the uninstall logs is because that is the only ready way I have to troubleshoot; checking the logs and seeing where the bytes match up to my code.

Edited by jefeonwuka, 29 November 2014 - 12:26 PM.


#13
wghost81

wghost81

    Faithful poster

  • Members
  • PipPipPipPip
  • 1,746 posts
jefeonwuka, uninstall file is not very informative, because it's more about patcher inner workings. I already said what tool you can use for troubleshooting: it's UE Explorer. The code in your example is wrong and it will be decompiled with lots of errors by UEE. This way you could see where the problem is.

UPK Utils "Miscellaneous" download section has file named UPK_Format_Document_pdf. It can help you with upk format understanding.

If you really wanna know about those extra zeros, they are inserted by internal ResizeAt function which resizes object at current relative offset, which for REPLACEMENT_CODE just happens to be 40. In this case it's a starting offset for virtual script size. And 48 is a script starting offset.

One quick note: you should never make any assumptions about data offsets in upk, because all upk objects are variable-size. So there are no such things like "header" or "footer".

Bytecode in your example is so mixed up, I couldn't see return and EOS tokens. Now I see they are indeed there, so the problem is with wrong parts of the code I've noted in my previous post.

You can't recompile decompiled scripts not just because XCOM engine is different, but simply because decompiled code is incorrect. It contains syntax errors, decompilation errors and, most importantly, it can't decompile default properties correctly. BTW, even UDK can't do this for whatever reason.

Edited by wghost81, 29 November 2014 - 02:52 PM.


#14
wghost81

wghost81

    Faithful poster

  • Members
  • PipPipPipPip
  • 1,746 posts

Here's an example on how to convert hex code to pseudo-code.

 

// m_kHeader.txtCash.strLabel = GetResourceLabel(0)

0F                                // token: operator = (let)

  35                              // token: struct member access

    EC F8 FF FF                   // import object reference

    9D F9 FF FF                   // import object reference

        00 00                         // unknown separator

    35                            // token: struct member access

      65 40 00 00                 // export object reference

      67 40 00 00                 // export object reference

      00 01                       // unknown separator

      01                          // token: class variable     

        6B 40 00 00               // export object reference

  1B                              // token: virtual function

    25 13 00 00 00 00 00 00       // name reference

    25                            // token: zero const

  16                              // token: end of function

//Now replacing all the references in hex with pseudo-code references:

0F

  35

    <XComGame.XGTacticalScreenMgr.TLabeledText.strLabel>

    <XComGame.XGTacticalScreenMgr.TLabeledText>

        00 00

    35

      <XGHeadquartersUI.THQHeader.txtCash>

      <XGHeadquartersUI.THQHeader>

      00 01

      01

        <@m_kHeader>

  1B

    <GetResourceLabel>

    25

  16

 

Use ExtractNameLists utility which is a part of UPKUtils package to extract name, import and export tables from the package. You can then use that list to quickly find the right reference:

0xFFFFF8EC (-1812) ( EC F8 FF FF ): StrProperty'XComGame.XGTacticalScreenMgr.TLabeledText.strLabel'

UE Explorer has a Disassembled Tokens view, which can help with understanding the parts of hex code and matching them with decompiled code:

(0-6;000/000) [0F 35 EC F8 FF FF 9D F9 FF FF 00 00 35 65 40 00 00 67 40 00 00 00 01 01 6B 40 00 00 1B 25 13 00 00 00 00 00 00 25 16]

    LetToken(59/39)

    m_kHeader.txtCash.strLabel = GetResourceLabel(0)



    (1-3;001/001) [35 EC F8 FF FF 9D F9 FF FF 00 00 35 65 40 00 00 67 40 00 00 00 01 01 6B 40 00 00]

        StructMemberToken(47/27)

        m_kHeader.txtCash.strLabel



        (2-3;014/00C) [35 65 40 00 00 67 40 00 00 00 01 01 6B 40 00 00]

            StructMemberToken(28/16)

            m_kHeader.txtCash



            (3-3;027/017) [01 6B 40 00 00]

                InstanceVariableToken(9/5)

                m_kHeader



    (4-6;030/01C) [1B 25 13 00 00 00 00 00 00 25 16]

        VirtualFunctionToken(11/11)

        GetResourceLabel(0)



        (5-5;039/025) [25]

            IntZeroToken(1/1)

            0



        (6-6;03A/026) [16]

            EndFunctionParmsToken(1/1)

            )
 


#15
jefeonwuka

jefeonwuka

    Newbie

  • Members
  • Pip
  • 14 posts
Thank you for responding. I'll find my own way.

#16
tracktwo

tracktwo

    Regular

  • Members
  • PipPip
  • 75 posts
Raargharg: there is a way to do a recompile using the udk in certain circumstances, but not for general hex modding. WGhost's mutator work basically lets you create brand new packages in uscript and link them to certain events in game. But the lack of official mod support means the available hooks is fairly small, and writing the scripts is still fairly tedious because you need to create stub packages for all the external references your script uses before the udk can compile it.

I did find using the udk a good resource when debugging complex logic. Writing the hex code for complicated functions by hand is pretty error prone, so I would write the code in uscript using dummy functions and variables and compile it, then copy out the hex code and replace the dummy table references with the real ones from the xcom upks.




Page loaded in: 1.402 seconds