Menrva

They must add this kind of mission as well in MSFS 2024: https://www.instagram.com/p/Csz3-eDrPca/?igshid=Y2IzZGU1MTFhOQ== Airlifting cows with a helicopter from Swiss mountains to the vet.

@orsin There's another experiment using TODs and tweaked shader done by Stary for his Korea/Taiwan tileset. Basically the texture for TOD buildings would be a TGA and windows would be made transparent. With the tweaked shader Stary provided, windows wouldn't be affected by darkness and would be visible from a long distance, thus simulating lit interiors of the buildings. There's one major issue with this approach; you'd have to set ObjectsFade=FALSE in the Options.ini and MipMap=FALSE for SolidObjectTextureMaterial in the terrain's data.ini or else it won't work at all, and by doing so you'd get lots of very noticeable flickering which cannot be fixed. Mip mapping exists for that exact purpose and so disabling it is not ideal at all. With either mip mapping or fading enabled, this trick by Stary no longer works. This would be the best solution if the flickering could be solved somehow, but mip mapping is a necessity.

It can be done, but each city has its own size and tiling so many variations might be needed. The object requires to be set up as a ground object (as a downside, it would appear in the mission editor), not placed as a terrain object because the light effect would flicker very much otherwise. I know this since me and Jimbib added floodlights to new airbases made for the ODS 30AE mod, together with a light effect. Speaking of which, I haven't thought about using horizontal polygons for the light, we can simply use SF2's effects to create such lights, as done already on carriers and vehicles of the ODS 30AE mod. About making them destroyable, the way the game works, you'd have to make each lamp post separate sadly. Make one huge object with 50 of them and destroying one would destroy them all. All in all, it's worth a try, but there are side issues and limitations to take into account.

Nope, it's just the HUD texture that was given a green color and it makes darker areas more noticeable in-game, it's just a normal consequence to our eyes, there's a deeper scientific reason as to why green is used in real life for NVGs. The effect of the green on the HUD texture also depends a lot on the quality of the screen panel on which you play games. On my end, without cockpit, I couldn't see the terrain on the horizon at night with the realSKY mod. By enabling the cockpit, then I could distinguish the terrain from the sky thanks to the HUD's reworked texture. There is no way to add such a FLIR shader effect to the 3d model of the cockpit. Hell, we don't even have a proper FLIR shader in the game for the DTV in cockpits, which is the cheap reason why TK made nights unrealistically bright. We've been there already, we've been modding the game for two entire decades (considering SFP1 days) so we know all about the engine limitations, there's nothing new to discover about it. The only realistic solution (apart from using Unlimited Effects, thus having TW's post processing shader kick-in all the time) is to use a shader injection method like Reshade, but that one eats a lot of resources and can decrease FPS by a lot depending on the system on which you run it. I've been looking for lighter alternatives but nothing good that works in SF2 so far. All that is needed is to reproduce the shader done by simonmiller416 for use on such a shader injector (the TW .FX shader cannot be re-used as is, the shader injector usually requires its own syntax and/or language).

You can select and hide nodes in LODViewer as well before taking screenshots, it can be a useful function in this case. Keep up the great work, this is an awesome project! We could make some time trial missions on the smaller NL terrains I released a while ago, if only we had proper towers acting as route checkpoints.

A small island in the Gulf for a friend...

Hey Eric, I wasn't referring to you, so don't worry! Also, things like these tend to happen, RL these days makes us do everything faster. I'd lie if I say I have never read a post in a hurry without misunderstanding it. No worries, mate, it happens. Also, daddyairplanes pointed out a good reason, the pic I uploaded was certainly distracting. The most important info wasn't given a clear space in the post I made, so this is my mistake as well. Looking forward to seeing what you'll do with those textures, it must be an interesting project!

Thanks for noticing it. I don't know why, it's not the first time that my posts seem to be ignored or not fully understood by other users of the site. On another recent topic I suggested some solutions, but the user in that case missed it or rather focused on another post that didn't provide a solution. I'm truly wondering if something's wrong with my English, it is not my mother language

They are in ObjectData001.CAT, thanks to mue's LODViewer I got the list of textures: A-4B_pit_textures.txt Use his CAT Extractor and you can look for each single texture.

The post processing effect is applied also in daytime, so it's not an optimal solution. Only with injectors like Reshade it's possible to make something that works on a specific key press. SF2 remains very limited in how stock post processing works.

I may be wrong, but I think @Cliff7600 is the only FM guru still around. Baffmeister hasn't been around in a long time, he contributed for some time on ODS 30AE. Both are very talented! I have no such good knowledge on flight models.

The crap is yours I'm afraid, unless you believe John and Mike are still alive, cause they aren't. And the guy working on YAP-RW is an end-user (not a 3d modeller nor a modder) who bought those products. Is he at fault because he updated the products he bought for use on SF2 for free? He also was scammed if the stuff he bought was stolen and that's terrible. I don't think anyone can held him responsible for the crap done by others. That's what I meant with my post. The RW guy, unlike the original YAP guys, is at least asking for permissions in using CA mods in his rework, and he's also crediting modders. Original YAP never did this to my knowledge, they'd rather steal and monetize upon free mods. Before disliking posts trying to give a more complete perspective of the situation, think twice. I (luckily) never dealt with YAP in the past and I never cared about it. I'd obviously be angry if any of my work had been monetized by others. I'm here for creating and sharing free legitimate mods. If you had an issue with YAP in the past, it's your problem that you haven't solved it in years before the owners died. You're a nobody to call me a liar, and it's suspicious this is only your fourth post on CombatACE. Your previous three posts were about complaining that GKABS' 3d models don't work on SF1. You've never contributed anything over here from what I see, you behave like a troll. You'd rather show some respect to people in the community.

Just to clarify, it's not the YAP most over here at CA think it is. YAP-RW is a free fan-made project done almost entirely by one end-user who bought all YAP products in the past; he's been updating those so that they work on Strike Fighters 2 for his own enjoyment and simply thought about sharing what he's done for free. He's in no way related to the original YAP nor to the fact original YAP guys monetized upon freeware mods without permission. The owners of YAP died years ago and the store was still up despite not being controlled by anyone anymore. Apologies for the little off-topic, it's just that I've seen people complain about YAP-RW as if it was done or even monetized (it is not) by the same YAP guys responsible for those issues. This is a case where an unrelated end-user was held accountable by some for the issues surrounding those products, products he legitimately bought without knowing of all this chaos.

Pretty cool! Is it available somewhere? I don't recall anything like this in the SF1 download section.

Fedayeen Saddam - Wikipedia Just discovered that this helmet used by Saddam's paramilitary Fedayeen resembles the one of Star Wars.

@Wrench By the way, during the development of ODS 30AE, I discovered that the E-2C_Destroyed.LOD model (and also Yak-38_Destroyed.LOD) actually don't exist in the game files. So if you crash, there's no destroyed model for those aircraft. I use the C-47A_Destroyed.LOD for the E-2C and for this C-2A, better than nothing.

My extended thanks to the team for this release. We need proper ODS skins for the ODS 30AE mod. Any volunteers? References are available here: https://dstorm.eu/pages/en/usa/c-2.html

Most have probably missed this fact that with Strike Fighters 2 North Atlantic, additional types.ini statements for a terrain have been introduced. Here below you'll find the extra ones: [TargetTypeXXX] Reported=FALSE DetailLevel=2 FadeWithDistance=TRUE IgnoreHeading=TRUE AdjustZBuffer=FALSE The most interesting and useful statement is DetailLevel. The Ground Objects graphics setting in the options has always been rather pointless in Strike Fighters as it would only affect randomly parked aircraft. This DetailLevel statement makes it much more useful when applied to most if not all target types defined in a terrain's types.ini. DetailLevel=3 means that the target type will spawn only when Ground Object settings are set to Unlimited, a value of 1 means that the target type will only spawn when Ground Object settings are set to Medium or higher. The below screenshots show it clearly. Ground Objects set to Unlimited; even the smallest eye-candy objects are shown, loading times are obviously higher. Ground Objects set to Low; only priority objects (those that should be targets for missions) are shown, loading times are quicker. The downside is that it requires a terrain modder to add such DetailLevel statement to each of the eye-candy objects in a types.ini file. If you have 300 or more, you can imagine it takes quite a bit of work and trial and error to choose which priority to assign to each object. This update/feature will be part of the IraqWA terrain in a future update of the ODS 30AE mod. The other statements are also used in the stock IcelandNA terrain, here below a summary of what I managed to figure out about them: FadeWithDistance - No matter what, it doesn't seem to work. it would have been cool to have terrain objects fade like TOD entities; most likely this is a placeholder for something TK never implemented properly. IgnoreHeading - Rather self-explanatory, it makes the object type ignore the heading you give to it in a terrain target area of the targets.ini file. TK uses it for the countless tree LODs created for the IcelandNA terrain. AdjustZBuffer - When set to false for runways, they suffer from heavy z-buffering issues on tile based terrains. Most likely this option was needed for specific runways on the IcelandNA terrain, since runway LODs are placed over another LOD, that of the terrain. For our usual tile based terrains, this statement may be of little to no use. Reported - The only statement I couldn't figure out. For sure you wouldn't set it to false for main terrain objects. This info may be useful to terrain modders wiling to optimize their own terrains and make them more scalable depending on graphics settings. Please admins, pin this topic for future reference.

@Wilches I should have specified, do NOT use Photoshop. It doesn't save 8bit bitmaps properly. Now you have to start from scratch. Extract the water bitmap via TFDtool, repaint green and yellow areas with MS Paint. Use MS Paint or it'll most likely break.

I don't know what you're trying to achieve. Just look at the IcelandNA water bitmap. You have to use the same exact green and yellow colors (respectively indicating where friendly and enemy fleets can spawn), save it as 8bit. It's best to use MS Paint for this. You need to have ships in the GroundObject folder, with their data properly updated to SF2NA standards. Then you just have to pray and hope the game spawns stuff like you wish. Nothing else can be done. I cannot help more than this. Use the search bar on the site, I already explained how to create water bitmaps properly on several topics.

I think there's quite a lot of confusion over here. Carrier Stations are never used in single missions, they exist only for campaign use. Adding ship objects to those target areas won't achieve nothing apart from having static ships able to fire back. Naval fleets ala SF2 North Atlantic just require a proper water.bmp and the NavalMap=TRUE statement. You cannot control where the fleet exactly spawns on game generated missions, that's a limitation you cannot overcome. Only in campaign data we can specify precisely where a naval fleet or a static carrier station can be. Fleets ala SF2NA are dynamically spawned objects, nothing to do with terrain target areas.