Posted: Mon Mar 12, 2018 12:31 pm Post subject:
Custom Image Extention triggered by Weapon (SHRINKRAY)
II had an idea on how to create a shrink ray, but will need new tags.
Here, we create a tag that modifies infantry image temporarily, in which the player could make custom "SHRUNKEN" Shps for each infantry that may be tagged like TANY_S.shp (using similar extention logic to alternate arctic and wo). I.e (this is the image of the shrunken version to use when this infantry is targeted with shrinkray=yes)
additional tags could control the variables - shrinkray time modifier, range modifier, attack modifier, speed modifier etc. --- health etc.
Of course this logic may not only be used for shrinkray, but also freezers and expanders as the image extention could be customized into anything the modder desires. Last edited by AnimalMan on Tue Mar 13, 2018 6:02 pm; edited 2 times in total QUICK_EDIT
Unit-to-unit would solve the same issue if it retains health. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
Unit-to-unit would solve the same issue if it retains health.
this may disrupt AI usage of the units. new alternate image extention is the way. Trigger the image change to the custom extention temporarily on a target for a number of frames through a weapon.#
unit-to-unit may cause adverse effects, such as a deselection, unit lost, it may register as a death, additional units may be counted. all this would be harder to tune. With image extention we go with what we know works - like water image. I don't know though,
It is a potential mechanic never the less - with a nice variable of customization, and something that potentially everybody could use. QUICK_EDIT
Please make pokemon logic (turn units into another)
Technically we can already do this to infantry via AnimToInfantry on an elite weapon that autofires at itself. Sure it doesn't keep health, but consider it a tactical mechanic. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
Conversion is not meant to lose the original unit. If you deploy your mcv you know your mcv isn't counted as lost and you won't deselect it if it converts and triggers work fine. Unit-to-unit should preserve these properties. _________________
With unit-to-unit you will not be able to make the weapon seem to have a unique effect on each infantry/vehicle it is targeted, you will just have a mutator gun, which is already possible with infantry.
Again, with an image change and new custom extention ---- a single weapon can appear to have multiple effects on different types of unit.
Instead of having "ShrunkenPerson.shp" as a universal shrunken person - you would have an actual mini Tanya and an actual mini conscript produced from the same weapon + effected by modifier (shp/image could be zombie versions, frozen versions, shrunken versions, enlarged versions)
Unit to Unit - this gun makes that unit a rhino tank.. A somewhat less useful/impressive mechanism. QUICK_EDIT
Technically we can already do this to infantry via AnimToInfantry on an elite weapon that autofires at itself. Sure it doesn't keep health, but consider it a tactical mechanic. #Tongue
That really made my day.
Still that wont cut it some serious tag needs to be implemented.
I want more Veteran ranks and wana try all sorts of stuffs.
I'll bribe Alex if I have to Last edited by Bu7loos on Tue Mar 13, 2018 6:11 pm; edited 1 time in total QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Wed Mar 14, 2018 6:36 am Post subject:
Last I checked - sure, was years ago -, the renderer of this engine ain't remotely 3D and there are GODDAMNED amount of references between renderer and game logics so this likely does not worth the effort.
Feel free picking up OpenRA instead if you really need this - it can do this. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
The shrinkray is a mechanic that would - trigger a change - in its targets artwork. This "Change" would come in the form of an - image extention (wo, turr etc) - to its TARGETS artwork, for example TANYS1 XXXXS1, with S1 being the extention that is triggered by the shrinkray weapon.
This then allows the weapon to have a unique effect on its targets artwork. As with Ares WaterImage= that allows you to define a new image when the unit is passing over the water. Though in the case of the shrinkray - you are triggering a temporary image change that comes in the form of an extention.
The variables of this effect would be controlled by the warhead or weapon.
Modifers would include
ShrinkrayDuration= Number of frames the image extention is displayed
+
AttachEffect modifiers relating to attack, speed, strength etc.
The weapon merely tells the target unit to use a differnt art for a number of frames.
Attach effect or custom modifers flavour the effect.
Unit-to-Unit is a differnt logic that can be used to simulate unit upgrades. QUICK_EDIT
Because you need a lot of images for it to work. You need shrinken_Image, shrinken_WaterImage, shrinken_NoSpawnAlt, shrinken_UnloadingClass... and each of these may contain 1 or more turrets if this is an IFV or Prism Tank...
Every time you add a new image variations, it interacts with all of the previous ones and all of their codes need to be modified. _________________
Pardon any incoherencies in the ensuing brainstorming:
AnimalMan wrote:
Unit-to-Unit is a differnt logic that can be used to simulate unit upgrades.
Or it could be used to implement what you are requesting. I can see generalized Type?Type transition as having a far broader applicability than even a more generalized function of "inflicting alternate artwork", while covering all applications that may be covered by the latter; it also exports the matrix concatenation that cxtian39 has mentioned as plagueing the implementation of additional "AltImage" functions from code to INI, because it would be possible to define further transitions in the sections of a Type that another Type has transformed into, rather than handling all possible transitions with additional tags in a single section.
[TypeNoSpawnsW]
SpawnsType=TypeW
LandType=TypeNoSpawns ; needs special handling for one-in-a-hundred chance of Spawns regeneration and entering a land cell occuring at the same time?
Of course, if one wants, for whatever reason, to limit oneself to just image handling and does not want to introduce type transitions, then the exportation of these tags could also be achieved by reading just the Image from a section, as RA2/YR natively does in the case of the UnloadingClass tag.
What needs to be considered, though, is how conditions can be defined on part of the modder to trigger a transition (insert cross-reference here to that post in the main ARES suggestion thread that asked for an UnloadingClass for transports, to be triggered by units being deployed from it or entering it); it appears that without a more fundamental re-write, we might be limited to a hard-coded set of transition conditions per-unit (PromotedInto, DeploysInto, etc.), which could be linked up to certain warhead attributes, and perhaps a freely expandable range of transitions inflicted by warheads, which however would be identical for all units they affect (consider "Webby" of Firestorm, which would give all affected InfantryTypes the appearance of Light Infantry) - this is obviously not desireable for a thing like a shrink ray, which should produce smaller versions of affected units, and not turn all affected units into the same Type. Arguably, a workaround exists for this problem by granting such a weapon several warheads by means of AirburstWeapon, each warhead affecting a certain kind of enemy, but I suppose a cleaner implementation would be to introduce a "transition type" tag on warheads that allows customization of the transition to be inflicted by the warhead, rather than handling a limited range of transitions by means of booleans on warheads.
Ex.:
Code:
[Warhead]
TransitionType=OnFire
[Unit]
TransitionType.OnFire=UnitOnFire ; when hit by a warhead with TransitionType.OnFire
rather than
Code:
[Warhead]
Ignites=yes
[Unit]
IgnitedType=UnitOnFire ; when hit by a warhead with Ignites=yes
Of course, this only covers warhead-inflicted transitions; transitions caused by other game features would, I suppose, still be limited to a rather small range of hard-coded conditions, which may however allow for any desired application.
There is one last feature that is covered by the original request, but is not accounted for in Type?Type transitions, and that is temporal limitation. Arguably, workarounds can be conceived (InitialAmmo, AmmoType), but any workaround that I can think of would bite itself with other features. QUICK_EDIT
Honestly a "shrink ray" is asking too much of a SHP based engine, it could be done with voxels much like the HVA, but it would break the intricate voxels like ones with moving treads and really there would be no point if you couldn't do it to SHPs too. Stick with the debuff it would give, this engine can't do everything.
I do like the TransitionType feature though and could possibly function the same as unit-to-unit in veterancy by giving ElitePrimary a weapon that hits itself with the TransitionType.Veterancy= warhead. Even that is a workaround though, so I'm not sure it's the right way to go about it. _________________ "Don't beg for things; Do it yourself or you'll never get anything." 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