Gunrunner

Engine : The code that makes the game run, interprets assets Assets : The content, planes, textures, terrains, menus, anything that is not code File Format : The specific way content is stored and organised to be read properly by the engine To clarify what OP intends as I read it : Important, IANAL, I'm just stating generalities not specific to any country, based on commonly used laws, enforceable EULAs and existing similar efforts OP apparently intends to provide a new engine, not using TK's intellectual property, not distributing TK's content, but compatible with its file format, meaning that if you own SF2, you would move SF2 assets to the new engine, and the game could then use them; likewise, any mods would be compatible. IF OP provides a clean engine, developed legally, without including TK's code, it would be legal. (TA Spring IIRC is an example of this) IF OP does so by reverse-engineering TK's code for reference and rewriting it, it would be legal in most countries. (ScummVM, OpenRCT and modern OpenTTD are good example of this) IF OP does so by reverse-engineering TK's code but not rewriting it, it would be illegal in most countries. (Early OpenTTD is a bad example of this, it's been fixed since) IF OP distributes any of TK's assets without a licence and his authorisation, it would be illegal. (I don't have any example of project behaving that way) IF OP distributes the engine without assets, requiring the user to use his own legally owned copies, it would be legal (TTD Patch, OpenTTD, OpenRCT, ScummVM, TA Spring, Falcon BMS and so many other projects work that way, provide a new engine, or engine patch, but require original files for assets). IF OP distributes the engine along community assets, following the rules of the assets' licence, it would be fine. IF OP distributes the engine along community assets, without following the rules of the assets' licence (asking for and obtaining the creator's consent, properly crediting creators etc), it would be an issue. Some mods are under a pretty liberal licence, other under a rather restrictive one, some have no clear licence, almost none have an industry standard licence (which isn't good but hey, that's how it works here and does so mostly fine for this community), the rule of thumb would be to make sure to follow the licence, and even if not required, inform and obtain the consent of the creator. The question is whether the file formats are proprietary, someone's intellectual property that OP can't use without a licence, or are a free format that doesn't require a licence, allowing OP to freely have their engine interpret it. The "key" file formats would be : - The CAT format, which is the main archive storage for assets, but AFAIR it's a rather basic concatenation of files and is not proprietary, besides extraction/creation tools have been provided by TK and the community for decades so it's likely not an issue. CatPack by Gerwin in extract-write mode and CAT Extractor by Mue in extract-only exist as tolerated precedents. - The LOD format, which is used to store 3D models, it might be specific to TK in its implementation, but he provided tools to export to LOD and allowed community tools to exist provided they are read-only, his objections were to being able to extract the models for modifications. LOD Viewer by Mue exists as a read-only precedent. - The TFD and HFD formats, which are used to store terrain tiling and height map data, likewise, they are rather generic and TK provided tools to manipulate them and never objected to third party tools. TFDTool by Gerwin exists as a read-write precedent. - The TOD format, which is used to place non-physicalised objects on tiles, is not standard to my knowledge. TOD Editor by Mue exists as a read-write precedent. Anything else is a rather standard and non-proprietary affair. As you can see, even if these formats are proprietary, their use has been tolerated by the community and TK for decades at this point, so the only issue might be if the intent is to extract assets for IP infringement, or for a commercial use. As you might have guessed, the people to contact to understand how to manipulate these file formats would be Gerwin and Mue (but be polite and patient, they already contributed a lot, have a life of their own, they might not be willing and able to help as much or as fast as you'd hope, but if you ask nicely, I'm sure they'll do their best, just don't harass them). You would also need a FM and avionics guru as these are non-trivial and have their peculiarities. This would mean that decades of work on the Strike Fighters series could get a new life on a new flight simulation engine, which could, once on par with the original, fix and even extend the damn thing. This would be the best way forward, provided the file formats are not proprietary. BUT... this is a monumental task (well, getting things in a workable state is "easy", getting it working as intended, polished, stable, scalable, with decent framerates, bug-free is the monstrous task), requiring a lot of time, possibly money, and expertise. IF such a project were to happen, I would suggest it to be non-commercial, possibly open-source, and community-managed to avoid issues. Having it be a CombatAce project would provide an existing structure, community, possibly financing, access to knowledgeable people, and above all, people able to tell you that some things would be unethical by the community's standards if you were to take shortcuts the community isn't at ease with. Also, a pool of people who have played these games for decades and can thus test things for you, tell you exactly how to make it behave as intended and how to improve what we've been dying to see improved for years can't hurt. It would be important for the project to be source-available at the very least, to allow TK to independently check whether any of his code found its way into it, for the coders among us to offer advice and criticism without having to commit time to the project. Open source with an adequate licence would be even better, allowing anyone to contribute to the project without getting more involved than they can afford, or allowing the community to pick the project up should real-life force you to abandon the project at some point. It would be good for trust, transparency and long-term sustainability of such a project.

Yup, probably memory limits, SF2 is a 32 bit program, it can address/use at most 4GB of memory, heavily modded installs can end up running very, very close to that limit. My guess is that in these situations you're out of free memory to process and temporarily store the image before writing to file, but the file is created, has nothing to write into and is cleanly closed in case of error, leaving an empty file.

Reminds me of an anecdote, probably apocryphal, about the first flight test of the Airacomet; Supposedly the pilot was wearing a gorilla suit, the idea being that if anyone not part of the program witnessed it, the idea of a gorilla piloting a propellerless plane was so stupid no one would believe it anyway.

1:23, seems like some sort of what-if Soviet S-3, nice !

Macros are also useful for flare/chaff release on modern birds, instead of mashing the buttons you push once and it releases x CM over y time, by using nested menus you can make it "programmable".

The mods part should be in c:\users\[username]\Saved Games\ThirdWire

A primer/undercoat is a layer of paint you apply before your actual paint, either to increase adhesion, protect from corrosion/rust/other environmental elements, enhance shadows when talking about model painting, or a mix of all. Zinc-chromate is one such primer used in the aviation industry since at least WW2, and it's well, yellow.

Finally ! Some love for the CR, can't wait for earlier standard. Thanks Ludo and team.

Nope, the trick only works on flat parts. Imagine you have two connected textured cubes, only their interface (the part where they meet) isn't textured or even mapped to be textured. What you propose to do in this specific instance is to make all the textures of one cube transparent, opening a visual hole letting you see into the other. It can be done, it doesn't look good.

Just chiming in... If you go that direction, there are two ways to distribute this kind of mods that won't go against TK's intellectual rights : - Distribute replacement DLL/EXE using only new code. (What OpenTTD is to Transport Tycoon Deluxe, even though the "new" code on early versions was questionnable) - Distribute a patcher and patches. (What TTDPatch was to Transport Tycoon Deluxe) The reverse engineering is, in most jurisdictions, not illegal, so long as what you're reverse engineering has been obtained legally, and you're not illegally redistributing what you obtained from it. Then there is the contractual issues, by installing SF2 we agree to a long forgotten EULA, does that EULA prevent reverse-engineering ? Is that EULA legally enforceable ? Is TK still willing to defend it ? Mods tend to frown upon it because allowing it would open a can of worm, with many people not understand what they can and can't do, exposing the site to legal consequences for facilitating it. I don't agree with the heavy handed approach at times on these topics but I completely understand why as it could turn into a shitshow extremely fast.

Those are J-10s not J-20s. But yes, you're owed royalties for the idea, try contacting Xi.

Wait, Facebook is still around ?

Also, check the mission ranges. If there is a valid base, a valid plane, but the range of the plane can't put it in a mission interceptable at compatible range with the plane you chose, it will crash too. Once had that on an install, launching from a carrier, and crashed, because in the era I played, the closest enemy base supporting compatible target aircraft was too far for my flight and the enemy flight to ever meet due to the max mission ranges.

IIRC, Sea Power, they're Triassic Games, they were (with ?) Killerfish previously, they already published War on the Sea, Atlantic Fleet, Pacific Fleet and Cold Waters. As much as a loss it is to SF2, they seem to have life happen to them and seem to be on a reasonnably succesful roll so I'm glad for them.

Well, Julhelm is working with Stary on a naval simulator with the revived Microprose as an editor. So I guess he hasn't much free time on his hands these days.