New Wish List for OpenGen / OpenSuite 2023-2024

[none]

it would be needed some change to realize your are upgrading the transport only

The way it worked (back then?) was that if you clicked on a unit on the right pane, available upgrades and transports appeared in the left pane. If you did not select a new unit on the upper list, but only a transport in the lower list, it would just upgrade the transport. (Transports were chosen from those available to that unit.)

In other words, you could upgrade a unit to itself without selecting it in the upper pane, and so you could change transports for exotic/unavailable units.

[LuisGuzman]

The way it worked (back then?) was that if you clicked on a unit on the right pane, available upgrades and transports appeared in the left pane. If you did not select a new unit on the upper list, but only a transport in the lower list, it would just upgrade the transport. (Transports were chosen from those available to that unit.)

In other words, you could upgrade a unit to itself without selecting it in the upper pane, and so you could change transports for exotic/unavailable units.

Yes, that is how I've done, but it looks a bit strange for me.

[LuisGuzman]

Hi Luis,
If it is possible, I would like the report from the editor to be customizeable.
The current report is like a data dump and very cluttered.
For instance, I would display exp, kills and "exp gained" because I don't want to see bars, transports, strength, prestige etc. The summary would also be much the same.

Ideally, a report on each unit would be great. Listing each scenario it fought in and the exp gained and units destroyed etc.
A report of each scenario listing the number of units killed, lost, exp gained, etc and types of units destroyed(16 tanks,etc) would be great.

Something that is really missing is the lack of info on ships.
I would like to see how many subs my destroyer has sunk or how many ships my torpedo bomber has sunk etc.

Hi again Brian

Could you please post or send me by email a sample of the report/s you are thinking ?
I mean taking one of the reports available, edit adding removing you want and send me back the edited report/s to see better what you want.

Regarding info on ships, the problem is that PG2 and OG never tracked individual ship classes' kills, only a the global data summing up all ships classes is stored. I can expand the structure to track every class and thus in future games played with that modified structure will include details of each naval class killed.

[none]

Yes, that is how I've done, but it looks a bit strange for me.

Why? It's a different paradigm, but a pretty simple one:

1. Select the unit to upgrade on the right pane
2. Select what to change in the left panes: Unit types on top, transports on bottom.

That's all.

The only thing which has changed is that before you could only change both aspects (type + transport) at the same time, for which there is actually no reason: In a campaign you change transports often, for instance to adapt to specific scenario conditions (snow).

[none]

Me again.

A nice thing to have would be the possibility to make sub-folders in the /Scenario folder, so you can assemble all files of a given campaign inside its own folder. You would have /Scenario/campaignA/[files], and /Scenario/campaignB/[files], and so on.

This would avoid the current jumble where you have several hundred files belonging to different campaigns (my /Scenario folder currently contains 316 files, representing 3 campaigns...). At some point it becomes hard to find anything, even with strict naming schemes...

[LuisGuzman]

Me again.

A nice thing to have would be the possibility to make sub-folders in the /Scenario folder, so you can assemble all files of a given campaign inside its own folder. You would have /Scenario/campaignA/[files], and /Scenario/campaignB/[files], and so on.

This would avoid the current jumble where you have several hundred files belonging to different campaigns (my /Scenario folder currently contains 316 files, representing 3 campaigns...). At some point it becomes hard to find anything, even with strict naming schemes...

Yes, it would be probably nice for designers ... but irrelevant for players and probably even worse when browsing to load a campaign or scenario.

But the main problem is to implement such option because of the many changes it would require.

The current "game\efile\" is used as the root of all the subfolders used by the game, so all files can be checked, when game need to load them, at a well known place depending its type, once the player has selected a given efile.

Allowing in practice many "scenario" folders would break that game strategy, requiring to add data here and there and change many lines of code, which usually means raising a lot of bugs and making the game unstable.

Actually this simple idea (efile as root of all files used by game) was the key to solve how difficult was to change the efile, and its campaigns & scenarios, to play in PG2.

So I am not keen to even think on such possibility right now, sorry.

[sympatyk]

Do it like a CC campaign --> each campaign is a separate e-file --> You can duplicate the e-file and add only one campaign (marking it appropriately) --> done --> instead of switching between subfolders, you will switch by e-files

[LuisGuzman]

Do it like a CC campaign --> each campaign is a separate e-file --> You can duplicate the e-file and add only one campaign (marking it appropriately) --> done --> instead of switching between subfolders, you will switch by e-files

Then setup the official EFILE_NOKORP merging all SCENARIO campaign folders into EFILE_NOKORP\SCENARIO

[none]

Then setup the official EFILE_NOKORP merging all SCENARIO campaign folders into EFILE_NOKORP\SCENARIO

Not sure I understand you.
I'm not very fond of the 1 Campaign = 1 EFile solution for this use (CC campaigns are special), because an EFile with 10 campaigns would appear in OG as 10 EFiles and you'll never know what campaigns there are, unless you manually switch through all those 10 EFiles. In other words, you lose the list of campaigns to chose from, and that's quite important for players.

