Jump to content
COMBATSIM Forum

World Editor-3P-4tfx


Recommended Posts

9 hours ago, DrKevDog said:

in tfx3 "20" / estuary is also a type of water which makes it unclear to me as to why the substitution to "19" / river is necessary if water transitions is the objective.

 

Maybe because of elevation? Sea is always at sea level, while rivers can be at any elevation. They surely need a way to differentiate them, as sea was treated specially by EF2000.

Link to post
Share on other sites
  • Replies 72
  • Created
  • Last Reply

Top Posters In This Topic

Who knows? Elevation might be one reason, but I think the TFX worlds just use a small number of discrete heights with a slope between them, and I think I've seen a river going a slope in TFX3 with no change to the texture used.

Even in TFX1, at least three palette colours for water can be used on the same map. This is from Colombia.asc, and the result of plotting out all the middle numbers (index 5) from the 200x200 map.

col200x200.png.1027d18f694becaa5af89cb7d1f9859e.png

I've zoomed in a bit, but each little square is one pixel on the original 200x200 bitmap.

Link to post
Share on other sites

There are only 5 of these Estuaries on the TAW palette map and they are all in the SE corner of the world:

 

estuary-taw.jpg.e45d293c5df98ef8b0c34a164794fe70.jpg

(estuaries are encircled, but faint)

Maybe it's elevation, I'll have to work on that. Note how each transitions from river to sea.

The main goal is to understand the rules on how this system works, especially the rules governing the .asc tag lists.

it seems clear that there are significant differences between tfx3 and tfx1 and 2.

One example is the advent of what I call the Target Complex. Below is the Kings Complex:

 

55

55

5

51

51

51

5

3

3

3

3

16

16

16

16

16

21

16

55

55

4

51

51

51

5

53

22

54

54

22

54

54

22

54

54

16

5

4

4

4

51

51

5

5

5

5

5

5

4

21

54

54

54

16

51

51

51

5

5

5

5

55

5

55

55

55

4

54

54

53

22

16

51

51

51

5

55

5

55

55

5

55

55

55

4

54

54

22

53

35

51

51

51

5

55

5

55

55

5

5

5

5

4

21

54

53

21

16

5

5

5

5

4

4

4

4

5

55

55

55

4

54

54

54

54

16

3

54

22

54

54

22

54

54

5

55

55

55

4

54

22

54

54

16

3

21

54

54

21

5

5

5

5

4

55

5

5

5

5

4

21

16

3

54

54

54

54

5

55

55

55

4

4

5

55

55

55

4

54

16

21

54

22

54

54

5

55

55

55

4

54

5

55

55

55

4

54

16

3

21

54

54

21

5

55

55

5

5

5

5

4

55

55

4

21

16

3

54

54

54

54

4

4

4

5

55

55

55

4

4

4

4

54

16

3

54

22

54

54

22

54

54

5

55

55

55

4

54

22

54

54

22

16

54

54

54

21

54

54

21

5

55

55

55

4

21

16

16

16

16

16

22

53

54

54

54

54

54

4

4

4

4

4

54

16

80

80

16

16

53

22

54

54

22

54

54

22

54

54

22

54

54

16

80

80

16

16

35

16

16

16

16

16

22

16

16

16

16

16

16

16

16

16

16

 This includes Luxor and I wish to understand how to read the grids as well as the tag lists.

Another example, unique to tfx3 is how the tag values are utilized in an unusual way in the case of two unique types of Infrastructure intersecting:

rvdsts_1-213-Grid2.jpg.50d436f511fc47f5f72e401de9726543.jpg

Where one would expect to find a "19" there is a "23" which seems to herald the existence of the pipeline which intersects the river in the adjacent tile. This is consistent in tfx3 and I have yet to find it in tfx2 and the implications of which are not yet fully known.

 

 

Link to post
Share on other sites

I've just had a quick look at redsea.asc and there are more 23s where you wouldn't expect them.

It's been a while since I looked at this and I don't remember ever getting to the bottom of it. I had a theory of how the world might have been created from a basic bitmap and I think the .asc file was part of that process. Whether it was an input or an output, I have no idea, but none of the information after the first line is used when running the game.

 

I suspect that while there was an attempt to produce a fully automated terrain system, it required a fair bit of manual overriding to get a good result, thus you'll never see total consistency. We see this in other areas as well.

 

Regarding the estuaries, it could just be marking them for different textures. If they were being clever, they could put some tidal effects into the transitions in these areas.

 

Maybe I'll get a chance to look into this a bit over the next few days.

 

ps, that's a cool XP screenshot. :thumbsup:

Link to post
Share on other sites

Hmmn, a problem already with my theories from last time I looked at this.

