Gunrunner

With SF2 to guarantee a plane to show up for a specific nation reliably it must either be the primary operator or have a userlist entry for the nation. For example in your MyAircraft.INI file you need to have : [AircraftData] AircraftFullName=Whatever (...) Userlist=MyAircraft_Userlist.ini (...) then you need a MyAircraft_Userlist.ini file with content following the syntax : [China] ServiceStartYear=1980 ServiceEndYear=1990 Availability=COMMON [Russia] ServiceStartYear=1978 ServiceEndYear=1988 Availability=VERY_COMMON The nation names in brackets being the NationName used in your Nations.ini (and it works with nation declared locally in a terrain as per my previous post). Entries in the Userlist have priority over entries in the AircraftData (so the AircraftData might say the plane is not exported to the Enemy and had a service end year of 1985, but has long as there is an entry in the Userlist for an enemy nation, beyond 1985, it will be picked up nevertheless). Really, the service dates and availabilities in the AircraftData files should be considered deprecated, and a Userlist as the preferable and reliable method to do things. Seems I was wrong, the statements do not have the same usage. The service dates in the AircraftData files are for determining the availability dates for the player or, should a UserList be missing, for AI planes as well; while the UserList is used only to determine which planes to spawn for the AI.

Do the Chinese have aircrafts with compatible service dates ? Do these aircrafts have missions types compatible with the player flown mission (Intercept vs Strike, CAP vs Sweep, and so on) and the terrain ? Do these aircrafts have the range required to perform assigned missions ? These are 3 things I'd check if we are to assume the problem lies with the planeset.

Actually, this isn't the whole truth (what Wrench said being true, but not the whole picture). The first format is for using Nations already set in the global NATIONS.INI file (this is usually all SF2 needs) or set within the local *_NATIONS.INI file (requiring further declarations). The second format is to set new Nations, not already present in the global NATIONS.INI, for use by the AI only (as you can't select the defined nation otherwise); you have to make sure it uses a unique NationID though as duplicates MAY cause problems (usually doesn't because they exist as SF1 legacy, representing the same nations with same names and IDs). I use this to prune nations I don't intend to fly from the global NATIONS.INI, while adding them to their specific terrains, allowing me to have a shorter, more pertinent service list to choose from, while keeping everything working as intended. In short, in SF2 they're complementing each other for specific purposes, not alternatives. For example you can do something like : [LimitedNationList] FriendlyNation001=Australia FriendlyNation002=AustralianNavy FriendlyNation003=NewZealand EnemyNation001=Indonesia EnemyNation002=China EnemyNation003=Mordor [Nation001] NationID=xxx (ideally a number greater than the last one used in the NATION.INI, but I haven't tested if it's required to be in sequence or if gaps in the sequence are supported, assume it's not) Name=Mordor DisplayName=Mordor Alignment=Enemy PilotNameList=NamesChineseWG.lst RankList=RanksUSAF.lst CallsignList=CallsignsUS.lst Formation.Fighter=USFighter Formation.Attack=USFighter Formation.Bomber=USBomber Formation.Transport=USBomber Formation.Tank=USTank Formation.MobileAD=USAD PilotTrainingStandard=Normal GenderRatio=0

