aggies11

That's a super useful/great idea. As someone who has to deal with pretty strict data limits, and develops on a different machine that I build on, the large size of the SDK is a pretty prohibitive download, which makes me have to be very careful about updating. (I actually had to wait until the next billing cycle in between downloading the game and then SDK, and even then it still ended up costing me some extra overage charges :/). A resource to at least know what has changed, and see what's different would be extremely appreciated :)

As amineri said, it's likely to due with the specifics of overriding and how object inheritence etc all work. A way I find helpful of thinking of it. X2AbilitytoHitCalc.uc is actually NEVER used by the game. What it is is a specification for a "generic" kind of toHitCalc object, a blueprint if you will. It's actually the CHILD SUBCLASSES of X2AbilitytoHitCalc.uc (eg. X2AbilitytoHitCalc_standardaim or X2AbilityToHitCalc_StandardMelee etc) that are used in the game. They follow this specification or blueprint of the parent on how to "properly" setup/create the idea of a "toHitCalc" object. So if you want to change something and have it show up in the game, you have to change one of those subclasses. However you can't actually change a class/object in the game(at least in the terms we mean in this thread), but you can REPLACE it with one of your own, via the Override feature of the XCOM 2 mod system. Now you can't just replace it with any old class, the replacement class has some rules. Specifically you have to extend the class you are going to replace, for the override to be valid (I believe this is true as I think I ran into it myself). Which means if you want to change any of the hit calculations on say the standard weapon shot (used by many/most weapons in the game) then you will need to replace the X2AbilitytoHitCalc_StandardAim class in the game. You do this by writing your own class and extending X2AbilitytoHitCalc_standardaim. You then override/replace (not in the XCOM 2 modding sense, but in an object oriented programming sense) any functions/methods in this class with your own version you write (with changed behavior). So for example, I'm tinkering with the RNG distributions used in the toHitCalculations. So in my mod I need to REPLACE the InternalRollForAbility() function with my own version, that does things a bit differently. So I have to write my own class, extend StandardAim, provide my own version of InternalRollForAbility, and then make sure my override is set via the appropriate config (Engine?) file, the details of which you can look up in the class override example. Now if you do all the above, it will work, however there is probably something interesting you will notice. Your changes will only show up on overwatch shots and grenade throws. This is because the above system will replace all StandardAim objects in the game, with your replacement, but only those that are created in the code using the "new" operator. As it turns out, for whatever unknown reasons, many of the standard weapon abilities actually have there toHitCalc object created in a different way, that avoids the above system. But that is info for another time/discussion (and is present in other threads) once you get the above working. So TLDR - Overriding/replacing the PARENT CLASS of an object used in the game, will have no effect on that object in the game. The child class in the game's reference/dependence on it's PARENT class is not changed by the XCOM2 override system. You have to actually override/replace the class used in the actual game (the CHILD) itself. Now if the changes you want to make are actually in code specified in the PARENT CLASS, then it's a bit trickier as you need to familiarize yourself with the rules of Object Oriented Programing on what properties/functions of the parent class does a child class inherit, and how you can change/override/ "hide" that behavior. Some of that can be language dependent.

