Increased Pod Size

[wghost81]

XGStrategyAI.BuildPod function in EW has additional (optional) argument bExaltOnly. But first token seems to set this herd-coded to false. Am I correct and bExaltOnly is never used?

 

UPD: Nevermind, this was just lack of attention. :smile: 49 token sets default parameter value. :smile: So, EXALT do indeed use a mix of three types.

Edited November 30, 2013 by wghost81

[Amineri]

I've been following up on some earlier designs and adapting some of the "extraneous" BalanceMod config arrays to make things easier for people to configure.

 

Right now I'm planning on using three of the four BalanceMod Arrays:

 

1) BalanceMods_Easy will be used to configure initial alien stats based on difficult. CritHit won't be configurable, the iCritHit field will be storing the game difficulty (e.g. 0 = Easy)

 

2) BalanceMods_Normal will be used to configure dynamic alien stat progression. This affects all aliens of a given type (e.g. Sectoid, Muton Elite) as time progresses. All 7 stats are configurable as well as ShieldHP, Damage Reduction and Regeneration.

 

3) BalanceMods_Hard will be used to configure individualized alien upgrades. This includes granting individual alien bonus perks and extra stats, as well as modifying their size to reflect their new nature. Each alien pod will be able to have a leader defined in the strategy game (with valid leader levels from 0 - :cool:. Additionally randomized individual alien unit upgrades will be definable.

 

While testing the limits of the sizing, I created the following situation, which was good for a chuckly, so I thought I'd share :

 

http://wiki.tesnexus.com/images/a/a0/Godzilla_size_sectoid.jpg

 

The "godzilla-sized" Sectoid is 10x normal dimensions in each direction, so 1000x normal volume.

 

I also have accidentally made some Sectoids so tiny that they were unrenderably smally and took about a minute to run across 1 tile.

 

And yes, my active soldier has Grenadier, as it's one of the Long War subclasses, an Engineer.

[Zyxpsilon]

This was soooooo hilarious, i actually knocked the coffee cup off onto the mouse pad. Lucky me - it was almost half-empty.

 

BUT - i want me some of these Giant Sectoids. Just imagine how a *bigger* Sectopod would feel like.

A monsters storm is comin'. :D

[wghost81]

Amineri, you may try to make variables configurable via "config" flag and specifying config name. I haven't tried this myself, but see no reason why it shouldn't work. And this way you could make your own ini-configurable variables instead of re-using existing ones. Not necessarily add new variables, but make existing variables configurable...

[Amineri]

 

 

Amineri, you may try to make variables configurable via "config" flag and specifying config name. I haven't tried this myself, but see no reason why it shouldn't work. And this way you could make your own ini-configurable variables instead of re-using existing ones. Not necessarily add new variables, but make existing variables configurable...

 

That's a good thought that I'll keep under my belt, but so far I haven't had to use it. I also had a lot of weird glitchiness when trying to access the XGTacticalGameCore config variables from XGUnit.DebugAnims, even though I used precisely the same format as a loop in XComStrategyGame.upk (but using the local object references instead of the import references). I still don't understand how some of my local variables were getting overwritten, as I found workarounds ...

 

Firaxis' use of 4 separate arrays for BalanceMods instead of just 1 array w/ a variable for difficulty was easily tweaked. At the cost of not being able to configure iCritHit, I was able to pack all four initial difficulty settings into the one array (BalanceMods_Easy), leaving the other three arrays free for new use.

 

I've finally got both the dynamic base alien upgrades (using the Normal array) and the leader/navigator updgrades (using the Hard array) working, and the BalanceMods_Classic array is still unused, so I'm free to use it for something else in the future :smile:

 

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

 

Difficulty-based stat upgrades work like so:

BalanceMods_Easy=( eType=eChar_Sectoid,             iDamage=0,  iCritHit=0,   iAim=0,   iDefense=0, iHP=-1,  iMobility=0,  iWill=0 )
BalanceMods_Easy=( eType=eChar_Sectoid,             iDamage=0,  iCritHit=1,   iAim=0,   iDefense=0, iHP=0,  iMobility=0,  iWill=0 )
BalanceMods_Easy=( eType=eChar_Sectoid,             iDamage=0,  iCritHit=2,   iAim=0,   iDefense=0, iHP=1,  iMobility=0,  iWill=0 )
BalanceMods_Easy=( eType=eChar_Sectoid,             iDamage=0,  iCritHit=3,   iAim=0,   iDefense=0, iHP=2,  iMobility=0,  iWill=0 )

This adjusts starting sectoid HP based on difficulty. If you want you can technically list the same alien type at the same difficulty multiple times, and they all add up, but there's really no point in doing so.

 

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

 

Dynamic base alien upgrades (these upgrades apply to all aliens of the given type after the elapsed time) work like so :

; time-based modifications -- use MaxActiveUnits to scale all of the times based on difficulty
;    dynamic upgrade encoding:
;        	iDamage		(damage)
;  			iCritHit	(day count)
;  			Aim			(low 2 digits Aim, high 2 digits CritHit)
;  			iDefense	(low 2 digits Defense, high 2 digits damage reduction )
;  			iHP			(low 2 digits HP, high 2 digits ShieldHP)
;  			iMobility	(Mobility)
; 			iWill		(low 2 digits Will, high 2 digits regeneration )
BalanceMods_Normal=( eType=eChar_Sectoid,             iDamage=0,  iCritHit=10,   iAim=0,   iDefense=0, iHP=1,  iMobility=0,  iWill=0 )
BalanceMods_Normal=( eType=eChar_Sectoid,             iDamage=1,  iCritHit=60,   iAim=5,   iDefense=0, iHP=1,  iMobility=0,  iWill=0 )

This gives Sectoids an extra +1 HP after 10 days, and another +1 HP (to total +2 relative to start) and +5 aim after 60 days. There's no need for blank filler and pretty much any number of upgrades can be applied per alien type. For example Sectoids could have 8 upgrades, while Ethereals only have 2 upgrades.

 

I still have to implement the regeneration and damage reduction (it's stored, but not used).

 

The time when upgrades hit can be adjusted overall based on difficulty using :

; Re-purposed as difficulty slider for dynamic alien upgrades. 100= default value used in BalanceMods_Normal
MaxActiveAIUnits=110
MaxActiveAIUnits=100
MaxActiveAIUnits=95
MaxActiveAIUnits=90

This makes upgrades appear 10% later on easy, 5% earlier on Classic, and 10% earlier on Impossible. Note this change also removes the limit of 5 max active aliens on Easy/Normal. There is still technically a hard-coded limit of 32 active aliens, but I don't think players will notice :wink:

 

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

 

Individual alien upgrades work like :

; leader and special character (navigator) enhancements
; stat definitions:
; 		iCritHit -- low 2 digits hold leader level/navigator chance (if <10 is leader level, if >= 10 is % chance for navigator upgrade)
; 				 -- upper digits hold day (from STAT_GetStat(1) when the upgrade becomes possible
;		iHP, iAim, iDamage, iWill -- normal stat upgrades
;		iMobility -- perk ID to grant
;		iDefense -- unit scaling information 20 = +20% scaling.
;		scaling is additively cumulative
;		+20 and -10 combines to +10 = 10% larger
BalanceMods_Hard=( eType=eChar_Sectoid,             iDamage=0,  iCritHit=101,   iAim=0,   iDefense=20, iHP=3,  iMobility=0,  iWill=0 )
BalanceMods_Hard=( eType=eChar_Sectoid,             iDamage=0,  iCritHit=130,   iAim=0,   iDefense=-10, iHP=2,  iMobility=5,  iWill=0 )

I'm going to go into more detail because this system is new (in Long War we had something similar but it was hard-coded into the hex).

 

This short example defines 2 types of individual alien upgrades:

 

First ) An alien leader upgrade

 

Each pod can have 1 alien leader, who is always in position 0. Alien leader can only be defined via further modding tweaks to the XGStrategyAI code that defines pods. With the larger alien pods mod, the alien leader information is stored in the low 3 bits of the eMain_AltWeapon field (which is 8-bit field). This allows alien leader levels from 0 through 7 to be passed from the strategy game to the tactical game.

 

The alien leader level for upgrades is defined in the iCritHit field, low 2 digits. The upper digits provide a way to clamp the leader upgrades to be possible only after a certain number of days has passed.

 

So iCritHit = 101 means leader level 1, available after day 1. iCritHit = 6002 would mean leader level 2, available after day 60, etc.

 

Leaders can only have 4 base stats upgrades currently -- HP, Aim, Will, and Damage. These values work as usual, but are applied only to the leader alien.

 

The iMobility field is the perk ID of a perk to grant to the leader. Unfortunately the name can't be used because the variable is an integer while the name is an enum (byte). Only one perk can be granted per upgrade line, but multiple upgrade lines for the same leader level can be defined, allowing multiple perks to be granted if desired. Not all perks will work on all aliens. Some experimentation is required.

 

Finally the iDefense field allows for resizing of the leader unit. Each +/- 1 is a +/-1% size increase in each of the x/y/z dimensions, so in terms of apparent volumetric size this is very non-linear. I may tweak it to make it more linear in terms of volume, depending on feedback.

 

Alien leader upgrades stack, so if an alien leader is level 4, it gets all upgrades for that alien type for levels 1, 2, 3, and 4. This can include multiple lines at a particular level. It is definitely possible to stack up some nasty bonuses to create some crazy-difficult alien "bosses".

 

 

Second ) An alien 'Navigator' upgrade

 

This upgrade type is not restricted to leaders, but can randomly be assigned to any alien in the pod.

 

The primary distinction is in the iCritHit field, in the low 2 digits. If the low 2 digits are >= 10, then they are treated as a % chance that any alien will have the line's upgrade. This can apply to leader aliens as well (so that they can get both the leader upgrades and navigator upgrades).

 

In the example given, iCritHit = 130 means that the Navigator upgrade has a 30% chance of being applied to any alien in the pod.

In this example iMobility = 5 was set, and 5 = ePerk_LowProfile, which I verified does work with Sectoids (and in general should work for any alien that can use cover).

 

If multiple alien navigator upgrades are defined for the same alien type, then each such upgrades has it's own independent chance of being applied. So if three such upgrades are defined for Sectoids, each with a 30% chance of being applied, there are 4 possible outcomes :

0 upgrades) (1-.3)^3 = 34.3%

