Idea/Basic Brainstorming Thread

[Krazyguy75]

My brain has always been full of ideas, like many peoples. I come up with new ideas so often that they often conflict with the time I have available. Some of my ideas just go beyond the scope of my programming knowledge.

 

So, I figured I'd just create a thread for the purpose of hosting ideas. Note: This is not a thread for mod requests, this is just a thread for putting down ideas that you thought of.

 

Examples of what to put in this thread:

• Ideas you want help exploring
• Ideas you don't have time to work with or are saving till later
• Ideas you don't know how to work with, and/or ones you just want someone to help you find where to start.
• Elaborations on any of the above
• Help with other people's ideas and/or concepts

Examples of what not to put in this thread:

• Mod requests (Pretty much anything beginning with "I want to" or "Can someone" is bad)
• Questions (This is for ideas, not "How to"s; questions about other peoples' ideas are fine, though)
• Demands (Don't demand other people do your work for you)

Basically, post your ideas here, and others can come along and see what they can do with the ideas, and we can use this thread to brainstorm new things to mod.

[Krazyguy75]

So, just to get started, here's a problem I faced for a while now, but never got around to solving:

Modifying the AI to work for expanded alien types in the ini.

 

I have no experience with alien AI, which is why I did not do much with this. AFAIK, adding new aliens doesn't work for two reasons:

1. Because the game doesn't know that they should be put into pods.
2. Because even were they to be added, the AI wouldn't know what to do with them.

My ideas for potential solutions were as follows:

• Try to make all enemies into groups (as in, you could define a new addition's group as Sectoid, in which case it would follow Sectoid AI). Given my complete lack of knowledge into the AI, I have no idea how difficult it would be to replace the functions that determine one enemies type into one that identifies it's group instead. However, I do know that this would require you to modify the character struct in the ini and the upk to accept a new field for AI group.
• Base pod creation off of a point system (with synergies like Drone/Sectopod getting a higher chance), and base AI off of stats and perks instead. I believe that the first part has already been done in the past, and I know work has been done into the second part, such as with Amineri's Low Profile aliens prefering low cover and such. However, it seems to me that the second part would be a large project to complete fully.
• Base pod creation off of a point system, and just have the AI try to deal with the second (I know it has somewhat flexible AI to handle mind controlled soldiers and so forth; I've never really tested what MC'd soldier are truly capable of.)

[Krazyguy75]

So despite having a near migraine level headache, my brain still insists on new ideas. This first one would be a massive project, but could definitely help modding in the future: Recreating the native functions.

 

Difficulties:

• While some functions are easy to understand the purpose of, others would be near impossible to recreate, such as buildability() due to their sheer scope.
• Every single native function would require both a resizing and a function type change

However, similar work has been done in the past IIRC (I believe Amineri did this once for one function).

The problems of which bring me to my second idea: Has anyone tried experimenting with the numbers in BuildAbilities()? I've been wondering what they do, since I've heard nothing on them.

[Amineri]

 

However, similar work has been done in the past IIRC (I believe Amineri did this once for one function).

 

I've actually done this twice.

 

For the Ammo mod I rebuilt the native function GetAmmoCost using XGAbility_Targeted.GraduatedOdds.

For the Damage mod I rebuilt the native function CalcOverallDamageModFromPerks using XGAbility_Targeted.TShotInfo_ToString.

 

The problem with generally rebuilding native code is two-fold:

1) We don't know precisely what the native function does, but have to guess at the functionality from observed effects in-game

2) It's not possible to intercept when one native function calls another

 

As an example of the headaches of issue 2, for the Ammo mod the native function XGUnitNativeBase.BuildAbilities must be calling the native function GetAmmoCost, because it dims abilities based on remaining ammo (if there isn't enough ammo to use the ability the ability icon is dimmed an unusable). It wasn't possible for me to intercept this call, so I had to put in a fairly ugly workaround.

 

 

Has anyone tried experimenting with the numbers in BuildAbilities()? I've been wondering what they do, since I've heard nothing on them.

 

JL and I have both messed with the parameters if BuildAbility within the XGAbilityTree.BuildAbilities function. If you look at the BuiltAbility definition you can see what the parameters are, and Bertilsson's reverse lookup tool will map the numbers back to functionality.

 

In short: BuildAbility calls define range, targets, duration, effects, properties, display properties, cooldown, etc.

[Krazyguy75]

Thank you for the clarification.

 

As for problems intercepting native functions calling native functions, that's a shame. That's a limit I wasn't aware of...

[Amineri]

In case you are interested in what it took to get around the "native function calling another native function" for the ammo mod, here's what was done :

1) Use an otherwise unused variable m_iTurnFired (which was related to weapon overheating) to store the real ammo count, leaving iAmmo "unused"

2) When updating the ammo for a weapon set iAmmo to some value that generates the correct behavior in the native GetAmmoCost function.

For example, in Long War the LMG ammo has been increased to allow 6 shots before being empty instead of 3 in vanilla. However the native GetAmmoCost will still report 100/3 = 33 ammo usage when XGUnitNativeBase.BuildAbilities checks to see if an ammo-using ability is available. Suppression will get reported as using 66 ammo. So if my real ammo count is at 2/6 shots remaining, I set the iAmmo count to 90 so that both regular shots and Suppression ability will be available (and Flush).

 

