Money Conversion

[g.a]

The ability for certain warheads to convert a certain amount of the unit's cost to money when the victim unit dies.

Application 1: Harvest units, making a combat based faction

Application 2: Make some units cost money when killing an enemy (by setting the percentage to negative values)

##### ADDITIONAL INFORMATION #####
I think it could be done through:

[warhead]
moneyconversion.percentage= ;percentage of the victim's cost converted to money
moneyconversion.gradient= ;Boolean, if set to yes, money is gotten through doing damage, if no, all money is gotten on the victims death

[technotype]
Immunetomoneyconversion=

[General]
aircrafttypes.immunetomoneyconversion=
buildingtypes.immunetomoneyconversion=
unittypes.immunetomoneyconversion=
infantrytypes.immunetomoneyconversion=

[g.a (g.a)]

Forgot to mention: when an entire technotype is set to immune for money conversion, it does not affect when that technotype is attacked with a warhead that has moneyconversion.percentage to a negative value.

[Rogan (pdrogan)]

So you're thinking of a Grinder-type warhead?

There's a Soylent= tag for technotype that determine how much is converted into money either by selling or grinding.

So maybe having a MoneyConversion= boolean and Soylent= as the base value would be better. But that's just my own opinion.

[Graion Dilach (graiondilach)]

Duplicate of 203, IMO.

In NPatch the logic was called as bounty, search for this word.

[g.a (g.a)]

The bounty logic specified in 203 requires being on every unit, this is more general, allowing for greater ease. Though they are similar. Merging this with 203 would be best.

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: AlexB
Location: ft-bounty, r1045
Commit contains DLL: Yes
Revision comment:
Bounty logic implementation and first binary. Graion's and Joshy's code.
Related to issue #203, Related to issue #1523.

Documentation:
[TechnoType]->Bounty.Modifier (float, defaults to 0)
Multiplier of the enemy victim's Cost/Damage which should be granted as bounty.
[TechnoType]->Bounty.Message (bool, default's to no)
If set to yes, the granted money will be written out above the unit.
[TechnoType]->Bounty.FriendlyModifier (float, defaults to 0)
Multiplier of the friendly victim's Cost/Damage which should be taken as bounty.
[TechnoType]->Bounty.FriendlyMessage (bool, defaults to no)
If set to yes, the taken money will be written out above the unit.
[TechnoType]->Bounty.Pillager (bool, defaults to no)
If set to yes, the unit will grant money for the Damage it delivered and not when it destroys a unit.
[TechnoType]->ImmuneToBounty (bool, defaults to no)
If set to yes, the TechnoType can't grant money.
SVN: http://svn.renegadeprojects.com/Ares/1045

[DCoder DCoder (dcoder1337)]

Code review time!

DEFINE_HOOK(702E64,RecordTheKill_CalculateBountyXP,6)

FootClass *F = reinterpret_cast(Victim);You're not using any FootClass functionality, so you don't need this cast.This cast doesn't work like you expect - it simply tells the compiler "oh yeah, this is definitely a pointer to FootClass" and no checking is done. Which is not correct, when the victim is a building you're lying to the compiler and nothing good can come from that. If you really need a FootClass pointer, use auto F = generic_cast(victim) and check the result against NULL. See ModEnc.
Killer->Owner->UIName != pOwnerVictim->UIName && !pOwnerVictim->IsAlliedWith(Killer->Owner)The second check is sufficient to determine whether the objects are allied.The first check doesn't do what you think it does. In C/C++, this simply compares two pointers, not two strings, and the result is only true if the two pointers themselves are pointing to the same location, it doesn't check if their target entities are the same. To compare strings, you need strcmp or in this case wstrcmp.

Killer->Owner->UIName == pOwnerVictim->UIName || pOwnerVictim->IsAlliedWith(Killer->Owner)This is an inverse of the previous if. Instead of writing it out, make it into an else {} branch.

 Debug::Log("[Bounty] %s's %s destroyed an enemy %s, gained %d as Bounty.", Killer->Owner, Killer, Victim, victimActualCostInt);
This is going to crash. %s expects a pointer to string, what you're giving it is a pointer to an object. Use Debug::Log("[Bounty] %ls's %s destroyed an enemy %s, gained %d as Bounty.", Killer->Owner->UIName, pTypeKiller->ID, pTypeVictim->ID, victimActualCostInt); instead. (Note the %ls for the house name, it's a Unicode string instead of an ordinary one.)

DEFINE_HOOK(701DCC,BountyPillage,7)

GET(int, Damage, EBX); //Get actual damageUh no, that's an int*.

GET_STACK(TechnoClass*, Attacker, 0xC8);
TechnoTypeClass * pTypeAttacker = Attacker->GetTechnoType();Attacker can be NULL, in case of superweapons or other extraordinary cases.
Same notes about FootClass, if/else, %s and string comparison apply.
At the point this hook is defined, the value of int *Damage equals the literal Damage of the weapon as Verses and CellSpread have not been applied yet. If you changed the hook to DEFINE_HOOK(701DFF, TechnoClass_ReceiveDamage_BountyPillage, 7), its value would already have those and other damage scaling factors applied.

DEFINE_HOOK(5C9A44,loc_568A0A,6)
This hook doesn't look like it's meant to be in here at all.This is commented out, but DEFINE_HOOK is still caught by the .inj generator. Change it to something, anything else.I don't think ra2md.ini is the right place for this information. It should be easy to change when switching mods, this method isn't.

void TechnoTypeExt::ExtData::LoadFromINIFile(TechnoTypeClass *pThis, CCINIClass *pINI)
Doubles are being used more widely than floats, let's keep it consistent - change Bounty_Modifier and Bounty_FriendlyModifier to use doubles.
One of the good things about Valueable is that it has better methods for parsing INI values with less duplication.
this->Bounty_Message.Read(&exINI, section, "Bounty.Message");
this-...

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: AlexB
Location: ft-bounty, r1052
Commit contains DLL: Yes
Revision comment:
Refactored to work, also to follow DCoder's review. Added sanity checks for Armory Hospital and Slave Miner. Logics haven't changed yet. Graion's code.

Related to issue #203, related to issue #1523.
SVN: http://svn.renegadeprojects.com/Ares/1052

[Renegade (renegade)]

Closed in favor of blueprint.