Amineri

I've requested this exact thing from Firaxis -- to add a "Always fires on game load when mod active" in addition to the "Fires only first time loading with Mod/DLC"

If you just want it to be always created, probably the best place for your gamestate creation code is in X2DownloadableContentInfo (your extension of it). This will run exactly once when a new campaign is started, or the first time a save is loaded with the mod installed. However, it wouldn't handle adding your component gamestate to newly created units (new recruits generated each "month", or reward soldiers). You'll likely have to set up an event listener of some sort to handle new soldiers being added. The event handler has to it in some sort of gamestate, but I think you should be able to create a gamestate in your initialization code that isn't linked to anything -- only purpose is to receive the listener events and add your component gamestate to newly created units.

In your case you don't need to override the "CreateTemplate" functions, as they are only run when the game launches. Their purpose is to create the template class instances, which get stored in the appropriate TemplateManager (this all happens in native code at launch, so is "invisible" to us). What you need to do is either modify or overwrite the templates themselves.

I haven't tried this yet, so can't answer why it isn't working. But, I'll test it out in the next day or two and get back to you if I figure anything out.

Yes, overriding class is a bit of a pain and not friendly to other mods. However, there is a REALLY IMPORTANT tool regarding gamestates that hasn't been brought up yet, but I will do so now. Built in to the XComGameState_BaseObject class is support for game state components. That is, any gamestate can attach any number of components to itself. This can recurse, so these can be organized into logical trees. This doesn't allow overriding functionality in the original game state in many cases, but is the principle way to effectively add new functions or data to a gamestate class. As an example, in the officer mod I created a new class called XComGameState_Unit_LWOfficer. This actually directly extends BaseObject, not unit. I named it with "Unit" in the name to indicate that it is intended to function as a component of the Unit gamestate. I also built a Utiity class with statics (although these could go into the gamestate itself to reduce class-count, I suppose) which allows retrieving the officer component given a unit game state. This works via code : XComGameState_Unit_LWOfficer(Unit.FindComponentObject(class'XComGameState_Unit_LWOfficer')); So, in UIcode where you'd typically think to access the Unit gamestate to store/retrieve data, or provide some sort of function, you can instead retrieve your mod's unit component to provide the same service.

So, I won't go into full detail on how the behavior tree works here, but the "NodeType=Selector" basically goes through each option in order, checking to see if it is valid and can be executed. In terms of a tree, it's a depth-first left-hand parsing rule. Reworking the AI to target mimic beacons the same as any other unit would require folding it into the FirstAction and SecondAction options, at the least.

This looks like it should work. You might try prefacing the first line with ! so that it deletes just on key and not value : !FragGrenade_BaseDamage +FragGrenade_BaseDamage = (Damage=3, Spread = 0, PlusOne = 20, Crit = 0, Pierce = 0, Shred=0, Tag = "", DamageType="Explosion")

AFAIK, the configuration file management is all stock Unreal Engine 3, unmodified by Firaxis. I'm not sure if the config merging is handled in native code (in XCom2.exe) or in one of the packages like Core.upk or Engine.upk.

Very good find. You're right about that. So, I guess you'd have to write a bunch of code to go through all abilities in the X2AbilityTemplateManager and change the Template.AbilityToHitCalc definition. Except that you don't want to do it in ALL cases, because some abilities have legitimate other to-hit functions, some of which are child classes of the base one. So this may just be a case where the change is fundamental enough that it would require a replacement XComGame.upk to make happen.

Probably the best bet would be to skip the Unrealscript side of things, and just jump into UnrealEd. From there, you can make cosmetic changes by making copies of existing archetypes and linking them to new art. The whole Unreal art pipeline on that side is designed to be accessible to artists that aren't code-savvy.

Yes, the config(LW_MutonM2) definition specifies that all config class variables in the class will be defined in a config file name XComLW_MutonM2.ini. The XCom prefix is always assumed for all config files (replacing the Default prefix in the main game config folder). Each class can specify which config file it uses. So you can have a bunch of smaller configs, or fewer larger ones.

It's me! Of course I made that configurable.... If you scroll down a bit in that same file XComLW_OfficerPack.ini, you'll find TrainingDaysForRank array, which defines the number of days required to train each particular rank. So you can make early training quicker, and later training slower, or whatever you prefer. There's also the "RequiredRankPerOfficerRank", which controls what regular class rank is required to allow training of a particular leader rank. In both cases there are commented out versions with to allow much quicker testing. You should be looking at the XComLW_OfficerPack.ini that's in the Mods folder in the game folder, not any version that may pop up in My Games.

