Jump to content

JDDysart

Members
  • Posts

    58
  • Joined

  • Last visited

Everything posted by JDDysart

  1. Hello xkopofil, My apologies in taking so long to reply. When I first came onto the EU modding scene most mod makers were overly involved with mods for "Long War", which I had no real interest in, but these mods do delve into just about all the interesting parts of the game. To handle the number of units taken on a mission might I suggest - With ini loading enabled, the DefaultGameCore.ini file contains three (3) relevant lines:NUM_STARTING_SOLDIERS=12BARRACKS_CAPACITY=99SKYRANGER_CAPACITY = 4notes:These lines are usually maintained in any save files, requiring a new game be started to see the effect(s).The units shown (in the hanger) are: up to the first five (5) auto-selected units and the last auto-selected unit.I recommend that you maintain: SKYRANGER_CAPACITY <= NUM_STARTING_SOLDIERS < BARRACKS_CAPACITY. When otherwise unmodded, the game will add any OTS Squad bonuses to the SKYRANGER_CAPACITY and (when enough units are available) take that number of units on a mission. To handle the spawning issue (with EU) might I suggest - Where the DefaultGameCore.ini is located, there is also a DefaultInput.ini file, at the bottom of which I have included the following: [Engine.PlayerInput] .Bindings=(Name="S", Command="exec SHQResources.txt", Control=True) [XComGame.XComTacticalInput] .Bindings=(Name="T", Command="exec TSquadUnit.txt", Control=True)placing these lines at the bottom of the DefaultInput.ini file will override any other bindings to THESE KEYS.the SHQResources.txt file contains lines such as GiveResource Scientist 5, GiveResource Engineers 10 and ;GiveItem WeaponFragment 250, (the semi-colon makes the rest of the line a comment);the TSquadUnit.txt file contains the TeleportToCursor command, among other console commands (such as ReloadAmmo and ResetUnitMovement); For the more or less vanilla versions of EU there appear to only be two issues:the UI functions for selecting which units to take on a particular mission;and the "spawning" function on the maps.My first thoughts - Adding more units to the "spawning" function should be easy enough, however the original code included a six unit limit which will need to be modded. But the big block, at least to me, is the UI coding for selecting a squad - which will probably far exceed my poor graphic abilities; IMO not really worth doing, unless you can actually select which units to take! My work around currently is to keep the SKYRANGER_CAPACITY equal to the number of units in the barracks, and use the TeleportToCursor function (as suggested above) to retrieve any "out of bounds" units. Edit: I am currently reviewing this thread to see what I might have forgotten. Seems that the R&D started with EU (Enemy Unknown) before more recent Official Patches were released, and at some point transitioned to EW (Enemy Within) - with some Longwar revisions thrown into the mix. Not to mention the use of some fairly early versions of certain modding tools. Once I have enough of this clear in my own mind I expect to have at least a current status report to post ...
  2. While on a mission, have you tried the console command "GiveAbilityCharges"? In tactical mode, said console command will super charge each ability that the current unit has; to like 10 to the 3rd (or 4th) power, in charges. Of course all charges are dropped at the end of a mission, and re-loaded at default values at the beginning of a mission. Should someone want to actually write a mod that allows more control over the number of charges and/or specifying a single ability, said console command should give you a good start on what is needed.
  3. These tools (both vanilla and WotC) should (for those that purchased XCOM 2 & the WotC DLC from Steam) still be in Steam Tools: XCOM 2 Development Tools XCOM 2 War of the Chosen Development Tools [full content requires authorization (i.e. opt-in) via "beta" tab in properties window] Both of the above, by default, install into ...SDK folders. Please explore the nexus XCOM 2 wiki for more information.
  4. Personally, I do not know just what the "codex" that you refer to is, but in regards to the more official general XCOM 2 : There is a preliminary list of interesting locations for the Directory Structure that XCOM installs into on the XCom2-Wiki. Both of the article templates have these "interesting locations" included (as an example); a more comprehensive list of locations is in the works (mixed in with other wiki articles that I am working on). You might check to see if your directory structure conforms to what is shown on the referenced wiki ... as a starting point (for finding potential mistakes).
  5. The Developers, in producing War of the Chosen, made a few (relatively) large changes and several (relatively) small tweaks to the "vanilla" source code ... For most (those that don't conflict with changes/tweaks) "add-on" mods should (other than lacking a WotC "stamp") still work? For any modification to the "vanilla" source (especially those that conflict with changes/tweaks) will put one back to getting the SDK and doing a (more or less) major re-write of the entire mod. Regardless - due to directory-tree-locations - those that made tedious small manual changes to the "vanilla" files are going to need to go back and make all of those tedious small manual changes to another (the new WotC) set of files!
  6. Already in-game is a buildable room that will train rookies to a particular (you choose) squaddie "class". There is also a console command (see various CheatManagers for source code), MakeSoldierAClass "Joe Doe" Grenadier while aboard the HQ ship, that allows for dynamic in-game changing of a soldier's "class"; while SPARK may be used (in place of Grenadier) this is NOT recommended!
  7. What the OP (back in 2014) was asking for was basically a re-skinning of existing armors - which, in the OP case might(?) be accomplished by assigning existing skins-art-work in place of existing armor-skins-art-work in the DefaultLoadout.ini; basically replacing the values on the "iArmor" parameters. Personally, I am not sure how well this would have worked ... Also see: "ArmorDeco" lines in DefaultContent.ini - for how the developers re-skinned armors.
  8. In case you have not already noticed (and as you have asked?) email addresses are masked on these forums; proper contact - when a simple forum reply is not enough - should be a PM address, such as: Your (Spruence) PM address is https://forums.nexusmods.com/index.php?app=members&module=messaging&section=send&do=form&fromMemberID=53239586 ... My PM address is JDDysart ... Viewing another's profile should also provide an option ("Send me a message" button) to send a message to the owner of that profile ...
  9. Please be advised that my knowledge of LongWar is limited to knowing that it started out as a player developed mod on par with Enemy Within or War of the Chosen ... With the above disclaimer taken into account ... generally class restrictions are implemented via configurable options in INI files; more commonly found on Primary and Secondary Weapons (and less commonly -if ever- found on armors, grenades and utility items). So you might want to see if you can find something similar that is already class-restricted - to compare to what you are attempting to do?
  10. Back to basics ... First on the 3 small item slots? Are you wanting to add slots to a particular armor? or be able to see lower slots (on the load-out screen) after you have added slots to a particular armor? To add slots - use PatcherGUI to enable INI loading - then change the Armor line(s) in the DefaultGameCore.ini file. To see lower slots - when you add too many? - you will need an actual mod to do this. Then on to modding basics ... Have you reviewed what is available on the XCom Wiki? in particular have you seen the "Hex values XCOM Modding" article? Do you have access to the UE Explorer ("Unreal Engine" Explorer)? UPK files are "Unreal Package" files ... similar to DLL files (if you have any experience with them?) ... this is a collection of what programmers refer to as "object code modules", with several of these packed into each UPK file. Similar to ZIP files - UPK file contents may be uncompressed, (partially compressed?) or fully compressed. UE Explorer won't work with FULLY COMPRESSED UPK files; but PatcherGUI (or actually PatchUPK) checks for compression state then deals with what it finds. PatcherGUI, which you should know - if you have read the ReadMe.txt files that come with it, replaces the need to manually "hex edit" UPK files ... PatcherGUI does such editing for you! based on the pseudo-coded contents of a text file. The general modding procedure is to use UE Explorer to find the function (or whatever) that you want to modify (and to get some ideas on what you want to modify whatever to); ... then either copy mixed code from UE Explorer or use HexToPseudoCode (from the UPKUtils toolkit) to get the before code; ... once you have the before code - you then have to "MODIFY" it (based on what you are wanting to do) to get the after code; ... finally you put the before code and after code together in a PatcherGUI text file and attempt to apply it to the UPK file of your choice. And if the mod you are making is not for JUST your personal use, then it needs to be extensively tested before you publish it. BUT PatcherGUI does have some paths that must be properly set before it will work; one of these is the "Backup path". From personal experience, I know that the 0F 00 in your example is a length value, in pseudo-code you might use [@] where you want a length value, followed by "(" & ")" around what you are wanting the length of. The 1D Is an "Unreal Token" specifying that an unsigned-32-bit-integer value follows (the %u in your example, with a value of 10000000 being replaced with a value of 99999). What is actually happening in your example is that PatcherGUI is setting the RelativeOffset to where it finds that particular string of code within OBJECT=XGTacticalGameCore.GetXPRequired, then placing the modded code value at that relative offset, while updating the memory and serial sizes as needed for <iXPRequired>. A good place to start learning might be to get the entire mixed code (hex & pseudo) from HexToPseudoCode of XGTacticalgameCore.GetXPRequired (from the XComGame.upk file), and place all of it in a [bEFORE_CODE] ... [/bEFORE_CODE] section. Then find the code string that is being altered and see if you can write the [AFTER_CODE] .. [/AFTER_CODE] section? Clue: for this mod you need to make sure that the before code and after code both start with same code and both stop with the same code (and the UPK_FILE= and OBJECT= lines go above the before code section). Caution: if you have the Display Soldier's XP, PsiXP & Mobility mod already installed - then the mod you are writing may conflict with it! Hopefully something above helps, ~ JDDysart
  11. I am glad to hear that you have your mod loading without errors now. Still, being the curious type, I have noted several changes: ARC_Helmet_BlacklightGhost_M in >ArchetypeName="AamaxuMod_Assets.Archetypes.ARC_Helmet_BlacklightGhost_M"< .Archetypes. (context) in >ArchetypeName="AamaxuMod_Assets.Archetypes.ARC_Helmet_BlacklightGhost_M"< AamaxuMod_Assets in >ArchetypeName="AamaxuMod_Assets.Archetypes.ARC_Helmet_BlacklightGhost_M"< which you did mention and TemplateName="Helmet_BlacklightGhost_M"I suspect that all of the above factor into your mod now appearing in the game without errors; ... while I am left to wonder if AamaxuMod_Assets could be something closer to Helmet_BlacklightGhost and still work? But this last is just my overactive curiosity at work and definitely NOT your problem. Please have a great modding future, ~ JDDysart
  12. Referring to the DefaultContent.ini (for current naming conventions) your ArchetypeName="BlacklightHelmets.ARC_Ghost_F" should probably be ArchetypeName="Helmet_Blacklight_Ghost.ARC_Ghost_F" (or maybe ArchetypeName="Helmet_Blacklight_Ghost_F.ARC_Ghost_F"). Which would mean your TemplateName="Blacklight_Ghost_F" should be TemplateName="Helmet_Blacklight_Ghost_F". I am thinking that Ghost is one style (of several) that Blacklight Helmets may have. If you are NOT using an existing (already in the game) "ARC_Ghost_F" 'as-is' then I would recommend that you use the name "ARC_Blacklight_Ghost_F" on the one you are creating. So, if I have this correct, ArchtypeName="<TemplateName>.ARC_<associatedArchtype>" ? Now, I'm guessing here, do you know if the BodyPartTemplateConfig is creating the Template it is configuring? or do you maybe need to create said template before you can configure it? Seems you might still be missing a file - the one containing the code that does a CreateTemplate() for the appropriate type of template? ... say maybe an X2BodyTypeTemplate ? Missing file, if you need it, should be one of these two: I had thought I mentioned a "missing file" earlier ... but if I failed to (or you failed to notice when I did) ... it must be time for me to make another attempt to bring this to your attention. If the other mods that you are modeling yours on don't show how to create the proper template - then you might want to take another look at ExampleWeapon (in ModBuddy) to see if you can work out how to create said proper template? You will probably want something other than a WeaponTemplate ... say maybe an X2BodyTypeTemplate (as defined in X2BodyTypeTemplate.uc) ? Please note that said file must be listed on an include line in the file that specifies which files & folders to include. ~ JDDysart
  13. If - by any chance - you have not already seen X2DownloadableContentInfo.uc (can be found in "<InstallFolder>\Development\Src\XComGame\Classes\"), then you may want to review this file for ideas on what the loading possibilities are for a mod? Does explain, in part, why I tend to be so concerned with folder names. Might be nice if someone could be found to do a wiki article on this file?
  14. Okay folks, I think I have it ... "there is no longer any real interest?" (or no one can find the "XCOM 2 | XCOM2-WarOfTheChosen" wiki pages?) So, lacking any feedback, I guess I will just plod along as the mood moves me? I did add some templates today: Template:Mods XCOM2 & Template:Modding Subject XCOM2 to assist those willing to contribute to this wiki. If anyone would care to leave feedback (or wonder of wonders want assistance with the above linked wiki): I will be checking for new posts to this topic? or you might try sending me a PM?
  15. Shameless bump :sleep: Okay, there is a very small Wiki for "XCom 2" and "XCom2: War of the Chosen" started at Wiki-Link !! Should someone with the proper authorities care to place a link to it on the Main XCom2 Forums Page, like there is for XCOM:EU on the XCOM Forums Page, maybe wiki-contributors might be able to find it? ~ JDDysart
  16. First on zip files, the two most commonly used unzip options are "Unzip to here" & "Unzip to <"filename.zip"-converted-to-"folder-name">", and preferring not to have the zip file contents mixed into the folder with the actual zip file itself I use the later ... and, as in this last instance, will refer to the folder that is created while unzipping as <Blacklight Helmets>. Found (in last download) : For this download, my first suggestion is to remove the space from your folder names (i.e. change "Blacklight Helmets" to "BlacklightHelmets"); you should be able to do this in windows explorer. File "Blacklight Helmets.x2proj" (probably should rename to "BlacklightHelmets.x2proj"), using Notepad (or your favorite text-editor) : With: You will probably want to rewrite your "ReadMe.txt/; file again, once you understand what the actual code should look like ... Okay, that takes care of the easy part of what you did put into the zip file. When the developers decided to switch from the old (more or less static) containers in XCoM: EU & EW to a newer (more dynamic) data format for XCom 2, the result was a lot of "template" language ... in a basic sense "template" is just another label (or name) for "structure" - a way of describing the format of one's data. Breaking down "Blacklight_Ghost_F" you get something known as "Blacklight" that has a variant of "Ghost" and in this instance should be for the gender "F" or female; one might expect there to be another line for the male gender that uses "Blacklight_Ghost_M". Any DLC info should be referring back to your "package" or in this case to "BlacklightHelmets". Archetype is used to define (or refer to?) a datatype such as INT | FLOAT | ARRAY | BOOLEAN | STRING | XComGameState | XComGameState_Ability | XComGameState_Unit | etc. -OR- in short "BlacklightHelmets.ARC_Ghost_F" probably should be "BlacklightHelmets_Ghost_F.ARC_BlacklightHelmets_Ghost_F", or might be "BlacklightHelmets_Ghost.ARC_Ghost_F" - in both cases it is implied that these can only be used with female pawns (male pawns would require a "_M" in place of the "_F"). While I am willing to help with simple technical details - such as Folders, Files and scripts - I simply do not know enough to help with the graphical | visual aspects. ~ JDDysart
  17. FYI: The following file is created by ModBuddy, but I believe that you could manually rename it if you need to? The inconsistency with names might be why you had an issue requiring you to load into the editor before the game would see it at all? All the text files, regardless of extension (as long as notepad shows them properly?) should be manually edited - changing names as needed for consistency - while renaming folders and files (keeping the current extensions), again for consistency. If you do this properly then everything should load into ModBuddy when you open what was the BLRGearHelmets.XCOM_sln file. A sure sign that you have missed something is, when attempting to open a SLN file, ModBuddy gives error messages and/or fails to load something you know is there! My major concern was that the filenames (and/or folder names) did not match the package names that you told XCOM 2 (WotC?) to expect ... 0FYI: I compared your mod with what I found in the Example Weapon mod & DLC_3, for the name consistency expectations; with a small dash of programming experience thrown in, the naming inconsistencies appeared to be glaringly obvious to me?) As already stated, if you were getting things to show up in the Debug Mode of the game, then these inconsistencies can be considered to be minor technical issues. I have had my own issues with attempting to rename Folders & Files from within ModBuddy, which is why I recommend NOT doing said renaming from inside ModBuddy - somehow it just doesn't seem to handle renaming all that well! Of course as you suggest, you can backup what you have then start-over from scratch - maybe with some copy & paste of file contents from what I've seen? I hope you manage to make it through your "brick wall" fairly soon now, ~ JDDysart
  18. Searching the Nexus forums I found one discussion on when Recruiting switches from a "Pool Only" Character Pool policy to a "randomized character generation" policy ... Searching the Nexus Mods I found mods to revamp SPARK perks / Soldier skills ... Having purchased (and installed) all the DLCs available on Steam's XCom 2 store page ... I have managed to save SPARK-001 and "Julian" SPARK-002 to my Character Pool ... I have even created SPARK units (more-or-less) from scratch in my Character Pool ... I have found and installed two ModBuddies (XCom 2 and XCom2-WarOfTheChosen, SDKs) Development tools ... But so far, even though I set the SPARK units in the Character Pool to "appear as soldiers", I can't seem to find them in any recruitment lists? on newer campaigns! Can anyone offer any assistance on which functions (in which .uc files?) might be modified to allow for recruitment of SPARK units from one's Character Pool? Or might said SPARK recruitment be implemented via INI files? (which ones? where?) Any assistance (whatsoever) on this? ~ JDDysart
  19. After unzipping the download to <BLRGearHelmets> ... Found: <BLRGearHelmets>\BLRGearHelmets\BLRGearHelmets\ModPreview.jpg <BLRGearHelmets>\BLRGearHelmets\BLRGearHelmets\ReadMe.txt <BLRGearHelmets>\BLRGearHelmets\BLRGearHelmets\Src\BlackLigthGearHelmets\Config\XComContent.ini <BLRGearHelmets>\BLRGearHelmets\BLRGearHelmets\Src\BlackLigthGearHelmets\Config\XComEditor.ini <BLRGearHelmets>\BLRGearHelmets\BLRGearHelmets\Src\BlackLigthGearHelmets\Config\XComEngine.ini <BLRGearHelmets>\BLRGearHelmets\BLRGearHelmets\Src\BlackLigthGearHelmets\Config\XComGame.ini <BLRGearHelmets>\BLRGearHelmets\BLRGearHelmets\Src\BlackLigthGearHelmets\Content\BLRGearHelmets.upk <BLRGearHelmets>\BLRGearHelmets\BLRGearHelmets\Src\BlackLigthGearHelmets\Localization\XComGame.int <BLRGearHelmets>\BLRGearHelmets\BLRGearHelmets\Src\BlackLigthGearHelmets\Classes\X2DownloadableContentInfo_BlackLightGearHelmets.uc Missing?: To me the most glaring issue is a conflict between whether this is "BlackLightGearHelmets" or "BLRGearHelmets"; if one knows what one is doing one might get away with some mixed usage (such as this), but as I noticed conflicts in the way this usage is mixed I would suggest that you decide on one or the other and be consistent with whichever one you DO use. This could be what is causing your "XCom 2 Editor" issue. For obtaining consistency: I would recommend using Windows Explorer and Notepad.exe to correct any inconsistent names (labels? folders?), and only after that go back into ModBuddy and see if everything is still included when you load this project into ModBuddy? (might want to hold onto the zip file, as a backup copy of what is currently there - before you start changing names.) I may have targeted only small technical issues here ... but correcting these should make it easier for others to help find any larger issues! ~ JDDysart
  20. Update: After further review (of XCOM 2) ... Apparently when a DLC is installed the DLC's "Cooked content" (including default values?) is placed in with the rest of the game's "Cooked content" - so, once the DLC is installed, the supporting content is "In The Game". The pieces placed in the DLC folders are only what is needed to bridge-the-gap (hook-into?) to said supporting content ... for including the DLC specifics on whichever 'Campaigns' that the user selects to have it included on; and may or may not (depending on section headers?) override any default values in the "cooked" files. If the section headers (such as >[sparkSoldier X2SparkCharacterTemplate_DLC_3]<) do match up with what is in the "cooked" files, then when the DLC is selected for a particular campaign - the INI values should override the default values. If you are into modding ... are you aware that there is a GiveHackReward console command (for use while on a mission) that permanently increases the active unit's hacking stat? (re: EnemyProtocol_1 or EnemyProtocol_2) Personally I have better luck with Key-Bound commands -or- a Key-Bound text file containing one or more console commands (as these appear NOT to require enabling the "Console"). ~ JDDysart
  21. First: I seem to remember from "MakeSoldierAClass", that In a console command, a UnitName SHOULD be in quotes: SetSoldierStat eStat_Hacking 100 "KILLER SPARK002" ? Then, I have more experience with XCOM:EU 2012, where the DLC content from the Steam Local Files (installation) are combined with default files before being written to the Document Files (User dependent data) ... I am not quite up to speed with how XCOM 2 manages this for (optional?) DLCs, such as Shen's Last Gift and Alien Hunters ... it would appear that (at one time) the intent was to only allow said 'DLC Content' into a game where these DLCs were selected while starting a campaign? and that when selected the DLC content is loaded in - but not saved in the Document Files? It would also appear that, at some other time, it was intended that SPARKs be allowed in as an additional Soldier Class (in addition to Grenadier, Ranger, Sharpshooter, Specialist and Psi Operative); taking the place of "tanks" or "SHIVs" from earlier XCOM games? Any which way, IMO, these two intents came to cross purposes that created a SNAFU - that I hope to live to see untangled. Back to how to save time now ... as XCOM 2 and WotC do not actually share files (re: "<Steam>\SteamApps\Common\XCOM 2"): For the XCOM 2 game (without WotC) stay out of the XCom2-WarOfTheChosen folder; in Documents use "\MyGames\XCOM2". For XCom2-WarOfTheChosen stay in the XCom2-WarOfTheChosen folder; in Documents use "\MyGames\XCOM2 War of the Chosen". Now I need to get back to playing the game ... and see if I can make it past the confusion of slowing Advent down while contacting Resistance factions (post Shen's Last Gift); and locate this "Black Market" that I have read so much about. ~ JDDysart
  22. First - have you found Steam's "XCOM 2 War of the Chosen Development Tools"? Do you have enough disk space and time to get the 'full_content' beta? Are you using these for your modding? Have you figured out how to enable these tools to kick (transfer) you into the Debug Mode of the (XCOM 2 War of the Chosen) game? There is a PDF file that explains what one needs to do ... If you haven't already done so ... you might check out just what is contained in the "<Steam>\SteamApps\Common\XCOM 2\XCom2-WarOfTheChose\Development\..." folder (and it's sub-folders, such as ...\Src\XComGame\Classes)? And a good start on finding your issue might be to review the "ExampleWeapon" template (that comes with this SDK -aka Firaxis's ModBuddy-)?
  23. As a college professor once explained it to me, the so-called Random Number Generator is actually a "PSEUDO" Random Number Generator; meaning that with a large enough sampling It behaves like an RNG, but there actually is a pattern to it if one pays enough attention for a long enough time. Then there are the additional factors, not only just the chance to hit, but any bonuses (or penalties) that may affect that 'chance to hit' on one side, as well as the other side's 'chance to be missed' along with any bonuses (or penalties) thereto. Generally the 'chance to hit' is labeled "the offensive" side, while the 'chance to be missed' is labeled "the defensive" side. Should you be familiar with the concept of "Save Scumming" - generally if you take the same actions in the same sequence you tend to get the same results; to get different results you need to figure out how to mix up the sequence (and sometimes change out the offensive unit, the defensive unit or both) in order to get different results. XCOM can be frustrating in that when you use four offensive units in an attempt to take out four defensive units, and when done in one particular sequence the offensive side fails ALL four attempts; but, in a different particular sequence, all four "otherwise exactly the same" attempts may ALL be successful. "Under the Hood" of Random Number Generation: The RNG uses a 'seed' value that is fed into a complex numerical operation that produces a "pseudo random number" value, returning said value (that is then used as a 'seed' for the next "pseudo random number"). XCOM effectively generates a 'stack' containing several of these "pseudo random numbers" at certain intervals. Then retrieves a number from this 'stack' each time the game encounters a need for a random number. At the end of said interval, any remaining numbers in this stack are discarded, and another 'stack' is generated. And please do note: chances to 'hit' or 'miss' are not the only equations that use random numbers (from said 'stack')! When the above mentioned "interval" is too short or said 'stack' is too small, the results will appear to be a 'lucky streak' (good, bad, or otherwise).
  24. In the context of UPKUtils & PatcherGUI (in extremely technical terms) an object is something that may be accessed via a 'named reference' to a "serialized" (i.e. indexed) location. If you have been using the Unreal-Engine Explorer (a.k.a. UE Explorer) to view what is in an Unreal-Package (a.k.a. UPK) file, then you may more easily understand what follows. A UPK file is a container of various "objects" addressed via one of three tables: the "Names" table (contains simple 'unique' names), the "Exports" table (contains complex names, of 'objects' contained in this file), and the "Imports" table (contains complex names, of 'objects' contained in another file). Simple names are unqualified single level names, such as "IsATank" and "IsInPsiTesting". Complex names are qualified multi-level names, such as "XGStrategySoldier.IsATank" and "XGStrategySoldier.IsInPsiTraining". A top-level 'object', in Unreal-Script, is a 'Class object' defined by a "UC" (Unreal-Class) tag; which (in unexpanded form) is what you first see on the "Objects" tab in UE-Explorer; of course these 'Class Objects' may be expanded to show 'sub-objects' (with various 'U?' tags). PatchUPK.exe uses the Less-Than ("<") and Greater-Than (">") symbols in place of quotes to designate 'pseudo coded references' that need to be resolved into 32-bit index values for one of the three primary tables in a UPK file. A qualified reference (i.e. name - such as "XGStrategySoldier.IsATank" or ".IsATank" - the "." in ".IsATank" does make a difference) resolves to a single 32-bit value, while an unqualified reference (i.e. name - such as "isATank") resolves to a double 32-bit value (a 32-bit index-value followed by a 32-bit "0" numeric-value). And then there are the serialized size (length) vs the memory size (length) issues, which is the main reason for using the ?_CODE sections - so that PatchUPK.exe can handle these (usually confusing) issues; which works really well when all the serial (index) values are properly pseudo-coded. An unresolvable "pseudo coded reference" will cause PatcherGUI to "Fail" when attempting to "apply" a patch. The "unable to create backup" error is indicating a problem with placing a copy of the pre-modification-UPK-file (the "XComStrategyGame.upk" file in your example) in the designated backup location. Might be caused by failing to designate a valid 'backup path", see PatcherGUI's "Advanced" menu for the "Settings" (Program Settings) window - which should have valid values for three critical paths; or possibly, for whatever reason, the program is unable to write (a file of that size) to the backup location. Speaking of which, it might be considered as 'a good policy': when uninstalling a patch - do "clean up" (at least some of) this backup location. I sincerely hope some part of the above is of some use to you, Good Luck! ~ JDDysart
  25. Are there any lurkers, players, modders, ETC that might still have any interest in seeing XCOM 2 wiki articles? Maybe covering such things as: Where various files might be found on one's local hard disk drive?How & where to obtain the related XCOM 2 ModBuddy Tools?AKA "XCOM 2 SDK", "XCOM 2 WotC SDK" ...AKA "XCOM 2 Development Tools", "XCOM 2 WotC Development Tools" ...How to play XCOM 2 (& WotC) in Debug Mode (with the developers console enabled)?ETCOr maybe someone wanting to write (or at least suggest interesting) additional XCOM 2 wiki articles? Reference: Category:XCOM 2 ~ JDDysart
×
×
  • Create New...