Nope, at least not in exact form.Isn't it used for the pedia?
Nope, at least not in exact form.Isn't it used for the pedia?
So mistimed code then?Ok, I opened those events, and I see some issues with one of them, there is no check on whether there actually is an improvement on the plot or not before it adds the button for the improvement with the message about it being destroyed.
Variables can have different names and still be the same variable, 99% of all improvement buttons displayed in game are displayed from python with a "something.getButton() call on the improvement object.Nope, at least not in exact form.
Ok, new SVN rev on the way with fix to pink buttons for three different improvement, radio tower, mountain mine and fossil dig site.PINK btn, must be an event .. . ??
If CR 3 isn't available, CR 4 is naturally unavailable as well so why specify that it is unavailable? Is there a display bug somewhere that doesn't understand that promotionline assumable inherited unavailability still? You could never get CR4 if you can't get CR 3. Clearly.Not sure if new, but City Raider 3 is unavailable for Mounted (and Melee or something), yet CR4 is again available.
I found it when building a Chariot next to a Chariot Archer.
The latter could go all the way to Multi-Attacking of CR5, but the former stopped at CR2.
I say it's a bug.
By "available" I meant that Pedia lists CR4 with Mounted, but like you said, it's unattainable by those Mounted due to CR3 not listing it.If CR 3 isn't available, CR 4 is naturally unavailable as well so why specify that it is unavailable? Is there a display bug somewhere that doesn't understand that promotionline assumable inherited unavailability still? You could never get CR4 if you can't get CR 3. Clearly.
It's not a bug to deny CR3+ from mounted because much city fighting is done inside buildings, where a mounted unit is definitely not working as it is designed. Mounted too easily become able to abandon the use of foot units otherwise. They are intended to dominate in the open field usually and can take advantage of faster movement and mobility. If also allowed to be as capable of capturing cities, then early city capturing armies can too easily be made extremely fast, which is something we're trying to avoid until mechanical forces. That said, they should be used in city captures to wear down defenders with hit and run tactics or to run down highly weakened defending units.
IIRC, they still get access to Blitz through basic combat promos building up to the actual Blitz promo. I'm not 100% sure of that.
I have a hard time seeing a mere information display issue as a real bug worthy of addressing - at least with much priority. However, that said, I've known for a while that the way that the pedia displays what should be available to a unit has been ignoring the rules established by promotionlines and I honestly don't know where to fix that. I could probably chase it down but... again, less important than many more serious issues so I just haven't and don't plan to worry about it soon. Still, thanks for the reminder because it will probably be forgotten for a while again as it waits to be addressed.If you state that CR3 is correctly blocked off fom Mounted, then CR4 shouldn't list Mounted as an option, obviously.
Dude, sometimes the SIMPLEST solution is also the CORRECT one.I have a hard time seeing a mere information display issue as a real bug worthy of addressing - at least with much priority. However, that said, I've known for a while that the way that the pedia displays what should be available to a unit has been ignoring the rules established by promotionlines and I honestly don't know where to fix that. I could probably chase it down but... again, less important than many more serious issues so I just haven't and don't plan to worry about it soon. Still, thanks for the reminder because it will probably be forgotten for a while again as it waits to be addressed.
<PromotionInfo>
<Type>PROMOTION_CITY_RAIDER4</Type>
<Description>TXT_KEY_PROMOTION_CITYRAIDER4</Description>
<Sound>AS2D_IF_LEVELUP</Sound>
<PromotionPrereq>PROMOTION_CITY_RAIDER3</PromotionPrereq>
<PromotionLine>PROMOTIONLINE_CITYRAIDER</PromotionLine>
<iLinePriority>4</iLinePriority>
<iCityAttack>25</iCityAttack>
<UnitCombats>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_ARCHER</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_MELEE</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_MOUNTED</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
Now I wonder how broken are those promotions....Dude, sometimes the SIMPLEST solution is also the CORRECT one.
Just remove the one(s) that aren't supposed to get it - ya know, the OLD "manual" STYLE.Code:<PromotionInfo> <Type>PROMOTION_CITY_RAIDER4</Type> <Description>TXT_KEY_PROMOTION_CITYRAIDER4</Description> <Sound>AS2D_IF_LEVELUP</Sound> <PromotionPrereq>PROMOTION_CITY_RAIDER3</PromotionPrereq> <PromotionLine>PROMOTIONLINE_CITYRAIDER</PromotionLine> <iLinePriority>4</iLinePriority> <iCityAttack>25</iCityAttack> <UnitCombats> <UnitCombat> <UnitCombatType>UNITCOMBAT_ARCHER</UnitCombatType> <bUnitCombat>1</bUnitCombat> </UnitCombat> <UnitCombat> <UnitCombatType>UNITCOMBAT_MELEE</UnitCombatType> <bUnitCombat>1</bUnitCombat> </UnitCombat> <UnitCombat> <UnitCombatType>UNITCOMBAT_MOUNTED</UnitCombatType> <bUnitCombat>1</bUnitCombat>
LOL!
Though, yes, this does require a CHECK of all Promotions - but, hey, that's both quite simple and straightforward, and is needed in the end anyways.
<PromotionInfo>
<Type>PROMOTION_CITY_RAIDER2</Type>
<Description>TXT_KEY_PROMOTION_CITYRAIDER2</Description>
<Sound>AS2D_IF_LEVELUP</Sound>
<PromotionPrereq>PROMOTION_CITY_RAIDER1</PromotionPrereq>
<TechPrereq>TECH_SEDENTARY_LIFESTYLE</TechPrereq>
<PromotionLine>PROMOTIONLINE_CITYRAIDER</PromotionLine>
<iLinePriority>2</iLinePriority>
<iCityAttack>15</iCityAttack>
<UnitCombats>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_ARCHER</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_MELEE</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_MOUNTED</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_SIEGE</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_GUN</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_HITECH</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_WHEELED</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_TRACKED</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_DREADNOUGHT</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
</UnitCombats>
<Button>,Art/Interface/Buttons/Promotions/CityRaider2.dds,Art/Interface/Buttons/Promotions_Atlas.dds,6,2</Button>
<iCaptureProbabilityModifierChange>5</iCaptureProbabilityModifierChange>
</PromotionInfo>
<PromotionInfo>
<Type>PROMOTION_CITY_RAIDER3</Type>
<Description>TXT_KEY_PROMOTION_CITYRAIDER3</Description>
<Sound>AS2D_IF_LEVELUP</Sound>
<PromotionPrereq>PROMOTION_CITY_RAIDER2</PromotionPrereq>
<PromotionLine>PROMOTIONLINE_CITYRAIDER</PromotionLine>
<iLinePriority>3</iLinePriority>
<iCityAttack>20</iCityAttack>
<UnitCombatMods>
<UnitCombatMod>
<UnitCombatType>UNITCOMBAT_GUN</UnitCombatType>
<iUnitCombatMod>10</iUnitCombatMod>
</UnitCombatMod>
</UnitCombatMods>
<UnitCombats>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_ARCHER</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_MELEE</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_SIEGE</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_GUN</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_HITECH</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_DREADNOUGHT</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
</UnitCombats>
<Button>,Art/Interface/Buttons/Promotions/CityRaider3.dds,Art/Interface/Buttons/Promotions_Atlas.dds,7,2</Button>
<iCaptureProbabilityModifierChange>5</iCaptureProbabilityModifierChange>
</PromotionInfo>
<PromotionInfo>
<Type>PROMOTION_CITY_RAIDER4</Type>
<Description>TXT_KEY_PROMOTION_CITYRAIDER4</Description>
<Sound>AS2D_IF_LEVELUP</Sound>
<PromotionPrereq>PROMOTION_CITY_RAIDER3</PromotionPrereq>
<PromotionLine>PROMOTIONLINE_CITYRAIDER</PromotionLine>
<iLinePriority>4</iLinePriority>
<iCityAttack>25</iCityAttack>
<UnitCombats>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_ARCHER</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_MELEE</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_MOUNTED</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_SIEGE</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_GUN</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_HITECH</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
<UnitCombat>
<UnitCombatType>UNITCOMBAT_DREADNOUGHT</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
</UnitCombats>
<Button>,Art/Interface/Buttons/Promotions/CityRaider4.dds,Art/Interface/Buttons/RoM_Promotion_Atlas2.dds,4,3</Button>
<iCaptureProbabilityModifierChange>5</iCaptureProbabilityModifierChange>
</PromotionInfo>
Definitely BETTER, but probably much HARDER as well.Wouldn't it be better to enforce that rule by switching key and value - that is, specifying for each combat type which promotion line they had access to and up to which point?
That's what is happening in the rules but not in the display code. I've never been too arsed to go in and fix it on the display coding since I don't see why its necessary we're trying to show ever promo a unit could possibly get in the pedia anyhow.Wouldn't it be better to enforce that rule by switching key and value - that is, specifying for each combat type which promotion line they had access to and up to which point?
This is irrelevant.That's what is happening in the rules but not in the display code. I've never been too arsed to go in and fix it on the display coding since I don't see why its necessary we're trying to show ever promo a unit could possibly get in the pedia anyhow.
THANKS!As promotion line rank increases it should never gain new unitcombat.
Otherwise you are just adding promotion to unitcombats, that they can't get at first place.
City Raider III didn't have Mounted unitcombat, and I fixed it.
Apparently Mounted weren't meant to get City Raider III, IV and V.THANKS!
Yeah, that was what I pointed out in the first place, when my own units bumped into it.
TECHICALLY, though, it's not impossible for a unit to UPGRADE to a different UnitCombat in some wonky way.
So you could eventually "force" units to have Promotions that they "officially" shouldn't be able to have.
But this is very RANDOM and impractical, to say the least.
In this (unfixed) case, a Mounted unit with CR2 could *somehow* upgrade to a Melee one, get CR3, then upgrade back to a Mounted one, and get the bugged CR4.
But this is pretty much "bugging out the bugs", lol, and absolutely NOT a normal "tactic" whatsoever.
On the other hand, you COULD (in a very FAR future) employ this TRICK for, dunno, Equipment and similar stuff.
Still, normal Promotions should NEVER work this way, period.
OH, I see why that becomes a problem... for this reason. lol. Except that SHOULD invalidate the CR3 when they then later lose the melee Unitcombat, leading to a retraining of both 4 and 3, though it might hang on to 4 since it would then think, since it's specified incorrectly in the xml directly on the CR 4 promo, that THAT should be valid so keeps it despite CR3 being made invalid. A loop was removed in the invalidation checks that was intended to fix that - the modder who removed it I think just thought it was an unnecessary redundancy.In this (unfixed) case, a Mounted unit with CR2 could *somehow* upgrade to a Melee one, get CR3, then upgrade back to a Mounted one, and get the bugged CR4.
This would be beneficial to note on a bug log on git.Is the forest fire feature supposed to destroy lumbermill improvements? I have 3 lumbermills that randomly disappear at times, I get no notification about being pillaged. They are just are gone.
Edit: Never mind, figured out it is burglars pillaging. I forgot there is no notification for some criminal units pillaging.