The next Step

[tbkiah]

Some information that might help people out, maybe not.. I asked on the UE Explorer site what the numbers in the brackets mean and he told me this:

 

The first parentheses mean the relative start position of the first token for example (0x000) means the token starts at the first byte of wherever the Tokens start(you can see this when you click "View Buffer" and look for the Red underlined byte.

The other parentheses after the tokens means the remaining size in bytes for example NativeParameterToken(9), meaning it consists of 9 bytes including all following tokens of that line.

 

This might be useful.. maybe not..

[Lethargus]

The 2 bytes following the 07 are the offset within the function to jump to.

 

It may or not be 2 bytes. It could be 1. But that's not what I was asking. ;)

 

I want to know HOW it works. I want to be able to look at 07 D4, and know EXACTLY where D4 is in the code. I know what it isn't:

 

1) It's not the number of bytes to jump

2) It's not the offset of bytes from the beginning of that script.

 

How exactly does it determine where to go based on that byte value? It's driving me mad.

 

 

What you said regarding using 06 to eat some bytes in multiples of 3 was interesting. Can you be so kind to show us a short example? :D

 

07 and 06 both seem to always be followed by two bytes. They also seem to be referencing different offset starting points. 07 and 06 are consistent within themselves for a given function. Is it a label? An offset? I don't really know. If we figure it out a jump would be 3 bytes, so just tell it to jump to the next instruction (ie, do nothing of value) and that takes up 3 bytes of space we wanted to get rid of. But I agree, figuring out how the offsets are calculated is something I don't full get. Hard to give an actual example without knowing how to calculate the offset value correctly.

 

EDIT: I've confirmed the 2 bytes refer not to a byte offset but perhaps an opcode offset. ie, number of commands. I was trying to get rid of a large portion of code and found just pasting the same jump in to the end of the if/else block seemed to change where the ending actually was. Plus, you can't jump over bad bytes to the good code you want. Trying that the game refuses to even start.

Edited October 26, 2012 by Lethargus

[trolcia]

If some of you guys aren't re-packing the .upks then what are you doing...?

 

Once I determine specifically what bytecode needs to edited, I copy the surrounding hex data into my clipboard. Then I close UE Explorer, and open the uncompressed upk that was previously opened in UE Explorer. Then, I paste the bytecode in my clipboard into the search feature of the hexeditor to find the code in the upk. I make the actual change there, and save the file. Done. All I need to actually do after that point is just run XSHAPE. But, it's nice to re-open the file in UE Explorer to see the change in the decompiled code first.

 

Basically, I don't change the unpacked files.

 

 

Also Ive been working with the .upks that deal with meshes and textures, and I know you guys are working mostly with game mechanics, maybe theres a difference in how they are set up and thats whats throwing me off?

 

I haven't looked at the meshes or textures. This is one game where I'm not particularly interested in changing those, but maybe someone else can help.

 

 

Daemonjax - sorry man but you cant explain simply thing how to to copy anything from UEE hex viewer to clipboard cant see any option .magic.

[Daemonjax]

Daemonjax - sorry man but you cant explain simply thing how to to copy anything from UEE hex viewer to clipboard cant see any option .magic.

 

I don't use the UEE hex viewer at all. ;) I use HxD.

[Wolfgeist451]

The 2 bytes following the 07 are the offset within the function to jump to.

 

 

About 07 as a jump to instruction

 

 

I've got a case where... well, see for yourself :

 

4a 16 07

 

where

07 being the jump function... 4a == 74 in decimal and 74 bytes later I got the 04 28 (return False) that I was expecting for the code :

 

 

function bool CanBeSold(int iItem)

{

local TItem kItem;

 

kItem = Item(iItem);

// End:0x8c Loop:False

if(kItem.iCategory == 1 || (kItem.iCategory == 2) || (kItem.iCategory == 3)) This "If" is the jump function I speak of

{

return false; This is the return false 74 bytes later in the bytecode.

}

// End:0xd4 Loop:False

if(iItem == 192 || (iItem == 135) || (iItem == 133) || (iItem == 134))

{

return false;

}

return m_arrItems[iItem].iCash != -1;

}

 

 

So, it seems to me like the length of the jump (jump to a destination inside the function), preceded the 07 instruction.

 

(apologies, I don't know how to paste stuff properly... :( )

Edited November 4, 2012 by Wolfgeist451

[Wolfgeist451]

[Looks to his feet in shame]

Forget the above post (tried to deleted it), I was wrong about 07 jump... happens there is another return false that just happens to be exactly 74 bytes later.

Edited November 4, 2012 by Wolfgeist451

[Daemonjax]

[Looks to his feet in shame]

Forget the above post (tried to deleted it), I was wrong about 07 jump... happens there is another return false that just happens to be exactly 74 bytes later.

 

Yeah, it's the byte after 07 that controls the jump ;)

[trolcia]

Daemonjax - sorry man but you cant explain simply thing how to to copy anything from UEE hex viewer to clipboard cant see any option .magic.

 

I don't use the UEE hex viewer at all. ;) I use HxD.

 

 

Its Ok I use Hex Workshop,IDA,HxD,010Editor etc....depends which I need but the main problem with UE hex view is you have to type everything in your editor which is not good would be easer just copy to clipboard and paste. thats is all about.

[zenija2007]

deleted

Edited November 28, 2021 by zenija2007