Will anything be done to correct the worst issue in the game -- CV attack and defense values being decreased by each CV ship in the battle? The -0.02 per ship is fine for normal surface ship gunnery but is just plain wrong for CVs battles. CV battles need to be done by a different set of rules.
-
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.
Found another issue with 1.10, in my Improved 1936 mod, I have edited the Xi'an incident in hoi2.txt among other vanilla events. The edited hoi2.txt and other country files are within their own folder in db/events/Improved/Vanilla events folder. My scenario has the correct paths to the correct folders and files, like they have for ever, and the edited events have worked just fine in the past.
However, when I upgraded to 1.10, the scenario, for some peculiar reasons, the scenario loads up the vanilla events from db/events, rather than the edited ones from db/events/Improved/Vanilla Events folder! I noticed this when Xi'an incident happened at its vanilla date, and Germany liberated Slovakia at the end of Czechs instead of giving it to Hungary like I have told them to do in the event, among other things.
I checked the save, and there are no paths leading to the vanilla events at db/events, all paths are to the various Improved folders where the edited events are located. So no errors within the paths what so ever.
So somehow, for some reason, its ignoring the edited files and loading up the vanilla files instead. Could it be an ID issue? The vanilla and edited events have the same ID, so it loads up the vanilla event data from some mysterious database?
All the events I have added with new IDs and files are working just fine.
However, when I upgraded to 1.10, the scenario, for some peculiar reasons, the scenario loads up the vanilla events from db/events, rather than the edited ones from db/events/Improved/Vanilla Events folder! I noticed this when Xi'an incident happened at its vanilla date, and Germany liberated Slovakia at the end of Czechs instead of giving it to Hungary like I have told them to do in the event, among other things.
I checked the save, and there are no paths leading to the vanilla events at db/events, all paths are to the various Improved folders where the edited events are located. So no errors within the paths what so ever.
So somehow, for some reason, its ignoring the edited files and loading up the vanilla files instead. Could it be an ID issue? The vanilla and edited events have the same ID, so it loads up the vanilla event data from some mysterious database?
All the events I have added with new IDs and files are working just fine.
Mmh... so you do not use moddir at all?
Would the topic in your signature contain the mod in question in a version that exhibits the problem?
Would the topic in your signature contain the mod in question in a version that exhibits the problem?
another annoying thing is the manpower aging, it is absurd that manpower decreases the time a manpower point is active, it should be the other way around, any increase in manpower growth should extend the life of manpower
And the fix listed in the changelog does not work? Strange.
Manpower growth has never affected aging at all - it was just the tooltip that claimed so.
Manpower growth has never affected aging at all - it was just the tooltip that claimed so.
i will check again
edit checked and yes, the tool tip is working now, so ignore my previous post
Last edited:
That is correct, moddir is not being used by the mod, the files are in their own folders within the main folder. Think its an issue because of it? It has previously worked just fine like that.
And yes, the mod can be found from my signature, I ran the tests with the current version of it.
Found the "problem". It wasnt about paths or IDs, the scenario was loading the correct files and folders.
Seems with the new .exe, having Historical events outcome ON completely overrides any ai_chance value there are in the event options, even 100% chance. AI always picks option A, which lead to my incorrect assumption that it was loading the vanilla events.
I ticked it OFF and everything works wonderfully again.
Curiously, I had Historical events outcome ON with the old .exe too, and the AIs chose accordingly to the ai_chance = values, rather than always going for option A, so having it ON made zero impact really. Guess it was broken before and now its fixed?
Seems with the new .exe, having Historical events outcome ON completely overrides any ai_chance value there are in the event options, even 100% chance. AI always picks option A, which lead to my incorrect assumption that it was loading the vanilla events.
I ticked it OFF and everything works wonderfully again.
Curiously, I had Historical events outcome ON with the old .exe too, and the AIs chose accordingly to the ai_chance = values, rather than always going for option A, so having it ON made zero impact really. Guess it was broken before and now its fixed?
Last edited:
I guess it is the opposite. In 1.08 Historical events outcome worked as intended, the option with highest ai_chance wins. As usualy Option A has the highest ai_chance the two usually coincide, but not always. So Historical events outcome in the 1.10 exe would seem to be broken.
Ah yeah, that makes perfect sense. Thanks for clearing it up, seems we stumbled on a bugged feature after all.
Well... actually this is a bit difficult.
When I started working on the code, the two "Historical [something]" options added in 1.08 were not in, so I had to replace them from scratch - the game crashed when encountering their tokens in 1.08 saves even.
So, naturally, I asked how it is supposed to work and presented these two possibilities:
Many historical choices are - either from hindsight or from inadequate simulation - bad.
Alright. But furthermore, especially in the second case, many historical choices are completely ridiculous because the game does not at all simulate the rationale for originally making them.
Events dealing with the latter should not have the historical option as the one with highest ai_chance.
Case in point: Slovakia was not offered to Hungary. This is an ahistorical event choice, it should never happen with the option active.
- But it's definitely the best course of action. It should have the highest ai_chance (if one is interested in the AI making smart decisions).
In contrast, @Lennartos noted that the historical event choice is by design the first one. If I am not too mistaken, this is also mentioned in one of the old developer diaries. - So I did not deem it necessary to actually investigate how the original implementation worked; apparently I better should have.
In conclusion, the issue is apparently, that this change is not documented in the changelog - I am going to add it for the next RC.
... Unless someone wants to present a profound and passionate argument against it, I am inclined to retain the current functionality.
When I started working on the code, the two "Historical [something]" options added in 1.08 were not in, so I had to replace them from scratch - the game crashed when encountering their tokens in 1.08 saves even.
So, naturally, I asked how it is supposed to work and presented these two possibilities:
- always option_a
- always highest chance
Many historical choices are - either from hindsight or from inadequate simulation - bad.
Alright. But furthermore, especially in the second case, many historical choices are completely ridiculous because the game does not at all simulate the rationale for originally making them.
Events dealing with the latter should not have the historical option as the one with highest ai_chance.
Case in point: Slovakia was not offered to Hungary. This is an ahistorical event choice, it should never happen with the option active.
- But it's definitely the best course of action. It should have the highest ai_chance (if one is interested in the AI making smart decisions).
In contrast, @Lennartos noted that the historical event choice is by design the first one. If I am not too mistaken, this is also mentioned in one of the old developer diaries. - So I did not deem it necessary to actually investigate how the original implementation worked; apparently I better should have.
In conclusion, the issue is apparently, that this change is not documented in the changelog - I am going to add it for the next RC.
... Unless someone wants to present a profound and passionate argument against it, I am inclined to retain the current functionality.
Last edited:
Current meaning using option a instead of the one with highest ai_chance?
In vanilla there are few event where option a does not have the higest ai_chance, namely event 2005 GER and a few others. So for vanilla the disadvantages are somewhat limited. As for modding a proper mechanism using highest ai_chance seems much more comfortable as ai_chance could simply be edited instead of having to rearange all the options in the event and possibly also having to change the translation files.
You may want to use option 2 for AI-only events while keeping option 1 for all others. In Core we use some AI events to decide event outcomes and this may be (or is) spoiled with option 1.
... I was under the impression that CORE is not meant to be played with that option active anyway?
Context-sensitive handling definitely seems unintuitive.
Context-sensitive handling definitely seems unintuitive.
Indeed. "Previous": apparently highest ai_chance; "current": always option_a.
That is kind of the point, is it not? They should not generally coincide.
Imo the general idea is that the historical choice has the highest ai_chance. If historical outcome of events is implemented as it currently is in 1.10, than this is a design decision to make them coincide in general.
I completely agree with Zsar. The AI should make smart decisions, not historical ones. Obviously, the historical events choice lets players chose that. In 1.09 and earlier versions there is little point for the historical events option as most historical decisions have a 90%+ chance of triggering anyway.
That said, there should IMO be some benefit to chosing historical (or some penalty for not doing so). I.e. for the German events about the removal of Schact, von Fritsch and others the ahistorical option should create some dissent for Germany (or, if Schacht is kept, Germany should get +1 free market - I've stolen the idea from the Third Reich Mod).
Very good to see some on going development thanks.
Would have liked a new event command for activating naval doctrines, rather than just activating a blueprint for naval doctrines. Would certainly help out with naval doctrine path change when some naval doctrines, common to both paths, have already been researched.
Does the division retreat path have anything to do with a memory of the original path that the division took to arrive in that province?
Would have liked a new event command for activating naval doctrines, rather than just activating a blueprint for naval doctrines. Would certainly help out with naval doctrine path change when some naval doctrines, common to both paths, have already been researched.
Does the division retreat path have anything to do with a memory of the original path that the division took to arrive in that province?
