R&D XCOM UI/Flash modding

[Zyxpsilon]

Good job! That means the basic framework is in place and almost ready to receive a number of features and sampling components. Which in turn will lead to the nitty gritty encoding of the dedicated Summary Methods+Functions+Data+GFX_Assets (..etc) resources.

 

I just hope a similar process would be possible to implement the "LW-Pedia" stuff as it is #1 on my list (Summary being second) of priority projects.

 

:wink:

Edited July 11, 2015 by Zyxpsilon

[Amineri]

 

copying the resulting map and other packages into the CookedPCConsole folder,

 

One small suggestion. You should be able to drop all of your files into a subfolder within CookedPCConsole folder, instead of in the root folder itself. Vanilla does this with the Voice folder. When I was first experimenting with the code for new voice files, I put the new voice packages into a separate "LW Voices" subfolder, and they were loaded just fine with no configuration changes.

 

Hopefully this should help keep things more organized.

[tracktwo]

Yeah. I was actually thinking about how these kind of mods would be installed, as there are a lot more moving parts than just a patcherGUI script. Putting all the associated .upks in a new sub-folder is one part of it. The other part is getting all the .ini and .int changes applied. It's not quite at a LW level of installation problem, but it's getting worse. Some kind of installer is probably going to be necessary, and it'll need to be smart enough to not interfere with other mods that may already be installed.

[Amineri]

In theory, the unreal config files support separate files that "merge" to make the final version in My Games (at least on windows).

 

If you look at some of the DLC in Enemy Unknown, you can see how the DLC provides for additional lines to be merged in without modifying the Default version.

 

Unfortunately, I've been unable to get this working under Enemy Within.

[tracktwo]

I've figured out a little bit more about the mechanisms for flash interfaces used in certain areas, mostly in the strategic UI.

 

For these, the flash movie is not drawn directly onto the screen, but rather is basically attached to some model as a texture. The situation room back wall, for example, shows the world map while you're scrolling around in the ant farm view. Clicking on it or selecting the room from the menu will lock the camera onto it and zoom in, but during that process you can already see the HUD elements have been placed - the blank side panels are filled with the country info, the ticker starts up, and the doom tracker is overlaid on top of the map. This is all flash, and it's attached to the wall and doesn't scroll with the camera.

 

This is handled by a state in XComHQPresentationLayer - State_SitRoom.Activate. It does the following:

 

* Spawns the situation room submenu flash, and displays it. This is not attached to a texture, this is a HUD that's written right onto the screen and doesn't scroll with the camera, it's parent movie is the main HUD.

* Spawns the situation room UI (UISituationRoom) and displays it. This one is not parented to the main hud, it's parented to the return value of Get3DMovie(), which has type UIDisplayMovie.

* Shows the new display passing in a DisplayTag UIDIsplay_CountryPanels.

 

The DisplayTag is a name, and names an actor on the map of type UIDisplay_LevelActor. Presumably, this actor is associated with the situation room map plane model. There is code in UIDisplayMovie.ShowDisplay() to attach the movie rendering texture to the material on the actor.

 

The game handles all the perspective and scaling for this rendering - I tested this with a sample movie attached to the situation room display tag and it displayed correctly with all resolutions I tried.

[tracktwo]

A couple of new discoveries to document:

 

- The Xcom base class UI_FxsPanel (from which UI_FxsScreen inherits) does not inherit from the scaleform base class GfxMoviePlayer. This is the class that has all the useful little utilities like invoking actionscript with ActionScriptVoid() and friends, but they're all private and are by default inaccessible to UI subclasses of Screen or Panel because this is enforced by the compiler (even if it isn't at runtime). In the version of Engine.upk from XCom, these functions are not private, the accessibility was adjusted. We can do the same and just make them all public in the copy of GfxMoviePlayer.uc that comes with the UDK and all is well.

 

- Symbols can be imported from other flash movies that are in the game, as long as those symbols have been exported, and many have. To do this, you just need to know the name of the symbol and it's path. For example, the panic bar in the situation room can be accessed through the path "../gfxStrategyComponents/StrategyComponent" with the name "panic bricks". To do this, create a new symbol with the same name "panic bricks" and under "Runtime Shared Library" tick the import box and enter the path. To determine the path you need to use a combination of UE Explorer to find the true package name and class name - in this case they're strategic elements in the strategic layer map Command1.upk and you can find them under the "Contents" tab. Then you need to extract the swfs (with toolboks) and open them in something like JPEXS until you find the right .swf and then locate the asset you want. Validate that it's actually exported in the "others" tab as an "ExportAssets" element and note the name. Symbols that are imported like this can be dropped on the stage and manipulated, but are not actually embedded in your .swf, they're found at runtime, meaning they don't need to be distributed with the custom .swf.

