Menrva

That's the kind of help and thinking I need. Thanks for the effort, mate. Keep in mind what I stated about the WeatherAlt statement inside .msn files. Manually editing that one works. The Mission Editor by TK only allows a maximum value of 20,000 for Weather Altitude, and it does not do the job in my case. It's all about finding which .dll applies this logic and its value and where. Could it be that it's hardcoded in the TerrainEngine.dll instead? I have no idea. Worst case is that it's hardcoded in the .exe, I guess. AFAIK, it's the Mission Editor thing that broke a lot of stuff, FAC included! I even tried to trick the terrain engine into thinking that the terrain's heightmap has different values than in reality, using HeightMapOffset statements inside the terrain's _data.ini. Nothing. PS: There's no way to limit selectable weather types, otherwise there would be no issue. I can only put WeatherChance values, and those affect campaign missions only. In the single missions menu, you can always choose Inclement and Overcast. I managed to disable the heavy fog on those two weather types for the Moon terrain. By being able to give an extremely high value to the Weather Altitude, even the Moon terrain would gain a proper feeling. PS No.2: if anyone like gerwin is willing to look into the matter, let me know and I'll PM you and send the terrains for troubleshooting.

It's not really that straightforward as 1977Frenchie says, though. The Desert4 terrain contains additional target areas and alters some names of original target areas, IIRC. To have a properly working campaign, target area names referenced inside the campaign's _data.ini file must be changed as well, and it's a time consuming job. Luckily there's a mod updating all Desert campaigns to be used with the Desert4 terrain, here at this link: PS: the above mod also requires the user to install an additional terrain update by Centurion1, which alters the names of airbases. All the required stuff is linked in the mod's page.

That's true, Wrench. However, 3d clouds' altitude CAN be changed with a specific environmentsystem.ini for high terrains. Those horrible Overcast and Inclement cloud layer bitmaps, instead, always spawn at a low altitude, no matter what. There's no way to get rid of those (it would be what I need for the Moon terrain) because the game is coded to have such layer anyway, in those Weather conditions. By editing a saved mission's WeatherAlt value, I can temporarily solve the issue, I can put the layer as high as I want. Unfortunately, that statement does not alter anything if put inside the environmentsystem.ini file, and that's something I would need; I need to alter such value for when the single mission is automatically generated by the game. But TK coded it to work this way, with such low values being assigned to those weather types. It seems the only real solution is to flatten the heightmap and get rid of those deep canyons, which ATM is a big NO from me. That's how I always imagined it, LOL! I knew that the sky had that kind of shape. By editing the environmentsystem.ini, with extreme values on certain statements (there's one about the sky's max vertex height, for instance), you can uncover how the sky is modelled. Anyway, the Cloud Layer bitmaps are another thing. Those only spawn on Overcast and Inclement weather types. Otherwise, they do not exist at all.

Think out of the box, they say. And I did. I saved a mission file, having inclement weather. Opening the .MSN file revealed the following Weather statements; [Weather] WeatherType=INCLEMENT WeatherAlt=2677.597168 WeatherThickness=480.078125 HasHighLayer=FALSE FogAmount=0.664001 ContrailAlt=8007.995605 StartWindDirection=57.425541 StartWindSpeed=7.938888 WindGustingAmount=7.626858 By changing WeatherAlt to an higher value, say 20000.0, I fixed the issue! However, what we need is for this to be applied before flying the automatically generated single missions. The way the game is coded, it always assigns such low values to WeatherAlt for Inclement and Overcast weathers. I tried to put that statement inside the terrain's environmentsystem.ini, but to no avail. Looks like I am on my own in this battle. Anyone remotely interested in those Moon and Mars terrains, please wish me luck on finding a solution.

