[EDT] Content Editors: Tips & Tricks

[Radoye]

I'm opening this topic on behalf of our friend @Lettos who tells me he has some interesting advice for prospective PGF mapmakers. If other custom content designers have similar information they'd wish to share with others, they're welcome to do so here too. So mostly information on different tools, editors etc and how to use them, and various design tricks one might find useful when making their scenarios / campaigns.

And if our own in-house librarian @HexCode thinks any of this is valuable enough to preserve for posterity, i'm sure he will include it in his great PGF library!

[Lettos]

Thank You, Radoye!

Map resizing option in FPGE. One tip.

Imagine that we have in free usage very large map of very large territory, about 80x80 hexes or even more.
But for new scenario we need only cut a piece from somewhere in this large map. For example, new map size is only 40x50 hexes. In this case we use Map Resize option in FPGE.
Setting smaller values and combining with Offset fields with positive or negative values we can do with map size all what we want. We can resize (increase or decrease) map from one side only or resize simultaneously from all sides to center direction.
But doing this You need keep in mind:
Value in S field (value can be positive or negative) mean resizing of South side of map, value in N field mean changes on North side. It's working correctly.
But values in W(West) field mean more or less tiles on EAST side, and values in field E(East) mean resizing of WEST side. It works good , but in mirror direction

[HexCode]

If ... custom content designers have ... information they'd wish to share with others, they're welcome to do so here. So mostly information on different tools, editors etc and how to use them, and various design tricks one might find useful when making their scenarios / campaigns.

In my opinion, this sort of topic has long been overdue. The "[EDT]" prefix now joins the "[DEV]" ones in a mutually supporting relationship.

1) Such matters are hardly appropriate for an "[EPH]" designation.

2) It will be up to each designer-poster to decide whether a piece of information should be designated and lodged as such as a "[DEV]" or "[EDT]" one. My own rather obvious recommendation is to consider the information's wider applicability potential and decide accordingly.

3) The present topic is ideal for focusing on observations and discussions directly pertinent to the use of content editing utilities.

Note: There's a good chance that some of this topic's contents will be incorporated here:

[VM] Advanced Technical Know-How
viewtopic.php?f=100&t=540

in due course.

Finally, and in my opinion, this is critical, I urge posters to entitle their posts as per the following template suggestion:

[EDT] {followed by a helpful description specific to each post}.

Monotonously repetitive, nondescript titles such as:

Re: [EDT] Custom content design tips & tricks

won't be helping much !

NOW:

The two programmers who successively coded FPGE's many versions did all this, no doubt, out of pure hobbyist interest and dedication. In any case, FPGE's source code is "publicly" accessible.

Having perused FPGE's source code, I've reached some definitive conclusions about the utility as it specifically applies (or not) to PGF:

1) It was coded without a solid understanding of PGF's technical specifications, strengths and weaknesses.

2) It observes many restrictions broadly applicable to PG1-DOS and routinely subjects PGF to those very same restrictions as well; unnecessarily so.

3) By trying to service content playable under too, too many wargame titles via one and the same UI (especially focusing on content conversions), FPGE unfortunately falls short in effectively supporting the editing of content playable under any one such title in particular.

Bottom line: FPGE has quite a few... warts ! To this effect, veteran modders who make use of FPGE are bound to view it as an editing tool of "intermediate stage" usage. Edited content often requires remedial finessing in varying degrees.

[Lettos]

I kindly ask Community to share solutions how to synchronize MAPNAMES file if it edited by two people on desktops.
A simple, offline solution is required.
We have two versions of the same startup MAPNAMES file. Each of the participants in the joint project added dozens of new geographic names to the file. Now you just need to copy all new names from one file to another.
Blocks of new names corresponding to new maps made by each of the project participants are already separated in the MAPNAMES file by empty entries "Name = EMPTY / or RESERVED". Now you just need to copy the results of the work of one of the project participants, visually visible even in a line-by-line file, into a common file.
It is highly desirable that copying is possible not only line by line, but on many lines at once.
Which text editor can I use? I have tested a dozen different free editors, and several trial versions of proprietary editors ... none of the tested works correctly or does not meet the convenience requirements set out above. It is possible that I have not found the correct editor.
Need help!

[HexCode]

Earlier, I wrote:

The present topic is ideal for focusing on observations and discussions directly pertinent to the use of content editing utilities.

SO

I'm afraid you've been barking up the wrong tree (no offense intended, just an Anglo-Saxon idiomatic expression ). MAPNAMES.STR is a binary file. As such, text editors won't do the trick. As far as I know, you have two options:

1) Employ a reasonably capable Hex Editor.

2) Employ Larry Widing's dedicated editing utility, PGSTRED (native to MS Windows 3.1x). Its import and export functionality can be particularly helpful in instances where whole chunks of GLN records need to be replaced or otherwise edited. The utility can handle up to a maximum of 8,188 GLN records.

