Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Krycztij last won the day on February 5

Krycztij had the most liked content!

Community Reputation

3 Neutral

About Krycztij

  • Rank
    Brig. General
  • Birthday 09/05/1981
  1. TFXplorer

    The unit is always meters. (TFXplorer is SI-based since ~2015; TFX’s units have since been converted with a tiny rounding error.) Tiles can have an arbitrary size in meters, not necessarily integer
  2. Interpretation of SSD files

    Please take into account my uploaded screenshots! https://app.box.com/file/24479249637 https://app.box.com/file/24479287085 https://app.box.com/file/24516749789 https://app.box.com/file/24467849463 https://app.box.com/file/24467848487
  3. TFXplorer

    Minor update: Last week, I finally isolated the code for tile sidelength. This was a major problem in the way of new terrain, because TFX’s tile sidelength (16384 ft) was hard-coded everywhere. I can now use arbitrary sidelength with arbitrary geometry: Forward, step by step
  4. Interpretation of SSD files

    Thanks, I’ll try soon! If you want to see the crashes in person, fly to Aden. Fly to the tile with the large airport tower. Shoot at the buildings. You’ll see that the collision boxes don’t match the visuals and eventually, it’ll crash. I suspect it’s something about the order of collision boxes …
  5. Spitfire replica crashed

    Yes; the first one was a glider crashing next to me last summer, but without injuries. What’s the chance …
  6. Spitfire replica crashed

    A spitfire replica crashed in Germany yesterday. The plane caught fire in flight (cause unknown) and crash-landed on a field. The 69 years old pilot left the cockpit, but with severe burns (witnesses had to extinguish him) and he is now in critical condition. I’m living just a few kilometers from the crash site – I’ve even watched that plane flying loopings above my garden the day before yesterday. My hopes and wishes go to the pilot.
  7. Interpretation of SSD files

    TFXplorer doesn’t for two reasons: It’s hard. There is no path through a .3 shape that draws all triangles; it’s always branching on viewer position (which does not exist with physics) and so you always miss triangles. If you explore all branches, you’ll have overlapping/duplicate triangles, which is just as bad (triggers duplicate collisions, so a ball will bounce off the ground twice as fast). I never had the energy to find a good solution. I designed TFXplorer to follow ADF/TAW behavior as close as possible (after all, we wanted to speed up TAW 2.0 modding!), and this would have been a major difference. Remember that one mountain in EF2000 where physics and visuals don’t match? We never solved that one Yes please! The code was a rushed-down combination of copy-pasting your Python code and hacking in TFX 2 compatibility. It’s full of crashes and security issues. It needs a full rewrite, I’m afraid … keep me informed on anything you find. Should be the 0030 opcode: Every shape has one, and they are often nested …
  8. Back to TFX1

    I don’t write the API with any specific format in mind – it’s a code API (note 1). The terrain plugin must implement a handful of functions like “does this ray hit the terrain, and if so, which material or object is there?”, and then physics work automatically. All our current code is moved to a TFX terrain plugin. This implements the functions using SSD’s COLLISION_BOXES, SSD’s COLLISION_TRIANGLES, and 3’s texture transformation in the header (note 2). Nothing will change there. However, once the API is finished and all TFX traces are removed from the simulation core, I’ll implement a second terrain plugin with a new format, most likely VRML. Nothing of it is coded yet, so all I say is preliminary and I’ll gladly listen to your wishes. I imagined: Tile-based, again (there is little way around this if you want to support arbitrary terrain sizes). Per tile, one VRML file with one or more objects in it. Each object has one specific material. Materials should probably use predefined names. So if you want to make a desert with a small lake in it, you probably have to write in VRML a height map with “sand” material a planar polygon with “water” material Terrain collision information *should* be generated automatically from the visuals. If you desperately need to override it, you could insert an object group with a special name, e.g. starting with COLLISION_, I guess. Interactive/destroy-able buildings could be realized by adding Inline nodes to the terrain VRML files, where each building is an individual VRML file. VRML files for buildings should be in the same format, but should use the COLLISION_ feature more often. Each VRML file should be accompanied by an INI file with some data on damage tolerance etc., but I have not yet thought about the individual properties we need (e.g. I want fire/explosive damage separate from impulse damage) we probably can embed them directly into the VRML file as well using a WorldInfo node Further data can be embedded into VRML using named objects. E.g. place an empty object with the name TAXI_OBJECT_1 at a specific XYZ in the airfield tile, and I’ll know it’s taxiing. (I know DCS does this as well, e.g. the spawn positions for missiles are encoded as named empty objects in the 3DS file describing aircraft.) This will be very slow to process on loading, so I’ll likely add a cache system with a binary format in API-optimal encoding. You should not care about this. One more statement regarding damage etc. in the API: Building handling is very immature in TFXplorer. We have the animated windsock, we have buildings that can be destroyed using COLLISION_BOXES (still crashes randomly), and that’s it. No interconnections, no accurate collision detection, no nationality. Current API: allows to create a building at a specific place in a tile allows to assign collision boxes (even in the wrong coordinate system because I never got to repair it; I will soon) expects three callback functions for timer (e.g. the windsock’s is “call me every n seconds so I can update my animation”) rendering on hit (e.g. TFX buildings’ is“spawn an explosion in my place and update my .3 parameter #7”) I’ll improve it but currently it’s not high-priority. E.g. I’d like to add electricity nodes so destroying a power plant will black out nearby cities etc. I’ll add nice class diagrams about the API structure when it’s done. But right now things are still changing and it would be a waste of time. Note 1: I can’t tie the terrain to a specific format anyway, because we’d probably like to use procedural generation or web-streamed content at some point in the future – i.e. the data is not yet existent when the game starts! Binding it to arbitrary code instead of arbitrary data makes much more sense from that point of view. Note 2: This is necessary to differentiate grass, sand, and water in COLLISION_TRIANGLES. I don’t use it now, but prototype code from ~3 years ago is in place and awaits activation. Priorities …
  9. GTX590

    Yes, I open and clean my GTX 660 every once in a while because that design is very far from optimal. I should have mentioned that; sorry …
  10. Back to TFX1

    Eventually, why not? It started as a tool to make us understand the TFX games and it will always be. Plus, soon terrain logic will be separate from the simulation core, so we can implement whatever we want without polluting the rest of the engine. (Nice that you mention place names. I’m currently writing an API for borders, because borders.txt has to be removed from the simulation core as well. I could use the above TFX 1 information to implement cities with area instead of point size …)
  11. Back to TFX1

    Just write down every little thing you find out; no matter if short or unclear. I’ll come back to it and implement it once the time has come.
  12. Back to TFX1

    Mike, this looks just amazing!
  13. Back to TFX1

    It’s okay; that post may be handy for the next problem Did you check because I remember there was something odd about the map’s memory layout (mirroring or 90° rotation or something like that) and it was hard to figure out.
  14. Back to TFX1

    I’m somewhat surprised as well. I once experimented with randomization in TFXplorer, but I think (hope?) I removed all of the artifacts. I don’t have time right now to investigate it, but if you can compile your own TFXplorer, you can check for yourself: open TFX\TFX Terrain.cpp navigate to somewhere around line 130, in the middle of tryToLoadTFX3Terrain() below the index out-of-range error, there should be a line tile.toSupershapeOrNull = toSupershapeOrNull; click where the red dot is in this image, this creates a breakpoint: right-click the breakpoint, select Conditions…: in the way too tiny edit field in the badly positioned dialog, enter x==123 && y==456 of course replace this with actual tile coordinates you’re interested in – you’ll have to check the for loop a few lines above, because IIRC, TFX transposes or mirrors the data …! hit enter make sure you have selected the Debug version in the menu bar hit F5 to start debugging and wait a moment – the debugger will break into your desired tile hover the mouse above the toSupershapeOrNull variable; name information will appear if it’s a cloud tile, hit F5 again to skip forward to the terrain … I changed this code a lot here so I can’t say for sure whether terrain or clouds load first if that’s the wrong tile, hover over the supershapes variable (and click the tiny arrow to expand) or over the currentTileIndex variable to get more information. If supershapes, for some reason, does not display as a list like it does in this snapshot, go to the next step and type supershapes.toBeginning,3000 in the window: if that list is too long to read in a sane way, go to the menu and select Debug -> Windows -> Watch -> Watch 1, then type the variable names in the lines (you can check the raw indices typing toIndices,160000 and switch to hexadecimal display in the right-click menu!) If that still doesn’t make any sense, report back! Sorry for forcing you into C++ debugging, but isolating the renderer screwed up so many things here that I can barely get the engine loading …
  15. Back to TFX1

    Sorry for your loss! TFXplorer does put a lot of pressure on the GPU driver (not on the GPU itself, though). I know because I’m looking at this code right now – and wondering, how will I ever get this code hidden behind a proper, Vulkan-compatible interface?! The 3 shape renderer really is one of the ugliest problems I ever had to solve. But anyway, that’s some good work you’ve done on the randomization. I bet you’ll get it right eventually!