But of course, Gepard! I have edited everything to achieve orange skies, custom dust clouds, different altitude for the 3d clouds, etc. I created specific environmentsystem.ini files for the Moon and Mars. There's nothing to alter the height of those cloud layer bitmaps, I'm afraid. TK locked their altitude, it's dependent on the heightmap's minimum height, as I already stated above. The only way to fix the issue is to lower everything heightmap-wise, to the point that such impressive canyons become much uninteresting. I don't know why TK should have made it like this. I know that stock SF2 terrains are not meant to feature such deep canyons, but it's such a wasted opportunity.

Unless someone in the terrain modding department comes up with an idea on how to overcome the issue explained in the previous post, I guess I will have to halt development. Such a pity, but there's no point in proceeding if I cannot produce things as they are meant to be. Unless there's some desire from users to have uninteresting terrains with almost flat canyons and craters.

Right when TK is trying to fund an update, I uncover other "bugs" or limits, so to speak, of the terrain engine. It seems that the Overcast and Inclement cloud layer's height is hard coded, and on terrains with extreme elevation changes, the cloud layers directly spawn below the terrain, creating an horrible game-breaking bug. That shot was taken on my Mars terrain. The aircraft is sitting on an airbase at an altitude of around 7000. You can see the bug, below there's a repainted cloud layer (Overcast and Inclement are meant to represent dust storms on the planet). The terrain is not rendered at all, because it's as if I was above the cloud layer already. The minimum heightmap's height is around 1000. For testing purposes, I added a square at height 0 (meaning sea level); as a side effect, the cloud layer spawned even more below. This means that the cloud layer's height is locked and dependent on the minimum height of the terrain. To put it short, it's impossible to have a terrain with such extreme, interesting elevation changes, without triggering this bug on those weather conditions. The only way to fix it is to reduce elevation changes by a lot, and I have to say goodbye to the beautiful canyons. An awesome idea being strongly limited by a stupid, hard-coded thing. PS: I even tried some fancy tweaks, like adding a big ZBufferOffset to the CloudLayerMaterial. It doesn't work, of course.

The Angola terrain contains various bugs, target area wise, referencing missing objects and having sequencing errors. I can't tell if it's the campaigns, because many crashes are sometimes due to the terrain. I plan to fix it in the future, while remaking the heightmap and tiling from scratch. Thinking about it, the GroundFormation.DLL should have to do with the formation of ground units during air-to-ground missions. Most likely the campaign .ini files reference a wrong/missing GroundObject.

Other shots of the Moon terrain. The environment system has been tweaked to allow for stars to appear even during daylight hours. Unfortunately, the stars are the same as seen from Earth, and a day lasts 24 hours as if it was Planet Earth. At least the gravity is correct. And "here" we have blue-ish sunsets... orange skies... hmm...

Challenge accepted, people! Hope you don't mind about the F-22 being used. It's all a proof of concept, but it's very promising. A new environmentsystem.ini is being worked on (hence the colors are off), with correct inclination and gravity values (it makes up for some fun physics). The terrain will only feature a small, real scale portion of the Moon, namely an area between Mare Crisium and Mare Smythii (full of interesting craters), stock SF2 terrain size of 1000km.

I had thought about doing one, and I have some ways on how to do it. It will probably be a thing in the future.

Spinners, I do not recall the Mirage F1 being worked on here soon after TK planned Expansion 3. IIIRC it took a while before the community made a new Mirage F1 model. It's not the timing that was harsh on TK, rather bad development decisions on SF2NA (the new terrain engine didn't work as intended), game breaking bugs on SF2NA release and the constant issue of pirate sites meant that TK didn't gain as much as he deserved during the years. As far as I know, some .ini tweaks that used to work on old SF2 patch levels no longer work, not to mention player missiles being more powerful than AI ones and other issues that were introduced rather than fixed, because TK decided to do things his own way, without listening to the modding community. Is that fair on a modding community that has long supported him? I'm just playing devil's advocate.

