Zyxpsilon

Direct approach (as in UI-Listeners & multiple custom function(s) in some weird dedicated scripting methods) is exactly what i would prefer to escape with a specific SDK "toolset" that would replace TexMod-style processing entirely. Call me lazy or unskilled enough to bother... but in my mind -- this sort of technicality should have been ironed out waaaayyyyy BEFORE release. It's best practice to supply everything possible. But who am i to judge what they did or were enforced to do. In the meantime, we're struggling and working in minimalized conditions. I'm no genius. Some are. Not everyone is.

Then, that surely means another issue has caused ModBuddy to isolate that x2project wherever essential "packaging" processes can't detect anymore. As for a proper diagnostic, it's fairly hard for anyone to determine except by.. you carefully examining LOGs or other tracing factors that may hint on flawed scripting steps. It may also be a buggy SDK installation or borked resources in the folders structure ( tried verifying yet?! ) , IMO.

Sooooo, any decisions yet about the feasability of modding such a QoL asset, FalcomPro? Cuz, i might have something else to offer you in exchange. ;)

This happened to me as well.. for nearly a week before i decided to hump into the process with a sledgehammer. Somehow, ModBuddy & SteamLauncher references were looped into the valid access pool using the exact MOD names found in x2proj declarations. What this does is a knockout tagging function where every further BUILD attempts would simply try processing any newly edited files assuming the past Mod-Title(s) versions are still active -- thus protected. The only thing that worked for me was to delete all instances of the borked MOD everywhere (while preciously keeping copies of the essential files as backup in some isolated folders) the old name existed. Then, start fresh from scratch with a brand new project RE-NAMED. Add the backup "files", verify anything, rebuild solution -- done. So your "Vigilo Confido" must be changed for "Vigilo Confido2"... for example. Sadly though, the old naming principle (ID & tags) is now off-limits and should never be used again -- unless you enjoy being spammed by continuous "FAILED!" :wink: *** PS; Note a new HotFix is now live. Maybe they resolved such issues.

That could be the solution i've been waiting for (directly from some SDK update/extra Tools that may well never come our ways, sadly)... I just want an easiest process to reproduce what TexMod was able to achieve by snatching runtime Hash-Tags and looping in its custom TPF files aiming to replace simply Vanilla assets. Without the whole complex tragedy of searching each instances of target objects -- be they supplied by core functions or embedded in various gfx components. To be precise (currently), Ranks Icons.. everywhere they're getting dispatched on the UI -- all at once. And maybe some more interesting HUD elements mainly archived into UILIbrary_Common.UPK, etc. PS; Indirectly this is a formal request to any genius coders out there for a specific XCom2 IDE that would perform the same tasks but within compatible limits inherent to things like the Steam-Launcher or Flash resources -- just to name these two.

That would be somehow easy to gather up yourself... just searching through two specific files. 1) XComGame.INT (Localization Folder) 2) XComGameData_SoldierSkills.INI (..\Mydocuments\MyGames\XCOM2\XComGame\Config) Some other UC script files (mostly Templates) might even give more hints for each. Example... X2Ability_GrenadierAbilitySet.uc

Yes - that's right... at first i thought they had somehow changed the HTML coloring context(s) away from gfx/swf compositing. It's probably sbatista remark of "Keep in Sync" that mislead (or confused) me the most. Here's my current plans (in a weird theory) for HTML dispatching. 1) The top right side row of HUD icons (End-Turn, Next+Previous, etc) are using those principles to toggle their active states (ON/OFF, hovering) while i simply could snatch a texture hash-tag for the Re-CLR mod stuff. So in my wacky mind, i wanted to have more "Static defaults" pre-defined for later use under various custom functions -- if & when need be. 2) The ingame Tech-Tree project (LAByrinth) would also need a wider complexity of such colors (when toggled) to tag various gameplay facts in a possible flow-chart style device. Research_Blue=Check... Engineering_Orange=Check... But if you recall LW-Pedia_DB had given Armors/Yellow... Weapons/Red... SmallItems/DarkOrange... etc. So to maintain some sort of consistant approach, their available pool of colors is too limited for what i need to achieve. 3) Since LW had eight Classes i decided to make their Icons coloring schema unique... but also the various perks did get a distinctive "Framing box" to put most in their relative origins as direct references. I'd like to offer a similar system for XC2 -- but again, by only toggling a dedicated 8 colors HTML dataset (see below). Faster, easier, familiar (to me). http://s17.postimg.org/3kotd9rmn/Swatches_RANKS.png ... Ranks palette. http://s24.postimg.org/nfxzc199x/Swatches_CLASSES_HTML.png ... Classes palette. L/R= Psi, UI-Cyan, GeneMods, MECs, Grenadier, Medic, Gunner, Rocketeer, Assault, Infantry, Scout, Sniper! Sooooooo.. since XC2 can also have EIGHT pseudo-classes by selecting two distinct sides - there is surely an indirect design connection for me to exploit eventually with at least, Perks identifications and rapid visual detection. Throw in the newest "random" bonus gimmick and you get how specific colors could help out. Toggling i predict could allow for much smoother integration and less busy code. 4) I really hope GFX+SWF editing (( low level fiddling might even be enough for some people! )) will soon be made available by an extra SDK toolset. Considering 80+% of the whole interactive HUD stuff depends on Flash components -- it's a spectacular Modding control they'd keep away from everyone for i don't actually care what vague reasons. Adobe_Flash is seriously MUCH too costly for the hobby driven crowds out there. Ideas are fun to have. Paying for solid results though is a very different beast or obstacle. Firaxis & 2K absolutely need to step up to the plate and take a swing at proper Modding capacities for the masses of talented minds just waiting to make this gameplay even more enjoyable. SDK is the pocket knife edge, we just need (or want) a true Ranger's bloody metallic Scimitar that never misses.

