Gunrunner

Thanks guys, I should have enough to occupy me for a moment (better pictures, some panel changes to do too, yeah) and I'll do a "best guess" on some things. What was a side-project is getting a bit more ambitious, so much to do, so little time.

They do and it is possible. The only exceptions to making a full mission are either in campaign (TRANSPORT missions and off-map based units) or irrelevant because friendlies (calling for reinforcements through the com menu, they magically spawn).

While working on a template for it I found that there's a 2/3rd of a pixel mapping shift between the left and right part of Nacelle2 (the right inboard engine nacelle; the other nacelles are affected by a much smaller shift - I'd say about 1/6th of a pixel at worst -, you have to be on top of it for it to be annoying, but on Nacelle2 it's fairly noticeable), any chance of a correction ?

What, they have no guns, but how can they defend against drone piloting neighbours and unarmed black people ? Shows how uncivilized and backward they are.

After "having" to run the thing on a GTX 950, I found a few things that made the bug not so game breaking with moderately modded installs : - remove any custom shader - set ObjectsFade=TRUE in your OPTIONS.INI - if/when the bug occurs nonetheless, go to map view for a few seconds (changing to other views doesn't seem to have the same effect), get out of it and it will be fixed in most, but not all, cases (doing it too quick doesn't seem to work for some reason)

nVidia card, 2GB Video RAM or less, with 355.xx drivers... Two temporary fixes depending on whether you can apply the first or not : 1) Roll back to older 353.xx drivers or 2) If you have a GTX 950 and/or Windows 10, remove any custom shader (keep them somewhere for when the problem gets fixed), set ObjectsFade=TRUE in your OPTIONS.INI and if/when the bug occurs nonetheless, go to map view for a few seconds, get out of it and it will be fixed in most cases

One thing I forgot to mention, there is a HUGE difference between JPG and BMP. You can put BMP at a plane or ship root directory and they'll be used unless there is a file with the same name inside a skin directory, the same thing does not work with JPG. Let's say I have a plane with 2 image files constituting a skin, it has 2 skins, but those skin only differ on the second skin file. With BMP I can set things up as follow : Aircraft\Plane\Skin_1.bmp Aircraft\Plane\Skin1\Skin_2.bmp Aircraft\Plane\Skin2\Skin_2.bmp And it will work, but if you want to do the same thing with JPG you have to do : Aircraft\Plane\Skin1\Skin_1.jpg Aircraft\Plane\Skin1\Skin_2.jpg Aircraft\Plane\Skin2\Skin_1.jpg Aircraft\Plane\Skin2\Skin_2.jpg So depending on the number of skins and the commonality between them, it might make a huge size difference (because one 3MB BMP file is smaller than 12 600kB JPG files). It also means that converting BMP in place might end up with broken textures. Keep in mind though that you can mix and match file types, making : Aircraft\Plane\Skin_1.bmp Aircraft\Plane\Skin1\Skin_2.jpg Aircraft\Plane\Skin2\Skin_2.jpg possible and probably most efficient in cases of a large number of skins with high commonality.

No solution as of yet, apart from rolling back to 353.xx drivers (unless you are a GTX 950 owner), sorry. Apparently setting a few parameters directly with the nVidia config app slightly mitigates the problem but doesn't solve it entirely, it seems memory related and a change in how things are dealt with when you use more memory than the card has (having a 4GB card might mitigate the problem but most of the heavy modded installs usually seen here will come across that problem too, it's definitely not worth spending cash hoping to solve the problem that way).

Let me guess, you have a nVidia based card, with 2GB of VRAM and running 355.xx drivers ?

Let's see, a typical 1024x1024 BMP is always 3MB, the JPG version with the lowest compression (100% quality) is around 600-700kB, the DDS version with MIP images is around 650-750kB. The more complex the skin is, the heavier the JPG will be (conversely, a 1024x1024 skin consisting only of pixels of a single colour would be around 20kB), BMP and DDS however always have the same file size for the same spatial dimensions. BMP is frankly the worst format, it takes more space on disk and it takes longer to load (because nowadays it's faster to decompress a JPG/DDS than read a BMP, this hasn't always been the case). JPG is a nice intermediary, it takes the least space and it's fast to load, however it requires a bit more processing to load than DDS and takes up more VRAM than DDS (NB: with Kerbal Space Program, I'm not sure it holds true for Strike Fighters 2, I'll have to check). DDS are the best, they take only marginally more space than JPG in typical situations, they load the fastest and use the least amount of VRAM (see the NB above). P.S. : "Lossless" JPG produced by some graphic software as well as the one included as stock by ThirdWire may actually be larger than DDS in many cases. P.P.S. : Take into account that DDS is an accepted format only for skins, your best bet for mass conversion is JPG (and even then, there are a few instances where only BMP are read, demonstrating how "sub-optimal" some parts of the code are).

