LeeS
Imperator
- So far as I recall no one has been able to get a negative plot yield to be implemented by the game when the 'Name' value in a ModifierArguments row is 'YieldType'. As a general rule negative values tend to be ignored by the game by most ModifierTypes.
- This part is not correct at all
Column 'Type' is not used in that way. Only the following can be provided for that columnCode:
INSERT INTO ModifierArguments (ModifierId, Name, Type, Value, Extra, SecondExtra) VALUES ('IMPROVEMENT_MINE_MODIFIER_JJ', 'Amount', 'YIELD_FOOD', '-1', NULL, NULL);Code:ARGTYPE_IDENTITY LinearScaleFromDefaultHandicap ScaleByGameSpeed- The last two are only ever to be used to create scaling effects for the human player's chosen difficulty-level and game-speed. All other usages must use 'ARGTYPE_IDENTITY'.
- Since the default value for column 'Type' in table 'ModifierArguments' is 'ARGTYPE_IDENTITY' you never need to state a value for column 'Type' unless you are reconfiguring the way game-speeds (Marathon, Quick, etc.) work or player difficulty levels (Prince, King, etc.).
- It's better to just eliminate use of the column altogether.
- It is also better to omit columns 'Extra' and 'SecondExtra' as greater than 99% of all Modifiers added to the game by mod-makers will never need them.
- This may be contrary to what you might have seen on other threads but I don't advocate people adding unecessary columns to their code because it's just a lot of extra typing and prone to result in syntax errors.
But as already mentioned the '-1' is likely not going to work as best as I can recall which modifier-types accept negative 'Amount' values.Code:INSERT INTO ModifierArguments (ModifierId, Name, Value) VALUES ('IMPROVEMENT_MINE_MODIFIER_JJ', 'Amount', '-1'), ('IMPROVEMENT_MINE_MODIFIER_JJ', 'YieldType', 'YIELD_FOOD'); - Eliminating additional un-needed columns from your SQL code elsewhere it is a little easier to see that this makes no logical sense:
Code:
INSERT INTO Requirements (RequirementId, RequirementType) VALUES ('REQUIRES_IMPROVEMENT_MINE_JJ', 'REQUIREMENT_PLOT_IMPROVEMENT_TYPE_MATCHES'); INSERT INTO RequirementArguments (RequirementId, Name, Value) VALUES ('REQUIRES_IMPROVEMENT_MINE_JJ', 'UnitType', 'IMPROVEMENT_MINE');- An ImprovementType is never going to be a 'UnitType' or vice versa.
- Instead of 'UnitType' you need 'ImprovementType' in order for the logic to make sense. The given RequirementType is 'REQUIREMENT_PLOT_IMPROVEMENT_TYPE_MATCHES' so the "Name" column in table "RequirementArguments" needs to be specifying 'ImprovementType'.
- 'MODIFIER_CITY_PLOT_YIELDS_ADJUST_PLOT_YIELD' is not logical either.
Table TraitModifiers attaches its modifiers at a player level, so you can't have the ModifierType be a city-level modifier.Code:
INSERT INTO TraitModifiers (TraitType, ModifierId) VALUES ('TRAIT_LEADER_MAJOR_CIV', 'IMPROVEMENT_MINE_MODIFIER_JJ'); INSERT INTO Modifiers (ModifierId, ModifierType, RunOnce, Permanent, OwnerRequirementSetId, SubjectRequirementSetId) VALUES ('IMPROVEMENT_MINE_MODIFIER_JJ', 'MODIFIER_CITY_PLOT_YIELDS_ADJUST_PLOT_YIELD', 0, 1, 'PLAYER_IS_HUMAN', 'QUALIFIED_REQUIREMENTS_JJ');- The problem with 'MODIFIER_CITY_PLOT_YIELDS_ADJUST_PLOT_YIELD' is that the game would not be able to "parse" what to do with this modifier since no City is specified as the object to which the modifier should be attached.
[table=head]ModifierType | CollectionType | EffectType
MODIFIER_PLAYER_ADJUST_PLOT_YIELD | COLLECTION_PLAYER_PLOT_YIELDS | EFFECT_ADJUST_PLOT_YIELD[/table]So all of a player's plots are affected with the Yield Change when using this ModifierType .
And it makes logical sense because the ModifierType is a player-level modifier rather than a city-level modifier.


Soon™.