1. Those @ signs in the text of the log function call, presumably are just placeholders to make it easy for him to see it in the rather large log file, helps make it stand out. Since they are inside the string quotes (") they act as just visual characters I believe. Outside of quotes the @ symbol in Unreal I believe works as a string concatenation(combining) operator. I think one that adds in blank/white space in between the strings? You can look that up on the UDN/UDK language reference for confirmation (a great resource for anyone unfamiliar with unrealscript) 2. If I understand correctly (which is never a guarantee at this early stage of my modding adventures :wink:, what you intend to do does not require use of technique in this post. This technique is to provide a single implementation of this method, implemented by one mod, and then other mods are to us functionality provided with it. Think of it like eXecator cutting a hole in the wall and building a doorframe for us to walk through, so that we don't have to always go around blasting holes in walls ourselves (which is messy). If that sounds appealing then you'd look up his mod that provides this and follow it's instructions. Otherwise you have two ways of accomplishing your task. 1. Modify templates at RUNTIME, post creation, using custom UIScreenListener classes you make as the entry point for making your modifications. This is the "standard" way of doing this, but requires a bit of extra work. See Amineri's post(s) for examples of this, I believe it's used in the Longwar Studios office mod (so look at it's source for further enlightenment). 2. Use the information provided by eXecator in this post (note: not his code! His code exists to built a doorway for others to use) basically by "cheating" the createTemplates() function of custom version of the X2AmbientNarrativeCriteria class, as a "safe" place to modify templates. This is basically the same as #1, but a different way of doing it. Not sure if it's better/worse, but for eXecator's goal, it provides a good place to build that proverbial "doorway". If you are already familiar with extending Datasets to create templates, then this one should be the same speed and avoids having to learn about UIScreenListeners and the events they are invoked for. Hopefully that helps (and also is reasonably accurate :wink:

Actually, technically, you can actually extend a template. E.g. : Ah, I'm guessing I'm confusing the fact that you can't extend a native class, vs the fact that you can't class override a native class? I'm hoping I didn't make up either of those things..? :sad: Spoken like a true programmer :tongue: Mod tools are great, and they definitely have set up quite the system here, but it also means there is a ton more to absorb. As probably the most useful source of "documentation" out there, your work has been absolutely essential. Someone should definitely go about collecting all your many posts in the various threads, into a single location as I'm sure it's probably out numbered the guides at this point just in terms of quantity of useful information. I'm almost ready to put the final touches on my mod. What would have been a single line change back in 2012 for Enemy Unknown, has balooned into 60KB of source files... but it's been an entertaining ride. I'd imagine we are going to be seeing a good amount of new and surprising things for this game coming out of the community over the next months and longer. :smile: As is the case with many modding endeavors, I've actually only been able to play about two missions so far, and that was mostly for testing purposes. Such is the life ;)

Sounds like they were saying that on first run of the mod it will create a new file "on the fly". The user can then edit that new file and the *next* time the game starts, those config values can be incorporated. I'd imagine the idea is in response to that any file in the packaged mod will overwrite itself on workshop updates. So the only way around that is to create a file in the mod directory that isn't actually shipped in the packaged mod, so it can't overwrite. You'd then have to be able to have the ability to detect if the file is present, if not create it, and if so take in it's values. Not familiar enough with Unrealscript to know if that is allowed for.

