Menrva

910129 OP-1 Siege

No idea, I don't know on which airfields you spawn. Anyway, don't bother. The terrain needs to be updated to the latest version which is included in ODS 30AE. I lack time due to RL unfortunately. Some day I'll manage to update it fully.

Before the Storm After the Storm A-7E skin by @yakarov79, F-16C Block 25 skin by yours truly.

Since nobody cared to fix the cockpit, I spent some time with it to produce a quick improvement. Original data; built-in gunsight (3d model nodes) and misplaced viewpoint. Improved cockpit; lighter reflections, gunsight data as in all usual SF cockpits, fixed misplaced viewpoint. Here it is: Hawk_Cockpit_Improved.zip By no means this is perfect, but at least now it is usable and the gunsight matches where you're firing at. The gunsight textures come from an old package by paulopanz, IIRC. This fix will be added to the Hawks within the ODS 30AE mod in a future update.

Please ask @swambast for permission. Even though it's included in my IraqWA terrain, he made it clear with me that it was to be exclusive for my terrain only. So before a release, double check with him. I have no problem with it being used elsewhere, but I'm not the owner of his work.

Though it's not perfect, at least it seems it's an improvement for night missions. I wonder if the DTV could be improved via shader. By default TW makes use of twColor1.FX. However, it seems in the game files there is an unused FltDTVFilter.FX shader. It doesn't work but I wonder if the code was a work in progress by TK. The game does not feature true IR images so black and white FLIR still is not a thing.

@Stary Yesterday I graduated and the IT engineer in me has been thinking about the rendering issues of your shader hack. I think they cannot be solved for good without some major hex-editing (no idea where). I'll try to explain what might be happening: your shader hack successfully moves the rendering of clouds to a lower Z value, but clouds as an entity/object are still thought by the game to be in the original, hardcoded altitude. This is why they disappear abruptly from the top border of the camera; on stock altitude values, clouds beyond the top border of the camera disappear without us players noticing. By moving the rendering of clouds to a lower altitude, we see this clearly because the disappearance behavior is still triggered by the hardcoded value TK has put. I cannot claim this is exactly what is happening in the game code, but given how it happens it makes sense to me. Needless to say, I'd love to be proven wrong, or that we manage to find that one hardcoded value that needs to be changed.

Alright, whatever suits you. It's just that this is a pinned topic on a specific matter but now it's cluttered with something else. You could have sent Stary a PM instead. Thanks anyway.

Some trivia... All river tiles are displayed in red, all road tiles are displayed in yellow. Thanks to @gerwin's latest TFDtool, I was able to calculate some stats. Since 2017, I placed manually one by one: more than 8600 rivers tiles, more than 1100 road tiles, more than 2000 city related tiles! This is just the tip of the iceberg, not counting other thousands of tiles that have been placed manually on the tilemap to better reproduce coastlines, islands and lakes. Adding roads to Eastern Europe is out of question at this stage, thankfully all farm tiles feature some kind of dirt roads so those will do fine. The terrain won't be completed anytime soon due to RL and time constraints, so I may consider releasing it as a beta sometime later. As it is now, it features "only" more than 140 airports, more than 100 SAM sites and more than 70 EW-GCI sites. City target areas exist but have no targets at this time.

@Stratos No offense, but maybe you should remove these posts starting from your question (and including this post I wrote), as they are not pertinent to the topic which is about clouds. Like Stary said, this is a crude shader tweak and it comes with rendering issues. Avionics are a totally different matter, we cannot create new functions for them from scratch. We have no source code and reverse engineering the avionics DLL library files is not feasible. Besides, during the development of ODS 30AE I tried my best to see if we could reproduce IR images for the DTV screen filter via shader. I discovered that TK did NOT implement some DirectX 10 blending operations which would be needed for that. Point being, we've beaten this horse already. Only TK can change things for good, and he won't.

Unfortunately, after further testing, it turns out this is due to the effects folder, rather big out of necessity. It puzzles me a bit as it should be totally unrelated, but it seems it is not. The game is bounded to 32bit, as such it is more limited in handling so many extra effects. There's no easy fix on the horizon.

Nope, not possible. On campaigns you can control that to a good extent, but for single missions it's just Blue Side and Red Side. Simply put, each usable runway needs a specific target area and runway data file. If you want to achieve something like you say, you still need to create two separate airport target areas, but for one of the two it may be needed to specify an invisible runway 3d model, since the proper airport 3d model would be added by the other target area.