By the way, I recommend that you take a look here:

MAPNAMES.STR
viewtopic.php?f=100&t=550#p9029

[Lettos]

I tried FlexHex editor now.
I copied all strings from my working MAPNAMES-NEW file to existing MAPNAMES-ORIGINAL. Checked all "double-zeroes" before and after copied text, looks identical. File size is identical, 47002 bytes. I copied edited MAPNAMES-ORIGINAL to my working scenario folder. Renamed to MAPNAMES. Extension is .STR. But FPGE can't see any new names. How can I describe that is wrong here? I don't know now.

[Lettos]

I'm afraid you've been barking up the wrong tree (no offense intended, just an Anglo-Saxon idiomatic expression ). MAPNAMES.STR is a binary file. As such, text editors won't do the trick. As far as I know, you have two options:

1) Employ a reasonably capable Hex Editor.

2) Employ Larry Widing's dedicated editing utility, PGSTRED (native to MS Windows 3.1x). Its import and export functionality can be particularly helpful in instances where whole chunks of GLN records need to be replaced or otherwise edited. The utility can handle up to a maximum of 8,188 GLN records.

By the way, I recommend that you take a look here:

MAPNAMES.STR
viewtopic.php?f=100&t=550#p9029

I looked several times ... For me it is a little complicated written there ... anyway, thanks for help, Hexcode!
I found the documentation that accompanied the good old STREDIT. It is easier for me to understand a topic if it is explained with an illustrative example. In other words, the features of my personal subjective process of understanding. But do not focus on this.

Documentation said:

"The values at offsets 0 and 1 have a special meaning and must be read together. The value at offset 0 is 74 and that at offset 1 is 04. In base ten terms, hexadecimal 0474 translates to 1140. This means that the file contains precisely 1140 geographical name strings, each 20 bytes long. Therefore, 1140 times 20 equals 22800. Add 2 bytes corresponding to offsets 0 and 1 and the result is 22802 bytes which, of course, is the MAPNAMES.STR file size."

Many thanks to this README author Panos Stoucas!

The barking dogs led me as a hunter on the right track. I apologize for not being able to immediately clearly and correctly formulate what exactly I needed. Now I see that a product like this exists:
http://www.editpadpro.com/download.html#trial

You can switch file view between HEX, HEX+ASCII and ASCII only! It looks almost as usual text editor but keeping all Hex editor features!
It is very convenient to copy here large fragments of text. Names are clearly visible on the screen, and code is copied automatically.
We can replace now the previously reserved "empty" names with new, real ones. For example, one map designer is reserved names from 3000 up to 3999, another works in range 4000-4999 etc.

And the last thing that is required for the edited file.
If we need to add new lines, I figured out how to do it! We know the number of added rows, STREDIT lets us see it. Add this number to the existing names + 1 per zero service line (first two bytes + 18 empty bytes).
We use any calculator to convert a decimal number to hexadecimal.
For example, new file contain 2702 names. 2702+1 = 2703 = 0A 8F.
We need to replace two first bytes with new ones but in offset: 8F 0A.

And the problem of coordinating work in the MAPNAMES file is solved.

[Lettos]

FPGE has an excellent and very useful "generate road layer" option.
ALT + R - look at road layer
CTRL + Q - Generate Road Layer

But if new custom tiles with roads are used on the created map, then FPGE, when pressing CTRL + Q, does not understand what to do with custom tiles, and simply erases all roads from them.

Tip:
when creating new maps with custom road tiles, all the standard roads must be placed first. Make road layer by pressing CTRL + Q.
And only after that you can create roads on each custom tile, editing each such tile manually.

[HexCode]

When Panos Stoucas wrote:

The values at offsets 0 and 1 have a special meaning and must be read together. The value at offset 0 is 74 and that at offset 1 is 04. In base ten terms, hexadecimal 0474 translates to 1140. This means that the file contains precisely 1140 geographical name strings, each 20 bytes long. Therefore, 1140 times 20 equals 22800. Add 2 bytes corresponding to offsets 0 and 1 and the result is 22802 bytes which, of course, is the MAPNAMES.STR file size.

he was talking about PG1 / AG. Unfortunately, FPGE was also coded to religiously observe the above quoted requirements without making any distinctions. In reality, PGF's engine doesn't care about the values of those two bytes... All it cares about are the sequentially placed, GLN records where there are TWENTY (20) bytes reserved for each such GLN record.

STREDIT lets us see it

STREDIT is a 1st generation editing utility native to MS-DOS. PGSTRED is a 2nd generation editing utility native to MS-Windows 3.1x. In my opinion, PGSTRED is way user friendlier and versatile than STREDIT. Of course, a user must be able to run programs native to MS-Windows 3.1x on a modern computer. This is accomplished by installing / placing MS-Windows 3.1x within DOSBOX / D*FEND RELOADED. In any case, regarding the two bytes, both STREDIT and PGSTRED religiously observe the PG1 / AG requirements.

