Attribute modifiers on weapons.

Bug #894934 reported by Nighthawk
30
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Ares
Invalid
Wishlist
Unassigned

Bug Description

Basically, what this would be is some kind of modifier to, for example armour or speed etc. that can be applied to a weapon. I.e. weapon X fires, decreases ROF of enemy unit; friendly unit uses area-effect weapon Y, increases armour of all nearby friendly units. Another way of putting this would be the ability to apply the veteran modifiers in [General] to a weapon or warhead, and that any unit hit by this weapon / warhead will have these modifiers applied.

So, tag-wise, something on the weapon (or warhead) like this:
[Weapon]
ArmorModifier=0.9 (multiplier to armour)
SpeedModifier=0.75 (multiplier to speed)
ROFModifier=1.5 (multiplier to rate of fire)
SightModifier=0.8 (multiplier to unit's sight)
DamageModifier=1.0 (multiplier to target's weapon damage)
SelfImmune=yes (in the case of area-effect weapons, does this affect the firing unit)

The modifiers should be 1.0 by default (i.e. nothing modified).
This could be used to create some interesting effects with units, for example a rudimentary recreation of the BfME Leadership logic, which increases the attributes of nearby friendlies.

Revision history for this message
Nighthawk (nighthawk) wrote :

Now that I think on it, it'd be better on a warhead, then you could apply it to, for example, custom radiation types (if they return), or animation warheads.

Revision history for this message
pd (pdmail) wrote :

This would be very good for real hero units indeed.
You forgot a modifier radius as well as something indicating that radius (the radial indicator or a light source would probably be the best thing here).

Revision history for this message
Nighthawk (nighthawk) wrote :

Well, for the modifier radius, I was thinking of just using the CellSpread of the warhead. I'm not sure whether PercentAtMax should be factored in though. Sorry for the delay in replying.

Of course, if you've already coded in a seperate radius tag, let it stay. I just thought linking it to CellSpread might result in less coding for you. Then again, I know nothing about any of that anyway, so for all I know, it could be more.

Revision history for this message
Bug Importer (bug-importer) wrote :

I don't know if SightModifier would be a good idea, because a sight >10 gives you a crash

Revision history for this message
Black Temple Gaurdian (black-temple-gaurdian) wrote :

Doesn't me, I had a chitzkoi with sight=12

Revision history for this message
Millennium (kotaka) wrote :

Well, Sight= doesn't give you a crash, as far as I know, but any Sight multiplier does... But that's something RP2 is there to fix, right?

Regarding "SelfImmune"... isn't there a CanDamageSelf= function, which can be set to "yes" (and is no on all stuff by default - try to fire a nuke at your nuke silo in original RA2, for example...)?

Revision history for this message
Bug Importer (bug-importer) wrote :

If this is to affect a player's own units like an Aura, there should be a tag like: "WarheadCanAffectEnemies=no", unless you want the bad guys enjoy the same buff as your own guys...

Revision history for this message
Millennium (kotaka) wrote :

I agree... btw, I meant "SightMultiplier above 10 gives you bad crash" in my post above, not "any SightMultiplier gives you bad crash", just in case someone got me wrong...

Revision history for this message
Bug Importer (bug-importer) wrote :

Does anyone know if 5 times SightMultiplier 2 gives you a crash?

Revision history for this message
Millennium (kotaka) wrote :

Or 2x SightMultiplier 5? Sorry, no idea... But worth testing, though.

Revision history for this message
Millennium (kotaka) wrote :

Oh, and... if these modifiers are included, they should not add up, but rather override each other. For example:

You have a bike with Speed=10
Bike is hit by weapon with SpeedMod=.2
Bike now has Speed=2

Now, if you hit it with a weapon that has SpeedMod=1, this should not modify the current Speed (which is 2), but rather change the speed to 1x the original speed (which would be 10). This is important, because otherwise, you could never restore a unit with a mobility kill (or armor kill, blindness, whatever) to its original state. I see that this override path is kinda buggy, therefore, alternatively, you could create a special tag, or maybe special number to put into the XXXXModifier= tag, to indicate that this warhead is a "restore" type, which removes all buffs and debuffs (useful for repair units).

Revision history for this message
Bug Importer (bug-importer) wrote :

or, alternatively, you could make the damage= value for the weapon this warhead is associated with be a timer that specifies how long the effect lasts on the unit. For infinite you could specify damage=-1 or something.

And we should hash out an effective system for telling if the warhead is a buff for friendlies versus a penalty for enemies.

Revision history for this message
Nighthawk (nighthawk) wrote :

The only thing is that that would then prevent modders from creating an attribute modifier weapon that can do damage.

Revision history for this message
Nighthawk (nighthawk) wrote :

I'm not a fan of bumping things... but this thing did seem to disappear under the rug a while ago... I wonder if it's possible to draw some attention back to it again.

Revision history for this message
WoRmINaToR (worminator) wrote :

there is a related issue (basically asking the same thing) and for that issue, the target version is 0.3, which is quite a ways off. We don't have to hash out everything about this yet, and I think what has been discussed is quite enough to know what is needed for implementation when the time comes...

I'm just saying, that's probably why there hasn't been much more discussion on this.

Revision history for this message
MRMIdAS (mrmidas) wrote :

this could be used to re-create the limpet drone from TS, although why you'd want to is a different question altogether .

Revision history for this message
WoRmINaToR (worminator) wrote :

all this work to remake one of CNC's top ten most useless units?

Sounds good to me.

Revision history for this message
Nighthawk (nighthawk) wrote :

... you make it sound like recreating Limpet Drones is the only thing you could do with this logic, which is most certainly not the case.

Revision history for this message
Black Temple Gaurdian (black-temple-gaurdian) wrote :

How COULD you use this to recreate Limpet Drones is a better qustion. I mean, you fire at enemy, enemy slows down. Okay, how does that add to your revealed area?

Revision history for this message
Renegade (renegade) wrote :
Revision history for this message
Blade (nadia-xy) wrote :

Didn't the reveal follow the unit with a limpet mine?

Revision history for this message
Renegade (renegade) wrote :

Yes, and a parasite regularly fires, doesn't it?

Revision history for this message
regulus (regulus) wrote :

You know, the Yuri Chaos Drone does something similar to this effect. It increases the rate of fire (or damage) while units are under the influence of the drone's gas. Perhaps this holds something useful?

Revision history for this message
4StarGeneral (4stargeneral) wrote :

Pretty sure Chaos gas just makes everything Berserk, aka Cyborg berserk logic.

Apocalypse that gives everyone around it 1000% armor? Why not.

Revision history for this message
regulus (regulus) wrote :

According to several sources I looked at and my own gameplay experimentation, the berserk effect caused by the Chaos Drone causes:

Significant damage increase
Afflicted friendly units auto target friendly units before enemy units
Set duration of effects

So its only somewhat like the old cyborg logic.

Revision history for this message
falaka21 (falaka21) wrote :

This logic will be great for my dream about Real-freeze unit that only freezes
victim (stops it and makes it fully vulnerable but not damage only armor eater.)
But this effect has to have a "duration" (so victim that saved by teammate units
can continue as nothing happened to it.)

thanks to gatling logic that weapon damage can be customizable :) (stages for different damages by time )

(and colorable wave logic and colorable laser logic...Thanks to them,too)
(we can use both gatling and laser like logics for blue ice beam)

Anyway;slowing down victim first,and FINAL GATLING STAGE needs an E.M.P. duration to make the victim unit fully stopped.Then new "armor modifier" comes out! To make victim fully vulnerable like ice-shatter for instant death.But do not forget !This needs a "Duration" to make the victim "bringable to life again) (same value with E.M.P. duration will work great! And a color logic on "warheads" (I read it from here :) will be perfect for the "freeze animation"
(maybe light blue,dark blue or white..you know iron curtain is black and boris laser is red in default)

Yeah,isn't it a wonderful dream ? (I think I played too much with those "Cryocopters" in RA3 )

Revision history for this message
kakrain (kakrain) wrote :

how didnt i seen this before o.o implement this please! xP
this also make possible my dream of implementing a machinegun weapon that do supression fire, with speed modifier and ROF modifier, the machinegunners will do a great job as support units
also can you create a modifier, that modifies the time that a unit is proned?
TimeProned=float (time in deconds that a unit is proned def=same as usual)

Revision history for this message
falaka21 (falaka21) wrote :

I think, you understand me clearly.There is only one problem."Speed and Armor Modifier logics must have "Duration" for clear game and balance.Either once a unit is hit by the last part of the ice-beam (you know,gatling logic),it will stand there FOREVER for its own instant death to any enemy.(even though it is not underfire anymore!) "Duration" will fix this.

Maybe you are bored about that I write them here twice (again and again) please forgive me for it.But I only want to explain it open clearly.

1.Gatling ice-beam hits the enemy.Enemy will slowdown a little.
2.Gatling ice-beam goes on enemy 2nd stage.Enemy will slowdown a little more.
3.Gatling ice beam reaches its final stage to Freeze enemy.(E.M.P. will help us)
4.Final gatling stage weapon will make victim extremly vulnerable (Reverse Iron
curtain "Armor Modifier(Negative) " is on right now.)
5a.)When you hit victim now even one bullet ,it will explode into millions of pieces instantly.)
5b.)If victim's teammate units are successful to kill ice-beam unit,when the "Duration" goes away,the victim is free and NOT vulnerable(gains its original armor again.)

