Has anyone tested the river variable in the AI files? What is its impact on the AI?
Last edited:
-
We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
You bet I did 
Well its valid range is between 0.0 and 1.0. At 1.0 the AI considers that it does not have any impact, at a lower level the AI will be reluctant to send offensive across rivers, which might lead to a sitzkrieg situation. I think the default is 0.5 but not completely sure.
To use it you have to take into account the tech level and the amount of "oil-consuming" units.
Well its valid range is between 0.0 and 1.0. At 1.0 the AI considers that it does not have any impact, at a lower level the AI will be reluctant to send offensive across rivers, which might lead to a sitzkrieg situation. I think the default is 0.5 but not completely sure.To use it you have to take into account the tech level and the amount of "oil-consuming" units.
Tamerlan said:You bet I did
To use it you have to take into account the tech level and the amount of "oil-consuming" units.
Thanks for your reply.
I looked at a saved game and found the german river variable to be 1.0 instead of the 0.85 that the loaded AI file indicated. I tried changing the AI file river variable (0.1 to 0.9) and the saved game always showed 1.0. In looking at other countries I could not match the saved game river variable with the loaded AI file river variable in any of them.
Did you look at saved games also? Maybe I'm missing something.
Yeah, I looked at the saved file... And it was not like that !mikel said:
Congratulation you found a real, big, nasty bug !
In the save files, river and withdraw_odds seem equal everywhere. Correct me if I am wrong...
Tamerlan said:Yeah, I looked at the saved file... And it was not like that !
Congratulation you found a real, big, nasty bug !
In the save files, river and withdraw_odds seem equal everywhere. Correct me if I am wrong...
Yes you are right. When I change the withdraw_odds to 1.2 the river variable was saved as 1.2. It appears that the withdraw_odds variable value is being saved as the river variable.
Ouch! Now if we just knew which values it is actually using in the code. I suppose someone could test that by setting withdraw_odds to something like 0.01 to see if that nation stops attacking across rivers completely. And it would be helpful to know if the "saved" value is updated when a new AI file is loaded.
Mithel said:
Hmmm, all I can say is that I've been using 0.25 withdraw odds for Japan vs. China in CORE 0.70/71/8 (to simulate Japanese stubborn defense somehow) and they were still crossing rivers quite nice. Too bad I can't test 0.01 now, I'm making this post from my laptop...
Copper, ah, but were you observing results after a save and reload?
If the error is in the save game then potentially our hands off testing of a complete run without ever reloading a save might never show this bug.
If the error is in the save game then potentially our hands off testing of a complete run without ever reloading a save might never show this bug.
Mithel said:
You are right, I guess those were always hands-off's.
I'll try to test it when I come home...
Copper Nicus said:
Although I was not specifically testing the river-withdraw_odds switch when I first ran across the problem, I did observe that when I changed my withdraw_odds from .5 to 1.5 the AI began immediately and repeatedly to attack across a river where previously it had not done so. Far from a rigorous test but the results were quite dramatic.
The savegame is clearly incorrect and on reload I see no other way it could go back to the original AI file river value unless an event reloads the AI file after startup.
Unfortunately it's impractical to reload the AI files constantly! Hmmm... might actually be tempting to try and reload them once a month. When we play multiplayer (once the war breaks out) we rarely play more than three months in a night and then we have to save. So I consider this a very critical bug!
If someone is going to test this it would be worth it to carefully observe the settings of all the other front variables to see if there are any others that get wiped out upon save and reload.
If someone is going to test this it would be worth it to carefully observe the settings of all the other front variables to see if there are any others that get wiped out upon save and reload.
As a solution, the trigger of the AI switch could be considered as a single "signal" trigger event and some "persistent" events which would really load the AI would be added. Persistent events can be fired each time you reload.
The combination of "signal" preconditions should be checked quite carefully with multiple AIs however. Quite tidious :wacko: .
The combination of "signal" preconditions should be checked quite carefully with multiple AIs however. Quite tidious :wacko: .
Tamerlan said:
Tamerlan: Have you already reported this as a bug to Paradox? Or should this be reported in the Bug Subforum?
Did it. Like the -1 garrison penalty, and almost everything not straight which is on this sub-forum. After that it is up to the developpers to consider what they change/leave. This one got a nasty title, so I hope it will be prioritized (somehow it is a memory bug. memory bugs are something C++ dev dreadsmikel said:
).Tamerlan said:Did it. Like the -1 garrison penalty, and almost everything not straight which is on this sub-forum. After that it is up to the developpers to consider what they change/leave. This one got a nasty title, so I hope it will be prioritized (somehow it is a memory bug. memory bugs are something C++ dev dreads
Sounds good. Let's hope they fix it. The event workaround just adds unnecessary stress on the engine.