1 upgrade) 3 * 0.3 * (1 - .3)^2 = 44.1%

2 upgrades) 3 * 0.3^2 * (1-.3) = 18.9%

3 upgrades) 0.3^3 = 2.7%

 

If the same perk is applied more than once the effects don't stack in any way, but care in granting stat bonuses in this way should be taken, as the stat bonuses will stack.

 

 

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

 

I still have a bit of work to implement the alien regeneration and damage reduction, to do a bit more testing, and to wrap the mod up into an install-able package, on which I'm hoping that Bertilsson and wghost will be willing to collaborate.

 

[wghost81]

Wow. Amazing work!

[wghost81]

Amineri, I'm working on another increased pod size version for my mod and I have a question about XGBattleDesc.InitAlienLoadoutInfos. I used your XComGame.upk changes for Larger Pods mod without deep investigation, but now I need to make things different, so I started to dig deeper. :smile:

 

I can't see why you need to add more than one entry for each alien type in XGBattleDesc.InitAlienLoadoutInfos. m_arrTeamLoadoutInfos seems to be used for determining loadouts by alien type and needs only as much entries, as many alien types squad has. AltWeapon references need to be removed, but other than that no changes are required. I tested it and it works: 6 alien pod (2 main + 2 sup1 + 2 sup2) was equipped properly.

 

Please, correct me, if I'm wrong.

Edited March 21, 2014 by wghost81

[Amineri]

Amineri, I'm working on another increased pod size version for my mod and I have a question about XGBattleDesc.InitAlienLoadoutInfos. I used your XComGame.upk changes for Larger Pods mod without deep investigation, but now I need to make things different, so I started to dig deeper. :smile:

 

I can't see why you need to add more than one entry for each alien type in XGBattleDesc.InitAlienLoadoutInfos. m_arrTeamLoadoutInfos seems to be used for determining loadouts by alien type and needs only as much entries, as many alien types squad has. AltWeapon references need to be removed, but other than that no changes are required. I tested it and it works: 6 alien pod (2 main + 2 sup1 + 2 sup2) was equipped properly.

 

Please, correct me, if I'm wrong.

 

I'm pretty sure you are correct.

 

I had that function still hanging around from a very old version of the mod in which I used all 6 elements of TAlienPod to define alien types. In that case it was required to extend InitAlienLoadoutInfos to handle the extra 3 aliens. When I converted it to allow only 3 types and use the AltWeapon to hold counts/etc, it wasn't needed. I still have the function but I don't apply it and everything appears to work correctly.

 

Incidentally, the "bad" behavior it originally fixed was "invisible aliens", which would hang the game when they tried to do anything.

