Jump to content
COMBATSIM Forum

DrKevDog

Members
  • Posts

    1,299
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

DrKevDog's Achievements

Colonel

Colonel (6/10)

0

Reputation

  1. I for one appreciate the new layout type. It looks better and feels better than with all the Windows 10 wasted space. 👍
  2. 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
  3. 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.
  4. 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.
  5. I like the simplicity of the format it grants wider room for future modifications. The Arcade level, for example, lends itself to many developmental modifications ☺️
  6. 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'.
  7. 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.
  8. 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}
  9. 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 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 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 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 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
  10. Well done! I am savoring every word as your Editorial skills are quite commendable. Thanks!
  11. I like it ! And especially the logic which is clean and simple, like Sorbet to cleanse the palate without complicating the process. Wading through the Collision Triangles data to check the values is, for me, currently manual and time consuming so I have cheated a bit and used the .3 model vertex data instead. I really thought the relationship between the tag values and the base height values would prove to be direct, maybe even 1:1, but that is not the case is it? How did you discover this pattern or did you find something in the tfx files that pointed to it?
  12. Nice work, very close indeed ! ☺️ The only difference I see in your image is one that seems to implicate the redsea.wld as being incompletely updated. It has index location 171 without a palette name and yet it has 5 occurrences in the Box Canyon areas as desert textures. Similarly # 108 (not in your image sample) may translate to aswan_p.ssd or are you referring to another difference?
  13. The way I see it, a big part of this exercise is understanding and assimilating the names and naming conventions of the three systems. The three systems being: 1. .wld/.lbm, 2. .lst/.asc, and 3. .env/.ssd. My interpretation of the above posted 3 names leaves me wanting for the correct interpretation of the last one. I read "plrvdt_1" as; pipeline, river, desert, _1 (= North/South). These naming conventions representing primary feature, secondary feature, base texture and directional orientation. ie. pipeline is the primary feature which is assigned the directional orientation "_1", river is the secondary feature and runs perpendicular to the primary feature and desert is the base texture. This interpretation works as expected for rvpldt_1 and most .ssd names. HOWEVER, 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.
  14. I do not yet know whether pipelines are always at the same elevation, or can they be put on slopes. Pilpelines seem to always be on one of 3 base tiles (desert-3, dunes-4 and forest-7) there is some indication in the ssd files that they can be at varying elevations although not yet confirmed. Working out the elevation transition rules is critical. The current focus for me is the infrastructure intersection rules. Indications are that of a hierarchical system where, perhaps, the palette codes indicate a value-magnitude relationship involved with transitions: 3 3 3 3 23 3 3 3 11 3 3 3 3 23 3 3 3 3 3 3 3 3 23 3 3 3 3 3 3 3 3 23 3 3 3 3 19 19 23 19 23 19 23 19 19 3 3 3 3 23 3 3 3 3 3 3 3 3 23 3 3 3 3 3 3 3 3 23 3 3 3 3 3 3 3 3 23 3 3 3 3 plrvdt_1 3 3 3 3 19 3 3 3 3 3 3 3 3 19 3 3 3 3 3 3 3 3 23 3 3 3 3 3 3 3 3 19 3 3 3 3 23 23 23 23 23 23 23 23 23 3 3 3 3 19 3 3 3 3 3 3 3 3 23 3 3 3 3 3 3 3 3 19 3 3 3 3 3 3 3 3 19 3 3 3 3 rvpldt_1 3 3 3 3 23 3 3 3 3 3 3 3 3 23 3 3 3 3 3 3 3 3 48 3 3 3 3 3 3 3 3 23 3 3 3 3 48 48 48 48 48 48 48 48 48 3 3 3 3 23 3 3 3 3 3 3 3 3 48 3 3 3 3 3 3 3 3 23 3 3 3 3 3 3 3 3 23 3 3 3 3 dcplct_1
  15. Perhaps that is true and it may not be easy to prove. For example, you wrote: "Need to rethink those transitions... ", and I am not yet 100% sure, however, I think of those .lbm maps as transition maps but thinking in transitions can be counter-intuitive. My current EXAMPLE: 87 104 desrtm_1;88 104 rvdsts_2;89 104 desrtm_1 87 103 pldsts_1;88 103 rvpldt_1;89 103 pldsts_1 87 102 desrtm_1;88 102 rvdsts_2;89 102 desrtm_1 rvdsts_2 rvpldt_1 rvdsts_2 3 19 3 3 19 3 rvdsts_2 (532) 3 23 3 3 19 3 23 23 23 rvpldt_1 3 19 3 3 23 3 3 19 3 rvdsts_2 (533) 3 19 3 239 328 rvdsts_2 3 3 3 19 19 19 3 3 3 524 25 rvdsts_2 3 3 3 19 19 21 3 3 3 525 25 rvdsts_2 3 3 3 21 19 19 3 3 3 528 6 rvdsts_2 3 3 3 19 19 22 3 3 3 529 6 rvdsts_2 3 3 3 22 19 19 3 3 3 532 3 rvdsts_2 3 3 3 19 19 23 3 3 3 533 3 rvdsts_2 3 3 3 23 19 19 3 3 3 493 rvpldt_1 3 23 3 19 23 19 3 23 3 RIVER\VALDST\X\PLINE\ 451 pldsts_1 3 23 3 3 23 3 3 23 3 This is the interpretation of coord's (88, 296) as read from redsea.lbm in Irfanview: Only the brown stamped pixel is visible on the map at those coordinates and correlates to index #23 which is a "pipeline" pixel. If we look to the .lbm map again we see that the pipeline pixel is flanked to the North and South by 2 "river" pixels In order to use this 2D map to communicate a 3-Dimensional world space, we look to the ENV map and .asc tag-string and working backwards we see that, the pipeline pixel ,which represents rvpldt_1 is flanked to the North and South by 2 rvdsts_2 entries. It is the tag-list string, which is configured with 2 flanking "23" edge tags for both rvdsts_2's, one of which is called from index (.lst) slot 532 (N) and the other from 533 (S), that tells us that this is a map / world space which contains both a river and a pipeline and the pipeline is superior to the river.
×
×
  • Create New...