This results in :

m_iTurnFired = (100 - 4 * 16) = 36 as the actual ammo remaining (and since each shot takes 16 ammo that means 2 shots left

iAmmo = 90 is set to make the interaction of native GetAmmoCost and BuildAbilities result in correct behavior.

 

When another shot is taken, reducing m_iTurnFired to 20, then iAmmo is set to 40, allowing abilities that need a single shot of ammo to work, but abilities such as Suppression and Flush will be unavailable.

 

As I said, kind of ugly workaround ~_~

 

---------------

 

 

So, just to get started, here's a problem I faced for a while now, but never got around to solving:

Modifying the AI to work for expanded alien types in the ini.

 

Can you expand what you mean by this? I'm not sure what the "expanded alien type in the ini" is referring to.

[Krazyguy75]

Everything else is a dynamic array, easy and helpful for modding. However, due to the AI, graphics and coding necessary, it's not really possible to just dynamically add aliens (or even do it with a small amount of coding).

 

I just want to make a framework that would make it easier to do something like that, specifically on the AI side (since I know we can't do much beyond textures when it comes to graphics).

 

Which brings me to a new idea (these buggers keep popping up everywhere): Can we potentially duplicate objects and their textures (aliens in particular) and adjust references to allow things like pod leaders to have custom textures? I know nothing about the texture side of things, so I'm not sure about this.

[Amineri]

 

Everything else is a dynamic array, easy and helpful for modding. However, due to the AI, graphics and coding necessary, it's not really possible to just dynamically add aliens (or even do it with a small amount of coding).

 

Sorry, I'm still not quite following you :) Do you mean that we can't dynamically add aliens to an existing pod while a mission is underway, add new aliens to the game, or add new aliens to an existing mission?

 

 

Which brings me to a new idea (these buggers keep popping up everywhere): Can we potentially duplicate objects and their textures (aliens in particular) and adjust references to allow things like pod leaders to have custom textures? I know nothing about the texture side of things, so I'm not sure about this.

 

I've been digging into where raster image data is stored, and have made headway in terms of most icon images (which aren't progressively loaded and have different compression in order to avoid image artifacts).

 

However it appears that texture data is all managed by the Unreal Engine, and rightly so since loading/streaming textures can be rather system-intensive. Paths to images are defined in the UDK (such as "img://MyPackage.MyGroup.MyTexture"). These textures appear to be put into a tfc file and handled by the Unreal Engine.

 

Changing textures would mean hacking into the 3D model upk and changing the texture name. When I've tried to do so in the past (on some armor decos) it's always resulted in the deco completely failing to load.

 

However, I have figured out to apply scaling to different aliens of the same type (XCOM male and female soldiers use the same weapon models but they are scaled differently), and this feature has made its way into the upcoming Long War EW -- alien leaders will in general be slightly larger than the units the lead.

[Krazyguy75]

Alien stats are stored in the ini in a dynamic array, correct? So you could technically just add a new character to the ini without any problems.

 

But I don't think that there is any way to actually make the added items work in game, without an extensive amount of UPK editing per alien added. What my goal is is to make a framework that allows it to actually be viable to add aliens (using existing in game models) to the game without the average person having to go in and make zillions of UPK changes to support it.

 

This requires that the model, the texture, the animation, the AI, the pod spawning, etc all be linked in to any changes to the ini, and as such would need to be extremely versatile.

 

There's a reason this is just an idea and not physical work yet. It would be a large project to undertake, and I don't even know if it would be possible to make it work.

[Amineri]

Hmmm, I guess we're kind of already doing this in Long War EW.

 

However instead of using the Characters= dynamic config array, I've basically taken over the 4 different BalanceMod arrays to perform various things. Some of the things in the Characters= array would require additional animations (for instance being able to poison spit like a Thin Man or MindMerge like a Sectoid requires that the model have a particular animation asset).

 

What I've done for Long War EW is the following:

• BalanceMods_Easy sacrifices the ability to adjust crithit chance (it now stores difficulty) in order to define alien stats for all difficulty settings (which in theory could allow a 5th or higher difficulty setting)
• BalanceMods_Normal is used to configure general dynamic alien stat upgrades. For example, giving Sectoids +1 HP at day 20. This applies to all aliens of a particular type
• BalanceMods_Hard is used to configure aliens of the same species with different stats/upgrades. Each pod can have a single alien "leader" who receives bonus stats and perks based on level. Alien leader level is set in XGStrategyAI.BuildPod, and can be a value from 0-7. Navigator upgrades can also be configured here, and also give stat increases and perks, but can be given to any unit of the given type. Each navigator upgrade is configurable to have a random chance of being applied (10% - 100% per unit). The overall pawn scaling of the indvididual unit can be configured via these settings as well.
• BalanceMods_Classic isn't implemented yet, but I'm planning to use it to allow configuration of "once-per-campaign" type of special characters, kind of like "bosses". I think it will be possible to define up to 8 special characters of each alien type (there are ~27 pawn types), which provides a lot of possibilities.

Working within the existing alien types like this makes certain things easier, since we don't have to worry so much about the AI or animations, while still providing for greater diversity of alien forces. Some AI tweaks were necessary, like making the AI prefer Low Cover if the unit has the Low Profile perk.