SpazmoJones

The setting of the color happens in my modified XComTank.OnArmorLoaded function. If it's called with a "none" ArmorArcheType then it sets the main mesh color and the attached weapon color. Mesh is the main SHIV. It then finds the attached weapon mesh and sets the colours there too. The regular soldier armor tint setting is done in a similar way yet each soldier's armor keeps it's unique color. This tells me that the SHIV mesh must be constructed in a slightly different way for it to behave like it does. simulated function OnArmorLoaded(Object ArmorArchetype, int ContentId, int SubID) { local XComTank PawnArchetype; local int MatIdx; local SkeletalMesh WeaponMesh; local SkeletalMeshActor NewWeapon; local editinline MeshComponent FoundMeshComponent; local name SocketName; // End:0x3C9 if(ArmorArchetype == none) { MaterialInstanceConstant(Mesh.SkeletalMesh.Materials[0]).SetVectorParameterValue(name("CMOD"), ((ContentId == -1) ? MakeLinearColor(0.50, 0.50, 0.50, 1.0) : XComContentManager(class'Engine'.static.GetEngine().GetContentManager()).GetColorPalette(9).Entries[ContentId].Primary)); MaterialInstanceConstant(Mesh.SkeletalMesh.Materials[0]).SetVectorParameterValue(name("CMODB"), ((ContentId == -1) ? MakeLinearColor(0.250, 0.250, 0.250, 1.0) : XComContentManager(class'Engine'.static.GetEngine().GetContentManager()).GetColorPalette(9).Entries[ContentId].Secondary)); // End:0x3C5 foreach Mesh.AttachedComponents(class'SkeletalMeshComponent', FoundMeshComponent) { FoundMeshComponent.SetScale(-0.020 + (0.020 * float(SubID))); MaterialInstanceConstant(FoundMeshComponent.SkeletalMesh.Materials[0]).SetVectorParameterValue(name("CMOD"), ((ContentId == -1) ? MakeLinearColor(0.250, 0.250, 0.250, 1.0) : XComContentManager(class'Engine'.static.GetEngine().GetContentManager()).GetColorPalette(9).Entries[ContentId].Primary)); } } // End:0x705 else { PawnArchetype = XComTank(ArmorArchetype); // End:0x5C5 if(PawnArchetype.Mesh.SkeletalMesh != Mesh.SkeletalMesh) { Mesh.SetSkeletalMesh(PawnArchetype.Mesh.SkeletalMesh); MatIdx = 0; J0x499: // End:0x54E [Loop If] if(MatIdx < PawnArchetype.Mesh.Materials.Length) { Mesh.SetMaterial(MatIdx, PawnArchetype.Mesh.Materials[MatIdx]); ++ MatIdx; // [Loop Continue] goto J0x499; } Mesh.PrestreamTextures(10.0, true); Mesh.SetLightEnvironment(LightEnvironment); LightEnvironment.ResetEnvironment(); CacheTreads(); } WeaponMesh = SkeletalMesh(XComContentManager(class'Engine'.static.GetEngine().GetContentManager()).GetGameContent(string(PrimaryWeapon))); // End:0x6F9 if(WeaponMesh != none) { NewWeapon = Spawn(class'SkeletalMeshActorSpawnable', self,,,,, true); NewWeapon.SkeletalMeshComponent.SetSkeletalMesh(WeaponMesh); SocketName = class'XGInventory'.default.m_SocketNames[3]; AttachItem(NewWeapon, SocketName, false, FoundMeshComponent); } m_bUnitContentLoaded = true; } //return; }

I've just finished updating my Enhanced Customisation mod to allow custom weapon size and colours for SHIVs. Everything works well except for when I set the material colour of a single SHIV pawn - for some reason the colour change gets applied to every other SHIV pawn. It's as if there's just a single global SHIV material that's attached to every SHIV mesh. Is there some sort of setting or way to define a material that would make it behave in such a "global" way. If I understood this better I'd know what to look for in the code to fix it.

