OpenGen Questions & Bugs - Latest exe:24.11.08.0 ( 8-Nov-2024 )

[LuisGuzman]

Hi, I have read a little bit about the discussion about the aggressive maneuver leader. My question is: If I will give a special unit eg infantry a non-infantry leader like overwatch what will happen? Will the second ability then not used?

Yes, it should work. For those actions that can be affected by leaders, the engine checks if leader is defined as class or random.

[sympatyk]

Hi Luis

What is the matter - when upgrading the unit?
The unit won the leader in the hex. The unit does not yet have a bar.

https://drive.google.com/file/d/13IvMV5 ... sp=sharing

During the upgrade, the leader was taken and I got a lot of expe ... and an increased chance of being a leader
Some strange ...

https://drive.google.com/file/d/1WYvakx ... sp=sharing
https://drive.google.com/file/d/1VQi6ro ... sp=sharing
https://drive.google.com/file/d/12rl4hl ... sp=sharing

After deploy up the next scenario and the first shot I got a leader and 5 bars!

https://drive.google.com/file/d/1YfPEUy ... sp=sharing

and here is the save of the game
https://drive.google.com/file/d/1ATYUug ... sp=sharing

and after upgrading and before being placed on the game board
https://drive.google.com/file/d/10bd5EI ... sp=sharing

game engine 0.93.3.8, 0.93.3.7, 0.92.0.5
Gustlik's e-file

Additional question - was the leader from hex - the wrong one?
The hex - can enter - infantry, tank, artillery ...

[mythos]

Czesc sympatyk

The problem is: artillery with 0 organic movement shouldn't receive the Aggressive Maneuver Leader (because the bonus to movement doesn't work if 0).
You upgraded the unit to equipment which also has 0 Speed.
Please check, if the following config variable (either for efile or campaign/scenario) is set to 2:

Code: Select all

upgrade_ldr=0
* When upgrading leadered unit which makes random leader attribute useless... Default = 0
* Set to 1 to assign new random (according new equipment) but losing 1 bar.
* Set to 2 to remove leader, reducing unit's exp and bars as to be able to get a new leader.

I think the large amount of XP is an overflow, if the unit has 0 XP when upgrading.

[sympatyk]

Hallo Mythos
Vielen Dank für eine so schnelle Antwort

The e-file is set
* --- CFG setting file created by OpenSuite.
* --- only $ Variables included.

ground_carrier = 2
evade_special = 11
flak_range = 2
flak_ex2 = 1
upgrade_ldr = 1
avoid_cbf = 1
wild_weasel_ex = 1
blow_any_terrain = 1
attach_on = 1
subcd_naval_only = 1
allow_country0_gtp = 1
.......

The question remains -> why was the wrong leader in the hex awarded?
Overflow should not happen either ...

[LuisGuzman]

The question remains -> why was the wrong leader in the hex awarded?
Overflow should not happen either ...

Grzegorz

The reason of the overflow is because the unit#22 has a leader with no bars and only 22 xp (although that low xp doesn't affect)
Having zero bars is the reason for the overflow as when losing the leader the experience is adjusted (to give a high probability to recover the leader) using:

Code: Select all

new_xp = current_bars * 100 -50

thus when the unit has no bars, the new experience becomes - 50 (as it shows in the message), which overflows to:

Code: Select all

65536 - 50 = 65486

Regarding why that the Aggressive Maneuver is taken as not valid ... Chris explained before
The Agg.Maneuver leader is rarely assigned to a unit having no movement (game uses a random with probability only 5%) and the same routine is used when raising the leader or checking the leader validity, so you can be lucky when raising it, and not so lucky when upgrade the unit.
Maybe it would be better to remove that random possibility and disable always for units not able to move without a transport

[sympatyk]

Thank you very much
... I wrote here because - because the wrong leader should not be awarded the first time (in the hex - here is an error) -> the draw should be repeated -> there would be no incompatibility later

[Waldzios]

The reason of the overflow is because the unit#22 has a leader with no bars

This is very probable situation, with leader raised by 'Raise Leader' trigger. There is no bars or exp limit in trigger.

Having zero bars is the reason for the overflow as when losing the leader the experience is adjusted (to give a high probability to recover the leader) using:

Code: Select all

new_xp = current_bars * 100 -50

