Gunrunner

Convert your files from BMP to JPG; simplest way, open with Paint, select "Save as..." and choose JPG, then post like you did for your first try, the picture should show up. CA_Stary, that's impressive... I just love it however, in case of war, wouldn't there be some kind of curfew ?

Are you sure you didn't use an old weapons editor and an up-to-date SFG, or vice-versa ? Until the latest patch, you must use the old weapons editor, with the latest patch, you must use the new weapons editor.

Have played with Harpoon when it was still only a rule for miniatures, then with the Classic series, the II, and the early III... I spent countless week-ends with them... Unfortunately I discovered that I can't play either the II or my early III anymore (the II can't find the DRM, and the III apparently can't find its registration), still not sure whether taking the plunge for the new III, with multiplayer, is worth it...

Errr, that's usually normal, as DX7/8, DX9 and DX10 are rather different beasts with rather different code path, most GPU are optimised for the latest and greatest DX at the time of conception, and legacy functions are, in a way, emulated, often leading to "decreased" performances in older games. But that's not all, as for all games, even with brute numbers down, it still is more than enough to play at full resolution. Benchmarks are NOT a way to measure graphic performances, they are a way to show off your brand new hardware, you should NOT take the numbers generated by these useless piece of crap as any indication of performance and rather play the games you want to play and compare the real case figures...

That's what I was saying, let me recap things so far : In SF1 : a- /SFP1/Objects/Aicraft/MirageF1/MirageF1.LOD calls for miragecanopy.tga b- SF1 engine searches for /SFP1/Objects/Aicraft/MirageF1/miragecanopy.tga If it is found, then he uses it... Else... c- SF1 engine searches for miragecanopy.tga inside OBJECTDATA.CAT If it is found, then he uses it... Else... d- It either crashes or uses a perfectly transparent canopy... In SF2 : a- /SF2/Objects/Aicraft/MirageF1/MirageF1.LOD calls for miragecanopy.tga c- SF2 engine searches for miragecanopy.tga inside OBJECTDATA.CAT If it is found, then he uses it... Else... d- It uses a perfectly transparent canopy... It seems like either the b- step is missing completely from the SF2 engine OR the b- step is searching in another directory. BTW, do any of you understand pseudo-code, it may be somewhat easier to use than trying something more verbose versions...

IIRC, yes it is, but it would be even better to find out where the SF2 engine expects the TGA to be. Or maybe asking TK might be fruitful, as it might also be a bug in the new engine that he can't know about (as he has little reason to expect TGAs outside of CATs).

It might be that the TGA is missing; Either because the LOD calls for a TGA missing in the SF2 OBJECTDATA.CAT, or because instead of searching the TGA at the root of the airplane directory the engine now searches for it elsewhere. I can't offer more without a list of which addons work and which doesn't. One simple way to know which file the LOD calls, simply open the LOD in any good text editor or hex editor, and search for TGA, usually the first occurence of the string is the call made for the canopy.

IIRC, it's a TGA called from the LOD, at least it's the way I remember from the TMF F-16s.

GreyCap> Well, usually it depends on the year you're playing, the campaign, and learning it the hard way through previous missions... once you know enough, you see where the mission will lead you and the potential SAM opposition.

Well, there will be one when Marco's satisfied with it... (unless he dropped the project ?)

Nope, I think he meant the US bought MiGs for agressor training...

AleDucat> Except a lot of photos are poorly labelled, based on Cold War data, and what you might see labelled as an early Yak-38 might be in fact a late Yak-36M. Krizis> Thanks for sharing part of your references, it's quite interesting to see something more extensive and fresher than what I've seen yet.

So, according to your drawings, ALL Yak-38 and Yak-38M had intake splitter plates ? Damn, good thing I stopped trying, there seems to be no two source saying the same thing -_-

True, but we still forget the fact that PC gaming, once a sector by passionate people for passionate people with very little profits, has become a behemoth industry, with only profits as a benchmark, and while most developers still are out there to make products they can be proud of, the various intermediaries, actually funding the projects are there only to make as much money out of it, as fast as possible, and flight sims, even with a large appeal, are no such product.

Wait, were Falcons ever meant to hit a target ? I never ever managed to hit anything with, not even nice slow bombers, the damn thing managed to miss them...

