CaveRat

Glad I could help. :thumbsup:

Try passing NewGameState along to the AddStrategyUnitToBoard() function instead of History. // Spawn the new unit SpawnedUnit = AddStrategyUnitToBoard(StrategyUnit, NewGameState, Spawnlocation) And the function should be changed too. private static function XComGameState_Unit AddStrategyUnitToBoard(XComGameState_Unit Unit, XComGameState NewGameState, Vector SpawnLocation) { local X2TacticalGameRuleset Rules; local XComGameStateContext_TacticalGameRule NewGameStateContext; local XComGameState NewGameState; local XComGameState_Player PlayerState; local StateObjectReference ItemReference; local XComGameState_Item ItemState; local X2EquipmentTemplate EquipmentTemplate; local XComWorldData WorldData; local XComAISpawnManager SpawnManager; // not needed // NewGameStateContext = class'XComGameStateContext_TacticalGameRule'.static.BuildContextFromGameRule(eGameRule_UnitAdded); //!!!! Redscreen appears after next command !!!! // no need to create new state // NewGameState = History.CreateNewGameState(true, NewGameStateContext); Unit = XComGameState_Unit(NewGameState.CreateStateObject(class'XComGameState_Unit', Unit.ObjectID)); Unit.SetVisibilityLocationFromVector(SpawnLocation); (rest of code not important) Also don't submit the NewGameState at the end.

@E3245, I've never seen GoTo and Labels used outside Actor state coding. You might wanna check Unreal Script reference. https://udn.epicgames.com/Three/UnrealScriptReference.html I would've probably done something like this:

First, make sure that you load a save which was created before enabling the mod, otherwise OnLoadedSaveGame() won't work. I'd also put a log statement there somewhere to see if it runs at all; because people have reported having strange issues with this function. Second, not sure about Templates but you can't do something like this: //Make the changes to the HQ state. Here we add items to the HQ's inventory ItemTemplate = ItemMgr.FindItemTemplate('BOM16'); ItemTemplate = ItemMgr.FindItemTemplate('CritUpgrade_M16'); ItemTemplate = ItemMgr.FindItemTemplate('AimUpgrade_M16'); ItemTemplate = ItemMgr.FindItemTemplate('ClipSizeUpgrade_M16'); ItemTemplate = ItemMgr.FindItemTemplate('ReloadUpgrade_M16'); This will only pick up the last ItemTemplate, so theoretically, ReloadUpgrade should've been present ??? I'd probably replace ItemTemplate with X2WeaponUpgradeTemplate. And you need to instantiate each one separately and add it to XcomHQState. local X2WeaponUpgradeTemplate WeponUpgradeTemplate; // .. skip WeaponUpgradeTemplate = X2WeaponUpgradeTemplate(ItemMgr.FindItemTemplate('BOM16')); ItemState = WeaponUpgradeTemplate.CreateInstanceFromTemplate(NewGameState); NewGameState.AddStateObject(ItemState); NewXComHQState.AddItemToHQInventory(ItemState); // next template WeaponUpgradeTemplate = X2WeaponUpgradeTemplate(ItemMgr.FindItemTemplate('CritUpgrade_M16')); ItemState = WeaponUpgradeTemplate.CreateInstanceFromTemplate(NewGameState); NewGameState.AddStateObject(ItemState); NewXComHQState.AddItemToHQInventory(ItemState); ^ this is just to illustrate. Obviously, it would be better to create some sort of FOR loop to handle it.

Uh, I've tested the above without experiencing any problems. Some native classes cannot be overridden - true, but CheatManager is "newed" via PlayerController script.

I thought I'd post an update on this with my findings in case someone might find it useful. So far I have found two ways of making custom console commands work (not counting Highlander mod) 1. First you need to decide which part of the game you need commands to work in (Tactical, Strategy). The game loads different GameInfo objects, each with their own PlayerController > CheatManager objects. Commands (exec functions) are defined in those CheatManager classes, and the hierarchy is as follows: CheatManager >XcomCheatManager >XcomShellCheatManager (works in Main Menu) >XcomHeadquartersCheatManager (Strategy) >XcomTacticalCheatManager (Tactical) So, if for example you want to make commands that work during Tactical play, first you need to do is create a class that extends XcomTacticalCheatManager: /* * Commands for Tactical Game */ class CustomTacticalCheatManager extends XcomTacticalCheatManager; // test function exec function TestCustomCommand() { OutputMsg("Hello World"); // prints text to console window } Once you have that, all you need to do is define a ModClassOverride in the XcomEgine.ini [Engine.Engine] +ModClassOverrides=(BaseGameClass="XcomTacticalCheatManager", ModClass="CustomTacticalCheatManager") This is what I was originally missing, and why my commands failed to work. This method will work fine but as with all class overrides, you need to keep track of your XcomEngine.ini. If you want to use different CheatManager classes with different mods, this might become problematic. There is another way of doing it. 2. Set CheatManager at run time. You still need your custom class, but you can call following function sometime during Tactical game: /* * Sets up CheatManager in Tactical section */ function SetupTacticalCheatManager() { local XcomTacticalController TPC; TPC = XcomTacticalController(class'WorldInfo'.GetWorldInfo().GetALocalPlayerController()); if (TPC != none) { TPC.CheatManager = new(TPC) class'CustomTacticalCheatManager'; } } Basically, it just grabs XcomTacticalPlayerController and instantiates new CheatManager class. I have run this via a UIScreenListener which is set to listen to UITacticalHUD, and it worked. No class overrides needed.