I have an idea of combining some of my mods together to create some new gameplay elements. For example, now that shivs can be resized, perhaps add some new shiv types to the game. Similarly, we can now create "alien" soldiers that not only look different, but also have different rules applied when it comes to how they gain XP and level up. For example, they might be able to level up by picking perks from any level (using my commander's perk choice mod), but earn XP at a slower rate, and have longer fatigue time. Other differences could be dreamed up as well of course. I don't know if the regular LW team have already investigated if this is possible, but I'd really like to see "regular" XCom-like soldiers on the alien/exalt team, with the same wide range of abilities XCom soldiers have. I suspect this is very hard to do though which explains why we don't see anything like that in LW at the moment. The air war RNG issues could also be greatly improved by doubling the interception time and halving the damage (I saw this suggested somewhere on the forum). I also really like what I've seen with the new "Tactical Sense" overhaul. There are a lot of great ideas there. For "Long War++" to continue we really need somebody to take charge and make the hard decisions, like JL has been doing, otherwise we're not going to get anywhere.

If you're able to intercept the write you could just multiply the float by 1000 and write it as an int to get an effective 3 decimal place accuracy. Or by 10000 for 4 decimals, etc.

I remember having the same problem when I first started modding XCom - the code looks fine but it crashes. If you're increasing the size of the function you'll have to expand it. Your header should look something like this: UPK_FILE=XComStrategyGame.upk EXPAND_FUNCTION=XGStrategySoldier.RebuildAfterCombat:0x0700 OBJECT=XGStrategySoldier.RebuildAfterCombat:AUTO If you code moves the locations of any jumps then they'll have to be updated as well. Which is a huge pain! Personally, I'd recommend that you use the HexToPseudoCode.exe utility to decode the entire function and then change it as you like. You won't have to worry about memory sizes and jump targets as it will handle everything for you. The pseudo code it also much easier to read than plain hex. The other benefit is that you can keep making changes and re-applying the patch as you're replacing the entire function in one go - you won't have to uninstall each time.

First the bad news: I eventually managed to hack a version that set the socket relative scale values but it didn't make any difference. I eventually realised that this would only scale components attached to the socket you set the scaling on. Because the head mesh isn't actually attached to any sockets this approach wont work. The technique I used to access the .RelativeScale object (which isn't referenced by XComGame.upk) might be useful to somebody, so here's what I did: I modified the Actor.TriggerGlobalEventClass function in Engine.upk as follows (this function is referenced by XComGame.upk): UPK_FILE = Engine.upk OBJECT = Actor.TriggerGlobalEventClass : AUTO [REPLACEMENT_CODE] /*(0x0000/0x0000)*/ 49 [@] ( 1D <%i -1> 15 ) // Check our magic number 07 [@notspecial] 9A 00 <.ActivateIndex> 1d <%i 123456> 16 //** do something special with the <.InInstigator> object here. It seems it can hold any object (not just an Actor) E7 1f <%t "Access everything in ENGINE.UPK here!"> 2A 16 // write to the launch.log file // my code that set the relativescale went here... //************************** [#notspecial] /*(0x0009/0x0009)*/ 07 [@label_0x002D] 99 00 <.ActivateIndex> 25 16 /*(0x0018/0x0014)*/ 0F 10 25 00 <.ActivateIndices> 00 <.ActivateIndex> /*(0x002D/0x0021)*/ [#label_0x002D] /*(0x002D/0x0021)*/ 0F 00 <.GameSeq> 19 01 <@WorldInfo> [@] <WorldInfo.GetGameSequence.ReturnValue> 00 ( 1C <WorldInfo.GetGameSequence> 16 ) /*(0x0056/0x003A)*/ 07 [@label_0x011E] 77 00 <.GameSeq> 2A 16 /*(0x0065/0x0045)*/ 19 00 <.GameSeq> [@] <NullRef> 00 ( 1C <Sequence.FindSeqObjectsByClass> 00 <.InEventClass> 27 00 <.EventsToActivate> 16 ) /*(0x0097/0x0063)*/ 0F 00 <.I> 25 /*(0x00A2/0x006A)*/ [#label_0x00A2] /*(0x00A2/0x006A)*/ 07 [@label_0x011E] 96 00 <.I> 36 00 <.EventsToActivate> 16 /*(0x00BA/0x007A)*/ 07 [@label_0x0110] 19 2E <Class.SequenceEvent> 10 00 <.I> 00 <.EventsToActivate> [@] <SequenceEvent.CheckActivate.ReturnValue> 00 ( 1C <SequenceEvent.CheckActivate> 17 00 <.InInstigator> 4A 00 <.ActivateIndices> 4A 16 ) /*(0x0104/0x00A8)*/ 14 2D 00 <.bResult> 27 /*(0x0110/0x00B0)*/ [#label_0x0110] /*(0x0110/0x00B0)*/ A5 00 <.I> 16 /*(0x011B/0x00B7)*/ 06 [@label_0x00A2] /*(0x011E/0x00BA)*/ [#label_0x011E] [#end] /*(0x011E/0x00BA)*/ 04 2D 00 <.bResult> /*(0x0129/0x00C1)*/ 04 3A <.ReturnValue> /*(0x0133/0x00C7)*/ 53 The idea is that you call it with a "magic number" parameter (in this case 123456) so you can do something with the passed object inside Engine.upk So inside XComGame.upk you'd call it like this: 1B <TriggerGlobalEventClass> 20 <Class.SeqEvent_OnUnitChanged> 17 // self - Pass some sort of object here. Could be anything 1d <%i 123456> 16 Anyhow, that didn't help me with my big head problem. :smile: Now for the good news: The solution I eventually came up with was to simply scale the head mesh as I'd done before. The problem was that scaling the head made it hover above the body model due to everything being bigger. So I had to find a way to 'snap' the head mesh back into place. I modified the XComUnitPawn.Tick function to move the head mesh by the difference between the body's head bone position and the head mesh's head bone position, and it ACTUALLY WORKED. And I'm so happy now. :smile: :smile: :smile: It's here: http://www.nexusmods.com/xcom/mods/600/

Hey wghost - is it possible to add code to a function that has no script code attached? In Engine.upk there's the AppendSockets function which is defined as: // Export USkeletalMeshComponent::execAppendSockets(FFrame&, void* const) native final function AppendSockets(out array<SkeletalMeshSocket> aSockets, bool bReplaceDuplicates); The decompiler produces this: UPK_FILE = Engine.upk OBJECT = SkeletalMeshComponent.AppendSockets : AUTO [REPLACEMENT_CODE] /*(0x0000/0x0000)*/ 29 /*(0x0001/0x0001)*/ 8D 0C <None> <%u 83> <None> <%u 0> <None> <%u 0> Is it possible to modify such a function using Patcher? I'd try it myself but I can't test this at the moment. If it's possible I could modify this function to check for references to the 'head' socket and set the scaling directly.

Thanks for the info. Tricky stuff indeed! If there's a way to make this work I'll find it, watch this space! :)

I think I know how to increase the size of just the head part - but there's a problem! Using UE Explorer to view Engine.upk, we see that SkeletalMeshSocket is defined as follows (notice the RelativeScale variable): class SkeletalMeshSocket extends Object native(SkeletalMesh) hidecategories(Object,Actor); var() const editconst name SocketName; var() const editconst name BoneName; var() Vector RelativeLocation; var() Rotator RelativeRotation; var() Vector RelativeScale; var() editoronly SkeletalMesh PreviewSkelMesh; var() const editconst export editinline transient SkeletalMeshComponent PreviewSkelComp; var() editoronly StaticMesh PreviewStaticMesh; var() editoronly ParticleSystem PreviewParticleSystem; defaultproperties { RelativeScale=(X=1.0,Y=1.0,Z=1.0) } To scale just the head, I'm pretty sure the SkeletalMeshSocket object named 'Inv_Head' must have its RelativeScale value set. The XComHumanPawn.OnHeadLoaded function would have to be changed as follows: simulated function OnHeadLoaded(Object HeadArchetype) { local MaterialInterface SkinMaterial; // End:0x22 if(HeadContent == XComHeadContent(HeadArchetype)) { return; } HeadContent = XComHeadContent(HeadArchetype); m_kHeadMeshComponent.SetSkeletalMesh(HeadContent.SkeletalMesh); m_kHeadMeshComponent.SetParentAnimComponent(Mesh); RestoreAnimSetsToDefault(); UpdateAnimations(); PostInitAnimTree(Mesh); m_kHeadMeshComponent.SetLightEnvironment(LightEnvironment); m_kHeadMeshComponent.SetShadowParent(Mesh); m_kHeadMeshComponent.bAllowApproximateOcclusion = false; SkinMaterial = HeadContent.SkeletalMesh.Materials[0]; // End:0x1B3 if(SkinMaterial != none) { m_kHeadMeshComponent.SetMaterial(0, SkinMaterial); } UpdateMeshMaterials(m_kHeadMeshComponent); Mesh.AppendSockets(m_kHeadMeshComponent.SkeletalMesh.Sockets, true); //*********************************************************************** // set scaling here...? Mesh.GetSocketByName('Inv_Head').RelativeScale = (2.0, 2.0, 2.0); //*********************************************************************** m_kHeadMeshComponent.PrestreamTextures(10.0, true); MarkAuxParametersAsDirty(m_bAuxParamNeedsPrimary, m_bAuxParamNeedsSecondary, m_bAuxParamUse3POutline); //return; } Now the problem is that PatcherGUI returns a 'Bad object name: Engine.SkeletalMeshSocket.RelativeScale' when I try to reference the RelativeScale variable. It seems as if you can only reference objects/functions/variables that are actually used in the XComGame.upk file. I think you can view the available Engine.upk objects by opening up XComGame.upk using UE Explorer, then viewing Objects->Dependencies->Engine. If you do this you'll see that the only object within SkeletalMeshSocket is SocketName. RelativeScale isn't there, thus the 'bad object name' error. Is there a way to access RelativeScale directly via address or something? If not, how do I get XComGame.upk to reference RelativeScale as a dependency? Phew. :smile:

Yikes, that sounds horrendous. I think I'll pass. :)

I'm trying to access it inside the XComHumanPawn.OnHeadLoaded function. If I need to call a function or access a variable I normally search the existing code for examples where they are being used in the way I want to use them. I then decompile those functions using the HexToPseudocode utility and then reference them in a similar way in my mod. I haven't found any references to LocalAtoms anywhere in the code. How would you do it?

I tried that but I get a "bad object name" when I try to use a reference to <Engine.SkeletalMeshComponent.LocalAtoms> with PatcherGUI, so I don't think it's available for use.

I'm giving up on this for now. I've tried pretty much everything I can think of but I'm not getting anywhere. If I detach the head mesh in the code then the head disappears as expected, so that function works. If I then reattach it using the "AttachComponent" function it appears again (attempting to attach it to the "head bone"), but it ignores any scaling, location or rotation transformations sent via the function. From my limited understanding of Unreal it seems that the model has to be set up to support scaling or this sort of thing won't work. If somebody manages to crack the problem of updating the in game models then I might look at this again as I think that's what it's going to take. If the head models meshes could be adjusted so that they sit on the origin instead of floating up in the air then the scaling problem would go away but that doesn't seem to be possible using UnrealScript. Sigh. :(

Thanks for the info. I can only find references to skeletal controllers for the left and right hands - nothing for the head. There is a 'HeadBoneName' reference but I haven't had any luck getting it to scale in any way. The only function I could find that looked like it might work is 'AttachComponent' which allows you to set the relative location, rotation and scale. I tried using this function to re-attach the head mesh to the headbone but it didn't seem to have any effect. The helmet scaling works fine however, so I've made a mod that just scales helmets for now: http://www.nexusmods.com/xcom/mods/600/?

Hi I'm trying to make a "big head" mod for XCom. So far it works ok while viewing soldiers in the barracks: http://imgur.com/a/nsgJn The problem is the head scaling does weird things when applied to soldiers in the tactical game. From what I can tell the head mesh is positioned to line up exactly with the body mesh, so when it's scaled, the Z co-ordinates get scaled up as well and the head ends up much higher. I work around this in the barracks view by using a SetTranslation on the mesh to move the scaled head "back down" so it lines up with the body. This doesn't seem to work with the tactical game and the scaled heads end up floating around weirdly, like this: http://imgur.com/AJ9R2hU If I adjust the translation to position the head correctly for the "standing" animation, it doesn't appear in the correct place when the soldier is crouching or taking cover. I think I can make this work if I can find a way to set the origin/pivot point of the head mesh around (0,0,0) or something similar so that it scales in size without moving, and then "translate" it back to it sits back where the head should be. The problem is I can't seem to find a way to change the pivot point of a mesh using UnrealScript. Does anyone have any idea if this is possible?

Hey tracktwo that looks very promising. How did you inject it?

Thanks for the tip. I found that I had to write at least 4K at a time to get the data on the disk. I'm using this log file in my new "music" replacement mod http://www.nexusmods.com/xcom/mods/584/ I hope this 4K thing works on other PCs too, not just mine... :)

Does anyone know how to force the game to flush its log file? I'm using the LogInternal function which writes to the "..\My Games\XCOM - Enemy Within\XComGame\Logs\Launch.log" file, like this: E7 1F <%t "Log message!"> 2A 16 The problem is this file only gets updated once the game has been closed. I'd like to be able to view the "current" log file while the game is running without having to quit all the way out to see if something worked or not. Is this possible?

I know this is asking a lot but would you consider adding a feature to PatchUPK that would allow changes to text files? For example, to add a new second wave option now the user has to edit XComGame.int and add some lines. Imagine if you could do something like this in the patch file: TEXTFILE=XComGame\Localization\INT\XComGame.int [BEFORE_TEXT] m_arrGameplayToggleTitle[28]="Perfect Information (#28)" m_arrGameplayToggleDesc[28]="You will see enemy to-hit values." [AFTER_TEXT] m_arrGameplayToggleTitle[28]="Perfect Information (#28)" m_arrGameplayToggleDesc[28]="You will see enemy to-hit values." m_arrGameplayToggleTitle[29]="My new Option (#29)" m_arrGameplayToggleDesc[29]="New Option." The TEXTFILE file name would be relative to the selected XEW folder. This could be used to change config and other text based files.

I'd like to update some of my mods to make them custom second wave options. How do I define new ones and how do I check if they are enabled or not? I presume there's a standard way to do this now? Thanks!

Try patching the entire line (not just the variable reference) and put the nops at the end of that instead.

Thanks for the info! This is unrelated, but I'm thinking you would know the answer to this one too.... :) Is it possible to change the type of an existing variable without breaking the game? I know you can change an int to an array of ints, but is it possible to reference a boolean variable as a byte (or maybe an int)? Recently I discovered that it's possible to access "private" variables as if they're public when patching. I'm doing this now with my alien sight ring mod, which uses a private boolean variable as a "global" switch to enable or disable the ring display. If it's possible to reference the boolean as a byte I'd be able to use the same boolean variable to store many different flags.

I've been going through the code trying to figure out how buffs and debuffs are applied to aliens, but it's been slow going. For example, if I wanted to apply a flashbang effect, or a blood call effect to an alien, which variables do I need to modify in the aliens XGUnit class? Also, where is the effect duration stored? I tried to figure this out for flashbangs but I ended up going in circles. There's a particular flashbang class that "applies" the effect based on aliens in the blast radius, but it wasn't very clear as to which variables were being changed. Also I couldn't find any references to the disorientation penalties applied, and there seems to be more than one state of disorientation, so I'm a bit muddled. Can anyone shed some light on how this works?

Thanks, it seems obvious now. I wonder how I missed that the first time. :)

I've found the function UITurnOverlay.IsShowingXComTurn which I thought would do the trick, but it's returning FALSE during the player's turn. Is there another way to tell if the player or AI is currently in control of the game? I want to be able to display something on screen based on who's turn it currently is.