anUser

Yeah, as I suspected. Then I'm not counting well. I was taking the values from UE expl in view tokens, besides each item there's a number which I thought it was virtual size... but there are things I ignore if they should be counted like native functions that only take 1 byte. In this example... (0x000) JumpIfNot(34) -> NativeFunction(31) -> NativeFunction(13) -> InstanceVariable(9) -> IntConstByte(2) -> EndFunctionParms(1) -> Skip(16) -> NativeFunction(13) -> InstanceVariable(9) -> IntConstByte(2) -> EndFunctionParms(1) -> EndFunctionParms(1) if((m_eType == 85) || m_eType == 88)I know the offset is 14 (0E) because I've been trying, but I cannot figure this offset from this. ... and if I were to change several skips, as I pretend, if there's only OR's (A || B || C || D), the first "skip" points to "outside" the condition, so every successive skip token "skips less", right? if I get it all in one sentence I'll try to bring back danger zone perk, as I've realized now this affects suppression area. btw I've been playing for a while with this and grenade random damage and I must say it's absolutely great. I'm playing a new game, got only 4 soldiers and faced a bunch of sectoids... what a difference now, when before throwing a grenade meant killing 3+ sectoids (including psi-link deaths) now it's completely different, you never know if that grenade will even be a kill. I've also reduced damage to 3 to increase the dramatizing effect, and sure it does. A side note, I'm thinking if this were used on other weapons, given they had radius > 0 (I've tested changing it in the ini, it works), this random radius thing could be used to cause accidental friendly fire, or taking it further, make shotguns behave like shotguns, getting increased radius and decreased damage per distance.... if that were possible

... just asking :whistling: cool. It'd be nice if it were as you say and not just GetMonth(), I like really long games and it all gets weird when the year turns, I wouldn't like to face weaker aliens again after a year.

After struggling against OR's, skip tokens and other nasty creatures from the world of hexes, I finally got explosive weapons with an extra random radius. The result may not be very appealing visually, but it indeed works. And this, combined with explosives random damage modlet now defenitively makes grenades something much less certain Function: XComGame >> XGWeapon >> GetDamageRadius Original code: Weapon types 7 and 19 are rocket launcher and blaster launcher, respectively. HasUpgrade(25) is Danger Zone perk, and 192 is 3 tiles wide. What I've done is removing the Danger zone check, and add random extra radius to either grenades and rockets New Code: New code in hex: Code break down: ight now once this change applied, when selecting a grenade or a rocket to throw, you'll see the blue semi-sphere marking the area of effect changing it's size constantly, as if blinking, so you can get an idea of how small or how big it can get, but there's no way to tell beforehand how it will end, no matter the size of the blue area at the moment of throwing the grenade, when it explodes it will calculate it again. Therefor I'm expecting inconsistant behaviour from AI, since they won't be able to tell 100% if a grenade will hit their target or won't, so maybe they'll hold some grenade they could throw or maybe they'll miss the grenade because of different random results. Anyway it should be of minor effect, but I'll report if I see it affecting in a relevant manner. an please someone tell me how those skip token work? I assume they operate like: if previous condition evaluates to true, then skip the rest of checks (useful for conditions with a bunch of OR's, when it's either one or another or another one, so when one evals true just skip that section) but the numbers following the 18 puzzle me. I assume it's also some offset in little endian or however it's called, but the number itself I don't know what it should be. I got it working just by trial and error, but I can't see what it represents... and it's not even multiple of 4. Any clue? edit: typo, copy-pasting, etc

Nice. I assume the regeneration effect wil affect every unit, including mine, right? I've seen there's little room for additions in that function, perhaps you could make it so instead of that variable it reads whether the unit has certain ini property, or is there some other way to set which units have regeneration and which don't? If it were possible to get the extra HP value from DGC.ini's BalanceMods_Whatever and make aliens regenerate that amount per turn that would be awesome. I implemented your damage reduction modlet a few days ago and it seems to work so I'm not touching that for a while :p I defenitively need a hex version converter...