They've gone out of fashion 10 years ago, along with real wargames (miniatures, pen and paper or computer), pen & paper RPGs, model kits and a whole host of classical hobies, now replaced by console games and... well, console games... It's a cultural thing as much as an economical one... Culturally, these hobbies require too much time, too much learning, offer delayed gratification... Economically, there is little interest to get money to produce such things when the market is shrinking and there are more profitable sectors, the shrinking in demand leading to a shrinking in offer, in turn shrinking demand etc... these hobbies fell below their critical mass.

Surely you are joking, right ? The Phantom is a navy bird...

Nice drawing Krisis, never seen it before, that changes the external distinctions quite a bit... Let me sum it up, for the major ones that would show up in the model : Early Yak-38 No intake splitter plate, no dorsal "dam", no ventral "dam", small rear facing "RWR?" Late Yak-38 Intake splitter plates, dorsal "dam", ventral "dam", small rear facing "RWR?" Early Yak-38M Intake splitter plates, dorsal "dam", ventral "dam", additional air intake(s) near the vertical stab, large rear facing "RWR?"

Just a suggestion... As Lindr2 pointed out, someone on the russian part of the forums (Krizis) is already working on one, and making good progress too... It's not a reason to scrap either project, but maybe you could join up and share the workload, working together, one concentrating on the Yak-38, the other on the Yak-38M (or one on the Yak-38/Yak-38M and the other on the Yak-38U), or one on the airframes, the other on the pit if you decide that one of your model is better or easier to map than the other. BTW Krizis, your model seems a bit of a hybrid, as it seems to have the dorsal strakes of the Yak-38M, the ventral strakes of the Yak-38M and late Yak-38 (from the photos I have, the early Yak-38 seem to lack them, but I found the fact mentionned nowhere yet), but lacks the splitter plate in front of the intakes that is typical of the Yak-38M. No offense taken I hope.

Nice find, except that would mean the weapon editor reads inside objectdata.cat. But I just tried and it works fine on a system where there's no TW game to be found, hence, while it "may" allow the game to read a weapondata.dat with more than 2048/2049 entries, it won't help generating one with the editor. Besides, this INI file looks more like the configuration file for the number of "displayed" objects in game (in flight), the various categories they fall into and how the game engine should treat them.

That would still make sense as calculating from the LOD for ground objects, especially when most use simplified models, would be inconsistent, forcing to set "static" values. In fact that might be an argument in favor of a LOD-derived base RCS, as if it is statically set for ground objects, why can't it be for planes, it would be so much easier than a modifier set against an unknown value (simpler both for modders and TK, internally).

Have you tried switching weapons ? In the INI, exchange the content of entries 2049 and 2050. If the file still truncates at 2049, then it's an editor limitation, if it truncates at 2048 then one of your weapons doesn't parse correctly and the editor stop parsing once it reaches it, so correcting the weapon entry would fix the problem. Off the top of my head, if it's the editor's fault, there may be 3 types of limitation of the editor that might cause such a problem : 1) The editor uses a counter limited to 2049 values, dropping anything beyond, which seems surprising... one would understand 2048, but 2049 seems strange, but it's late and I might be missing something; most probable. 2) The editor uses a buffer to keep ALL weapons while parsing them, and when out of buffer, writes all the complete weapons, dropping the rest (corollary, the longer your weapon entries, the less weapons you could use); very unlikely. 3) The editor has a hard set size limit for the maximum size of WEAPONDATA.DAT, in practice it ends up doing the same as 2); unlikely.

That would be about the most elegant way to do it, yet a hard one to mod for, as unless you can get access to the actual numbers used internally, the only way to adjust the RCS will be guesswork (well, it is guesswork now anyway). Also, using such a method would imply that the way planes are modeled would impact the base RCS (ie. modelling rotating fan blades would return a higher base RCS than not doing it and getting them by a pasted texture).

Mostly depends on the opposing SAM forces. While going out en-masse is a great way for them to get experience, when faced with SAMs they usually end up being SAM-fodder, so in such cases I try to limit the number of pilots to the absolute minimum.

Nice, some more Bears, and they're not dancing :D Not to sound greedy, but do you guys have, by any chance, plan to work on Tu-95RTs, Tu-95MR , Tu-142 and Tu-126 ?