I don't think that this function class'SeqAct_SpawnUnitFromAvenger'.static.SpawnUnitFromAvenger(); can be used within an effect in such a manner. It creates and submits its own game state before effect game state is submitted. Basically this creates a mess of things. You'd probably want to base your effect on X2Effect_SpawnUnit.uc and re-use some of the code from SecAct_SpawnUnitFromAvenger.uc.

Yeah, I saw your post in the other thread, You got pretty close. And yes, you need to add both object states to the new gamestate. At least in this case. "AddComponentObject" method merely creates a link between the two (AFAIK).

Try this: function CheckforRangerInfoObject() { local X2_SkyrangerCustomSettings RangerHolder; local XComGameState_HeadquartersXCom XcomHQ; local XComGameState NewGameState; local XcomGameStateHistory History; History = `XCOMHISTORY; XComHQ = `XCOMHQ; RangerHolder=X2_SkyrangerCustomSettings(XcomHQ.FindComponentObject(class'X2_SkyrangerCustomSettings')); if (RangerHolder == none) { // create change state NewGameState = class'XComGameStateContext_ChangeContainer'.static.CreateChangeState("Adding Ranger Info Object"); // make a copy of XcomHQ object which will be modified XComHQ = XComGameState_HeadquartersXCom(NewGameState.CreateStateObject(class'XComGameState_HeadquartersXCom', XComHQ.ObjectID)); // instantiate new object RangerHolder = X2_SkyrangerCustomSettings(NewGameState.CreateStateObject(class'X2_SkyrangerCustomSettings')); RangerHolder.InitComponent(); XcomHQ.AddComponentObject(RangerHolder); NewGameState.AddStateObject(XcomHQ); NewGameState.AddStateObject(RangerHolder); History.AddGameStateToHistory(NewGameState); `log("Creating Holder" @ RangerHolder); } }

I have a theory why this isn't working. After poking around in X2TacticalGameRuleSet.uc I found a function which is responsible for registering EventListeners in abilties. // THIS SHOULD ALMOST NEVER BE CALLED OUTSIDE OF NORMAL TACTICAL INIT SEQUENCE. USE WITH EXTREME CAUTION. simulated function StateObjectReference InitAbilityForUnit(X2AbilityTemplate AbilityTemplate, XComGameState_Unit Unit, XComGameState StartState, optional StateObjectReference ItemRef, optional StateObjectReference AmmoRef) { ///...... } I won't post entire function (as you can look it up), but it would appear these triggers might be registered during mission start up .. only once. However, in your case, you are adding the ability via an effect (dynamically). My guess is that the trigger simply doesn't get registered in this case. I don't know how you add the ability in your effect, but you might be able to add RegisterListener call manually.

To be honest, I am not quite sure why your code is not working. Can you describe (preferably, in detail) how your unit obtains this ability, and how you are testing this in the tactical game? Are you loading a save with tactical game, or are you starting a quick game from debug menu?

Hm, you've added some odd conditions. ExcludeFriendlyToSource = true?? Since the source and the target is one and the same, perhaps this condition prevents it from working.

I thought that without the debug mode, redscreens will be suppressed altogether. I'd suggest you simply try to run it via ModBuddy's debug option. (at least once, to test it). As for the order of execution of these functions, I'm not entirely sure. But I've always assumed that if class B extends class A, then class A must be processed before class B. But like you say, I suppose it is possible that it's the "other" CreateTemplates() being rejected. Whichever the case, it's a pretty easy fix. You just need to add those modified templates to the template manager manually. This is what Josh recommended as well in your reddit conversation.

Which is why the code you posted should only partially work. It will only return your new templates. But the ones you've modified will be rejected. I also don't understand why it's not showing you any redscreen warnings. By any chance, are you launching the game from Steam instead of ModBuddy? Admittedly, I've tried this method before the patch, and I am not sure if anything has changed since then.

Strange. Don't you get a ton of Redscreen errors when entering Main Menu? When I tried doing it almost exactly the same way, I got a bunch of redscreens about "templates rejected due to having the same name" or something. I suspect its due to CreateTemplates being called twice and Templates array returning duplicates. I had to call up template manager and add modified templates manually, and simply return empty Templates array.