There's a field "SF2 Installation Directory" in the "CAT File Access" field of the "Extra/Settings" tab of the LOD Viewer, than when it's set to your... drumroll... SF2 Installation Directory (that is, by default "C:/Program Files (x86)/ThirdWire/Strike Fighters 2" of course, and should be pre-set) and the checkbox is Enabled, allows the LOD Viewer to read LODs inside CAT files (for that you read not the LOD file obviously, but the main object INI, so for the A-1H, you'd read AH-1.INI using the LOD Viewer).

Can you imagine engaged in dogfight with a few tons of bombs ? It makes you less maneuverable, it makes it risky because you're taking the risk of the attach point/pylon/wing breaking under the stress, and if you're not breaking anything and survive the engagement, you have a high risk that the release or detonation mechanism will not work as intended. It's normal behaviour for the period covered by the sim. As the mission leader, it's up to you to give relevant orders, you order them to attack, only their guns qualify for ground attack, therefore they resort to suicidal strafing. Of course that creates problems when you are flying modern swing-role aircrafts with modern ordnance.

In my experience there's no point in using LAA with the SF series, VRAM being a problem much faster than RAM will ever be.

Yep, TK has lost the plot, to compensate the loss of revenue that the loss of sales volume created, he increased his prices. Frankly, if I were him, I'd go next door ask Chris Roberts if he needed someone with an aero engineering degree and flight sim experience to join his team for atmospheric flight, then try to sell him the idea of a Strike Commander/Pacific Strike/Wings of Glory successor, or get sold on the idea of fan funding.

We don't have a Kuznetsov, only an Ulianovsk and a Minsk. We also don't have a Charles de Gaulle (well, we have one but with crappy statics baked in unfortunately).

That's not a "problem" it's the way the engine renders relief attenuated by atmospheric haze at a distance, it's not always very aesthetic against some skyboxes (as in your picture), it might necessitate some color tweaks,and the effect might benefit from being more gradual and subtle, but that's what we have, you didn't do anything wrong.

Environment : July 2013 patch-level, SF2NA. Only in Single Missions, on NavalMap. In non-stock installs. Conditions : If using a land-based plane. If the enemy is the side with a carrier group. Rarely. On any mission type. Might only happen with some planes. Possibly related to improperly configured INIs, but no common error found in terrains and planes exhibiting this bug. Expected result : The engine generates a mission of the chosen type, for the chosen aircraft type. Result : Randomly, instead of generating the expected player mission, the player will be assigned to one of the NAVAL_SEARCH missions generated, for his service, even if the plane is non-player flyable (no cockpit available). The expected mission the player chose is not generated. Stock Frequency : 0 Specific Frequency : 1 Severity : 4 Test environment : On demand Potential fixes : - Uncertain given the unclear conditions. Menrva, if you are using the frequency and severity scale I suggested, you would be using 4 at max, as the bug doesn't happen every time, and it's only making it impossible to finish the mission, not crash the game, unless I misunderstood the bug. Stratos, if you want this to pick up, I'd suggest contacting old timers and modders, who have been working around bugs for up to a decade now and probably have some very interesting bugs and ideas to contribute, consider also this not being simply for a future patch, but a catalog of known bugs for modders to know about, a part of the knowledge base to ease the life of modders, so they know what to avoid, get an idea how to avoid running into that bug or be reassured the problems comes from a known bug and not a flaw in their work.

Menrva, your terrain revision is the base, but I know my way around, it also happens with Iceland or any terrain I tried, it's definitely an engine bug*. * Well, it's a corner case, the code was never meant to be faced with such a configuration, so it's not a game bug, just a case of the engine taking a shortcut because it knows which limited cases it will face and bypass the necessary steps to face other cases, it's a time-saving, cost-saving measure that's not future-proofed, but given the budget and manpower constraints of TK's operations, that is perfectly fine, it's only for us tinkerers that it becomes an issue.

Let's start with something that's kind of a corner case but irritates me greatly on my Madagascar/Mozambique install. Stock Frequency : The frequency at which the bug can be reproduced in a full stock game, from 0 (Never) to 5 (always when following the conditions). Specific Frequency : The frequency at which the bug can be reproduced in the specific game setup, from 0 (Never) to 5 (always when following the conditions). Severity : How bad the bug is. 1 (occasional annoyance), 2 (Recurring annoyance), 3 (Immersion breaking, game can be played, missions won, but things are weird enough you're constantly aware of it), 4 (Gameplay breaking) or 5 (Game breaking/crashing/freezing/CTD). Test environment : Either stock, a link to the necessary files, on demand so people interested in testing and reproducing can contact the bug reporter to obtain the necessary files, or closed if for some reason the bug reporter can't provide a test environment. Environment : July 2013 patch-level, SF2NA. Only in Single Missions, on NavalMap. In non-stock installs. Conditions : If the only bases available to player are carrier groups and off-map bases. If there are multiple friendly nations with player available planes. If the player tries flying an ESCORT mission for a service other than FriendlyNation001. If FriendlyNation001 only has planes using a MinBaseSize larger than the carrier generated for the player. Expected result : The engine generates a flight of the same nation to be escorted by the player, based on the same carrier group. Result : The engine generates a flight to be escorted only from FriendlyNation001, but failing to assign a plane with the right MinBaseSize (because it doesn't exist), assigns one from the next available size (effectively trying to have MinBaseSize=MEDIUM planes take off from a CarrierBaseSize=SMALL carrier) leading to the flight failing to populate and a mission that can only be failed by the player (since the ESCORTed flight never takes off, it can never reach its objective, automatically making it impossible for the player to achieve his own). Other missions non-player flights are similarly afflicted but since they are non-essential to the player's own mission, their failure to populate has no impact on the player apart from skies mostly empty of friendlies. Land bases in similarly constrained situations do not seem to suffer from the same problem as the engine seems not to limit itself to the planes available to FriendlyNation001, more controlled testing needed to validate it. Stock Frequency : 0 Specific Frequency : 5 Severity : 4 Test environment : On demand Potential fixes : - Instead of defaulting to FriendlyNation001 for the escorted flight, default to the player's nation. - Provided there is another friendly carrier station on the map, populate another carrier group from FriendlyNation001 to serve as a base for the escorted flight.

Let's not put the cart before the horse. 1, collect bug reports, as detailed as possible, with steps to reproducibility, details on the configurations. 2, triage of the bugs by severity and priority, elimination of non-reproducible bugs and non-bugs. 3, collect feature suggestions. 4, triage and prioritise, first feature changes, then new features to implement. 5, add core engine changes (think, moving to DX11, or Vulkan, adding an API for exporting flight data, add multiplayer). 6, draft a formal document. Then, once this is done and the community involved, we will worry about the next step, let's not start daydreaming and bypass the groundwork to fantasise about the future.

Let's start with drafting what we need; Whatever road is taken, this is something that WILL be needed, and it WILL be necessary to convince TK that we are serious about it. That we aren't even able to do the simplest step is not going to inspire confidence when trying to find devs or negotiating a licence with TK.

Or, draft a list of bugs we want fixed, the changes and new features we want implemented, ask TK for a quote on how much it would take to implement them, have the community finance the work, provide the testing and QA and let TK release it as a new patch. It's really the most realistic path forward, the one with the least moving parts, the shortest timeframe and the best chance of success. Just contract TK to fix/update his own work.

I suppose it's because in typical soviet fashion the exported Fulcrums were "monkey models", probably equipped with MiG-23 radar and weapon systems. Think of it as the MiG-29 version of the MiG-23MS. What's surprising is that a high-profile client like Turkey would be given a version downgraded to that point, until you factor that Turkey is only at odds with the US, and through other western countries might compromise the MiG-29 radar and weapons system, so it makes sense to only give them a functional but outdated system.

JH-8, eh ? mkay...That sounds like a serious, well-researched publication...

Soon in a farmer's field near you !

No no, the content in the subcategories isn't picked up in the categories above them. Ah, now it's back apparently.

There is a problem with your trick to show the content of child nodes in parent nodes (eg. if the structure is Modern Era>US Origin>F-15>newest mod, newest mod only shows when you're at the F-15 node, not US Origin or Modern Era), the recursion seems to be broken, and has been for about two weeks AFAIR.

Yeah, that's why if you are relatively close to open water, you'd better go with the Navy these days, they deliver not only from planes but ships also. Or you could go with UPS, but they require you to be here to sign for delivery.

You don't, the Fake Pilot method doesn't work for that. Ok, let's say you have a plane with a Fuselage node, an Antenna node, which you want to remove, there are 2 methods to hide a node : 1) The Delete node method [AircraftData] ... Component[xxx]=HideAntenna [HideAntenna] ParentComponentName=Fuselage (regardless of the actual inheritance) ModelNodeName=Antenna DestroyedNodeName=Antenna DetachWhenDestroyed=TRUE HasAeroCoefficient=FALSE 2) The fake fuel tank method - Set up a LODless, almost empty and massless fuel tank as a new weapon (it needs to have a non-0 fuel capacity and weight to work AFAIR), make sure to have idiotic dates or stationcodes guaranteeing they can't be manually loaded. - If you are below the maximum number of WeaponStations : [Fuselage] ... SystemName[xxx]=HideAntenna [HideAntenna] SystemType=WEAPON_STATION StationID=xx StationGroupID=7 (This is so they can't be added back manually, they can be added through _loadout.ini though) StationType=EXTERNAL AttachmentPosition=0.0,0.0,0.0 AttachmentAngles=0.0,0.0,0.0 AllowedWeaponClass=FT AttachmentType= ModelNodeName= PylonMass=0.01 (Not sure if massless pylons work) FuelTankName=DummyFuelTank (or whathever name you used) FuelTankNodeName=Antenna If you aren't, just add the FuelTank parts to an existing WeaponStation not already having FuelTank entries. I personally favour the fuel tank method as I find the other... inelegant, but it's the historic one. There's also a third one, setting up the node to hide as a pylon or rail, but I don't remember the details and it usually requires a bit more fiddling to get right (plus it tends to waste more WeaponStations). That's the best I can do out of the top of my head, I'll let others correct me if I missed something.

Not allowed for me either.

Probably because it's not the same Nation, keep in mind that countries with multiple entries for each of their services are considered separate nations by the game engine. So for instance, if you try to load a USAF weapon on a USN plane, the dates used will be the export ones. Also IIRC the date checks are done for the player aircraft's nation at mission load, not the aircraft's nation of origin, so if you load a stock USAF Phantom but as a Greek Air Force one, the available weapons will be the ones available for export, if you change back to USAF in the loadout page, the available weapons will not be updated.