I've been playing for a while with the changes posted here, and made a couple of improvements I'd like to share: 1) Remove scouts and supply ships preceding abduction and terror mission code: XcomStrategyGame.XgStrategyAI.BuildObjectives(): just remove the first line after BuildObjective 5 and 6 (the one corresponding to the first, weak ship). You can replace them for 0B's and it keeps the same visrtual size. Function ends up looking like this: function BuildObjectives() { BuildObjective(1, false); AddUFOMission(1, 1, 4, 0, -1, 7); BuildObjective(3, false); AddUFOMission(3, 1, 4, 4, -1, 7); BuildObjective(2, false); AddUFOMission(2, 1, 4, 2, -1, 7); BuildObjective(4, false); AddUFOMission(4, 1, 5, 7, -1, 1); BuildObjective(0, false); AddUFOMission(0, 10, 4, 0, -1, 5); BuildObjective(5, false); AddUFOMission(5, 3, 6, 5, 0, 0); BuildObjective(6, false); AddUFOMission(6, 20, 8, 5, 0, 7); BuildObjective(7, true); AddUFOMission(7, 1, 9, 1, 100, 0); AddUFOMission(7, 4, 9, 5, 0, 3); //return; }reason: with increased ufos flying around it was kinda too much, and it didn't make much sense to me to have all this ufos that had no other purpouse than fighting my interceptors or defending other ufos on mission. I'm no particular fan of this ufo combat, and although I like it having a tactical component I'd rather focus on ground combat. Still got to play it throughly but in theory it should make I see less ufos flying, and also it'll make if you shot down an ufo to prevent an abduction you'll assault an abductor, not a scout. Not sure if that's good though 2) Give each abduction a random number of destinations code: in XcomStrategyGame.XgStrategyAI.GetNumAbductionSites(): since the SW 4th spot is bugged 'cause UI editing current limitations, the whole function can be used at will. With this code here it first gets a random number within 0 and 4, then caps it up to 3 if it was greater, and caps it down to 1 if it was lower. This way 3 destination abduction got more chances function int GetNumAbductionSites() { return Max(Min(Rand(4), 3), 1); //return ReturnValue; }reason: with only 1 destination per abduction I was able to intercept all of them, so I got no panic penalty, now the idea is that there are some panic you can't avoid unless you have satellites in those countries. Now to the doubts: - I couldn't find where to control landed ufos. Someone has managed to change how that works? - With modified ship weapons, does it work consistently blowing up ufos and not getting crashed ufo mission vs shotting down ufo and getting crashed ufo mission? Does DGC.ini's PANIC_UFO_SHOOTDOWN affects it the same if shot down or destroyed?

Well, since we can't edit constants I assume it should be safe to change those replicationInfo, right? I haven't had any problem so far... Got a couple of questions about items and abilities, and I was wondering if some of you guys have experimented with / succeeding at: 1) Getting extra equippable items (either to be used as a placeholder for ability charges or actually items with abilities, such as grapple, some shiv cannon to be used in the rocket slot ala demolition man, etc. It'd be great too if alien weapons or those eItem_PlaceholderWeapon in XGGameData.EItemType could be used by the player, to make more weapon variants) 2) Removing the perk requirement for some abilities like fire rocket, smoke grenade or battle scanner, thus making those depend only on equipped items (class restriction may still apply separately)

I've always thought it'd be nice to be able to equip more of the cool stuff into your item slot, and today I gave it a try at hex scripting and got it done! :) the function responsible for item charges is in XComGame.XGUnit.UpdateItemCharges() which now I changed to read: which in ('''my''') hex is: and still got plenty of space left to script, almost half file. original hex (in my game, it will probaly differ from yours, but if you check function calls you may see there's the same hex offset for each function reference, so you'd increase or decrease each of the function refs if copy-pasting from my code, or preferably looking at the structure to script it yourself)

Yep, equipping a grenade with the grenadier ability only takes 1 grenade from storage, not 2. Following this sequence I end at releaseLoadout, where the num of grenades don't appear at all. As I said before, it seems to me the game handles separately grenade items and grenade charges, because of the grenadier ability, bacause in UpdateItemCharges() each unit has SetGrenades(num.grenade items), and more. So I think the way to go with this should be: - removing grenade items from units inventory during tactical game, either right after activating the grenade ability or at the end of the mission. - If possible check if ( unit.getFragGrenades() < unit.inventory.smallItems(type(85)) ) to see if num of items on inventory matches grenade charges, and then removeItem if the unit has spent the grenade. I'm gonna try a crude approach, just skipping this line in XGStorage.ReleaseItem(), in the small items check TACTICAL().TInventorySmallItemsSetItem(kSoldier.m_kChar.kInventory, I, 0);so every small item equipped is spent at the end of each mission. It is not a perfect solution, but with appropiate lower item prices (specially armor vests) and before we can remove items on the fly as they're used, it doesn't seem as bad. The choice is not whether using the grenade or not, but rather equipping it or leaving it for further missions.

Another example of how the game treats grenades as item charges. XComGame >> XGAbility simulated function int GetCharge() { switch(GetType()) { // End:0x39 case 40: return m_kUnit.GetGhostCharges(); // End:0x3E case 9: // End:0x43 case 10: // End:0x68 case 42: return m_kUnit.GetArcThrowerCharges(); // End:0x6D case 41: // End:0x72 case 37: // End:0x97 case 36: return m_kUnit.GetMediKitCharges(); // End:0xBC case 22: return m_kUnit.GetFragGrenades(); // End:0xE1 case 24: return m_kUnit.GetAlienGrenades(); // End:0x106 case 66: return m_kUnit.GetShredderRockets(); // End:0x12B case 25: return m_kUnit.GetRockets(); // End:0x150 case 71: return m_kUnit.GetBattleScannerCharges(); // End:0x175 case 23: return m_kUnit.GetSmokeGrenadeCharges(); // End:0xFFFF default: return 0; } //return ReturnValue; }I totaly ignore whether this function is actually called, but it just strenghten my suspicions. Maybe we'll have to code it out inside the tactical game, and check if m_iFragGrenades < getSmallItems[item(85)] then removeItem from inventory/backpack.

I did a bit of research, trying to trace this m_iFragGrenades. Well, first I've checked it works. Function UpdateItemsCharge (XComGame >> XGUnit) calls SetFragGrenades, which is the setter for XGUnitNativeBase.m_iFragGrenades. And changing this WORKS. I've tested giving 3 grenades with grenadier perk and it works, so the variable is readen in the tactical game, and changing it affects number of grenades. But then I also made a search through XComGame.upk and XComStrategyGame.upk searching for key words "frag" and "gren", in hopes I'd find something to correlate those variables in the strategy game but I couldn't find anything related, so that makes me think the game no longer cares about m_iFragGrenade once the mission is finished, and the only thing that matters is the item equipped in the slot. Anyway I've found this in XGUnitNativeBase replication { // Pos:0x000 if(bNetDirty && Role == ROLE_Authority) m_aAbilities, m_aAbilitiesAffecting, m_aAbilitiesApplied, m_aAbilitiesOnCooldown, m_aCurrentStats, m_aHeightBonusStats, m_aInventoryStats, m_arrBonuses, m_arrCiviliansInRangeReplicated, m_arrEnemiesEngagedByReplicated, m_arrEnemiesInCloseRangeReplicated, m_arrEnemiesInRangeReplicated, m_arrEnemiesRevealedWhileMovingReplicated, m_arrEnemiesSeenByReplicated, m_arrFlankingUnitsReplicated, m_arrFriendsInRangeReplicated, m_arrFriendsSeenByReplicated, m_arrPassives, m_arrPenalties, m_arrSuppressingEnemies, m_arrSuppressionExecutingEnemies, m_arrSuppressionTargets, m_arrVisibleCiviliansReplicated, m_arrVisibleEnemiesReplicated, m_arrVisibleFriendsReplicated, m_bBattleScanner, m_bForceHidden, m_bHasChryssalidEgg, m_bInCombatDrugs, m_bInDenseSmoke, m_bInSmokeBomb, m_bIsInOverwatch, m_bRunAndGunUsedMove, m_bSprinting, m_bStabilized, m_iAlienGrenades, m_iArcThrowerCharges, m_iBattleScanners, m_iBuildAbilityNotifier, m_iCurrentCoverValue, m_iFireActionsPerformed, m_iFragGrenades, m_iGhostCharges, m_iImmuneToDisable, m_iMediKitCharges, m_iMoves, m_iMovesActionsPerformed, m_iNumAbilities, m_iNumAbilitiesAffecting, m_iNumAbilitiesApplied, m_iNumAbilitiesOnCooldown, m_iNumOfBonuses, m_iNumOfPenalties, m_iNumTimesUsedInTheZone, m_iNumTimesUsedPistolInTheZone, m_iPanicCounter, m_iRift, m_iRockets, m_iShredderRocketCtr, m_iShredderRockets, m_iSmokeGrenades, m_iTelekineticField, m_iTracerBeamCtr, m_iUseAbilities, m_kArmor, m_kBehavior, m_kCustomAbility, m_kDynamicSpawnedBattleScanner, m_kDynamicSpawnedSmokeGrenade, m_kPlayerNativeBase, m_numSuppressingEnemies, m_numSuppressionExecutingEnemies, m_numSuppressionTargets // Pos:0x020 if((bNetDirty && !bNetOwner) && Role == ROLE_Authority) m_bDashing, m_bReactionFireStatus // Pos:0x051 if(bNetInitial && Role == ROLE_Authority) m_kCharacter, m_kNetExecActionQueue, m_kPathingPawn, m_kPawn, m_kSquad }dunno what replication is, but it's the only place where that m_iFragGrenades var is referenced besides it's getter and setter

I'm still failing to see how can I get the hex code for a function call given that I only knew function's name, class and package, without actually having to find a call to that function within some other function and then copy-pasting it's hex representation. Hence that I asked for that list UE Explorer seems to use internally, actually I'm asking for the shortest/fastest way from point A) I've got a function name, to point B) I've got the hex code to call that function. I think there has been some missunderstanding, I hope this makes it clear. If what I'm asking has already been answered and the missunderstanding is mine then I beg you excuse me, for I totaly fail to understand it.

Bravissimo!! Great finding! Time to start making a list of usless functions to gather up space for useful stuff. I'm looking forward to see an implementation of it removing grenades after use I wonder if variables are stored in a similar way, and if this finding could lead to the creation of new object or function local variables. Also it'd be great if this list can be extracted somehow so we know it's hex representation beforehand. Does UE Explorer tell that?

I really like the concept... it makes more sense, moreover many times I run out of sectoids if I've got to sell them early in the game... I wanted to re-do techs and foundry projects a bit too, and I'll definitively incorporate this into my game. I def can give you some guidance on how to change the code yourself (yesterday I managed to get jumps to work! yay! and found that switch cases follow the same pattern), but I can't post my code since it wouldn't work on your game. I guess the main difficulty lays in adjusting those lines with multiple items that now only require 1 and vice versa, so if I may suggest, you could try to change the order in which things appear to make use of current structure (ie, if tech110 has item1 and item2, and tech112 has only 1 item, and you want it the other way, instead of re-writting those two sentences just change the order in which they appear, so first tech112 with 1 item, then tech110 with 2 items. It's a theoretical example, I actually haven't gone deep through the code). I know it's not perfect but it's a bit more you can do without changing jumps and offsets (it's like if you change the shape of the sentences [not the content], you got to tell the game where some relevant sentences start, since their position has been moved, kind of). If you're interested in re-scripting there's tons of examples and useful stuff in this thread, or maybe some modder with the latest patch will mod it out since it's a cool idea. Btw, as it seems to me you're already familiar with stuff involving research, foundry projects, items, etc, could you please post those, or the class where they are defined? I'm asking 'cause I assume you've got them in a text file, if you don't then don't worry I'll search it myself edit: typo

... I wonder if when we finally locate it, there will be some way to tell wether the soldier has the item (grenade) equipped, and wheter that item has some charge left, if that's how the game processes grenades too... edit: sry, half post got erased before posting. I see... well, actually it sounds promising, as long as what I've said avobe isn't true, ... is there some problem calling functions from other classes or packages? Is that some sort of unexplored terrain? It'd def be great if we could use that (or some other function) to process loadout and make grenades and medikits gone

The infinite items stuff doesn't seem to work... The function I mentioned before is in XComStrategyGame.upk >> XGStorage >> GetNumItemsAvailable(), which reads: function int GetNumItemsAvailable(int iItemType) { // End:0x21 if(IsInfinite(byte(iItemType))) { return 1000; } // End:0x4A else { return m_arrItems[iItemType] - m_arrClaims[iItemType]; } //return ReturnValue; } Attempting to change this failed because my lack of knowledge of jumps, BUT I managed to change XGStorage.IsInfinite() to read function bool IsInfinite(XComGame.XGGameData.EItemType eItem) { return 0; } That was (note it may differ from your code on the first 6 bytes) SF: 65 40 00 00 A9 1F 00 00 00 00 00 00 63 40 00 00 00 00 00 00 00 00 00 00 65 40 00 00 00 00 00 00 29 00 00 00 5F 05 00 00 29 00 00 00 1D 00 00 00 04 9B 46 01 5F 40 00 00 0A 00 00 65 40 00 00 16 1D FF FF FF FF 16 04 3A 64 40 00 00 53 00 00 00 02 00 02 00 78 14 00 00 00 00 00 00 RW: 65 40 00 00 A9 1F 00 00 00 00 00 00 63 40 00 00 00 00 00 00 00 00 00 00 65 40 00 00 00 00 00 00 29 00 00 00 5F 05 00 00 1D 00 00 00 1D 00 00 00 04 25 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 53 00 00 00 02 00 02 00 78 14 00 00 00 00 00 00 In this case I assumed virtual size would be identical to fisical size since there's no extra reference and there are only 1 byte elements (4a - return, and 25 - 0 or false), is that how it works? Anyway, the case is that I got 100 of everything, so in stock there's always 100 minus what my soldiers have equipped. I played a couple of missions but I always get the same amount (81 in my case, as I got 20 soldiers but 1 is wounded from 1st mission), no matter how many grenades I spend... I *think* the key maybe in some "release loadout" function, like this in XComStrategyGame.upk, but I think I've seen similar functions for the skyranger and it may be well tangled, so who knows. XGStorage.ReleaseLoadout function ReleaseLoadout(XGStrategySoldier kSoldier) { local int I, iItem; ReleaseItem(kSoldier.m_kChar.kInventory.iArmor, kSoldier); kSoldier.m_kChar.kInventory.iArmor = 0; ReleaseItem(kSoldier.m_kChar.kInventory.iPistol, kSoldier); kSoldier.m_kChar.kInventory.iPistol = 0; I = 0; J0x145: // End:0x261 [Loop If] if(I < kSoldier.m_kChar.kInventory.iNumLargeItems) { ReleaseItem(kSoldier.m_kChar.kInventory.arrLargeItems[i], kSoldier); TACTICAL().TInventoryLargeItemsSetItem(kSoldier.m_kChar.kInventory, I, 0); ++ I; // [Loop Continue] goto J0x145; } I = 0; J0x26C: // End:0x39B [Loop If] if(I < kSoldier.m_kChar.kInventory.iNumSmallItems) { iItem = kSoldier.m_kChar.kInventory.arrSmallItems[i]; ReleaseItem(iItem, kSoldier); TACTICAL().TInventorySmallItemsSetItem(kSoldier.m_kChar.kInventory, I, 0); ++ I; // [Loop Continue] goto J0x26C; } //return; } XGStorage.ReleaseSmallItems function ReleaseSmallItems(XGStrategySoldier kSoldier) { local int I; local XComGame.XGGameData.EItemType eItem; I = 0; J0x0B: // End:0x156 [Loop If] if(I < kSoldier.m_kChar.kInventory.iNumSmallItems) { eItem = byte(kSoldier.m_kChar.kInventory.arrSmallItems[i]); // End:0x148 if(!IsInfinite(eItem)) { ReleaseItem(eItem, kSoldier); TACTICAL().TInventorySmallItemsSetItem(kSoldier.m_kChar.kInventory, I, 0); } ++ I; // [Loop Continue] goto J0x0B; } //return; } I recall seeing one of those with a specific check for grenades (item 85, right), but man, it gets hard to trace someone else's code Btw, now I realized that my last comment was a complete stupidity, since armors and weapons are not consumible ... my bad... well, maybe knowing that it can be done we could give it some use now. Overheated weapons and critically hit armors rendered unusable (ie vanishing after mission)?

That disctinction is already made by means of categories, there's the Tutorials XCOM Modding category which hopefully will eventualy host hundreds of useful documents :p and there's what I came to call "Modding Subjects", which are categories (each with a front page) to group any kind of knowledge from a specific subject all together, with the intention that, rather than posting and decoding whole mods in series of step-by-step tutorials we could have it all at once, and let the user/modder choose which bite of info s/he needs at the moment. Here's an example of what I mean: Abilities (XCOM modding subject), so here you get a front page for one specific modding subject (this one could be expanded with detailed explanations) and below you get the links to every related entry on the wiki. That's what I came to think it could be the most useful, not only for beginners that can just jump to the replacement codes section (once it's set up :() but also for modders because they can see what functions are involved, get a quick reference for enum values, etc. But yeah, tutorials are essentials, and articles about how to implement all the changes from a mod won't hurt either; I'd just try to keep "procedural" info together, perhaps in the shape of a tutorial (the how-to info) while keeping those copy-my-mod-step-by-step tutorials as just a list of function names and hex codes changed, for the sake of not repeating the same in different places. But well, that's just my oppinion, let me know yours.

This is good news. I'm still digesting most o the stuff here, and keep updating the hex edtiting tutorial on the wiki, though I structured it as a tutorial and the content is more fitting for a manual, I'll give it another go when I make sense of jumps and gotos and see then how to re-structure it. Nevertheless, if there's some bit of knowledge you consider 100% solid, no matter how small it is, don't hesitate posting it on the wiki, I'll keep an eye they get linked properly, just add the [[Category:XCOM Modding]] text by the end of the page. I realize we'll have to wait until there's a critical mass of content on the wiki to judge it's usefulness, no hassle here, luckily I'll finish the tutorials by the time your research is done, but anyway I'd appreciate some tought, even theoretically speaking, of how to structure entries and their content, specially upk data, like functions, classes, etc. I've posted above a standalone html/javascript app to get enum values, it crashes when loading tons of files at once but for the rest seems to work in modern browsers. If something like this but more elaboraed could be usefull I take requsts on this, it could even be ported to php to be integrated into the wiki, if that's possible.

Well, so far I've been trying with little success to document current code, so documenting changes between versions seems to me far beyond comunity willingness, alhough in my experience I've found that most changes are related to deleted variables which change the ref value to other variables and functions, so you've gotta decrease those values in the same amount, so in theory, if keeping the original code it could be possible to extract a pattern by mere string comparisson, but that's alot of work I'm not taking now, though it seems perfectly doable, and it'd be pretty useful imo

Yesterday I only managed to make storage unaccessible :( I've found this functions getNumAvailableItems, getInfinitePrimaryWeapon, and avobe all isInfinite. Can't remember the class or upk now, I think it's xgstorage something, or xgfacility_barracks, but I need a better understanding of jumps and gotos to get it skips those checks. If it is so simple as that we could take it to it's maximum exponent and make EVERY item consumable, including basic armor and weaponry, I'll def do it for my game. I'll post the functions on the wiki when I make it home, unless yoi get it before

I see... so basically we're hex editing inside the upk's, but with the handicap that we must use ActionScript to change those parts, isn't it? Well in any case it's good to know edit: unfortunately I'm not familiar at all with AS. I do web programming but now they only teach us html5. Flash is kaput! :)

I'm not sure I get what it means exactly or the implications it has. Is it only for UI editing and cinematics or could we actually write functions (in plain text) in actionscript and then call them from within the upk (given that we hex program a wrapper function in the upk)? If so, could it reach further than UI and cinematics?

Partial success editing this two functions. With the code Yzaxtol posted grenades can be built, and removing the whole line m_arrInfiniteItems.AddItem(85); for 0b's worked on new games, not saved ones. Though I started with 100 grenades in stock, and every grenade was automatically spent at the end of the mission and new ones already placed in soldiers slots (at least that's what it seems, I just finished the 1rst map and got 82 grenades left in stock). I've tried it with frag grenades, haven't seen yet where's the call for infiite alien grenades.

I've found this in XcomStrategyGame.upk >> XGStorage, but I can't seem to find the items list. Not sure if it will remove 'em or what, I guess they'll have to go to m_arrItems instead. function Init() { m_arrItems.Add(195); m_arrItemArchives.Add(195); m_arrClaims.Add(195); m_arrInfiniteItems.AddItem(57); m_arrInfiniteItems.AddItem(3); m_arrInfiniteItems.AddItem(4); m_arrInfiniteItems.AddItem(2); m_arrInfiniteItems.AddItem(85); m_arrInfiniteItems.AddItem(6); m_arrInfiniteItems.AddItem(5); m_arrInfiniteItems.AddItem(7); m_arrInfiniteItems.AddItem(57); m_arrInfiniteItems.AddItem(124); //return; }

I totally missunderstood that when I first read it... well here you are! I've made a crappy standalone web app in javascript, it's crappy, it uses html5 local storage and globals as well, but it should work, just input the decompiled XGTacticalGameCoreData or all the files you want and type in a number. When focus is out (just click anywhere) it should perform a search for every element with that index within enums. only enums now. copy-paste this into a text file, rename it as an .html file. let me know if it works as it should edit: formatting

Edit: that wasn't very constructive, nevermind