W-T-F... where are the cumulative STATS tracker details? Bugged off to oblivion by an overwhelming player base? Has anyone ever waited long enough for the game-ending-server to activate whatever it is the process must gather up online? I pressed ESC after 30 seconds. Which is an eternity in a world of Alien mathematics subliminally stuck at results we simply want to view before going to bed -- in the morning after. http://s14.postimg.org/nd2618vht/WIN_Page1.png ... 2/4 ... 3/4 ... 4/4. World == Z-Hero'es!! :devil: :ermm:

Now decrypt this Twilight-Zone linguistic ruleset for me please...(Legit--) Q/A (--Pending) in various popular (or less so) threads on Nexus. :smile: :laugh: PS; Amineri... remember how LW1 went beyond the call of Moddy to provide addressable stacks of Image references using its custom DefaultContent.INI ((MultiplayerLoadoutSlots= spiking at the LongWar.UPK and more)) ? Why-Oh-why didn't Firaxis include (straight into the SDK toolset) such precious control over their "HUD+UI" assets for anyone to replace at will?? I mean, in all logic -- they surely knew what TexMod is capable of hacking. Why limit everyone's power or restricting alternate solutions via complex code acrobatics 95% of the planet don't even understand? Where's the proper HOOK i've been urging for over the last 19 days? XC2 got Voice-Packs, Hundreds of pooled behind the 8-Ball Characters, a few QoL diamonds here & there, Flags diversity exponentially packaged from everyone's opinions of what is a must have... Shall i continue?

Com'on... we're all just a bunch of Modders (of various skills & talents) that enjoy the same game here. It's the community of thoughts and shared ideas that lead to fantastic results. As much as i'd love proper recognition for anything i create (past & future), it's the natural effect of our modern www and how freedom of association works. The trick is (or was -- already) to be quick (ironically, the release title of my first XC2 mod) enough to hold the major trigger that drives the unknown invisible crowds towards copy/cat attempts that can go both ways; better or worst. Then, i can safely claim the current summit of a few HUD elements (Classes & Ranks colored) for XCom2 -- presently. :wink: I went VERY public with two more major projects (GeoscApps & LAByrinth) in the last few weeks and i'm well aware of the risks. Anyone could plunge straight in similar ideas and beat me to the punch -- that's for sure. Yet -- here i am, staring at online Proofs preciously held in a binary stone monument named Nexus. Scan through it if you must and you'll find plenty of wild stuff signed by a proficient Red Spider member. And that's the point... reality is better than thinking aloud. Soooooo, here's my policy (since you asked) --- DO what you must, as qUIckly as possible! :D And just let the birds sing or flyby while praying they won't eat your lunch. :ninja:

