Zybertryx

Hi Amineri, I implemented the last upload of your Expanded Perk Tree Modlet for EW using UPKModder (including the two files prefixed with double underscores, but not including the gamepad folder files - as found here) And though it appears to be fully functional and configurable via the DGC (which is great) it displays some UI symptoms of 'entanglement' with LW code (which you did warn about). Firstly, when browsing Soldiers from within the barracks there's an expanded display window for various attributes with some snazzy icons (note I had previously included the 'Display Mobility and XP in Barracks' modlet in the captured image as I wasn't expecting the EW Expanded Perk modlet to influence this). I really like this use of icons over text for HP, Mobility etc, so I'd either like to make it properly functional by making the 'undefined' values display the correct amounts or simply revert to Vanilla instead. Any help in either case would be sweet (I'll of course remove the redundant 'Display Mobility and XP in Barracks' modlet if the former is doable). Secondly, and more of a serious issue, when choosing a squad for mission deployment the UI appears provisioned for LW's eight+ Soliders by default and thus Vanilla's initial four-to-six options are quite severely right-shifted on screen. (Note that the fifth and sixth 'slots' are not accessible at all). Looking over the code it's not clear to me at all what is governing this (it's a my-end issue) :confused: I'm basically recreating my old EU Patch 4 mod for EW and most of the basic rebalance and a host of less complex features are complete. In the meantime I'll go back to playing current Long War which is truly great and is far better realised (imo) than the versions I was last familiar with a year ago. =) Fantastic work as always from yourself, Johnny and Ghost. Inspirational. Cheers. PS: Aggressively-Psionic-Sectoids is pure gold!

This is truly fantastic work Ghost, a bona fide must-have feature. Thanks a lot for making this public.

Hm, you know doing it via the DGC since EW is actually comparatively not tedious. The former method - 100% HEX side - was an ordeal which is what spurned the talented Bertilsson to create his web tools in the first place. You can still use the web tool currently as a very helpful 'visual map' of how you want your perk trees to look and then simply manually edit the corresponding DGC entries per class to match it.

I'm not actually sure (I haven't even touched XCOM for about 6 months or more) and only really progressed a little beyond 'dabbler' status even then but it looks to me that the third set of integers for each entry is the time it takes to go through the gene manipulation process in game hours. Example: BuildGeneModTech(4, 44, 72, 8, 15, 155); 72 hours = 3 days Should be pretty painless to change by finding the specific HEX string in UE Explorer' buffer view then doing an old school "Find/Replace" using HxD.

I too use the _ShotSuppress ability for Assault Rifles via the DGC alone but it appears to cause a graphical glitch whenever the Suppressor is behind full cover and someone else kills the alien he was Suppressing. They (the Suppressor) become 'twisted'; looking over their left shoulder while their weapon points to the right (and is held awkwardly). It appears that they correct themselves only once they move into a new High Cover position - it sure is unsightly in the meantime however. I implemented Amineri's comprehensive EW Suppression Bug Fix modlet assuming that was the answer but, although the "getting-stuck-one-tile-from-cover when their Suppression ends issue" no longer occurs, this graphical/skeletal anomaly remains. Is this a known issue with Suppression via the actual perk too (Vanilla style) or is it specific to using eAbility_ShotSuppress on a weapon entry in DGC? And, does anyone know how to fix it?

Yikes, though SOLVED thanks to Bertilsson's "Downgrade EU to Patch 4" app available at the Nexus here. Amazing work, Bert, it's like the EW launch never happened. It's quite devestating to learn that the EW update to EU has broken all the major mods. I assume everyone is busy modding EW from the ground up then eh? Ouch. :\

Hi guys, I'm back! I stopped playing XCOM after a lifestyle shuffle and burning out after finally modding my own version to relatively polished completion. Then EW was released and my EU was auto-updated (after a careless online launch on my part) (4 gigs or something!). Now my mod no longer works (crashes instantly) and as it's been so long since I was dabbling HEX-side I'm hoping there's a simple solution. So, did this Decemberish 2013 update break everyone's mod too, and if so, how'd you fix it? Note: I don't have EW at all, just updated EU. To recap: 6 months ago, mod was finished and awesome, working issue free. 1 month (or so ago) EW Patch/update to EU happened. Now Insta-crashes on launch even after verifying cache, offlining Steam, reappling mod, modpatcher (for the DGC) and toolboks (for the perks, tweaks and hash check skip thing). That which was formerly fine, now isn't. :sad: Simple fix or worst case scenario? :sad:

