Zyxpsilon

Well -- that simply means we can actually get these old files to compare stuff. I just created a temporary "Default Mod" and the whole 1927 files (from Feb-3rd) were indeed all there. Copy/Paste.. done! Now onto some analysis steps for specific tricky changes that may explain a few important development steps. Indirectly, thanks. ;)

From Line #8321 of XComGame.INT ;[X2StrategyElement_TFTDWorldRegions] ;AtlanticOceanDisplayName="Atlantic Ocean" Either they had plans to introduce another "Fortress" feature or that specific strategy element still has some form of active status for future DLC. (( Shen's Gift, maybe?! ))

Enough of a clear answer for me (seems RampUp fiddling might be worth another try), wGhost! Sorry (again) for getting OT... but i really thought some UC changes might have been rolled-in into AH that would affect any Camera (indirect) settings. Thus, it just felt like wGhost should be the right person to ask for some precisions -- if she had (already) explored the relevant script files - that is. :)

See, this is exactly the kind of acute details & principles that only super-coders (like you) can grasp enough to give some rational powers over any serious attempts at making gimmicky solutions worth inclusion in whatever Mods. In theory (from a long gone past of Cobol school times for me), the inherent difficulties with compiled resources is that THEIR "static" design can only go thus far within conceptual customization. We can only strike at available code structures (++) and nothing else. The good lessons to get from XC2 (scripts & all) is that certain features aren't really obvious to the "common man" and that even Unreal Engine also has its own specific methods (which are again adapted to Firaxis plans), IMO. Hacky Class Overrides included! ;)

Hey wGhost81, Small question about FreeCamera.. Is it "still" possible to adapt the Zoom-In/Out component with some pure (value) steps via the normal Key-Bindings (T/G)? I've been trying to edit the current Interpolation configs (below) and the actual ingame results aren't matched with the "Pseudo-Degrees" system used by Rotation. XComCamera.ini ... RotationInterpolationRampUpDuration=0.40 ZoomInterpolationRampUpDuration=0.40 MaximumInterpolationRotationPerSecond=180 MaximumInterpolationZoomPerSecond=0.25 ZoomedDistanceFromCursor=4000 DistanceFromCursor=1256 XComTacticalInput.ini ... CAMERA_ROTATION_FIXED=15.0f CAMERA_ROTATION_SPEED=180.0f CAMERA_ZOOM_SPEED=0.25f bAnalogMode=false MIN_ZOOM_MULT=-0.30f Presently, I just click your Ctrl-F2 trick to activate Analog-Mode and i certainly get an approximative Zoom stepping process... but (IIRC), you already mentionned to me that XC2 handles these Camera instructions differently that XC1. If the latest patch hasn't offered us new "code functions" to adapt the Zoom(s), i guess we must stick with the Interpolations system, right?