Agreed 200+% with you, TisKwahn. Why was i comin' here for ?! Oh yes. I will soon be in serious needs for a few more custom colors to toggle many "Icons" (ref:LAByrinth) with. Found this precious stuff in burried code files... That's where and how... XC2--Classes::UIUtilities_Colors (COLORS-REFS) ----------------------------------------- // TAKEN FROM Colors.as - keep in sync - sbatista const WHITE_HTML_COLOR = "FFFFFF"; // White const BLACK_HTML_COLOR = "000000"; // Black const NORMAL_HTML_COLOR = "9ACBCB"; // Cyan const FADED_HTML_COLOR = "546F6F"; // Faded Cyan const HILITE_HTML_COLOR = "9ACBCB"; // Cyan const HILITE_TEXT_HTML_COLOR = "000000"; // Black const HEADER_HTML_COLOR = "ACA68A"; // Faded Yellow const DISABLED_HTML_COLOR = "828282"; // Gray const GOOD_HTML_COLOR = "53B45E"; // Green const BAD_HTML_COLOR = "BF1E2E"; // Red const WARNING_HTML_COLOR = "FDCE2B"; // Yellow const PERK_HTML_COLOR = "FEF4CB"; // Perk / Promotion Yellow const CASH_HTML_COLOR = "5CD16C"; // Green const PSIONIC_HTML_COLOR = "B6B3E3"; // Purple const WARNING2_HTML_COLOR = "E69831"; // Orange const ENGINEERING_HTML_COLOR = "F7941E"; // Orange engineering const SCIENCE_HTML_COLOR = "27AAE1"; // Blue science const OBJECTIVEICON_HTML_COLOR = "53B45E"; // background of objective icons on the ability hud ----------------------------------- How do i proceed **CORRECTLY** and objectively, please?

On every Patches/HotFixes/Updates (rare or not) by Firaxis... all of your default**.INI files would be re-written. Upon starting (or Loading saves) your very next gameplay, such newest Defaults would then proceed re-constructing the XCom**.INI structure and files with the latest details as well. BUT -- that doesn't stop there, AFAIC. Here comes the Steam-Launcher and its auto-validation steps to hook each and every MODs you have installed! Guessing where i'm going with this? The data-flow battles are raging for priority calls and instructions that should affect such fresh values directly and transparently. Thus... here comes the various Modders as well. I can already predict a rush phase of obligatory verifications towards every oblivious facts contained in as many custom files (INI included) as there is on the Workshop. (Oh -- the familiarity scans that LW_Betas kept offering to my huge Re-CLR mod and its hack jobs.) :wink: Parenthesis closed. Welcome to the chaotic world on compatibility checks & balances, my friends! Performance issues you say? Imagine the pains on these dreaded updating Day(s)... i'd rather think of it all as a gambling machine where everyone wins eventually. What was the question again? :D 1) ((\\Documents\\Bla-Bla...)) XCOM*** == Modding assets. Dot. EOF. 2) ((Installed XCom2\\Bla...)) DEFAULTS == Local temporary gimmicks & (more importantly) Firaxis official ruleset devices and solidly protected control.

It's VERY confusing and counter-intuitive to say the least. The transfer principle isn't obvious for a simple reason; checking these boxes (X) doesn't offer any feedback proof that the next button click confirmation step would actually switch that content to the custom "Pool" currently in focus -- while we are waiting for the HUD to present us with a new POOL slot. Good idea, bad execution from Firaxis designers.

A tiny QoL adjustment to the Proving Grounds "Completed Projects" drop-down list... http://s21.postimg.org/7jb3x8z13/Proving_Grounds_EXP_Reminders.png Since Cores are soooooo precious, it would help anyone determine if we must start work on another random gamble in categories that need it the most.

Oooookay... this is the current XComClassData.INI file; ------------------------------ ;XComClassData.INI (custom for RCP) [Rookie X2SoldierClassTemplate] IconImage=img:///qUIck_RCP_UILibrary.class_rookie [Ranger X2SoldierClassTemplate] IconImage=img:///qUIck_RCP_UILibrary.class_ranger [sharpshooter X2SoldierClassTemplate] IconImage=img:///qUIck_RCP_UILibrary.class_sharpshooter [Grenadier X2SoldierClassTemplate] IconImage=img:///qUIck_RCP_UILibrary.class_grenadier [specialist X2SoldierClassTemplate] IconImage=img:///qUIck_RCP_UILibrary.class_specialist [PsiOperative X2SoldierClassTemplate] IconImage=img:///qUIck_RCP_UILibrary.class_psiop ---------------------------- If nothing else is needed -- how come none of my custom Rank Icons (same names) show up ingame?! http://s16.postimg.org/eywgfkc11/XC2_Preview_RANKS.png Wrongfully defined "Texture2d" properties, or what? Weird stuff, AFAIC. PS; These textures are just streamed as (A8R8G8B8) instead of the TC_Linear default compressions (loaded in_by UI group) that can have various DXT1-5 settings which AFAIC ruin any images quality (bigger sized.. but should be compatible). BUT that didn't stop Classes from appearing. Still no luck with Ranks.

