The flamer's "Torch" and other "new" abilities

shadowtiger · October 31, 2012

OK, so thanks to sir EliotVU I did make some advances.
Until I didn't. I must be really bad at this :confused:

So the ellusive defaultproperties{} was in the separate file called default_XcomDamageType_yadahyadah.
The bytecode to it is super short and short be easy pie, right ?
So I was hoping to find a 27 which is "false" in a .function. There's none, meaning that the bytecode is different for these files which does not help, but hey there are so few things in there I'm bound to get to it at some point.

So I change a few values around and understand the following :

plaintext content
	①bDamageUnits=②false
③DamagedFFWaveform=④ForceFeedbackWaveform0
KilledFFWaveform=ForceFeedbackWaveform1
hex content
61 4A 00 00 ①F3 07 00 00 00 00 00 00 ②61 0B 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ③1D 14 00
00 00 00 00 00 BE 55 00 00 00 00 00 00 04 00 00
00 00 00 00 00 84 BE 00 00 03 41 00 00 00 00 00
00 BE 55 00 00 00 00 00 00 04 00 00 00 00 00 00
00 85 BE 00 00 32 55 00 00 00 00 00 00

If I modify bytecode marked 1 the variable 1 is changed, same for 3, so 61 0B must be "false". Indeed if I edit eitheir of these bytes (randomly) false changes into something else, usually a 0 or 1 (I think I got a 2 once). If I change the first 2 bytes 61 4A I see no effect, so yeah, this must be it.
Great, so now I just need to find the correct hex value for "true" and we're in business !

So I look around for a defaultproperty with "true" in it ; here is Default_particulesizebydistance_somethingsomething
defaultproperties
{
MaxDistance=40.00
bUpdateModule=true
bSupported3DDrawMode=true
}
2 instances of true in there, should be fairly easy to point out

40 02 00 00 9C 52 00 00 00 00 00 00 1D 2E 00 00
00 00 00 00 04 00 00 00 00 00 00 00 00 00 20 42
D1 0D 00 00 00 00 00 00 61 0B 00 00 00 00 00 00
00 00 00 00 00 00 00 00 01 2A 0C 00 00 00 00 00
00 61 0B 00 00 00 00 00 00 00 00 00 00 00 00 00
00 01 32 55 00 00 00 00 00 00

Oh look two 61 0B s, that sure looks like my "true"s
Wait what, 61 0B was the code for "false" ! But... But...
Again, what is this sorcery !?

:wallbash:

I don't have much experience hex editing and it seems more complex doing it through the UDK system.

However some basic computer science helps. A true should be stored as a 01 and a false should be stored as a 00.

An A is a 10 and a B is an 11... so technically those could be used to store booleans if you only looked at the last digit but that is kind of weird and unlikely. So maybe you could look at where the 01s appear in the second one and change those to 00 and see if they become false.

I really don't understand how the bytes are laid out, but remember that a integer is 4 bytes, or 4 hex digits. So technically everything should be split into 4s, though the number of zeros between important numbers can be varied.

Since you are editing variables, they may be longer than 4 bytes. Without more examples I can't really find a pattern as to what represents what.

PepprmintButler · October 31, 2012

Whaddaya know, basic computer science does help !

I knew I was missing something :tongue:

Thanks for the help.

So yeah, simple as that, the two 01s in the second are the trues, 00 makes them falses.

I guess 61 0B was more like an operator then ? Or prefix or something. I still don't got no computer skills to go with.

Anyway I know I need to change a 00 into a 01 in the first file and I have a general feeling of where to look, so maybe I'll get somewhere this time.

PepprmintButler · October 31, 2012

Yup, Torch does make damage now ! :dance: weee

Problem is, it does a bit too much of it. Or more precisely it does no particular amount of damage, it just kills. There is no damage indicator, just a dying enemy. I guess the damage amount is not defined anywhere so this is what it comes down to by default.