Well-- here's the latest on my MCController and the missing Rank-Icons adventure... they're all back right as they should! :D I am utterly baffled by this weird code/or/gameplay event. But, i might have a wicked explanation at least. My first thought was that a caching process finally triggered on what needed runtime updates... silly me. From instinct, that seemed like the most logical cause. Yet, i've recalled every step i had been taking since this morning Launch. -- Trying to reactivate whichever MODs i felt would most likely be compatible as is. So in order to be thorough, ModOptions.INI before AH; ---------------------------------- [Engine.XComModOptions] X) ActiveMods=FullCharacterCustomizationFromStart (simply edited the necessary INI line with "Veteran=0"... and finally could unsubscribe) 6) ActiveMods=ConfigurableMissionTimers 6) ActiveMods=FreeCameraRotation 5-- ActiveMods=Upcomingeventsinhours 5-- ActiveMods=MissionTimeRemaining 5-- ActiveMods=DiverseFacepaints 4-- ActiveMods=Morearmorcolors 4-- ActiveMods=Moreskincolors 4-- ActiveMods=NewHairmod 3-- ActiveMods=AmmoandVestSlotsV2 (Check out my custom Ammo+Vest Hud Icons in it :wink: ... first mod to be updated, btw) 2-- ActiveMods=LWS_OfficerPack (was updated by LWS ealier this afternoon) ------------------- 7) ActiveMods=EvacAll (QoL by TrackTwo) 7) ActiveMods=UpgradeReminder (QoL by TT) 7) ActiveMods=BlackmarketUsage (QoL.. informed decisions when you Buy/Sell) 7) ActiveMods=MoreSquadSizeUpgrades (5-6.. then, 7-8 with this for a balanced cost .. or Toolbox's 12 .. you do the maths) :ninja: ** Not sure yet if IT is completely validated though because it touches some UISquadSelect functions which AH altered since that mod was created in February. ------------------- 8 ) ActiveMods=LifetimeStats (Works perfectly fine as is) 8 ) ActiveMods=AdvancedBallisticsandMaterials (essential for #3 above... yet, it doesn't apply the intended upgrade variety of multiple Ammos or Vests.) 0... ) ActiveMods=Uniforms (THE mod!!) Still not updated... may take awhile before i even risk. 8 ) ActiveMods=LWS_AlienPack (Ok! Three new Rulers or a single Muton Centurion - i just dunno if i will re-install that one) 8 ) ActiveMods=LWS_SMGPack (Ok! Have yet to use any.. might not re-install again) ------------------- 9 ) ActiveMods=SWRHiddenPotential (Just updated this morning by its author, seems to be okay) 9 ) ActiveMods=SWRNotCreatedEqual ( " " " ) 9 ) ActiveMods=CostBasedAbilityColors (Works, but there's been recent reports another mod "Perfect Information" somehow breaks it) 9 ) ActiveMods=ShowMeTheSkills (ABSOLUTE must , AFAIC) What a relief.. this one is validated!! 9 ) ActiveMods=ShowMeThePersonel (Another essential QoL) That too!!! I can now safely use my custom darkened background for UI clarity. ------------------- 10) ActiveMods=CapnbubsAccessoriesPack (Graphics array heavy burden but it's soooo cool.. even if NOW i absolutely love the newest AH_elmets) 10) ActiveMods=ProgressiveArmorOptions (Kevlar is slightly more persistent -- just as much as i wish for) 10) ActiveMods=ProgressiveArmorResistanceOptions (That much variety is sooo cool to have when creating special Characters) 10) ActiveMods=ProgressiveArmorLessAnarchy (Bare skins of anything -- that's plain silly IMO) 11) ActiveMods=MrKXCom1Stuffs (Solid porting of every EU/EW Kelmets.. Just saw a video about his Tier_2+3 Armors.. might as well install these in too) 11) ActiveMods=CovertOpsArmor (Nice gameplay touch of alternate Armor conditions that reminds of FiLP & Shaoji Zhang from EU) 11) ActiveMods=DarthMaulMod (One single Face paint and you're in Star Wars territory) ------------------- ----In the XCom2\Mods folder---- X) ActiveMods=AllArmorOptions (Zero-Trick by wGhost.. It's some trailing old stuff kept there for posterity about my early days silly choices!) 1-- ActiveMods=qUIck_FLG 1-- ActiveMods=qUIck_FP2 1-- ActiveMods=qUIck_FP3 1-- ActiveMods=qUIck_FP4 1-- ActiveMods=qUIck_FP5 1-- ActiveMods=qUIck_RCP ------------------------------ With the exact order of the current activation steps taken so far. Smooth, no bad gameplay effects .. #1 to #9 seem to be fine. (...) remains, but they can wait until they are verified by their authors. Secondly, as i was perusing the Workshop posts, i came upon a comment that mentionned how deleting all "+ModClassOverrides=" entries from XComEngine.INI had solved some compatibility problems for that person. And i believe this is probably what re-activated the RCP process; Among about 12 lines, this wacky instruction was there too... ModClassOverrides=(BaseGameClass="UIMCController", ModClass="UIMCController_qUIckRG4") I think that's what gave me back my colored Icons. Yppie! :wink: PS; I will keep adding each of the above remaining Mods (#) until i can confirm they actually work as is or that they have been updated "correctly". PS-Last; Took awhile to verify everything but the only pending Mod is "Uniforms Manager" as of 26/05. Two full weeks of risky testing.

@abeclancy, Haven't tried anything new yet for that stuff. I'm still open to whatever suggestions. Dealing with Templates (directly) seems to be a good solution on first thought.. but these Rank Icons are --everywhere-- which made that MCController method sooooo appealing. I think InfectedM should be a good source of help in that specific case. Aren't Localization files highly varied? From English (INT) to many more? I don't want to be stuck in multiple support pipelines if i can. The point with that UIUtilities_Image function is that it's centralized enough that a lot of external modifications can simply connect to the loop without further needs like -- Listeners. Trouble is -- codewise, i somehow lack the minimal skills to find the correct ways to do so. :sick:

Gotcha.. it's a rational technical hurdle which has more obstacles to "adaptative" solutions than meets the un-informed eyes like mine. I guess, the only other way to maintain compatible Mods directed (in particular) to SquadSelect duties falls on the shoulders of whomever has already tackled extensive variations of these HUD assets (ShowMeTheSkills by ²²², being just one essential i enjoy having). When it comes to overrides.. i'm at a lost for precisions while the mystery of magic phrases used by many people to qualify their own mods (( NO overrides have been used! )) pushes that reasonable frustration even further more. Oh well. If only i had 25 years less on the counter -- i could possibly start learning HOW to properly code my ideas.

Be darned! UIUtilities_Image.uc has been given a weird update to a core function... simulated static function string GetRankIcon(int iRank, name ClassName) { local X2SoldierClassTemplate ClassTemplate; local string strImageName; ClassTemplate = class'X2SoldierClassTemplateManager'.static.GetSoldierClassTemplateManager().FindSoldierClassTemplate(ClassName); if (ClassTemplate != none && ClassTemplate.RankIcons.Length > 0) { strImageName = ClassTemplate.RankIcons[iRank]; } else { switch (iRank) { case 0: strImageName = "UILibrary_Common.rank_rookie"; break; case 1: strImageName = "UILibrary_Common.rank_squaddie"; break; case 2: strImageName = "UILibrary_Common.rank_lieutenant"; break; case 3: strImageName = "UILibrary_Common.rank_sergeant"; break; case 4: strImageName = "UILibrary_Common.rank_captain"; break; case 5: strImageName = "UILibrary_Common.rank_major"; break; case 6: strImageName = "UILibrary_Common.rank_colonel"; break; case 7: strImageName = "UILibrary_Common.rank_commander"; break; case 8: strImageName = "UILibrary_Common.rank_fieldmarshall"; break; } } return "img:///" $ strImageName; } Unfortunately, this means my qUIck_RCP trick (via MCController) to re-color the Ranks simultaneously in multiple screens (instead of building up a gauntlet of UIListerners) no longer works. What does anyone make of this? Is it really "necessary" and if so, how would someone alter the following script to bring back its formal functionality?? class UIMCController_qUIckRG4 extends UIMCController; simulated function QueueString(string Param) { Param = Repl(Param, "img:///UILibrary_StrategyImages.GTS.", "img:///qUIck_GTS4_UILibrary.GTS."); Param = Repl(Param, "img:///UILibrary_Common.rank_", "img:///qUIck_RCP_UILibrary.rank_"); Param = Repl(Param, "img:///UILibrary_Common.psirank_", "img:///qUIck_RCP_UILibrary.psirank_"); super.QueueString(Param); } Not really asking for a fix to *MY* own stuff... but, it's a very strange design switch, AFAIC.

Wow... XC2 = 1.7GB & SDK = 2.1GB worth of new files. That latest Launch-Trailer really is perfecto video stuff, AFAIC. The Vipers cavern entrance with Bradford looking in has this wild cinematic feel. I think i'm gonna enjoy these three new gameplay conditions as they are more in-line with the Guerilla Warfare basic concept(s) of the original. Anarchy was a fun aesthetic set of cool addons but Hunters crosses the path of tough'er TBS mechanics while stacking the odds above the Tactical Layer like a coat of burning acid flow! Should be crazily fun to play with..

Sorry for Hi-Jacking the LWS-Toolbox thread, JL... this patch "switcharoo" for AH-DLC activation has everyone (modders) on the edge of their seats! :wink: Back OT.. any plans on a more "modular" Toolbox, btw. For example, there are some gameplay features "changes" (12 Men Squads being the major aspect that actually broke other LoadOut mods, at least in principles) along with the core Mod-Options + Tuple context that (IMHO) should be somehow isolated from each other.

I feel one simple good advice is for Modders to not try upgrading their stuff (while the update feed is happening) without a clear & stable installation structure. When a patch with such extensive changes is "processing" & "verifying" the whole game (at least once, as recommended by Firaxis, btw), there's a very high risk of corrupted "Cache resources". And thus, please follow these minimal steps; 1) Once download is fully completed, Exit Steam 2) Log again.. you might receive a popup stating that XCom2 is being processed. 3) Before playing.. empty (as in - deactivation of the "Boxes") your entire list of active MODS (even the referenced Locals in XCom2) from whatever Launcher you use 4) Start a fresh gameplay 5) Play at least one entire "Gate Crasher" mission and visit the Geoscape 5a) I'd suggest to keep the freshly made Saves for future reference 6) Exit everything once more!! Done... ready & solid. :D