The problem of campaign browsing could easily be solved in my suggestion if the campaign files contained paths to their scenario files: You would keep putting all campaign files (.xcam) (only the campaign files) in the "/Scenario" root, and they would point to their respective subfolders. In other words, "/Scenario" would only contain .xcam files and individual campaign folders.
Instead of only "myscenario01.xscn", the "ThisCampaign.xcam" file would reference "/ThisCampaign/myscenario01.xscn".

(And the path to the EFile's "equip.xeqp" file would need to be referenced as always being in "/EFile", instead of ".." like it is now. The game knows which EFile you're using, since it always defaults to that once you've selected it, so I suppose it's easy to retrieve that value.)

Just suggesting. The problem is that campaign management is slightly tedious since an average campaign has over 100 files...


-- Edit:
Could you please look into that bug please? It seriously hinders playing, since it deactivates right-click for many units when there is a plane over them: You can't embark, take a train, resupply, repair...

[LuisGuzman]

Then setup the official EFILE_NOKORP merging all SCENARIO campaign folders into EFILE_NOKORP\SCENARIO

Not sure I understand you.

What I mean is to use the official EFILE_NOKORP including all the campaigns (the official NOKORP available in the installer) and ...
---> another working EFolder EFILE_NONE_W (or whatsoever) including the efile, SAVE and rest of official folders (including SCENARIO) where you should put the campaign you are currently working (so can easily test) and ...
---> as many EFILE_NONE_W\XCAM_$$$ including each campaign you are not currently working in.

So if you want to test another campaign you need only to rename the folders.
When you want to release changes, you only need to update EFILE_NOKORP with the changes.

The problem of campaign browsing could easily be solved in my suggestion if the campaign files contained paths to their scenario files: You would keep putting all campaign files (.xcam) (only the campaign files) in the "/Scenario" root, and they would point to their respective subfolders. In other words, "/Scenario" would only contain .xcam files and individual campaign folders.
Instead of only "myscenario01.xscn", the "ThisCampaign.xcam" file would reference "/ThisCampaign/myscenario01.xscn".

Yes from campaign perspective is easy, but from saves and rest of filenames needing to setup its filename in base to their scenario file (which is the real problem from the game perspective) the problem remain the same.
The game knows (because the save-games include it) the scenario filename (with no suffix) to set up the rest of the filename to check and load.
And save-games store that scenario filename only in a fixed length of chars, so those sub-folders should be limited in their denomination.

Too much work and risk to fix your wish, you should better try the option described before using a def efile-folder

-- Edit:
Could you please look into that bug please? It seriously hinders playing, since it deactivates right-click for many units when there is a plane over them: You can't embark, take a train, resupply, repair...

I could not find any bug. I replied already

[none]

What I mean is [...]

I see. Well, I guess that's what I'll end up doing.

Too much work and risk to fix your wish

Okay, no problem, I thought I'll ask...

I could not find any bug. I replied already

Answered there. I'll give you a savegame when I stumble upon it again. When I first met the problem, the "airplane" button didn't work, I tried everything.

[none]

One of my fighters got a leader, i think it was influence, and i declined it with the new option. After i closed the game i saw a message:

- Err - U:12 is a fighter but got an improper Leader! - Check CombatTest log file

Ok, so i got the aformentioned message when i closed the game. But since i notice this only when i close the game the last combat logged is not the one that raised the message.

- Err - U:67 is a fighter but got an improper Leader! - Check CombatTest log file

Got one of those too: "- Err - U:21 is a fighter but got an improper Leader! - Check CombatTest log file"

Me too only got the message long after the turn it happened, so no log, but said "U:21" is an auxiliary unit, and auxiliaries aren't supposed to get leaders anyway. So "got an improper leader" should actually read "got improperly a leader"...
(For the record, no, it didn't actually get a leader)

BTW, seems this error only happens with fighters...

[LuisGuzman]

Got one of those too: "- Err - U:21 is a fighter but got an improper Leader! - Check CombatTest log file"

Me too only got the message long after the turn it happened, so no log, but said "U:21" is an auxiliary unit, and auxiliaries aren't supposed to get leaders anyway. So "got an improper leader" should actually read "got improperly a leader"...
(For the record, no, it didn't actually get a leader)

BTW, seems this error only happens with fighters...

Yes this error happen(ed) only with fighters and the problem was in the leader class attribute not the random attribute and it was logged regardless core or aux unit and regardless it was really raised.
Actually all planes was assigned "Skilled Assault" class leader

I have it already fixed, but I'm waiting to finish Puma's suggestions about AAR to release RC2b

[none]

I see, thanks.
That been said, my case was a little special, since the offending unit was an auxiliary unit and my equip.cfg has "noldr_auxunits=1"...
No matter what that leader was, it shouldn't have happened at all, isn't it? When does the "noldr_auxunits" check happen? Before, or after the leader attribution?