It would be reasonable/expected way with upgrade_ldr = 2 option set, not necessary with upgrade_ldr = 1.
IMHO if you can check option 1 for bars, then you should check option 2 for exp, and then possibly use option 0.

Maybe it would be better to remove that random possibility and disable always for units not able to move without a transport

Most definitely.

[mythos]

Maybe it would be better to remove that random possibility and disable always for units not able to move without a transport

I thought it was working like this for years.
Yes please, i think it is the more efficient (if not the better) solution to remove the random chance

[LuisGuzman]

Maybe it would be better to remove that random possibility and disable always for units not able to move without a transport

Most definitely.

Another option is to allow keeping that leader if the new equipment has a transport, because that was the condition allowing to raise it.

Currently several leaders are allowed for units not able to move by themselves if the unit has a transport. Aggressive Maneuver is one of this, but then another condition discard it when player is not luck enough (95% of the times). Doubtless, that was the condition to have got that Aggressive Maneuver leader in the artillery unit.

But this is not the only leader using a random probability to be raised (Bridging, Expert Camouflage, Liberator), although these other leaders are not removed when upgrading the unit randomly. Why not do the same with this rare case ?

The random possibility to get some leaders was widely debated and agreed long ago, so there is a reason to have kept that Aggressive Maneuver random leader for units moving only with a transport ...

What do you think ?

[Waldzios]

when player is not luck enough (95% of the times)

Are you sure?
For me it sounds, like there is about 3% to draw a specific leader (1 of ~30), then 5% to validate it, together it gives around 0,15%. So player is unlucky about 99,85 % of time.
Or I'm missing something ?

What do you think ?

The random possibility to get leaders is OK. I'm definitely not against it. I would never suggest to remove it.
Although, I'm little unsure about the math .

But the random test to validate leaders (when upgrading) is very strange.
IMHO separate validation procedure (without random part) for upgrade only, would be reasonable solution.

[LuisGuzman]

when player is not luck enough (95% of the times)

Are you sure?
For me it sounds, like there is about 3% to draw a specific leader (1 of ~30), then 5% to validate it, together it gives around 0,15%. So player is unlucky about 99,85 % of time.
Or I'm missing something ?

I meant that getting that Aggr.Man leader as a result of a trigger, has a probability of 5%.

The random possibility to get leaders is OK. I'm definitely not against it. I would never suggest to remove it.

Ok them!

Any other comment from someone else

[Waldzios]

I meant that getting that Aggr.Man leader as a result of a trigger, has a probability of 5%.

I''m pretty sure it's much less than 5%. In GusOpen we are using $upgrade_ldr for at least two years now, and we have plenty of 'raise leader' triggers in campaigns. If it was really 5% chance, we would have plenty of similar issues already reported (with this, or other random leader).
Whereas Sympatyk issue is first one reported ever.

Unfortunately I don't have time to test it. I will left it for now.

[randowe]

Any other comment from someone else

Is the whole discussion bount to upgrade_ldr = 1 or 2? I can not say anything on this because i am not using the variable

[sympatyk]

I'm sorry I opened a Pandora's box
Continuation of this story
Unit # 22 after the next scenario (I shot a little and gained experience) suddenly loses exp
Now this unit looks like this

https://drive.google.com/file/d/12bQbx0 ... sp=sharing

There are 9 exp, 5 bars and a leader ...

[mythos]

But this is not the only leader using a random probability to be raised (Bridging, Expert Camouflage, Liberator), although these other leaders are not removed when upgrading the unit randomly.

i hadn't considered potential side effects.
I guess, with such a small chance, keeping the chance "as is", and only fixing the XP overflow of $vars, is the more efficient solution

[Puma]

Where can I download the latest exe? I am using 93.3.0 and I am fed up with all the weird shirt happening

[lvjtn]

Where can I download the latest exe?

http://luis-guzman.com/OpenGen/OpenGenTest.zip

imo you can boookmark it, Luis uses this url permanently

the latest test version (0.93.3.98.Test) is close to be released as 0.93.4.0 soon

[LuisGuzman]

I've just uploaded the next Release Candidate version, including all these fixes since last oficial 0.93.3.0:

