New in Gathering Storm: You Can Disable the Ability to Construct Projects Until an Effect Triggers

isau

Deity
Joined
Jan 15, 2007
Messages
3,071
This is pretty useful IMO.

There is a new table in Gathering Storm called Projects_XP2. One of the fields is called UnlocksFromEffect. If set to 1, this field will prevent players from building the project until you manually trigger the effect from a Modifier.

Now, the only existing ModifierType Firaxis thought to include in the DynamicModifiers table is MODIFIER_EMERGENCY_PLAYERS_MAKE_PROJECT_AVAILABLE. This Modifier is intended exclusively for use with Emergencies. However, you can do an Insert into DynamicModifiers to change the CollectionType to something else, and now you have the ability to control access to the Project.


I pasted an example below. This code makes a Project available only to civs that have a certain Trait.

I can think of many, many uses for this feature. It's just too bad Firaxis didn't include a UnlocksFromEffect option for Civics, Technologies, and Buildings too, or we'd really be cooking.


Code:
INSERT INTO Types
    (Type,                     Kind)
VALUES     ('QUO_PROJECT_BIOME_ASIAN_EXPANSE_THIS_SPHERE_ONLY',         'KIND_PROJECT') ;


INSERT INTO Projects
    (ProjectType,             Name,                ShortName,                Description,                    Cost,    PrereqTech,        MaxPlayerInstances,    PrereqDistrict)
VALUES ('QUO_PROJECT_BIOME_ASIAN_EXPANSE_THIS_SPHERE_ONLY',    'QUO_PROJECT_BIOME_ASIAN_EXPANSE_THIS_SPHERE_ONLY_NAME',    'QUO_PROJECT_BIOME_ASIAN_EXPANSE_THIS_SPHERE_ONLY_SHORT_NAME',    'QUO_PROJECT_BIOME_ASIAN_EXPANSE_THIS_SPHERE_ONLY_DESCRIPTION',        40,    NULL,    1,            'DISTRICT_CITY_CENTER');


-- this new table in expansion 2 lets us limit the project so it is only enabled once we activate an effect
INSERT INTO Projects_XP2 (
                             ProjectType,
                             RequiredPowerWhileActive,
                             ReligiousPressureModifier,
                             UnlocksFromEffect,
                             RequiredBuilding,
                             CreateBuilding,
                             FullyPoweredWhileActive,
                             MaxSimultaneousInstances
                         )
                         VALUES (
                             'QUO_PROJECT_BIOME_ASIAN_EXPANSE_THIS_SPHERE_ONLY',
                             0,  --'RequiredPowerWhileActive',
                             0, -- 'ReligiousPressureModifier',
                             1, -- 'UnlocksFromEffect',
                             NULL, --'RequiredBuilding',
                             NULL, -- 'CreateBuilding',
                             0, --'FullyPoweredWhileActive',
                             1  --'MaxSimultaneousInstances'
                         );    

-- code to enable the effect that enables the special rproject for this sphere
INSERT INTO Types
 (Type,     Kind)
VALUES  ('QUO_MODTYPE_BIOME_ASIAN_EXPANSE_MAKE_PROJECT_AVAIL', 'KIND_MODIFIER' ) ;
INSERT INTO DynamicModifiers
  (ModifierType, CollectionType, EffectType)
VALUES  ('QUO_MODTYPE_BIOME_ASIAN_EXPANSE_MAKE_PROJECT_AVAIL', 'COLLECTION_OWNER','EFFECT_ADD_PLAYER_PROJECT_AVAILABILITY');

INSERT INTO Modifiers 
 (ModifierId, ModifierType, RunOnce, Permanent, OwnerRequirementSetId, SubjectRequirementSetId)
VALUES ('QUO_BIOME_ASIAN_EXPANSE_ENABLE_PROJECT', 'QUO_MODTYPE_BIOME_ASIAN_EXPANSE_MAKE_PROJECT_AVAIL', 0, 0, NULL, NULL) ;

INSERT INTO ModifierArguments
 (ModifierId,    Name,   Type,    Value,    Extra,  SecondExtra)