This is the place that I was at. My above post was to try and show you the way I organized the various components of the Xcom "system" for lack of a better word, in a way that started to make sense. I have some initial notes I wrote down from last week that ended with something like "Buy why 3 seperate classes to represent the same 3? Why use Object Oriented Design if you are just going to short circuit the paradigm whenever its' convenient". Etc. Which sounds similar to what I'm hearing from you. All this discussion has actually been really helpful for me to read/participate in, as it's further helping things digest in my mind and cement my understanding. (They often say the best way to help you learn something, is to try and explain it to someone else). So for the Object Oriented part, I think it's important to realize that OOP is one design paradigm, and it's interesting and has it's benefits and it's downsides. One thing you usually see is if someone takes a naive approach to OOP, (especially when stating out) they start making EVERYTHING an object. Like every last detail gets it's own object. The level of abstraction becomes comical (and unwieldy). One of the tricks to good Object Oriented Design is known where to draw the line with the abstraction, when it stops being a tool and starts getting in the way. That's important to relealize/remember when you get into projects like this (modding an existing game). So I still wonder why 3 classes for a single game entity? But I'm not so obtuse to not have a few ideas/speculation. One thing you hear is that while UnrealScript is nice and useful, it has it's performance issues and so you aren't going to write an entire game in it. So a lot of the Unrealscript classes are going to be sitting ontop of actual gamecode in CPP or whatever. So right away we are probably stuck with an immediate layer of abstraction there. So it might be setup this way ironically, for modders in the first place, as an interface for us to "access" the game. The next part Amineri has touched on(edit: Just read the latest post. 'touched on' barely covers it, more like "explained in glorius detail" :wink: ). They designed the game using the very explicitly idea of game states, and state changes. Which makes sense for a turn based game that isn't realtime. With their synched random seed system they use, the game becomes completely deterministic, which is very helpful from a problem fixing standpoint. Part of that system is the idea that a save game can quite literally be a record of everything that has ever happen. To keep that organized it's based on a series of game states, and changes between one state to another. I'm not sure how big the save files get, but regardless it seems like an interesting idea. But right away then, if you have to save the entire state of your game, on like every single turn, and every turn going forward and looking back, that is a LOT of states. So much so that you probably can't just start serializing all your classes. If there was a single class to say represent a soldier, you don't want every part of that object serialized and taking up space in the save file, if all you really need is just a few of their attributes. So I can see the distinction of splitting the "soldier" into two parts. The savegame or "game-state" info that needs to be in the saves/gamestates. And then all the other common stuff and functionality that can be abstracted into a template, which doesn't get saved. Consider the template the skeleton and the gamestate the mean on the bones that fleshes it out and allows it to "move". So far I can kinda see the above maybe being a reason why they went that way. But of course we have 3 versions of the solider, not just two, so why the third? This last one I'm guessing is for modding. Rather than having modders simply extending templates directly themselves to do their modifcations I'm guessing they wanted to buffer the player changes a bit through the use of the "DataSet classes (whose subclasses never use that word in their name, making it tricky to keep track of initially). Extending a class can be tricky in terms of breaking functionality, and considering how important templates are (they are native classes I belive?) I'm guessing they wanted to make sure they were bullet proof. Even then the modders really only extend datasets to simply replace a single function, one that produces/fills out some templates. So it's all very constrainted. So if you want to boil it down, you have the Soldier gamestate object (yes soldier is a bad example as it comes with some Unreal Engine extra baggage by being an active 3d represented object in the engine, but ignoring that part...) which contains all the info required to save the game, and nothing more. Then you have the GENERIC (this part is important) template, which honestly itself is really just a container for all the fields you "fill out" when constructing one. It is a container that holds all the stuff the Soldier needs to work, but either doesn't change, or at least doesn't need to take up space in a savegame. And then you have the Dataset objects, which are just the places where the templates are filled out. I don't even want to use the word "constructed" because I think that's misleading as far as templates are concerned. It really is just a container with a bunch of predetermined slots (that the person filling out has no control over) that you put your specific items into. These ones are the trickiest as they are the least like "objects" in the true noun sense, they are just a place where you fill out a single template that the game uses to be the "other half" of the gamestate object. At first blush the idea of a "template" might seem better suited towards a typicall OOP "interface" concept. That seems fair, although it seems like there definitely is some data associated with templates, and they aren't just a series of functions, so an "interface" might typically not cut it. I'm also not sure how Robust UnrealScript interface system is, plus that also might be a tough distinction to for modders exposed to the system to absorb, if they aren't already experienced in OOP. So I'm guessing they found this extra layer of abstraction useful, hence even the name "template", despite all the baggage a name like that might unintentionally convey. That's my layman's understanding of it anyhow. I have to admit, you are right about the naming part. The names they have chosen for their classes really aren't that enlightening, and often a bit confusing. Don't get me wrong, having any official mod support at all is wonderful and I don't want to sound ungrateful, just explaining why there is some confusion. Personally I take naming things in software development very seriously, and often am given a hard time about how long it takes me to come up with good/appropriate names. When I design software I try to take the approach that I'm not just instructing the machine to accomplish the task I want it to, but rather I am specifically trying to teach/convey whoever is reading my code exactly what everything is doing and what my intent is. It takes a bit longer, but as I'm often the one going back to software/code much later after it's originally written, I always aim to be kind to my future self and make it as easy as possible for them to get back up to speed. As for the specifics about overriding replacing say the ranger ability: You have to remember the distinction between inheritence, overriding, and then straight up "replacing" an object using the Firaxis given Xcom Modding system. When you extend the RangerAbility class, all you are doing is making your own new class/object, that has everything the Ranger one does "but a bit more". That big more can include changing how the RangerAbility class does some of it's things (ie. overriding/replacing/hiding it's methods/functions). That on it's own doesn't mean you have replaced the parent class. You have just defined an additional class, ontop of the existing one, although they do share some similarities. This goes back to what I was saying before about how I've found it helpful to think of this other entity the "xcom game" itself, as it's the thing that actual does all the work. Just writing a class in your mod in itself doesn't do anything. You need this "xcom game" to actually use your class in the first place, otherwise it will just sit there collecting dust. In order to do this you have to understand the system of how/what/when the xcom game does, and make sure your class/object is in the right place to actually be used. Specific to your Range ability, in this case you don't have to actually do that much. The XCom game will actually go through all the "DataSets" that it finds (the X2Ability classes are all "datasets", even though they are poorly name) and ask each one of those classes to please "construct/fill out all the templates you know how to make, and give them to me", and all those templates are collected and handled by the idea of a template manager. So that is how you get that object into the game, in the case of dataset classes (eg abilities) it happens automatically. Very important to know here is no "overriding" has actually happen, in terms of the Xcom game mod system, although technically in terms of Object Oriented Programing, you technically are overriding the parent class "CreateTemplates()" function. But those words mean different things confusingly enough in each context. Now to continue on with the Abilities example, it's important to know that even though your new/modified/extended ability is now in the game, what that actually means is a single object of the dataset class you made is created, and it's used to produce some templates who are collected by the appropriate manager. BUT nothing more will happen unless something somewhere else in the game is told to use that template. Eg. if you made a new ability that you want a gun to use, the gun itself (whatever that nebulous term "itself" means..) needs to refer to your template. Again you need to be aware of how the Xcom game "idea" operates so you know what to place where to get what you made into the game in the way you intend. Now as far as the term "overrides" goes, it means different things to the Xcom game modding system. In terms of Templates you can't actually extend a template in the game, so we don't worry about it there, the dataset/ X2Ability classes are how you introduce new templates to the game. But for OTHER objects (for example, the toHitCalc objects that are used, (by ability templates) to determine of an ability hits/misses) it does apply. If I want to make a new toHitCalc object, just making/extending the class isn't enough, unlike datasets, the "Xcom game" does not go and look for toHitCalc classes and automatically do stuff with them. They just sit there unused. So what you have to do is TELL the game to "use my object instead of/in place of another object". You do that with the idea of "class overrides" using the Engine.ini part of the mod. What this tells the game to do is "anywhere you were going to use an object of this class-type in the game, use my new object instead". This is something that I believe Firaxis had to add, which seems pretty neat/helpful. This is the "next level" of modding because you aren't just adding something new, additionally. You are actually replacing something that already existed. An important sticking point is that it will only replace objects created with the "new" operator. There are a few other ways to create objects that unfortunately ignore this system, and special steps have to be taken, regrettably, in those cases. This doesn't work for all classes, as certain ones are not overridable. Overriding is more dangerous in the sense that if you stray to far way from doing what the game expects your class to do, you can presumably cause problems, hence why some areas are off limits. So in Summary I'd say it makes sense why it's all a bit tricky. The way the system is set up is a bit unobvious, and the terminology gets really tricky. Some of the terms come with their own baggage/assumptions that don't always live up to how they are used in game. In Objected Oriented Programing some people will describe a "class" as being a "template on how to construct/ an object". When combined with the in game "Template class", (which itself is a class, used to produce objects, those objects are "templates" for corresponding gamestate objects, but the term "template" isn't really accurate as they don't actually describe how to build them, and are not related to them at all in the Object Oriented sense) it can get convoluted pretty fast. When in reality templates are really the "other half" the gamestate objects, the parts that "dont fit" or "don't need to be in" the savegame. After all that is said and done, I'd just like to call out Amineri again for all the amazing amount of effort put in enlightening and educating the rest of us. It really is a thankless task but has made an absolutely immeasurable difference in terms of the spread of knowledge in this community. It's a lot of effort, but it definitely (at least for myself, although I'm sure countless others" is incredibly appreciated. :smile:

Thanks for the replies. All that extra reading does seem to help solidify things a bit in my mind. Re: Steelrook My modified understanding that was key to it making sense for me (could still be wrong of course, but things seem to fit together together in my understanding for the moment), is you can think of there being something called the "XCom Game" (that's the native game code/executable that we NEVER see or have access to). This "game" is the thing that does all the work, and all the Unrealscripts/classes that we see/have access to are simply tools for the game to "use". We have no impact/control on what the game does, but it does all it's tasks in a fairly consistent routine/order. So for example, the game will go through all the X2Ability Objects, and for each one call it's CreateTemplates() function. These creates a whole bunch of ability templates that are collected together/handled by it's corresponding category manager. The game will then go through and connect each template with it's potential corresponding gamestate object (this part I'm less clear on as my mod doesn't involve gamestates thankfuly. But the order/direction of these operations isn't too important in terms of high level details). The same thing happens for Weapon(Item) templates (which when they are Created via CreateTemplates() are associated with specific abilities (or ability templates) but only referenced by name). So with the above in mind, the way I am thinking about it is that the "game/exe" has a bunch of "places/pools" that it will look into for content. The way we "mod(ify)" the game then is to add our "additions" to these pools, so that the game will find them and do it's normal routine with them. We don't really have control over this process, however if we do know what/why/how the "game" is doing, then we can both create our additions and make sure they end up in the right "place" so that the game will do with them what we intend. For someone familiar with modding Xcom already, this probably seems like a fairly childish way of looking at something that is already pretty straightforward, but for someone on the outside looking in, it's currently where my level of understanding is. (Maybe? the most natural way of thinking about it would be working backwards from the played game entities and then going back to the script files and classes. So you'd start with a map, that specifies an alien or something. That alien requires a gamestate object, which has references to it's template. That template has connections to it's weapon template, which in turn has connections to the Ability Templates that the weapon can perform. Each of those have their own gamestate objects to keep track of bullets loaded, shots fired maybe, cooldowns, who knows (just guessing, I haven't touched that part of the game). All these templates are created by the specified "DataSet" Subclasses (eg. X2Ability.uc), note we don't really mention the Template class files themselves. We can't touch them as they are "native" and essentially their structure is tied to this "game" concept above, that expects them to work behave in very specific ways that can't/shouldn't be changed). Looking at it that way you can see the relationship between entities in the game played on screen all the way back to the eventual files that we have the option of modifying). So for my desired mod, I know the "rolls" to see if you hit are done in toHitCalc objects. Now a Weapon itself doesn't actually take any actions, these are abstracted into "Abilities" eg "StandardShot" "PistolShot" "SniperShot", so I had to look at those. Each AbilityTemplate is allowed to specify it's toHitCalc object. So not only do I have to create my own modified version of a toHitCalc object, I also have to make sure mine is used on the AbilityTemplates that I want to effect (Specifically all the standard weapon shooting etc). Now as mentioned above, if you want to modify an ability template, you don't mess with the AbilityTemplate.uc themselves, as they are just generic specifications on what a generic Template of that type would contain. You actually have to go to the X2Abilityxxx classes who create/fill out the template fields and specify what toHitCalc objects to use. That was a big source of my initial confusion. I know what/where I wanted to change, but I didn't know how the game actually used any of this stuff, so I didn't know what if any other changes were required to get the game to USE my changes. The above understanding allowed me to get my mod working, although it required me to override/replace several classes that the game was using. (My toHitcalc objects, but also the "factories" that created the templates that would need to use my toHitCalc objects). After the suggestions for more reading in this mod, and some other stuff I was lucky to find reading further, I'm actually not doing that anymore. With the knowledge that I just need to get the AbilityTemplates that I require to use/refer to my modified toHitCalc object(s), and the above understanding how they are produced from the factories in the X2Ability classes, but then go on later to be used by the "game", stored in template managers, and in conjunction with gamestate objects, used to "run/calculate" the tactical game, the seemingly prefered way of doing things would be skip replacing the factory, and just *modify* the Template Objects themselves *after* they have been created/instanced. So don't actually change the *.uc class file, but rather just modify running objects in the game. The tricky part of this is that it steps beyond simply knowing the steps that the "game" takes when setting everything up (and just making sure my changes are picked up by the game automatically in the normal course of it's operation). But it looks like all that is already fairly well understood and talked about in a few posts/examples. If you want to actually change things yourself on the fly, rather than just providing tweaks/replacement to existing data that the "game" will use in it's normal way, you need a way of getting anything you write to be run/executed itself. The current way to do this it seems is through the UIScreenListener's (oddly enough explained in the documentation that comes with the SDK, but none of that really stuck with me until I was able to really absorb all the above info enough that it's context finally made sense). With the generous examples in the forums you can see how the game provides certain execution points, where at certain times in the normal game play execution, you can "register" your pieces of new code to be run by the game. The neat part about this is you aren't actually replacing something existing to slot into the normal chain of events like above, and the benefit of that is that it helps with mod compatibility. Currently two mods can't override the same file/class. However theoretically no limit of mods can "registry" for these entry points and all have their code/instructions/alterations run. So the update to my still WIP mod is to avoid having to touch Ability or AbilityTemplate files, overriding etc, and just use the UIScrenListener entry point system to have my own code simply make a few changes to the *already created* existing AbilityTemplates after they are made and being handled by the TemplateManager. I just need to change them (once hopefully?) per time the game is run/loaded to refer to my new toHitCalc object, and that should be it. I have the rough draft of it up and running now and it seems to be working. What remains then is the finer points of figuring out/research exactly what is the proper and "safest" way to do this, since you are now modifying game contents "in flight" so to speak, I'd imagine greater care is required to not really mess things up. Re: eXecator With respect to 1) I think DataSets (The classes/objects required for filling out Templates) aren't native and can be extended/overriden? I believe in my earlier version I replaced a bunch of them to deal with the above issues and it seemed to work ok. But I am definitely going with 2) now, as I feel that the lower the number of classes you need to override/replace the better, especially for inter mod compatibility.

Short Background: I had an idea for a "simple" (aren't they all..) mod for the Enemy Unknown, tried it, was too hard to make work, and promptly forgot about it. Enter in XCOM 2 with official modding support and the old idea came back to me. Good news, I've been able to get the mod working, after many trials and tribulations (while the mod is still simple in terms of what it changes, it's a purely gameplay/programing and the new games systems are much more involved requiring more learning/trial and error). While I'm happy that it's working, I have the feeling that I'm probably not doing it in the "best" way and in order to do that I probably need to know more about how the underlying game is setup. Which leads to my question.. What is the difference between Templates and the standard XCom Classes? The best example is probably X2Ability and X2AbilityTemplate? Obviously they are both technically classes, which I understand fine in the Object Oriented stance, but for whatever reason I'm finding it a bit unintutive how the game is actually *using* these things. I've tried to read as much as I can, search, tutorial guides, but can't find anything that lays it out bare (just bits and pieces I've been able to hopefully glean and try and piece together). If there is place where it's all spelled out that I've somehow missed, I'd be terribly grateful if anyone can point me the correct direction. I am *guessing* that many of the "Non-template" classes aren't used in the traditional ways? (where they are instanced into Discrete Objects, possibly many of them, and those Objects are used, modified and manipulated through the course of their existence). My particular mod has the modest goal of changing the RNG Roll probability distribution in toHit Calculations (trying to make it *appear* subjectively to be more "fair". Currently trying out a crude average Sum of 2 Rand rolls, but that discussion is for a different topic...), and that required Overriding a few toHitCalc Class/Object(s) which was straightforward enough and fine. However those object(s) are used by Abilities and are "attached" to them, and due to a quirk in the way the vanilla game is set up, the Abilities that used my new overriden Classes/Objects weren't set up to automatically attach. Which required me to look into those problematic Abilities and try to "fix" it myself, which is where the confusion arouse. What my current (at best incomplete, and more likely completely wrong) idea is that the Game doesn't actually use say X2Ability in the regular sense. This class is NOT instantiated into an X2Ability Object, which would then represent the ability in the game, called to handle any time a weapon uses that ability, and then it uses it's own toHitCalc objects etc, to do the "work" of using that ability? Instead it seems like this X2Ability Class, is maybe instantiated once (or a small number of times) into an object, and this object is then used to "produce" an Ability Template Class/Object (specified by X2AbilityTemplate). Essentially it creates and then "fills out" all the required (predetermined) fields of this Template object, and sends it out into the world. And at that point the work of the X2Ability Object is done? Further then, this newly Created/Filled out X2AbilityTemplate object is also NOT technically used in the typical way in that there are not many copies/instances of it out there being used to handle the "work" of an ability when weapons are fired/used etc like mentioned above. It is not the games internal representation of an Ability either, and doesn't live a life, being changed or whatnot etc? But rather this Template object (and maybe again only a single copy/instance) is kept on hand by the game and actually used to construct another Class/Object, the final result a type of GameState object. These gamestate objects are linked to their base-template, in the sense that they refer to them to do certain things, but they themselves ARE the games internal representation of an entity, and contain all the information (that may be updated,changed etc) as that entity goes through it's existence in the game? This is where things start to really decouple in my mind, as I guess I can follow that train if we are talking about a Soldier or whatnot, but with respect to an Ability, the distinction between AbilityObject, AbilityTemplateObject and then AbilityGameStateObject really starts to break down/blur. I guess it seems odd to me that it would be broken out this way with so many individual pieces, instead of just a single object? With respect to my specific mod, I need to make sure that the correct "Abilities" are refering to my modified toHitCalc Object. I can just start overriding classes left right and center (which in my first version I have), however those numbers start to add up as it seems all "information" regarding what we'd outside of the game describe as an "entity", is spread out over multiple classes/objects. This is the part that feels like I'm not doing it the "right" way, especially if some of those classes exist in only certain, brief, circumstances, it might be unnecessary to go replacing them all at will. A possibly better way to put it, if my above understanding it's too flawed (a big "if"...) is that do I need to replace the entire "factory" (X2Ability Object) if it's only ever producing a single "flawed" product (an X2AbilityTemplate object), or would it be better/easier/possible just to "fix" (modify and/or replace?) directly and leave the factory untouched. My apologies again if I've missed something glaringly obvious. I guess it's only fitting that my initial idea for such a "simple/small" mod would be one that actually touches a variety of system components. Thanks for any input, help and or advice.

While I appreciate the Schrodinger's cat reference (awesome), the above statement unfortunately does not accurately use the word "chance". There is a not a 50/50, ie. equal chance for either event to come. You are stumbling on to a very important part though: "chance is meaningless with respect to a single event". It also brings up a larger debate about determinism in general (very interesting, although an age old philosophical question), but that it definitely for another place ;) "Chance" implies "if you do it many times, the numbers will tend to match this chance". You are right in that, at the moment, either event can happen. But on a 99.999% shot, you can still miss, just that if you were betting, you could make that bet many many many times over, and only very rarely lose. Probability is a statistical concept, one that really only applies "after the fact". That doesn't mean we can't make useful predictions before hand, but it is really only accurate "looking back". The guy who won the lottery last week, had a 1 in 10million chance to win, just like you. Yet he won, and you didn't. Just like the surgery that has a 98% success rate, the person it didn't work for had same "chance" and "odds" as everyone it did work for, yet for him it didn't work out. It's a tricky subject. Back on topic UPDATE: After more digging it seems like this will be a rather difficult thing to accomplish. All the "to hit" calculations are done in UnrealScript, outside of the call to the Random Number Generator, which is inside the EXE itself. Since all we can do is hex edit the compiled UnrealScript byte code, we really can't modify the contents of scripts outside of changing literals. But inside the game, all the calculations are hidden inside the Bytecode interpreter, and even injecting code into the game itself, would only allow you to alter the RandomNumberGenerator itself, NOT how the game uses it (which is what we want). So you could make it that the toHit chances work out the way we want, but all other probability in the game (eg. Random events in the Strategic game, like UFO appearance, etc) would also be affected. Which seems like way too big of a side effect. So unless we get some sort of Script Compiler (or less likely, a Bytecode editor that allows code injection), this idea has to go on the back burner. Shame, because I really think it would be interesting to see how people react to it. Like the post before, it'd be neat to see if the simple change in probability would actually do what you want (change the effectiveness of cover). For Example: With a 65% aim, -40% tall cover, you have a 25% chance to be hit. Where with a modified hit calculation, it would end up being more like only 12%. So that could make tall cover quite the improvement. Would have to see it in action to be sure though.

Great thread topic here. Definitely something I was looking into (searched high and low, should have figured it'd be waiting here all the time, at the nexus). To Sum up my opinion: For some, the randomness in the game feels "unfair". Investigations have been done to show that it's not the case, the randomness is technically pretty accurately random, however that isn't the important point. Humans have a hard time with the concept of probability, it's in our nature. Since this is a game played by humans, it makes sense that while technically correct (an 84% chance to hit will, over long averages, actually produce 84% of your attempts hitting), it's more important for the game and game play to address the perception of the players, regardless of what the reality is. So the perfect way to test this: would be a mod to alter the way the Random Numbers work in the game. OP and further posts I think hit the nail down on the head. I think human perception intuitively "likes" (is more comfortable with) a uniform probability curve/distribution, rather than the uniform/linear one that we have by default int his game. The easiest (and most intuitive way) to accomplish this would be to simply add an additional "roll" in. You see that in board games (mentioned by a few), but basically, if you roll 1-100 once, each # has the same chance of coming up. Roll twice, and find the average, and now the middle numbers will come up more than the extremes. (Rolling a "1" now requires two rolls of "1" in a row, which is much less likely). You can further change this weight by adding increasing rolls, but I think a 2 rolls should be a good compromise. (After more than 2, the extremes of both high and low start to get really low odds, such that things like over-watch might no longer be viable.) So how to accomplish this: Thankfully there is a good analysis of the RNG that was posted recently Here. In that the investigator found where in the UE scripts the chance to hit is calculated. XGAbility_Targeted:RollForHit(): Unfortunately at the moment, there is not ability to edit the Scripts outside of changing number values (HEX Editing) and not adding the additional code (to make the change to two rolls, instead of one. So the only real option is the inject this code into the executable itself (using something less savory, like say cheat engine?). From that same article we have an idea of the function in the EXE that does the work: function bool RollForHit(float fChance, out TCharacter kShooter, out TCharacter kTarget, out float fRoll) { fRoll = class'XComEngine'.static.SyncFRand(string(Name) @ string(GetStateName()) @ string(GetFuncName())); return fRoll <= fChance; } So if we could simply modify that, it could accomplish the goals. The effect: Not sure how easy the above is to accomplish, but if such a mod exists I would be very curious to see what the effect would be (on the players). Would it make the game more "in line" with their expectations on how an "80%" shot should feel? And would this actually change their enjoyment of the game (some of the charm of Xcom may be due to it's sheer abusive difficulty ;)). Either way, I'd love to see this happen to try it out. Any insight into the feasibility of the above would be welcome.

Hello, It would seem that the comments on my mod/file page (http://skyrim.nexusmods.com/downloads/file.php?id=14365) are disabled, even though they are enabled in the settings/attributes control panel. (Turning this on/off does not seem to help). It has been suggested that I post here to receive assistance for this issue (as it's something that can happen sometimes?). Thanks in Advance for the help. :)