From my experimentations it seems video RAM related, I've tried the following, all with exactly the same settings, all using a mission that gives me a VRAM usage around 1.9GB with the 353 drivers. 353 Drivers : Windows 7 x64, GeForce GTX 760 2GB : No bugs. Windows 7 x64, GeForce GTX 960 4GB : No bugs. Windows 7 x64, GeForce GTX 970 4GB : No bugs. 355 Drivers : Windows 7 x64, GeForce GTX 760 2GB : Bugs, VRAM swapping. Windows 7 x64, GeForce GTX 950 2GB : Bugs, VRAM swapping. Windows 7 x64, GeForce GTX 960 4GB : No bugs, VRAM usage around 2.3GB. Windows 7 x64, GeForce GTX 970 4GB : No bugs, VRAM usage around 2.3GB. That led to three things to test : 1) What happens with 353 drivers when you use more than 2GB on a 2GB card. 2) What happens with 355 drivers when you use less than 2GB on a 2GB card. 3) What happens with 355 drivers when you use more than 4GB on a 4GB card. So I tailored my install and missions to test these... I only have a small sample because swapping cards and drivers is time consuming but so far : 1) Degraded performances, stuttering and similar bugs. 2) No bugs. 3) This is where things became interesting, for a variety of reasons I didn't manage to consistently have more than 4GB VRAM usage (varied between 3.5GB and 4.2GB depending on the run). However it showed something interesting; Above 4GB, both the GTX960 and GTX970 displayed the same bugs as the GTX760 and GTX950, at 3.5GB however, the GTX960 had no bugs while the GTX970 displayed them intermittently (there for a few dozen frames then gone, then some more appears and so on). It would seem that for some reason (frame buffer increase I'll guess) : a) 355 drivers lead to an increased VRAM consumption with Strike Fighters 2 with settings left to default. b) 355 drivers implement a different way to deal with VRAM when the card reaches full usage, favoring the conservation of framerate over texture display (with 353 drivers you slow down to a slideshow before having texture problems, with 355 you lose textures first). Anyone can try reproducing, confirming or discrediting that hypothesis (if true it would mean that stock installs should not have display problems on a 2GB card) ?

Too many mods. In short, you installed a third party RAF bird with decals setup to use a variant of the RAF nation sharing the same NationID as North Korea in your NATIONS.INI, that's why many mods are intended to be used on separate installs rather than merged with others mods.

Oasis ? *snorts derisively* Blur, baby, Blur...

Do335, once more, sorry for the tone but your own really annoyed me and the idea was, from my point of view, so ill-thought out it was insulting (come on, even defending it you admitted it wouldn't work on at last two levels if you were the target audience). But hey, if you have other ideas, I'm game, I'm much, much better at finding problems than solutions.

@Do335, as a matter of fact, yes (just not often for SF), but you like to tell little stories to illustrate your point, let me do the same for mine... - Hey girl (modder), what are you doing this week end ? - Well, I haven't add time to see my boyfriend (work on my Yak-36 project) for a long time so... you know... - Come on, that's lame, dump it and come spend some time with us instead (work on a F7U for us) ! - Nah, I'm not into that. - Come on, we'll pay you, I know you can use the money ! See the problem ? Donate money to modders without conditions ? Yes Refund modders their source materials, info gathering trips or necessary tools ? Yes Properly commission modders who advertise themselves as available for commision work ? Yes Exploit the financial needs of modders to have them work on what you want rather than what they'd rather do ? Fuck no What we need is something to patronize (in the noble sense) modders, and organize commission work, not a Mechanical Turk for Mods. Look, I understand where you're coming from and that it's well meant, but quite frankly even in an ideal world it'd fraught with problems and we're far from living in an ideal world. On another note, if you ever negotiate something with TK regarding the code, make sure to include some measure of support, I'd wager that the source code is not extensively commented (or at least not necessarily in any useful way for a 3rd party) and that documentation if it exists might be a few revisions late (That's not a jab at TK, it's just that for small outfits these things are certainly not a priority, been there, both as the original coder and the one tasked to make sense of someone else's work) and it might save you (or any coder ending up dealing with it) weeks if not months of work to have access to the man himself (not that he wouldn't help otherwise, but if it's part of the contract it's easier to guarantee it).

Do335, it doesn't matter, if it is free but has been lifted from another game, stolen from another modeller, used against the original licence, we'd still have a disaster on our hands. And yes, you would have a lot of foul play, we've only had a few so far and they've usually been swiftly taken care of, but once there's money involved, they'll be everywhere... The most basic will be some guy will buy/license a 3rd party model to adapt it, never minding he did so under the conditions that it's strictly for personal use, therefore his adaptation could not be distributed under terms compatible with your idea. Hell, many would do it without even thinking they are doing something wrong. As for your suggestion that the idea would only be for recognized modders, it is preposterous... You're telling me that you intend on solving the problem of too little modders with too little free time by... not adding any modders but using money to influence modders into reallocating their precious free time in ways that benefit you ? That's even less likely to work and I find fairly insulting for the modders because it suggests 1) that you think they should rather spend their modding time according to your piorities rather than their own, 2) that they are currently not contributing enough, 3) that money can motivate them to contribute more. They are not cats, you can't distract them from their current occupation by dangling a piece of foil in front of them, have some respect. And what do you think will happen the day most core modders will feel modding is becoming a chore ? Patronize them (as in, be their patron), commission them, but don't treat them like animals. Sure, some modders are pros or semi-pros and would be more interested in paid work and have retired from SF modding, but in that case... commission them the proper way, not through some pseudo-kickstarter. And sorry for the tone but you have royally pissed me off. @Stratos, he's probably suggesting that you two contact TK to negotiate one of the following : 1) Commission TK/TW to update the game engine to your specifications 2) Obtain a licence to the engine, with source code, documentation and content creation tools and the rights to continue development for the community 3) Outright buy the game, engine etc... And that anything less isn't enough.

