gerwin

For your information; AFAIK: A simulation is about book-keeping all the game data every tick. Even with the source it is not an easy task to do this. Fortunately, In the source all structures are named and can easily be expanded upon. Once compiled to an executable all such structures+procedures lose their name and are tied to fixed memory offsets. Writing beyond that range gets you in the memory range of another structure. This makes it very hard to add a feature to the engine without the source. Much harder then disabling a feature, like CD checks for example. One typical thing is that SF uses a lot of DLL's to hold game code. There are only few projects I know that have reverse engineered a game exe back to comfortable C, or the more primitive ASM code, thus allowing for expanding of structures and features. OpenDune / Dune Dynasty is the best example I know (C code). Red alert has also been recompiled to ASM by some people, not yet to C. Here is a time estimation of reverse engineering a simpler Flight Simulation: 15 years. http://fabiensanglard.net/reverse_engineering_strike_commander/ "they (Third Wire) were happy not to be working on PC these days" Piracy has been an issue ever since the PC was introduced, back then. Has it become worse? Apple has its own Piracy, the terrible 30% of all payments in the app store that goes in the pockets of Apple. And most importantly, these TW mobile games are just too simple. It is like playing Chuck Yeager's air combat (1991) with a timer and bad controls. Better graphics though. Would also be curious how a SF2 game would do in the GoG Catalog. Though I often think the average customer tends to stick to games he already knows, or something close to it.

Latest old CatPack program can create CAT's that are read fine by the game. You have to pass '2' as the desired output format, the ASCII format '1' is no longer supported by SF2.

Amazing work mue!! Quite an accomplishment to decrypt both the protected cat files and the 3D model formats. I hope you can add support for the older simple .cat formats too. I can tell you how to read them, but then again it should be a piece of cake compared to the current format.

Thanks, that is definitely helpful! I'll compare it it with what i noted myself. The manual says: "In addition to the TileMap and Heightmap, the program can display a ReferenceMap named *_ref.bmp. When found it will be loaded and can be shown through switching the editing mode, with the M key. This Bitmap must be in a fixed size ratio compared to the TileMap: 1:1, 1:2, 1:4, 1:8." So it is a matter of exporting the tilemap to a bitmap, and load it in an imaging program with layers. For best results scale it up so it is 8x the size of the actual tiles (ratio 1:8). In another layer one puts the map from google earth, make it transparent so you can see the tilemap as well. Then you use scale/transform/rotate/distort until the google map matches the tilemap below. remove the transparency and save it for import in TFDtool. Good luck. .... I am sorry to say that the past months did not allow me much time for hobbies; Since the contract for the house I rented was revoked. So I had to move to a temporary place, and soon to a new place of my own.

AFAIK that bit information is displayed on the bottom left, at any time: "texture: ##"

Thanks guys. Good to see the tool is still in some demand. The reference map feature was just a quick adjustment, I think it took about 2 hours. Centurion, I disabled the editing commands while in reference map mode. Is that proper or should I allow (blind) tiling or something?... Hope this month will allow me some time to look a the TOD's again, as to read the tree and building locations.

Fair enough. :) I just added support for a ReferenceMap, which can be displayed just like the TileMap and the HeightMap. Details are in the manual.

My Classic TFD/HFD IcelandNA Is about as realistic as the Stock North Atlantic terrain, as it has the exact same targetareas: 2031 targets in 46 targetareas. The Stock North Atlantic targets are very generic, as the towns are just stock towns. It has a limited amount of tiles: greenish areas, brown rock/mud and snow. No roads or rivers. But great care was made to make the tiles blend in with eachother: no visible tile transitions or patterns. Places like the fjord airfield are pretty cool and real, but reykjavik is still nothing like it should be. I remember this terrain is shrunk compared to real size, like two thirds the size. The SF2NA naval campaign can be played with this terrain. Baltika's Iceland V2 Tried this briefly before, I would say more research went into this, regarding target areas and terrain type. 7519 targets in 166 targetareas. There are more different terrain tiles, but they are arguably contrasting a lot with eachother, as can be judged in the screenshots. Note that in reality the snow cover changes a lot throughout the year. I suggest you try both. The downloads are tiny in size anyways.

No, sorry. First thing on my TODO list for Strike Fighters is to finish the HEMTT truck model I started.

Thank you was enough already. :) There is this trick of listing the meshes for old style LODs like this. For newer LODs, made with a SF2 exporter, it is back to staring at the XVI 32 hex editor like wrench said....

OK it makes sense, I will see if such a thing can be added easily, when I next work on the program.

The attached document lists all the objects in the KC-10 LOD. I marked which ones appear to be the boom. Edit: 'Line03' and 'Line04' are the bulbs on the hull, where the boom starts. kc10.txt

Have you tried this?: http://combatace.com/topic/71249-sf2na-iceland-classic-tfdhfd-terrain/ In case you don't have the SF2NA stuff, use the files in the standalone folder (read the readme). If you really want the ocean plain, paint away the island in the middle ;)

TFDtool v0.94 is up @krfrge I raised the movement routes limits, you can find the current limits in the help file. @Eole2 Jpeg support has been added. Of course Jpeg compression has its advantages, when used under the right circumstances, like higher res tilesets. TFDtool works with images with the file extension "JPG", but extension "JPEG" does not work. So watch the file names. Windows hides extensions by default. Another new thing is the E key, which brings up a dialog with all the export options. @Centurion-1 Normally I would have added such a feature already. But the problem is that the DEM heightmap files used for Strike Fighters are usually in a rectangular format. And that projection does not really match any geographic reference maps. Unless someone converts projections with Geographic software (like Xplanet). But AFAIK I am the only one who did that once, for Wrench's North Sea map. Without exact projection conversion, a user remains approximating the exact locations of rivers and cities anyways. ...Feel free to correct me though.

Don't bother testing, I just noticed I indeed capped it at 64 somewhere. Will raise that limit in a few days.

Currently most, if not all things in TFDtool have a set limit. I see that the total movement points/coordinates is 4096, regardless of the amount of movement routes. Is the program failing to draw all your movement data? (PS. I answered the question from 14 February 2014 by combatace PM)

Yes; raw X, Y and Z coordinates. IEEE float format. With the far edge of the tile being 2000 meters. IIRC @10107 Glad you like it. Regarding quack74 his request, I mailed him an adjusted version of the program, with a target area limit of 1024. @101

I have never seen an updated hi-res version with the brown rock tiles.

With SF2NA in march 2012 a new LOD 3D model format was introduced (v8). DLCs after that time use this format. This is still the last LOD format up to this point in 2013. Any base install from 2011 or older cannot read this format.

Both yes and no. Angle is gone in the tod file, and there is no location for a single object. Instead there are coordinates of points/vertices which belong to triangles. The computer renders textured triangles. A square building has 5 square sides, 10 triangles. 8 different points. but possibly up to 3*10 stored points. Then the texture part stary just mentioned. And maybe some additional data I forgot about. Thanks for the list, it is still useful.

When I looked at the TOD files with a hex editor, I understood only half of it. Just (1) the amount of 3D objects and (2) the coordinates of their edges. Every TOD object being stored as an independant and individual bunch of polygons. This info would be enough to draw an overlay on the tiles to show where tod objects are located. But there are sections and bits of data in the tod file which I do not understand, so creating tods may be beyond my ability. One day I will try to draw the overlay I mentioned.