The gattling "workaround" doesn't allow an actual continous chargeanim, it is also pretty random and doesn't work as intended in many regards such as resetting the charge when you change targets.
Gattling logic is also pretty complex, not perfeclty documented and as such it demands a big chunk of time and testing for such a simple feature.
It's not really making a new logic just enabling the already existing one for buildings into it's use on units. _________________
It's not really making a new logic just enabling the already existing one for buildings into it's use on units.
In many cases it is not as simple as you think it is not to mention buildings work with shp's while vehicles use voxels normally and IsChargeTurret= with voxels do not really work outside of that logic. I know this example is not WW's RA2 but in OpenRA you can not simply use defence Tesla Coil's AttackTesla logic on vehicles without getting problems even tho one would think it would work perfectly fine. You are not alone in wanting building charge logic on vehicles and put voxels like this to good use https://ppmforums.com/viewtopic.php?t=22755 or just have a sound effect for charging.
So yeah summary: Many times things like this is harder than you make it out to be.
PS: Prism Forwarding logic for vehicles is in a even worse situation, people including me want it but it is much harder than it looks (for people that just throws suggestions/ideas out in threads like this without thinking about the difficulty of it) to implent/code. From chat with AlexB:
<AlexB> djohe: the logic would need to be reimplemented completely
<AlexB> plus the new special cases when units move out of range QUICK_EDIT
I know prism forwarding isn't simple at all. I said that was a kind of random idea, though it would certainly be neat (tesla/prism/laser chains, etc.)
So, let's not comnfuse things. Prism forwarding may be hard, but charging logic isn't that difficult.
But on the charge logic, it is not necessary the first implementation needs to include the voxel aspect. You could use a SHP chargeanim that works just as a muzzle anim.
Though, you are right in that making it so we can use the charging turret voxels correctly would be cool. Gattling workaround doesn't allow that that I know of.
Basically, the only "rewriting" for a basic implementation would be to make the chargeanim behave as a muzzle anim (IE move with the unit, respect FLH and have directionality) _________________
A pre-firing muzzle anim can again easily be done with gattling logic too. Your complaints that it's to hard & takes to much time seem really lazy...
*in grumpy old man voice* Back in my day when there was no Npatch or Ares we would spend days, weeks or even months slowly working though trial & error seeing what different logics & tags could be combined to create new effects. Now days too many people just cant be bothered to try stuff out for themselves & just ask Alex to add it to Ares >.> _________________
Basically, the only "rewriting" for a basic implementation would be to make the chargeanim behave as a muzzle anim (IE move with the unit, respect FLH and have directionality)
Mig Eater wrote:
A pre-firing muzzle anim can again easily be done with gattling logic too. Your complaints that it's to hard & takes to much time seem really lazy...
I fully agree with that this sounds like a perfect case of just using IsGattling=yes logic for this even tho I have not even tried it myself as from what I know IsGattling logic can do everthing you just said (directional muzzle anim, respect FLH, move with unit)
Also IsGattling logic also seems to have TurretCount but from what I can tell it has no effect if set above 1 sadly (will crash game at 0)(tested by copying prism tank from ra2.mix and renaming from sref to ytnk for body and turrets), it would be nice if that could be made functional for voxel turret changing for like Prism Tank / https://ppmforums.com/viewtopic.php?t=22755 with delayed charge instead of precharge. QUICK_EDIT
Migeater, as you should know I am not a "new" modder. I have used gattling logic many times, but the fact is, there is no way to making Gattling logic behave 100% predictability, since it is constantly retargeting.
In the Tesla Tower example, a single charge is for a single fire. Retargeting makes the pre-firing anim reset.
In Gattling logic, the gattling state is preserved even when changing targets.
There is also the issue of air weapon since last time I checked Gattling integrates all weapon systems. Rangefinding. Problems with virtual weapons, verses and warheads. Lag.
It simply isn't the same bahaviour, and there is no way to replicate the actual charge fire behaviour, period.
A workaround is not a solution, and is actually the "lazy" way of things. Why does OpenRA exist? Heck, why does Ares even exist? Just use workarounds for everything. There is surely some convoluted and half-functional way to do anything...
Stealth detection? LOL, just use constant area 1 damage to reveal enemies!
Create units superweapon? Easy, it's a paradrop with invisible plane and parachute.
Make structures superweapon? Why? They are paradropped invisible vehicles that auto-deploy with deploytofire and a virtual weapon!
And if you are the developer: Why even code infantry? They can be SHP vehicles with armor "none"! That "sequence" stuff sounds very hard! Use a workaround!
Or as I have seen some people say, why even mod. Just make custom maps so they can be played online with the base game. Since that's totally the same thing. _________________
Your argument is based on semantical personal opinion & nothing I say is going to change it, so I'm not going to bother dragging this on any further.
I do however find your insinuation that workarounds are "lazy" an insult to all the pioneers of this community, that as I mentioned before spent countless days trawling through the game's files in an effort to push the boundary of what is possible. If it wasn't for their work there would be no foundation of knowledge on which Ares or OpenRA could have be built upon. _________________
Workarounds are only lazy when you have the skill and know-how to do it yourself. Considering very few people qualify in that regard, workarounds are not "lazy" and are justifiable use of pulling as much out of the code as we can without being able to change it.
What is lazy is dumping everything onto one person to do it all for you and complaining about workarounds that could make that person's life easier, i.e. Ares. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
I suggest more than one type of money/resource. Like in TS you have tiberium and veinhole monster.
And flag for vehicles that requires operator. Without operator or other passangers this vehicle can be hijacked by enemy passangers. Like bunkers can be occupied by enemies. QUICK_EDIT
As AITargeting got expanded in 3.0, would be nice to add more targeting mode like AITargeting=Designator, that will fire at its one of its own designator. _________________
I suggest more than one type of money/resource. Like in TS you have tiberium and veinhole monster.
And flag for vehicles that requires operator. Without operator or other passangers this vehicle can be hijacked by enemy passangers. Like bunkers can be occupied by enemies.
I'd like an un-hardcoding of resources in general so you could be able to power as money and vice versa and make veinhole copies, but it's one of the most hardcoded things in the game, so it sounds pretty daunting to take on.
Operator logic exists though? _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
Currently vehicles using operator can only be "driven" by infantry from the same side/player as the vehicle. He wants the ability for other sides/enemies to be able to capture empty operator vehicles.
You could make the driver infantry also a hijacker, but you'd need to add VehicleThief.Allowed=no to every unit that doesn't require an operator to stop them being able to capture any unit though. _________________
Suggestion: Expand Spy Behavior, examples like:
-Making a specific infantry with 'Spy=yes' have different behaviors from another infantry with 'Spy=yes'. _________________ If you are a MetalHead (Heavy Metal Fan) and don't want to be a metalhead, Just remove your metal ball from your head. �:p .
QUICK_EDIT
Suggestion: Expand Spy Behavior, examples like:
-Making a specific infantry with 'Spy=yes' have different behaviors from another infantry with 'Spy=yes'.
Idea: allow Passengers to have a specific value that allows for infinite space within.
This idea is for Chronoprisons that "devour" everything.
Like the "World Gobbler". _________________ One and only developer of the Command & Conquer Dune "C&C D" mod.
m7 wrote:
I tend to release things I create so that assets are never lost to hard drive problems, accidental deletion, or me having to pretend to care about rippers taking things from my project when it is done.
Suggestion: Expand Spy Behavior, examples like:
-Making a specific infantry with 'Spy=yes' have different behaviors from another infantry with 'Spy=yes'.
What differences should there be?
Example: An Allied Spy who infiltrates, for example, a Superweapon, resets its timer, but, if a different infantry with 'Spy=yes' like, for example, a Soviet Spy or Thief, doesn't reset its timer, but instead, steals its 'Support Power', However, right now, you can only edit the Superweapon itself, so any Spy in the game will have the exact same behavior. _________________ If you are a MetalHead (Heavy Metal Fan) and don't want to be a metalhead, Just remove your metal ball from your head. �:p .
QUICK_EDIT
Ah, so basically, you want the Spy-Effects to be moddable on a per-spy basis rather than or in addition to per-building basis.
Sounds simple enough... _________________ One and only developer of the Command & Conquer Dune "C&C D" mod.
m7 wrote:
I tend to release things I create so that assets are never lost to hard drive problems, accidental deletion, or me having to pretend to care about rippers taking things from my project when it is done.
Oh, yes, something like that. _________________ If you are a MetalHead (Heavy Metal Fan) and don't want to be a metalhead, Just remove your metal ball from your head. �:p .
QUICK_EDIT
Please consider expand AttachEffect to include effects on:
Unit’s Reload rate (for ammo limited units, of course) , range of weapons, unit GuardRange, and unit sight.
And, it would be nice if AE can optionally affect units in an OpenTop transport. QUICK_EDIT
Another Suggestion: Silent Killer
A flag that is added to a Weapon, What it should do is when you kill an InfantryType with any object with Primary and/or Secondary, The killed InfantryType won't play the DieSound, here is an example:
Code:
[SNIPE]
Primary=AWP
[AWP]
InfantrySilentKiller=yes
_________________ If you are a MetalHead (Heavy Metal Fan) and don't want to be a metalhead, Just remove your metal ball from your head. �:p .
QUICK_EDIT
cxtian39: I'm planning to add a designator targeting mode for SWs, but it's surprisingly difficult to code efficiently.
Regarding custom custom spy effects: Also only doable in a very inefficient way, kinda like defining paradrops or ArmorTypes. Either each Infantry Type would need to load a new tag for every existing BuildingType like SpyEffect.GACNST.ResetRadar=yes or something similar, or each BuildingType would need to load all those tags for each InfantryType, like SpyEffect.NEWSPY.ResetRadar=yes. In any case, it would read thousands of tags, whose values need to be stored. And all this for a rather minor addition. _________________ QUICK_EDIT
I believe this change will cause the variables 'TimesExecuted', 'TimesCompleted', and 'unknown_10C', to be written to the debug.log file when the 'Type Data Dump' keyboard command is pressed. The reason I want to do this is because I'm working on a program to keep the updated trigger weight probabilities from one game to the next and I want more data about how they are calculated.
I'd also like Ares to automatically dump this data to debug.log at the end of each game. I can find the code to do that too if you want.
Let me know if this code causes problems or doesn't work how I think it does, I haven't been able to compile it and test it because I don't have the Aresbuilder program. QUICK_EDIT
A few things I'd like of which some have already been requested already:
1. A warhead tag that allows you to apply certain tags to a unit for a limited amount of time.
2. Critcal hit chance
3. Unit & Building shields
4. Tag to apply the warhead every single time a parasite does damage. (Allowing it to apply an attacheffect / EMP with every hit)
5. Warhead tag to make it able to remove attacheffects
6. Warhead tag to make it immune to attacheffect removers
7. Tag for warheads to have the radar jamming feature + Customizable durations
8. Tag to make a unit passive heal its passengers.
9. Excluding units from tech repair/heal
10. Drain weapons not be necessarily vertical QUICK_EDIT
A few things I'd like of which some have already been requested already:
1. A warhead tag that allows you to apply certain tags to a unit for a limited amount of time.
2. Critcal hit chance
3. Unit & Building shields
4. Tag to apply the warhead every single time a parasite does damage. (Allowing it to apply an attacheffect / EMP with every hit)
5. Warhead tag to make it able to remove attacheffects
6. Warhead tag to make it immune to attacheffect removers
7. Tag for warheads to have the radar jamming feature + Customizable durations
8. Tag to make a unit passive heal its passengers.
9. Excluding units from tech repair/heal
10. Drain weapons not be necessarily vertical
All of these requests aren't as bad as i think...
A warhead flag that allows a unit to cause another unit/structure to apply some certain flags, Not a bad idea, but, you mean something like this?
AttachFlag.Cond##= Where (##) are numbers between 0 to 32 (depends on how many boolean flags work in-game), Conditions that is added to the flag must be a flag that have boolean (yes or no/true or false).
So... Is it possible or not? _________________ If you are a MetalHead (Heavy Metal Fan) and don't want to be a metalhead, Just remove your metal ball from your head. �:p .
QUICK_EDIT
It would definitely be nice to have a timer attached to it so there's more room to play with it.
I saw that the Chinese version of Ares was able to make units immune to psionics for a limited amount of time, hence why I requested it here.
Should be doable. QUICK_EDIT
What about the multi-turret placement logic from C&C 3? Where Nod owns 3 laser turrets connected with the main hub/core, Is it possible? _________________ If you are a MetalHead (Heavy Metal Fan) and don't want to be a metalhead, Just remove your metal ball from your head. �:p .
QUICK_EDIT
You can already do this by making weapons slightly inaccurate with a low BallisticScatter along with a small CellSpread & PercentAtMax. Doing this will randomize the amount of damage a unit will take. Along with this you can also attach an airburst weapon with a 0 spread, which means that the extra airburst stage will only do damage if it's a direct hit.
I use this in my mod to make artillery "stun" units with an AttachEffect if they get a direct hit. _________________
Joined: 01 Feb 2007 Location: Las Vegas, Nevada, USA
Posted: Wed Dec 11, 2019 12:51 am Post subject:
Am I crazy by the way when I say an older version of Ares gave us the ability to make barracks also act as cloning vats? I could have sworn I got it working last time I was modding and was shocked it didn't work. I was surprised to learn there was a bug on it xD QUICK_EDIT
In addition to Mig's method, you could also use EMEffect=yes on the weapon's warhead and attach extra damage to particular animations listed on AnimList to give random bursts of additional damage. QUICK_EDIT
In addition to Mig's method, you could also use EMEffect=yes on the weapon's warhead and attach extra damage to particular animations listed on AnimList to give random bursts of additional damage.
That’s not the perfect approach as it potentially mess up experience. A better approach should be AE on a unit that launches a weapon with EMEffect, and those random animations give random AE that has different Firepower/ROF/Armor/etc multipliers. This approach gives experience. _________________
A few silly ideas in my mind, though I need to see if people are interested in turning them into blueprint requests.
As for some of the posts I've made before, I feel really bad posting in the first place as it makes me feel like I'm making unreasonable requests towards AlexB and the rest of the ARES contributors. If you find any of these interesting or would like to explain why/how are they feasible or not, it would be much appreciated. All feedback and criticism is welcome and appreciated.
1. Making the AlternateTheaterArt work on projectiles.
Implementing this on projectiles would allow for consistency for those deciding to keep the parasite behavior on attack dogs.
2. (Bug?) Units with a non-permanent mind control weapon, currently mind controlling a unit and acquire a permanent mind controlling weapon upon promotion cannot auto-acquire enemy units for mind-control. From my limited knowledge of how the game works, I'm going to assume the reason this happens is that a link between the controller and the controlled unit is still present, which prevents the unit from auto-acquiring a new target for mind-control. This makes the controller vulnerable unless manual targetting (player input) is involved. It could be fixed by either removing the link checking if the current mind-control weapon is permanent or turn the original mind controlled victim into a permanent mind-controlled victim.
3. (Bug) Weapons with IsRadEruption=yes are still green and do not follow the new Beam.Color= tag.
4. Navy SEALS and Tanya have Cheering animations when swimming, but no WetCheer= flags exist. Extremely minor and unimportant.
5. Tech Hospitals provide automatic healing for InfantryTypes through the InfantryGainSelfHeal, SelfHealInfantryFrames, SelfHealInfantryAmount tags. Tech Machine Shops provide automatic repairs (healing) for UnitTypes through the use of UnitsGainSelfHeal, SelfHealUnitFrames, SelfHealUnitAmount tags. Why not have some of these for BuildingTypes through tags such as BuildingGainSelfHeal, SelfHealBuildingFrames, SelfHealBuildingAmount? (Unsure if UnitsGainSelfHeal affects AircraftTypes)
6. Optional FireUp2, WetAttack2 for infantry units that use secondary weapons that default to FireUp and WetAttack respectively if not defined.
7. PenetratesBunker works one of two ways. If set to yes, then the weapon on which this flag is on will only affect the vehicle inside of the Tank Bunker. Otherwise, it will damage the building first. Two additional flags could allow weapons to damage both.
Code:
[WeaponType]?PenetratesBunker.UnitDamage= (double - percentage)
The percentage of the damage dealt to the vehicle inside of the tank bunker. Defaults to 100%, requires vehicle inside of the tank bunker.
[WeaponType]?PenetratesBunker.BunkerDamage= (double - percentage)
The percentage of the damage dealt to the vehicle inside of the tank bunker. Defaults to 0%, 100% if no vehicle is inside the tank bunker.
Tank Bunker here refers to a BuildingType with Bunker=yes
8. More customizable Permanent Mind Control on weapons with permanent mind control, more specifically, adding some of the tags from the Type=PsychicDominator SuperWeapon.
Code:
[Warhead]?MindControl.PermaControlAnim= (Animation)
The Animation displayed above units being mind-controlled by the Dominator permanently. Defaults to [CombatDamage]?PermaControlledAnimationType.
[Warhead]?MindControl.PermaCaptureMindControlled= (boolean)
Defines whether this warhead can capture units that are mind-controlled already. Otherwise already mind-controlled units are ignored. Defaults to yes.
[Warhead]?MindControl.CapturePermaMindControlled= (boolean)
Defines whether this warhead can capture units that are permanently mind-controlled already. Otherwise already permanently mind-controlled units are ignored. Defaults to yes.
[Warhead]?MindControl.CaptureImmuneToPsionics= (boolean)
Defines whether this warhead can capture units that usually aren’t mind-controllable. Setting this to yes ignores the ImmuneToPsionics tag on its victims. Defaults to no.
Again, these are merely suggestions and ideas that I'm putting out for the community in the hope of getting feedback so I can muster up the courage to blueprint them. Last edited by EliteGoatBoy on Tue Dec 24, 2019 5:19 am; edited 1 time in total QUICK_EDIT
1. Making the NewTheater= tag work on InfantryType and Projectile art entries. AlternateArcticArt= although working is limited to the SNOW theater.
Prerequisite.RequiredTheaters= can be used as pseudo-workaround, but as stated in the ARES documentation, it becomes a bit of a hassle for the AI.
Rather than making it work as it does with building art:
Code:
[GACNST] -> GTCNST for TEMPERATE \ GACNST for ARCTIC \ GUCNST for URBAN \ ... \ GGCNST for default or alternate art not found
The optimal way would be one that combines both AlternateArcticArt and NewTheater methods:
Code:
[SEAL] -> SEALT for Temperate \ SEALA for Arctic \ SEALU for URBAN \ ... \ SEAL for default or alternate art not found
Implementing this on projectiles would allow for consistency for those keeping the parasite behavior on attack dogs.
AlternateTheaterArt=yes is a thing. _________________ MIdAS - Turning wages into beer since 2002 QUICK_EDIT
I'm sure this has probably been asked already, but I've recently learned not to take guesses and ask instead if I can't test it myself.
Is there any chance Factory= can support at least a BuildingType and AircraftType OR InfantryType OR UnitType and actually get that combination to work properly?
I'm thinking something akin to the TT Defense Crawler that could pump out units (infantry and/or tanks) and can also build structures when deployed.
Or maybe a CY that can call for Aircraft like in TS (and in RA2 if you fix it properly) when all Helipads are full. Maybe have that CY reload aircraft too
It'd be nice if a CY could build infantry and tanks simultaneously and build buildings
(A work-around would be to have the "crawler" be a Helipad/Barracks/WF/whatever that gives SWs that spawn the buildings, but then you can spawn two non-defense structures, say both a PP and a Ref, at the same time.
Same if you do it the other way around: a CY with unit-spawning SWs allows "pumping out" a Tank and Miner or a Trooper and Engi simultaneously) QUICK_EDIT
I'm thinking about how to make a "Firebase" in the spirit of the Zero Hour one. So I know that garrisoned structures cannot have a turret or a weapon, so I'm wondering what my alternatives are.
1) I make the turret a single shp with the cannon in the center and four infantry at the corners. All five rotate in place and face 32 directions. So its technically one turret, but it looks like one cannon and 4 infantry. I then make the cannon the primary weapon with a minimum firing distance and then have the infantry be the secondary weapon with a range up to the minimum firing distance. Its a simple solution that doesn't require any additional logic, but it can't use both weapons at once, and it can only target one unit at a time.
2) Ares adds logic that a unit/structure can fire both its primary and secondary at the same time? And can target different things? Might work best with an omnidirectional type weapon and one tied to a turret. So picture a boat with a tesla coil at one end and a sentry gun on the other. Primary is tied to the turret and secondary is not. Or the M3 Lee from WW2 (small cannon in turret and large cannon in chassis). For my firebase, I could make it look like a garrisoned bunker with a turret on top. Cannon is tied to turret, but secondary is omnidirectional machine gun fire.
3) I'm not that familiar with TS but I remember the component towers. I'm don't exactly recall how adding the upgrade-turret worked, but if it's technically a different building, that could mean the base of the structure is garrison-able and the turret upgrade is a separate building with that can be the turret. Or that can be the ares logic - a building tag like BuiltOn=[BuildingType] where a structure can only be built on top of another structure? I'm probably reaching with that one.
I'm also pondering how to add mines like Chinese building upgrade in Generals.
Speaking of TS place-on-building upgrades. If a building has a passable bib (which I think ares got rid of so structures wouldn't take damage) could a mine upgrade work so that enemy units that drive/walk on the bib take damage? Although, if ore/tiberium is spawned via a weapon, I could probably clone&modify that type of logic so that a building can spawn mines around it. QUICK_EDIT
#3, AFAIK, building upgrades are just additional animations on existing structures that change existing flags like weapon, superweapon, etc. QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Thu Jan 23, 2020 7:48 pm Post subject:
List Appension
I just learned that using "+=" entries in headed lists appends the RHS entry to the list, even when no unique string is used in the LHS. I had intended to request such a feature as part of a more general appendability extension awhile ago, and I'm now recalling other details of that would-be request:
would it be possible to allow a prefix for IDs in flag lists that allow more than one entry, thus allowing these lists to be appended, rather than overwritten, in #included INIs? An example would be the "BaseUnit" list, which allows more than one entry, but re-stating this list in an #included INI will overwrite, rather than append the list. Introducing such a prefix, e.g. also "+", would mean that, say, stating "BaseUnit+=ZMCV" in an #included INI file would make the entire BaseUnit array "BaseUnit=AMCV,SMCV,PCV,ZMCV" (provided no other changes). As an extension to this, a removing prefix could also be considered, e.g. stating "BaseUnit-=PCV" in an INI loaded after rulesmd would remove the Yuri MCV from the BaseUnit array, even if it is included in rulesmd. In cases where there is no prefix, the intended reading would be that the following entry overwrites the previous stating of the same entry.
Customizable RadialFireSegments
Using the "RadialFireSegments" entry, we are capable of defining the angles at which a given unit will fire sequentially, with the first angle at which it will fire being 180° sinistral, and the last one being 180° dextral. Entry "OmniFire" causes a unit to fire even when not facing its target (and prevents it from making an effort to do so), but it will fire at its target.
Gen/ZH has "AcceptableAimDelta", which, to my understanding, allows the unit to fire if the target is within an circular sector, with the central angle determined by the entry. "OmniFire" can be modelled as a full-circle (360°) "AcceptableAimDelta". On the other hand, while "RadialFireSegments" permits a unit to fire within a circular section of 180°, it also does not alter the facing behaviour of the unit (it will still attempt to face its target), and the trajectory will be between the unit and a point on the limit of the circular section, with the angle depending on the current effective RadialFireSegment. "RadialFireSegments" also takes precedence over "OmniFire" insofar as projectile trajectory is concerned, but "OmniFire" takes precedence insofar as the angles at which the unit is permitted to fire is concerned.
I would like to propose several interpolations from these behaviours:
"AcceptableAimDelta" as a general case of "OmniFire"; at minimum, this flag would take a number that determines an angle mirrored at the unit's facing, determining the sinistral and dextral areas in which a target can be located without the unit requiring to turn in order to fire at it. An extended version could take a double-entry list, determining the sinistral and dextral angles separately. A luxury version of this feature would take the form of a list in which several angles can be defined (by defining the angle, from 0° (the unit's facing), at which a circular section begins in which firing is permitted, and another angle at which this circular section ends. If multiple angles could be listed, this would provide a highly customizable way of imitating "RadialFireSegments" without the feature of automatically cycling through the segments.
Likewise, the feature of the unit firing into pre-determined directions could be untied from the feature of the "RadialFireSegments". This potentially needs a complicated "translation" between the angle at which the unit finds its current target, and the angle at which it will fire in response. The highly specialized case of sequentially moving through all RadialFireSegments in response to firing at a target either straight ahead or anywhere around the unit (with OmniFire), which is the default behaviour of RadialFireSegments, could be made a special case.
The interpolation of the features "attempts to face the target" and "can fire at the target even when not facing it" can be discarded because of practical irrelevance; if the unit has to face the target before it can fire, stating that it can fire at the target from other angles is nonsensical.
Regarding the feature of defining numerous circular sections in which the unit will fire, it would even principally be possible to model the projectile feature "Inaccurate" by allowing a random, rather than sequential, distribution of fire between these segments.
Extension of RetargetAccuracy
Another approach of inaccuracy would be a generalization and further customizability of RetargetAccuracy; generalization in the sense that it could be extended to not only be applicable to projectiles created by Splits/AirburstWeapons, but to any projectile. "Inaccurate" and "RetargetAccuracy" could become a single "Inaccuracy" (or "Accuracy") tag, which determines whether a given projectile will target the same target as the object whose weapon created the projectile. The logic according to which this re-targeting occurs is incomprehensible to me, but there appears to be a range limit. A highly useful feature extension for "RetargetAccuracy" would be a way to define a distance from the target within which a projectile may pick a different target. Once this is implemented, functional difference to "Inaccurate" tag becomes minimal. However, "RetargetAccuracy" projectiles also prefer targeting objects over empty cells. This may in itself not be preferred, which is why it may be opportune to request that the targeting preferences of retargeting projectiles be made customizable. This can be done at different degrees of sophistication: a simple approach might allow the differentiation between objects and anything else, e.g. by introducing "RetargetAccuracy.Objects" as a sub-set of "RetargetAccuracy", which would allow defining a chance, within the chance of "RetargetAccuracy", that the projectile would target an object over an empty cell, with the projectile targeting an empty cell (or anything, including objects, at equal probability) if this chance does not kick in. This very low degree of sophistication, in combination with a RetargetAccuracy.Range would, on its own, make "Inaccurate" modellable in "RetargetAccuracy", except applying to homing projectiles spawned by Splits, rather than to ballistic projectiles fired by a unit's weapon. In short, features that would extend "RetargetAccuracy" would allow it to completely model, and subsume, the functionality of "Inaccurate". Additional degrees of sophistication could differentiate things like "RetargetAccuracy.ENEMY", "RetargetAccuracy.FRIEND", "RetargetAccuracy.WALL", "RetargetAccuracy.AIR" and whatnot.
Once allowed for weapon-fired projectiles and not simply Splits projectiles, there is an additional unification possible with "DistributedFire", which could simply be modelled by "RetargetAccuracy.UNIT=100%" and "RetargetRange" equal to the firing weapon's Range.
Unification of SubjectTo*, FireStorm, IronCurtain, Shield
I've finally bashed these stream-of-consciousness musings into a somewhat coherent form. I do not advise anyone to read them, except Alex, who might find some useful feature or other in here.
Spoiler (click here to read it):
There have been repeated requests for the introduction of a "shield" system in Ares. These requests, though made under this same term, have generally taken two forms: one for a "personal shield" that surrounds a single unit ("feature 1a" in the following), one for a shield that surrounds an area, either projected around an object, possibly mobile (I think that these requests are for something like the shield projected by the Force Shield Generator of War Front: Turning Point), or cast upon a location (all of these subsumed under "feature 1b" in the following). Shield requests usually went above and beyond the mere request of making an object more resistant to damage, which can be achieved with AE, also including the feature of being capable of taking only a limited amount of damage. As there is no value added to gameplay by a shield that in itself is essentially nothing but an extension to the Strength of the object (otherwise, this would be sufficiently served with AttachEffect.Armor), people who are not requesting the introduction of a Shield feature merely for the visual effect of displaying a separate, possibly heterochromatic, Strength bar, a shield animation and impact animations for absorbed damage will likely request that the Strength provided by the Shield behave in some way distinct from the Strength of the unit itself; perhaps it should regenerate, perhaps it should not be able (or be able) to be repaired or healed by means by which the unit itself can (or cannot) be repaired, perhaps it should have vulnerabilities distinct from those of the unit itself. Finally, “shield” may simply be a short-hand wording for Strength increases that are bestowed by certain external sources, which may or may not have the features described above; if there are no other features involved, such is equivalent to “Beyond-MaxHP Healing”, in which case it is now equivalent to the ArmorMult AttachEffect, and thus no concern anymore for requesting.
To be sure, what feature 1a and b do is simply re-route damage otherwise taken by the shielded object(s) to a different health pool. That said, there is a different idea of "shield" that is sometimes meant by requests, a shield which offers protection to things in a "bubble", with incoming projectiles detonating when entering the area (henceforth called "feature 2"), not only interacting with projectiles intended for the position at which it interacts with them, but it will also block projectiles that are headed somewhere else entirely and are simply cruising over the FireStorm Wall Segment on their way to their proper destination.
I would like to propose that these requested features, the FireStorm effect, currently restricted to be invoked by SWs to apply to soft-coded objects, and "SubjectTo*" are special cases of a generalized, parsimonious handling for these at first glance entirely distinct features that also offers some interesting interpolation. Finally, possibly IronCurtain/ForceShield and "PenetratesBunkers" can be tied up into this.
A non-area version of such a shield, that is, one that simply detonates projectiles entering the area of an object does not make sense for personal protection: after all, anything targeted at that object would detonate anyway, and if it didn't, that would be an advantage! However, in fact, a non-area version of the "bubble shield" already exists in vanilla TS and Ares, which is the "FireStorm" effect, and the advantage is clearly demonstrable: such a shield protects whatever is behind the shielded object (in the case of FireStorm, the shielded object itself does not even take damage, but it is possibly advantageous even if it does; to be sure "feature 2" here refers only to the feature of FireStorm to make projectiles detonate in a cell in which they otherwise would not). Customizability of feature 2 can be conceived as allowing to define an area (perhaps by radius, but perhaps also by more complex foundations) in which, when the effect is invoked upon the object, collision of projectiles is activated. Possibly, this could take the form:
Code:
[FireStormSpecial]
Name=FireStorm Defense
FireStorm.Radius=3 ; When this SW is active, the radius in which projectiles will be destroyed around buildings eligible for it.
or
Code:
[GAFSDS]
Name=FireStorm Defense Section
FireStorm.Radius=3 ; When FireStorm is active, the radius around this building in which incoming projectiles will be destroyed.
Possibly, a SW could even invoke such an effect on no object in particular, defining a cell/area on its own. The only "object-like" feature of this area would be that things could collide with it (possibly, this could be generalized by UnitDelivery and allowing ObjectTypes to exist in "incompleteness" to a larger degree than currently possible).
It is also possible to imagine feature 2 to be handled as an object in itself, existing at the same location as the objects upon which the effect is centered. Presumably, it should be traversible by your own units, but customizability of this feature follows almost on its own.
"SubjectTo*" and "IgnoresFirestorm" flags both handle whether a projectile will detonate when entering a cell occupied by an entity of the type "*" (walls, cliffs, buildings), or a cell in which FireStorm is active.
In this context, I would like to bring up a tag particular to Gen/ZH which points towards a more customizable implementation that might be usable here; this is "CollidesWith=". This tag allows to define per-projectile groups of other objects that it cannot pass through if it meets them on its way to its target (it has no effect on its collision with the target, which it always collides with), and the projectile would detonate when meeting any of the objects in the list. To my understanding, it is restricted to hard-coded categories that concern permutations of different attributes (for example, WALLS and ENEMIES). There is no advantage, of course, if this were implemented in Ares without making the list more extensive, or fine-grained, but it might serve as one possible implementation of a more customizable collision system. Alternatively, a generalization of terminology pre-existing in RA2, the SubjectTox tag, could take this function, although only "SubjectToWalls", "SubjectToCliffs", "SubjectToBuildings" have the function of outright collision, where "x" would be a variable to be replaced by terms. Such terms could be the IDs of ObjectTypes in themselves, but I would suggest to make it possible to create a "[CollisionSets]" list, which in themselves would take the form of equations, the LHS being a string and the RHS being a list of ObjectType IDs. Filling the LHS string into a "CollidesWith" (or "SubjectTo.x") would make the projectile in question collide with objects of these types. However, this is somewhat made redundant by the existence of the prototyping feature, so perhaps it can be foregone in favour of simply listing ObjectTypes, rather than pre-defining sets, as prototyping allows to import a list of types from another projectile without re-stating them anyway. As FireStorm not only destroys projectiles, but also units, consider expanding at least the collision with shields to units, just as "IgnoresFirestorm" is a valid TechnoType tag. If feature 2 shields exist as "incomplete objects", projectiles could be defined to collide with some of them, and not with others. Traversibility by units, likewise, could be generalized in this way: essentially, a "shield" as an object completely traversible, except to projectiles. Whatever features of traversibility already exist in Ares (such as "ImpassableRows" could be customized according to being impassable to what, or it could be envisioned as separate objects overlaying each other and sharing their stats, but not their passability - though at that point, what is an object?)
How should a situation be handled when there are several objects at the same position which are eligible for collision with a number of these? What occurs in one interaction may have influence on the course of other interactions. I am thinking in particular of the case of a unit and its shield existing on the same cell; naturally, projectiles should be collisive with both the shield and the unit itself, but with the latter only if there is no shield present. I propose that objects be given a "CollisionLevel" tag that instantiates the following functionality: if two objects exist on the same cell, they may only collide if there does not exist a collidable that can collide with one or the other and has a higher CollisionLevel.
This would mean that [Bullet] can only collide with [TypeA] if [TypeAShield] does not exist at the same position, because despite both being collidable with [Bullet], [TypeAShield] has a higher CollisionLevel.
It is possible to tie the tags that define interactions into the ObjectType rules sections themselves. While this would require the least change to code, it would allow for the possibility of sections definining contradictions:
Code:
[TypeA]
CollidesWith=TypeB
[TypeB]
CollidesWith=TypeC
One might say that this is of no relevance, that the list simply gets extended by each mention, even if the listings are not congruent. Another solution would be to define "collisions" independently, e.g.:
This could even be further generalized to allow more than two instances of a type being required to exist in a cell in order for the collision to occur, or even CollisionType to define the results (ordinary, to destroy the object, which, in the case of projectiles, cause the warhead to detonate, but possibly this could be overruled by a CollisionType statement).
The drawback to defining CollisionLevel within this list is that, again, conflicting statements can be encoded in this way if there are several collisions defined to have the same priority, leading to aequivocation. Of course, this is not a drawback incremental over the method of defining CollisionLevels within the ObjectType sections, since in those sections, too, collisions with aequivalent priorities can be defined.
Note that such CollidesWith does not have to be transitive, though it is necessarily symmetric; this is perhaps also not desireable. While it is certainly possible to model a projectile detonation by means of brt damage dealt to both involved objects, with only the projectile being vulnerable to that damage, thus avoiding the unfortunate implication of a perfectly symmetrical “detonate” type of collision, I think it is most auspicious towards the community to avoid, to the greatest degree that one is willing to invest time and effort, the narrowing of customizability.
("SubjectToElevation", of course, does something entirely different, and may be disregarded here.)
? All of these tags also involve alterations to AI, though these are customizable in the of "SubjectToBuildings" via "SolidLevel", and in the case of "SubjectToWalls" by whether the unit in question can destroy the intervening wall. It has been noted in this regard that "SolidLevel", the projectile tag, allows to control a unit's AI independently of whether it can actually destroy its obstacle, whereas there is no comparable tag for SubjectToWalls: the AI and targeting of a unit that is incapable of firing over a wall will decide to shoot anyway (destroying the wall) only if it can damage it, whereas it will be unable to target beyond a wall if it is unable to destroy the wall. Cliffs are never destructible, so there is no phenomenal difference between SubjectToCliffs=yes projectiles genereally not permitting weapons to be fired across cliffs, or whether a check, as in SubjectToWalls=yes, is included–either would return that firing across a cliff is unpermitted. In my estimation, it is possible to generalize SolidLevel (currently a projectile tag) and the purely Warhead-based consideration of whether to shoot at obstaclous walls, namely that SolidLevel could be generalized to not only work for SubjectToBuilding, but also for SubjectToWalls (and SubjectToCliffs, but, again, there would be no observable difference) in that it is a modifier to ratio of damage to obstacle strength that causes a unit to consider an obstacle as something to be avoided, or something to be destroyed. In particular, a unit that finds itself unable to destroy an obstacle can be considered as needing an infinite amount of hits in order to destroy that obstacle. In this case, for SubjectToWalls, the unit will abstain from firing upon the obstacle and will either move around it or, if such a path cannot be found, will be unable to fire or target behind the obstacle. If the unit finds itself capable of destroying the wall with less than infinite attacks, it will attempt to do so. I would propose for this consideration to be the default of SolidLevel, rather than the curret “0”. If this new default is adopted, it will allow SolidLevel tag to be generalized onto the behaviour against Wall obstacles without causing change, or else that the behaviour against walls be defaulted to work against buildings in the same way: if it can be destroyed, it will be considered destructible obstacle, unless SolidLevel dictates otherwise. Considering FireStorm and other collidables, we have a similar issue: there is no AI component in FireStorm that makes units defer from firing weapons to whose projectiles “IgnoresFirestorm” does not apply if there is FireStorm active in the line of fire, and prompts it to attempt to maneuver into a clear line of fire.
"SubjectToTrenches" has a functionality that already eerily similar to feature 1: it does not cause a projectile to detonate, but instead causes damage to be "passed on" to the occupants of a building, when it would ordinarily be dealt to the building, if the projectile is set to detonate on the building anyway by virtue of being targeted at its position.
Using feature 1a (a personalized shield), we can create all the features of Iron Curtain: it is an infinite-strength shield applied to just one object. There is no feature 2 (i.e. no collisiveness caused by Iron Curtain). We can consider that the shield invoked upon objects by a single instance of IronCurtain is the “same shield” for all of these objects, just as the FireStorm shield is the “same shield” over all objects over which it is invoked, or we can consider an instance of IronCurtain to invoke personal shields over a number of objects that just happen to be reduced by damage that is constant over all of them, and thus expire at the same time; there is no predictive difference between the two in this case. However, we run into issues of modeling the expiration of the timer in the facile way of using DoT to revoke it, as if the value that is reduced by damage and over time is truly infinite, then naturally, IronCurtain does not expire after any length of time, and non-parsimonious handling via a separate duration is needed.
A ghetto solution that does not depend on the existing timer settings might look to model IronCurtain as a shield with a very high, but not infinite strength; so high that any amount of damage that could reasonably or irreasonably be expected to be dealt to it during even up to the second-to-last tick of its existence would be insufficient to deplete it, with the exception of a certain damage-over-time that it is subject to and that reduces its massive health by the quotient of itself and the intended duration, in ticks, every tick. Since we already have existing timer settings for IronCurtain, such a truncation would of course be misplaced. What is really of interest here is the generalization of modeling the expiration of a timer and the taking of damage in such a way that one influences the other; this is pioneered in FireStorm, but perhaps considering both Timer and Strength to be just different iterations of a Strength values that could both pend upon the same Strength, as is the case for FireStorm, or could be separated into distinct values, is a valuable perspective for the customizability of shields. By extension, the general approach of allowing different Strength values (by way of saying, different values whose reaching of zero would cause expiration, or some other state transition) that interact with outside sources that alter them, rather than one with damage and one with a timer would perhaps be interesting for more than just shields; perhaps it is interesting to consider a unit that can be dealt five missile hits or 20 bullet hits before it is destroyed, but hitting it with the one does not reduce the number of times it has to be hit with the other, pathing players towards using particular means of damage (a similar effect could be achieved, I suppose, by cumulative damage reduction against certain kinds of damage by other kinds of damage). Conversely, using ArmorTypes on shields themselves, we can also make different damage types successive to each other: a shielded unit (or a shielded shield, or a shield-inside-a-shield-inside-a-shield-etc.) would be vulnerable to some types of damage, whereas the shield would be vulnerable to others. Using this approach, Iron Curtain could be a low-health shield with a DoT effect of a warhead that can damage it, whereas it would take no damage from any other source of damage. As a generalization of "SubjectToTrenches", a projectile tag would determine whether a given detonation would damage the shield at all, or bypass it to whatever it is shielding. This points us to another generalization, namely the difference between damage nullification and "damage pass"; this does not matter for vanilla RA2: since there is never one object in the special relation of "being shielded" by another object, brt damage that is not passed into net damage just becomes nullified and does nothing. But "SubjectToTrenches" reveals a different aspect that such "not-taken" damage could have; namely, the building doesn't take it, as if it was immune to damage, but something else takes it instead. Generalization of "Verses=" would be from the feature of nullifying a share of damage to a feature of passing a share of damage on to some other object. Consequently, "SubjectToTrenches" would allow the definition of a percentage of damage to be taken by the occupants of a building. Consequently, a projectile capable of dealing damage through shields could also define the share of damage that it dealt to the shield. Conversely, the percentage could be modified (only or additionally) by a value on the building or shield itself as well.
It is quite easy to represent the FireStorm in a model combining feature 1a and feature 2, that is, as having HP and causing a certain location to become "collisive", excepting one factor: it can be represented as a finite-strength shield that is under the effect of damage-over-time (each tick reducing its strength by its strength divided by the number of ticks it is intended to last), while also being able to take damage. The factor that we are not yet able to represent is that this shield is withdrawn from all objects it is on at the same time, irrespective of the object to which the damage had been dealt that it absorbed and that reduced its duration. It is illustrative in another regard: we think of a “shield” invoked upon objects to be roughly spherical or circular: objects in a circle or sphere share a single shield and consequently, shield protection is withdrawn from all of these at once. However, FireStorm is invoked over many objects simultaneously and the "FireStorm.Radius" feature suggested above simply defines, for lack of a good way of defining placement per rules coding, the area in which a collision mode is activated. Where such an area is located, and how many there are, on a map, is still up to the events happening in the game itself. To be sure, in order to model the FireStorm feature, the player is able to place many FireStorm.Radius=1 (i.e. "just on its own cell") sections, which each would be an "object" by virtue of being disjoined from the other areas. At this point, it becomes impossible to avoid dissolution of the idea of an "object": while we might be able to concede to having multiple impassable areas disjoined from each other be a single object (e.g. via making certain parts of the foundation impassable, and others passable), here, even the positioning of these entities is not pre-coded, but depends entirely on in-game events (unlike the case of the parts of a BuildingType's foundation), and, if it is possible to construct additional objects of the type while the FireStorm is active, different parts of the same object come into being at different times. And yet, all these objects should share a single health pool, in order to be revoked at the same time. A generalized feature that allows the sharing of HP between objects for this purpose would allow it to be implemented, and could possibly be extended to apply to objects which are not "incomplete", but ordinary, movable, buildable, objects. I have no idea how such a HP-sharing feature may be implemented, though. Perhaps a "damage sharing groups" list could be created. This is precisely what is implied by feature 1b between different instances of the "same" shield, and it is what is implied by the feature of allowing customizable damage sharing between shield and shielded object.
_________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
The Firestorm Charge logic isn't part of RA2 or Ares yet, right?
Might be a nice addition as well and could work well with CloakFull too. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Ares has made it so you can make a weapon use up multiple ammo pips (or even none) when fired, which can be used to recreate Firestorm's charge logic.
So you could make a stealth tank that has a primary weapon that doesn't use up any ammo & a secondary weapon that needs multiple ammo pips. Once fully charged you'd then have to chose between being cloaked or unleashing a powerfully blast etc.
Edit: You could also make the secondary an AOE attach effect that will cloak friendly units around the stealth tank when fired, so it could share it's cloaking ability for a short time at the expense of revealing itself. _________________
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