A Validator for EU3

[Jamie550]

Jamie, my apologies for screwing up. I claimed that war_score was percentages from -1.0 to +1.0. Turns out, in fact, it requires integers from -100 to +100.

Fixed, thanks.

One thing I've been getting is localisation errors, for too few or too many columns, seem to come up one-at-a-time. Thus it'll give a single error for a given one loc file, at say, line 100. Then, having corrected that, & re-validated, I get the same message for line 101, & so on.

Is this how it's supposed to be?

It is how it is for the moment. However, hopefully something can be done to make the process much more efficient.

While I agree with you about being allowed to use only parts of define_ruler etc the point I was suggesting is that the game is not good at creating random numbers for the other non specified stats. For instance the events in dynastic.txt that offer one of two heirs - several people posted that the game always assigns 3's for the missing stats and that maybe it would be better to specify all the stats in an event rather than letting the game assign them.

So in the case of creating a ruler leader by event would it not be best for validator to suggest all the stats be specified in the event to help the average user??? For myself writing events I would like the reminder that I forgot to specify a stat. On the other hand I guess if the goal of validator is only to specifiy things that are strictly invalid then maybe leave things optional.

It would be helpful to at least have your explanation, or a brief synopsis of it in the help or suggestion box to encourage average persons such as myself to fill in all three stats.

T

I agree. It would be helpful to at least have the option.

[George LeS]

On leader stats, I found when I had "maneuver" spelled as such, that the value was always 0. That, with the value of 3 always given to monarchs, makes me think that omitted stats are not randomly assigned, but that the minimum possible is what you get. IMO, that's an argument against making them optional. But just my opinion.

[17blue17]

Need to add to effect for HTT:

this_remove_casus_belli as in

this_remove_casus_belli = {
			type = cb_vassalize_mission
			target = THIS
		}

I left this effect out of the HTT changes originally because I did not know if it was a typo or not but jdrou correctly pointed out to me that it was added in the 4.1a beta.

[Jamie550]

Need to add to effect for HTT:

this_remove_casus_belli as in

this_remove_casus_belli = {
			type = cb_vassalize_mission
			target = THIS
		}

I left this effect out of the HTT changes originally because I did not know if it was a typo or not but jdrou correctly pointed out to me that it was added in the 4.1a beta.

Will be fixed.

[Jamie550]

Helius, I'd like to confirm some things in relation to FROM, to make sure that I'm understanding right.

1) Only events can contain FROM
2) To contain FROM, an event must have is_triggered_only set to true, and hence no trigger clause
3) FROM will never appear in a trigger clause; however, it may appear inside limit = { } clauses contained by an event satisfying the other conditions.
4) FROM always, always, with no exceptions whatsoever, refers to the country/province of the event that triggered this current event containing FROM. This also means that each FROM in an event must refer to the same country/province.
5) country_event = xxx is only valid when directly within a country scope, and province_event = xxx is valid only when directly within a province scope. This is true even if the event specified by xxx does not contain FROM.
6) country_event and province_event do not necessarily have to point to events where is_triggered_only is true, but can point to any events (of their respective types)

Also a question: Anytime you need a country tag, can you also have THIS (if we are in a country event) and FROM (if this is called by a country event), as well as things like emperor, random, and the like? Same for anytime you need a province.

[Helius]

Helius, I'd like to confirm some things in relation to FROM, to make sure that I'm understanding right.

1) Only events can contain FROM

True.

2) To contain FROM, an event must have is_triggered_only set to true, and hence no trigger clause

Not true.

The event may have either have is_triggered_only set to true, or have a trigger clause, or both.

is_triggered_only

Fires only when spawned, whenever it is spawned.

trigger clause

Fires at random (within MTTH), when the trigger clause is true.
Fires when spawned, every time it is spawned.

both is_triggered_only and has a trigger clause

If spawned, will only fire if the trigger clause is true.
Will never fire at random (i.e., if NOT spawned), even if the trigger clause IS true.

3) FROM will never appear in a trigger clause; however, it may appear inside limit = { } clauses contained by an event satisfying the other conditions.

True.

4) FROM always, always, with no exceptions whatsoever, refers to the country/province of the event that triggered this current event containing FROM. This also means that each FROM in an event must refer to the same country/province.

True.

5) country_event = xxx is only valid when directly within a country scope, and province_event = xxx is valid only when directly within a province scope. This is true even if the event specified by xxx does not contain FROM.

True.

6) country_event and province_event do not necessarily have to point to events where is_triggered_only is true, but can point to any events (of their respective types)

True.

Also a question: Anytime you need a country tag, can you also have THIS (if we are in a country event) and FROM (if this is called by a country event), as well as things like emperor, random, and the like? Same for anytime you need a province.

Not sure. In general, yes. In particular cases, I've seen it not work.


Notably, I can positively confirm "emperor" as a valid use only for the following contexts:

EUIII in general:
secede_province = emperor