In step #23 (( http://imgur.com/a/rQ3aJ )), this guy claims any referenced custom Icons packaged in a UPK (located in our Mod\Content folders) can be directly invoqued by the correct instructions written in a properly configured XComClassData.INI file... *IF* the original instance had been pulled (and used as template for any given copies) from the usual default hosting archive UILibrary_Common as valid resources. CLASSES worked as proven by my qUIck_CLR mod uploaded on Steam. But what i'm now after is the RANKS (9 of them). Including this "rank_fieldmarshall" TGA for the Avatar... http://s18.postimg.org/bxlh1yhrp/rank_fieldmarshall.png I've dug into various UC files and discovered this function from UIUtilities_image.UC ... ---------------------------------------------------- simulated static function string GetRankIcon(int iRank, name ClassName) { local string strImageName; if (ClassName == 'PsiOperative') { switch (iRank) { case 0: strImageName = "rank_rookie"; break; case 1: strImageName = "psirank_initiate"; break; case 2: strImageName = "psirank_acolyte"; break; case 3: strImageName = "psirank_adept"; break; case 4: strImageName = "psirank_disciple"; break; case 5: strImageName = "psirank_mystic"; break; case 6: strImageName = "psirank_warlock"; break; case 7: strImageName = "psirank_magus"; break; case 8: strImageName = "rank_fieldmarshall"; break; } } else { switch (iRank) { case 0: strImageName = "rank_rookie"; break; case 1: strImageName = "rank_squaddie"; break; case 2: strImageName = "rank_lieutenant"; break; case 3: strImageName = "rank_sergeant"; break; case 4: strImageName = "rank_captain"; break; case 5: strImageName = "rank_major"; break; case 6: strImageName = "rank_colonel"; break; case 7: strImageName = "rank_commander"; break; case 8: strImageName = "rank_fieldmarshall"; break; } } return "img:///UILibrary_Common." $ strImageName; } ------------------------------------ I think this is *IT*. But, i'm not really sure how to proceed within the constraints of whatever code logic or assuming step #23 mentionned above would allow to actually refer correctly to my custom stuff and then replace the default versions. I guess replacing that red string with this; "" qUIck_RCP_UILibrary. "" should work. Still, how would the XComClassData instructions be able to connect these new Icons?? End-of-my-rope... please help! :smile:

Good news. Then, this whole mystery looks more & more to me like the RefShaderCache-PC-D3D-SM4.upk (same size) somehow gets a clone copy (( starting with the Local prefix in place of Ref )) in the root folder. I'd risk a guess on when & how this accidental UE/ModBuddy transit process occurs == Debug! When the pre-build phase happens, the interactive flow clearly indicates such a file is being accessed while the VCard driver dispatches its settings (NVidia here -- and that one does have a tricky Shader swing). So at run-time, the engine presumes that temporary clone should be dumped as a core asset to the actual ModBuddy structure. Which in turn --of course-- grabs it like a go-happy-clown forever as valid. -duh. At least, you found us a workaround solution. Spread the word? ;)