I'm not really sure why it's not working, then. So far I haven't tried to override that class, just add new abilities/effects that adjust stats, which can accomplish a lot of the same effect, since such effects can be persistent and dynamic. I might play around with trying to replace it later, if I have the time.

Aha! OK, that would explain why it's so unfamiliar to me. I've done C++ back in the university and C# for Space Engineers Coding Blocks, but this looks like neither of those. "Unrealscript." That puts a name on the enemy and gives me something to work with. Thank you kindly :smile: *edit* And for the record, a token search now that I know what I'm searching for revealed that the ` is a "preprocessor" used to define code macros - simplifications to the extended into full code before compilations. The one that was really stumping me in the code files was always `HISTORY, which I now suspect is a shorthand macro for a more complicated method call. It's not in the UDK default macros list, so I presume it's XCOM specific, which means it must be defined somewhere in the class inheritance chain. I feel less lost now, thank you. The list of macros is defined in a file globals.uci in the /XCOM 2 SDK/Development/SrcOrig/Core/ directory. In practice I find I very rarely reference that file, though -- just copy/paste from Firaxis source. Also, if anyone happened to be using UE Explorer to look at the decompiled code in the XComGame.u, there won't be any macros, of course, because UE Explorer doesn't know about that. :) Some handy links for people picking up Unrealscript (which is pretty much a dead language since Unreal 4 and Unity both use C#) : https://udn.epicgames.com/Three/UnrealScriptHome.html https://wiki.beyondunreal.com/UnrealScript_overview

These are generally defined via an X2Effect class, in particular a child of X2Effect_Persistent.

I DO get message about which lines have errors -- you may need to check the VS Shell verbosity settings. The problem with your particular code is that the token "Menu" is probably out of scope in your mod class. I'd try changing the last line to something like : `HQPRES.UIRaiseDialogue(kDialogueData); Also, dialogues generally define a callback delegate that specifies which code to execute on each button-press respones.

You can use the class'UIUtilities_Text' static methods to apply html styling to your text. You can also nest them in order to add more tags (i.e. set title font/size as well as add centered html tags). Of course you can always add the html tags yourself, if you want :). After that, it's a matter if using the inherited UIPanel controls (SetPosition, SetX, SetY) to position it accordingly. The position is relative to the how you create your UIIcon or UIText object in the InitPanel(...) or InitText(...) method.

I think that you are correct that this is a bit hinky. In mathematical notation, if we set : A = Event "Hit" B = Event "Crit" It seems that they are confusing P(B) with the conditional P(B | A). When we say "there is a 20% chance to crit", my understanding is that it's not an absolute, but is really a 20% chance to crit IF the shot hits -- that is, it is conditional. And by the definition of independent events : P(B) = P(B | A) * P(A) That is, the absolute probability of getting a crit is the conditional probably (e.g. 20%) times the probability of getting a hit in the first place. With the code as it is, P(A) = 20%, P(B | A) = 100% The result is that the calculated to-hit ends up at -80% (0.2 - 1.0) and the Miss Result ends up at 180% (1.0 - (-0.8)). So not handling the crit conditional probably could have some strange effects, yes...

If you do a search through the source files for usages of X2AbilityToHitCalc_StandardAim (I use Notepad++), you'll find that the class is being explicitly specified in the weapon templates. Such as : StandardAim = new class'X2AbilityToHitCalc_StandardAim'; StandardAim.bGuaranteedHit = true; Template.AbilityToHitCalc = StandardAim; from X2Ability_AdventMEC.CreateMicroMissilesAbility. This is using new, so should be override-able, but it is being invoked when the game is launching, when the base-game templates are being loaded. Presumably this occurs prior to the mods being launched, so it's basically a sort of load-order issue. You'd want your class overrides to take place before these templates get loaded. This is just a theory of mine, but could be confirmed by changing the DefaultEngine.ini to include your override definitions (implicitly making them part of the base game). I'm not quite sure when the relative timing of "config merging" versus "Template creation" occurs, since it's all deep down in the native exe ...