Well... on the evening before the official release of Alien-Hunters DLC, i think it might be a good idea to revive this old "request" thread as i feel there are still probable solutions in some 3D experts' minds. Every time i see those cool Anarchy armors with their "Flashy Lines" decorations tied directly with the secondary color(s) -- i certainly wish (again) some wild custom code could be designed to enforce the Powered-Armors tier to use that extremely cool feature too. Crisp cyan was fun at first but now that some OTHER cool special armors are planned to invade our gameplay experience from Rulers' looting -- i'd say, WE really should get an hybrid Anarchy/Powered customization for those material effects. Via Mod or even, definitely patched by Firaxis if need be. Soooooooo -- any serious takers for that task?

Hey -- did Abeclancy actually made that Git-Repository transfer of the OrigSRC Class-Files from the Feb 5th initial release??

Hold on -- **WE** will be able to determine the whole "ChangeLog" business once we examine the exact release content, aren't we? I'd say .. after the compatibility rush fixes of most actively supported mods out there (which might take days or weeks in some cases), i have to predict that the essentials will be well known by then. Anyhow, being in a community of Modders certainly has some advantages when teamwork should be necessary to figure out the newest stuff & gimmicks that Alien-Hunters will introduce.

Shoootttsss -- i'm not alone wishing i still had kept any such files in a safe place for later use. Oh-well.. if we ever get lucky, some day. Alien-Hunters DLC soon, and i **DO** have proper safety backups -- now. ;)

