Posted: Fri Jul 14, 2017 1:06 pm Post subject:
Grinding=yes bugs InfantryAbsorb,UnitAbsorb
Subject description: Cannot create VehicleType only grinders.
Although I used ARES 0.D, I'm unsure this problem is related to it, but I could use enlightenment on the subject.
I've been implementing two new buildings:
-The Original Soviet Cloning Vats that grind InfantryTypes only (Red Alert 2)
-A War Factory that grinds VehicleTypes only.
The implementation of the buildings themselves went quite fine, and in fact, the Soviet Cloning Vat is working as intended, but the problem comes with the Grinding War Factory. Even with the proper flags set, it still grinds both InfantryTypes AND VehicleTypes.
As the experienced Red Alert 2/Yuri's Revenge/ARES modder knows, BuildingTypes got two new additional flags in Yuri's Revenge.
InfantryAbsorb and UnitAbsorb, both default to no.
InfantryAbsorb determines whether or not InfantryTypes can enter the BuildingType to trigger an auxilary function and UnitAbsorb does the same but with VehicleTypes. These two are used on Yuri's Bio Reactor to prevent vehicles from entering it and providing additional power. I've conducted a little research to see what was wrong.
The three flags in question that were manipulated on the two buildings I implemented with the Bio Reactor were the following:
Code:
Grinding=
UnitAbsorb=
InfantryAbsorb=
The results gave birth to the following graph:
To summarize the situation:
-UnitAbsorb, InfantryAbsorb work as intended with BuildingTypes having Grinding=no or undefined. The Bio Reactor works with all four cases.
-BuildingTypes with Grinding=yes can either accept InfantryTypes AND VehicleTypes or only accept InfantryTypes. They cannot only accept VehicleTypes (my problem here) or not accept anything.
I need to confirm whether or not this is the case with other players. If so, does anyone know an alternate way to implement this? QUICK_EDIT
I highly doubt you can include all the vehicles in that array though as I know there's a limit to amount of characters in lists. _________________ "Don't beg for things; Do it yourself or you'll never get anything." Last edited by 4StarGeneral on Fri Jul 14, 2017 6:37 pm; edited 1 time in total QUICK_EDIT
Technically InfantryAbsorb and UnitAbsorb don't actually work with Grinder at all. UnitAbsorb's cursor just overrides the Grinder one, same does not apply to InfantryAbsorb though. Or something like that, anyway. Either way vehicle-only Grinders are not doable at the moment. _________________ QUICK_EDIT
Technically InfantryAbsorb and UnitAbsorb don't actually work with Grinder at all. UnitAbsorb's cursor just overrides the Grinder one, same does not apply to InfantryAbsorb though.
So, the Cloning Vats with Grinding=yes, InfantryAbsorb=yes and UnitAbsorb=no; accepting only Infantry is the result of unintended behavior? QUICK_EDIT
Before anyone reads this on:
I'm not demanding this to be made into an actual feature for ARES. This is just discussion. I'm not unreasonable and I know AlexB and the rest of the ARES staff are already working their rears off to give us an amazing Red Alert 2 modding experience. I also know that some requests aren't that easy or even possible to implement, so I won't get salty over I will probably blueprint it later in the hopes that it gets acknowledge, but I'd like to get feedback, opinions and ideas from the ARES community.
Though I'm not entirely sure this is the right place to post this kind of thing.
So, I've been spending the last night thinking of useful tags that could be changed/added for a completely reworked Grinder Logic. I've also had a few friends throw in a few suggestions of theirs and did a compilation of the final result. I get something like this.
Code:
[BuildingType]?Grinding.EnterSound= (sound)
The sound that is played when a unit is ground. Requires a valid soundmd.ini entry. Defaults to EnterGrinderSound.
[BuildingType]?Grinding.DeathSound= (boolean)
If set to no, any ground unit's DieSound= will not play. Defaults to yes.
[BuildingType]?Grinding.MindControlledOnly= (boolean)
If set to yes, only mind control bound units are allowed to be sent into the grinder. This does not apply to permanently mind-controlled units,
only units that are bound to a controller. Defaults to no.
[BuildingType]?Grinding.AllowRefunds= (boolean)
If set to no, units will simply be destroyed upon entry with no refunds. Otherwise, refund logic applies. Defaults to yes.
[BuildingType]?Grinding.BuildingHealthDependance= (boolean)
If set to yes, the refunded amount will be multiplied by the health percentage of the grinder building. Defaults to no.
[BuildingType]?Grinding.UnitHealthDependance= (boolean)
If set to yes, the refunded amount will be multiplied by the health percentage of the unit sent. Defaults to no.
[BuildingType]?Grinding.RookieMultiplier= (float)
Defines how much of the money is refunded for a rookie version of a unit. Defaults to 1.0
[BuildingType]?Grinding.VeteranMultiplier= (float)
Defines how much of the money is refunded for a veteran version of a
unit. Defaults to 1.0
[BuildingType]?Grinding.EliteMultiplier= (float)
Defines how much of the money is refunded for an elite version of a unit. Defaults to 1.0
[BuildingType]?Grinding.RefundMultiplier= (float)
How efficent is the grinder at refunding the unit. If Soylent is set to a non-zero value on the unit, the amount refunded is simply
Grinding.RefundMultiplier x Soylent. Otherwise, it is the amount provided by the game's refund system multiplied by Grinding.RefundMultiplier.
Defaults to 1.0
[VehicleType]?Grinding.ProcessOre= (boolean)
If set to no, the ore contained within a harvester (miner) will not be processed and lost in the process.
Otherwise the value of that ore is processed with all necessary income bonuses.
Defaults to yes.
[VehicleType]?Grinding.RefundPassengers= (boolean)
If set to yes, the vehicle will be refunded along with its passengers. Defaults to no.
[BuildingType]?Grinding.AllowAllies= (boolean)
If set to yes, allies will be able to send their units to the grinder. Defaults to no.
[BuildingType]?Grinding.AlliesRefundRate= (float)
Determines how much of the gridning value is refunded to the allies. Defaults to 100%.
[BuildingType]?Grinding.AlliesShareRefund= (boolean)
If set to yes, 100 - AlliesRefundRate % is given to the owner of the grinder. If set to no, that amount will simply be lost. Defaults to no.
[BuildingType]?Grinding.AlliesReverseEngineer= (boolean)
If set to yes and if this building has ReverseEngineersVictims=yes, the ally will gain any tech they reverse engineer from the grinder.
Defaults to no.
[BuildingType]?Grinding.AlliesShareReverseEngineer= (boolean)
If set to yes and if this building has ReverseEngineersVictims=yes, the owner of the grinder gains the new technology provided by the ally.
Defaults to no.
[InfantryTypeorVehicleType]?Grinding.CanBeGround= (boolean)
IF set to no, this unit cannot be sent to a grinder. If the unit is in a transport, it is ejected from the grinder. Defaults to yes.
As for the whole refund mechanic, I made yet another graph, but again, I'm not implying it's easy to implement or even doable, but have a look:
With that down, I'd like to hear people's voices about all of this. Which flags should have their implementation prioritized? Which ones should be rethought, which ones should be ignored? Do some sound stupid? Any type of personal input and opinion is welcome. 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
Grinding=yes bugs InfantryAbsorb,UnitAbsorb