Also, since it is using the Shot animation & action, it actually only kills when a hit is rolled. Free aim does not give chance to hit % so difficult to say if it is actually the standard shot % but that seems likely. Also, Free aiming does in some instances result in the soldier firing somewhere silly (like the cover he is standing behind...). It looks like a LoS problem.

On the "fire burns" front, it looks like the modifications I did to CausesSurroundingAreaDamage actually works. I had one of my guys, who was standing in fire in titan armor, go from 20-something HP to dead at an end of turn without anyone shooting at him. Again the damage amount not being defined anywhere seems to be the problem. Also the fact that he died from fire while wearing titan armor is kind of stupid (the armors ! They do nothing !)

Anyway still ways to go but this is finally going somewhere. Thanks a bunch to y'all for the big help, feel free to continue to deliver :)

Edited October 31, 2012 by PepprmintButler

BanjoOz · October 31, 2012

Yup, Torch does make damage now ! :dance: weee

Problem is, it does a bit too much of it. Or more precisely it does no particular amount of damage, it just kills. There is no damage indicator, just a dying enemy. I guess the damage amount is not defined anywhere so this is what it comes down to by default.
Also, since it is using the Shot animation & action, it actually only kills when a hit is rolled. Free aim does not give chance to hit % so difficult to say if it is actually the standard shot % but that seems likely. Also, Free aiming does in some instances result in the soldier firing somewhere silly (like the cover he is standing behind...). It looks like a LoS problem.

On the "fire burns" front, it looks like the modifications I did to CausesSurroundingAreaDamage actually works. I had one of my guys, who was standing in fire in titan armor, go from 20-something HP to dead at an end of turn without anyone shooting at him. Again the damage amount not being defined anywhere seems to be the problem. Also the fact that he died from fire while wearing titan armor is kind of stupid (!the armors ! They do nothing !)

Anyway still ways to go but this is finally going somewhere. Thanks a bunch to y'all for the big help, feel free to continue to deliver :)

I've been too busy to help more recently, but wanted to give you a hearty pat on the back for some awesome work with this... sounds like you're getting there at least (and I know how frustrating it is to be "almost there" but not quite.

Also, I laughed at the Titan armor guy getting burned to death in one turn. :)

EliotVU · October 31, 2012

OK, so thanks to sir EliotVU I did make some advances.
Until I didn't. I must be really bad at this :confused:

So the ellusive defaultproperties{} was in the separate file called default_XcomDamageType_yadahyadah.
The bytecode to it is super short and short be easy pie, right ?
So I was hoping to find a 27 which is "false" in a .function. There's none, meaning that the bytecode is different for these files which does not help, but hey there are so few things in there I'm bound to get to it at some point.

So I change a few values around and understand the following :

plaintext content
	①bDamageUnits=②false
③DamagedFFWaveform=④ForceFeedbackWaveform0
KilledFFWaveform=ForceFeedbackWaveform1
hex content
61 4A 00 00 ①F3 07 00 00 00 00 00 00 ②61 0B 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ③1D 14 00
00 00 00 00 00 BE 55 00 00 00 00 00 00 04 00 00
00 00 00 00 00 84 BE 00 00 03 41 00 00 00 00 00
00 BE 55 00 00 00 00 00 00 04 00 00 00 00 00 00
00 85 BE 00 00 32 55 00 00 00 00 00 00

...

:wallbash:

61 4A 00 00 F3 07 00 00 00 00 00 00 61 0B 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 1D 14 00

00 00 00 00 00 BE 55 00 00 00 00 00 00 04 00 00

00 00 00 00 00 84 BE 00 00 03 41 00 00 00 00 00

00 BE 55 00 00 00 00 00 00 04 00 00 00 00 00 00

00 85 BE 00 00 32 55 00 00 00 00 00 00

Here I highlighted the structure for you.

1: The yellow colored bytes represents a nameindex to the name of the property, bDamageUnits in this case.

2: The Blue colored bytes represents a nameindex to the property type, BoolProperty in this case.

3: The gray is some other non-printed data, I don't remember this from memory, so I'll leave it at that.

