Ownership of MakeInfantry= animations should be controllable via INI

Bug #895030 reported by Demon Red Storm
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Ares
Fix Released
Wishlist
Unassigned

Bug Description

This is easy to grasp...simply allow an ini file tag(s) to determine the owner of a unit from animtoinfantry tags. Then, you could define whether it remains on the original side, switches to a random side(just an idea here), goes neutral, or switches to your side. This is helpful to create mutation logic and a sort of "golem" logic (makes sense if you know the legend).

##### ADDITIONAL INFORMATION #####
Example tag:
AllianceChange=*value*

*value* is a number with values being different cases.

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

AFAIK, the cases where an AnimToInfantry goes neutral is when the game cannot determine the player that caused the animation that created the infantry. So a side switch is really useless as long as yer don't do a new way of determining the house that caused the anim.

/Millennium out

Revision history for this message
Marshall (m-edward) wrote :

Every animation should have a default "who invoked me" lookup to determine the player to mutate to, but you'd then need several overrides.
Example:

artmd.ini:
[PHEONIX2ANIM]
MakeInfantry=2
MakeInfantryNeutral=yes ;overrides the RP2 default 'mutate-into' player (in this case the owner of whatever caused the animation)

rulesmd.ini:
[PHEONIX]
DeathAnim=PHEONIX2ANIM
DeathAnimInvokerIsKiller=yes ;overrides the RP2 default 'mutate-into' player (in this case, the default would be the original owner of the player)

In the above example,
1. When PHEONIX dies it becomes a neutral PHEONIX2
2. Remove MakeInfantryNeutral=yes (or set to no). Now when PHEONIX dies it becomes a PHEONIX2 owned by the killer of PHEONIX.
3. Remove DeathAnimInvokerIsKiller=yes (or set to no). Now when PHEONIX dies it becomes a PHEONIX2 owned by the original owner of PHEONIX.

You might need other flags in rulesmd.ini to cover other special cases, although I can't think of any right now.
I definitely don't see any point for a random player-assignment.

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

"Who invoked me" is pretty simple to add in. I'd propose MakeInfantryOwner=| instead of a boatload more yes/no flags though.

Revision history for this message
Marshall (m-edward) wrote :

Not sure how that would work, arbitrarily deciding the owner at design time makes no sense to me. You need a way to specify 'invoker' or 'neutral'.
The only special case I can think of is DeathAnim where you need to be able to specify 'original owner', 'neutral' or 'killer'

This could be simplified to just have an enumerated flag (like category/armor) on the animation:
MakeInfantryOwner=normal/neutral/inverse
For normal (default), whichever player invoked the anim
For InfDeaths, normal = killer, inverse = killed
For DeathAnims, normal = dying, inverse = killer

Revision history for this message
Demon Red Storm (demon-red-storm) wrote :

Here is my follow-up. First, I believe that it needs to work not only as a deathanim, but from ANY animation (I thought of using the anim superweapon to create a one powerful unit teleport-reinforcement SW). This is something to consider, especially if the anim-SW logic is kept.

Also, this opens the door for random player-assortment to be useful. Say a trigger on a map caused a certain unit(s) to be brought in using animation reinforcement every 20 minutes, but you want their faction to be random. That is the concept here. I guess it is possible to set up a mind control trigger for this, but I am not sure it would work as well as an absolute definition.

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

Animations can typically look up their invoker pretty easily. So a consensus is to add

[Animation]
MakeInfantryOwner=(normal|neutral|inverse|random)

? Random might warrant subsets, i.e. exclude civvie houses, include only civvie houses, include only human players, exclude human players, etc.

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

think HULK! the more demage he reisves, the angryer and BIGGER he gets! So, for each time he is "killed" he gets more power and less strengt?

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

Code related to this issue has just been checked in; DCoder wrote in revision 345:
Related to issue #188 - implemented
[Warhead]
InfDeathAnim=anim_name
, which should be triggered if the victim is NotHuman=no and less than 10 leptons above the ground.
Related to issue #356 - implemented AnimTypeExt and a stub hook. It doesn't do anything yet and doesn't parse anything from the INI yet...
Related to issue 188,356 .
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=345&sc=1

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

