tracktwo

I haven't gotten around to removing the credits from the screen yet, but it's on my list :) Don't worry about creating the custom controls, I can handle that unless you can author the flash yourself because I want them to be very similar to the existing XCom buttons. This means they have some basic animations and such that need to be done in flash and not just static PNGs. They will also need to be scaled to various resolutions (which I still need to figure out, as this UI isn't attached to the map, it floats in front of it attached to the master UI movie and not the material of the map plane). So they should be vector shapes, again PNGs would be somewhat worse for handling the other resolutions. I've already created a basic button that looks fairly similar to the stock xcom ones except it's green. It has a similar glow and pulsing brightness effect applied to it in the mouseover and down states, so I'm reasonably happy with it. I just need to clone it a few times to make up the transport button bar and it should be good to go.

Yes please, send em over, you still have my email, right? While you guys are discussing the "summary" view, I'm still working on the timeline aspect. Current status of the timeline view: The toolbar placeholder there will have controls: a slider to walk through time from 1 March 2015/2016 up to the current game date. Standard controls will be there too: play/pause, stop, faster, slower, step forward, step backward, and seek to beginning and end. These will probably all be custom UI elements, probably using the same green colour scheme as the country box UI borrowed from the satellite launch view. The date in the "country name" box will adjust as time goes by. The map will show a blip for the location of the event just displayed. I figure the box will be able to support maybe 3-4 events, so as new ones come in old events will scroll up and eventually "off" the top of the event box. Blips for each event currently visible in the box will be shown on the map. There will also need to be buttons to switch between this view and the alternates - the summary view you guys have all been discussing and a graph view. Not sure yet where to place that on the screen, as it'll depend somewhat on what the summary view ends up looking like. I'd like for the controls to switch between these to be in the same place for all three so they don't jump around on you when you switch back and forth.

So upon coming back from vacation I discovered that absolutely nothing worked :smile: I had upgraded to b15f just before leaving to verify my exalt VO skipping mod still worked properly and this wiped out my changes to the .ini files and broke everything. I spent a little while today getting this back up and running, which took longer than expected. Here's the story on .ini settings for the custom flash for future generations and for me to remind myself when I upgrade LW and blow away my .ini changes next time. In my case I have 3 relevant files: "CampaignSummary.upk" (the streaming map), "gfxCampaignSummary_SF.upk" (package containing the .swf files), and "XComCampaignSummary.upk" (the script package). The script package needs to be under [Engine.ScriptPackages] in DefaultEngine.ini. I also discovered it needs to be set as "+NativePackages" not "+NonNativePackages". I suspect this is because I also embedded my UI classes in here that are subclasses of UI_FxsScreen, a native class. If you keep the UI stuff separate from the rest, you can probably use NonNativePackages like the other LW extension packages.The map package doesn't need to be listed at all if you load it via a "AddStreamingMap" call in uscript. It seems to locate and load the package as long as it exists somewhere under CookedPCConsole.The graphics package containing the swf to play needs to be associated with the map it'll be loaded from in DefaultContent.ini under [Content.MapContent]. Since I load mine in the strategic layer, I added a line "Package=gfxCampaignSummary" under the section for "Map=Command1". Loading the gfx in other places, eg in the sections in DefaultEngine.ini, doesn't seem to work. And to answer Devon_v: This thread is just to discuss the technical aspects of how to get custom flash into Xcom. It isn't specific to any particular feature, LW or otherwise and is mostly going to be useful for other modders who want to add custom UI to their mods. I'm working on an actual practical implementation of this over on the campaign summary thread.

Hey all, I'm back to the land of internet access. I'm still reading over and absorbing all the stuff that's been posted in the last week. Glad to see all the activity here, though!

Sounds good! So this happened today: The blue box is not post-processing, it's a flash "movie" that I injected into the map during the game. Hello overlays! There is still a lot more that needs to be done here, but that's the first proof of concept at least. What remains to be seen is how much information I can get between my streaming map and the official map. Right now the movie is just triggered on a delay: 10s after the level loads it plays the movie (read: drops a blue rectangle over the view). This can do anything flash can do, including interactive UI elements and scripting. But right now I only have a very limited mechanism to trigger the flash through kismet. If I can programmatically stream a "level" from uscript, that'd basically do it. I think :smile: The best part? All of that flash stuff is done through a real flash environment, then cooked into a map with a little bit of kismet in the UDK. No hex modding needed for the flash bit itself. Hex modding will still be needed to get the game to trigger this new component, though.