VALUES ('QUO_BIOME_ASIAN_EXPANSE_ENABLE_PROJECT',  'ProjectType',  'ARGTYPE_IDENTITY',  'QUO_PROJECT_BIOME_ASIAN_EXPANSE_THIS_SPHERE_ONLY',   NULL,  NULL) ;

INSERT INTO TraitModifiers
 (TraitType,    ModifierID)
VALUES ('QUO_TRAIT_BIOME_ASIAN_STEPPE', 'QUO_BIOME_ASIAN_EXPANSE_ENABLE_PROJECT') ;
 
Well, Gathering Storm allows us to attach modifiers directly to players and cities from lua. So it may be possible to make lua do the heavy-lifting for whether a player has a given tech, civic, building, [fill-in-the-X here]. The effect should be the same whether the modifier is attached within the database from table TraitModifiers (for example) or whether the modifier is attached to the desired player-object via an lua script.

The only thing we cannot currently do is actually un-attach a modifier from a player or a city via lua. But by adding an OwnerRequirementSetId or SubjectRequirementSetId to the modifier definition, and then defining that RequirementSet and its individual Requirements to act as an enabler/disabler we should be able to get pretty darn close to an effective method for attaching/unattaching a modifier.

Using an OwnerStackLimit of integer '1' will also only allow the modifier to be effectively attached one time, regardless of how many times an lua script might give a result of "true" for whether or not the modifier should be attached to a given player or city. I've experimented with this for other types of modifiers, and even though I continuously added the same modifier once-per-turn to the same player, the OwnerStackLimit and the SubjectStackLimit both worked to control how many times the modifier was actually "added" to the same player or city.
 
Well, Gathering Storm allows us to attach modifiers directly to players and cities from lua. So it may be possible to make lua do the heavy-lifting for whether a player has a given tech, civic, building, [fill-in-the-X here]. The effect should be the same whether the modifier is attached within the database from table TraitModifiers (for example) or whether the modifier is attached to the desired player-object via an lua script.

The only thing we cannot currently do is actually un-attach a modifier from a player or a city via lua. But by adding an OwnerRequirementSetId or SubjectRequirementSetId to the modifier definition, and then defining that RequirementSet and its individual Requirements to act as an enabler/disabler we should be able to get pretty darn close to an effective method for attaching/unattaching a modifier.

Using an OwnerStackLimit of integer '1' will also only allow the modifier to be effectively attached one time, regardless of how many times an lua script might give a result of "true" for whether or not the modifier should be attached to a given player or city. I've experimented with this for other types of modifiers, and even though I continuously added the same modifier once-per-turn to the same player, the OwnerStackLimit and the SubjectStackLimit both worked to control how many times the modifier was actually "added" to the same player or city.


That's very cool that they added that feature to Lua--long overdue. I have never used the stack limit settings because to be honest I'm still unclear on what they actually do. :) The existing in-game modifiers don't seem to make much use of them.


The reason I'd like a feature to block Technologies, Civics, and Buildings is there are so many tables with fields like PrereqTech or PrereqCivic, etc that can be used to delay or lock out an effect. If we could designate some Civics or Technologies as "hidden" techs (like you now can with Projects due to the new field that designates them as becoming available only by an Effect) it would be possible to control many more game systems. I may be wrong and there is a way to do this currently, but all my tries so far result in the Civic or Tech tree screens collapsing. You can rewrite those of course. But native support like with Projects would be a huge win.
 
SubjectStackLimit
  • "SubjectStackLimit" must be an integer value. It must be a positive whole number.
  • This limit will cap the number of times the entire modifier can be applied to any "subject" of the modifier. It does not act as a cap on a Modifier's argument "Amount" values given in table ModifierArguments.
  • The cap is applied regardless of whether a "SubjectRequirementSetId" argument is supplied.
OwnerStackLimit
  • "OwnerStackLimit" must be an integer value. It must be a positive whole number.
  • This limit will cap the number of times the entire modifier can be applied to any "owner" of the modifier. It does not act as a cap on a Modifier's argument "Amount" values given in table ModifierArguments.
  • The cap is applied regardless of whether a "OwnerRequirementSetId" argument is supplied.
