Gunrunner

Another vote for whatever is easier for you.

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.

Yes, you set up your DSR ratio in the control panel, it then opens higher resolutions in SF2 graphic options, chose these resolutions higher than your monitor native resolution and the driver will automatically use them and rescale to your native resolution. Let's say I have a 1920x1200 monitor, when I go into the graphic tabs of SF2, the maximum resolution will be shown as 1920x1200, but if I went into the nVidia Control Panel and activated a 4x DSR ratio, the 3840x2400 resolution would also be available, if I select it, the image displayed would still be in 1920x1200 perfectly fitting my monitor but it would be downscaled from 3840x2400 automatically, giving better image quality through finer color rather than spatial resolution.

So, I read some uninformed bullshit that made my head hurt, I'll leave this here because I'm lazy and would end up being rude :

DLSS I don't know, but DSR yes, that's what I run. Just make sure to select the higher resolution in SF2 after making the change in the control panel. Don't worry, even if it's larger than your monitor's resolution the drivers will downscale it automatically to it.

Have you heard of our Lords and Saviours DSR and DLSS ? Not only does it provide better images than any AA mode, but it also comes at a fraction of the cost on most older games (for DSR) and many newer ones (for DLSS when supported).

There should be no issue, at some point there was a black screen bug if your Effects Detail were set at Unlimited rather than High but I'm not even sure that's still a problem. The bulk of problems were during the late 9x0 / early 10x0 series era if memory serves.

Purely at the top of my head after only a few hours of sleep... so, grain of salt and all that. To determine which plane to spawn the game searches for planes that : - Have the required range for the mission assigned. - Are capable of the mission assigned. - Belong to a nation assigned to the map or, failing that, are marked Exported to the right side (Enemy or Friendly). - Has compatible Start and End dates (either specific to the nation, or as export). - Succeeds at a random roll based on their availability, if the enemy nation only has one VERY_RARE plane type available, they will hardly show, if they're VERY_COMMON, they will usually show. That's for the plane showing up or not part. For the skin part, we'd need to see the INIs, my guess is that there's no specific Angolan skin for the MiG-15 so it uses the first export client for the ENEMY side, which happens to be China ? At times it pays to be hyper specific in your INI definitions, or duplicate planes in order to have granular control over what shows up, where and when, but it can become a pain in the backside.

Didn't you mean, "good luck with DAT" ? (Ok, ok, I'm out...)

Had them on occasion a few months ago too, on both Chrome and Edge, but usually reloading the page solved them. Haven't had them in a while.

Damn, that looks like absolutely stellar work. I understand the frustration but now that you know the limit, can't you find a few places to replace some tiles by more generic ones, losing a bit in details and gaining in repetition inland and in places not needing as much details while keeping the details for the coastlines and major target areas ? It would be a pity to just throw your work out. It's a pain but that's what happens when you try to push the envelope beyond what has been done before. That being said, the index stopping at 846 is weird. Damn, must be tired, somehow I missed that @Menrva had the exact same advice.