H3T, only:
add_core = emperor
who = emperor (as in relation = { who = emperor ... }

Hoping that others may be able to fill in other positively confirmed, valid uses.


I've never used 'random'. I'd be be highly surprised if, for instance, secede_province = random would produce sensible results, other than a CTD.

Off the top of my head, confirmed valid uses:

remove_merchant = random (removes a random country's merchant from a COT)
release_vassal = random
remove_advisor = random (not 100% sure, since I've never seen it in action, but rely on second-hand info)


THIS/FROM are interchangeable - wherever you may use THIS, you may use FROM.

While I do believe that any TAG is valid, where THIS is valid, I don't believe that the reverse holds true.
[EDIT] The validator didn't recognize "army = TUR" as valid, and I forgot I needed to test this. So hold off on this, until I've tested it, please.

From memory, the following require a specific TAG, without accepting THIS:

knows_country
id = TAG, in AI strategy commands of a country scope, and
id = [province_id], in AI strategy commands of a province scope


There were other things that used to require a specified type name, and will not accept THIS, like

religion = [name]
accepted_culture = [name], if used in decision triggers

These were inconsistencies that may have been ironed out, by now. Only Johan would know.

[jdrou]

While I do believe that any TAG is valid, where THIS is valid, I don't believe that the reverse holds true.
[EDIT] The validator didn't recognize "army = TUR" as valid, and I forgot I needed to test this. So hold off on this, until I've tested it, please.

In some recent testing of 'send_merchant' I wasn't able to get it to work with a specific tag, only THIS.

[Jamie550]

Helius:

Clarifying your response to 2), is it true that
- There may be events with is_triggered_only = no, and no trigger. Here, the event will not happen unless it is triggered. Also, in such a case as this it would be best to set is_triggered_only to yes.
- That to allow FROM in an event, is_triggered_only must be set to yes

Also, in the case of is_triggered_only = yes, and there being a trigger clause, can this trigger clause contain FROM?

Though it is unfortunate that not all country/province pointers are equivalent to each other, which would have made life simpler (and make sense, imho), the equivalence of THIS and FROM does greatly help in programming.

Progress is going well, but the problem is that startup time for validation is increased by up to 15 seconds, regardless of whether any command clauses are validated at all. Reducing this something much lower is not too hard, but does require a bit of rejuggling. Would the potential 15 seconds (though much less, depending on the number of events and the like) be problematic?

[17blue17]

Helius:

Progress is going well, but the problem is that startup time for validation is increased by up to 15 seconds, regardless of whether any command clauses are validated at all. Reducing this something much lower is not too hard, but does require a bit of rejuggling. Would the potential 15 seconds (though much less, depending on the number of events and the like) be problematic?

For myself 15 seconds would be ok if there was a message during start up saying that it may take 15 seconds to start - just something so the user does not think the program has failed to run / stalled.

[antracer]

15 seconds is not a big wait.

A simple slider or timer or notification is fine.

Or you could do what Maxis used to do and put nonsensical start up information and entertain folks as it gets going...

Loading Meteor Event...
Loading Meteor Event Choice One...
Loading Meteor Event Choice Two...
Loading meteor Event Choice Three...
Losing some Stability...



T

[Jamie550]

Hmm, ok. I guess most people use the Validator differently, and don't have to validate many times in quick succession. To clarify, this delay will come after pressing the validate button. As the validator searches for province_event and country_event commands, as well as recording event IDs, progress will come at the status bar, with text changing to reflect the file being parsed.

In general, is it fine to do something like

province_event = {
	option = {
		has_country_modifier = somemodifier
	}
}

In other words, allowing all country commands to be used in province scope, without wrapping them in owner = { } tags.

Also, does the religion_group trigger work for provinces, like the religion trigger does?

Also, in using THIS with culture/culture_group/religion_group/religion, can THIS point to either province or country?

[17blue17]

In general, is it fine to do something like

province_event = {
	option = {
		has_country_modifier = somemodifier
	}
}

In other words, allowing all country commands to be used in province scope, without wrapping them in owner = { } tags.

I would not think so as many events / missions etc do show owner = { } in province events. There are some that Paradox forgot but I assume they are bugs. On the other hand they never seem to fix them in the patches so who knows??????

One new item. The new 4.1 beta released 2-27-10 says that they added quote:

Added event effect scope 'any_core'

It was previously used in rebel_types.txt as:

modifier = {
			factor = 0.001
			NOT = {
				any_core = {
					primary_culture = THIS
					exists = no
		 		}
		 	}

It seems they have now added it in decisions - Cultural.txt:

potential = {
			culture_group = THIS
			has_owner_religion = yes
			
			any_core = {
				exists = no
	 		}
		}

effect = {
			any_core = { 
				limit = { exists = no }
				remove_core = 0
			}

[17blue17]

I noticed something today and I wonder if anyone can confirm my thinking and if so we need to update validator.

Specifically in the history war files when ever you have

casus_belli = cb_claim_throne

you should also always have

succession = BOH

and vice versus?????

In other words is the succession = required to tell the game what tag the cb_claim_throne relates to?

I think there are a number of files that have one or the other but not both so maybe validator should check for this combo?

[Helius]

In general, is it fine to do something like

province_event = {
	option = {
		has_country_modifier = somemodifier
	}
}

In other words, allowing all country commands to be used in province scope, without wrapping them in owner = { } tags.

No, absolutely not. The only confirmed uses of cross-scope commands, as far as I know, are [country_scope] remove_province_modifier, as well as certain mission types that allow in the effects section the use of commands that are of either country or province scope.

Also, does the religion_group trigger work for provinces, like the religion trigger does?

I believe it does, and even with THIS.

Also, in using THIS with culture/culture_group/religion_group/religion, can THIS point to either province or country?

That is the one big unknown, as far as I am concerned. It works counter-intuitively, and it would take me to spend a few hours with the code I know to be functional and valid, to be able to tell you exactly what works where.


In other news, I was wrong when I said that ADM/DIP/MIL accept as arguments any integer. Whatever I thought I remembered Johan saying must have been a faulty recollection on my part. The fact is, 2-9 is confirmed valid use, and 1 may be valid, but I haven't tested that. 10 will CTD.

[Helius]

I noticed something today and I wonder if anyone can confirm my thinking and if so we need to update validator.

Specifically in the history war files when ever you have

casus_belli = cb_claim_throne

you should also always have

succession = BOH

and vice versus?????

In other words is the succession = required to tell the game what tag the cb_claim_throne relates to?

I think there are a number of files that have one or the other but not both so maybe validator should check for this combo?

Have you tested the combo-use? Does it work?

I think jdrou pointed out to me that "succession = TAG" has "never worked in any version of EUIII," after I recently reported that it didn't work in H3T.

OTOH, cb_claim_throne does seem to work, and will give the attacker the option to force a union on the defender.

Now, that is obviously different from "succession = TAG", where the alliance leaders on the attacker and defender sides fight over a PU with a third party, namely "TAG".

[Jamie550]

No, absolutely not. The only confirmed uses of cross-scope commands, as far as I know, are [country_scope] remove_province_modifier, as well as certain mission types that allow in the effects section the use of commands that are of either country or province scope.




I believe it does, and even with THIS.




That is the one big unknown, as far as I am concerned. It works counter-intuitively, and it would take me to spend a few hours with the code I know to be functional and valid, to be able to tell you exactly what works where.


In other news, I was wrong when I said that ADM/DIP/MIL accept as arguments any integer. Whatever I thought I remembered Johan saying must have been a faulty recollection on my part. The fact is, 2-9 is confirmed valid use, and 1 may be valid, but I haven't tested that. 10 will CTD.

Thank you for taking the time for answering all of these questions. The previous version of the validator had this cross-scope thing very, very wrong then.

For now, culture/religion triggers will continue to be usable with THIS and FROM pointing to either country or province. The ADM/DIP/MIL numbers have been changed to 1-9, inclusive.

Could you clarify the scope of modifier = {} clauses inside advisortypes.txt? Most seem to be in country scope, but there are a few, such as "port = yes" that are within province scope (unless port is a country trigger equivalent to num_of_ports = 1?)

[Jamie550]

v0.7.3 internal beta has been released

Download v0.7.3b here

The purpose of this release is to test the new validation system for triggers. Command validation is temporarily disabled, and will continue to be so until commands are converted to the new system. This version is very stable; however it does report many errors that the old Validator does not. I believe this to be due to errors that the old validator missed, but at least some are probably false positives, which then need to be fixed.

Some details on the trigger validation: The validation is contained in the Extension\Data\Eu3\Calls folder. The Commands.pdox and Triggers.pdox files in the \Eu3\ folder are no longer used.

TLDR: Other than trigger and command validation, everything should work just as expected.

[fuzzbug]

Could you clarify the scope of modifier = {} clauses inside advisortypes.txt? Most seem to be in country scope, but there are a few, such as "port = yes" that are within province scope (unless port is a country trigger equivalent to num_of_ports = 1?)

I always put country triggers for advisors in owner scope because I know this works.

[17blue17]

Have you tested the combo-use? Does it work?

I think jdrou pointed out to me that "succession = TAG" has "never worked in any version of EUIII," after I recently reported that it didn't work in H3T.

OTOH, cb_claim_throne does seem to work, and will give the attacker the option to force a union on the defender.

Now, that is obviously different from "succession = TAG", where the alliance leaders on the attacker and defender sides fight over a PU with a third party, namely "TAG".

Thanks for the reply.

At this point I was simply trying to fix some validator errors in the war files for my mod. I think Validator is suggesting all war files must have a CB type and I saw wars named XXX succession war and so I added the cb claim throne. Then I noticed that sometimes XXX was not listed in the war and so I wondered if succession = XXX was also needed to tell the war whoose throne was being fought over. However, now I understand that maybe I should have used cb border war for some of them. If I understand correctly if CB claim throne is used the throne being fought over is the defender's. Not sure what the game does if there is more than one defender.

Sorry I am not very good at testing code Moding maps yes, testing code no........

[Helius]

17, the new 4.1 has updated the war history files, and they use cb_claim_throne. Haven't checked what that looks like in game, though.

fuzzbug is right, modifiers in advisortypes are of province scope. Paradox has this wrong.