Only these modifiers use a SubjectStackLimit:
"MOUND_AMENITY_MAX_TWO"
"LOCAL_INFORMANTS_SPY_DEFENSE_BONUS"
"COMMEMORATION_EXPLORATION_GA_FOREIGNIDENTITY"
"COMMEMORATION_INFRASTRUCTURE_BUILDER_DISCOUNT_MODIFIER"
"COMMEMORATION_INFRASTRUCTURE_SETTLER_DISCOUNT_MODIFIER"
"COMMEMORATION_TOURISM_GA_WONDERS"
"COMMEMORATION_ESPIONAGE_GA_ESTABLISH"
"COMMEMORATION_ESPIONAGE_GA_REDUCTION"
"SUPPLY_CONVOY_BONUS_MOVEMENT"
"COTHON_HEALFRIENDLY"
"MOUND_AMENITY_MAX_ONE"​

None of the Firaxis-made modifiers use a OwnerStackLimit so far as I can tell from a quick search of the database. But I've tested OwnerStackLimit and know it to work so long as the modifier being used is one where the "owner" of the modifier would be affected by the stack limit.

These two modifiers worked regardless of the number of times I tried to re-add the modifier(s) to the same player via lua. The game only implemented the modifier twice in both cases. So with the GRANT_2_EXTRA_MOVES modifier I got a total of 4 extra moves to all my units regardless of the number of times the same modifier was applied to the player. And with the GRANT_1_EXTRA_MOVES only a total of 2 extra moves were applied by the game regardless of the number of times the modifier was added to the same player by the lua code.
Code:
<Modifiers>
	<Row ModifierId="MODIFIER_ABILITY_GRANT_1_EXTRA_MOVES_ALL_UNITS_LRS" ModifierType="MODIFIER_PLAYER_UNITS_ADJUST_MOVEMENT"
		OwnerStackLimit="2" Permanent="true" />
</Modifiers>
<ModifierArguments>
	<Row ModifierId="MODIFIER_ABILITY_GRANT_1_EXTRA_MOVES_ALL_UNITS_LRS" Name="Amount" Value="1" />
</ModifierArguments>
<Modifiers>
	<Row ModifierId="MODIFIER_ABILITY_GRANT_2_EXTRA_MOVES_ALL_UNITS_LRS" ModifierType="MODIFIER_PLAYER_UNITS_ADJUST_MOVEMENT"
		OwnerStackLimit="2" Permanent="true" />
</Modifiers>
<ModifierArguments>
	<Row ModifierId="MODIFIER_ABILITY_GRANT_2_EXTRA_MOVES_ALL_UNITS_LRS" Name="Amount" Value="2" />
</ModifierArguments>
 
Last edited:
I may be wrong and there is a way to do this currently, but all my tries so far result in the Civic or Tech tree screens collapsing. You can rewrite those of course. But native support like with Projects would be a huge win.
We can re-write the UI files easily enough to hide certain techs or civics. But the problem is this only dis-allows human players from selecting a hidden tech or civic and has no effect whatever on the AI. There's no method via lua I know of at the moment (unless one was added by Gathering Storm which we aren't as a modding community aware of athe moment) to set a player's current civic "research" project from a gameplay script, tho we can do so for technologies.

For technologies we can make use of dummy techs if we re-write the game's UI files and then run an lua GameplayScript to select a "normal" tech any time an AI player tries to select a "hidden" technology. But then we are going to be banging up against all those popuar UI mods that re-write everything to make them "better".

The other issues I recall from testing this approach for Vanilla was that "hidden" or "dummy" technologies when given to a player still make the research-completed pop-up want to occur for a human player. And there may or may not be "diplo gossip" messages occuring when a "hidden" or "dummy" tech is given to an AI player. I never advanced far enough in testing the system to determine whether game-mechanics such as free techs from Great People, goody huts, or Wonder-construction are going to want to give "hidden" or "dummy" techs.

Firaxis in general have made "dummy" or "hidden" anything not easy to use or implement in civ6, unlike things were in Civ5, where dummy or hidden techs, policies, buildings, etc., were pretty easy to do and were standard methods to get otherwise unavailable effects.
 
Last edited:
Top Bottom