[XMarksTheSpot]

And here I was thinking XCOM modding was dying down after LW went final :smile:

 

Very glad to see more people picking up GFx modding; I find the parts about injecting new FxsMovie implementations very fascinating, I assume a similar procedure will be possible in XCOM 2, so I'm interested to learn more about that :smile:

 

Your observations align with mine for the most part, I was going to point out the 'Runtime Shared Library' feature, but you happened to do so yourself today. One addition regarding that feature is worth mentioning though, certain resources are shared among GFx objects without explicitly being imported, namely ActionScript classes. While most GFx files contain duplicates of certain common classes (e.g. generic stuff like Environment or Colors as well as specific UI component implementations like XComList and XComButton), they are actually a side-product of the export process from Adobe Flash and are essentially dead weight as they aren't actually used in-game. Most of the common class templates are looked up from a central repository which is located inside the interfaceMgr GFx file inside XComGame.upk.

 

To name a use case, to rework the way scrolling in list components works for LW I had to edit only the XComList and XComScrollbar classes inside the interfaceMgr file and this automagically applied to all menus where instances of those classes were used (there were some exceptions like the load/save dialog which implement scrolling differently).

 

On the authoring front, I've successfully prototyped and exported assorted sprites and associated ActionScript classes using Flash CS6 and brought them into the game by injecting them into an existing GFx file via hex edits. I've also read lots of the SWF FIle Format Specification on which GFx files are fundamentally built, so I have a pretty good understanding of the inner workings of SWF/GFx files - which helped immensely when trying to figure out the whole hex injection business :smile:

That said, I can definitely lend a hand with the authoring part of any UI projects you might have planned, if you want.

Edited July 16, 2015 by XMarksTheSpot

[tracktwo]

I'm hopeful that this will be applicable to XCOM2 too, but until we know more about what will actually be in the modkit it's all just guesswork. We know they're staying with a v3 UDK, which means if they continue to use scaleform for the UI it'll probably either be the same or possibly scaleform 4 if they've moved to a slightly newer version of UDK3. If they did move to one with ScaleForm 4 then we could use AS3.0 but the fundamentals are probably the same. That's sort of why I went down this path, cause I think it'd be somewhat applicable to both EW and XCOM2.

 

I was curious about why the script files were included in every single package, when it seemed like they weren't actually being used. Is that fundamentally a name resolution thing because of how the movies are injected as sub-movies of the master movie? I.e. Environment.instance() in the sub-package actually refers to the Environment class in the root and you'd need to fully qualify the name (this.Environment?) to get the one in the package, or am I way off base on that?

 

Happy to have a flash expert around, though, so I'd like to chat a bit after I get back next week. I'm currently mostly working on the campaign summary mod, if you'd care to help out at all with that it'd be appreciated!

[XMarksTheSpot]

I was curious about why the script files were included in every single package, when it seemed like they weren't actually being used. Is that fundamentally a name resolution thing because of how the movies are injected as sub-movies of the master movie? I.e. Environment.instance() in the sub-package actually refers to the Environment class in the root and you'd need to fully qualify the name (this.Environment?) to get the one in the package, or am I way off base on that?

I think the main reason that those class duplicates exist is because Adobe Flash likes to publish fully self-sufficient Flash movies. As such a SWF/GFx file itself is not actually "aware" that its AS classes are supposed to be pulled from elsewhere - I believe this is the job of the in-engine Scaleform implementation. Similar to how several Flash movies are composited in the scene I expect the same to happen to their corresponding AS classes, i.e. discarding/ignoring duplicates in favor of those higher up in the hierarchy (rooted at interfaceMgr.gfx, I assume).

 

It would be nice if local class duplicates could be used as some form of overrides for menu-specific implementations, but alas, that doesn't seem to be the case. Nevertheless it's pretty straightforward to provide your own subclasses extending core classes and linking them to your sprites of interest. All you need are stubs of the relevant AS classes so Flash will compile everything properly. If you want you can rip the actual classes using a Flash decompiler like JPEXS, but stubs will do as the embedded local class variants after export don't end up being used anyway :)

Edited July 17, 2015 by XMarksTheSpot

[tracktwo]

Yeah, stubbing seems to be the tried and true method for both actionscript and unrealscript modding :)

 

I wonder what if any flash assets we will get in the mod kit - they did say that some game assets would be included but who knows what that will actually mean... If we get actionscript sources that'd be nice, not having to manually stub everything would be a real improvement.

 

Getting the .fla files would be even better, but I dunno what the odds of that are!