If you based your model off of something like the Assault Rifle, but modified the skeleton for your own weapon, then this is likely the culprit. We experienced this same issue with the SMGs. The problem is likely the re-use of the AssaultRifle (or what you based on) animation set, as defined via the weapon archetype. When you actually play the animation, it will snap the skeleton back to the original Assault Rifle positions. So if you modify the skeleton, you properly should create a new animset. Also, weapon attachments shouldn't be previewed via the "Extra Meshes" -- attachment are connected via Sockets, so you should preview attachments by loading the preview mesh in the Socket Manager for the Skeletal Mesh. Note that some of the sockets aren't connected to the root bone, but are connected to other bones instead. Hence if the skeleton deforms during the weapon animation, and the socket is attached to a bone that is moving, the attachment will move. This is often a desired feature :) The way we got around this for the SMGs (in particular the conventional one where the Magazine bone is in a completely different place) was to attach the Mag socket to the root bone instead of to the Magazine bone. That way when the animation deformed the skeleton, the socket didn't move. Hope this helps!

So, when a upk has a reference to another object in another upk, Unreal has to create links in order to find them. When the objects are "sitting in place" /XComGame/Content/ (which maps to place in XComGame/CookedPCConsole in game folder), this is no problem. However, when you save your upk to your project folder, it ends up outside the XComGame folder, so it treated as an "external" upk. These upks can reference objects within the XComGame folder without problem, but can't resolve links to each other -- which is what your error is stating. 1) The way I got around this for our release mods was to put all objects that reference each other inside the same upk inside the mod's content folder. So when I was working on LWSMG_CV.upk and would save it, I would get messages saying that links to itself could not be resolved. The base game kept archetypes and art in different packages, but for our mods I put them into the same package, for this specific reason. 2) An theoretical alternative would be to create your content packages within the XComGame/Content folder so they are not treated as external packages. But then you would have to move them manually into your mod folder so that the precompileshaders commandlet gets run.

There are two types of events and two event systems going on. 1) The built-in one in Unreal Engine, which is used to pass events between Unreal, Kismet and GFx components. In Unrealscript, these look like : `XCOMGRI.DoRemoteEvent('AnEventName'); 2) The custom one built by Firaxis, which is within the gamestate system to modifiy behavior. In Unrealscript, these look like : `XEVENTMGR.TriggerEvent( 'EventName', EventState, SourceState, NewGameState); Both of these are defined implicitly, so there's no single "master list" which has to be updated. In the latter case, a RegisterForEvent method in the X2EventManager allows creating a new EventID implicitly by the act of registering it. So you can either search for "TriggerEvent" to find the various types of events that get triggered, or you can add code to make the X2EventManager dump debug output via its "AllEventListenersToString" debug method, then dump the string out to the log. The latter method will only show events that are registered at the time you invoke it, however, which may not be all of them possible.

Hi, good to see you back again :) The reason you can't use an override on the given class is because it is an archetype class. This means that the artists use it as a template when creating art in UnreadEd. If you launch the XCOM 2 Editor (aka UnrealEd), look in the content browser and do a search for types XComHumanPawn, you'll find that these are already instanced during development. The Spawn in this case is being used to create a copy of that already instanced archetype, not a brand new one, which is why it is failing. AFAIK, there are only two ways to change archetypes currently : 1) Change the archetype class, create new instances using the new archetype in UnrealEd (linking to same assets), then update config/template data to point to the new archetypes. This is akin to the pipeline for creating new art, which are you in a way. 2) Build a complete replacement for XComGame.upk, which would allow you to change the functionality of XComHumanPawn without changing the name. This is possible, but pretty drastic. Regarding "big heads", one significant different from XCOM EU/EW to keep in mind is the following : 1) In EU/EW, the "body" was the root object to which attachments were made (head, weapon, etc) 2) In XCOM 2, the "head" is the root object to which attachments are made (torso, face props, beard, hair, etc). The torso gets attached to head, then arms and legs are attached to torso. This may have an impact on what you are trying to do.

Redscreens are a tool used to help capture serious but non-fatal bugs. They are explicitly added via the macro `REDSCREEN("Your redscreen text"); They don't indicate anything going wrong besides what was going to anyhow, they are just a glaringly obvious reporting mechanism. Redscreens should be disabled in release version of the game, and only present when launching in debug mode. (That is, when launching through the SDK, or with appropriate command-line arguments). If you are getting redscreens when playing normally, I'm not sure what could be causing that -- it doesn't happen for me when launching XCom2.exe normally with no commandline parameters.

It's true, I eventually got lazy, and relied on DubiousIntent to cross-post information in particular posts over to the wiki. I will make an effort to make some contributions to a wiki, if one gets created, though. :)