Suggestions for Improved Moddability

[Meneth]

One thing I forgot to mention: a remove_nickname command or something similar to remove nicknames.

Makes sense. Added:

• A remove_nickname = <character> command

 

[Captain Gars]

All suggestions added to the first page as of now are under review.

Meneth: please don't add anything else or update the first page until I give notice.

 

[Captain Gars]

Moved the thread to the proper subforum.

 

[Captain Gars]

Should be crossed off the list:

There already is a difficulty trigger.
There alread is a combat_tactic trigger.

Meneth: please also see the Captain's Log for info on which suggestions has been implemented.

 

[Meneth]

Should be crossed off the list:

There already is a difficulty trigger.
There alread is a combat_tactic trigger.

Meneth: please also see the Captain's Log for info on which suggestions has been implemented.

Thanks for the updates!
Removed from list:

• Add conditions to check the difficulty level, E.G., difficulty = hard, and higher_difficulty_than = easy
• Trigger conditions based on combat tactic in use

Moved to implemented:

• Improved variable support, most importantly the ability to compare two variables to see if they're greater, lesser, or equal
• Allow multiplication and division of variables (like in EU4)
• Allow comparing two variables
• Allow effects/conditions to use variables instead of only pure numbers (E.G:, wealth = var)
• Allow mathematical operations involving multiple variables (E.G., var1 = var2 * var3)
• Add a dynasty_head scope
• A condition to check the number of holding slots in a province, and a condition to check the number of free holding slots in a province
• Add condition "borders_major_river = yes/no" or similar, making it possible to check if a province borders a major river

Question:
Is there any way to check that two variables are equal, rather than just var a => var b? If not, that'd certainly be useful in some contexts.

 

[Captain Gars]

Question:
Is there any way to check that two variables are equal, rather than just var a => var b? If not, that'd certainly be useful in some contexts.

No. Those triggers operate exactly as others. I really wish that Paradox once upon a time when creating the script system hadn't settled for that model and instead implemented three operators (>, < and =). Would have made my life much easier as well

 

[Meneth]

No. Those triggers operate exactly as others. I really wish that Paradox once upon a time when creating the script system hadn't settled for that model and instead implemented three operators (>, < and =). Would have made my life much easier as well

Ah well, can be worked around by testing =>, then incrementing slightly, then testing <; if both are true then they must be equal.
How high is the precision of the numbers anyway? Floats? Doubles?

 

[Captain Gars]

Ah well, can be worked around by testing =>, then incrementing slightly, then testing <; if both are true then they must be equal.
How high is the precision of the numbers anyway? Floats? Doubles?

We don't use floats or doubles but a FixedPoint based on an int32, using the last three digits as decimals. So you can have a value from -2,147,483.648 to 2,147,483.647

 

[Captain Gars]

But well now you have the sources, right? It is so difficult to add new commands to make this tests? Those test using XXX = { NOT ... } are incubus for me...
it seems not efficient to me for the engine itself...

Oh well maybe a new version of the engine itself? Or use a real scripting language as for example lua at this point...

The use of only = as operator has little to do with the triggers and effects but with how the engine parser works. Not impossible to change (some said so, but I proved them wrong) but changing how all triggers work and their localisation - that would take a lot of work.

 

[Meneth]

We don't use floats or doubles but a FixedPoint based on an int32, using the last three digits as decimals. So you can have a value from -2,147,483.648 to 2,147,483.647

Thanks, that answers the question. Incrementing by 0.001 would be the ideal, then.

The use of only = as operator has little to do with the triggers and effects but with how the engine parser works. Not impossible to change (some said so, but I proved them wrong) but changing how all triggers work and their localisation - that would take a lot of work.

Would it perhaps be possible to have an "is_equal = { var1 var2 }" command specifically for variables? Equality does come up rather a lot for variables.

 

[Captain Gars]

Would it perhaps be possible to have an "is_equal = { var1 var2 }" command specifically for variables? Equality does come up rather a lot for variables.

Hm, I guess.

EDIT: Done.

 

[Meneth]

Hm, I guess.

EDIT: Done.

<3

Moved to "implemented in upcoming patch":

• Ability to set graphical culture for characters, both in history and through commands

 

[Captain Gars]

<3

Moved to "implemented in upcoming patch":

• Ability to set graphical culture for characters, both in history and through commands

None of what I've done so far is in the new patch. I will gather some of the simpler fixes and port them over to the next patch. All major changes I do down the line though will probably have to wait until the next expansion/DLC patch.

 

[Meneth]

None of what I've done so far is in the new patch. I will gather some of the simpler fixes and port them over to the next patch. All major changes I do down the line though will probably have to wait until the next expansion/DLC patch.

I'll rename the section to "implemented in an upcoming patch". Does that sound good?

Moved:

• More raid related conditions/scopes (E.G: is_raiding = yes, raiding = ROOT, on_action for when loot is returned)

On_action is crossed out since that isn't implemented (yet).

 

[Captain Gars]

I'll rename the section to "implemented in an upcoming patch". Does that sound good?

Moved:

• More raid related conditions/scopes (E.G: is_raiding = yes, raiding = ROOT, on_action for when loot is returned)

On_action is crossed out since that isn't implemented (yet).

Sounds good. I also renamed them to is_looting and is_looting_in to be more in line with in-game localisation.

 

[Meneth]

Moved:

• More specific familial relationship opinion modifiers (E.G., brothers, uncles, grandparents)

 

[Captain Gars]

How about the ability to script opinion of characters and other things like 'traitor' and 'reason to get jailed'? E.g. Magnus is a murderer because he murdered Knud in 1134, but characters don't remember this if you start in 1135 which would otherwise be punishable by law. King X divorced Queen Y in year A, as the script say, but Y's family wouldn't act accordingly if you started at a later start date a few years later. Duke Friedrich was commonly known as a traitor since the Great Saxon rebellion, but there is no way to have this scripted. The Hvide family are valiant supporters of one particular branch of the Danish Royal family, but this is not scriptable.

I think we need some kind of way to script in opinion modifiers to character in certain years and such.

You can script any effects in the character history files, see for example Rurik's starting army and fleet. So adding opinions should work - however I tested this and apparently the opinion effect can't take a charcater id as an argument... I will fix that though.

 

[Captain Gars]

Fixed. You can now script opinions in history files.

 

[Meneth]

Removed strikethrough:

• More raid related conditions/scopes (E.G: is_raiding = yes, raiding = ROOT, on_action for when loot is returned)

 

[Meneth]

• killer and any/random_killed_character scopes. any_lover_even_if_dead, mother_even_if_dead, and the ability to scope to the former holders of a given title would all be nice as well.

mother = {} and father = {} to my knowledge both ignore the parent being dead; I seem to recall that father_even_if_dead = {} is deprecated.