4: The red is the value data, in this case a byte for True/False, 01 = true, 00 = false.

Hope that helps :)

FlyingHigh10000000 · October 31, 2012

Something I noticed when giving Carapace armor the Torch ability, is that if you use a laser weapon to "fire" the napalm, no matter how good your LOS is, the stream will always result in the fire starting right next to your character.

rb0k · November 1, 2012

EliotVU!!!

Thanks for UE Explorer, it's helped greatly! If not for UE Explorer I'd have long given up modding this game.

Can you please explain what is up with jump offsets? I know they're not a simple number of bytes to jump or offsets into the function. For example...

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))
   {
       return false;
   }
   // End:0xd4 Loop:False
   if(iItem == 192 || (iItem == 135) || (iItem == 133) || (iItem == 134))
   {
       return false;
   }
   return m_arrItems[iItem].iCash != -1;
}

Bytecode:

C83500009F1F000000000000C53500000000000000000000C835000000000000470300007FB800000D010000BD0000000F00C63500001B001500000000000000C83500004A16078C0084849A35B7020000C6020000000000C635000026161821009A35B7020000C6020000000000C63500002C0216161821009A35B7020000C6020000000000C63500002C031616042807D4008484849A00C83500002CC016180E009A00C83500002C871616180E009A00C83500002C851616180E009A00C83500002C8616160428049B35C2020000C602000000001000C835000001513500001DFFFFFFFF16043AC735000053000000020082000505000000000000

My understanding:

Let, kItem,     Item(),               iItem,        EmptyParmValue,   )
0F,  C635 0000, 0015 0000 0000 0000,  00 C8350000,  4A,               16   

if (!,  ||, ||, ==, StructMember( .iCategory,  TItem.ScriptStruct,    0)  kItem,       1,    ),      Short condition?,
078C00, 84, 84, 9A, 35,           B7020000,    C6020000,           0000,  00 C6350000, 26,   16,     182100,

               ==, StructMember( .iCategory,  TItem.ScriptStruct,    0)  kItem,       2,    ),  ),  Short condition?,
               9A, 35,           B7020000,    C6020000,           0000,  00 C6350000, 2C02, 16, 16, 182100,

               ==, StructMember( .iCategory,  TItem.ScriptStruct,    0)  kItem,       3,    ),  ),
               9A, 35,           B7020000,    C6020000,           0000,  00 C6350000, 2C03, 16, 16,
               
return, false,  
04,     28,      

if (!,  ||, ||, ||, ==, iItem,       192,   ),     Short condition?,
07D400, 84, 84, 84, 9A, 00 C8350000, 2CC0, 16,     18E000,      

                   ==, iItem,       135,   ),  ), Short condition?,
                   9A, 00 C8350000, 2C87, 16, 16, 18E000,
                   
                   ==, iItem,       133,   ),  ), Short condition?,
                   9A, 00 C8350000, 2C85, 16, 16, 18E000,
                   
                   ==, iItem,       134,   ),  ),
                   9A, 00 C8350000, 2C86, 16, 16,
return, false,  
04,     28,


return, !=, StructMember( .iCash,      TItem.ScriptStruct,    0)  ArrayElement, iItem,       m_arrItems.ArrayProperties,  -1,          ),
04,     9B, 35,           C2020000,    C6020000,           0000,  10,           00 C8350000, 01 51350000,                 1D FFFFFFFF, 16,  

return, BYTE to INT, ReturnValue 
04,     3A,          C7350000

End of script
53

It seems when modifying the conditions the jump offsets need to be modified depending on not just the size of the bytecode, but also what instructions are used. Both offsets 0x8C and 0xD4 seem to be closest to function offsets, but are not. I've compared several conditions with various sizes and offsets but can't find the pattern. So far I've resorted to guessing.

Daemonjax · November 2, 2012

I tested the eAbility_Torch, and i saw no damage applied by the flame effect. But i checked the XComGame.upk and i found XComDamageType_AreaBurn where that was:
defaultproperties
{
bDamageUnits=false
DamagedFFWaveform=ForceFeedbackWaveform0
KilledFFWaveform=ForceFeedbackWaveform1
}
I dont know to much about programing, but i think we can apply the damage to the flames.

