Jump to content

UI Editing

johnnylump

By johnnylump
in Enemy Unknown

 Share

Recommended Posts

Amineri Veteran

Amineri

Posted
Posted (edited)

I've figured out a couple more tricks to make UI editing a bit quicker and less painful. These are primarily oriented around editing the SCRIPT portion of the actionscript (as opposed to the sprites or bitmaps).

 

1) Hex Codes

A fairly comprehensive set of hex codes can be found here: http://www-lehre.inf.uos.de/~fbstark/diplom/docs/swf/Actions.htm

Scripts in Actionscript are considered a specialized type of ACTION, and are always wrapped in an action tag. Scripts are not procedural (like in UE hex code), but is stack-based, which may require some adjustment.

2) Null-ops

Actionscript doesn't directly have a null-op (like the 0B in UE hex), but you can create null ops of various sizes. Simply PUSH a string onto the stack, the POP it back off. The string can be variable length so a variable length null-op can be created. The PUSH, POP, and the string terminator require 6 bytes, so this is the smallest null-op that can be created this way.

 

3) Quickly generating hex code

The JPEXS decompiler supports a limited amount of editing. Currently it is limited to editing the stack-level commands (push, pop, etc) as opposed to the higher-level C/java style code (there is beta version of that editing capability, but it isn't working yet).

I've found the following sequence that lets me edit the scripts fairly quickly:

1) Open Actionscript, figure out what code I want to change

2) From the JPEXS hex-view, identify the leading hex blocks for the original function and the NEXT function

3) Using HxD, copy out the hex of the function from the original SWF

4) Back in JPEX, edit the function in the "stack view"

5) "Save as" the changes to a new file (JPEXS can't save much of the data in the original SWF, but it can correctly save all of the scripts)

6) From JPEXS hex-view, identify the leading hex blocks for the edited function and the NEXT function

7) Open the newly saved SWF file in HxD (or other hex editor) and find the block of changed hex

8 ) Copy out the modified hex from the modified copy of the SWF

9) Test the new hex by search and replace in a copy of the ORIGINAL SWF, and try to decompile in JPEX

This is MUCH MUCH faster than trying to manually edit the hex codes. Due to the stack-based structure, MANY of the commands are 1 byte. Using the above method I was able to rewrite a 1014 byte SWF function in about an hour.

Edited by Amineri
Link to comment
Share on other sites
  • Replies 54
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Amineri Veteran

Amineri

Posted
Posted

Yup. Right now still in the middle of the perk tree overhaul. It's a pretty substantial change. 8 significant function rewrites in the upk files, and 2 substantial changes in the swf files.

 

To be honest I might take a little while on the UI editing article -- once I get done documenting the perk tree change I'll probably not want to edit the wiki again for a while o_O

Link to comment
Share on other sites
dubiousintent Grand Master

dubiousintent

Posted
Posted

I can relate to that. But I'm thinking Bokauk could use the assistance of such an article right now with her Perk Builder. However, you have the best sense of your priorities and capabilities and you both are interacting nicely already.

 

-Dubious-

Link to comment
Share on other sites
bokauk Collaborator

bokauk

Posted
Posted

Don't worry about me; the part of the perk builder I'm working on at the moment is fairly straight forward in terms of UPK edits. I'll get this part of it working before attempting to wrap my head around the SWF UI changes, but I'm sure the research and notes Amineri has posted will be hugely beneficial when I get around to that part :smile:

Link to comment
Share on other sites
Amineri Veteran

Amineri

Posted
Posted