Do335, with all due respect, it's not only not a good idea, it's also a potentially community destroying idea. Basically you're diminishing the efforts of volunteers and incentivizing less dedicated and scrupulous ones to take action potentially leading to decreasing quality control (discouraging existing high quality volunteer modders) and creating a host of problems (reverse engineering, use of asset without proper permissions, downright theft of models). I have no problem with an unofficial fund to help fund source material, fact finding trips and cover other expenses for recognized and high quality modders, or even a sort of Patreon for modders (even though most here would shudder at something they'd consider a handout I think), but your idea as it is formulated is unfortunately a recipe for disaster (remember, the community is not just us nice and reasonable forum-active people). I think the DAT schism is detrimental enough to the community, we don't need another one because we tried to implement a bad solution to a misdiagnosed perceived problem. As mentioned by others, it also puts the community into a whole other dimension from the legal and licensing point of view, and what were nice, tacit, gentlemen's agreements (or ignorance) will turn into a legal nightmare very quickly.

@Snailman, but the pre-purchase came with the season ticket, which would include the laser weapons and opponent plane hacking DLCs. It might be a bargain (or extremely expensive for no good reason).

Slick Cowboy, is that a 2GB or 4GB GTX 960 ? I have issues with a 2GB GTX 950 (which unfortunately can't use anything earlier thant 355.xx drivers) but none with a 4GB GTX 970 (even with 355.xx drivers). I'd wager this has to do with a combination of the game and drivers memory management on cards with "low" memory quantity/bandwidth when playing on high/unlimited with highly modded installs (large textures, modded environment.ini etc).

If you intend to use the dhimar decals included with the game, Dhimar HAS to be [nation256] to correctly use level 0 (country/service) decals. Also make sure that in decals.ini decals supposed to be insignias - and other country level decorations using the country numbering scheme - are set to DecalLevel=0. Another way is to create a nation specific skin duplicate and add 256 at the end of the FilenameFormat of concerned level 0 decals (i.e. FilenameFormat=Insignia should become FilenameFormat=Insignia256 if it's a Dhimar skin). Yet another way is to extract the Dhimar decals and rename them with the nation number you used in your modified nations.ini, but that's the least graceful way to do it. P.S.: The same applies for Paran, except that Paran should be [nation257]. Also, use placeholders between your last nation and Dhimar/Paran, if you skip numbers in the nations.ini it won't work properly.

Sex-ed for war planes, brilliant.

Nice; She's usually F-111B Manatee on my installs to match the equally ridiculously named Aardvark, but that wouldn't make for a nice patch...

Paran will invade Dhimar... again ?!

@russo, yeah, so Wrench has BIG hands, got a problem with that ? :)

Any chance of a 4000-5F (same pylons as the N, same nose as the M, with SPIRALE dispensers at the wingroot (at the back)) ?