[BUG]/limitation with GlobalTriggers/GlobalFactionMods & mod compatability possibility.

from GalCiv3 Forums
  • curremntly ResearchCost (the value used to determine how much research is needed to research a tech) is not valid for GlobalTriggers/GlobalFactionMods due to not being in the schema.  If these can be expanded, mods like my ILO & naselus' IAB will be mostly drop-in compatible and with a ciouple more events types to match OnEvents against we won't have to worry much about updating them even with big changes in future patches.
    • I also need/want a little help making this work if the xml limitation isn't the only problem

      <GlobalFactionMods>
      <Trigger>
      <OnEvent>OnTechAgeReached</OnEvent>
      <Target>Faction</Target> (should this be <CriteriaCampaignID>?  kinda tough wading out into the darkness with a modifier type I can't use)
      <CriteriaInternalName>AgeOfWar</CriteriaInternalName>
      <PerformAction>
      </PerformAction>
      </Trigger>
      <Modifier>
      <Target>
      <EffectType>ResearchCost</EffectType>
      <Target>
      <TargetType>Faction</TargetType>
      </Target>
      <BonusType>Multiplier</BonusType>
      <Value>.25</Value>
      <Modifier>
      </GlobalFactionMods>

      End of quote
  • The things we would need to be able to match against are specific building improvenents, specific ShipComponents, ShipHulls, StarBase modules, AICategoryWeights  & possibly a few other things off the top of my head.  A simple text file with xml examples ofa few basic things (mod ResearchCost by TechAge, mod a specific tech/improvement/shipcomponent/shiphull/StarBaseModule)would likewise be useful for everyone. ModifierEffectTypes.xsd has a bunch of them
  • making something like this would be helpful all over as well:

  • <GlobalFactionMods>
    <Trigger>
    <OnEvent>OnConstructImprovment</OnEvent>
    <Target>Planet</Target>
    <CriteriaInternalName>ColonyCapital</CriteriaInternalName>
    <PerformAction>
    </PerformAction>
    </Trigger>
    <Modifier>
    <Target>
    <EffectType>Manufacturing</EffectType>
    <Target>
    <TargetType>Planet</TargetType>
    </Target>
    <BonusType>Flat</BonusType>
    <Value>ToNull</Value>
    <Modifier>
    <Modifier>
    <Target>
    <EffectType>SocialManufacturing</EffectType>
    <Target>
    <TargetType>Planet</TargetType>
    </Target>
    <BonusType>Flat</BonusType>
    <Value>5</Value>
    <Modifier>
    </GlobalFactionMods>

    [/quote]
    End of quote

    Going from memory on what he changed there in iab, but the concept remains sound even if different values , it's a way to null out a value there already by default that may or may not still be $DefaultNum and replace it with $newEffect and $newNum.  if that can apply to all the stuff I mentioned above, significant overhaul mods will be dropin compatible once we have the ability to set which should take precedence in the event of a conflict & in some ways much easier to make/keep updated.
4,576 views 2 replies
Reply #1 from GalCiv3 Forums Top
  • curremntly ResearchCost (the value used to determine how much research is needed to research a tech) is not valid for GlobalTriggers/GlobalFactionMods due to not being in the schema.  If these can be expanded, mods like my ILO & naselus' IAB will be mostly drop-in compatible and with a ciouple more events types to match OnEvents against we won't have to worry much about updating them even with big changes in future patches.
End of quote

 

 

This would be particularly useful for setting the game's research pace - the present +/- research modifier is ineffective because it stacks with the building bonuses.

 

And yes, having some xml injection capability would be nice - it'd massively reduce the amount of reconciliation needed whenever there's a patch, too.

Reply #2 from GalCiv3 Forums Top

Even a rudimentary system would be of enormous help, an example I can point out is endless space, a game whose modability was frankly limited but still better than GC3's overall.  And this was largely due to a simple dependency system.  You listed in the header for the mod those files the mod had dependency on, then you could build your files as you saw fit. If for example you were modifying ship components and wanted to overwrite a specific component you did not need to replace the whole file. You simply made sure the internal name matched that of the original item and the file header listed the correct entry type just like we do currently, but instead of throwing duplicate entry errors and acting all weird in game, the game simply over-rode that entry and it prevented the modders from needing to create total overwrites anytime they wanted to replace one thing in an original file.

Galactic Civilizations III