Quote:Hi,
don't know if it's possible.
I would like a new terrain type: ICE.
Could have the same stats like rough terrain. But if it could be changed by Aty-fire it would be nice.Terrain Ice -> Aty-fire -> terrain impassable river?
The Finns used their heavy coastal artillery batteries for shelling the ice of the Viipuri Bay in early 1940. That caused heavy casualties among the Soviets as you could imagine and built obstacles (as long as the ice did not freeze again).
For my finlandmaps it would be interesting. But also for other snowy maps.
..
it would be also nice if the crushed ice could change backwards to ice after 1/2 turns (like the ice freeze again).
I think Ice terrain is a very good idea - I've added to the wishes list as item #166.
About if AI will be able to use all those features, I am pretty confident Tor will be able to develop a good AI ... either I have not worked so much on GUI development.
I see a big problem making the AI itself and this is awesome Tor is so confident he will do.
So, being able to do this I wonder why he would not be able include those additional features ?
Well maybe I am wrong, but I prefer to belive I'm not.
But if at the end of the project, some of the new features couldn't be available for the AI, I think we still could include them as optional, so those wanting to play fair could disable them and those no worried of that, could enable even if it is a human player advantage.
Anyway those could still be used on PBEM games, though PBEM designers wont be able to test his mods againt the AI ...
This point has been told also at JP's OpenPG2 forum, but my point is to include anything we can and then allow each player to customize the features he wants to play with.
Quote:... and then allow each player to customize the features he wants to play with.
This is the best solution for a single player, no doubt. On the other hand, it makes PBEM more difficult, for both players have of course to use identical options. How could this be checked?
I believe it would be the best solution if all features are in one game for human and artificial and pbem. And not to have some variations of the game.
Thanks for the ice.
Quote:This is the best solution for a single player, no doubt. On the other hand, it makes PBEM more difficult, for both players have of course to use identical options. How could this be checked?
These would be, as other optional features, set by the player who start the PBEM, and then saved into the EML (with no further access), so they will remain the same for the rest of the game. And as any other optional feature they could be set as "standard".
Quote:On the other hand, it makes PBEM more difficult, for both players have of course to use identical options. How could this be checked?
These would be, as other optional features, set by the player who start the PBEM, and then saved into the EML (with no further access) ...
Well, nevertheless each player could start his attacker game with different options. Please keep the mirrored mode in mind. Standard settings (which can be checked) are acceptable.
Quote:Well, nevertheless each player could start his attacker game with different options. Please keep the mirrored mode in mind. Standard settings (which can be checked) are acceptable.
maybe an additional option: "mirrored PBEM-game", so that the second player plays his attacker game directly after playing his defender-game, which keeps all setting.
all online leagues play mirrored PBEM, so it would nice if this would handled by openPG2 directly.
Hi Luis,
yet another idea. For campaign and scenario designers.
It would be interessting to set hex prestige free. Not 40, 80, 160 automatically like it's now. Better would be to set the prestige for a hex like the designer will have it.
For example an early hex only 20pp but a late hex maybe 300 and so on.
Quote:Hi Luis,
yet another idea. For campaign and scenario designers.
It would be interessting to set hex prestige free. Not 40, 80, 160 automatically like it's now. Better would be to set the prestige for a hex like the designer will have it.
For example an early hex only 20pp but a late hex maybe 300 and so on.
Bye, Clu
I like it ... and it would be possible (and simple) if scenario would define just a base pp which would default to 40 of course. This way only a single byte would be needed on scenario file. So if you'd set that base to 30, then hexes will give 30,60 and 120 pp instead of 40,80 and 160 pp. We could think as a kind of prestige modifier for prestige available on map.
Defining pp for each hex would need a new scenario format and it would be a bit boring to define when designing the scenario.
Oh, sorry. I mean only for victory hexes. In your suite there is a box to set only no prestige or automatically. Wouldn't it be possible to set a pp by your own in this square?
But your idea is also very good.
Quote:Oh, sorry. I mean only for victory hexes. In your suite there is a box to set only no prestige or automatically. Wouldn't it be possible to set a pp by your own in this square?
But your idea is also very good.
Clu
Ummm, I replied but it is lost now ?
I'll do again:
Scenario map section defines for each hex (among other info):
- Owner (flag)
- if it is a VH (axis/allied)
- if it is a SH (axis/allied)
- if this hex don't give prestige (avoid prestige bit)
The prestige awarded by any hex is implicitly given depending these data, using 40 as a pp base, so owned hexes gives 1x40 pp; VH/SH/Ports gives 2x40 pp; SH+VH give 2x2x40 pp ... unless hex is set to disable prestige (then it gives 0 pp)
Suite provides a check box to show/set if "avoid prestige bit" is set/reset (hex gives normal prestige or hex doesn't give prestige at all) and shows on buddy texbox the amount of prestige given, but there is no room to store prestige for VH SH or whatever.
So the only choice I can wonder to customize prestige on map is to set a global base pp (defaulting to 40 if no set) using one of the unused bytes in scenario file.
Hi Luis,
sorry for your lost input. Unfortunately this forum sometimes is that nasty.
So if you have typed a longer text rather copy it to the clipboard before previewing it.
As for this discussion:
I think there should be two steps in the OpenPG2 development:
1. Must: all functions available in the UK patch - but not all bugs.
2. Nice to have: anything on the wishlist.
And I think you should not do everything that could be done. Such programs tend to get unmaintainable pretty soon. For instance: I could live without the hex prestige enhancement. 40 or 0 - anything in between is not relevant for the outcome of a battle IMO.
Hi Luis,
i understand. But sometimes you will have to explain. Because i don't understand that much of programming.
So i except your idea. Sounds also good as i wrote earlier.
Rayy: I agree. But some ideas are really nice.
And: It's a wishlist. So why don't wish something. Luis (and Tor) decide what is possible and what not.
Quote:I think there should be two steps in the OpenPG2 development:
1. Must: all functions available in the UK patch - but not all bugs.
2. Nice to have: anything on the wishlist.
And I think you should not do everything that could be done. Such programs tend to get unmaintainable pretty soon. For instance: I could live without the hex prestige enhancement. 40 or 0 - anything in between is not relevant for the outcome of a battle IMO.
The fact I write down new ideas on wishes list doesn't mean we'll finally do. Some of the ideas seem to be easier to make than others and also some ideas need a further discussion as sometimes changing slightly the way it is first explained turns them doable (a kind of "brain storming" method).
But our priority is to do first the functions already available, fixing most bugs (yes some bugs are wanted as they are!). It is also truth that some of the wishes features are easier to include at this point than later - and these are the ones I include on the way - as later they would need a lot of extra work.
IMO, PG2 has so many features than a few more makes no difference on maintenance if they are well structured within the code, and surely including later could be more risky for maintenance.
IMO also, if there were not wishes list or no new features were accepted, nobody were interested on the project right now ...
The critical point is to get some help on improving Combat formula as this is what can make more dramatic changes on game.
What is needed is some experienced players, wanting to make serious testing by recording combat results (forecast and real) on PG2 and on OpenPG2, as to detect how to change the formula in order to get similar results. This is a boring heavy task, as anytime the formula is changed all test must be made again checking the new results. We haven't got anyone engaged yet.
Quote:The critical point is to get some help on improving Combat formula as this is what can make more dramatic changes on game.
What is needed is some experienced players, wanting to make serious testing by recording combat results (forecast and real) on PG2 and on OpenPG2, as to detect how to change the formula in order to get similar results. This is a boring heavy task, as anytime the formula is changed all test must be made again checking the new results. We haven't got anyone engaged yet.
I do not think the forecast formula has to be changed. Of course it is significantly wrong in some cases, but IMO this is realistic. There is always a random factor in warfare.
Quote:The critical point is to get some help on improving Combat formula as this is what can make more dramatic changes on game.
What is needed is some experienced players, wanting to make serious testing by recording combat results (forecast and real) on PG2 and on OpenPG2, as to detect how to change the formula in order to get similar results. This is a boring heavy task, as anytime the formula is changed all test must be made again checking the new results. We haven't got anyone engaged yet.
I do not think the forecast formula has to be changed. Of course it is significantly wrong in some cases, but IMO this is realistic. There is always a random factor in warfare.
I think I've not explained myself. What I mean is:
we don't know what is the combat formula included on current PG2, but we should make a formula on OpenPG2 that will give same results than obtained on current PG2 both for estimated losses and for real casualties.
And that needs some research ... unless we can live with a different formula
Although it is already on the wish list (#53), I would like to emphasize the importance of a decrease in experience whenever a unit is filled up to maximum strength.
I guess the formula was in the PG1 manual (don't have it no more): new exp. = old exp. * (old strength / new strength)
or s.th. like that.
The current PG2 'behavior' is one of the most unrealistic features at all. PG2 programmers should be kicked in their a.. for it! They did have the code for it in PG1 and didn't use it. UNBELIEVABLE!
Even better idea:
The 'new soldiers' should have the same experience as totally new units (defined in turn 40). I leave the formula for this to you.
Hi,
I don't know, whether there's already the following suggestion:
One of PG mistakes is, that you can't enter the last Victroy Hex in a PBEM-match, without quitting the game automatically. This can cause discussions, whether it is necessary to hold some own hexes to win. And if one conquers the hex in the very last turn, one has to make a sreenshot to proof the victory.
Sie sind vermutlich noch nicht im Forum angemeldet - Klicken Sie hier um sich kostenlos anzumelden
Offline