David, speaking of OrigSRC Class files... do you still have the whole (Feb-5th) release folder? I normally keep tracking these updates but lost the initial set from a weird drive copy/paste that didn't actually backup those (1930+) on my external 500G USB! Arrggghh. In fact -- there should be about 150 files missing, since the first Patch on March-10th only changed these. On March-17th, DLC0 (Anarchy) replaced 29 more, btw.

Well, there are some particularily interesting (or important) stuff in many UC scripts that seem to indicate a bunch of other features weren't actually finished. Sure --TODO-- doesn't imply Firaxis DEVs will or would try to continue a few "Todo" tasks... but i find it extremely funny to realize cool options were left hanging in the Twilight Zone. Here's a quick example (by which this post was triggered, btw) !... From UITacticalHUD_SoldierInfoTooltip.uc. I was just trying to figure if the Mobility Stat could be inserted in that ToolTip. I soon realized the actual enum for it isn't defined in the necessary structure. We get what is there.. that is all. Unless, some genius could find another way. Anyhow, here's that comment; simulated function array<UISummary_ItemStat> GetSoldierStats( XComGameState_Unit kGameStateUnit ) { local array<UISummary_ItemStat> Stats; local UISummary_ItemStat Item; local EUISummary_UnitStats Summary; Summary = kGameStateUnit.GetUISummary_UnitStats(); Item.Label = class'XLocalizedData'.default.HealthLabel; Item.Value = Summary.CurrentHP $"/" $Summary.MaxHP; //TODO: Colorize when below a threshold Stats.AddItem(Item); ...Soooo... Thresholds in colors! Kinda sounds cool, don't you think? :)