Excellent, cheers. Very helpful and compatible with my .upk.

Hmm, this sounds pretty cool, thank you. "Note that this leaves Foundry project 12 as an "empty" project that has no game effect. However, this allows for another Foundry project to be put in its place -- presumably one that will have a greater game effect (my own personal favorite is an interceptor / firestorm upgrade)." Do you happen to have this on hand?

Part 4b: The Completed Code So, after a bit of deliberation, consternation and procrastination, I've finally nailed down exactly how I want Hidden Potential to work for each of the four classes. Although this is tailored explicitly for my own balance I'm hoping that this can act as a template that anyone can modify to suit their own tastes. There's also much more content than the original entries contained and that was a slight concern due to the byte limits which constrain us. After careful investigation it appears it will all fit. It's really very fortunate that this function happened to contain so much dormant garbage. First up, the Sniper class. It largely mirrors my non-Hidden Potential DGC settings (offering only a modest amount of randomisation against that measure) but it will suit me fine. By using a combination of Token and Buffer views on the existing Vanilla function I've been able to piece together exactly the kind of 'phrases' I need to produce the intended results. The first part of my working .txt now looks like this: This continues on for the other three classes each with their own flavour and values. For example, I've given the Heavy an additional unique entry, to ensure they are immediately saddled with a -1 Mobility hit. This was done to add a little flavour to the Rocket Launcher. A robust list of various Hex tokens and their functionality can be found on the Nexus Wiki, here: http://wiki.tesnexus.com/index.php/Hex_values_XCOM_Modding Note, that there are sometimes different ways to write the same thing but that some functions or calls prefer one way to the other. If in doubt have a look for the token in the other sub-functions of the parent function in UE Explorer. If you find it used a certain way there, it's probably best to use it that way yourself. Also note that many of these require their own "16" executor. The mouse over tool tips of UE Explorer's Buffer View can really help to determine what kind of token is appropriate and which require their own executors. With the complete line-by-line breakdown of my custom hex finished, it's time to prepare it all for a find/replace splice into the Vanilla function. Before we do that though, we need to ensure that our new code is the same byte size as the section we are replacing. If you're over that limit, then its hopeless; the original byte size of the function cannot be exceeded. But if you're under that limit, and we are, then we can 'puff up' our code to the necessary size with use of Null Operators; dormant "filler" code that will ensure our rewrite contains the same number of bytes as the code it replaces, but which will be totally benign and ignored by the engine. More on this in the next section. --------- Continues Below ---------

Hmm, the more I think about this the more I agree that in hopeless situations like those described the alien should move even if it results in death by reaction fire. I mean, what would a human player do? Sit there and overwatch only to be captured alive and grant XCOM a free pwngun? It would mean that capturing is still possible against wounded aliens with friends on the field (thus increasing the risk and game-within-a-game for XCOM - always a good thing) but it would reduce the "last Alien is free RP and weapons" thing for experienced Arc Thrower laden squads. I imagine it could result in some memorable gameplay moments too, with pinning a wounded rat only to have him bail and survive, getting the pin again and this time his dash results in reaction fire or suppression death. "The one that got away". I'm all for it.

"I think Zybertryx's tutorial will be the first step for people trying to learn how to make hex changes more significant than single-value changes. Within that category I'd say that being able to manage skip tokens to build more complex boolean constructions is an 'intermediate' level skill." I agree with this, it's the precise intention. This skip stuff is beyond me currently and I failed my first boolean attempt; I'm still working with simple if statements and relatively tidy nests (and that's great, I've done some cool and unique things already). I'm hoping that my tutorial acts as a foot-in-the-door for those who are filled with desire but frustrated with the seeming unassailable learning curve concerning the even decompiled code, let alone the hex. Also, as I said when I first got into this scene, the wiki I'm sure is great for the technically savvy, but for a lot of 'mere' gamers it seems an unfriendly bludgeon. I'm trying to add as much "101" type stuff as I can when it comes up during the exercise, and I think, as has been my experience, that the more basics I click to, the more accessible (and relevant) the information on the wiki becomes. So, rather than dumbing down the wiki, I'm trying to skill up some noobs (myself included) and maybe entertain some bored pros with my quips. :wink: This is cool stuff though, great to see Amineri offering new modder-side enhancements and insights (like this and the renaming of functions recently).