That's why I'm trying to drop the "good leads" and such bits of wisdom as I possess onto the forum. Editing the wiki (with it's need to manage all the special tags) takes about 5x longer for me right now, and is definitely more draining.

 

I imagine eventually I'll get more proficient at the wiki editing thing (plus there will be solid templates), but for now it's slow going.

Link to comment
Share on other sites
dubiousintent Grand Master

dubiousintent

Posted
Posted

There are separate templates for subject articles and Mods already under 'Category:Tutorials - XCOM:EU 2012'. Just the template for Mods is also linked under 'Category:Mods'. Let me know if any others would help.

 

Also when editing a page the Edit Help link (bottom of the page, next to the buttons) now contains links to the MediaWiki help pages, and some 'mini-templates' to put high visibility message boxes on a page. I've been using them for a lot of copy-and-paste stuff. Let me know of anything that would help speed up the creation of a page.

 

-Dubious-

Link to comment
Share on other sites
  • 7 months later...
Amineri Veteran

Amineri

Posted
Posted

Sorry to necromance this thread, but it does have most of the back history on editing the embedded Flash code, and I'm trying to figure out a new angle on this.

 

I've been working on changing how the MECs are built/equipped, and I've been able to mod the game so that all of the MEC armors, MEC rifles and MEC secondary systems are built in Engineering (including meld cost), and are equipped in the Locker screen like all the other soldiers are.

 

The problem I've having is that Firaxis didn't appear to create any Inventory / Item Card imagery for these items, so while it technically works it looks really, really ugly.

 

Here's what I've been able to trace so far :

  1. Inventory images are referenced via string, which is retrieved from XComGame.upk >> UIUtilities.GetInventoryImagePath.
    • A typical example string is : img:///UILibrary_StrategyImages.InventoryIcons.Inv_LaserRifle
  2. The imagepath is passed to the Actionscript via AS_AddInventoryItem(int Type, string Title, string imgLabel, int numEquipableItems, GFxObject mecIconsArray), the 3rd parameter imgLabel
  3. I've extracted the SoldierLoadout Flash file and traced through, and ended up in SoldierPromotion.ImageContainer with: 
    1. Bind.image(register2,this.imgPath,{"onComplete":mx.utils.Delegate.create(this,this.realize),"_visible":true});
  4. Bind is another package within SoldierLoadout, with the function image: 
    1.    static function image(owner, path, props)
   {
      ImageLoader.load(owner,path,props);
   }
  5. ImageLoader looks like a pretty low-level Package in SoldierLoadout. It invokes : 
    1. ClipLoader.load(container,path,properties);
  6. ClipLoader is yet another package (I'm not sure why they bounce around so much ...), which invokes : 
    1.       register1=new MovieClipLoader();
      register1.addListener(ClipLoader);
      register1.loadClip(path,container);
      register1.path=path;
      register1.properties=properties;
      if(ClipLoader.loaders==undefined)
      {
            ClipLoader.loaders=new Object();
      }
      var register3=String(container);
      ClipLoader.loaders[String(register3)]=register1;

 

And this is as far as I've been able to trace it. I haven't been able to figure out where the actual image associated with the string "img:///UILibrary_StrategyImages.InventoryIcons.Inv_LaserRifle" is.

 

Ultimately my goal would be to be able to add additional images, but I can't even figure out where the images are stored, so inserting new images is still a ways off.

Link to comment
Share on other sites
Drakous79 Experienced

Drakous79

Posted
Posted

Amineri, you can check Command1.upk >>> Content >>> UILibrary_StrategyImages.InventoryIcons.Inv_LaserRifle. It is the one from loadout screen.

 

It is stored as DXT5 texture in the upk. You can recreate *.dds file by combining spoiler A+B.

 

http://i.imgur.com/lclXLBH.jpg

 

A. Image DDS header taken from a file saved by Texmod (loadout screen):

 

  Reveal hidden contents

 

 

B. Image raw uncompressed data stored in Command1.upk:

 

  Reveal hidden contents

 

 

C. Command1.upk Texture2D object cotains header, image data and footer. Header contains data seen in UE Explorer. If there are more sizes of an image, each size has own entry in the header. Each image entry can contain size and offset in texture file cache file. Footer of LR icon is:

 

  Reveal hidden contents

 

 

 

Still working on documenting it. The process is really nasty. Tfc files have a compression I haven't been able to decompress yet. Texture2D header contains offset position of image data (0x0256427C) in Command1.upk, so adding new images in-place may affect positions of all images later in the stream. Also you'd have to add new Name List entries, new Export List entries, new Texture2D objects with image data (may be possible to append them to avoid recomputing offsets).

Link to comment
Share on other sites
Amineri Veteran

Amineri

Posted
Posted

Aha, so that's where they are hiding out. Most useful :)

 

My first step is to double check that the MEC secondary weapon images weren't included in the upk but just not added to the UIUtilities helper function in XComGame.upk. ... they weren't.

 

This means to get any sort of meaningful images for these six items they would have to be added. I'm thinking it's going to take a combination of wghost's techniques for appending new objects to the end of the upk file and then linking them into an existing container (as she demonstrated with the structure), PLUS understanding what the compression mechanism is for the image data so that new images can be created.

Link to comment
Share on other sites
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...