Well, on a careful look, editing the z value on the shader as you've shown makes this issue apparent especially on the top border of the camera. Without the altitude tweak, clouds on the top border of the camera/screen no longer disappear abruptly, so this is an issue of the altitude hack. I've been experimenting and looking for a solution, but nothing positive so far. Multiplication values cause no issues, in fact I even added those to x and y properties of input.pos, and they can bring some interesting results. This is a test package I made for use on realSKY, after I experimented a little with values: realSKY_clouds_test.zip For each type of weather there is a different EnvClouds shader, so the look of clouds in each weather type can be customized separately via their own shaders. On Overcast and Inclement, clouds have been (unrealistically) added close to the 2d cloud layer (whose altitude and gameplay effect is terribly hardcoded), giving it a puffier 3d look as you approach it. Below shots show it clearly. Unless the bug with clouds disappearing abruptly is solved, this will remain a test package only. It's a pity, clouds look much better at realistic altitudes, but TK made it harder (if not impossible) for us modders to bring positive and bug-free changes, so "thank" him for that.

I watched it yesterday at the cinema with a friend. I really enjoyed the movie, and I think the storyline is decent compared to the first movie, even better on some regards. Sure, there are quirks and inaccuracies here and there, some noticeable CGI stuff, but overall I had low expectations and it surprised me a bit. Loved the aerial footage and some poignant scenes with characters. The movie objective was to be enjoyable and I think it succeded in its purpose.

Nope, overcast and inclement are 2D cloud layers, totally unrelated, they use a different rendering and shader, so all is fine. I wouldn't lower those if we could, because unfortunately the game is hardcoded to make terrain rendering invisible when above those 2D cloud layers. What this means is that on terrains spanning from sea level up to 5km or more of elevation, you'd get invisible mountains when flying over the layer, hence you can crash into or even spawn above invisible terrain. One of TK's weird (or cheap) design decisions; of course, this doesn't happen on stock terrains which hardly reach a safe value of 4km of elevation.

Exactly. The SF2 games still have a reason to exist, they may be dated but they still are a very decent platform and framework for mods. The amount of third-party content made for them is unrivalled. However, TK insists on selling them overpriced on a late 90s-looking store, thus making these games even more unknown and scam-looking. Probably we got it wrong all these years, TK actually stands for Taken Down, with reference to his own game series...

Quite true, but not the full picture. During the development of ODS 30AE we discovered that it is best to compile a global WeaponData.ini with TW's weapon editor. Not only this allows to have only relevant weapons in a mod folder and remove any unused stock and anachronistic weapons from appearing, it also allows to reorder them and, surprisingly, it seems the AI makes use of guided bombs, while in the old days they wouldn't and dumb versions were required. Bottom line is, if you're planning to do something right for a mod folder, better use the weapon editor. If you're just an end-user who wants to play with an aircraft add-on and its weapons, then you shouldn't bother about this.

Somewhere over the legendary skies of Porco Rosso... Island tiles courtesy of @tiopilotos

@Stary Just FYI, someone was working on PBR shaders for Strike Fighters 2. They seem promising, but no updates since last year and so far they break some things. Worth having a look at though: GitHub - Zackin5/StrikeFighters2-PbrShaders: Experimental PBR shaders for Strike Fighters 2

I'm so thrilled to see you, Stary! Thank you so much for this fix, indeed something can be accomplished by editing shaders; I made a slightly modified shader for changing in-game text color which is hardcoded for subtitles, it's included in ODS 30AE. Thanks! I do plan on updating it in the future, so if you wish to contribute some tweaks to it or have any suggestions about it, feel free to PM me. Welcome back! PS: Admins, please pin this topic! This should be pretty useful!

Today I just resumed some terrain modding, so I had a look at what you should add to all your concrete taxiway 3d models. Check the below statements in bold. [TargetType027] Name=Runway1 FullName=Runway ModelName=airfield1.lod TargetType=MEDIUM_RUNWAY ActiveYear=0 TargetValue=1000 UseGroundObject=FALSE DamagePoint=140.0 ArmorValue=0.0 ArmorType=0 RepairRate=10.0 StartDetectChance=100 StartIdentifiedChance=50 IncreaseDetectChanceKey=10 MaxVisibleDist=50000.0 ZBufferOffset=6.000000 FlatObject=TRUE DamagedModel= DestroyedEffect= DestroyedModel= SecondaryChance=0 Keep up the great work! I know well how tiring and annoying adding roads, rivers and lakes could be, still have the Balkans in my hard drive waiting for more work. On a real scale terrain like yours it's even more time-consuming, so big respect for what you're doing.

Usual z-buffer issues. Make sure that the 3d models of your concrete bits have the same statements of stock TW runways in the _types.ini. I don't recall exactly the names of some properties, but one was about being flat and the other about a z-buffer offset.

Sorry, I'm late to the party, have been in hospital. What Gepard says is right. If the terrain has a big time span, one in which Red Side has no carriers nor cruisers up to a certain date, then it would work as intended. But the moment you fly a single mission in a year when the Red nation has a carrier available, it's back to a naval battle ala SF2 North Atlantic. Just an opportunity to consider, my Nations Expansion mod adds Soviet/Russian Naval Aviation as a separate service. The terrain could be limited to the Soviet nation only, while all that is navy related is given the SovietNavy service I added with the mod, by editing each object's userlist.ini file. That way, it's problem solved, it would work just fine and you'd get only Blue Side with carriers.