Jump to content
COMBATSIM Forum

World Editor-3P-4tfx


DrKevDog
 Share

Recommended Posts

On 12/29/2020 at 7:53 PM, mikew said:

Need to rethink those transitions...

If we take a look at the Path lines for the Infrastructure shapes in tfx3, we see that the

sub-directories, beyond \sh\, have varying case. They can be upper case, lower case, Title

case, mixed case, etc..
It has become apparent that this case variation communicates instructions of various types.
It appears that the Paths line and the index-tags line are working together to decide

transitions information. In tfx3, at least, the process is more complicated than the simple approach initially taken.

Instead of the world creation automation process being concerned with just the immediately

adjacent terrain transitions for the 4 corners and 4 sides, it seems to be addressing

neighboring infrastructure types, WHY?

 

The tile types in tfx3 can be divided into ENV and TARGET. Both can then be divided into

further subtypes. I have ben spending time on the ENV / Infrastructure tiles which contain

Roads. Rails, Rivers, Pipelines and seems to also include Oil Derricks. All of the

infrastructure contents, in the files I have been analyzing are located in depressed Valleys.

The world creation process is involved with transitions to determine specific terrain tile

supershape placement.
It seems that the subtypes may have specific rules or conventions that very per subtype.

I coined the phrase "Target Complex" for tfx3's massive target constructs, there may also be

a "valley Infrastructure Complex" based on the way the unique infrastructure terrain

transitions are handled.

Here is an example:

The first 2 pictures are the basic supershapes followed by the .asc handlings.

Note the sub-directory case handling for the valley terrain types: VALDST, valfor and VALfor.rvdsts_1.jpg.d8ff12ede7d75450c94bb670ac2fd63a.jpg

rvdsts_1

 

rvfors_1.jpg.b64f5bf54c85ffe59e9638e33fd7320f.jpg

rvfors_1

 

 

VALDST: rvdsts_1

rvdsts_1  SSD Index # 238

q:\projects\tfx3\sh\ENV\RIVER\VALDST\S\1\

0 3 19 3 3 19 3 3 19 3

3

3

3

41.desrtm_2 

41.desrtm_2 

236.rvdstc_3 

19

19

19

236.rvdstc_3 

238.rvdsts_1 

242.rvdstt_2 

3

3

3

234.rvdstc_1 

41.desrtm_2 

235.rvdstc_2 

771518388_rvdsts-1-valdst(2).jpg.ffac4a158630087c6440c8b281e3b023.jpg

 

 

valfor: rvfors_1

rvfors_1 SSD Index # 549 

q:\projects\tfx3\sh\ENV\RIVER\valfor\S\1\

0 7 19 7 7 19 7 7 21 7         @        (201, 83)

7

7

7

69.rvfors_2 

159.forstm_1 

349.rdfors_2 

19

19

21

274.rvfort_4

549.rvfors_1 

507.rdrvfo_1 

  7

7

7

269.rvfors_2

159.forstm_1 

349.rdfors_2 

598575183_rvfors-1-549-valfor(2).jpg.cb2f92a84e198d65bc18f56a62741bd5.jpg

 

VALfor: rvfors_1

rvfors_1 SSD Index # 268

q:\projects\tfx3\sh\ENV\RIVER\VALfor\S\1\

0 7 19 7 7 19 7 7 19 7        @     (206, 58)

7

7

7

156.forsti_2 

159.forstm_1 

266.rvforc_3 

19

19

19

298.rvforn_4 

268.rvfors_1 

272.rvfort_2 

 7

7

7

152.forsts_2 

159.forstm_1 

275.rvfore_1 

rvfors-1-268-VALfor.jpg.a71a4373cf53b7c627125558bb2bb762.jpg

 

That which is encoded "VALDST" is the only one handled in the conventional manner, as we would expect

3 3 3
19 19 19
3 3 3
Link to comment
Share on other sites

  • Replies 84
  • Created
  • Last Reply

Top Posters In This Topic

I hadn't realised that different items in the .asc file would lead to the same ssd file, in this case, rvfors_1.ssd.

No reason why not though.

 

By the way, here's the heights of the edge vertices of those tiles:

Index 238 used: 201
\tfx3\sh\env\river\valdst\s\1\rvdsts_1
   80    80    80    80    80
    0     3     3     3     0
    0    19    19    19     0
    0     3     3     3     0
   80    80    80    80    80


Index 268 used: 91
\tfx3\sh\env\river\valfor\s\1\rvfors_1
  690   690   690   690   690
  480     7     7     7   480
  480    19    19    19   480
  480     7     7     7   480
  690   690   690   690   690


Index 549 used: 5
\tfx3\sh\env\river\valfor\s\1\rvfors_1
  690   690   690   690   690
  480     7     7     7   480
  480    19    19    21   480
  480     7     7     7   480
  690   690   690   690   690

Note that I've totally ignored the case differences, and made everything lower case in my printout.

I'd interpret this as differences in style from artists maybe working on different areas of the map, then combining their work into the .asc file we see today. It's entirely possible that there are other interpretations though. :lol:

Link to comment
Share on other sites

On 2/28/2021 at 7:51 PM, DrKevDog said:

we see that the

sub-directories, beyond \sh\, have varying case. They can be upper case, lower case, Title

case, mixed case, etc..
It has become apparent that this case variation communicates instructions of various types.

 

6 minutes ago, mikew said:

Note that I've totally ignored the case differences, and made everything lower case in my printout.

I'd interpret this as differences in style from artists maybe working on different areas of the map, then combining their work into the .asc file we see today.

 

I’m on mikew’s side here. Neither DOS nor Windows 98 supported case-sensitive filenames. It would have been impossible to have two directories q:\projects\tfx3\sh\ENV\RIVER\valfor\S\1\ as well as q:\projects\tfx3\sh\ENV\RIVER\VALfor\S\1\; these are identical from the file system’s point of view. Seems like a style decision of the individual artist.

Link to comment
Share on other sites

On 3/1/2021 at 3:19 PM, mikew said:

I hadn't realised that different items in the .asc file would lead to the same ssd file, in this case, rvfors_1.ssd.

No reason why not though.

 

 

Tfx2 also has this condition in its ssd index. I'm actually using  a script modified version of

your old Terrain Viewer to print out the tfx3 terrain ssd indices for my analysis... hope you

don't mind....Do you have an updated tool that also provides heights of the edge vertices?

When you say, "differences in style from artists maybe working on different areas of the map",

are you just referring to the variation in case type in the path formats?

Index # 208 q:\projects\tfx3\sh\ENV\COASTCLF\S\3\
0 1 18 13 1 18 13 1 18 13

Index # 209 q:\projects\tfx3\sh\env\coastclf\s\4\
0 13 13 13 18 18 18 1 1 1

Would you then say that the case differences simply suggest that the SSD Tiles for 208 were created by a different artist than 209?

{TFX3 Artists: Ian Boardman - Head of Art & Design - art team management and 3D object building
Paul Hollywood - Head of Art & Design - art team management and world building
Andy Bate - Senior Artist - object, texture, target data and environment management, the F-22 shape and manual screen shots.
Matt Green - Artist - environment, target and aircraft texture creation
Craig Houston - Artist - environment shape and texture creation
Martin Carter - Senior Artist - creation and management of environment shapes, textures, palettes and manual screen shots}

Link to comment
Share on other sites

On 3/1/2021 at 3:25 PM, Krycztij said:

 

 

I’m on mikew’s side here.

Okay, however, I don't want you to be concerned that the utter rejection and bitter isolation could be responsible for creating a blood thirsty, psychopathic Serial_Killer...😮

 

What you say about the case-insensitive nature of the OS is true and is in keeping with the fact that none of those lines are executed at runtime. I would have to assume that the Application that was used supports POSIX semantics, or some similar process for case sensitivity. 

Link to comment
Share on other sites

I hadn't really considered the operating system aspects, but as those paths start with a drive letter, I think we can assume DOS/Windows.

In the early 1990s, Linux wasn't something you'd want to use in a commercial operation unless you couldn't afford an expensive UNIX license. Even if they did that, I think it would take an infeasible level of discipline to maintain a project file system based on the case of the filenames.

Their early games also ran on the Amiga, but that OS doesn't use case sensitive filenames either...at least according to the internet.

 

5 hours ago, DrKevDog said:

I'm actually using  a script modified version of your old Terrain Viewer to print out the tfx3 terrain ssd indices for my analysis... hope you don't mind

As it's you, I'll get my lawyers to draft a special license exemption. :lol:

 

5 hours ago, DrKevDog said:

Do you have an updated tool that also provides heights of the edge vertices?

Not really, as I need to somehow account for the tiles where the edge vertices are not in the 'usual places' eg the box canyon tiles. I'll see if what I have right now is in any sort of condition for someone else to use...

 

5 hours ago, DrKevDog said:

When you say, "differences in style from artists maybe working on different areas of the map",

are you just referring to the variation in case type in the path formats?

Index # 208 q:\projects\tfx3\sh\ENV\COASTCLF\S\3\
0 1 18 13 1 18 13 1 18 13

Index # 209 q:\projects\tfx3\sh\env\coastclf\s\4\
0 13 13 13 18 18 18 1 1 1

Would you then say that the case differences simply suggest that the SSD Tiles for 208 were created by a different artist than 209?

That would be unlikely, as the difference between 208 and 209 is just a rotation, so may be the same  artist before and after lunch which would have been spent down the pub in those days.

Interesting, that even for TFX3 they've kept the rotation parameter although it's always zero. This implies the 'World Editor' is the same or based on that for the previous games.

 

The important takeaway here is the uniqueness of that row of numbers. The path tells the 'world compiler' where to find the appropriate tile for that combination, and while having a logical naming system makes it easier to describe what a file does, I don't think there is a technical requirement for it.

Link to comment
Share on other sites

6 hours ago, mikew said:

The important takeaway here is the uniqueness of that row of numbers. The path tells the 'world compiler' where to find the appropriate tile for that combination, and while having a logical naming system makes it easier to describe what a file does, I don't think there is a technical requirement for it.

I don't want to miss the forest for the trees, or more specifically, miss the World for the Infrastructure. The uniqueness of that row of numbers is dependent upon how the system interprets the numbers. It seems to me that in certain subsets of the tiles the path not only tells the 'world compiler' where to find the appropriate tile but also broadens the scope of the 'transitions'.

Link to comment
Share on other sites

  • 2 months later...
On 1/3/2021 at 2:23 PM, DrKevDog said:

...a few names like the above dcplct_1 does not seem to conform. I interpret it as; dc = derrick, pl = pipeline, ct = ????, _1 = N/S (?).

The .wld defines "48" as "Oil Derrick" but what actually runs North and South is a pipeline with a road running East and West. Is "dc" a derrick road? What is "ct" ?

Any help would be appreciated.

 

Just to clean up an old nagging question:

The answer is that despite the designation "n" being the nomenclature default for connector, it seems this group of oil derrick files, in tfx3, is a late entry and they, instead, used "ct" for connector. This is confirmed by the files that precede it in the list which are in the standard configuration for primary infrastructure set entries which are usually followed by a block of connectors.

Link to comment
Share on other sites

On 3/1/2021 at 3:19 PM, mikew said:

I hadn't realised that different items in the .asc file would lead to the same ssd file, in this case, rvfors_1.ssd.

No reason why not though.

 

In my mind the question was Why?

 

The answer is to allow for each situation of neighboring infrastructure tiles containing non-matching infrastructure. I could start the explanation by saying that it is a significant feature of the Infrastructure files, more specifically, the secondary S1 and S2 files and the crossing (X) infrastructure files. The infrastructure block can be loosely divided into a primary section and a secondary section. Taking the Straight (S\1 and S\2) tiles example, the redundant groups usually involve only one file from the primary group and six (to accommodate 2 each of the  non-matching infrastructure types ,ie. N/S and E/W) from the secondary group. As you probably know, the rules for the 3x3 tag-list transitioning is different for the Infrastructure tiles than for the basic environmental tiles.

Link to comment
Share on other sites

On 3/1/2021 at 3:25 PM, Krycztij said:

 

 

I’m on mikew’s side here. Neither DOS nor Windows 98 supported case-sensitive filenames. It would have been impossible to have two directories q:\projects\tfx3\sh\ENV\RIVER\valfor\S\1\ as well as q:\projects\tfx3\sh\ENV\RIVER\VALfor\S\1\; these are identical from the file system’s point of view. Seems like a style decision of the individual artist.

Attributing the uniquely tfx3 case-variable path statements to simple variability of

artistic style could be true, however,  I am not yet a believer in that theory and I would like to revisit that issue.

I am not advocating a two directories explanation but would like to look closer at the two examples you sited:

 

q:\projects\tfx3\sh\ENV\RIVER\valfor\S\1\ 

q:\projects\tfx3\sh\ENV\RIVER\VALfor\S\1\

 

Reading the tfx3 ASC file in a logical order indicates, by its lower case characters, that the first line is a secondary type file. It communicates that the on tile infrastructure is a (\S) straight river coursing in a E/W (\1) direction. The lower case, secondary type designation indicates that it is concerned with a second infrastructure type (Road, Rail, Pipeline) on an adjacent neighbor tile, either to the North or South of it. "VALfor, on the other hand, is a primary type and has only the river infrastructure on its tile and no non-matching infrastructure neighboring it.

Neighboring tiles (S\1 and S\2) of the infrastructure type have the rule that the side tag, on the side of an infrastructure hosting neighbor must match the code of that neighbors infrastructure type (ie the 5th tag string value.

 

Below are the 2 rdfors_ S\1 and S\2 primary file  paths with their secondary file paths. Note the tag string values and the case logic ?

 

348     60  rdfors_1 

ENV\ROAD\VALfor\S\1\  7 21 7 7 21 7 7 21 7

 349     89  rdfors_2 

ENV\ROAD\VALfor\S\2\  7 7 7 21 21 21 7 7 7

 

560  0  rdfors_1

ENV\ROAD\valfor\S\1\   7 21 7 7 21 7 7 22 7

 561 0  rdfors_1

ENV\ROAD\valfor\S\1\   7 22 7 7 21 7 7 21 7

 562 0  rdfors_2

ENV\ROAD\valfor\S\2\   7 7 7 21 21 22 7 7 7

 563 0  rdfors_2

ENV\ROAD\valfor\S\2\   7 7 7 22 21 21 7 7 7

 564 0  rdfors_1

ENV\ROAD\valfor\S\1\   7 21 7 7 21 7 7 23 7

 565 0  rdfors_1

ENV\ROAD\valfor\S\1\   7 23 7 7 21 7 7 21 7

 566 0  rdfors_2

ENV\ROAD\valfor\S\2\   7 7 7 21 21 23 7 7 7

 567 0  rdfors_2

ENV\ROAD\valfor\S\2\   7 7 7 23 21 21 7 7 7

 

 

 

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


×
×
  • Create New...