[Lettos]

Suppose I want to make a scenario in which one turn = 1 hour. That is, 24 turns per day.
Alas, as it turns out, the minimum time step in PGF is 2 hours.
The each morning always starts at 08:00. Before 24:00, we have only 8 turns before 24:00.
This is the legacy of PG1.

What would happen, though, if one day equaled 24 turns in the scenario?
In PG1 you will see times like this (two screenshots from PG1)
And at turn 25, the day will finally change to the next day.
PG1 is stable, and allows you to do tricks like this:


But PGF, after showing, for example, 26:00 or 32:00, can switch to the next day, but sooner or later crashes. If the crash does not happen on the second 24 hours, it will happen on the third.

[B29]

I would like to add a few tiles adapted from Pacific General to the map sheet. Obviously I can't create whole new terrain types but I think existing terrain types could be adapted to work i.e. jungle=forest, desert oasis=swamp, small one-hex lake =ocean, etc. How do I assign those terrain values to the map sheets?

[Radoye]

You don't.

You can add as many terrain tile images as you'd like. The underlying terrain is completely independent from the image on top of it - you can have an airfield terrain that looks like ocean, or a desert that looks like a city. You set your terrain to whatever you need it to be, then assign any visual representation that you'd like to go with it. It's actually very easy.



(If you're still unclear about this, i can elaborate; and i'm sure there's already something written about this in our friend HexCode's PGF tech library too!)

[HexCode]

Technical Facts

1) Under PG1-DOS, all map terrain tiles reside within multi-image file TACMAP.SHP.

2) Under PGF, all map terrain tiles reside within multi-image "sibling" files TACMAP_DRY.BMP, TACMAP_FROZEN.BMP & TACMAP_MUDDY.BMP.

3) PGF / FPGE feature a functionality with which one can convert the images contained in file TACMAP.SHP to the corresponding images to be hosted by the three "sibling" files mentioned under preceding point (2) in one fell swoop.

Technical Question

If one were to design a brand, new map tile specifically targeting file TACMAP_DRY.BMP for inclusion, does FPGE allow one to somehow generate the corresponding new images to be hosted by files TACMAP_FROZEN.BMP & TACMAP_MUDDY.BMP ?

[Radoye]

Technical Question

If one were to design a brand, new map tile specifically targeting file TACMAP_DRY.BMP for inclusion, does FPGE allow one to somehow generate the corresponding new images to be hosted by files TACMAP_FROZEN.BMP & TACMAP_MUDDY.BMP ?

Never tried such a thing, but then again using GIMP or some similar free image editing tool it's not too hard to do this manually. So it never occurred to me to try it from FPGE.

FPGE is a great tool for many things and i find it very useful to accomplish stuff i can't do otherwise but still it is now showing its age and i find the user interface somewhat counter-intuitive. I prefer to do as much as possible outside of FPGE - in spreadsheet, plain text and hex editors.

[B29]

You don't.

You can add as many terrain tile images as you'd like. The underlying terrain is completely independent from the image on top of it - you can have an airfield terrain that looks like ocean, or a desert that looks like a city. You set your terrain to whatever you need it to be, then assign any visual representation that you'd like to go with it. It's actually very easy.



(If you're still unclear about this, i can elaborate; and i'm sure there's already something written about this in our friend HexCode's PGF tech library too!)

Yeah unclear, but let me explain more of what I'm trying to do and how I understand (or perhaps misunderstand) how this works.

If I have a map open in FPGE and I wish to add a tile like a fortification for example, I click the Tiles button and pick a fort tile and place it on the map. When I check Terrain Type from the View menu, it displays the numerical values for all of the terrain types on the map. The fort hex will show as "0" which is "Clear". If I save and open the scenario in the game and hover my mouse over that hex it shows "clear" and functionally it is clear, that is until I go to the Tools menu in FPGE, select Generate Layers and select Terrain Type ID's and Simple Names. Only then will it become a fort hex functionally-speaking and display the correct name. To check it, under the View Terrain Types option, that fort hex will now display as "25" instead of "0" and when I hover my mouse over it in game it will show as "fortification".

Why? I think it's because Rudankort has the terrain types associated with particular coordinates on the BMP map sheets. I mean how else would the Generate Terrain Type Layer tool be able to recognize that the fort tile is supposed to become 25?

I know that the graphical tiles can be replaced, McGuba's map mod proves it, but I don't wish to replace existing tiles, I want to add entirely new tiles to the blank areas on the map sheet, then place these new tiles on a map, and when I run the Generate Layers tool for Terrain Type ID's, I want it to assign certain Terrain Type values to each of them.

[Radoye]

I understand what you are trying to do, to have more terrain graphics tiles added.

The terrain graphics tiles have nothing to do with the underlying terrain type on the map. The two are entirely separate things. There is no connection between one and the other in the scenario map files (.SET and .STM) which are entirely inherited from PG(DOS) and have nothing to do with Rudankort.

There appears to be some kind of a mapping between terrain types and terrain graphics tiles within PGF, where for (some? all?) default PG terrain tiles when they're picked by user the FPGE editor auto-picks the "correct" underlying terrain type. But this can be manually overridden, you can pick and place a Desert tile and set the underlying terrain to Ocean and in the game this hex would look like a desert but behave like ocean with ships being able to enter it. As far as the game engine is concerned, it does not care what the tile looks like or which of the existing tiles is being picked - it is the underlying terrain type that dictates how the hex behaves in the game.

You can freely add terrain graphics tiles (in fact, i am currently working with terrain tile files which contain about twice as many tiles as the default ones - mountain and forest roads, rivers through swamps, extra wide major rivers...) and you can use these in FPGE to make maps, but you will have to be careful to manually pick the correct underlying terrain type for each ('Type' field in the TERR popup menu in FPGE).

See these two posts for additional detail:

1. viewtopic.php?f=100&t=545#p9030

PGF's engine is "interested" in TIR* descriptors for visual display purposes only. Such descriptors play no role whatsoever in the way PGF's underlying play system is being "policed" by the engine.

*) TIR = Terrain Iconic Representation or "terrain tile"

In the TERR popup menu in FPGE the terrain tile ID can be manually set with the 'Tile#' field.

2. viewtopic.php?f=100&t=550#p9031

Here's a list of all terrain type codes that exist in PGF - all 39 of them, including a lot of repetition (only 18 unique entries). At the same time, there are some 238 terrain graphics tiles in the default BMP files. As i said there is no direct correlation between the two.

Hope this clarifies things - once you "get" it it actually isn't so complicated, it is much harder to explain than to use it

(Or it might be just me being horrible at explaining things )

[B29]

No, this is really helpful, thank you.

But this can be manually overridden, you can pick and place a Desert tile and set the underlying terrain to Ocean and in the game this hex would look like a desert but behave like ocean with ships being able to enter it.

You can freely add terrain graphics tiles (in fact, i am currently working with terrain tile files which contain about twice as many tiles as the default ones - mountain and forest roads, rivers through swamps, extra wide major rivers...) and you can use these in FPGE to make maps, but you will have to be careful to manually pick the correct underlying terrain type for each ('Type' field in the TERR popup menu in FPGE).

Okay so the way to do this is within the TERR menu (?) —which I've only ever used for naming cities or other features, I have no idea what the rest of it means or how to use it. So how exactly do I do it? Can you give an example?

And if I run the Terrain Type Layer tool afterward, will it undo these individual edits?

A more extensive set would be fantastic, Radoye, looking forward to that! Especially if there's more options for coast tiles and port tiles —particularly ones which are more visually horizontal or vertical connections. Building an accurate coastline is a headache without them.

[HexCode]

General Assessment

FPGE is a great tool for many things and i find it very useful to accomplish stuff i can't do otherwise but still it is now showing its age and i find the user interface somewhat counter-intuitive. I prefer to do as much as possible outside of FPGE - in spreadsheet, plain text and hex editors.

Bang on ! The bottom half of post

[EDT] Covering All Angles
viewtopic.php?f=95&t=579#p9471

expands on the above.

FPGE's Automatism: Current Example

There appears to be some kind of a mapping between terrain types and terrain graphics tiles within PGF, where for (some? all?) default PG terrain tiles when they're picked by user the FPGE editor auto-picks the "correct" underlying terrain type.

Yes ! Absolutely ! This approach dates back to David Smid's map editor (mid-1990s). In addition, FPGE's automatism includes invoking default alphanumeric descriptors residing in file MAPNAMES.STR.

Inevitable Conclusion

Bottom line is this. FPGE has been programmed to asist modding ventures entailing light to somewhat moderate deviations from PGF-SSI's content "traditions". Once one enters PGF-CDP territory, FPGE's output should always be viewed as provisional. To this effect, remedial editing is invariably required to finish the requisite job. Unfortunately, oftentimes, such remedial work presupposes that the modder possesses rather significant, technical "nuts & bolts" knowledge; hence, PGF Online Library's practical utility !

[Radoye]

Okay so the way to do this is within the TERR menu (?) —which I've only ever used for naming cities or other features, I have no idea what the rest of it means or how to use it. So how exactly do I do it? Can you give an example?

And if I run the Terrain Type Layer tool afterward, will it undo these individual edits?

It's the "set to" section near the mouse pointer... You enter values there manually and can select any combo of terrain graphics tile (in this case #230, which represents a coastal tile), underlying terrain type (26, Fortification), you can assign a name (Narew River), road connections (8, to Southeast)...

I can't say if running the Terrain Type layer tool will undo these manual changes or not, but in general it is best to first run all your automatic tools and then start manual fine-tuning.

And save often, backing up the last working version of the file. It's easier to recover the last 1/2 hr of work than the last couple of weeks.

A more extensive set would be fantastic, Radoye, looking forward to that!

This was actually done by our friend Lettos, who also allowed me to use some of his maps for my mod, so all credit goes to him!

[B29]

Ahhh... it's the first column. Last night I tried the second "match" and it did zilch. Thank you so much, this is great!

And save often, backing up the last working version of the file. It's easier to recover the last 1/2 hr of work than the last couple of weeks.

Always good advice, something old paK88 stressed often for making PacGen maps.

Next question — how (as a designer, not player) do I rename units? If I plop a Hipper-class CA down, how do I rename it to "Prinz Eugen"? Is this possible?

[HexCode]

... how (as a designer, not player) do I rename units?

This is bona fide PGF-SSI territory. No dedicated editing tool is required. PGF Online Library posts

EQUIPMENT.PGEQP (Section 00)
viewtopic.php?f=100&t=678#p11933

EQUIPMENT.PGEQP (Unit Type ID, Name & Class)
viewtopic.php?f=100&t=678#p12174

excruciatingly detail what needs to be done, how, some inherent limitations, and potential editing pitfalls to avoid. For all practical purposes, MS Notepad is your friend.

P.S. By the way, what do you mean by the verb "plop down" ? What's the precise context here ? Some PacGen feature which may not be present in PGF, perhaps ?

[Radoye]

Next question — how (as a designer, not player) do I rename units? If I plop a Hipper-class CA down, how do I rename it to "Prinz Eugen"? Is this possible?

I don't think this is possible in the same way it is in PacGen... If you follow the method suggested by our fried HexCode and change the name at eqp file level every Hipper-class will be renamed Prinz Eugen. Which is not what you're trying to achieve, if i understand correctly.

Unless you get into unit cloning and have separate copies of the same unit for every ship in a class in your eqp file, i don't think it can be done.

[B29]

P.S. By the way, what do you mean by the verb "plop down" ? What's the precise context here ? Some PacGen feature which may not be present in PGF, perhaps ?

From the context of scenario design or editing, it means adding a new unit to the scenario in FPGE, or manually in Notepad.

I don't think this is possible in the same way it is in PacGen... If you follow the method suggested by our fried HexCode and change the name at eqp file level every Hipper-class will be renamed Prinz Eugen. Which is not what you're trying to achieve, if i understand correctly.

Unless you get into unit cloning and have separate copies of the same unit for every ship in a class in your eqp file, i don't think it can be done.

Bummer. Yeah, that's exactly what I mean, hoping for some hidden way of replicating what the renaming button does in PacGen's Battle Generator. And naturally, I'm tantalized by the fact that I can hit Alt + N and rename a unit in the PGF game, though I suspect that info is just for the PGSAV file?

I have already done a little bit of cloning. As you know, there are a few individual icons on the AGW sheet for specific vessels which share the same ship class (e.g. Scharnhorst and Gneisenau) and I went ahead and added each one to my e-roster since I'm simply rebuilding AG and PG campaigns (with a few custom scenarios thrown in), and having a few specific ships adds flavor, but building full navies has been low priority and not something I want to do without a naval engine. Yet as I'm dusting off old PacGen folders and looking at Z-Plan and EWR maps lately...I was starting to have other ideas.

It would be nice to rename other units as well — "Fort Eben Emael" in Low Countries, "101st Airborne" para inf at Bastogne, Ardennes, etc.

[HexCode]

Preamble

Perhaps the earliest manifestations of PGF-CDP... adventurism go back to modding PG1 / AG terrain. The early realization that terrain visuals are technically unrelated to the relevant play system properties and behaviors opened diverse, creative custom content design avenues.

There're are two key, prescriptive considerations here:

1) Terrain visuals must be symbolically effective. Just by looking at the map, a player must be able to fully and accurately anticipate all relevant play system properties and behaviors.

2) The underlying terrain core specification (i.e., UTRs and URRs) must be precisely calibrated to allow / enable the intended, relevant play system properties and behaviors while, at the same time, prohibit undesirable such properties and behaviors.

Recent Example

Elsewhere in THIS forum...

I think there is a way to outwit the game if needed! For example it's possible to set terrain type to 'River' for desired hexes in the STM file without changing the tiles for the same hexes in the SET file. Then, these hexes will have a river's properties but look as an ocean...

The idea works well!

1. Save Map*.set in a separate folder.
2. Open a scenario in the PGF editor.
3. Choose any of 'River' tiles and change the desired 'Ocean' hexes on the map.
4. Then: Go to Tools->Generate layers->Terrain type IDs (check box)->'Generate' button
5. Save the scenario.
6. Now put the old Map*.set back to the campaign folder.

That's all! Now pontoon bridges through 'Ocean' hexes work! The procedure takes a few minutes...

Brief, Illustrative Commentary

Is the preceding terrain construct symbolically effective ? Not necessarily. I mean, what if, in the situational absence of a pontoon bridge unit, a player gets the impression that the "Ocean" hexes can readily accommodate the entry / passage of naval units ? Of course, ultimately, it all depends on the scenario's particulars.

[HexCode]

Preamble

Earlier under this topic, I opined:

1) [FPGE] was coded without a solid understanding of PGF's technical specifications, strengths and weaknesses.

2) [FPGE] observes many restrictions broadly applicable to PG1-DOS and routinely subjects PGF to those very same restrictions as well; unnecessarily so.

FPGE's latest "publicly" available version is 0.7.5.10543.

Filename Neatness
viewtopic.php?f=100&t=535#p8924

details PGF's most welcome versatility when it comes to filename choices. Unfortunately, FPGE is rather stilted by comparison...

In FPGE, each scenario is specified via a triplet of companion files:

*.PGSCN
MAP*.SET
*.STM

The * values are NOT necessarily identical across the file triplet.

FPGE: Files *.PGSCN

Fileroot * must be in the format nnnn, spanning the integer range [0,9999] and subject to the following additional restrictions:

--- Specifications 0, 00, 000 and 0000 are NOT allowed.

--- Format n is NOT allowed. 00n should be used instead (i.e., two leading zeroes).

--- Format nn is NOT allowed. 0nn should be used instead (i.e., one leading zero).

--- Format 0nnn is NOT allowed. nnn should be used instead (i.e., no leading zeroes).

FPGE: Files MAP*.SET

Fileroot MAP* must be in the format MAPnnnn, spanning the "integer" range [MAP0,MAP9999] and subject to the following additional restrictions:

--- Specifications MAP0, MAP00, MAP000 and MAP0000 are NOT allowed.

--- Format MAPn is NOT allowed. MAP0n should be used instead (i.e., one leading zero).

--- Format MAP0nn is NOT allowed. MAPnn should be used instead (i.e., no leading zeroes).

--- Format MAP0nnn is NOT allowed. MAPnnn should be used instead (i.e., no leading zeroes).

The desired filename should be specified within its companion text file *.PGSCN (variable "SET file" value).

FPGE: Files *.STM

FPGE is quite permissive here ! The desired filename should be specified within its companion binary file MAP*.SET, always starting at decimal offset 48.

[HexCode]

Map Tiles

From time to time, the issue of enriching PGF files TACMAP_DRY, TACMAP_FROZEN & TACMAP_MUDDY with additional images surfaces during discussions in THIS PGF forum. Such custom map tiles are bound to be judged on the basis of subjective, symbolic effectiveness and aesthetics criteria. HOWEVER, the important fact to be internalized here is that these custom icons leave PGF's play system behavior completely unmolested. In other words, they're all about looks and nothing else...

Custom Map Underlying Terrain Representations

To the extent that some ambitious designer wishes to introduce new map terrain types fully intended to somewhat alter PGF's play system behavior, he should understand that such endeavors fall squarely within the confines of PGF-CDP territory. Specifically:

1) For starters, he must most certainly internalize the basic technical knowledge contained in PGF Online Library's posts

Underlying Terrain Representations
viewtopic.php?f=100&t=550#p9031

*.STM
viewtopic.php?f=100&t=550#p9032

2) He should also internalize the advanced technical knowledge contained in PGF Online Library's posts

Terrain Base Entrenchment Level Table
viewtopic.php?f=100&t=551#p9045

Terrain Initiative Cap Table
viewtopic.php?f=100&t=551#p9047

UTR-to-ATT Cross-Table
viewtopic.php?f=100&t=551#p9041

SO, YEAH

Hex-editing PGFOREVER.EXE lies at the heart of PGF-CDP territory... FPGE is certainly helpful. Nevertheless, a capable hex editor is invaluable.

[Lettos]

Elsewhere in THIS forum...

I think there is a way to outwit the game if needed! For example it's possible to set terrain type to 'River' for desired hexes in the STM file without changing the tiles for the same hexes in the SET file. Then, these hexes will have a river's properties but look as an ocean...

The idea works well!

1. Save Map*.set in a separate folder.
2. Open a scenario in the PGF editor.
3. Choose any of 'River' tiles and change the desired 'Ocean' hexes on the map.
4. Then: Go to Tools->Generate layers->Terrain type IDs (check box)->'Generate' button
5. Save the scenario.
6. Now put the old Map*.set back to the campaign folder.

That's all! Now pontoon bridges through 'Ocean' hexes work! The procedure takes a few minutes...

Brief, Illustrative Commentary

Is the preceding terrain construct symbolically effective ? Not necessarily. I mean, what if, in the situational absence of a pontoon bridge unit, a player gets the impression that the "Ocean" hexes can readily accommodate the entry / passage of naval units ? Of course, ultimately, it all depends on the scenario's particulars.

Absolutely right! You can't just change the Terrain type of a hex and mislead the player!
What is required here is a complete solution consisting of:
- new tile icon
- a change in the MVT Table for Naval Class to allow movement on rivers
- To avoid seeing a battleship on the Rhine near Frankfurt, block the river mouth with terrain type "35"Escarpment. The fact that this hex will not be available to Naval units is unlikely to change much on the battlefield.

This complex solution can also be used for:
- creating river units (monitors).
- creating naval (or ocean or river) units with Bridging capability

By the way, Bridging units can be lined up in a chain and used as a bridge (ferry, transport route). The first practical scenario application that comes to mind is the Husky scenario, crossing the Strait of Messina.

An example can be seen on screenshot.

[HexCode]

Lettos,

FPGE scenario editor has a limit of 20 VH in a scenario. PGF does not seem to have a limit. At least 26 VH does not cause PGF crash. In FPGE, if there are more than 20 VH in the scenario, clicking on VICT causes the program crash. If the VICT button is not touched and the scenario is re-saved, FPGE will reduce the number of VHs to 20 on its own. Therefore, editing more than 20 VHs should be done only in a text editor. Nothing complicated - just write down the cities we want to make VHs and add them to the list of VHs.

PG1-DOS does limit the number of Objective Hexes to a maximum of twenty (20). PGF does not. I was under the impression that FPGE's second programmer of record did modify the code to remove the above restriction. On second thought, that's what usually happens when a support utility programmer attempts to service more than one wargame title via one and the same editor...

Relatedly,

[EPH] Direct & Inverse Proportionalities...
viewtopic.php?f=95&t=174&start=250#p17536

[Lettos]

On second thought, that's what happens when a support utility programmer attempts to service more than one wargame title via one and the same editor...

Of course it is! More VHs would require changes to the interface. And in general, the solution met the requirements back in the day. And nobody set such tasks then as they do now.

[Lettos]

Transferred from
[DEV] Historical Content Representation - Pilot Projects
viewtopic.php?f=95&t=467&start=200#p18255

I think the "All-Terrain" movement type name has been unfortunately chosen. I take it as "All-Wheel-Drive" as opposed to "2-Wheel-Drive" for "Wheeled".

(I know, i'm not 100% consistent with that, but there should be some allowance for modder liberty! )

I'm all for it!

But in this case unlimited modders liberty is strictly limited by the number of possible letters in the name. Name can be shorter than existing but can't be longer as maximum letters quantity.

Experiments with exe file give the following info:

Names have the number of letters "in quotes" (maximum possible number in brackets):

Half-trk = "8" (maximum possible +1 = 9)
Amtrac = "6" (7)
Seep = "4" (5)
---
All-trn = "7" (7)
Track = "5" (5)
Leg = "3" (3)
Wheel = "5" (5)
Towed = "5" (5)
Mount = "5" (5)
Air = "3" (3)
Naval = "5" (5)
======================

Therefore possible changes in All-trn case is only seven letters.
Options: AllWhDr, A-W-Dr, A-W-D, All-W-D, A-Wh-Dr etc.

[Radoye]

AWD is a common abbreviation used in automotive industry for all-wheel drive. It is probably not accurate for 1940's time period but that's no big deal IMHO.

[Lettos]

AWD is a common abbreviation used in automotive industry for all-wheel drive. It is probably not accurate for 1940's time period but that's no big deal IMHO.

"OffRoad" ?

[Radoye]

AWD is a common abbreviation used in automotive industry for all-wheel drive. It is probably not accurate for 1940's time period but that's no big deal IMHO.

"OffRoad" ?

Sounds OK to me, i guess it is a matter of personal taste first and foremost...

[HexCode]

Elsewhere in THIS forum:

I've tried setting quite difficult win conditions in the pgscn file, using FPGE, and without it. I can tell from the negative results that FPGE handles win conditions different from the simple "All VH" so incorrectly that it cannot be relied upon. For example, in the pgscn file after saving, I see the two sides as ALLIED. If I edit the pgscn file, does the whole job end there? Doesn't the new win condition information need to be put into the .STM files? In tests, I haven't seen any difference in AI behavior from me putting something new about winning into pgscn.

FPGE isn't the "great helper" many "modders-lite" have claimed it to be. It's beta software reflecting its last programmer's of record personal hobby interests which have absolutely nothing to do with PGF-CDP...

1) *.STM & *.SET files have nothing to do with Outcome Conditions (OCs).

2) FPGE is known to... mangle "things" here; hence, the need to manually edit *.PGSCN files.

3) I doubt very much OCs influence the AI Module's behavior...

[Lettos]