I tried reading through this thread but couldn't find the answer ... Is there any special action that needs to be done to a streaming map in order to get it to be loaded correctly? As a quick test I created a basically empty level in the UDK, cooked it, and copied the resulting UDK into the XCOM cookedpcconsole folder, then added the map to the streaming maps array in defaultmaps.ini. On map load, the game crashes with a log saying it can't find the package corresponding to the map (although it has the same name). I don't think I've done anything silly, but am I missing a step here? I can get the same error by renaming one of the patch_XXXXX streaming maps in defaultmaps.ini, but I've double and triple checked that the names are the same. EDIT: I'm not a smart man. I spent all that time making sure the base name was the same and didn't notice that the udk by default names the maps with a .uDk extension, while xcom wanted to find a .uPk extension. Changed that and now it still crashes, but it crashes differently! So, progress? No log this time, unfortunately, so I think the map is just missing something that the game is expecting to find. Related: I tried installing LiQuiD911's github project over my UDK installation and loading up the editor but it freezes at loading engine.u. Anyone had success with this?

I did a little poking around in the situation room map UI and it's populated more or less like the radar was for the motion tracker. E.g. the logic says "put a _hq icon at pos (x,y)" to show the XCOM HQ, or a _jet icon for an interceptor, or a _ufo for an active UFO, etc. All this UI is defined in UICollection_Strategy. So that can all be borrowed for other purposes, sort of like the radar was. Defining new sprites is kind of a PITA though. The timeline for the strategy layer is already basically recorded by the game. Each mission is recorded, along with whether it was successful or not and the list of soldiers that went on it, each of their equipment (primary weapons only so far) and their end of mission HP, what resources were obtained, and what aliens were on the map (excluding dropins). There are similar entries for completing research and projects, buying and selling stuff, etc. This would make a pretty decent high-level timeline of the campaign, although the individual details of the tactical battles aren't there. One thing I was wondering about UI-wise is if it'd be possible to overlay a brand new UI over the existing one via a brand new package and some new unrealscript hooks. Tying new packages into the game was already done via the mutators, so this isn't too unrealistic in general, but I don't know yet how the UI would interact. Defining new sprites then becomes easy, it's just flash authoring. If those can be baked into a .upk like the voice packs were baked into the new custom voice packages, it might be possible to get the game to display the normal situation room map ui and some of the "standard" controls, and then overlay on top of that a bunch of new custom UI elements, e.g. sprites to represent the timeline. I'm going to investigate this a little bit next. If that can work, certain UI edits might become much easier.

Zyxpsilon listed this in the "LW projects" thread and the new roster export mod posted on reddit yesterday gave me some more ideas on this, so I'd like to start a new thread here to flesh out some ideas. Yesterday I wrote a proof-of-concept patch that records shot information into the game journal. The journal is just a big list of strings that records "interesting" events that occur in the game. As far as I know, this journal is never actually read by anything, but it's implemented in the same place as the game statistics are recorded (e.g. days til first colonel, days til first firestorm, etc.). My proof of concept patch records a line for each shot - who took the shot, the percentage chance, whether it hit or not, crit or not, and the target. That's just a first sketch, lots of things can be recorded here as the object that does the recording can be accessed from anywhere in the game. It currently looks like this: RollToHit: actor="Masako Ishikawa" chance=94 hit=True crit=True damage=9 Note: it needs to have the target name listed there too, but I haven't added that yet. Also can show the weapon used. This sort of information is interesting to build up a form of AAR per mission, but accessing it and processing this data from within the game would be very tricky. The data are available, but per-shot information among other things will generate a ton of data and aggregating this data and analyzing it from unrealscript, especially hand-modded hex codes, would be veeeery tedious. I was imagining more of an offline or web-based tool that you can use to visualize this info or do some rudimentary mission replays. What do you all think? Any other ideas on this?