We can't change that (Actually, apparently Elliot can).

However, we can change: XComGame\XComDamageType\CausesSurroundingAreaDamage\CausesSurroundingAreaDamage.Function

static function bool CausesSurroundingAreaDamage(class<DamageType> inDamageType)
{
// End:0x32 Loop:False
if(inDamageType == class'XComDamageType_AreaBurn' || (inDamageType == class'XComDamageType_Flame'))
{
	return false;
}
return true;
}

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  33 4A 00 00 32 55 00 00 00 00 00 00 21 4A 00 00  3J..2U......!J..
00000010  00 00 00 00 00 00 00 00 23 4A 00 00 00 00 00 00  ........#J......
00000020  19 00 00 00 26 03 00 00 3F 00 00 00 2B 00 00 00  ....&...?...+...
00000030  07 32 00 84 72 00 23 4A 00 00 20 51 4A 00 00 16  .2.„r.#J.. QJ...
00000040  18 15 00 72 00 23 4A 00 00 20 4D 4A 00 00 16 16  ...r.#J.. MJ....
00000050  04 28 04 27 04 3A 22 4A 00 00 53 00 00 00 02 20  .(.'.:"J..S.... 
00000060  02 00 B3 0F 00 00 00 00 00 00                    ..³.......

Change the 0x07 to 0x06 at offset 0x30 to skip the conditional, and see what happens.

Hell, I'll make a distributable mod for it... 1 sec...

FireDoesDamageMod -- for XCOM Mod Manager

Edited November 2, 2012 by Daemonjax

PepprmintButler · November 2, 2012

I tested the eAbility_Torch, and i saw no damage applied by the flame effect. But i checked the XComGame.upk and i found XComDamageType_AreaBurn where that was:
defaultproperties
{
bDamageUnits=false
DamagedFFWaveform=ForceFeedbackWaveform0
KilledFFWaveform=ForceFeedbackWaveform1
}
I dont know to much about programing, but i think we can apply the damage to the flames.
We can't change that.

Actually we can. EliotVU showed me how and I did it ; it works (see my report a few posts up). The next thing is to find a way to give the damage a value because it does not seem to have one at the moment (instant kill).

I also already made the changes to causessurroundingareadamage, it seems to have some effect, but I still need to do more testing to be clear on how it works.

Thanks for the mod anyway, that's awesome, I hope more people can try it out and find out how it works because I don't have much time to do it myself these days.

Edited November 2, 2012 by PepprmintButler

Daemonjax · November 2, 2012

Can you please explain what is up with jump offsets? I know they're not a simple number of bytes to jump or offsets into the function.

I've been wanting to know that myself for some time now.

After about 6 hours I'd given up... Specifically on the same function you posted (function bool CanBeSold(int iItem)), and probably for the same reason.

Forget it.

It's magic. ;)

I will check out everything Eliot has said on the subject, though, since he's the Unreal Engine guru.

Actually we can.

I think we're talking about two different things.

EDIT:

61 4A 00 00 F3 07 00 00 00 00 00 00 61 0B 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 1D 14 00
00 00 00 00 00 BE 55 00 00 00 00 00 00 04 00 00
00 00 00 00 00 84 BE 00 00 03 41 00 00 00 00 00
00 BE 55 00 00 00 00 00 00 04 00 00 00 00 00 00
00 85 BE 00 00 32 55 00 00 00 00 00 00

I stand corrected it seems. That's some crazy guru s*** to figure that out. Not a feat I can reproduce at all. There's nothing that distinguishes that red 00 from the others in my eyes. Maybe Eliot can explain to us how the jump byte actually works (I'm looking at you, function CanBeSold).

Edited November 2, 2012 by Daemonjax

The flamer's "Torch" and other "new" abilities

Recommended Posts

Link to comment

Share on other sites

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Recently Browsing 0 members