This might explain how i got my own big file too, btw. I had assumed this was a new Patch/HotFix consequence simply because the timing matched with the exact moment Steam Installed this tricky update. Two flaws could have caused it to appear, then; 1) Double-Clicking directly on the Content\***.UPK file from ModBuddy solution (as an absolutely normal OS reflex, i guess -- we're all conditioned to just use that process) 2) Firing up the editor & wanting to edit that specific file straight into its own external package section (tricky proposition, AFAIC)... cuz, there's no immediate FeedBack proofs that the changes performed are validated ***WITHIN*** the correct string of editing principles that UE3-IDE is conceived to handle. Again, this is a matter of intuitive coding reactions. Meaning -- there are unclear design rules that risk borking up our setups and ruin files structure. Sadly, we don't really have a direct way to intervene or verify... what-where-how something destroys stable work. It's okay for people familiar with UE3... but apprentices like me are bound to fail --not because they aren't skilled-- but on some weird IDE requirements and technical details undocumented by XC2-SDK. I feel Caching is necessary -- sure. Yet this major problem needs to be solved at the source extremely soon by Firaxis. I suspect the Tsunami of unpredictable flaws has yet to reach its inevitable momentum. Workshop flood included. It's very dissapointing nonetheless. :sad: As if i didn't have enough troubles already figuring out how to use custom Rank Icons by means of studying many different source code files; UIUtililies_Image.UC + X2SoldierClassTemplate.UC & XComClassData.INI ... and even more! I promised myself never again to hack my way to textures via TexMod. If nobody can truly help at this point -- well, see ya all around in a few months or years without any rational guarantees of results or even, success. Yeah-right... Listeners. We need Talkers. I'll just go play some more -- maybe that's all i can do.

SpazmoJones... are you there -- yet? :ninja:

Oh yes -- that infamous "Obstruction Trap" that makes the full 3x3 zone invalid in some cases where vertical "Tubes" aren't linked to the roping cycle towards the Skyranger take-off position. I got scooped once by this flaw and promised myself never to be fooled again. Ya know what -- three more times already, i swear my visual acuity was right on the spot... so i thought. Isometric rendering is such a gimmick for most people. The shaderCache 85MBs silly problem? Well, this really seems to be an attempt by Firaxis Devs to solve performance issues on some Video-Cards settings or PC Drivers... honestly, they're shooting straight for diagnostic hints (publicly, no less) with that stuff. Conspiracy aside, it's almost useless and there's an easy way to deal with the temporary situation. Go to the XComGame\MODS folder in the XCom 2 SDK root and simply delete that file ---before--- uploading to Steam. Be warned that each subsequent BUILDS will put it right back in, every-time-we-must-do-our-magic-finishing-steps!! Let's hope they'll fix that messy "principle" soon -- cuz at that rate, the Steam-Workshop (and most people's directories) has been flooded by pseudo -- (or relatively important) -- junk long enough, AFAIC. I'd rather concentrate on CREATING/CODING some mods than worrying about validated file size(s). :D PS; Superb Tutorial, btw. (And... since i'm contemplating a new symbol for the Puck cursors, that precious and detailed info will certainly come in handy -- mucho thanks, Jo.) :wink: PS2; I'm crossing 11 fingers & all toes overhere that this might well be related to (or exploited for...) the theory "Send/All/To" feature we discussed last week! Logic is fun when performed by skilled minds.

The original file is 640x870_PNG and was resized+edited from a snapshot taken from a 1920x1080 full-screen. Right/Click & Save/As the file... and that's what you'll get to process locally (( and zooming in! )) instead of trying to decipher from this web page. The gfx/ScaleForm resource for that menu normally is "based" on various shape/sprites combo-set. I simply added (with PSPro-X3 & Gimp) a few custom XC2 assets to it in order to expose the generic idea only. Eventually you'd be able to grab anything (codewise) from anywhere and re-structure the header "areas" or Buttons however you'd see fit. So to be clear -- i really don't have a hi-res version cuz the game itself doesn't offer any!! :D PS; Key to this attempt is the Engineers + Scientists option(s), btw. Something to discuss later, i gather.

Preferably, these preview JPG's should be square (average 512x512 pixels) to circumvent the (quite ugly) re-sizing filter supplied by Steam-Workshop. This is why i purposely gave my qUIck_RCP mod some 640x640 "Template", in fact.

Yeah well... someone else has been quite active to integrate another kind of static image straight into the game, BTW! http://steamcommunity.com/sharedfiles/filedetails/?id=630693520 See -- it's very easy in this wacky wild world of talented Modders (or intellectually sharp minds) to get beaten to every worthy ideas anyone can suddently have or think about for too long, like what half-a-day or less!! :laugh: Congrats to AlexF -- whomever that (almost) thief is. :D PS; Send me your credentials ... maybe i'll hire you for this stuff.

Bump for a definitive answer to #Q5... cuz, i've just uploaded my first Mod to Steam -- and it's 86Mbs bigger than it really needs to. It takes precious time away from both ends of the community equation. :pinch:

So you can beat me to the punch?! :wink: Good Luck... but, i always reveal my stuff on Nexus for anyone to follow. It's a clear modding principle i've been keeping dearly for years. I will offer much more "Concept" details (as time permits) about this LAByrinth project over the next few weeks. Here's a very generic Tech-Tree image developped last week by Jarcionek for the WiKi that defines the essential reasoning behind having such a structural POV when someone tries to understand the entire gameplay patterns. But this is external. Mine will be available --InGame--. UPDATED!! http://xcom.wikia.com/wiki/File:ResearchTreeDiagramV7.png Another here; https://raw.githubusercontent.com/mstum/xcom2/master/techtree/xcom2techtree4.png Between ideas & projected steps towards realization (or coding, btw) -- there is a definitive rational gap; skills & willingness to put sweat and elbow-grease on the tasks ahead. I can afford most of it (retired and rich enough to sustain a good life) but what matters most for me is that ANYONE with the proper mindset & determination can produce wild Mods for us all. The magic in community access is the dynamo. We are the imaginative gears. Firaxis gave us the blue-prints for some great wizardy results. Proof is Steam-Workshop as it stands presently. Let's go... don't wait. DO **IT** NOW. :smile: