EXU2 ACTORS BREAKDOWN - by UBerserker

[UB_]

DISCLAIMER: Since i'm taking a bit time off from going back to develop more G59 stuff, I was afraid I could lose momentum to zero by not seeing the Unreal editor open for like a month. So I'm doing this thread, so I can keep my sight daily on the editor and the EXU actors, never forgetting what they do etc...


EXU 2 ACTORS BREAKDOWN

WHAT'S THIS?
Here I will detail the basics of the most important actors within EXU.u that you make use of in the levels.
While literally no one besides me and Buff make EXU2 maps, many people overlook the amazing techs of the mod that enable you to do so much stuff easily (as well as learning more about how the game engine works); there are no tutorials available as far as I know, the EXU2Wiki was never updated and while the actor scripts come with tons of helpful comments, it's easy to be overwhelmed by the technology behind EXU2.
Many of the actors can also work outside of the EXU2 gametype. Mainly, scripted pawns and triggers should all work in oldskool, which means if everyone would have EXU.u installed, we could all enjoy making and playing SP maps with heavily improved and more stable Scripted Pawns, triggers, spawner systems and whatever else could work in there (once again, I don't know which actors don't work outside of EXU2Game, at least the EXMapInfo doesn't).
Note: I don't understand everything in the code.

We will start with the scripted pawns first.


SCRIPTED PAWNS

No, we're not talking about all of the EXU2 pawns here. None of them actually.
We're talking about the EXUScriptedPawn class itself.

See, the EXU2 pawns are all subclasses of Unreal pawns that have been rewritten/reedited as subclasses of the main EXUScriptedPawn class (which is a subclass of ScriptedPawn).

As you can view above, EXU2 has its own version of all the regular Unreal pawns. All improved, be it new properties, bug fixes and overall stability adjustments. These carry on for the entirety of the EXU2's pawn roster - and this is what you'll generally bother with, so that's why you have to know this new stuff beforehand. Certain EXU2 enemies come with their own custom features but this is not part of the topic.

We now check the EXUScriptedPawn class. I'll talk about what you specifically can do throughout properties and list some internal fixes.

Let's get these out of the way:
//var(Filters) bool bFuckerMode;
//var(Filters) bool bExtremeTreesMode;
//var(Filters) bool bMeteorMode;
//var(Filters) bool bHorrorMode;
//var(Filters) bool bClownMode;
//var bool bWaffleMode;
//var bool bBawssMode;
These are unimplemented filters. They were once part of the EXUScriptedPawn's default properties but have been cut off, maybe forever. Found no code for them but from what I remember Buff teased a ClownMode with the piddledoper's firemodes going insane? I don't remember so let's go on.

We will talk about the properties under EXUAI.


Here's the first important new AI state that EXU2 brings:
var(EXUAI) bool Relentless;
Relentless can be true or false. You can also add it as an order: put Relentless in the Orders->Orders or Orders->AlternateStartupState (latter when strictly necessary because you use Orders for something else) and there you go, pawn is Relentless. I'd stick with the EXUAI property though.
What this does, pawns will constantly, and SUCCESSFULLY, chase the player anywhere in the map, regardless if there's pathing or not. Even if they have no vision of you, they'll chase and get to you (assuming you are in a reachable place, of course). They will stop the assault if the distance between them and the players/targets become large enough. There are unimplemented variables about the Relentless state being broken by a specific distance or after a certain set time.
EXU2 introduces an order named AttackPlayer. I'm not fully sure if this order triggers the Relentless state on, as the ForceAttackPlayer coregame function mentions Relentless as True. Either way, this is an AWESOME ORDER that you can set for enemies spawned throughout creature factories (or the spawner system): basically, enemy spawns, he'll instantly go after the player regardless of vision and pathing. If you played God of the Sun in G59, the enemies coming from the portals all have AttackPlayer as a set order for when they spawn, which is why they immediately go after you.
DO NOT USE THE ATTACKPLAYER ORDER (as an AlternateStartupState) for enemies that spawn with the SpawnWhenTriggered order (this is for later). It'll get them permanently stuck on spawn. You don't probably want to use the AttackPlayer order on a placed pawn that's somewhere in the map entirely compared to the player unless you know what you're trying to do.
Relentless otherwise is fine, however in maps with complex layouts, the AI may go apeshit and will heavily lag the engine. Use the Relentless state on enemies that have to fight or chase you no matter what.
Relentless mode doesn't make pawns retreat, ever. They will pursue you until dead.
Note that Relentless and AttackPlayer also work between pawns that hate each other, due to attitude changes or TeamHateTags. Great if you want to force fights between enemies.

EXUAI properties regarding attitude to other scripted pawns.
var(EXUAI) eAttitude AttitudeToOwnClass;
var(EXUAI) eAttitude AttitudeToSubClass;
var(EXUAI) eAttitude DefaultAttitude;
var(EXUAI) name TeamHateTag;
Should be self-explaining. They are all set by default to Friendly.
All these properties work on the spot when changed on placed pawns in the editor, except TeamHateTag because it depends on TeamTag.
AttitudeToOwnClass - the attitude of a pawn with another one of the same type. Here are two Brutes, one is set to hate. This Brute will attack on sight the other Brute (the one with AttitudeToOwnClass=Friendly won't attack back, obviously).
AttitudeToSubClass - same as above, except only all the subclasses of the pawn. I.e. SkaarjWarrior's AttitudeToSubClass=Hate will hate IceSkaarj, SkaarjScouts, SkaarjLords and SkaarjBerserkers on sight but won't hate another SkaarjWarrior.
DefaultAttitude - again, same as above but this is the attitude to any other pawn that ISN'T the same pawn or its subclasses. So, a Brute with DefaultAttitude set to Hate will attack anyone except other Brutes or LesserBrutes/Behemoths - that's what AttitudeToOwnClass and AttitudeToSubClass are for.
So technically you can't have something like a SkaarjBerserker hating everything except Pupae -
the EXUSkaarjBerserkers and its subclasses will still do that however, it's hardcoded in. If you want SkaarjBerserkers with a reasonable attitude pair them (or other pawns) under the same TeamTag. With TeamTags (these are already from Unreal, you can set them under AI, it's a name you can write), enemies under the same team name won't attack each other. This is how it was done with the Skaarj Berserker duo in Nexus End, they couldn't attack each other because they were under the same TeamTag name.
Now there's this:
TeamHateTag:
As you may guess, a pawn will hate on sight any pawn under a specific TeamTag name. You put the same name under TeamHateTag and there you go. "Demons" vs "Saints" is the classic example, and it's shown in G59's Mausoleum of Elohim.
There's however a huge limitation with TeamHateTag: it only works if the TeamTag name is set as a default property of a pawn, not when put it on a placed pawn. So for example, Demons and Saints are under Demons and Saints teams and hate Saints and Demons respectively, and it's all already set in the specific pawns' properties as you use them. However, if you have a Demon (who hates Saints), add a random creature to the level and name its TeamTag "Saints", Demon won't hate it ever. Only as a default property, which may require creating another pawn under a new package to get the desired effect (or just edit a Saint to look like that pawn but bleh).

This property is usually overlooked:
var(EXUAI) float AutoHateRadius;
This works with the Patroling order only, I believe.
Pawns will auto-hate (as in, BEGIN TO ATTACK) anything around them for the specified radius set in AutoHateRadius, even if the targets don't make noise. The default set for all is 2000 (quite large), in contrast to regular Unreal pawns that would virtually have this property set to zero.
The autohate only works if the enemy has sights on you. The radius is like a 360° field of view, of course if the target is behind a brush the enemy can't see him and won't go attack mode.
As for the radius it should be cylinder-based, so you can turn on Radii View in the viewport and measure the AutoHateRadius with the pawn's CollisionRadius (remember to re-adjust the collision values back to normal once you're done!).

Last one for EXUAI:
var(EXUAI) name PawnTags[32];
PawnTags opens up a list of name boxes, from 0 to 31. These applied names are "tags".
You can see these tags as traits; by itself they don't do anything but they are read by other classes and execute a specific script when available. Tags ARE NOT RELATED to TeamTags, so don't expect to use these for AI Hate behavior stuff - this is the most important thing you have to know about PawnTags.
This is a very alien feature that people won't likely use, because it requires them to know the tag names; I personally don't know where to find them all either. I only used this for the "NoDamageStacking" tag, which stops the Hellgun's special damage stacking feature from working against the pawn in question; or "HFNadeImmune", which makes all HyperFlakker grenades to completely bounce off the pawn like if it was a wall. There are some tags, like "Fearless", "Bug" and "Robot", that make pawn not go into fear/retreat mode when they see Shadows or Brussalids. And so on.
Don't mind this feature too much.

We move to the next group of properties, under EXUDebug.

This is not gameplay related stuff, this is all for debugging, testing stuff to see if they work, how they work. The help info is displayed or in-game or in the UnrealTournament log, only when these features are activated. Almost all modern EXU actors have debugging tools, so if there's something that doesn't work, turn debug on and view the log to see where you have fucked up.
For all the scripted pawns, we have these three True/False properties. Of course, by default they are all false:
var(EXUDebug) bool bUseDamageFlashes;
var(EXUDebug) bool bEnableDamageLoggers;
var(EXUDebug) bool bEnableStateLogger;
bUseDamageFlashes info is displayed in-game. It's a super visible version of the TakeDamage effect properties (we'll see these later): the pawn, upon being hit by damage, will flash of a color. Flash color depends on the damage dealt. If you deal damage above 100% of the default value (so the enemy would be weak to something), the pawn will flash red. From 1% to 99% of the damage, the pawn will flash yellow. 0% damage, the pawn will flash blue. Negative % value (so the pawn will be healed by this damage), the pawn will flash green. If the damage dealt is perfect 100% of what it is, the pawn won't flash.
bEnableDamageLoggers info is reported in the log. With this on, you can see the damage you actually deal vs the pawn - damage that may be modified due to resistances or weaknesses.
Example in the log (the numbers at the end of each line is the game level time)
DISCORDUDAMAGELOGGER: Autoplay.EXUBrute0 with 340 Health initially took 15 exploded damage | 12.545918
DISCORDUDAMAGELOGGER: Autoplay.EXUBrute0 Damage Type processor: Initial damage 15 changed to 10 | 12.545918
DISCORDUDAMAGELOGGER: Autoplay.EXUBrute0 now has 330 Health: took 10 exploded damage | 12.545918
bEnableStateLogger info is reported in the log. With this on, you can see the enemy's state/Orders progression.
Example in the log:
EXUScriptedPawnStateLogger: Autoplay.EXUBrute0 switched state from { Patroling } to [ Charging ] 10.938081
EXUScriptedPawnStateLogger: Autoplay.EXUBrute0 switched state from { Charging } to [ RangedAttack ] 11.932814

EXUScriptedPawn features new important variables for the Orders properties.

var(Orders) class<Effects> TriggeredSpawnEffect;
var(Orders) float TriggeredSpawnEffectScale;
var(Orders) float TrigSpawnDelayMax;
var(Orders) float TrigSpawnDelayMin;
var(Orders) name AlternateStartupState;
We can finally talk about the Order named SpawnWhenTriggered. One of the most useful things introduced in EXU2: put a pawn, put SpawnWhenTriggered as an order. Now the pawn is totally invisible in the map when you play it. It's technically still in the level, which means property changing commands and killall will affect these invisible pawns. They are just not spawned, and will only do once they are triggered (classic Event->Tag, throughout the pawn's Tag name).
This is for when you need a few enemies to be spawned in the level in specific positions (as you placed them in the editor) without the bothersome use of creature factories. Once again, they are virtually already in the level, just unspawned, while creature factories outright produces enemies to be thrown into the level (so commands won't affect them, I believe only until the creature factories are active).
Since SpawnWhenTriggered takes the Order slot, you'll use AlternateStartupState as the secondary Order slot for when they spawn into the level. Generally, the order applied is "Ambushing". Ambushing is great as the pawn stays in its place, doesn't make any noise and remains in its regular breath animation. They also don't tend to change state if they hear noise or see something weird.
What you do not use as the AlternateStartupState order is AttackPlayer, as already mentioned above. The pawn will get stuck. Use instead the order SeekAndDestroy (I'm not sure how much this order differs from AttackPlayer - doesn't turn on Relentless?). You don't want many enemies active in the map (thjs is vital in huge EXU levels), so with the SpawnWhenTriggered order you can turn them off until it's necessary to avoid needless engine stressing.
With TriggeredSpawnEffect you can apply an Effect actor for when the pawn spawns throughout the SWT order. Very useful to simulate pawns teleporting in instead of appearing out of nowhere. In EXU2, the most widely used effect is DemonExplo or Hellshockwave. ShockExplo is also a good Effect - just find which one fits the most in the Effect actor list! Note that EXU comes with the EXUSpawnpoints that also use this effect-when-spawn feature.
TriggeredSpawnEffectScale - size of the applied spawning effect. -1 is the default value; when it's -1, the effect will autoscale with the following formula: CollisionHeight / 25. So the size will depend on how big the CollisionHeight value of the pawn is. Otherwise, you can scale it yourself from 0 to a number of your choice (0 = nothing, 1 is the default size of the effect, anything beyond it's the effect scaled bigger).
TrigSpawnDelayMax and TrigSpawnDelayMin are also self-explaining. Basically the delay for the spawn to occur after the pawn is triggered, in SECONDS. So, Min and Max values are 4 and 6 respectively? After trigger, the game will wait between 4 and 6 seconds for the pawn to fully spawn. If the Min value is below zero, the game will only take in consideration the Max value.

Next up, EXUTakeDamage.

This is one of the two big boxes of properties, so we will proceed slowly. This is stuff related to damage resistances, gibbing, blood color and hit effects.
var(EXUTakeDamage) bool bDisableDamageEffects;
When you hit a target that is weak, or resist, or absorbs or is immune to a certain damage type, there will be special effects and sounds upon hit (for example, green hit effects are seen if the target absorbs damage type x plus a special sound is played). With bDisableDamageEffects turned on, none of these effects and sounds will show up while keeping the resistances functionalities the same. Turning this off would be like, essential if you want to use the pawns in a regular Unreal game (since they have resistances too).
Note that there's no way to turn off the effects manually (and separately), only through this settings. Not true for sounds (though you can't have no effects with sounds, only the following cases: effects and sounds, effects with all no sounds, effects with some of the sounds).

The bread and butter of damage resistance/weakness types/values:
var(EXUTakeDamage) name DamageTypes[10];
var(EXUTakeDamage) float DamageScales[10];
This is very easy. You have two lists of 10 entries each. These lists are "connected": in the first list, you type in the DamageTypes and in the second list, the DamageScales values. So, you want a pawn to be immune to Burned damage; put Burned as DamageType[0] (first entry) and put 0 as the DamageScale[0] (first entry, again). There you go. Entry numbers have to match, basically.
The script comments "mock" you if you wanted more than 10 entries but the reason is for stability and to avoid lagging or engine stressing. The system runs throughout a for loop, checking each entries in order, every single time. This is why you put the most common DamageTypes on top, to avoid lag as much as possible (whose impact is likely bigger online).
There are many DamageTypes; Unreal mainly comes with "exploded", "Corroded", "Frozen", "Burned", "Drowned" and "Fall". EXU2 has many many MANY more and you'd want to check the projectiles' own damage type for clearance. Most common ones introduced are "Hell", "Sainted", "lasered", "TachyonDamage", "Shit", "Pulsed", "PulseBeam", "Fusion" and "Stunned". It's all a matter of putting the right names in, and the most common ones on top.
As for the values... the default one is 1. 1 means no resistance/weakness whatsoever. If you put a number above 1, it means increased damage value (WEAKNESS). Below 1, it means decreased damage value (RESISTANT). At 0, it's immunity. Below 0, and the pawn is healed by the damage.
Special hit effects and sounds are set automatically when a pawn is resistant/immune/absorbs/weak to damage.

Regarding damage absorption, there's a specific related property:
var(EXUTakeDamage) float MaxHealingScale;
With MaxHealingScale, a scale-based value, you can set if a pawn, by absorbing damage, should be healed more than its default health or not. I.e. Slith have 210 health and they are set to absorb Corroded damage. With MaxHealingScale valued over 1, absorbed damage will heal them over 210 HP.
With the value you are setting a cap; with the value set at 1, the default, the cap is just the pawn's regular max health. Anything below 1 restricts that cap, until zero where the pawn can't be healed at all (which makes absorbed damage a moot point, so beware). Above 1, increases the cap scale-wise above the pawn's default health. With a negative number, there's no cap, so the pawn could absorb damage to the point that its health will rise to an infinite amount.

Another simple property.
var(EXUTakeDamage) float SelfDamageScale;
SelfDamageScale is another scale-based value. Basically this strengthen or weakens the damage a pawn does to itself (e.g. splash damage). Very useful if you have a Demon who shoots hellbolts whose splash damage accidentally heals the creature in the process, and you want that to not happen.
1 is the default value. Less than 1 if you want to weaken the self-damage (read: pawn does less damage to itself), more than 1 otherwise.

A variation of the above.
var(EXUTakeDamage) float FriendlyDamageScale;
It's the same, except this is damage dealt by other pawns that are under the same TeamTag as the victim. TeamTag-only related, not a thing between classes or damagetypes. Helpful if you have SkaarjTroopers (under the same TeamTag) that use different weapons and you don't want them to kill each other.
FriendlyDamageScale uses the same value system as SelfDamageScale.

The following is for special hit effects:
var(EXUTakeDamage) class<Effects> EXUHitEffect;
var(EXUTakeDamage) float EXUHitEffectScale;
This is if you want a custom effect (with scaled size) of your choice when you hit a target. This replaces the blood sprouts entirely! It has its uses, generally on robotic creatures (EXU2's robotic pawns make use of this feature).
EXUHitEffect is the effect you apply (an Effect class, like DemonExplo), EXUHitEffectScale is the size of the effect displayed (1 = default, closer to 0 = smaller, higher than 1 = bigger, and there's no autoscale this time around). Effects come with specific sounds too, so if you apply ShockExplo as the EXUHitEffect, it'll play its sound every time you hit the target.
NOTE that resistance/weakness special effects will override the EXUHitEffect no matter what.
And another thing, the custom effect will also play on the creature's gibs. So if you have applied DemonExplo, each time a gib is moved or is being hit, it will cast the DemonExplo effects/sounds every time.

Three properties about gibs:
var(EXUTakeDamage) Texture SpecialGibSkins[6];
var(EXUTakeDamage) bool bUseOwnSkinForGibs;
var(EXUTakeDamage) bool bMetallicGibSounds;
SpecialGibSkins can be ignored. Basically it loads sets of gib colors depending on the chosen blood color. It serves a purpose if you want to add custom gib skins, definitely, however it's not possible to add custom blood color (or at least I don't find a way so far but I'm sure there isnt?) which kinds of defeat the feature's usefulness. I believe this is mainly used for special gibs like the Skaarj/Merc/Krall ones when they are decapitated (and yes the head flies now).
bUseOwnSkinForGibs has its uses, especially with energy-based pawns. When this is on, the gibs will have the same skin as the pawn's Skin/Multiskin (this depends if the creature makes use of the Skin property or the Multiskin[n] one), and will also use the Display's Unlit and Style properties that the pawn had.
bMetallicGibSounds is aimed to robotic/metallic units. If this is turned on, the main gib sounds will be replaced with metallic noises.

Another property for gibs:
[size=85]var(EXUTakeDamage) enum eGibType
{ GIB_Normal,
GIB_Always,
GIB_Never
} GibMode;[/size]
GibMode is related to how much damage is required for the carcass to be gibbed when the creature dies (not the carcass itself after the creature died). GIB_Normal is the classic default setting, the enemy may gib instantly or not depending on how much damage they took on death. With GIB_Always, no matter what's the fatal damage applied to the enemy, the body will immediately gib on death. GIB_Never is the opposite, the body won't blow up on death regardless of the damage (the carcass itself will however lose this buff BUT not instantly).

Here comes the blood settings!
var(EXUTakeDamage) enum EXUBloodType
{ BLOOD_Red,
BLOOD_Green,
BLOOD_Blue,
BLOOD_Brown,
BLOOD_White,
BLOOD_MYBLOODvvvISvvvvvvBLACK,
BLOOD_None
} Hemospectrum;
Hemospectrum settings are self-speaking. You choose the blood color for the pawn. It will impact the main blood sprout colors, as well as the skin of the pawn's carcass gibs.
BLOOD_None shows no blood whatsoever, whenever you hurt the pawn or when gibbed. Great on mechanical units (G59's Magatsu pawns also use this).

The last EXUTakeDamage setting
var(EXUTakeDamage) enum eCorpseLighting
{ DLM_LightsOut,
DLM_CorpseLit,
DLM_GibsLit
} DeathLightingMode;
DeathLightingMode is yet another visual control setting for carcasses and gibs, this time related to lighting. This is useful specifically for pawns that cast light - and cast light BY DEFAULT, not pawns that cast lights because you set them to do so when you placed them in the editor. It has to be by default, similar to the TeamTag dilemma vs TeamHateTag.
Pawns in question by default must have a LightBrightness above 0, a LightRadius above 0 and a LightType that isn't LT_None. With DLM_LightsOut, carcass and gibs won't have the light cast that the pawn previously had; with DLM_CorpseLit, only the carcass will retain the light, the gibs won't; with DLM_GibsLit, the lights will be always retained, even with the gibs (they'll only disappear if you destroy the gibs).

We'll be moving now to the other big box of properties: EXUScriptedPawn.

Generic misc variables for gameplay, which you'll touch quite a lot.
var() name MeleeDamageType;
Oh yes, you can set here the damage type of the enemies' melee attacks! That is awesome, even though ultra mega situational, and you'll likely never ever touch this feature (maybe an energy being of fire, and all it can do is Burned damage, even throughout melee attacks).
MeleeDamageType, by default for all EXUScriptedPawns (not sure if this is true for ALL EXU2 pawns but this doesn't matter) has the damage type "hacked". Just write in another damage type like Burned, Corroded and so on.

With EXU you have control over this:
var() int PointValue;
PointValue is how many score points the pawn gives you on death. 100 points? Kill the pawns, you have now 100 points on your scoreboad. This however won't work on Oldskool, the mod likely calculates points per enemy health in its own way.
Apparently the PointValue automatically increases if the pawn heals himself over the default amount due to damage absorption (depends on MaxHealingScale settings); the point increase is permanent and will never decrease. However my current tests result with the pawn giving you zero points due to this... probably some bug.

The following settings are related to the pawns' ranged projectiles:
var() int ProjectilesPerShot;
var() int RangedAccuracy;
var() int ShotsPerBurst;
var() float TimeBetweenShots
If you played EXU2 and saw enemies like Skaarj that can shoot multiple projectiles at once, these are the settings that allow that stuff.
ProjectilesPerShot - this is the number of projectiles that are spawned at ONCE. These are not the bursts, this practically is having pawn x that shoots once, and instead of spawning one projectiles it spawns more than one. Like you have a Skaarj Warrior and this property is set to 2 (default is 1 and why you would ever use zero? Use integer numbers only), he will shoot two projectiles per each hand, in total four (because Skaarj Warriors use two projectile spawning spots, compared to Krall that have one).
RangedAccuracy - This is not fully related to the other three settings here, as this already by itself changes the accuracy of the pawn's ranged projectiles. Therefore it's useful. Minimum working value you can input is zero, maximum is 65536; smaller is the value, bigger is the accuracy (zero is perfect). Since 65536 is a pretty huge maximum number, if you want the pawn to scatter projectiles all over the place with no logic, you have to put in a really huge number. The usefulness of this property kicks even more when you have multi-projectile settings enabled, like ProjectilesPerShot; if the accuracy would be zero and if ProjectilesPerShot is above 1, the multi-spawned projectiles would all take the same exact trajectory, meaning you'd be seeing one projectile at best visually, which is awful if the projectiles in question are solid things like rockets.
ShotsPerBurst and TimeBetweenShots - now this is the burst-shooting setting. What it does is that the enemy does the ranged attack once, and it'll spawn in succession a bunch of projectiles. TimeBetweenShots dictates the delay between each projectiles shot in the burst. It works in seconds; if you put it at zero, you'd get the same effect as ProjectilesPerShot >1.
Generally, you don't want to go overboard with the amount of shots; not because it may look stupid at one point but some enemies, like Brutes with their "walkfire" firemode, will temporarily fuck up their animations. Let's take the Brute's walkfire animation; if the ShotsPerBurst value is really high (say 15), the Brute will finish the walkfire animation before the burst ends, and he'll temporarily stay in his default "fighter" animation until the burst is over. This is where you remedy stuff with TimeBetweenShots, decreasing the delay time between projs (also, I don't think there's ever going to be a case where TimeBetweenShots would be higher than 0.1 seconds). Once again, be sure to use this in conjunction with RangedAccuracy to get whatever scatting burst shot from the enemy you'd want for realism.
ShotsPerBurst and ProjectilesPerShot can be used together, as well with the other two settings, so you can have timed bursts of multi-shot projectiles with a specific accuracy. Insane.

I doubt any SP pack would ever make use of the Xloc after ONP.
var() int XlocBlockMag;
XlocBlockMag is the pawn's protection against xloc telefrags (both regular and the "unused" EXU translocators). By default it's 0, meaning there's no protection and the pawn is therefore telefraggable.
Any number above 0 is the speed in which the xloc disc bounces away from the pawn. meaning you cannot telefrag the pawn. Even if it can walk over a disc on the ground, you'll teleport inside the pawn but you won't frag him (you can walk out of the "body" of course).
If the number is below 0, the disc will break when it touches a pawn.

This is definitely for EXU2 only, since I doubt the boss bar will appear outside of EXU2Game.
var() name BossTag;
EXU2Game has support for enemy health bars, suited for bosses. This is done throughout the use of the BawssTrigger, the actor that brings up the health bar overlay for the HUD (it can use custom textures for bar, energy and pawn name). The BawssTrigger needs as Event whatever name you'll use for the pawn's BossTag. Then the BawssTrigger has to be triggered (that's for its Tag property).
So Trigger activates the event "berithhealth" which is the name the BawssTrigger's Tag uses. BawssTrigger's Event name is "knightberith", which is the BossTag name of the pawn.

The following is for visuals, at least that's what it's used for so far:
var() class<EXUOverlayProxy> OverlayProxyClass;
See the glowing eyes of DemonSkaarj? The glowing staves of DemonKrall? Tonatiuh's glowing gold parts of the body? This is all part of OverlayProxyClass.
"specify a proxy actor for spawning attached actors, such as overlay effects" and that's the best comment one can give. This requires other actors that already exist or that you have to create yourself; generally, if you attach visual overlays, you have to apply special textures (the glowing stuff like eyes) to MultiSkin[6/7] settings, check Demons for example.
I am unable to explain the extent of this setting. Basically you create your overlay class (i.e. under EXU2GenericActors->EXUOverlayProxy), script in whatever you need like spawning a panel class (i.e. Tonatiuh's golden ring around him, which was also a newly created DoomHalo subclass under Effects->EXUGenericEffects->EXUFlickeryPulseryThing that had the golden ring as a texture); then apply the overlay to the pawn's OverlayProxyClass and set the correct glowing textures under MultiSkin[6/7].

Next...
var() class<Effects> MuzzleEffect;
var() float MuzzleEffectScale;
You can customize the shooting muzzle effects for enemies! EXUScriptedPawns are all set to have whatever they need to be like the original Unreal pawns, like the Brutes with the rocket muzzle effect or the Skaarj Warriors with nothing as they should.
MuzzleEffect needs the effect class, MuzzleEffectScale is the scale value setting (1 = effect default size, go lower for smaller, higher for bigger). Technically this opens up another setting that you need to bother with if you apply projectiles to pawns but overall it allows for more customization.

This is definitely for EXU2Game only:
var() localized string PawnName;
What it says on the tin. The Extractor, when you zoom on a pawn, will read the pawn's MenuName or will read the PawnName if the latter is used. Not sure what else reads this variable other than the Extractor (not the death messages as far as I know).

This closes up the EXUScriptedPawn settings.
There are new properties inside the Sounds block:

var(Sounds) sound EXUDeathSound;
var(Sounds) sound EXUShootSound;
var(Sounds) sound EXUHitHealing;
var(Sounds) sound EXUHitImmunity;
var(Sounds) sound EXUHitResistance;
var(Sounds) sound EXUHitWeakness;
var(Sounds) float ShootVolume;
var(Sounds) byte ShootMagnitude;
Quickly.
EXUDeathSound applies another sound layer for when the pawn dies... supposedly. It doesn't seem to work at all, so ignore it.
EXUShootSound is the same as above, except for when the pawn shoots a projectile. And this one WORKS. With ShootVolume, as well as ShootMagnitude, you can set the volume of EXUShootSound. SoundVolume goes up to 8, apparently up to 16 too but I'm not sure; SoundMagnitude instead is the simultaneous repetition of the EXUShootSound with the applied SoundVolume; it's a byte, so it goes up to 255. Higher the number, higher is the number of simultaneous repeated sound recalls, which means it'll be MUCH LOUDER. You don't want this property (especially for projectiles, this is really more suited to EXUSpecialEvent sounds) to have a really high value, if it goes past 30 or hell 20, your ears might start exploding.
EXUHitHealing, EXUHitImmunity, EXUHitResistance and EXUHitWeakness are the sounds that play when you hit a target that absorbs/isImmune/resists/isWeakTo a certain damage type. You can't manually get rid of the effects (you can only turn all them off at once) but you can do this with the sounds, as well as completely changing them. Sadly you can't have these on with the hit effects being turned off.

This ends all the new properties that EXUScriptedPawns have compared to the outdated and old regular Unreal versions :>

EXUScriptedPawns also have internal improvements. I will list some of the most important ones here:

• EXUScriptedPawns attack bots on sight.
• There seems to be a bunch of Attitude improvements? As in the pawns will attack whoever has AttitudeToPlayer=Friendly (it's true, Buff?)
• Pawns are even more tempted to run away if their health and aggressiveness are lower compared to others.
• Better roaming from the looks of it, and much more territorial. Also pawns seem to move a bit away to make space to the patroling one passing by.
• Fixes for the bullshit ultra-fast sidestepping that happens when you use the Minigun or the Stinger's priamary fire against fast units. This should also fix pawns being stuck in one place when they are hit by extremely high ROF attacks.
• Flying pawns now have a maximum wandering distance (1500 is the radius), from the spot where they last seen an enemy (from there). Wandering distance appears to be related to the pawn's CollisionRadius value. Delay of wander decisions are also randomized. This is a big FUCK-YOU to Gasbags who would fly into nowhere.
• General fixes to stop many accessed nones from appearing (garbage that fills your log and impacts on the game's performance) and buggy animation code.
• Pawns now always die if their health touches zero while falling (I think this is more of an animation fix).
• Stunned function implemented. This is for the Stunned status applied throughout StunFlare and the Piddledoper's tertiary fire, which locks the pawn in one place (in a electric cage -sort of thing) until after few seconds. Stunned damagetype's resistances/immunity almost or completely prevent pawns being stunned in this way.
• EXUScriptedPawn class allows for the HellGun damage stacking ability to be a thing.

That's it for this post.
In another day, we'll check the EXU2 version of the regular ScriptedPawns to see what's improved about them. Should be short.


EDIT: TO WAFF
EXUDeathSound seems broken. and PointValue gives 0 points if the pawn heals with self-damage (or just self-damage is enough?)

[UB_]

MAIN EXUSCRIPTEDPAWN CORE SUBCLASSES

In this post we will see the improvements and additions to the regular Unreal pawns that are subclasses of EXUScriptedPawn - so EXUBrute, EXUKrall, EXUGasbag and so on. If there's something that differs with the non-EXU2 variants of these pawns (i.e. Behemoths, KrallElites, all the subclasses that were pawns in the original Unreal game), it'll be mentioned.
Pawn order is alphabetic.

EXUBrute
Brutes, faces of EXU2, home race of ChefFucker. Brutes and Behemoths (not LesserBrutes) retain their 30% resistance to exploded damage as seen in the EXUTakeDamage settings (DT[0]=exploded, DS[0]=0.70000).
Brutes here have their own MuzzleEffect: EXUMuzzleFlare. An improvement over the default one, the muzzle flare here fits more rocket firing, while the old Unreal one seems suited more to a gun (which was likely intentional, since in early Unreal development Brutes' weapons were plain guns).
LesserBrutes have no differences; Behemoths have a new unique piece of code regarding attack states - it seems like that after he's done with a battle, he will roam around instead of not moving (tested a Brute and a Behemoth; let them attack me, I retreated away. Brute remained in its position, the Behemoth would wander around instead).
EXUBrute's JumpZ property is 325 instead of -1. Later on this.


Let's check the EXUBrute class' new variables/settings (EXUBrute box properties):
var() bool bDoubleFire;
With bDoubleFire turned on, Brutes' "stillfire" shooting mode (when they stay in one spot and use both guns) will fire missiles from each gun SIMULTANEOUSLY instead of left->right->left->right and so on. This is awesome for bTurret=On Brutes.

These are settings for their gangsta-like firemode (gutshot):
var() float LngRngGutShotChance;
var() int ProjectilesPerGutShot;
var() int ShotsPerGutBurst;
var() int GutRangedAccuracy;
var(Combat) class<Projectile> RangedProjectile2;
First off, RangedProjectile2 is found within the Combat properties, below RangedProjectile; by default, this property is unused and when it's so, the Brute will only use the projectile set within the regular RangedProjectile property.
Indeed, here you'll have full customization for the "gutshot" firemode. So how it always worked in Unreal? It would randomly replace the "stillfire" firemode if the target was very close to the Brute pawn; the EXU version of the Brutes make it possible that the gutshot is used for targets far away, as well as customizing them separately from the other Brutes' firemodes for shit n' giggles.
Gutshot firemode always comes with two projectile spawning instances.
ProjectilesPerGutShot - set the number of projectiles shot simultaneously per every shooting instance.
ShotsPerGutBurst - the burst shot per every shooting instance. It'll read the TimeBetweenAttacks property under the pawn's EXUScriptedPawn properties. Reminder that if ShotsPerGutBurst's value is too high, the Brute may finish the animation before all the projectiles have been shot, leading to the Brute's using the default still/fighter anim once he's done with the gutshot (this is something that's true for almost every other pawn that use ranged projs).
Unfortunately, there's a big problem that may be hopefully addressed in the future: whatever ShotsPerGutBurst setting (that isn't 1) you'll put, will be copypasted into the Brute's other firemodes after the Brute uses gutshot once. ProjectilesPerGutShot isn't bugged at least.
GutRangedAccuracy is the same as RangedAccuracy, except for the gutshot (from 0 to 65536, bigger the number less is the accuracy). However, if this value is at -1 (which is the default) or any number less than 0, then the GutRangedAccuracy will be equal to the pawn's current RangedAccuracy (which is 325 by default for Brute pawns) multiplied by 1.5.
LngRngGutShotChance represents the chances for gutshot firemode to be chosen over walkfire. Default is 0.050000. If it's 1, Brutes will always do gushots. This won't impact the walkfire firemode.

This covers all of the Brute's new properties and variables.
Following is a list of internal improvements:

• A check to prevent Brutes to shoot through doors or thin brushes with their stillfire firemode.
• Gutshot firemode can be done even if the target is found far away.
• Adjustments for projectile spawning offsets (for the pawn's DrawScale changes).
• You noticed Brutes have a JumpZ value of 325. Indeed, an experimental jumping code has been added, so if they're on a platform and they feel the need of chasing you, they'll jump off it.
• Brutes can now swim, sort of. Regardless of their Mass, when a Brute falls into a deep pool they'll stay afloat on surface level, always, and will do any action such as wandering around or shooting exactly like on land; they'll NEVER go underwater and can jump out of a pool if possible. Brutes' WaterSpeed and UnderwaterTime values are unchanged. A Brute that spawns or is placed INSIDE the water pool (why you would do that?) however won't be able to move around and will be barely capable of shooting (this doesn't seem to affect pawns that use certain PawnTags, maybe the Robot one? Though in that case they'll only walk at the bottom, not swim).
• Brute's "berserk" mode shouldn't be lost if there's still a visible enemy around (the code mentions it's not perfected yet).

BUGS:

• ShotsPerGutBurst property value will be permanently used by the walkfire and stillfire firemodes after the gutshot firemode has been used at least once.
• Brutes will remain stuck in one spot with their running animation if they spawn inside a water zone and will barely be able to shoot. Doesn't happen when a Brute enters a waterzone from outside, as well as if some PawnTags are used (Robot? Inorganic?).

EXUCow
No changes.

EXUDevilfish
EXUDevilfish are set in the code to have a friendly Attitude to Squids and any EXUScriptedPawn that have the word "Fish" in any of the PawnTags.

EXUFly

THIS:
var() int StingDamage;
Unlike the original Unreal variant, you can finally set the melee damage of the Fly throughout the StingDamage property (under the EXUFly box). Default melee damage is 15.

EXUGasbag
Gasbags are ones of the trademark creatures of EXU2. Changes are to be expected. There are no new properties or property changes whatsoever but here we go with the internal changes instead:

• This is not purely related to this class but the wandering changes for flying pawns in the EXUScriptedPawn code will stop Gasbags from flying into unreachable parts of a level.
• This is probably very important: there's no EXU version of the defacto worst Unreal pawn: the GiantGasbag. I take it as a plus since that pawn was fucking horrible - just make your XL size Gasbag instead.
• const ProjectileOffset = vect(31, 0, 7); // Can be overridden by subclasses. A quick way if you want to set your own projectile spawnpoint of the pawn for a subclass. Mainly used in EXU2 for the LaserDrones and Hellfighter classes, that are under EXUGasbag.
• Gasbags have a new state called "BurstShooting" which is used for long burstfires. In this way, the Gasbag will remain with its mouth open during the spawnbelch animation instead of finishing it before the burstfire is done. Other creatures with ranged projectiles have this state.
• Misc. stability improvements (say NO to accessed nones).

EXUKrall

EXUKrall do have new variables/properties, and are all related to the Krall's legless mode:
var() bool bLegless;
var() float ChanceOfLeglessness;
var() float LeglessHealthThreshold;
var() Texture SpecialGibSkinsII[6];
bLegless is off by default. When it's on, the Krall will start out in its legless form.
Legless form for EXUKrall works differently, and better. It won't spawn a separate class (the LeglessKrall one) but the EXUKrall will keep existing with modified properties that match the LeglessKrall and using the legless animations. More importantly, this means they'll also keep whatever health they had when they became legless, instead of having 1 HP and dying from someone jumping on their back - i.e. Krall had 35HP when it went into legless mode, it'll keep those 35HP with no weaknesses added. Same if bLegless is on, you'll have a full health Krall in legless mode. Also the new legless Krall won't die immediately in the water.
ChanceOfLeglessness (0.75 is default) and LeglessHealthThreshold (0.5 is default) control the chances of Krall going legless and the health threshold for how much health the Krall needs to lose for it to possibly enter legless mode. LeglessHealthThreshold is used in the following formula: Default.Health * LeglessHealthThreshold (LeglessHealthThreshold is .5, Krall default HP is 180. 180 * 0.5 = 90. So once it's below 90HP the Krall might go legless. Values go from 0.000000 (0%) to 1.000000 (100%) for both. Note that even if both are at 100%, the Krall won't instantly go into legless mode for the slightest of damage. I'm not very sure of the way it works.
SpecialGibSkinsII is SpecialGibSkins but for something related to gib chunks lost by the Krall, probably when legless mode is triggered.

Internal changes and improvements for Krall:

• Similar to Gasbags, burstfiring animation hack for Krall is implemented but it's only for when he fires without moving (and regarding the animation on where it works, the Krall will keep being stuck in that one until the burstfire is fully complete). So if you have a Krall using burstfiring with a shittons of spawning projectiles, it's recommended to turn off MovingRangedAttack (Combat properties), as well as having ChanceOfLeglessness equal to zero.
• Krall's projectile spawning offsets seem to be adjusted for the better but I believe it's related to the offset change when the Krall goes legless mode.
• EXU's Krall won't aggressively hate Nali.
• Accessed none fixes.
• The EXUKrallElites lack the PreBeginPlay function of the regular ones (which had bCanDuck = True only I believe). I'm pretty sure the old KrallElites would retreat and crouch somewhere and this gets rid of that dumbshit (if it existed, don't judge me).

EXUManta
Nothing appears to be changed (their wandering should be restricted, however). Buff I thought you removed the whole Skill 0 = AttitudetoPlayer Ignore thing??

EXUMercenary
One of the more majorly improved Unreal pawn classes. However, at the moment (if ever), this class isn't really suited for regular Unreal.
The reason here is that the Mercenary's machinegun now finally makes use of projectiles, which you can customize. Under Combat properties, RangedProjectile is for the machinegun, RangedProjectile2 is for the rocket firemode.
Now, the machinegun utilizes the custom projectile DTGShot (EXU class; EXUMuzzleFlare is applied separately throughout the MuzzleEffect property, similar to the Brutes); compared to the old's Mercenary machinegun, this one is UTTERLY OVERPOWERED, EXU-LEVEL. Never ever misses the targets and pretty much tears down health in seconds. The workaround to this would be creating a custom DTGShot projectile whose damage is heavily nerfed down, up to you if you want to keep Mercenaries to god-tier status or not (as if they weren't strong enough).
EXUMercenaries don't have anything for the Texture property, no "Silver" texture unlike the original counterpart. When they'll use the god-mode shield, instead of the classic shining blue texture, the shield itself will look like a moltenmetal/glitchy/MESHENVIROMAP version of whatever skin the Mercenary currently has - so for the regular Merc it'll look like brown, for the MercElite dark blue with shades of red. You can fix this yourself by applying Silver to the Texture property; if you prefer these shield visuals, you should instead adjust the lighting color the Mercs cast, which is always light blue (therefore too bright for those different shield skins).
MuzzleFlare effect is used for both firemodes, you can't have two effects separately.


Onward, here are the EXUMercenaries' new settings; the following ones are found under the Combat properties:
var(Combat) class<Projectile> RangedProjectile2;
var(Combat) float AltProjectileSpeed;
So with EXUMercenaries we have customization for both fire modes. With RangedProjectile and ProjectileSpeed being used for the machinegun firemode, RangedProjectile2 and AltProjectileSpeed are the same settings for the heavy (rocket) firemode.
AltProjectileSpeed's default value is -1 - it'll use the ProjectileSpeed value instead, so you'll put a number different from -1 if you want to override ProjectileSpeed with AltProjectileSpeed's custom value.
If RangedProjectile2 is unused, RangedProjectile will be used instead, and WILL use the AltProjectileSpeed value (alongside AltRangedAccuracy and AltProjectilesPerShot described below).

Under EXUMercenary, we have these:
var() int AltRangedAccuracy;
var() int AltProjectilesPerShot;
var() float AltFireFreqMoving;
var() float AltFireFreqStanding;
AltRangedAccuracy - RangedAccuracy value for the rocket firemode. The usual, 0 to 65536. Except in this case, if it's set to -1, the RangedAccuracy value will be used. Ditto on zero but with a 25% accuracy boost.
AltProjectilesPerShot - I don't have to explain but mind this: EXUMercenary's ShotsPerBurst property affects the altfire/rocket firemode, not the machinegun one (so you can't set burst settings for the latter but ProjectilesPerShot does work instead).
AltFireFreqMoving and AltFireFreqStanding dictate the chances for the Mercenary to use the rocket firemode (moving one and standing one, separately!), from 0 to 1 (decimal values). If it's 1, the Mercenary will never use the machinegun firemode (and this makes ShotsPerBurst more attractive as you don't have to worry about its inability to give burstshots to the primary firemode). If both are at zero, machinegun mode only will be used instead. If both are below 0 (-1), the Mercenary will use the rocket altfire mode underwater ALL THE TIME, while on land he'll use the machinegun.

Once again, it's a good idea making use of both RangedProjectile classes. Trust me.

Since the muzzleflash effect is used for both firemodes, you can use this instead to recognize which firemode gets used:

var(Sounds) Sound EXUShootSound2
EXUShootSound2 is the EXUShootSound counterpart for when the rocket firemode is used. The first one uses the Enforcer's E_Shot sound (so if you change the machinegun projectile to something completely different, you'll have to change this sound for realism), while the second is empty by default.

Internal stuff:

• Similar to the EXUGasbags, there's the handy line of code involving the const with the projectile spawning offset (ROCKET FIREMODE ONLY). I'm assuming the reason this exists is because of the double-armed Mercenaries (the HeavyMercenaries, though they don't work that well).
• Usual story with burstshooting: long bursts should be ok when the Mercenaries shoot while standing still but I'm expecting animations to end early during walkfire if the burst is too long.
• Fire offset locations based on the Merc's animations for the machinegun have been all re-hardcoded for more reliability.

Bugs/issues:

• DTGShot is too overpowered for regular Unreal. Maybe use a nerfed down subclass.
• Silver texture is not applied, so the shield visual will use the skin for bMeshEnviroMap=True. Simple to fix, apply Silver (or anything else) to Texture.

EXUNali
No changes.

EXUPredator
They don't fill anymore the log with accessed nones garbage and other debug stuff, which is already a massive improvement. They have standard attitude, i.e. won't attack other ScriptedPawns (except Nali and I suppose Cows too). You set so attitude stuff throughout the available properties. There's this:
var() Texture SpecialGibSkins[6];
There's experimental code for a "headshot" death for Predator, spawning an extra gib chunk on death (skin used throughout SpecialGibSkins's textures). However, the Legend developers never put an headless death animation in for the Predator and the feature was aborted. Doesn't seem it's possible here either though.

EXUPupae
No new properties, however there are a bunch of internal improvements to the class:

• Pupae will be friendly to anyone that has SkaarjFamily as one of the PawnTags. They'll also be friendly to SkaarjBerserkers instead of ignoring.
• Pupae cannot damage other Pupae by accidentally jumping onto them (stomped damage). This is to avoid piles of Pupae damaging themselves in tight spots (for those who played Dasa Cellars in EXU2 BI, you might know).
• Pupae can now swim and very well too.
• Lunge attack improved; now the lunge distance will be increased depending on the CollisionRadius of the Pupae (this is good for bigger Pupae to make them cover bigger distances proportional to their size).
• Randomly, Pupae will play their death animation for lunges. This is purely for fun, even though it might look out of place outside of EXU.

EXUQueen
The 50% resistance to ' for Queens had no meaning, so it's not there.
No new properties, so here are internal changes:

• Queens will ignore SkaarjBerserkers instead of hating them. Other than Skaarj and Pupae, they will also be friendly to Warlords, to Slith and to anyone with SkaarjFamily as one of the PawnTags.
• Projectile spawning offset adjustments.
• If a Queen should teleport with the Shield on, the Shield will immediately disappear.
• AI fixes/improvements for keeping aggressivity up after teleporting, I guess.

EXUSkaarj
Surprisingly not much to say.
This is the main core class. Internal changes:

• FUCKING IMPORTANT: Spin damage is now fixed on Unreal difficulty, so whatever melee damage value you put will actually work now.
• Skaarj are friendly to anyone with SkaarjFamily as one of the PawnTags.
• Various misc improvements (say no to accessed nones and shit).
• Improved lunge code, probably for better accuracy and for larger Skaarj.
• Shouldn't be firing projectiles (the animation) if you don't have one.

EXUSkaarjTrooper DOES NOT WORK RIGHT NOW. THEY SPAWN WITH NO WEAPONS. BUFF FIX THIS QUICK.

Either way, Troopers have something new:
var() bool bTossWeapon;
bTossWeapon is true by default. If this setting is false, the Skaarj's weapon won't be dropped for you to pick.
Other than this, there seems to be netplay related improvements.

EXUSkaarjWarrior - just recoding for spawning projectiles' offsets. And burstshooting anim-stucker for when they fire long projectile bursts (standing still only).
SkaarjBerserkers will be friendly to Pupae and Queens (this should mean that battles between EXU variants of Berserkers and Pupae/Queens will never happen, which makes more sense) but will still hate others. Remember that his hate is not instant - he'll only act if the other enemy goes in attack mode against any existing target. The hate part is overall unchanged.
IceSkaarj keep the immunity to Frozen damage.

EXUSlith
EXU2 finally makes it canon that Slith are Skaarj.
Slith will ignore SkaarjBerserkers until it's being bothered, will still hate Nali, and will be friendly to Skaarj/Pupae/Warlords/Queens and anyone with SkaarjFamily as one of the PawnTags.
Projectile offsets / burstshooting stuff, bla bla.
Corroded immunity is there.

EXUSpinner
Arc-trajectory projectile users like Spinners will enjoy the new arc calculation system implemented for EXUScriptedPawn. Extremely efficient at hitting enemies from any distance.

EXUSquid
Attitude stuff implemented, because the original Squid didn't have them! He'll be friendly to Devilfish anyone with Fish as one of the PawnTags.
Lots of technical issues fixed (accessed nones, call to nonexistent animations and so on).

EXUTentacle
WhipDamage is 50 instead of 0 by default. Their projectiles are also STRONGER - deal 45 damage instead of 12 and are very fast. I guess just use the regular Tentacle projectiles instead? Otherwise I'd be fine with Tentacles being relevant enemies in every stage of the game.

There are new settings:
var() bool bFinishAttackAnim;
var() float ShootRate;
With bFinishAttackAnim on, the Tentacle will finish his shooting animation before shooting again. This is to prevent the multi-shooting issues for when the Tentacles would play their hurt animation and reset the shooting one.
ShootRate (default is 1.00000) increases the shooting animation speed, therefore their rate of fire.

Tentacles will be able to fire at underwater targets always, without AI retardation fail. They'll also actively attack any player who crosses their AutoHateRadius value property (no orders needed this time).
I don't fully understand the attitude code but I suppose Tentacles will attack anyone with a TeamTag he hates and pawns with ExistentialThreat as one of the PawnTags? Unsure.

EXUTitan
EXUTitans will not attack other ScriptedPawns by default. This can be overridden with the attitude properties.
Beyond that, technical fixes, improved rock spawning offsets and functions.
Titans keep their 30% resistance against exploded damage.

EXUWarlord
EXUWarlords have now a 75% resistance against exploded damage, compared to the 0% of the old versions. That owns.

Two new properties:
var() bool bFlightEnabled;
var() float AfterBurstDelay;
bFlightEnabled is True by default. If it's false, Warlords WILL NEVER GO FLY MODE. THANK YOU.
AfterBurstDelay is, uh? Apparently it delays the proper end of the Warlord's shooting animations. 0 is default, and it's based in seconds. If this is put to number x, the Warlord after shooting will remain stuck in its final frame of the shooting animation for x seconds. This is likely made for some Warlord subclasses that make use of heavy burstfiring. Don't touch this otherwise.

Warlords mainly ignore SkaarjBerserkers unless provocation, hate Nali, friendly to Skaarj/Queens/Slith/Pupae and anyone under the SkaarjFamily's PawnTag.
Probably AI fixes inside the code.


That ends this post! In another day we'll probably check EXU's Trigger actors.

[Sat42]

Thank you thank you so much for doing this UB!!!

This type of document is exactly what I needed

It's all great new stuff for the regular gametypes, but if I ever want to make an EXU2 map then this is also damn useful!

Apart from that (and the need to fix the EXU2 Skaarj Trooper class):
can you please reiterate again what's wrong with the Giant Gasbag, besides it starting fights with its own offspring? (If I make a regular Gasbag giant, I lose the spawning of other Gasbags feature) P.S.: you could post that elsewhere if you feel it would clutter this place.

Cheers!

[UB_]

Apart from that (and the need to fix the EXU2 Skaarj Trooper class):
can you please reiterate again what's wrong with the Giant Gasbag, besides it starting fights with its own offspring?

The default properties were really bad. It was no different than placing a Gasbag and increasing its DrawScale. I'm fairly sure the spawning system it used wasn't good either and was visually terrible how it worked.

[Sat42]

Apart from that (and the need to fix the EXU2 Skaarj Trooper class):
can you please reiterate again what's wrong with the Giant Gasbag, besides it starting fights with its own offspring?

The default properties were really bad. It was no different than placing a Gasbag and increasing its DrawScale. I'm fairly sure the spawning system it used wasn't good either and was visually terrible how it worked.

Gotcha I agree the way the spawning system worked was not visually convincing.

[jaypeezy]

This is very cool of you to do this, thanks. Something like this will help anyone contributing to EXU2 in the future (and would have been pretty helpful for me too with the crap I was making a while ago). Maybe this will be the impetus for me to come out with another pawn pack...

[ividyon]

A nice reminder of how EXU2 is a great toolkit to make new Unreal maps with, without actually going into EXU2 insanity. Kickable gibs, AI and code improvements, the new UI and other features of EXU2 are more than worthwhile as a code base for a "standard" Unreal fantasy pack.

[UB_]

I forgot to mention here that EXUScriptedPawns do not have permanent carcasses or permanent blood decals. (like current 227); makes sense within EXU, maybe a bit less in Unreal maps but hey performance and cleaniless above everything.
Kickable gibs will very rare overall as outside of EXU gibbing isn't that common.

[Diego96]

Perhaps instead of kicking gibs, you could increase their "health" to make it so they get knocked back from explosions a lot. Makes sense for me since I usually avoid blowing up gibs, they just banish.

[MrLoathsome]

Great info here UB.

Nice work.

[medor]

@MrLoathsome

ECoop -> http://ecoop.ucoz.com/ is dead since some days

[MrLoathsome]

Yes. It seems that site is now gone.

Core set that up 10 years ago, but I never had more than min moderator rights there.
Ain't heard from core in over 3 or 4 years now.

Hopefully somebody has those files all backed up.
*Edit: I will take the dead link out of my sig now.

[medor]

Hopefully somebody has those files all backed up..

I ave all your files related UT99 http://medor.no-ip.org/index.php?dir=

[Buff Skeleton]

Also FYI, as of 7.2, all the bugs mentioned here should be fixed (except for the brutes that start in waterzones thing, which should be super rare so it's not much of a priority)!