Quote:luis, in featurelist there are "triggers", thats sounds cool, but at this time only for messages? it would be nice to afford simple missionscripting for scenarios using triggers. so e.g. reinforcements arrive if entering a hex (or VH) or destroying an unit. or opening new DH when enterig a trigger-hex.
Well I wrote the suggestion as it was posted, but I had already in mind to make trigger options more similar to PeG's :
* Scenario defines some hexes as trigger
* Scenario defines max turn to be activated (take the trigger hex)
* Game gives a random bonus (leader, prestige, air missions or improve troops) when taken
Of course those PeG bonus might be changed to something more useful for PG2.
But mission scripting sounds great if not too complicated to do by scenario's designers ... maybe you want to develop a bit he idea ?
Quote:
a global settings-menu, where can set up these options (i thínk, there will come any more) and saved in eml when starting a game, so that the opponent play with these options even if he not avtivated them.
some of these feature maybe would be "standard" in the course of time, so it would be annoying to set up these on every new pbem. and maybe onetimes you forgot one option to set, its angryly.
I quite agree you here, that's the way to go, thank you.
Here's another idea (maybe it is already in the whish list which I don't know by heart, though):
Scenario designers should be able to disband units in a certain turn - so to speak 'reinforcements the other way round'. This would be extremely useful, e.g. for strategic bombing missions limited to the very first turn(s), applicable to scenarios like 'D-Day' or 'Arnhem'. As it is, level bombers remain available for the entire duration of the scenario what it pretty unrealistic.
And another crucial point:
It is great to make an improved PG2 for PBEM only, of course. However, how could scenario / campaign designers test their work vs. the AI, then?
If OpenPG2-based scenarios provide more features, testing (and playing just for fun) with the UK-patch doesn't make sense.
Conclusion: OpenPG2 does need an AI, too.
Quote:it would be a great thing, if OPG2 compressed the eml-files of one match automatically to a zip-file and wrote this one into a choosable directory.
i've got a more better idea
server-based PBEM. anyone have to host a server, and this server will handle the pbem-files (in other words: the raw gamedata) directly. so, a big barrier for new players would be removed, easier handling (no emails needed), and reload-cheats etc would easy prevented.
Quote:But mission scripting sounds great if not too complicated to do by scenario's designers ... maybe you want to develop a bit he idea ?
yes. but it would useful to look at the current code/progress of scenario-handling.
Quote:
it would be a great thing, if OPG2 compressed the eml-files of one match automatically to a zip-file and wrote this one into a choosable directory.
I think it is doable (could be an option to be kept on user's windows registry automatic)
Quote:
Furthermore it should be possible to have savegames of several PBEM-matches in the save-directory without causing crashes (like in original PG2).
What is the problem on saving several PBEM-matches on SAVE folder ?
I guess all matches are saved with a common match prefix and appending some kind of suffix to identify player+turn, isn't ?
Is there any standard convention to name files ?
Do you know what make it crash ?
Quote:
Scenario designers should be able to disband units in a certain turn - so to speak 'reinforcements the other way round'. This would be extremely useful, e.g. for strategic bombing missions limited to the very first turn(s), applicable to scenarios like 'D-Day' or 'Arnhem'. As it is, level bombers remain available for the entire duration of the scenario what it pretty unrealistic.
No "Disband units" was not yet included - I've just done as #163
But at first sight it is not so easy to define, I'll check how it could be done.
Quote:
And another crucial point:
Conclusion: OpenPG2 does need an AI, too.
Yes, but nobody had imagined a new OpenPG2 without a new AI engine
Quote:i've got a more better idea
server-based PBEM. anyone have to host a server, and this server will handle the pbem-files (in other words: the raw gamedata) directly. so, a big barrier for new players would be removed, easier handling (no emails needed), and reload-cheats etc would easy prevented.
I think Tor already had same idea, but not for first release.
Quote:But mission scripting sounds great if not too complicated to do by scenario's designers ... maybe you want to develop a bit he idea ?
...
yes. but it would useful to look at the current code/progress of scenario-handling.
Well but you could start by enumerating the different trigger choices and a general description of the scripts commands. The current progress of scenario-handling code should not affect that.
I think it is better to develop the idea first and then review/set up the data & code needed to allow defining and playing
Quote:
What is the problem on saving several PBEM-matches on SAVE folder ?
Hi,
as far as I know, PG2 doesn't really crash, if there're two or more *.eml-files in the save-directory at the same time. But to my knowledge, this causes problems with the saving of the *.eml-files in a way, that the opponent will get problems with the replay.
However, in all leagues I know, it is strictly forbidden to have more than one *.eml-file in the save-directory at the same time.
Quote:
What is the problem on saving several PBEM-matches on SAVE folder ?
PG2 sometimes seems to merge the data of several EML files, resulting in too large output files (e.g. 80% of contents of input file A + 80% of contents of input file B) which can't be processed anymore. As worse as that: passwords are mixed up -> subsequent player cannot open the turn! It helps to exit PG2 after each turn played, but AFAIK this is no guarantee to prevent that merge.
More info by email; there are some 'classified' ones.
Quote:
PG2 sometimes seems to merge the data of several EML files, resulting in too large output files (e.g. 80% of contents of input file A + 80% of contents of input file B) which can't be processed anymore. As worse as that: passwords are mixed up -> subsequent player cannot open the turn! It helps to exit PG2 after each turn played, but AFAIK this is no guarantee to prevent that merge.
Shocking !
I thought only last enemy turn could be replied ... am I wrong ?
one more idea (more internal than gameplay related) :
a version number represented by a little string. someone of you maybe knows HoI2, there is the program-version shown e.g. as "HGJX".
I think, something like this could be useful in openPG2. this is a simple checksum created with exe-version, panzer.dat and the used EQF, so all data, which must to the be same when playing a pbem, has to included in checksum.
so on EQF-pages like raiders at the mainpage could be written "current PBEM version is 'COOL' ", and if my version is 'LAME', i've made a mistake during installation.
and so this should decrease questions like "why looks my commandos like pussies?" too, i think.
of cource, a PBEM game should have its own checksum, including mapdata and scenario-data, so that its sure that all players have the same version.
Quote:
PG2 sometimes seems to merge the data of several EML files, resulting in too large output files (e.g. 80% of contents of input file A + 80% of contents of input file B) which can't be processed anymore. As worse as that: passwords are mixed up -> subsequent player cannot open the turn! It helps to exit PG2 after each turn played, but AFAIK this is no guarantee to prevent that merge.
Shocking !
I thought only last enemy turn could be replied ... am I wrong ?
Hmmm ... I'm afraid its me who is wrong.
Of course only the most recent turn can be replied to. The file merge rather happens when s.o. reloads a turn and saves again. Password mix-up can definitely be caused by several files in the SAVE folder, though.
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.
Another question.
Some of the new features (if not all) are very exciting. But: Will the AI be smart enough to use them? I believe it is unnecessary to have them when only the human player uses them and the AI not (as now often the AI is not 'clever' enough).
Even if the AI remains as thick as a brick - so what? We're used to it!
And most existing campaigns could no more be won vs. a smart AI.
The crucial point is: all the new features should be available in AI games for testing purposes.
It will be a kind of unfair play when you use something like bridgebuilding and the AI will not because she? is to blind. Won't it?
And of course campaigns musst be overlooked and maybe changed after a complete new game like this will be.
Ice: it would be also nice if the crushed ice could change backwards to ice after 1/2 turns (like the ice freeze again).
Sie sind vermutlich noch nicht im Forum angemeldet - Klicken Sie hier um sich kostenlos anzumelden
Offline
but it would useful to look at the current code/progress of scenario-handling.