• Enabled "handwriting icon" in map menu, to allow resetting foe spotting
• Air units (using Air Missions) were not auto resupplying when they don't have a mission during a turn
• When a unit was losing its leader while upgrading but the unit had no exp-bars, the unit's experience did overflow to a huge value
• Planes using air mission could resupply if over a friend airfield different than its air-base
• Can add $ai_delay defining a different delay after AI actions (default is 300 ms)
• When $am_delaydrop was enabled for Air Missions, and game was was saved before an airborne unit was dropped after moving,
  the unit was moved to base after reloading
• When attacking ground unit was in a river, the defender was able to fire back, regardless stats
• Removed text tooltip on map when labels on map are enabled
• When raising protos the first GTP matching eight and F/F was assigned without checking if GTP was obsolete.
• When showing labels on map was set, didn't work the info on map. It has been improved
• Naval units could not deploy in Ports when the scenario setting "Ports don't behave as SH" was set.
• When assigning a leader to units of class: BS,BC or Cruiser in Suite, the increased range was not used in game.
• It was not possible to barrage an hex having a hidden unit
• When scenario defined default sp and terrain limit refitting based on %, units having current sp equal to default sp could refit 1 sp if terrain was less than 100%
• Depots was not working if $supply_ex was not defined
• The units in naval transport were not landing when using AI3
• Scroll of map while deployment, is improved.
• AI hanged when there were units starting embarked in NTP
• Reasigning units, was returning double prestige
• DH hexes were not available for deployment
• After returning to base, cannot rebase (no bases are highlighted
• Bug-report was storing user Nick and Mail in registry only
• AI planes using air missions and located at start of scenario out of an air base, didn't return to a base after his turn.
• Photos and medals were not updated when cycling prev/next within Inspect Dialog
• Photos and medals were not loaded if png is 8 bits.
• Default videos can be put into efile's SMACK folder too
• equipment size increased to 10999 units
• When scenario/campaign has videos defined for winning/losing and the videos are not found (neither local, nor main SMACK folder)
  default videos will be checked and eventually played in found in main SMACK folder and videos are enabled in settings
  Default video files are: scen_won, scen_lost, cam_won, cam_lost
• Fixed a bug when detecting if loading NamesEx.txt or Names.txt
• Leaders' names are stored in the savegames
• Leader's names can be read from existing names.txt or from new namesEx.txt which must not include the unused first dummy 31 entries
  and can include comment lines starting with token * (asterisk) (#2)
• Optimized loading medals and photos (dossier and inspect) to load only the image needed. (#1)
• Replacing JP forum button with OG forum button
• Reinforces was not marked to track experience
• Die Mel was not playing

Can download from [url=http://luis-guzman.com/OpenGen/OpenGenRC.zip] OpenGenRC.exe version 0.93.3.99.RC.
The link and the change log is also available from my web.

I'll wait a week or two to promote as official release 0.93.4.0 in case someone else find any other glitch

Also in the coming days I'll upload another version I call "OGX" including the current state of the AI3, in case someone wants to test, although it is just "work in progress" yet.

[sympatyk]

When a unit was losing its leader while upgrading but the unit had no exp-bars, the unit's experience did overflow to a huge value

At present, nothing changes -> the leader and experience after modernization - the same

Thank you very much

[mythos]

Luis

• When raising protos the first GTP matching eight and F/F was assigned without checking if GTP was obsolete.
• Naval units could not deploy in Ports when the scenario setting "Ports don't behave as SH" was set.

Works



Luis, could you please check: hotkey combo <Alt 8> (cycle Grid type) doesn't seem to work.

[randowe]

I have a little request. Or i would like to ask if it is possible first. And useful for others.
Often (every time ) when i read other people's AAR i would like to take a look at the map of the scenario. To understand what they write about in their AAR.
Is it possible to add the map number of a scenario to the AAR header? Could be a five digit number or five letters for TILED maps.
(It is not very important but i have that idea in my head for quite some time now and thought i ask it)

[LuisGuzman]

Luis, could you please check: hotkey combo <Alt 8> (cycle Grid type) doesn't seem to work.

Sorry Chris that I forgot to reply this question, but I checked and it works for me.
Are you sure you are using hex_outlines.png ? ... old hex_grids.png cannot do that.

[LuisGuzman]

I have a little request. Or i would like to ask if it is possible first. And useful for others.
Often (every time ) when i read other people's AAR i would like to take a look at the map of the scenario. To understand what they write about in their AAR.
Is it possible to add the map number of a scenario to the AAR header? Could be a five digit number or five letters for TILED maps.
(It is not very important but i have that idea in my head for quite some time now and thought i ask it)

Not sure how useful it can result when the map is tiled, as you'd need anyway to load the scenario in the Suite to see it.

When the map is a picture it can be added easily ...but where would you like to appear, next to AI stance ?

[mythos]

Hola Luis

Luis, could you please check: hotkey combo <Alt 8> (cycle Grid type) doesn't seem to work.

Sorry Chris that I forgot to reply this question, but I checked and it works for me.
Are you sure you are using hex_outlines.png ? ... old hex_grids.png cannot do that.

No Problem.

This leads to technical questions:
- OG has hex_outlines.png (and hex_grids)
- Efile_GUS has a custom hex_grids.png, but no hex_outlines
it seems the efile's hex_grids is overwriting OG's hex_outlines, why that ?

It also seems that if the efile doesn't have custom outlines/grids, then OG, which has both files, works as i expected = merging both files (or maybe it ignores hex_grids then).
Would it be possible to replicate this behaviour for custom files of efile GUI ? (unless the above note "hex_outlines ignore hex_grids" is true).
Maybe with a $var (i could imagine that current behaviour is expected by efile keepers).

I tried adding OG's hex_outlines to the efile's GUI, but hex_grids still overwrites hex_outlines

[randowe]

I have a little request. Or i would like to ask if it is possible first. And useful for others.
Often (every time ) when i read other people's AAR i would like to take a look at the map of the scenario. To understand what they write about in their AAR.
Is it possible to add the map number of a scenario to the AAR header? Could be a five digit number or five letters for TILED maps.
(It is not very important but i have that idea in my head for quite some time now and thought i ask it)

Not sure how useful it can result when the map is tiled, as you'd need anyway to load the scenario in the Suite to see it.

When the map is a picture it can be added easily ...but where would you like to appear, next to AI stance ?

Yes, next to AI stance would be fine

[LuisGuzman]

I tried adding OG's hex_outlines to the efile's GUI, but hex_grids still overwrites hex_outlines

Yes adding ONLY hex_grids.png doesn't make OG to load it, you need to put also hex_outlines.png to work.

The old UI file: hex_grids.png includes all the outlines (grid, borders, selection), the patterns (movement, fog,...), and all the hex marks (red binoculars, red planes, built markersm ..). It was the UI file for OG versions using DD.

When OG moved to use SDL, "blending" was became possible, and the UI was updated to use solid colors to replace the old patterns (movements, fog and so) and hex_grids.png was splitted in 3 files: hex_blend.png, hex_marks.png and hex_outlines.png.

Then, hex_blends.png has the solid colors to replace old patterns, ex_marks.png has all marks with 3 columns to allow using different icons for each ground conditions, and hex_outlines.png has all the grids and "borders" icons, allowing to select different grids using the hotkey.

The game loads hex_marks.png and hex_outlines.png, ONLY if both files are found, otherwise it loads the old hex_grids.png

Gustlik's efile keeps using hex_grids.png because many of its players are still using the DD version yet, which obviously cannot load the new marks & outlines files.

[mythos]

[Aleksandr]

While designing and testing my new campaign Panthers In The Mud (working title...). I realized that there's an issue with how Suite and OG cooperates considering the Purchase List. I think that this should be discussed, and, if possible, solved.

So, for those who don't know: Purchase list is used when the scenario/campaign designer wants to limit the purchase pool of player for whatever the (un)reason. One of the Suite's sub-options is to tick the "Purchase Unavailable Units" checkmark, which allows to put unavailable units into the purchase pool. This is useful in many cases that you can already imagine. But! While Suite has no troubles with this, Open General has. It won't load any obsolete units into the purchase pool, and now let me cite Luis himself:
"Although you can include an obsolete item in the custom list, it won't be available in game, as when buying, the game creates a list of the items, either from the custom list or the equipment pool, and then (when you select a class to buy) it scans that list to set up the items to show, discarding any item not matching country selector and valid date. So no, you can't purchase and outdated unit by including it in the custom list."

Imho this is wrong, bug even. If the designer wants the item to show up, and Suite even allows it, then OG shouldn't protest and should allow the unit. It's not even consistent, as I realized that you may put an item from different country into the list - tested with Croatian 250/1 put into German pool -, and it will be available and buyable. (Although it'll be a Croatian unit for a while, before it changes nationality to Germans.)

So my proposal is to change the behaviour so that the unavailable units:
- don't show up in Suite's Purchase Pool unless the "Purchase Unavailable Units" option is ticked (just like now)
- do show up in Suite only when the "Purchase Unav. Units" is ticked (just like now)
- can be put into purchase pool, and do show up in Open Gen purchase screen when the "Purchase Unav. Units" is ticked in Suite (bug removal)

This way the option would be functional, useful, and even consistent with how .proto files work.

[LuisGuzman]

While designing and testing my new campaign Panthers In The Mud (working title...). I realized that there's an issue with how Suite and OG cooperates considering the Purchase List. I think that this should be discussed, and, if possible, solved.

So, for those who don't know: Purchase list is used when the scenario/campaign designer wants to limit the purchase pool of player for whatever the (un)reason. One of the Suite's sub-options is to tick the "Purchase Unavailable Units" checkmark, which allows to put unavailable units into the purchase pool. This is useful in many cases that you can already imagine. But! While Suite has no troubles with this, Open General has. It won't load any obsolete units into the purchase pool, and now let me cite Luis himself:
"Although you can include an obsolete item in the custom list, it won't be available in game, as when buying, the game creates a list of the items, either from the custom list or the equipment pool, and then (when you select a class to buy) it scans that list to set up the items to show, discarding any item not matching country selector and valid date. So no, you can't purchase and outdated unit by including it in the custom list."

Imho this is wrong, bug even. If the designer wants the item to show up, and Suite even allows it, then OG shouldn't protest and should allow the unit. It's not even consistent, as I realized that you may put an item from different country into the list - tested with Croatian 250/1 put into German pool -, and it will be available and buyable. (Although it'll be a Croatian unit for a while, before it changes nationality to Germans.)

So my proposal is to change the behaviour so that the unavailable units:
- don't show up in Suite's Purchase Pool unless the "Purchase Unavailable Units" option is ticked (just like now)
- do show up in Suite only when the "Purchase Unav. Units" is ticked (just like now)
- can be put into purchase pool, and do show up in Open Gen purchase screen when the "Purchase Unav. Units" is ticked in Suite (bug removal)

This way the option would be functional, useful, and even consistent with how .proto files work.

I can admit that it looks like a bug, 'cause if designer is allowed to include outdated items the game should allow the players to buy those outdated units.

I'd say it wis worth to consider

[Aleksandr]

Thanks Luis!

Yet another related thing, though a minor one: I think that if a designer moves Foreign unit into a National pool (see my example with Croatian recon above), it should change the flag in purchase screen from Foreign to National; it was moved to National pool so it should wear National flag.
But I don't know how the game would solve this in case there'd be both National and Foreign nations available for purchase. This is really tricky, but then again I got like 48 hours of experiences with the .buy4 files/settings, so maybe this is in fact an easy matter.

[mythos]

I support the "buy unavailable units" proposal.

Yet another related thing, though a minor one: I think that if a designer moves Foreign unit into a National pool (see my example with Croatian recon above), it should change the flag in purchase screen from Foreign to National; it was moved to National pool so it should wear National flag.

I disagree. Some campaigns were designed with original flags for different campaign nations in mind (i.e. many western allies, Sapper's Axis).
If you want foreign units to use the flag of the main nation, there is the option to load the campaign (*) and tick "Set core units to player's main country".


(*) dunno if there is something for stand-alone scenarios

[Aleksandr]

Thanks for support!

Considering the flag change: I of course meant that the units moved to Purchase list should change the flag, because by moving them in, they become a part of that nation's list, and to me it seems logical that they wear the National flag, not the Foreign one. All other units should behave normally... but honestly, I'm kinda lost what does "normally" even mean, coz I forgoteen how the things worked, as I haven't played in a long time. Moreover OG is different from PG2.

It's cool that there's the "Set core units.." option, I somehow missed that. I'm still not sure why the Croats in my above example had Croatian flag while being part of a German pool, and then becoming Germans once I purchased them, but really, this is a small "issue" if any at all.

The obsolete units are much more important, and I really hope that they will be fixed.

[randowe]

The obsolete units are much more important, and I really hope that they will be fixed.

I'd go as far as to say that it should be possible to put every unit (regardless nation, time frame, etc.) from a efile to a purchase list and thus make every unit buyable using that option/list

[mythos]

I of course meant that the units moved to Purchase list should change the flag, because by moving them in, they become a part of that nation's list, and to me it seems logical that they wear the National flag, not the Foreign one.

good question. I currently have no opinion about it.
I understand your idea of having a unit, bought from nation X, using the flag of nation X - no matter its country of origin. It would also be "in line" with default purchase behaviour, which works like this.

It's cool that there's the "Set core units.." option, I somehow missed that. I'm still not sure why the Croats in my above example had Croatian flag while being part of a German pool, and then becoming Germans once I purchased them

That's default purchase behaviour (in campaigns) for the "Set core units..." too:
- you buy unit from support nation Z
- during the scenario played, it keeps the flag of support nation Z
- upon moving to the next scenario, units with flag Z change their flag to that of main nation X

[Aleksandr]

I'd go as far as to say that it should be possible to put every unit (regardless nation, time frame, etc.) from a efile to a purchase list and thus make every unit buyable using that option/list

Yes, of course, this is right!
I should have been more precise. Obsolete units are useful for secondary fronts, reserve armies, desperate situations, etc., while some designers might find it useful to move prototypes into purchase pool so that they work differently, they could allow units a month or two sooner for balance reasons, and such.
It's not even about the units, after all check the glorious 503.cam where there were a few units available, and the limited purchase pool was one of things that made the campaign so cool!

[LuisGuzman]

Updated RC version to 0.93.3.99.RC3
Including:

• Optimized the routine finding map picture file. Existing files in .shp or .bmp format are skipped
• Camouflage expert units were adding air defense to predictions
• Nickname and email for bug-tracker was not saved to Settings.cfg
• When enabling option to enhance hexes having planes when AirMode is active, airfields will be also enhanced

Also the test version (OGX.exe) 0.93.4.16.OGX is also available, to test the change asked to allow outdated units included in .buy file when purchasing units in game.

[randowe]

[*]Camouflage expert units were adding air defense to predictions (jaro)

What does this mean?

[Jaro]

[*]Camouflage expert units were adding air defense to predictions (jaro)

What does this mean?

When checking the odds for attacking the ground unit by your air unit the influence of "hidden" air defense unit with camouflage expert leader (in the spotted hex) was taken into consideration. That means player could figure out that there is invisible air defense unit nearby.

[LuisGuzman]

[*]Camouflage expert units were adding air defense to predictions (jaro)

What does this mean?

That I am getting older and forgot to remove who reported the bug :

[randowe]

[*]Camouflage expert units were adding air defense to predictions (jaro)

What does this mean?

When checking the odds for attacking the ground unit by your air unit the influence of "hidden" air defense unit with camouflage expert leader (in the spotted hex) was taken into consideration. That means player could figure out that there is invisible air defense unit nearby.

Thanks for enlighten me

[Aleksandr]

Nice to read this!

[Aleksandr]

So, I can confirm that the new RC exe works and the Purchase pool/screen bug is removed. Very cool, many thanks Luis for your work!

Now, what is the consensus, if there indeed is any at all, about the National/Foreign units and their flags in the Purchase screen? As explained in my above post about the Croatian-German recon, the units moved into the National pool from a Foreign units' list keep their Foreign flag while appearing in the National purchase lits. I think that this is wrong, as they were moved into the National purchase list and thus they should appear with the new flag. It's a minor issue, and it's not high on anyone's list of priorities I guess, but it's still an interesting thing.

Sidenote: this has nothing to do with secondary country. Those are a different units at all that share nothing with the main country, and they have their own flag, of course. What I'm specifically writing about is when the Purchase pool is set to using the foreign units as one's own.

[randowe]

So, I can confirm that the new RC exe works and the Purchase pool/screen bug is removed. Very cool, many thanks Luis for your work!

Now, what is the consensus, if there indeed is any at all, about the National/Foreign units and their flags in the Purchase screen? As explained in my above post about the Croatian-German recon, the units moved into the National pool from a Foreign units' list keep their Foreign flag while appearing in the National purchase lits. I think that this is wrong, as they were moved into the National purchase list and thus they should appear with the new flag. It's a minor issue, and it's not high on anyone's list of priorities I guess, but it's still an interesting thing.

Sidenote: this has nothing to do with secondary country. Those are a different units at all that share nothing with the main country, and they have their own flag, of course. What I'm specifically writing about is when the Purchase pool is set to using the foreign units as one's own.

I agree with you

[mythos]

Now, what is the consensus, if there indeed is any at all, about the National/Foreign units and their flags in the Purchase screen? As explained in my above post about the Croatian-German recon, the units moved into the National pool from a Foreign units' list keep their Foreign flag while appearing in the National purchase lits. I think that this is wrong, as they were moved into the National purchase list and thus they should appear with the new flag.

Does it change the Flag after the "current" scenario ?
If not it is a bug.
If yes, i guess this was the simplest way of imlementing the "changing Flags" mechanic: upon switch between campaign-scenarios all sorts of data is reloaded/re-called, thus here it is when Flags get updated. Sorry if my explanation is wonky, i don't know (respectively understand) enough about programme mechanics for a cleaner wording

[randowe]

Now, what is the consensus, if there indeed is any at all, about the National/Foreign units and their flags in the Purchase screen? As explained in my above post about the Croatian-German recon, the units moved into the National pool from a Foreign units' list keep their Foreign flag while appearing in the National purchase lits. I think that this is wrong, as they were moved into the National purchase list and thus they should appear with the new flag.

Does it change the Flag after the "current" scenario ?
If not it is a bug.
If yes, i guess this was the simplest way of imlementing the "changing Flags" mechanic: upon switch between campaign-scenarios all sorts of data is reloaded/re-called, thus here it is when Flags get updated. Sorry if my explanation is wonky, i don't know (respectively understand) enough about programme mechanics for a cleaner wording

Aleksandr is talking about units which have been added to a purchase list only. Under normal circumstances they would not appear in the player's purchase screen anyway. But, if you, for example, put a Korean unit to a purchase list for Sweden, the Korean unit should get a Swedish flag. Because the player's main country is Sweden in that case. That has nothing to do with "changing flags mechanics" in a standard game.
That's how i understand Aleksandr and i think it is a good idea (i hope, i didn't get it wrog )

As i said before, in the best case it sould be possible to add every unit of an efile to a purchase list (EDIT: no matter the unit's nation or time frame) and the units should always get get the flag /become a member of the player's main country

[Aleksandr]

Yep, randowe explained it exactly as I meant it.
Obviously the standard purchase of foreign units through secondary country has nothing to do with this, but as randowe wrote:
"As i said before, in the best case it should be possible to add every unit of an efile to a purchase list (EDIT: no matter the unit's nation or time frame) and the units should always get the flag/become a member of the player's main country"

Cheers!

[LuisGuzman]

Sorry but I don't understand the change you are asking for

1.- I took a scenario for Efile_BadeKorp where Germany is the only country for human player (no support countries).
2.- I added a Hungary paratrooper to the scenario custom purchase list (.buy4 file)
3.- When I run the game and go to purchase panel, that Hungary unit show up in the list for Germany
4.- If I purchase it, it is set as Germany, with German flag.

Do you mean that the unit from the custom purchase list should keep the Hungary flag ?

[randowe]

Sorry but I don't understand the change you are asking for

1.- I took a scenario for Efile_BadeKorp where Germany is the only country for human player (no support countries).
2.- I added a Hungary paratrooper to the scenario custom purchase list (.buy4 file)
3.- When I run the game and go to purchase panel, that Hungary unit show up in the list for Germany
4.- If I purchase it, it is set as Germany, with German flag.

Do you mean that the unit from the custom purchase list should keep the Hungary flag ?

German flag is correct. The sequence you describe is exactly what i meant in my post too. Then i don't know which issue Aleksandr encountered

[Aleksandr]

Top right corner of the screenshot: the unit has a Croatian flag although being a part of German purchase list.

[randowe]

I just checked it with a scenario too. Yes, the flag of the original country is shown in the purchase screen.
But when you deploy the units and start the scenario, they get the flag of the main country.