Got a new favorite -- more cynical than a real comment, IMHO; // TODO: ... (( just about anything! )) Now, that they are getting ready to issue two more (summer) DLC and the extra great features they'll offer to us... i have to wonder if the DEVs have any serious intention to re-visit these code areas to finish up the planned fixes. :D

BestStartingRegions factor is certainly near enough to what could cause the RNG impression i get from rare occurances of other smaller (less regions) continents -- indeed. Having a special condition of TWO regions from different continents at a minimum is indicative of such tricky setups as well. Sooo, it's no wonder getting a NewChile or NewAustralia starts (for example) is almost impossible. Thanks.

Refer to this small excerpt from that file... ------------------------------- PossibleStartingRegions="WorldRegion_EastNA" PossibleStartingRegions="WorldRegion_WestNA" PossibleStartingRegions="WorldRegion_SouthNA" PossibleStartingRegions="WorldRegion_NorthAF" PossibleStartingRegions="WorldRegion_EastAF" PossibleStartingRegions="WorldRegion_SouthAF" PossibleStartingRegions="WorldRegion_EastAS" PossibleStartingRegions="WorldRegion_WestAS" PossibleStartingRegions="WorldRegion_NorthAS" PossibleStartingRegions="WorldRegion_SouthAS" PossibleStartingRegions="WorldRegion_WestEU" PossibleStartingRegions="WorldRegion_EastEU" PossibleStartingRegions="WorldRegion_NorthSA" PossibleStartingRegions="WorldRegion_SouthSA" PossibleStartingRegions="WorldRegion_NorthOC" PossibleStartingRegions="WorldRegion_SouthOC" ------------------------------- I've been totally baffled by the lack of (complete) diversity for our random starting Locations. So i went into the INI file to add the last six entries above which were somehow absent from the Vanilla version. Yet, when every game starts -- i still mostly get the usual NA or AS or AF regions only. Is the RNG toying with my mind or is there a particular code function that prevents any of these six others to be selected but that i can still remember seeing at least once in Legendary difficulty level starts? Anyone knows the facts about this specific gameplay rule or where in a UC script that sort of restriction is defined?

