The next Step

[tbkiah]

I know they are not being used... but my question is what is telling the game to +20 defense when you are in low cover.. and what is telling the game to give +40 defence when in high cover?

 

Nevermind... stupid microsoft default crap

Edited October 24, 2012 by tbkiah

[Lethargus]

I know they are not being used... but my question is what is telling the game to +20 defense when you are in low cover.. and what is telling the game to give +40 defence when in high cover?

 

Nevermind... stupid microsoft default crap

 

XGUnit::SetCoverValue and UpdateCoverBonuses are native functions. I'm not seeing anything else. Lots of functions for determining the best cover and direction of facing related to cover... Nothing else regarding what it actually does. Even the XGTacticalGameCore::CalcHitChance function and CalcOverallDamage function don't seem to reference cover in any way. No idea where it's at.

Edited October 24, 2012 by Lethargus

[bokauk]

Nice work on the template, Lethargus.

 

I had considered exploring the .upk file format but heard it was an extremely complicated format and so way beyond my very limited knowledge. It looks like you've made some progress though and I admire your efforts!

 

I bookmarked some info about the file format in case I did ever have a look into it, but you might find these links useful if you haven't seen them already:

 

http://www.gildor.org/smf/index.php/topic,882.0.html

http://www.gildor.org/smf/index.php/topic,297.msg2859.html

http://eliotvu.com/unreal-package-file-format.html

 

Good luck and keep up the good work :)

[Daemonjax]

Does anyone know or care to try and figure out how the byte directly after the 0x07 bytecode actually works?

 

Changing it does affect where the code jumps to if the conditional is false, however I can't seem to work out precisely how it works.

 

Furthermore, there doesn't seem to be a way to simply "null out" bytecode. i.e. removing code without the use of jumps, while maintaining the function length. Anyone solve this? I tried and tried...

 

Let's leave changing the script length for another day. The above are important to know how to do in some fashion.

 

I'll try and find the time today to locate simple scripts to use as examples.

Edited October 24, 2012 by Daemonjax

[Lethargus]

Does anyone know or care to try and figure out how the byte directly after the 0x07 bytecode actually works?

 

Changing it does affect where the code jumps to if the conditional is false, however I can't seem to work out precisely how it works.

 

Furthermore, there doesn't seem to be a way to simply "null out" bytecode. i.e. removing code without the use of jumps, while maintaining the function length. Anyone solve this? I tried and tried...

 

Let's leave changing the script length for another day. The above are important to know how to do in some fashion.

 

I'll try and find the time today to locate simple scripts to use as examples.

 

The 2 bytes following the 07 are the offset within the function to jump to. If you use my template one of the unknown variables is labeled RelativeZeroAddressUnknown8. The start of that variable seems to be the 0 address. It's part of the 8 bytes before what appears to be the start of the code itself, and I have no idea what those 8 bytes do. You can "NOP" out in multiples of 3 by just using jump instructions (06) to the next instruction. Not sure what would happen if you tried to jump over trash bytes... It probably wouldn't go so well. But I have not found a single byte "do nothing" code.

 

I'm really hoping someone knows how to interpret the structure code 35. I have a placeholder in my template that sort of works, but doesn't properly handle the negative identifiers or the last 2 bytes (it seems to be an 11 byte opcode?) which limits changing the more complex variables.

Edited October 24, 2012 by Lethargus

[Daemonjax]

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

Edited October 25, 2012 by Daemonjax

[tbkiah]

The only thing i noticed was that if i opened a function within UE Explorer and looked at the tokens, the 0x0XX number on the left corresponded with the 0?XX of the jump.

 

I know as i increased the XX it slowly added the Loop:False text further and further down in the function.

 

It just so happened that the function i looked at the first number on the left was 0x00B and the jump was 060B(00?)

 

I also noticed that if you put something really high the type of jumped changed. I'll show an example of what it looks like.

 

This was the Orignal Function:

 

function int PerkStampFind(XGUnit kUnit, array<PerkStamp> stamps)
{
local int I;

I = 0;
J0x0b:

// End:0x6f Loop:True
if(I < stamps.Length)
{
	// End:0x61 Loop:False
	if(kUnit == stamps[i].m_kUnit)
	{
		return I;
	}
	++ I;
	// This is an implied JumpToken; Continue!
	goto J0x0b;
}
return -1;
}

 

This was the function after i changed the 060B to 07FF

 

 

function int PerkStampFind(XGUnit kUnit, array<PerkStamp> stamps)
{
local int I;

I = 0;
// End:0x6f Loop:False
if(I < stamps.Length)
{
	// End:0x61 Loop:False
	if(kUnit == stamps[i].m_kUnit)
	{
		return I;
	}
	++ I;
	// End:0xff Loop:False
	if(return -1)
	{
	}
}
}

 

 

This is after i changed 060B to 0645

 

function int PerkStampFind(XGUnit kUnit, array<PerkStamp> stamps)
{
local int I;

I = 0;
// End:0x6f Loop:False
if(I < stamps.Length)
{
	// End:0x61 Loop:False
	if(kUnit == stamps[i].m_kUnit)
	{
		J0x45:

		return I;
	}
	++ I;
	// This is an implied JumpToken; Continue!
	goto J0x45;
}
return -1;
}

 

And this is the "View Tokens" in UE Explorer

 

(0x000) LetToken(11) -> LocalVariableToken(9) -> IntZeroToken(1)
I = 0
(0x00B) JumpIfNotToken(24) -> NativeFunctionToken(21) -> LocalVariableToken(9) -> DynamicArrayLengthToken(10) -> LocalVariableToken(9) -> EndFunctionParmsToken(1)
if(I < stamps.Length)
(0x023) JumpIfNotToken(52) -> NativeFunctionToken(49) -> LocalVariableToken(9) -> StructMemberToken(38) -> DynamicArrayElementToken(19) -> LocalVariableToken(9) -> LocalVariableToken(9) -> EndFunctionParmsToken(1)
if(kUnit == stamps[i].m_kUnit)
(0x057) ReturnToken(10) -> LocalVariableToken(9)
return I
(0x061) NativeFunctionToken(11) -> LocalVariableToken(9) -> EndFunctionParmsToken(1)
++ I
(0x06C) JumpToken(3)
goto J0x45
(0x06F) ReturnToken(6) -> IntConstToken(5)
return -1
(0x075) ReturnToken(10) -> ReturnNothingToken(9)
return ReturnValue
(0x07F) EndOfScr

 

 

EDIT: I didn't think it adds up... but in the View Token Side, it doesn't actually shot the J0x45.. it's actually up a little further.. closer to what would be 0x045

Edited October 25, 2012 by tbkiah

[tbkiah]

I can't believe they used intone and intzero for values like the number of rockets and such... yea maybe for return true and false and such, but really a token that only allows for 2 possible values?

 

I guess it might be alright once we finally are able to manipulate the bitcode a bit better.

[bokauk]

I can't believe they used intone and intzero for values like the number of rockets and such... yea maybe for return true and false and such, but really a token that only allows for 2 possible values?

They didn't, it's just how the code gets compiled and converted into bytecode.

Edited October 25, 2012 by bokauk

[tbkiah]

So why are some 1s IntOne and some are byteconst 01?