The simplest map is 'seaworld' from TFX1 and only uses 11 different tiles. The problem is that if I just plot out the 'middle' value from the .asc file, I miss the dock that's the yellow square in the picture below. Wasn't expecting that. :(

In the picture, the upper left is all the .asc parameters plotted, upper right is the .lbm file that comes with the game, and the lower plot is just the middle value from .asc. As the dock (palette position 143) is on the edge, it is missing...

seaworld1.png.18c0c2e664f4affae218e6ace79426ec.png

Need to rethink those transitions...

Link to post
Share on other sites

Actually, the 'seaworld.lbm' above came from the TFX2 dataset, but still matches quite well with my .bmp derived from the TFX1 .asc file.

So, I'd like to perform a pixel by pixel comparison, but this requires converting the .lbm to .bmp and I can't find anything to do that while maintaining indexed colour mode.

Doing it myself, I'm having trouble with the bitplanes.
After the RLE decoding stage, for this 320x200 bitmap, we have 200 rows of 320 bytes.
As I understand it, I have to take 8 rows at a time and cut them up so the first byte in the new bitmap will consist of the MSBs of the first byte in each row,with the MSB of the new byte being from the 8th row.
The resulting .bmp is still scrambled, so still a bit to do. :(

Link to post
Share on other sites
27 minutes ago, mikew said:

So, I'd like to perform a pixel by pixel comparison, but this requires converting the .lbm to .bmp and I can't find anything to do that while maintaining indexed colour mode.

Sorry, my tools always convert LBM to 32-bit color because it is easier to handle in the big picture of TFXplorer :(  

Link to post
Share on other sites

Totally understandable.

 

My interest here is the world building aspects where it's possible the .lbm file was quite a fundamental part of the process and where the palette is used for more than just colour. For me, .bmp is the simplest way of joining a palette to a bitmap with having to turn it upside down the only annoying thing.

Link to post
Share on other sites
17 hours ago, mikew said:

Totally understandable.

 

My interest here is the world building aspects where it's possible the .lbm file was quite a fundamental part of the process and where the palette is used for more than just colour.

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:

redsea-LBM-88-103.jpg.15920f00cce419de316dfa7c179384f3.jpg

 

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.

 

Link to post
Share on other sites

It's been a long time since I've looked at this, so can't give any intelligent comment. :(

Do you know whether pipelines are always at the same elevation, or can they be put on slopes?

 

All I had was a vague theory about how the world creation could be automated, and am visiting it again for some holiday season programming fun. This time I'm starting with TFX1 and see how it goes.

I think the first thing thing is to work out the elevation transition rules...

Link to post
Share on other sites
18 hours ago, mikew said:

 

Do you know whether pipelines are always at the same elevation, or can they be put on slopes?

 

All I had was a vague theory about how the world creation could be automated, and am visiting it again for some holiday season programming fun. This time I'm starting with TFX1 and see how it goes.

I think the first thing thing is to work out the elevation transition rules...

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

 

 

 

Link to post
Share on other sites

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.

 

Link to post
Share on other sites

I don't have those answers yet, but I'm trying to find scripts from years ago and adapt them to python3 while extending them a bit.

I've converted redsea.lbm to .bmp format and saved the palette which I've reused to make another .bmp from each middle index of redsea.asc using the index from redsea.env.

While these are not 100% identical, they are near enough I think to say the ssd indices in redsea.list, the .lbm palette, and the entries in the redsea.asc are related.

Not sure about redsea.wld yet...

redscomp.PNG.580333e4c906b7d3c9911761a574cdec.PNG

Spot the difference.

Link to post
Share on other sites

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?

Link to post
Share on other sites

I haven't done a byte comparison, but there's a couple of greenish pixels towards the top right of the image in the background which aren't there in the foreground image which hints at a slightly different .wld being used.

 

If I take the palette colours from redsea.lbm and match them with the text from redsea.wld we get this:

testout.png.154043423fcbecd4dce29c7108e72fd0.png

..with just enough effort to produce a picture with text on it, but not enough to space it out properly. :)

Link to post
Share on other sites

I was using a PC that doesn't belong to me yesterday, so was just using built in Windows 10 tools plus Python.

Not impressed to see this with Paint:

msp_wtf.PNG.9972932559932e6178627ec4326399d3.PNG

So, we've lost Freecell, now Paint. :(

I guess the XP era Paint etc will still work if I can be bothered to copy them from an old install.

 

Link to post
Share on other sites

I use a program called mtPaint on Linux. This is good in that you can hover over pixel with the and see the coordinates and palette index. Unfortunately this isn't visible in a screenshot.

Anyway, here I take those greenish pixels from the redsea.lbm derived picture and can see that they are palette entry 171.

In the redsea.asc derived picture they are palette index 3.

If I then look at the spreadsheet of ssd files, there is 'desrtm_1.ssd' at these positions, as there is for the areas around the box canyon area. The reddish pixels around the green ones are palette position 170.

This ties in with DKD's earlier comments, but shows palette position 171 must be on the 'edges' of the .asc data.

tfxaa.png.dc0d7bd9074a17fd4cac0efa3f8b4948.png

By the way, LibreOffice Calc opens in a tiny box in the top left corner if opened in windowed mode, just like later versions of Lean Viewer and TFXplorer. I haven't got to the bottom of that.

Link to post
Share on other sites
54 minutes ago, mikew said:

I was using a PC that doesn't belong to me yesterday, so was just using built in Windows 10 tools plus Python.

Not impressed to see this with Paint:

msp_wtf.PNG.9972932559932e6178627ec4326399d3.PNG

So, we've lost Freecell, now Paint. :(

I guess the XP era Paint etc will still work if I can be bothered to copy them from an old install.

 

 

I really can’t put that into words any more

 

Here, enjoy MSPaint from ’98 and XP … and the non-alert-version from earlier 10, which may not run because I did not bother resolving its dependencies: http://krishty.com/temp/mspaint.zip

FWIW, I’m still trying to port my apps to the Microsoft store. The architecture does look well-engineered and it certainly is an improvement over the jungle of legacy installers. However, the documentation is sparse and basically says “install 7 GiB of Visual Studio, make a new project and call these 10 compilers, and here’s your msix package.“ I’d rather build the package myself, so I’m stuck.

 

Link to post
Share on other sites

It feels a bit bad to be derailing DKD's thread with complaints about Win10, especially since he's still blissfully using WinXP. :)

 

...but does that mean you could create your own 'Krycztij Store' using MS's tools, or is everything dependent on a link to MS?

I'm still going to continue using Linux for non-gaming stuff because it's awesome (except when it's not, when it becomes unbelievably annoying). I'm not sure what the future holds when Torvalds gives up though.

Might have to save up for a Mac. :(

Link to post
Share on other sites
29 minutes ago, mikew said:

...but does that mean you could create your own 'Krycztij Store' using MS's tools, or is everything dependent on a link to MS?

Depends. You can distribute and install apps as .msix packages and they will install and behave just like from the Microsoft Store. I haven’t had a look at the payment side of things, though. And there are two prerequisites:

  1. Your users need to enable the Windows setting to sideload apps (i.e. install from other sources than the MS store). Sounds like something MS would disable in a few years, and some enterprise domains forbid it already.
  2. You need a digital certificate to sign your apps. (If you use the Microsoft store, MS will sign them for you.)

Not trying to euphemize things – the whole concept is still targeted at grabbing as much user data as possible and things are locked off in intransparent ways. But as far as I can see, nothing is limited to UWP or C# or that crap; you can distribute any program you like via store. My Win32-only-programs work like a charm. The Windows kernel debugger (WinDbg) is also distributed via store.

Apps are properly isolated from one another – their settings and files won’t collide – much in contast to classic programs. You can uninstall or reset settings with a single click. Through isolation, DLL hell is practically gone. The .msix packages are basically ZIP files with a few sub-folders and a little XML content, i.e. you can analyze and verify their content statically before installing. If MS had done this 20 years ago, it would have saved so many headaches for so many users and developers.

Link to post
Share on other sites

Thanks for your insight. For all I know, Linux may be totally compromised and it would be 'safer' just to do whatever MS want us to do.

 

Back on topic a bit, I've just looked at redsea.asc and index 171 isn't there at all, so any tie-up between these files is not perfect. There could be plenty of reasons for that though, particularly as redsea.lbm is not used at all at runtime, and neither is the bulk of redsea.asc.

 

Link to post
Share on other sites
  • 2 weeks later...

Combining the path names and palette indicesfrom redsea.asc, the ssd names from redsea.lst and the heights of the edge vertices from the COLLISION_TRIANGLES section of each ssd to try and get an idea of how the 3D mesh might be created.

The palette indices are the middle 9 numbers in each block and are surrounded by the height values. Need to find a better way to display them, but you get the idea I hope...

 

16
\tfx3\sh\env\sea\sea
    0     0     0     0     0
    0     1     1     1     0
    0     1     1     1     0
    0     1     1     1     0
    0     0     0     0     0

17
\tfx3\sh\env\coastsnd\c\1\ctsndc_1
   75    45    30     0     0
   45     2     2     1     0
   30     2     2     1     0
    0     1     1     1     0
    0     0     0     0     0

18
\tfx3\sh\env\coastsnd\c\2\ctsndc_2
    0     0    30    45    75
    0     1     2     2    45
    0     1     2     2    30
    0     1     1     1     0
    0     0     0     0     0

Not yet sure what use this is going to be. :)

Link to post
Share on other sites

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?

Link to post
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.


×
×
  • Create New...