You can read the values by opening up XComGame.upk in the UE Explorer program. Actually changing anything requires writing a hex patch file and applying it with upkutils/patchergui. This is fairly advanced stuff. though. If all you want to do is add a pre-existing perk to a pre-existing item instead of actually changing the inner workings of things, you can do that just by editing the .ini files. DefaultGameCore.ini has all the info. If it was a weapon, for example, search that file for "Weapons=" and find the line with the iType= value for the weapon you want to change. Then look at the ABILITIES array and add the value for the ability you want. Try looking for similar examples in the file and copy those.

XGAbilityTree.BuildAbilities has a lot of the standard properties of various abilities, including what affects they apply, whether they have cooldowns, who they target, etc. IIRC this is a native function in vanilla and was re-implemented in unrealscript by Long War, but I could be wrong on that.

Sounds about right. That's likely the default buffer size in the MS CRT and it won't be system-dependent. Glad it works!

It might not really be easy, it could be the underlying system doing the buffering and you'd need native code to disable the crt buffering if that's the case. On Mac/Linux you could try putting a newline in the string, but that probably won't work for windows. You could also write a bunch of junk to the log to fill the buffer and cause a flush, but that might be hard to read.

Yeah a new topic is probably a good idea as this isn't upkutils specific anymore.

Yeah I decided against making the permanent motion tracker mod a SW option because of the conflict possibility with other mods as well as because they become a little less self contained. For LW with a fancy installer its OK, but people are used to installing mods by loading the patch file in patchergui and clicking the go button. A SW option also requires changes to the .int file for the text, which is a separate step.

Maybe try putting some log statements in there and check the log to help in debugging. the LogInternal function is opcode E7, takes a string and then "none" as arguments. E.g: E7 1F <%t "Log test!"> 2A 16 You can log the floating point pct value by using a primitive cast float-to-string (38 55) and using that as the 1st argument. Then check the log in the Logs folder (sibling to the save folder where your saves go) and see what's going on.

That's odd. Each unit has it's own lowest HP counter, so another unit getting wounded shouldn't impact it. Are you using mind merge at all? That seems like it might be an issue with this logic.

If you paste in the patched function we might be able to help figure out what's wrong.

Yeah, no more posting before coffee for me :) You *can* use this trick when you need to balance out the serial/memory sizes, but this won't help in your particular case. You changed a name reference (8/8) to a variable reference (4/8) and added back in 4 nops (4/4). So you wind up with a total replacement size of (8/12) which is too much in-memory size. This trick is mostly useful when you need to remove a variable entirely - you can't just replace it with nops because the in memory size won't match up. But you can just move it out and stick it as a nop somewhere else. Like wghost says, you can change the function header to re-balance this - just increase the in-memory size by 4. BUT this will alter the jump offsets of any jump later on in the function and will cause many bad things to happen unless you patch all those up too. The better, more scalable way to do this is to replace the entire function and just patch in the piece you want with pseudocode and upkutils will worry about getting the function header right and correctly computing all the jump offsets for you. Dump the function with hex2pseudocode, replace the reference to the function with a reference to the variable and re-apply the patch. Re: the patchergui error, you need to have a corresponding [@] to go with your ( ). Are you replacing the whole function?

You might be able to replace the 5 nops with just a variable reference, eg 01 f4 c4 ff ff. This is just a bare "m_iLowestHP" as an expression by itself and is basically a nop but one that has the right size in memory. This will only work if its a statement on its own, not a subexpression. EDIT: Lack of coffee error. This won't work in this case as changing a name reference to a variable reference means you need to make up 4 bytes of serial size without impacting the memory size. This would make the memory size difference even worse in this case.

Yep, xcom modding often involves a lot of facedesk :smile: Now that you have the patch working you might want to share it here on nexusmods and leave a note in /r/xcom or other places in case anyone else wants to use it too!

Nice, glad you got it working! Like I mentioned earlier, the jumps at the end of if blocks are there to jump over the elses, otherwise it'd execute the "then" part and then fall right into the "else", which is clearly not good. 0xDD7 is the offset following that huge nested else, it's the address of "if (m_kUnit.IsAffectedByAbility(92))" that immediately follows the huge block. You can see this in UE explorer if you right-click on the "ApplyCost" function in the class tree and select "view tokens". Scroll down and you see this: (0xDD7) JumpIfNot(36) -> Context(33) -> InstanceVariable(9) -> VirtualFunction(12) -> IntConstByte(2) -> EndFunctionParms(1) if(m_kUnit.IsAffectedByAbility(92)) The increment is at 0xDB7, just before it. If it incremented fire actions for LeU it'd be a total cost of 1 move + 1 fire, which would be turn ending on the first shot, since it doesn't set the free shot flag. Since there is that dead code there that references the free shot flag but without modifying it it's possible that's how it worked at one point.