[wghost81]

Thanks.

 

There is another one pawn-related function in XGBattleDescription: DetermineAlienPawnContent. Very similar to InitAlienLoadoutInfos, performs character to pawn mapping.

 

Another question: have you found what's causing Hyperwave Relay to display wrong number of aliens with larger pods?

 

BTW, I may have found why reveal cinematic isn't accounting for additional pod aliens. It uses m_iAlienLimit to setup pod members for matinee. It is set in Default__XComAlienPod. I changed it to 9, but haven't tested this in game yet.

Edited March 22, 2014 by wghost81

[Amineri]

- DetermineAlienPawnContent (as well as the function MapAlienToPawn) use the native XGGameData.MapCharacterToPawn function. However, it's not necessary for us to modify this function, as the mapping is actually configured in DefaultGameData.ini :

;-------------------------------------------------------------------------------
; Character to Pawn (and vice versa) mapping
;-------------------------------------------------------------------------------
; Aliens
CharacterToPawnMap=(CharacterType=eChar_Sectoid,PawnType=ePawnType_Sectoid)
CharacterToPawnMap=(CharacterType=eChar_SectoidCommander,PawnType=ePawnType_Sectoid_Commander)
CharacterToPawnMap=(CharacterType=eChar_Floater,PawnType=ePawnType_Floater)
.
.
.

Soldiers with varying armors are handled differently, using the XGBattleDesc.MapSoldierToPawn function to map the armor type to pawntype directly, and this is configured directly in the unrealscript.

 

For aliens I think the difference is that InitAlienLoadoutInfos is setting up an array to ensure that all of the necessary assets are actually loaded and available (particular for console/iOS with limited memory they can only have so many aliens loaded), while DetermineAlienPawnContent is used to configure each individual alien's particular content.

 

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

 

- I hadn't thought about the Hyperwave relay, but it makes total sense that it would incorrectly parse the TAlienPod structure as it's being re-used. It would only count up to 3 aliens per pod.

 

- The cinematic reveal for Seekers has caused me particular grief, as it triggers the Stealth animation (which actually partiallly stealths the Seeker(s)) during the cinematic, regardless of any other unrealscript. If the actual stealthing mechanics are turned off you end up with an invisible Seeker but with still-visible UI flag. Good find on the Default__XComAlienPod.m_iAlienLimit :)