Code related to this issue has just been checked in; DCoder wrote in revision 355:
Related to issue #356 - extracted arguments of damage delivery, incl. sender object and house.
Related to issue 356 .
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=355&sc=1

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

Fixing name to make sense

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

Code related to this issue has just been checked in; Renegade wrote in revision 356:
Implemented MakeInfantryOwner=(invoker|killer|victim|neutral|random).
Only implemented on the custom InfDeath handler so far. (Issue #188, issue #356)
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=356&sc=1

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

Code related to this issue has just been checked in; DCoder wrote in revision 357:
Related to issue #356 - fixed Ren's code to compile.
Related to issue 356 .
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=357&sc=1

Revision history for this message
Professor_Tesla (professor-tesla) wrote :

Based on recent testing, I would say that all five cases seem to work as designed.
EDIT: The remap colour for the mutation animation is decided based on the house the infantry was owned by before it was mutated, rather than the house it will be owned by after mutation. This looks kind of weird.

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

Code related to this issue has just been checked in; DCoder wrote in revision 361:
Fixed issue #788 - remap should work correctly now.
Related to issue #787 - fixed a quirk in the verses parser, should work correctly now.
Fixed issue #781 - Yuri uses his proper GUI.
Fixed issue #356 - Was fixed in last revision actually, I just forgot.
(Changes were mostly in YR++, that's why the changeset is so small here.)
Related to issue 788 787 781 356 .
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=361&sc=1

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

Yeah, reopening since still needs to be done for non-infdeath anims.

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

Code related to this issue has just been checked in; DCoder wrote in revision 367:
Related to issue #356 - refactored MakeInfantryOwner to be an Animation property, not Warhead. Added hooks to fix up anims invoked via DeathAnims and map triggers (that last one needs some thinking).
Related to issue 356 .
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=367&sc=1

Revision history for this message
WoRmINaToR (worminator) wrote :

This isn't working for me... unless i'm doing something wrong.

I have Only one entry for AnimToInfantry, and that is JOSH (the monkey).I kept GENDEATH with MakeInfantry=0, but i also added MakeInfantry=0 to NUKEDIE. I HAVE NOT used the special InfDeathAnim= value, but rather I had a Desolator kill an infantry. Yes, it created a monkey, but rather than it being owned by the invoker (like the brute mutation does), it was just neutral. I added MakeInfantryOwner=invoker to NUKEDIE (you said you wired it to the animation in artmd.ini, right?), but nothing happened. Still neutral monkeys.

Revision history for this message
Professor_Tesla (professor-tesla) wrote :

Read the post above yours - this was implemented in revision 366/367, not revision 365, which is the latest released revision. In revision 365, it's still on the warhead.

Revision history for this message
WoRmINaToR (worminator) wrote :

I have tested this function on the animation and it now works as intended.

Revision history for this message
Professor_Tesla (professor-tesla) wrote :

No, it doesn't. It only works properly on InfDeathAnims.

Revision history for this message
WoRmINaToR (worminator) wrote :

were we going for something other than InfDeathAnims? AFAIK that's the whole point of MakeInfantry, to spawn infantry when you kill another infantry a certain way.

*EDIT*: Oh, I see... you want to be able to spawn infantry with, say an Anim superweapon? Thus creating the infantry out of thin air (technically at least; the anim to be played will show how they are created)?

Revision history for this message
Renegade (renegade) wrote :

Um...have you actually tested this on something else? According to the code, it should work on DeathAnims and map-created anims...

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

Created child issues for each type of animation, changing this issue to be parent bug of them all and re-targeting forward.

Revision history for this message
Professor_Tesla (professor-tesla) wrote :

I was using the wrong tag to test it for DeathAnims, which it works properly on.

Revision history for this message
Professor_Tesla (professor-tesla) wrote :

I can confirm that this works properly on InfDeathAnims and DeathAnims.

Revision history for this message
Renegade (renegade) wrote :

Setting this to resolved/fixed as the parsing mechanism is the same for all cases, thus this issue is, on principle, resolved - the ownership can be set via INI.

Not closing it yet since #bug:809 is still open and closing this issue would kind of hide it from view.

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

Closing these issues - implemented a fair while ago, tested during implementation. If any bugs do crop up, be sure to thank the lazy testers for doing their job so well.

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

Remote bug watches

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