Part 4a: Constructing The Replacement Code At this point we can start constructing the replacement code. Using Token View we can easily isolate and grab the various parts we need, and using some inference, Buffer View, and by generally paying attention to things, we can use these pieces to construct new 'phrases' we'd like too. I've decided I'm going to order the classes as Sniper, Heavy, Support and Assault as each of these corresponds to the case call "1", "2", "3" and "4" respectively. So, based on the road map of the previous section, lets start constructing our new code for the Sniper class. If you recall, the necessary sequence for a class specific Hidden Potential code was: Working from that model, I've grabbed a bunch of entries from the token view in accordance with the above sequence: --------------------------------------- It's important to note that with crude grabs like this, some of the information taken will be problematic for us when we splice it in. This is par for the course when modifying a large section like this though. In particular the jump references for Vanilla are specific to the precise locations of everything else in the Vanilla function. Our reworking/rewriting of things is going to throw all that way off. That's okay and it can (and must) be fixed up later (though that part is not fun). If you've had a bit of look at Token View in your own time you've probably noticed that all "if" statements begin with an "07" and then two more bytes "F4 01" (an example). It's the 07 # # that constructs the "if". Technically these are "jump-if-not" Tokens. That is to say that, if the following conditional is false then jump away (to the position defined by the subsequent pair of bytes). These bytes are "Little Endian" and you'll need to take that into account when working with them (which we won't be dong in this section but as they're so important and really need understanding I thought I'd write a little primer for them here). What "little Endian" means (at least to me, in practicality) is that you write them in reverse order. So "F4 01" points to the position "1F4". Similarly, "07 3D 04" would point to the position "43D". This is the same for unconditional jumps too, which are all "06 ## ##" in style. So. "07 9C 02" = Jump-to-29C-if-following-is-not-so. And, "06 53 01" = Jump-to-153-unconditionally. --------------------------------------- You can change the 'meaning' of a conditional (turn them into "Is Not" statements, rather than "Is" statements) by adding an "81" immediately following the jump token and prior to actual variable. The "81" token requires its own 'executor' - a "16" - which should be placed at the end of the completed 'hexphrase' (even if for other reasons a "16" is already present). Example: That was just an example and we won't be molesting our if(bRand) statements at all but we will be modifying a lot of our 'grabs' to suit our intended functionality and values. On that note, let's continue. I grabbed (and pasted into a fresh.txt): But some of that should be changed right now. Firstly, the "case 4" entry should be changed to "case 1" (from Assault, to Sniper). This is easily accomplished, a simple thing. The other part from this initial grab I'd like to change is the "statOffense = 1 + Rand(5)" line. That's far too generous, even for Snipers, for my taste, so I'm going to change it to "statOffense = 1 + Rand(2)" Like so: Next up I'm going to grab one of those cool "X% chance of getting statboost X" lines and paste it in my .txt right after the just modified "statOffense = 1 + Rand(2)" line and before the "goto J0x598" jump. Then I'm going to grab another "StatOffense" and marry it to a "+=" to give significance to the roll. I'll clean up all the Token View clutter too so that's its nice and legible (and ready for an eventual stringing together of just the Hex components). Now, we do have limits to what we can add for each entry byte-wise, but as I've run through this mod previously I know you can get away with three additional (and simple) sequential entries per class without any trouble. I'm going to go and have a think about what I really want Hidden Potential to do for my classes long term, and map out each class on my .txt., sequentially adding the buffs and values I'm after and in an order which will match the conceptual road map of Part 3. I'll post the results and discuss any lines I had to create that haven't been covered already, in the following installment. --------- Continues Below ---------

Part 3b: Road Mapping. Now that we've separated the original hex into three parts (two we are going to keep and one part we are going to replace), we need to start getting an idea of how our replacement code should look, or how it should 'fit'. For me, based on my DGC.ini rank settings, my plans for Hidden Potential are a little more complex than vanilla. That's fine, though one problem with increased complexity in refactoring is that it compounds that the amount of stitching required after the splice. For now lets march ahead. Based on our Token view of the original function we can see the breakdown of the different calls and we can use these to create a new sequence more tailored to our particular needs. Before we get too carried away though, lets take a good look at how Vanilla tied it all together as this will save us a world of pain later on if we build it into our code now. This is perhaps the most important part of the whole process, understanding how we can make our code work, even if we don't understand much about the particulars. These three entries offer us a bit of a road map on how to begin our custom code. Note: If you recall, the first line, - switch(m_kSoldier.kClass.eType) - should be the final line of hex in the "Header" section of our saved .txt. which we're keeping. Check out the sequence here, It goes: And. . . if we scroll down in our Token views to the end of the seven Vanilla rank cases (case 1 to case 7, which we don't want and won't keep) we see this sequence: Putting these two sequences together gives us: Finally we need to look at how Vanilla 'closes' each specific Class entry, so we scroll down under the last of the level boosts for the first class to position 14F - (1F4/170) - in our Token view, and we see: Cleaning this up conceptually we see: And if we scroll down further we will see the beginning of the if(bRand) section of this new class preceded as before with a "default:" entry like this: And if we put all of this together we see: Continues until we have four cases (one for each class) with each ending in an 06 ## ## "goto" unconditional jump. Now that we've have a clear 'road map' on how the vanilla code tied the "Remove" part (which we are about to completely replace) into the "Header" and "Keep" parts (which we've separated in our .txt.), we can at last begin construction of our new code in confidence. --------- Continues Below ---------

Part 3a: Let's Organise Ourselves. The next step is working out what we're going to remove to make room for our changes and what we need to keep to not break anything. It's probably a good idea to go to UE Explorer's "Buffer View" at this point. Select the tab "Edit" from the Buffer View menu and then select the option "Dump Bytes." This copies the Hex for this entire function to your clipboard, where you can easily paste it to a clean .txt (notepad). Switching back to UE Explorer's Token View, at the position 0x08F we can see the first switch to the Class case: The highlighted Aqua (08F) is the position of this line. Paying attention to positions is not all that important at this stage but it will become much more important after we have spliced in our replacement code. Everything above this line we are going to keep unchanged. So highlight and copy the relevant hex for this line and then do a search from the top of your "Dumped Bytes" in your .txt. When you've found it, separate it (and everything preceding it) from everything immediately following it. You should have divided the entire function hex block into two pieces now; a smallish piece which ends with "(continuing to) EC 44 00 00" and a much larger piece which starts with "0A F7 01 24 (continuing on)". Now, that we have 'protected' the upper part of the function, lets isolate the lower part of the function we also wish to preserve. Back into token view, we want to scroll right down to the entry at position 0x598 because that's where all the superfluous Vanilla stuff and the nasty Vanilla Hidden Potential stuff ends. Note the exclamation mark in "If(!bRand)" is a "NOT" flag/token. I'll explain this in a little more detail later, but for now it will help to know that this exclamation mark is changing the meaning of this 'phrase' to "If(NOTHiddenPotential)then. . " The stuff below that point is the all the stuff that actually is used when Hidden Potential is not enabled (it refers to the DGC.ini). We want to keep "If(!bRand)" itself and everything after it. So, copy the relevant bytes for "If(!bRand)" - 07 6A 08 81 2D 00 23 45 00 00 16 Do a "Find" in your txt for it (it is a unique instance in this function - there's only one) and then, once found, separate the beginning of it and everything after it from the rest of the dumped Hex. You should now have separated the "dumped bytes" into three distinct parts. 1) A shortish top part which contains the beginning of the function and ends with the first Class call - 05 30 FF FF FF 00 35 30 FF FF FF 7D FA FF FF 00 00 35 B4 F9 FF FF 74 FA FF FF 00 00 01 EC 44 00 00 2) The largest chunk which starts with 0A F7 01 24 04 05 73 FB FF FF (continuing until . . .) 3) Another largish chunk which starts with 07 6A 08 81 2D 00 23 45 00 00 16 (continuing to the end) The largest chunk is the part of the function concerned with the unreferenced Vanilla DGC values as well as Vanilla's actually-referenced "Hidden Potential" mechanics (which we intend to completely customise). Don't delete it from your .txt though! It's important to hold onto as when using "word wrap" in Notepad it can help us to ensure that our replacement code will be exactly the same size. It might be best to name and save your separated "dumped bytes" .txt now. I'd also name the chunks; "Header" for the smallish first chunk (though it's more than just that), "Remove" for the large middle chunk, and "Keep" for the good sized lower chunk (or whatever's good for you). Next, we'll nail down a working road map so we'll be able to work out the structure our new code should take. Following on from the road map of the next section, we'll lay out how we want our new mechanic to work, hex-line for hex-line, and I'll stress the importance of sticking to Vanilla's conventions as we do so (especially if we barely understand them). --------- Continues Below ---------