1) *.STM & *.SET files have nothing to do with Outcome Conditions (OCs).

2) FPGE is known to... mangle "things" here; hence, the need to manually edit *.PGSCN files.

All right, then!

It turns out that complex victory conditions (with mandatory VH) should be prescribed last, and the scenario should not be resaved in FPGE again.
The same goes for Supply hex - I don't think FPGE understands it at all. Otherwise, there were crashes and serious glitches with the STM file.

3) I doubt very much OCs influence the AI Module's behavior...

There was the idea of directing his offense to certain VHs by specifying Mandatory VHs in win conditions. And I didn't notice that the AI understood this command.

[HexCode]

Elsewhere in THIS forum:

FPGE replaces negative SFP values with a standard blank value when saving a scenario.

Even in the case of PGF-SSI styled modding, FPGE is highly problematic. In particular, FPGE often turns files *.PGSCN into unpredictable... garbage. Now, when it comes to PGF-CDP styled modding, FPGE is essentially useless, even harmful !

[Lettos]

Elsewhere in THIS forum:

FPGE replaces negative SFP values with a standard blank value when saving a scenario.

Even in the case of PGF-SSI styled modding, FPGE is highly problematic. In particular, FPGE often turns files *.PGSCN into unpredictable... garbage. Now, when it comes to PGF-CDP styled modding, FPGE is essentially useless, even harmful !

Yes, FPGE is made in the days when standards were ... how shall I put it? - standard. FPGE can't handle the new non-standard situations.
- Negative starting fuel value is erased by resaving;
- reduced AMMO and FUEL starting values will be turned back into blank (i.e. Listed) values by FPGE when the unit's location is changed;
- in unit parameters shows negative Listed Fuel as "256 minus listed Fuel value"

[Lettos]

Coastal artillery batteries are quite difficult to model in a program that does not distinguish between terrain types in terms of spotting at all.

1. Batteries varied in terms of sector of fire. Some could fire in all directions, and some could fire only towards the sea.
Examples of batteries with a firing sector of 0-360 degrees:
Battery Castillitos near Cartagena, Spain

Batteri in Mäkiluoto, Finland
https://www.jaegerplatoon.net/COASTAL_ARTILLERY3.htm


A battery with a narrow sector of fire: https://en.wikipedia.org/wiki/Todt_Battery


2. Spotting toward the sea at the battery was much more than spotting toward land. The battery itself was mounted on an elevated point.
Example: Breakneck Battery https://en.wikipedia.org/wiki/Breakneck_Battery
Elevation more than 300 meters above sea level.


And, if possible, organize an observation and fire correction post at a higher point than the battery location. This means spotting towards the sea 40-70 kilometers away. This is definitely at least equal to the fire range of a battery of 280-305-381 mm caliber.

What can be done?

1. Batteries with a 360 degree firing sector should have significant SA/HA parameters. About NA it is already clear that all batteries have it.
Batteries with a narrow sector of fire towards the sea logically have SA/HA=0.

2. Fire range - same as Capital ships equal calibers. If Battleship have Fire range = 5, coastal battery used same guns should have Fire range = Battleship.

3. Spotting.
You don't want to give the battery a chance to look far offshore. Its eyes are normal army units that report information about enemy land targets (provide spotting zone on land). Therefore, the battery's own spotting = 1 (maximum 2).
At sea, on the other hand, the battery needs to see far away. By the way, observers will see far away not only in the sea, but also in the air above the sea. Very logical.
That's easy to do with a trick explained on shown in the image below:



Island units are placed in the sea. Their parameters GD/AD = 99, others = 0. Class - let's say Fort, target type - land.
Spotting of such islands is 2, 3, 4 depending on the island model.

Real experiments in introducing such islands into scenarios on different coastal lines give clear confidence that it is possible to locate the islands on the map such that the battery gets a full spotting area towards the sea. In the picture above, spotting to the land side is marked with red marks.

For example, for a 6in battery, one island with Spotting=3 was enough.


Sometimes some hex can't be covered after all. I see no problem in making this uncovered hex terrain type 35 (Escarpment). It would not interfere with a naval battle.
Another alternative solution can be seen in the picture just seen. It's a minefield. You can create an indestructible minefield that acts as a simple hex blocker. You can make the field destructible. This emulates a situation in which the enemy has somehow closed an unseen important hex, but the player can unblock that hex. The hex is important because it is the only place from which you can fire at, say, a heavily interfering enemy anti-aircraft battery, and still be invisible to the enemy's coastal battery.
The picture shows another trick - the shore battery is placed on a promontory prominent in the sea. The battery is already becoming less dangerous, firing toward land.

And to keep the islands from interfering with enemy ships, they should be placed at least 3 hexes apart. Of course, the battlespace is shrinking. But, for the moment, I believe and see in scenarios that the positive effect of the spotting islands is far outweighs the minor inconvenience caused by the trick.