You have not to do anything about it.I am not giving orders.I only say my logical and reasonable ideas.("must be" and "have to be" words are about to clear all bugs about it in opinion.This doesn't include "Real Clever Developers"
I can't give orders to ANYONE, I know.Please forgive me if I have done a mistake about it. :(

Revision history for this message
Graion Dilach (graiondilach) wrote :

I have started doing this with the information based on http://bugs.renegadeprojects.com/view.php?id=405#c4700 and so far the only issue I ran into is that if I modify the crate bonus fields of the technos, crates'll be messed.

Why the crates are no-asm BTW, where should I search for the hook they got applied? Guess that's already in the code somewhere, it's just me who slipped it through.

And when I'll get there, I'll showcase a patch, too. The base is what I used for the animations and I planned it to be extendable with this, residual damage and maybe even flashing...

Revision history for this message
Cabal8616 (cabal8616) wrote :

A few things to add to this:

1: A tag for how long the effect lasts.
2: An animation tag for the affected units (Similar to EMP, iron curtain, etc
3: An animation tag for the unit that uses it (Something like the crate animations)
4: A tag that says whether or not the effect stacks or overrides similar effects.
5: Tags for minimum and maximum multiplier for stacked effects (so you can't debuff their speed until they're at 0)

All in all though, this'd be great to have.

Changed in ares:
assignee: nobody → Graion Dilach (graiondilach)
milestone: none → 0.3
status: Confirmed → In Progress
Revision history for this message
Renegade (renegade) wrote :

Closed in favor of blueprint.

Changed in ares:
assignee: Graion Dilach (graiondilach) → nobody
status: In Progress → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.