Not every animation has an owner. Originally the owner was set in few places, like when it was relevant to render a projectile in house colors. Ares expands this a bit, but there are still many ownerless animations, thus there's nothing to pass on when dealing damage. _________________ QUICK_EDIT
Regarding the animation damage issue, where sometimes anims don't do damage: could it be the firing unit is cloaking? The game makes anims lose their owners when they cloak.
cxtian39: Thanks!
mevitar: It's on my list to look into it. Each deactivation logic has to check all others, and maybe some checks are missing here. _________________ QUICK_EDIT
Regarding the animation damage issue, where sometimes anims don't do damage: could it be the firing unit is cloaking? The game makes anims lose their owners when they cloak.
No cloak was involved in the tests i did. It was regular infantry and the warhead was fired by a defense structure with a long range arcing projectile weapon. QUICK_EDIT
Yeah its not cloak. My issues for example are on a player owned chopper that does not cloak and an airstrike SW. One of them uses Next and both loop (which worked fine with Damage.Delay on earlier versions). QUICK_EDIT
Rate= less than 900 might be the "problem". I've reworked the code, but I'm not yet ready to release a new testing build. There's still a lot of issues I have to look into. The plan is to make the Anim Damage not game-frame-exact, but using anim-frames as the frame of reference, that is, factoring in Rate=. This is what the original game did.
New version should be ready for the weekend. _________________ QUICK_EDIT
Most likely the last pre-RC testing build (18.243.1246), with a few new features that fix existing feature.
Are there any loose ends that I still have to connect before I call it RC? I'm still not sure about Splits and AffectsAllies, Enemies and Owner handling. Jumpjet conversion still has some issues that might need to be resolved.
Minor additions
Fixed passenger pip generation, which was backwards
Observers are considered allies regarding Super Weapon timer visibility
If EMP or PoweredBy deactivates a unit, let go of locomotor-attacked victims
Units picked up by Magnetrons count as ground units regarding EMP.Threshold
Fixed Magnetrons juggling units that had their drivers killed
Animation Damage.Delay reworked
Changed Damage.Delay to use the animation's actual frame as reference (that is, also respecting Rate=). Damage will be applied only after Damage.Delay number of frames have been played.
This is about what I wrote some time ago: deterministic again, but not game-frame accurate. Anims of the same type will not all fire at the same time, but damage is guaranteed to fire first after a certain amount of frames have played.
CanBeDriven for TechnoTypes
[TechnoType]CanBeDriven= (boolean, defaults to yes)
Whether this unit can be reclaimed by a driver. If no, this unit cannot be captured by a driver after the original driver has been killed. If yes, ownership and other still might still prevent the unit from being captured.
Weapon effect customization
[Warhead]EffectsRequireDamage= (bool, defaults to no)
Whether warheads will only apply the weapon effects if at least one hitpoint has been dealt to an object. If no, weapon effects are also applied if the no damage is dealt.
[Warhead]EffectsRequireVerses= (bool, defaults to no)
Whether warheads will only apply the weapon effects if the Verses for the target's armor are above 0%. If no, weapon effects are also applied if the warhead cannot damage the object.
Note that the default behavior has changed with this release. Are the defaults okay? Should it rather be yes and yes like before? _________________ QUICK_EDIT
CanBeDriven on specific TechnoTypes works correctly (for example, a CanDrive=yes infantry is able to enter and control other civilian cars on the map Alamo, but not the school bus with CanBeDriven=no on [BUS]).
EffectsRequire* tags don't appear to work for me, but I might not be using them right.
Assuming everything not listed here is unmodified Yuri's Revenge:
[SAFlame]
EffectsRequireDamage=no; with both of these set to NO, my Initiate should be able to apply the damaging flames to any unit, without doing the initial "impact" damage to anything but buildings, right?
EffectsRequireVerses=no
CellSpread=.5
PercentAtMax=.5
CellSpread.MaxAffect=1
AttachEffect.Animation=INITFIRE; modified to do damage
AttachEffect.Duration=120
AttachEffect.Cumulative=yes
AttachEffect.DiscardOnEntry=yes
Verses=0%,0%,0%,0%,0%,0%,100%,100%,100%,0%,0%
Versus.none.ForceFire=yes; infantry should take no damage from the initial attack but still be set on fire...
Versus.flak.ForceFire=yes
Versus.plate.ForceFire=yes
Versus.light.ForceFire=yes; ...same with vehicles...
Versus.medium.ForceFire=yes
Versus.heavy.ForceFire=yes
Versus.special_1.ForceFire=yes
Versus.special_2.ForceFire=yes; ...and spawned rockets
The anim is attached to buildings and they usually take damage (Bio Reactors, Tank Bunkers and scenery props do. Conyards, Oil Derricks, and garrisonable civilian structures don't, as far as I've seen).
Infantry and vehicles, despite the Initiate being able to shoot at them, are unaffected; no animation plays, thus no damage is done. Last edited by gameaddict11707 on Sat Sep 01, 2018 8:42 pm; edited 1 time in total QUICK_EDIT
My assumption is that EffectsRequire* was intended for use with Sonar/DisableWeapons/Flash effects and does not affect IC/EMP/AE at all. The others never required the weapon to deal actual damage to apply in first place and in general work in different fashion.
EffectsRequireDamage works partially. Setting it to false / omitting it allows weapons with non-zero Damage and warhead Verses that cause the actual damage dealt against targets to be zero can apply warhead effects, but weapons with Damage=0 won't still be able to do so under any circumstances. This is not particularly problematic as to my knowledge there isn't any other impactful distinction between actual Damage=0 and damage being truncated to 0.
EffectsRequireVerses seems to not function at all, always behaving as if set to true. That said I am unsure if there is any sensible use-case for setting it to false in first place, and in case it is made to work having it default to true would be so much more intuitive, at least in my personal opinion.
CanBeDriven appears to work fine. I'll see if I can test Damage.Delay change and the minor additions later on. _________________ Last edited by Starkku on Sat Sep 01, 2018 3:31 pm; edited 1 time in total QUICK_EDIT
Damage.Delay works now, however something about it in this version seems to affect animations that don't have the tag at all.
For instance I have a 1 frame animation that triggers a weapon, however it no longer works in the latest version unless I explicitly set Damage.Delay=1. The animation does not have the Rate tag set.
Haven't yet seen it in action but EffectsRequireVerses defaulting to no sounds like a big change to me, since warheads are always set to 0% for armours you dont want affected. Can imagine it having unwanted affects on a lot of things, depending on what "effects" that tag exactly covers. QUICK_EDIT
In my test, vehicles took no damage but still had their weapons disabled for 10 seconds, other targets took damage and had weapons disabled. Setting either EffectsRequireVerses or Damage to YES made it so vehicle weapons weren't disabled on being hit with weapons using the warhead SAFlame.
Replacing DisableWeapons with Flash and Sonar (after making some units cloakable) worked exactly the same.
I agree with OmegaBolt that EffectsRequire* should default to YES, considering many other new tags have defaults that closely match the original game's settings. QUICK_EDIT
Nope, infantry cannot use the IsSimpleDeployer logic. Maybe in a future release.
The effects are indeed Sonar, Self Healing Combat Delay*, DisableWeapons, and Flash. Iron Curtain, EMP, and AttachEffects are applied manually, and they all use systems separate from normal damage handling.
The C&C games all exit early when the damage to be delivered is 0. The cells aren't checked for things that could be damaged then, thus no objects are made aware of damage being delivered at all. I could skip that check, but if, I would prefer it to be a new warhead tag**.
I found a problem with Anim Damage Delay (for Damage.Delay=0), which used a wrong comparison, and thus might fire a frame too late. I hope this fixes Omega Bolt's issue (though it's a shot in the dark).
I also fixed a bug with Scorch/SmallFire handling, which I introduced in the latest build. Will be fixed next time.
---
* This was more an oversight than a concious decision. This shouldn't be affected, and I plan to fix this.
** Only the warhead is known at this point, not the weapon. Using EffectsRequireDamage here would be weird, because that's unexpected. Also, CanC4=yes buildings might always get 1 damage then, as always. _________________ QUICK_EDIT
One more quick last testing-build-ish pre-RC unstable binary (18.248.910).
Minor additions
Changed the default of EffectsRequireVerses to yes
Fixed crash with Scorch=yes animations with SmallFire not set
Fixed something about Anim Damage that might interfered with delays
SelfHeal.CombatDelay is now always applied if positive damage has been dealt
Allow warheads dealing no damage
[Warhead]AllowZeroDamage= (boolean, defaults to false)
Whether damage of 0 hitpoints will still be passed on to all objects affected by a warhead. Otherwise, a damage of 0 will not be passed on.
This can be used to punctually disable an optimization in the game to still apply warhead effects without damage. _________________ QUICK_EDIT
RC time (18.250.1188). I'm still busy with the tedious task of writing the documentation; not sure when releasing a preliminary version would make sense.
Animation Damage using Weapons changes
No damage longer counts as being caused by the object the anim is attached to. This change was made to ensure that the object the animation is attached to can be damaged by the weapon, too. _________________ QUICK_EDIT
I used an animation which has a weapon that can apply an attach effect on own infantries.
And that AttachEffect's animation has a weapon with a warhead with infantry-making animation.
It works correctly in previous build but in this build spanwed infantries lost owner and became cilvian.
Directly infantry-making warhead animation works fine. QUICK_EDIT
Alas, it wasn't correct. The animation attached to an object is owned by that object, and previously the damage was done "in the name of" that unit. For AEs where the animation is attached to the same owner that created the animation, that might be desirable, but if you attach an AE to anything (like a virus cloud or something), and the anim kills units nearby, then you wouldn't want the infected unit to get the kills awarded, but the one who attached the AE.
So, for now, this isn't supported. Normal warhead damage was expanded to do the same silly thing, but it was too late to fix that and maybe break a lot of existing codes. For the new code however, the next Ares version after this one could extend the behavior, but I don't want to release something I'm sure I'll have to break shortly after releasing anyhow. This is the reason why I changed this. _________________ QUICK_EDIT
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum