FTG 1.3 Beta 23 February

[Toio]

And I thought in the simplified simulation that the game uses 5000 men per level of fortress were necessary to actually siege and fewer could only cover the fortress.

my game has 3000 and I have not amended anything

Most armies had a supply train which slowed them down and in most wars armies that operated deep in enemy territorry suffered from leaving the vicinity of their operational base. In the timeframe from 1419 to 1820 no army should be able to strike deep into enemy provinces far removed from their own lands without losing men like a snowball in the sun. Even Napoleon with several supply depots could not operate deep in russian territory for more than a few month - and the russian winter is only one of the factors that defeated his Grande Armee.
http://en.wikipedia.org/wiki/Loss_of_Strength_Gradient

supply trains/wagons went with the army and had a contingent of men to resupply the wagons as they moved, there was no supply line.
Basically up to Malborough who lived off the land while attacking Bavaria , the supply wagons was in use.

There was *always* attrition - even under the best of circumstances soldiers died in skirmishes, from diseases, desertion or marching. That attrition rises much higher under certain conditions is only realistic for the whole length of the game.
http://en.wikipedia.org/wiki/Military_logistics#17th-18th_centuries

I am saying a number 10 for winter is Ok, but an equal number 10 for supply attrition is silly, it has to be much lower. It makes NO sense that they are the same.

Or asking the other way: Do you really want states being able to march their armies with the same ease in their own provinces where they can be fully supplied, in neighbouring provinces or on the other side of the world?

Has it been tested?
I think a ONE province limit for supply ( ie only your neigbour) is silly, at least make it a 2 province depth

 

[Sleight of Hand]

my game has 3000 and I have not amended anything

From what I have seen, that only applies in overseas colonies.

 

[Andrei Gijgorev]

Not sure if you can have persistent events without country or province specifiers

So... after some tests I have concluded that "persistent = yes" is thoroughly broken, because persistent events trigger again and again and again and again regardless of offset values, although they work fine as AI events if the event commands prevent the event from triggering again, e.g. by the use of flags.

It is absolutely necessary that there is some mechanic that prevents a persistent event (or any event) from triggering multiple times for the same country on the same day, or while it is present as an event box.

 

[MichaelM]

So... after some tests I have concluded that "persistent = yes" is thoroughly broken, because persistent events trigger again and again and again and again regardless of offset values, although they work fine as AI events if the event commands prevent the event from triggering again, e.g. by the use of flags.

It is absolutely necessary that there is some mechanic that prevents a persistent event (or any event) from triggering multiple times for the same country on the same day, or while it is present as an event box.

Did you use an offset? I've had no problems with persistent events as long as either (a) it was triggered only, or (b) it used an offset.

 

[Andrei Gijgorev]

I did. Like this, yes?

event = {
    id = 878098
    persistent = yes
    trigger = {
        ai = no
        NOT = { flag = "test" }
    }
    name = "BLAH"
    date = { day = 0 month = january year = 1400 }
    offset = 20
    deathdate = { day = 29 month = december year = 1999 }
    style = 1
    action = {
        command = { type = setflag which = "test" }
    }
}

This triggers repeatedly. From the commands and triggers list thread:

How the offset works:
Many theories have been elaborated in the past ten years. Thanks to MichaelM, it seems that we now know the truth, hopefully he will correct me if I am (again) wrong: the offset is only used for the first check happening between startdate and startdate + offset, after that it is not taken into account at all and the event is re-checked between 16 and 76 days after the last check until the deathdate is reached.

If this is correct then persistent events firing repeatedly shouldn't have anything to do with offsets anyway.

Also, is the countryname command supposed to have a which parameter? There are some vanilla events that have one, but it has no effect.

 

[MichaelM]

That event works fine when I set the date to 1419; I tested the normal cases, but didn't realize there was an edge case when a persistent event's date is years before the scenario start date. I'll fix that.

Keep in mind that using a flag to make a persistent event trigger only once is not guaranteed to work in multiplayer games, since events don't pause the game.

Also, is the countryname command supposed to have a which parameter? There are some vanilla events that have one, but it has no effect.

It is not intended to, and as you said, it is a no-op.

 

[Andrei Gijgorev]

That event works fine when I set the date to 1419; I tested the normal cases, but didn't realize there was an edge case when a persistent event's date is years before the scenario start date. I'll fix that.

And since the scenario start date is reset upon loading a save game, this can happen with any persistent event. Good point about multiplayer games, looks like it's necessary to have one persistent event for an off-map country that triggers another persistent event for player countries. That way it should trigger only once.

About event dates later than the scenario start dates, I tried that with low offsets; offset = 1 had no effect and offset = 2 seemed to work but occasionally would trigger the event twice. I have half a mind to make the validator complain about offset values < 3. Since you have the code, how do you feel about that?

 

[Andrei Gijgorev]

event = {
	id = 878099
	persistent = yes
	trigger = {
		ai = no
		NOT = { event = 878099 }
	}
	date = { day = 0 month = january year = 1400 }
	offset = 1
	deathdate = { day = 29 month = december year = 1999 }
	action = {
		command = { type = setflag which = "test" }
	}
}

Upon investigating why this event wouldn't trigger even once, I found that persistent event IDs are written in the event history five times each time they are triggered. Is that really intended? Also, any idea why the event above doesn't trigger?

 

[MichaelM]

About event dates later than the scenario start dates, I tried that with low offsets; offset = 1 had no effect and offset = 2 seemed to work but occasionally would trigger the event twice. I have half a mind to make the validator complain about offset values < 3. Since you have the code, how do you feel about that?

I'll put in a manual adjustment to ensure that the time between firings is at least 1. Still, extremely small offsets are probably not going to be a common case.