R&D - New Modding Tools

[dreadylein]

@wghost81

 

if i remember right ueexplorer is written in a .NET Language und yield realy good readable decompilation, this should speed up your work quiet a bit, i would ask eliot before tho

[wghost81]

Having UE Explorer source code will be great, but as I understand, Eliot is not planning to release it (?). And right now Amineri and the others are working on actual tool, not me. I'm still trying to find dynamic aliens deployment code and I think I'm onto something. At least found where wave system parameters are defined (inside map upks, will make a topic about it when I'm done). Edited December 5, 2013 by wghost81

[dreadylein]

As long as UEExplorer isnt obfuscated ( and i think i remember it not beeing obfusacted) distributing the Binary is more or less like distributing the Source

[wghost81]

Well, I'm not an expert on reverse engineering. :smile: I can deduce data file format, but binary code disassembling is not in my skill set. :smile:

[dreadylein]

.NET is Bytecode and decompiiation yields preeeetty accurate highlevelcode ;)

[wghost81]

May be. But as I said, disassembling is not in my skill set.

[Amineri]

It's been a little while since I had much to say. Things are still moving along (if slowly), though.

 

With X's excellent Java GUI coding skills (my Java knowledge is pretty paltry), I was able to get some test Java code that can open, parse and display a modfile in a collapsible tree format, like so :

 

 

It's still quite rough and has a lot of debugging display stuff in it (the numbers at the front are the start/end character offsets for the document element). All of the various operands are shown rather generically (e.g. ModOperandElement_1B instead of "Virtual Function", and ModOperandElement_19 instead of "Context Token").

 

However as proof of concept it's nice to see that can correctly parse the unreal bytecode and identify key parts (jump offsets, references). I'm kind of thinking of this as an alternative view (with some definite cleaning up) to aid in visually comprehending the bytecode.

 

There's still a lot of work to do with regard to getting the document model linked to an editable general text editor and creating highlight styles for the various types of tokens. So don't hold your breath on it quite yet :D

[dreadylein]

Quiet neat ;)

Nice work

[troch22]

wow

[Amineri]

So finally some more forward progress after being a bit stuck for a day or so...

 

This is a screenshot of a loaded plain text modfile document. All formatting was done based on a parser that highlights various components.

 

 

 

For comparision here is the original file looked like as plain text before being loaded :

 

 

MODFILEVERSION=3
UPKFILE=XComGame.upk 
GUID= 33 2E 29 6A A5 DD FC 40 B5 CC 57 A5 A7 AA 8C 41 // EU patch 4
FUNCTION=ApplyActionCost@XGAbilityTree
// Increase max pod size Mod
// Author: Amineri 
[BEFORE_HEX]
[code]
// PlayerIndex = 0;   PlayerIndex@InitAlienLoadout@XGBattleDesc
0F 00 10 A0 00 00 25 
[/CODE]
[/BEFORE_HEX]

// line with parse error -- incorrect trailing 01 value
[AFTER_HEX]
[code]
// PlayerIndex = 1;   PlayerIndex@InitAlienLoadout@XGBattleDesc
0F 00 10 A0 00 00 26 01
[/CODE]
[/AFTER_HEX]


[BEFORE_HEX]
[code] // parsable unrealhex -- corresponds to full lines of code -- allows operand decoding
//iCost = XComGameReplicationInfo(class'Engine'.static.GetCurrentWorldInfo().GRI).m_kGameCore.GetAmmoCost(kAbility.m_kWeapon.GameplayType(), kAbility.GetType(), kAbility.m_kUnit.GetPlayer().HasFoundryHistory(10), kAbility.m_kUnit.GetCharacter().m_kChar, kAbility.m_bReactionFire); (259 file, 379 virtual bytes -- 120 extra)
0F 00 C3 7E 00 00 19 19 2E FE 2C 00 00 19 12 20 4F FE FF FF 0A 00 D8 F9 FF FF 00 1C F6 FB FF FF 16 09 00 98 F9 FF FF 00 01 98 F9 FF FF 09 00 F0 2C 00 00 00 01 F0 2C 00 00 13 01 42 10 00 00 00 1B 16 31 00 00 00 00 00 00 38 3A 19 19 00 C4 7E 00 00 09 00 E8 BB 00 00 00 01 E8 BB 00 00 0A 00 E8 9B 00 00 00 1B 92 30 00 00 00 00 00 00 16 19 00 C4 7E 00 00 0A 00 1C 7C 00 00 00 1B 1E 35 00 00 00 00 00 00 16 19 19 19 00 C4 7E 00 00 09 00 E6 7B 00 00 00 01 E6 7B 00 00 0A 00 EB B2 00 00 00 1B 0A 34 00 00 00 00 00 00 16 0C 00 9E 94 00 00 00 1B 7A 36 00 00 00 00 00 00 24 0A 16 19 19 19 00 C4 7E 00 00 09 00 E6 7B 00 00 00 01 E6 7B 00 00 0A 00 63 B4 00 00 00 1B 7B 31 00 00 00 00 00 00 16 09 00 C3 A2 00 00 00 01 C3 A2 00 00 19 00 C4 7E 00 00 0A 00 D2 7B 00 00 00 2D 01 D2 7B 00 00 16 
[/CODE]
[/BEFORE_HEX]

[AFTER_HEX]
[code]
// iCost = kAbility.GraduatedOdds(0, kAbility, kAbility.m_kUnit.GetPlayer().HasFoundryHistory(10)); (92 file, 128 virtual bytes -- 36 extra)
0F 00 C3 7E 00 00 19 00 C4 7E 00 00 61 00 B9 7C 00 00 00 1B E1 35 00 00 00 00 00 00 2C 00 00 C4 7E 00 00 19 19 19 00 C4 7E 00 00 09 00 E6 7B 00 00 00 01 E6 7B 00 00 0A 00 EB B2 00 00 00 1B 0A 34 00 00 00 00 00 00 16 0C 00 9E 94 00 00 00 1B 7A 36 00 00 00 00 00 00 24 0A 16 16 

// null-ops
0B 0B 0B 0B 0B 0B 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 00 C3 7E 00 00 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 
[/CODE]
[/AFTER_HEX] 

 

So the current (very bad looking highlighting) has :

• Operand Tokens : in Bold-Blue
• 
  
• Virtual Function references : Underline-Magenta
• 
  
• Regular references : Underline-Orange
• 
  
• Jump and Relative Offsets : Background-Yellow (the parser can tell the difference, but I'm just not highlighting them differently)
• 
  
• Bytecode with errors : Background-Red
• 
  

The tree view of the file is displayed on the left, allow display of bytecode nesting.

 

The key thing to keep in mind that this highlighting is all done in a text editor. I have to confess, until I saw this view I didn't really appreciate just how many references there could be in a single line of code :o

 

I'm not quite there yet in terms of having the model update correctly as the user types in the editor (there is some niggling thing wrong with a thread I tried to implement), but I feel confident that XMtS will sort it out shortly. Ultimately the design is that the highlighting will adjust as the user types.

 

After that the "hard" parts are over, and just have to layer in menu options etc to make user control happen. The model can also calculate memory sizes of lines and various parts of lines, but I haven't figured out a good way to display the info yet.

 

The plan is to add the ability to update references in an automated fashion and apply/revert hex changes directly to upks for debugging. Also I think there are still plans for a project file to contain/manage multiple modfiles.

 

I must confess to being a bit excited to start to see things finally coming together :D