Thanks for the heads-up Amineri. This is the kind of technical explanation that InfectedM could certainly seek his teeth into and possibly exploit much better than i would. The need for the above version was dictated by having two different pathways to individual "groups" of images; Rank-Icons & GTS-Upgrades --- in the same MOD structure and files (qUIck_RCP). InfectedM made it clear that only one custom MCController trick can be used within *A* mod. Makes senses and i also presumed the exclusivity trick you are referring to. To me, the essential stands in a single reason; as long as it does what my mod(s) require, it's good and fairplay unless proven unstable or tragically incompatible with too many other modding situations by community stuff. I'd certainly be willing to absorb and comply with some optimal code alternative (like what you're suggesting). Trick is.. it would probably prove to be too challenging for my skillset (UC programming, etc). Sooooo.. if "Interception" methods are too risky -- we'll have to find better ways, that's a given. Yet, the current state of the mod -- works fine! Unless InfectedM (( Nexus member=mbleichner )) can come up with some code that follows up on your theory (and would still.. work fine), i'll just be happy to bend over to such best programming principles.

Well.. if the upcoming summer DLC truly is what it's supposed (or described as teasers) to be, i seriously believe that's exactly what their goal is. Quoting the official publicity-stunts text; 1) ALIEN HUNTERS introduces new soldier customizations and gameplay themed around XCOM as an elite alien hunting unit. Face off against “Ruler” aliens with new, more powerful weapons and armor. Experience a new dramatic mission & confrontation. (( PS; Judging from the already revealed set of Steam-Achievements for it --- Archon + Viper + Berserker are in, and i suspect more are LWS'ly & timely coming our ways too! )) 2) SHEN’S LAST GIFT introduces a new soldier class with unique upgradeable weapons, armor and customization features, and a new narrative-driven mission and map. Thus... the whole basic (most probably complex and/or somehow minimally developped to fit the current gameplay flow -- as mentionned in my previous post) framework for what's being discussed here, IMO.

David, your very own "Hostile Territory" mod is a very good start for a cool concept that would involve an "Exalt" style of storyline pathway(s).. aside for many other design steps of various consequences. Which brings me to -- 1) A major concern when someone aims to add Missions variety (( of reasonable qualities!! )) is gameplay Balance. It's quite tricky to discover the fine-tuning times (in terms of Calendar cycle) necessary to properly integrate any amounts of additional "features" while considering how & when certain storyline hurdles should (or must) occur. For example, we know when or why the Psi-Gate shows up -- it's tied with a Shadow-Chamber discovery!! This system of "checks & go" principle is exactly what can make or break a stable (enough) flow of events. Soooooo, my recommendation is simple -- try hard to maintain a cohesive pattern that could.. 1a) Enhance the current Vanilla structure beyond the familiar patterns --BUT-- do so in some isolated bubble of "alternate Stories" with their own Goals & Requirements. Sic--extract the Operatives for reasons that develop dynamically inside a group of special missions. 1b) Offer everyone a juicy SciFi novelty where a number of brand new factors supplement the #1a structure too -- BUT-- in a tighter balance that should self-adapt to a stable flow without stalling everything else we're expecting from the rest of the regular storyline(s). THAT's the tricky part, AFAIC. It requires a lot of careful thoughts & strict planning. Trust me .. you really don't want to ruin the gameplay experience just because it's cool to play with new toys. It's very easy to throw a wrench into such TBS titles. If you want a proof -- take a straight up and honest logical stab at these mods that add new Dark-Events. 2) The fun part goes like this; people would or could enjoy anything as long as it all fits a clear design "product". You want Star Trek or Star Wars lore? You could find hundreds of worthy ideas in those SciFi legends. Yet, the rational objective remains to improve storyline stuff, right? Then -- 2a) Pick ONE essential device and stir it up in a soup-bowl to its inherent limits. Think of it like the "Rover must go through the PsiGate to find some facts" principle, which leads to this, and then to that. The player has been hooked to an intellectual pattern of relative strength simply because *WE* are humans and *we* still need emotional snippets in our lives. Death Star space dog-fight of giga-proportions to the rescue. *WE* are consumed by the stakes and are enjoying the suspense. XCom2 has the very same parametric components.. Firaxis dumped a mysterious Avatar_In_A_Stasis_Suit device. And it worked!! 2b) Missions are the muscular trajectory that HAS to lead to a proper conclusion. Here we go again... Balance! You'd be better served by a slow but steady flow of details that offer intrigue qualities and still, pushes the player to the gates of Heaven or Hell. *WE* want that push.. but not unless it is somehow intelligently waved into the current storyline patterns. Here's where i should mention something weird, i think; Ya know those missions where we must pick "data info" from devices in trains & Advent facilities? What's the point? Okay, i just got some SCiFi genetic secrets off that battle... what can it bring to the table of gameplay features? Presently, nothing. That's the kind of potential structural integration in a new system of Missions. You'd add worthy details to the storyline rather than presenting the strings on the HUD for readouts -- only! Build a new game feature, Yes. But... grab a pencil and draw a thoughtfull blueprint of YOUR systems & elements while you have that opportunity to create a good concept. Bigger YES. You'll need much more than luck. So i won't wish it. :wink:

1) You mean like "Model textures".. not sure how these are handled by the tactical Engine but if they all have a proper referencing pattern that can point at a steady path and the MC process can still control both the default-file & whatever else is being invoked in its place, i think it might work. The core UIMCController UC_script has a few more types of instructions that can deal with different assets although there isn't any simple ways to verify if the data flow (for Models or other stuff) would somehow react as intended. 2) Dunno yet.. but i suspect that if some indirect MOD generic component is created to stand as a placeholder for various HUD-UI elements (basicly the newest LWS-Toolbox principles and/or with Tuple's transit values structure). That impervious solution might still need to be designed though.. as we all know, a common device with upwards compatibilty features would become essential in the long-term. Again, Batista (or RyanMcFall) would be much more trustworthy of positive facts than i could ever decipher in their coded intentions. The trick here i guess... is to convince people like Amineri or TrackTwo to extrapolate furthermore on the real (rational) potential of this wacky stuff. That takes minimal skills which i just don't have, sorry. I can still smell the burning magic oven that tiny code would trigger though. :wink: