Help adding a simple UI texture?

[Amineri]

My own problems are not so much as adding textures but to replace any defaults. In terms of pre-declared components, btw. Gee, just take a look at my qUIck Project thread and you'll understand what's mostly involved.

 

I've heard this whole restriction can be explained in a simple way; IF the engine can't find correct references (archetypes, addressable tags, archive paths, etc) there's no way it would loop them in as valid.

Secondly, the destination context matters a lot. GFX, straight up UI/HUD placeholders, indirect components, models... and many more situations.

 

We can benefit from a "UIListeners" method i gather... but that is a freaking difficult process to master reliably. For code savvy people maybe - but to the common man, there's a lot of dependencies to deal with -- many of which burried in extra functions or obfuscated locations or instructions.

 

IMHO, the only reasonable solution to every kind of indirect re-texturing attempts probably still is a gamble with "TexMod style" processing... rightfully adapted (by some genius IDE coder out there in the wild) to the most recent XC2 properties. We simply need a supplemental SDK toolset specifically aimed at controlling (reasonably) any graphics related issues.

 

Otherwise, we're doomed to building mod results in months rather than just a few hours of drag/drop fiddling with proper resources already tied with rational principles -- documented enough.

 

Zyx, you know I love you and your zany recoloring projects :smile:

 

The reality is that Game Engines tend to prioritize "Looking good" and "Performance" over mere trifles such as "moddability". So the path for inserting new textures often isn't easy. There's a couple of things in particular that make this so :

 

1) Support for LOD (Level of Detail). Remember it's not just one texture, but a family of textures at multiple resolutions that have to get swapped.

2) Consoles. There. I said it. Even though XCOM 2 is PC-only, it's still using Unreal 3, which has many aspects of design tuned for consoles... The Unreal Engine Cooking process is primary engineered around optimizing streaming of textures from linear media (i.e. BD/DVD). Thus, during cooking, all of the higher resolution textures are stripped out of the packages and placed into a common tfc (texture file cache). This actually does improve performance on PCs as well, though not as much. If you look in the game's CookedPCConsole folder, you'll see files such as "CharTextures.tfc" which is nice juicy 1.34 GB.

 

I'm not saying it's not possible to set up more straightforward texture changes -- a lot of the UI texture definitions made in Templates could have been shifted to config file instead, which would have made replacing them a lot easier. But not everyone is as "eccentric" as you and me when it comes to shoving stuff into config files ^_^.

[Deleted32045420User]

i saw a way to get templates changed once before loading a lot of the stuff with another template class- we could take EVERY SINGLE TEMPLATE we want to edit and rewrite its generation code (since they are mostly not static), but that's a metric ton of work, we could also get every single template and rebuild them with an ini file variable to be able to hot swap them more easily but that's even more work...

[davidlallen]

 

 

We generally use the PNG format instead of TGA. Practically speaking, the main difference between DXT1 and DXT5 is that DXT5 supports an alpha channel, while DXT1 doesn't. So your class_viper image likely doesn't have an alpha channel, which you're going to want.

That is certainly a good pointer. The guide I followed used TGA, and all the files that I looked at inside the base game upk files seem to be TGA. I will try out PNG, which is what I started with anyway.

[davidlallen]

Well, it isn't a problem with DXT1 vs DXT5. I built a new upk with png files and they show up as DXT5. Furthermore, this time when I imported, I was able to find the LOD setting the first time, so I know that is right also. It is so frustrating to see a mod right next to mine, where his graphics work and mine don't. What else can I be missing? I have attached the latest upk, different name (PlayableAdvent.class_mec).

 

Notice the message says it cannot "find" the texture, not it cannot "load" the texture, but the pathname spelling is correct.

 

EDIT: would it be helpful if I zipped the entire modbuddy project and attached that? It isn't a big project, the zip is only 72 KB.

Edited February 28, 2016 by davidlallen

[Amineri]

Just to toss out the obvious ... did you remember to add both packages to your VS project? If you forget that, it won't get copied over to the SDK and game folders, so wouldn't find it at run-time.

[Zyxpsilon]

 

I'm not saying it's not possible to set up more straightforward texture changes -- a lot of the UI texture definitions made in Templates could have been shifted to config file instead, which would have made replacing them a lot easier. But not everyone is as "eccentric" as you and me when it comes to shoving stuff into config files ^_^.

 

 

Yet... this *IS* exactly what i'm trying to convince someone in the higher spheres of **XC2-SDK + ModBuddy + Extra Toolset** design decisions. To give us, such a solid control over whatever we might want to fiddle with -- easily and ultimately via INI dispatch if feasible enough. If you've seen my new Classes Icons, you know i'll soon be aiming for some extra textures from the GTS -- four of which are dedicated bonuses tied with corresponding Classes. Like this for the Ranger's Hunter Instinct packaged into UILibrary_StrategyImages_SF...

 

http://s18.postimg.org/m6d2z09hl/GTS_Ranger.png

 

It's got to be a nice cool "SkyBlue" just like its cousin Icon. That simple. That easy? It should.

 

I know i could always tighten my workbench belt until suffocation under the weight of 60 years, get a modern hammer and just dive head first into UIListening +/- various complex Templates/Functions and other coding tasks -- but i'm absolutely sure there is another magic trick (other than good old hacky TexMod). What's lacking is the willingness by Firaxis to just provide it to all of us.

 

Then again, there's the elephant in the room; Flash! Oh god -- help us all.

 

PS; David, i'll take a look at your project files -- two more pair of eyes are better none.

 

PS2; Amineri, DXT1 simply ruins the quality of most images as the 4x4 nearest denominator pixels are scrambled like a mess when re-allocation proceeds. This flaw is more evident when re-scaling factors get in too high range territory. DXT5, less so.

Edited February 28, 2016 by Zyxpsilon

[davidlallen]

did you remember to add both packages to your VS project? If you forget that, it won't get copied over to the SDK and game folders, so wouldn't find it at run-time.

 

They are both in the project, and I checked that both are present after the build under steamapps\common\XCOM2\XComGame\Mods\<modname>\Content.

Why does the SDK make its own copy under steamapps\common\XCOM 2 SDK\XComGame\Mods\<modname>\Content? What is that used for?

 

Please find attached the entire current modbuddy directory. I didn't keep the rifleman file around. This gives the rainbow img for the alien flag, which you can probably try at startup by looking in the customize menu for nationality. It is called in XComGameBoard.ini.

[Zyxpsilon]

:D

Zip isn't UPK for archiving, btw.

 

Anyhow, your Texture2d file for the class_viper seems to be in the proper Alpha format... so it's most probably a property declaration that couldn't tag the correct path to it.

 

..... (Got the project files and fired up UEExplorer)..

 

What concerns me is this function from class PA_UIScreenListenerProvingGrounds; ((or DLA_ ))

----------------

LogInternal("davea debug uisl-pg called exists is " @ string(alreadyExists));
// End:0x332
if(!alreadyExists)
{
tMec = new class'PA_MecTech';
techMec = tMec.CreateTemplate();
tState = XComGameState_Tech(NewGameState.CreateStateObject(class'XComGameState_Tech'));
tState.OnCreation(techMec);
NewGameState.AddStateObject(tState);
tViper = new class'PA_ViperTech';
techViper = tViper.CreateTemplate();
tState = XComGameState_Tech(NewGameState.CreateStateObject(class'XComGameState_Tech'));
tState.OnCreation(techViper);
NewGameState.AddStateObject(tState);
LogInternal("davea debug uisl-pg added two templates");
}
History.AddGameStateToHistory(NewGameState);
//return;

----------------

 

Two conditions in the same IF/RETURN. Second might not be detected.

Can you confirm?

 

#2) UIFlag_Alien... Green/on/Blue? (let's see).. aren't these dependent on a CUSTOM set of declared "empty" Flag slots like the multiple Mods that offered many such Flag(s) package??

Edited February 28, 2016 by Zyxpsilon

[davidlallen]

Well, I got the flags and class icons working, but I have no idea why. So I'll move this from "broken" to "mysterious". I compared the rifleman upk to my upk more carefully. There are two differences: the filename of the rilfeman mod is UILibrary_Rifleman, while mine is PlayableAdvent, and the textures are supposed to be in UILibrary. Also, when I open the rifleman upk in the editor, it shows up in the "External" section of the content browser, while mine shows up the "New Packages" section. So, I copied ULibrary_Rifleman.upk to UILibrary_PlayableAdvent.upk, and now it shows up in "External". I copied my textures into that new file and now they display properly in game (obviously I changed the file paths in the ini files to correspond). I have no idea which, or both of these things is important.

 

Does this information help anybody else explain why my original upk did not work?

 

@ Zyxpsilon, I did not understand your comment about "two conditions". I would like to move this code out of a UIListener, but it is working; it creates two different proving ground projects.

Edited February 28, 2016 by davidlallen

[Zyxpsilon]

If it *now* works as intended.. i'd suggest not touching anything. That Loop of two/conditions (more like statements) is a simple indirect debug check step (i think) and thus should have no direct effect on the "running code" resources necessary. Might be entirely wrong about this though since after all -- you're the messy coder that got into some weird troubles with unavailable //img// textures. :wink:

 

AFAIC, i was right on the dot to identify paths and/or INI declarations as the likely culprit of your buggy situation (as described here). UPK archives are fancy stubborn assets as far as "referencing" principles go, IMO. This is related to being experienced (enough) with such ModBuddy/SDK hidden secrets, i guess.

 

PS; Do you want a clear shot at LAByrinth script development? I'm looking for some solid partner. There are no "Viper-Tits" or "Advent-Bots" in my structural plans though. :D

Edited February 28, 2016 by Zyxpsilon