Is there randomness or are they set dates?
Have waited for one to appear several turns and getting a bad feeling my game is messed up someway.
-
Captain_Orso
- Posts: 5766
- Joined: Tue Sep 01, 2009 5:02 pm
- Location: Stuttgart, Germany
There is a chance you might be able to see how the events you are talking about ran. I'm not sure if you need to have debugging turned on or not -- I have it turned on all the time --, but I get a series of log files in ..\ACW\Scripts\ named ScriptReportnnnn.txt, where nnnn is the game-engine-world turn number.
Let me explain this. The game-world starts counting with turn number 0001 on I think 1750 January Early. The April 1861 ACW Campaign therefore starts on game-turn 2671. So for example if you start an April 1861 Campaign and run it for 10 turns you will have 10 ScriptReport files in ..\ACW\Scripts\ named ScriptReport2671.txt, ScriptReport2672.txt and so on up to ScriptReport2680.txt.
However there is only one possible ScriptReport file for each game-engine-world turn that the game executes. So if you are running two or more different games at the same time, they can overwrite each others ScriptReport files, with the last run turns ScriptReport for that run turn being the only one left, depending on the game-engine-worlk time of the games being played.
Assuming that you are only executing turns from the one game you should therefore have a ScriptReport for each game-turn run in that game.
Something else you have to understand is that every event belonging to the scenario you are playing is run each and every turn. So even events that have already fired and are only allowed to fire once, or logically cannot fire, because the time frame in which they may fire has passed, will still be evaluated each turn. Each of these events generates a section in the ScriptReport file. They look like this:
The lines with the dashes are simply to visually separate the reports on different events.
Very often you will find SelectFaction statements preceding the event itself.
Started processing event: show the name of the actual event being precessed.
Since my game is in September 1864 this event has already fired once (current occurences 1) may only fire once (Max allowed: 1) and therefore cannot fire again (Too many occurences for event evt_nam_CSA_FoodRiotsB1863 further processing aborted.).
Check for these logs and search them for the events in question and look for the report's explanation of what they did. If you already know the name of the event, simply search for it.
Hope this helps.
Let me explain this. The game-world starts counting with turn number 0001 on I think 1750 January Early. The April 1861 ACW Campaign therefore starts on game-turn 2671. So for example if you start an April 1861 Campaign and run it for 10 turns you will have 10 ScriptReport files in ..\ACW\Scripts\ named ScriptReport2671.txt, ScriptReport2672.txt and so on up to ScriptReport2680.txt.
However there is only one possible ScriptReport file for each game-engine-world turn that the game executes. So if you are running two or more different games at the same time, they can overwrite each others ScriptReport files, with the last run turns ScriptReport for that run turn being the only one left, depending on the game-engine-worlk time of the games being played.
Assuming that you are only executing turns from the one game you should therefore have a ScriptReport for each game-turn run in that game.
Something else you have to understand is that every event belonging to the scenario you are playing is run each and every turn. So even events that have already fired and are only allowed to fire once, or logically cannot fire, because the time frame in which they may fire has passed, will still be evaluated each turn. Each of these events generates a section in the ScriptReport file. They look like this:
Code: Select all
Line 1945: ------------------------------
Line 1947: SelectFaction, selected: Confederacy
Line 1949: Started processing event: evt_nam_CSA_FoodRiotsB1863
Line 1949: Event already referenced, current occurences 1 Max allowed: 1 >>Sleeping<<
Line 1951: Too many occurences for event evt_nam_CSA_FoodRiotsB1863 further processing aborted.
Line 1964: Finished processing event: evt_nam_CSA_FoodRiotsB1863
Line 1964: ------------------------------
The lines with the dashes are simply to visually separate the reports on different events.
Very often you will find SelectFaction statements preceding the event itself.
Started processing event: show the name of the actual event being precessed.
Since my game is in September 1864 this event has already fired once (current occurences 1) may only fire once (Max allowed: 1) and therefore cannot fire again (Too many occurences for event evt_nam_CSA_FoodRiotsB1863 further processing aborted.).
Check for these logs and search them for the events in question and look for the report's explanation of what they did. If you already know the name of the event, simply search for it.
Hope this helps.
-
Captain_Orso
- Posts: 5766
- Joined: Tue Sep 01, 2009 5:02 pm
- Location: Stuttgart, Germany
From my experience, no. Once the event has been set to "Sleeping" even changing the date(s) won't wake it up again. I think there is a list, probably in the .hst file, of the events that are 'asleep' and the engine just goes over them and reports it.
Maybe somebody knows a 'trick' to wake them up again?
Maybe somebody knows a 'trick' to wake them up again?
-
charlesonmission
- Posts: 781
- Joined: Wed Mar 09, 2011 5:55 am
- Location: USA (somewhere)
-
charlesonmission
- Posts: 781
- Joined: Wed Mar 09, 2011 5:55 am
- Location: USA (somewhere)
-
Captain_Orso
- Posts: 5766
- Joined: Tue Sep 01, 2009 5:02 pm
- Location: Stuttgart, Germany
I'm making an educated guess here. I looked into the the latest .hst file of the game I am playing. The last couple hundred lines in the file are the list of events and their status as I mentioned above.
If you are sure of which events generates which flavor units and the even(s) in question must fire and generate the unit(s)[SUP]1)[/SUP], but haven't[SUP]2)[/SUP], you can search out the event in this list and set its "Occurences=1" for that event in the .hst file back to "0" and edit the event itself[SUP]3)[/SUP] to fit a time frame so that it will fire in a future turn execution in your game.
[SUP]1)[/SUP] If the event has a chance of not generating the unit because of its parameters, you should leave it alone and consider it fate that the unit was not generated. It can be complex. Some events depend on other events firing first. Others depend on specific situations to be in effect, such as a specific leader being present in the game, for them to fire successfully.
2) If you can ascertain that the event failed when it should not have and can document it with save-game files and logs, please report it in the "Help to improve AACW" sub-forum and provide your documentation.
3) If you do intend to change your event file, make a copy of it first and put it in a safe place. Once you are satisfied with the results of your modified event(s), don't forget to copy your original file back into place after all events have fired so that you are back to a proper installation.
If you are sure of which events generates which flavor units and the even(s) in question must fire and generate the unit(s)[SUP]1)[/SUP], but haven't[SUP]2)[/SUP], you can search out the event in this list and set its "Occurences=1" for that event in the .hst file back to "0" and edit the event itself[SUP]3)[/SUP] to fit a time frame so that it will fire in a future turn execution in your game.
[SUP]1)[/SUP] If the event has a chance of not generating the unit because of its parameters, you should leave it alone and consider it fate that the unit was not generated. It can be complex. Some events depend on other events firing first. Others depend on specific situations to be in effect, such as a specific leader being present in the game, for them to fire successfully.
2) If you can ascertain that the event failed when it should not have and can document it with save-game files and logs, please report it in the "Help to improve AACW" sub-forum and provide your documentation.
3) If you do intend to change your event file, make a copy of it first and put it in a safe place. Once you are satisfied with the results of your modified event(s), don't forget to copy your original file back into place after all events have fired so that you are back to a proper installation.
Thank you for your help! 
What does this sound like?
Or this.
They are both active but the Missouri brigade has a fixed date, Tramp brigade just had bad rolls?
What does this sound like?
Line 16461: SelectFaction, selected: Confederacy
Line 16462: Started processing event: evt_nam_CSA_MissouriBdeReinforcement
Line 16462: Event already referenced, current occurences 0 Max allowed: 1 <<Active>>
Line 16465: Fixed date evaluated: 1862/05/02 converted to turn 2697 current turn 2702 False
Line 16474: SelectFaction, selected: Confederacy
Line 16490: Finished processing event: evt_nam_CSA_MissouriBdeReinforcement
Or this.
Line 16231: SelectFaction, selected: Confederacy
Line 16232: Started processing event: evt_nam_CSA_TrampBde
Line 16232: Event already referenced, current occurences 0 Max allowed: 1 <<Active>>
Line 16235: Min date evaluated: 1862/07/01 converted to turn 2701 current turn 2702 True
Line 16236: Max date evaluated: 1862/12/01 converted to turn 2711 current turn 2702 True
Line 16237: Unique unit: Tramp Bde NOT found / FixType differs
Line 16238: Probability evaluated: Probability 50 rolled 97 False
Line 16245: SelectFaction, selected: Confederacy
Line 16263: Finished processing event: evt_nam_CSA_TrampBde
They are both active but the Missouri brigade has a fixed date, Tramp brigade just had bad rolls?
-
Captain_Orso
- Posts: 5766
- Joined: Tue Sep 01, 2009 5:02 pm
- Location: Stuttgart, Germany
Firstly, you are looking at the wrong event for the Missouri Brigade. The Missouri Brigade is generated with the evt_nam_CSA_MissouriBde event, just above the evt_nam_CSA_MissouriBdeReinforcement event, which gives the Missouri Brigade, if it already exists, an additional infantry regiment.
So let's break the event down.
This says we are working with things to do with the CSA faction.
This is the event name. The first "1" means that this event may fire[SUP]1)[/SUP] only once. The second "1" means that it is a 'Line' event. This means that only a text description in the Mail Box will report that the event has fired. A "0" in this position means that no message is generated, and a "2" means that a message with a popup (news paper article), and sound is generated. The 'NULL's are placeholders and have no further meaning.
This section describes the conditions which must be met for the event to fire. MinDate and MaxDate define the time frame in which the event may fire. EvelUnqUnit tells the engine to look for a unit with the provided name; in this case "Missouri Bde". If found it evaluates as TRUE and the event continues to execute. If not found, it evaluates as FALSE and the event fails to execute. The "NOT" reverses the logic of the command. So this command is saying look for a unit named "Missouri Bde", if not found TRUE and continue executing. This is so that not more than one Missouri Bde can be generated.
If the event has gotten this far these are the actions which will be executed. Note, if any of these actions fail, and they can, the event will also fail. DescEvent references the text line in the ..\ACW\Settings\LocalStrings_ACW.csv file beginning with "evt_desc_CSA_MissouriBde". The text behind the name will be displayed in the Mail Box message.
SelectRegInArea tells the engine to select a region depending on the parameters. "$Ozarks" is defined in ..\ACW\GameData\Areas.ini as $MO and $AR, which means that it includes all regions belonging to Missouri and Arkansas. $MO and $AR are defined in the same Areas.ini file.
OwnedVPCities means that only regions containing an Objective or Strategic city are considered and these must be controlled by the faction (at least 50% MC and the city must be controlled. It is possible to have 100% MC of a region, but still not control the city[SUP]2)[/SUP].
Squared means that all the cities within the named area are considered with chances of each city being chosen weighted by the structure level of the city squared. So a level 1 city would be weighted at 1, but a level 2 city would be weighted at 4, etc.
Being that all parts of an event must evaluate as TRUE for the event to fire, if the SelectRegInArea command fails to find a city meeting the requirements, the event will fail. The VP Cities in $Ozarks ($MO & $AR) are: Saint Louis MO, Springfield Mo, Fayetteville AR, Little Rock AR and Madison AR. Is it possible that during the time frame in which the event may fire that the CSA did not control at least one of these cities?
If the event has reached this sections only an error in these parameters could cause it to fail. This section defines the unit to be generated and placed in the region selected by the SelectRegInArea command.
End of the event's execution.
Could you check if you have ScriptReport2690.txt through ScriptReport2694.txt. These correspond to '62 Jan Late through '62 March Late. If present and not generated from the running of a different scenario they will show the actual execution reports of the evt_nam_CSA_MissouriBde event.
[SUP]1)[/SUP] An event fires if all of its conditions are met and it successfully executes.
[SUP]2)[/SUP] There are restrictions on controlling a city. If you have =>50% Loyalty in a region simply having MC of the region gives you control of the city. If you have <50% Loyalty in the region you must garrison the city with either an infantry regiment or more (militia, conscripts, line, etc.) or a 'Late War' cavalry unit. Irregular units (Raiders, Rangers, etc.) cannot garrison.
So let's break the event down.
Code: Select all
SelectFaction = $CSAThis says we are working with things to do with the CSA faction.
Code: Select all
StartEvent = evt_nam_CSA_MissouriBde|1|1|NULL|NULL|NULL|NULLThis is the event name. The first "1" means that this event may fire[SUP]1)[/SUP] only once. The second "1" means that it is a 'Line' event. This means that only a text description in the Mail Box will report that the event has fired. A "0" in this position means that no message is generated, and a "2" means that a message with a popup (news paper article), and sound is generated. The 'NULL's are placeholders and have no further meaning.
Code: Select all
Conditions
MinDate = 1862/01/16
MaxDate = 1862/03/16
EvalUnqUnit = Missouri Bde;NOTThis section describes the conditions which must be met for the event to fire. MinDate and MaxDate define the time frame in which the event may fire. EvelUnqUnit tells the engine to look for a unit with the provided name; in this case "Missouri Bde". If found it evaluates as TRUE and the event continues to execute. If not found, it evaluates as FALSE and the event fails to execute. The "NOT" reverses the logic of the command. So this command is saying look for a unit named "Missouri Bde", if not found TRUE and continue executing. This is so that not more than one Missouri Bde can be generated.
Code: Select all
Actions
DescEvent = evt_desc_CSA_MissouriBde
SelectRegInArea = $Ozarks;Squared;OwnedVPCities
GenMsgIf the event has gotten this far these are the actions which will be executed. Note, if any of these actions fail, and they can, the event will also fail. DescEvent references the text line in the ..\ACW\Settings\LocalStrings_ACW.csv file beginning with "evt_desc_CSA_MissouriBde". The text behind the name will be displayed in the Mail Box message.
SelectRegInArea tells the engine to select a region depending on the parameters. "$Ozarks" is defined in ..\ACW\GameData\Areas.ini as $MO and $AR, which means that it includes all regions belonging to Missouri and Arkansas. $MO and $AR are defined in the same Areas.ini file.
OwnedVPCities means that only regions containing an Objective or Strategic city are considered and these must be controlled by the faction (at least 50% MC and the city must be controlled. It is possible to have 100% MC of a region, but still not control the city[SUP]2)[/SUP].
Squared means that all the cities within the named area are considered with chances of each city being chosen weighted by the structure level of the city squared. So a level 1 city would be weighted at 1, but a level 2 city would be weighted at 4, etc.
Being that all parts of an event must evaluate as TRUE for the event to fire, if the SelectRegInArea command fails to find a city meeting the requirements, the event will fail. The VP Cities in $Ozarks ($MO & $AR) are: Saint Louis MO, Springfield Mo, Fayetteville AR, Little Rock AR and Madison AR. Is it possible that during the time frame in which the event may fire that the CSA did not control at least one of these cities?
Code: Select all
SelectFaction = $CSA
CreateGroup
Posture = $Defensive
SetKind = $Land
Entranch = 0
InCS = 0
FixType = 0
SetName = Missouri Brigade
Apply
CreateUnit
SetType = $uni_CSA_BdeN13
NumCreate = 6
FlavorName = Brg.Gen. L.H.Little
SUFlavorName = Wade's Art Bty|Clarke's Art Bty|1st Missouri Cav|1st Missouri|2nd Missouri|3rd Missouri|NULL
SetName = Missouri Bde
ApplyIf the event has reached this sections only an error in these parameters could cause it to fail. This section defines the unit to be generated and placed in the region selected by the SelectRegInArea command.
Code: Select all
EndEvent
End of the event's execution.
Could you check if you have ScriptReport2690.txt through ScriptReport2694.txt. These correspond to '62 Jan Late through '62 March Late. If present and not generated from the running of a different scenario they will show the actual execution reports of the evt_nam_CSA_MissouriBde event.
[SUP]1)[/SUP] An event fires if all of its conditions are met and it successfully executes.
[SUP]2)[/SUP] There are restrictions on controlling a city. If you have =>50% Loyalty in a region simply having MC of the region gives you control of the city. If you have <50% Loyalty in the region you must garrison the city with either an infantry regiment or more (militia, conscripts, line, etc.) or a 'Late War' cavalry unit. Irregular units (Raiders, Rangers, etc.) cannot garrison.
-
Captain_Orso
- Posts: 5766
- Joined: Tue Sep 01, 2009 5:02 pm
- Location: Stuttgart, Germany
Glad to have helped. I don't know about it being a one time thing though. The thing about programs is they don't have a mind of their own. They can't have a 'bad day' and forget something. Unless something from outside is influencing what they are doing, they will do the same thing over and over again without regard.
Do you have backups of from the beginning of '62?
Do you have backups of from the beginning of '62?
Return to “AGEod's American Civil War”
Who is online
Users browsing this forum: No registered users and 12 guests