Again, you don't want the move check in there. 1. Shoot once, H&R fires: sets fire actions to 1 and sets the free shot flag. 2. Shoot 2nd time, it enters your if because move is 0 and the flag is set, increments fire actions again (now 2) So now you have 2 fires and one free one == turn end. Take that out and it should be (1) is the same, and 2 sets a move action. Now you have 1 fire, 1 free shot, 1 move, for 1 remaining action. Edit: And from my reading LeU doesn't increment the FireActionsTaken variable, that's in an else that is only entered for non-LeU, but it's hard to read due to the crazy nesting of logic there.

Looks like you're missing a function param terminator (16). You only have one at the end of your long || expression before the final close paren, and you need two: one to terminate the ! "function" and another to terminate the || itself. When function terminators are missing the decompiler can get very confused and print bizarre things. That said, I don't think this nested if solution will work: you need to enter the else clause corresponding to the original if (m_kUnit.m_bFreeFireActionTaken), and you won't do this with the nested ifs you have. That's why I suggested the one-level if (m_kUnit.m_bFreeFireActionTaken && !m_kUnit.GetCharacter().HasUpgrade(126)) solution instead. You shouldn't need to test if a move has been taken or not, it won't actually matter if this additional shot counts as a "fire" (if you tested for this) or as a "move" (if you just let it fall down to the LeU code below) because either way you'll be out of actions after it happens. At least that's my impression of how the remaining actions are calculated, I could be wrong on how that works.

I've done a little bit when trying to figure out some of the stuff related to how the native functions build the list of available voice packs. It's quite a bit more difficult than regular uscript modding, though. You need a solid understanding of the x86 instruction set and what compiled c++ code looks like. And statically analyzing the binary is extremely difficult because of all the virtual function calls, the only non-hair pulling way to do it is likely to step through it in a debugger. As a quick starting point, I did this: - Used the free version of IDA Pro to analyze xcomew.exe. Build the list of strings - be sure to include unicode strings - and search for XGAbility_TargetedexecCalcHitChance. There is a string AXGAbility_TargetedexecCalcHitChance, referenced by what appears to be a big table of string function names to function pointers. But I don't think this is what is used at runtime - after starting the game and attaching a debugger a breakpoint to that function was never hit. I suspect this is a data structure used during engine initialization to build up the mappings of native function entry points to their actual code and is not used again after initialization. However, there is also an assertion/error string they left in: "AXGAbility_Targeted::CalcHitChance: Tried to call when Role < ROLE_Authority, returning -1. Ability=%s, AbilityID=%d, AbilityType=%d.". This is referenced from one function, and you can get the function disassembly from there. You can also work backwards from that string to find the printf-style arguments passed in to find the ability id and type. IDA cross-references FTW. - IDA reports this function starts at offset 836F30, and the module has a base offset of 400000. Subtracting the two gives a relative offset of 436F30 to the function entry point. - Ran the game and attached WinDbg to the running process. Use lm to get the list of modules and find the memory range for XComEW.exe. Add 436F30 to the start address to find the in-memory address of the function. Disassembled that location and verified it was the same disassembly as I was looking at in IDA. Great, I've located the function in memory. Set a breakpoint there and continue. - In game I teleported a soldier with TeleportToCursor. After showing up at the new tile the breakpoint was hit a number of times. I just continued execution each time and eventually the game returned to a main loop and I regained control. (BTW, if you only have one monitor, run the game in windowed mode with mouse unlocked so you can easily step through/continue in the debugger without having fullscreen issues in the game) I didn't step through the function itself, but that will likely get you in the neighborhood.

Let me know how it goes. LeU doesn't look like it considers the shots to be shots at all, just "moves". That's why it doesn't increment fireactions nor set the free shot taken flag. The no-op line in LeU referencing the free shot flag looks as though it used to set the flag but this was disabled.