Agree to disagree. First of all, those 3d models are bad, they do not match SF2 quality standards in any way, have no cockpits, are low poly and do not have transparent canopy glass as it should be in reality. I do not understand all the people asking TK for more content, at the funding page. Either they do not understand what the funding is all about or I don't know what, really. We have so many high quality mods here that cover so many world scenarios. Some of you may remember that there was an Expansion No. 3 planned by TK, about the Mirage F1. It didn't materialize, yet in turn we got amazingly detailed Mirage F1 models by the community here, for free. As yakarov79 said, we modders can handle the content part; we may almost feel offended if so many ask TK for more content; I mean, what have we been doing all these years here at CA? Many of us here have continuously provided new stuff, the lifeblood and backbone of SF2. On my part I think I have released some decent quality terrains and miscellaneous mods and I have others on the way, all for free.

I am not sure about updating the game to DirectX 12, though. That means it will most likely drop support for DirectX 9 and 10, and it's just what my video card is capable of. With the game using DirectX 12, I wouldn't even be able to start it. I know that I need to upgrade (if only I could afford it now), but at the same time I hope he will always keep the DirectX 9 and 10 as an option for those with weaker GPUs. The game works good enough on Windows 10 as it is. I'd rather spend the funding on fixing broken AI behaviour with guided bombs, external dispensers, and probably re-add those features he originally had envisioned since SF1, ramp starts, and more complete radio chatter.

I tried to upscale using ESRGAN, but it doesn't seem to work well with these kinds of textures. I wish I could afford AI Gigapixel, which is not freeware as ESRGAN but it's said to be better. Nonetheless, I tried to do a very quick repaint of the deck, to better portray the Kutzetsov in its operational years. The original one should have been used until 1995, I have read somewhere. It was done in a rush, so it certainly could be done better.

You'd better join forces with Gepard, since he's adding skin decals as well. If I have time, I might try to use the ESRGAN AI to better increase resolution of the deck's texture as I have found the original, smaller texture, not the blurry one included in the uploaded package. Also, don't forget the Clemenceau we've been working on ;)

The number should be changed, I think. 113 was used before it was fully operational with aircraft onboard ready to be launched. When it became fully operational, it received the 063 number.

Glad to be of help! There was no need to fiddle with the old terrain, that one was utterly broken under various aspects.

Can anyone highlight/make sticky 1 of the 237 threads that have been opened about the issue?

@Richo No offense, but have you read my posts? You do not need to flatten anything, if you download the latest version of the terrain the HFD and TFD files have been fixed already for that airfield and various others.

Ditto that. I've said this countless times, by putting the effects to Unlimited, the game uses what appears to be some badly made DirectX 10 shaders. Putting them to high, most of the game uses DirectX 9 libraries.

In addition to what Erik said; when you're looking at a file uploaded by one modder, you can also click on "Find their other files".

Most likely those 568 are mostly subvariants with different skins and armaments. As I have seen in some videos of Modern Combat, there were for instance separate Eurofighters for Germany, Italy, UK etc. Same plane with a different skin shown as a new one in the menu screen, so to speak. Those mobile games use the Unity engine, which is perfect when it comes to small, quick games for mobile and PC. The models lack a transparent canopy glass and the number of polys (which is fine for a mobile game) seems low when compared to that of stock SF2 planes. It isn't worth to port those into SF2 anyway, unless they could be easily reworked, IMHO. The clouds' rendering instead, I could use some of that! But it's a totally different engine...

AFAIK that YAP add-on is for WOV, hence why it's worse than usual, they did not use your re-release for SF2, but an older version of the terrain, I guess. Still, this does not make them less guilty. As you said, for users it's better to download and use what CombatACE has to offer. It's greater quality stuff, for free! About the _HM bitmaps, I am of the opinion that it's way better not to use them at all, given that the heightmap is properly done that is. In my 250m resolution heightmaps, I am extra careful about flattening sea areas, coastlines and airbases. Without _HM bitmaps, the terrain is all in its HFD glory, so to speak.