[GTSVA]

Oh...ok thanks

[Jeff Vader]

Anyone know where I can get a build that supports Normal maps as well as the resolution fix?

It seems I can have one or the other, but I can't find one that does both. Would be much appreciated.

As far as I know, there is no such build that would do them both. At the moment you just have to decide which one is more important: the normal map support or the widescreen support.

[Shiku]

*sigh* Thanks Lobo.

Well I guess the normal maps it is then, I already know how to lead my targets.

[Zacam]

3.6.10-XT does both. (Widescreen and Normal Maps)

Xt0314-win32.rar

You will need this to:
sdr1112.rar

The shader VP goes into the mediavp's folder.

[Shiku]

Thank you Zacam!

Time to give this a spin.

[Jeff Vader]

3.6.10-XT does both. (Widescreen and Normal Maps)

What's all this, then? Why was I not informed? I already had this build but no. I was all like "this only supports normal maps so I'll just play in 1024x768 to avoid pain". Damnation.

Ach. Thanks for pointing that out. though.

[chief1983]

You will need this to:
sdr1112.rar

Wouldn't he rather have sdr1119.rar?  I read at one point that was the recommended one.

[Herra Tohtori]

You will need this to:
sdr1112.rar

Wouldn't he rather have sdr1119.rar?  I read at one point that was the recommended one.

sdr1119 is indeed supposedly recommended version, but as I and Zacam found out rather recently it has a rather remarkable bug with nameplate rendering, which makes a rather strange display on ships which have nameplates (ie. almost all cap ships). Namely, the nameplate texture looks like it's being used like a shinemap (intensity changes based on the angle of lighting) instead of being a constant diffuse texture.

The sdr1113.vp introduced this problem, while it is not present in 1112. However, on my installation the normal maps don't even show while using 1112 only. I have solved this issue by shoving both sdr1112.vp and sdr1119.vp on my mediaVP's folder, which is a horrible solution but I just can't bother to cross-reference the shader effect files to find out which is the one responsible for nameplate errors, and only replace the 1119 version of it with the 1112 version... having both in same directory causes all identically named files in sdr1112.vp take precedence over the ones in sdr1119 .vp because of filenames. Ideally, I would isolate the shader responsible for making nameplate rendering break, and put just that in mediavps/data/effects/ and have just that override the faulty one in sdr1119.vp, but as I said, I just don't feel like cross-referencing different file(s) and testing which one it is that breaks things...

This is, I believe, one of the reasons why XT series is indeed eXperimental series of builds. As it isn't officially supported (or, well, as official as a community based game can be supported anyways), users just need to tolerate the problems or solve them with iron wire and duct tape for the time being.

[GTSVA]

So what's a good combination?

[colecampbell666]

Xt 3/14 and sdr1112.VP.

[Herra Tohtori]

Xt 3/14 and sdr1112.VP.

Yah. Except in case you don't see normal maps, then use sdr1112 and sdr1119 in conjunction.

sdr1119.vp should be somewhat better optimized though (by logic if nothing else anyway), so if you're tight on performance and can tolerate a big like nameplates being incorrectly shown, get just sdr1119.vp. It is, after all, the latest version. Kinda like with video card drivers, some drivers have problems with some things while previous and later ones don't have same issue (but others instead). Balancing glitch-free graphics and best performance. Though in this case, I haven't noticed notable performance changes between different shader versions, so I rather take the glitch-free  set of stuff...

[blowfish]

When the MediaVPs are done, do you plan to release them right away, or withhold them until SCP 3.6.10 is released?

No answer?

[Zacam]

Not to be an official voice, but my _guess_ is as this:

If they are done before the EXE, we'll do some more testing for any last minute additions and release in conjunction with the exe.

If the exe is done first, a submissions freeze will take place and they will be released as soon as they are verified stable.

[blowfish]

But what if the VPs are done long before the exe?  My general feeling is that with the vps the end is in sight, while with the exes, the code is still in two separate branches.

[Herra Tohtori]

My logic is that Official, final release 3.6.10 VP's won't be even possible to exist before an official, final release 3.6.10 to play them with. The situation is a bit different from, say, 3.6.8 MediaVP's which got a whole string of public releases from beta to zeta (which ended up being the semi-official VP set for the FS2_Open 3.6.9 era) because it does indeed seem that in this case, the MediaVP's are ahead of the code developement and a lot of the features in 3.6.10 MediaVP's will require a 3.6.10 build... and those won't be official until they are, so MediaVP 3.6.10's can't be either.

Whether or not there will be a public Gamma release (following the current beta and preceding the final release) before FS2_Open 3.6.10 is a different matter altogether, though I would guess not - mostly because packaging an additional public test release would be a pretty unfair (and, IMO, unnecessary) workload that would undoubtedly rest on DaBrain's shoulders.


If you want moar than 3.6.10 Beta VP's contain, gather the stuff you want and integrate (or use multimultimods like I do).

So... what gives? I agree with Zacam... MediaVP content creation (like HTL models, their maps, making normal maps for ships that don't have them already, changes to effects like weapons, subspace vortices) can continue until 3.6.10 is released. After that, it should be bugfixing, packaging and playtesting and final bugfixing, then release them as soon as possible after 3.6.10 stable release build. If at all possible, co-ordinate the releases to be as simultaneous as possible.

But what if the VPs are done long before the exe?  My general feeling is that with the vps the end is in sight, while with the exes, the code is still in two separate branches.

There is no end, they can always be better... although, in this case I would say that if all the ships [models] get normal maps before 3.6.10 hits the sky, I'll be rather surprised and glad like no tomorrow. That would be a "complete" set of MediaVP's, as close as would likely be possible to get with 3.6.10. Complete in the sense that all the ships would then take advantage of the most visible graphical upgrade in the engine since shinemaps (and HT&L, but non-HTL models use shine- and normalmaps too so it's a better analogy - especially seeing how nowhere near all models have been upgraded to fully benefit fom hardware transform and lighting and it's been in the code for how long?).

[blowfish]

Ah, I see.  So you just keep improving them until the release.

[Admiral Nelson]

Could you guys clarify for me the naming convention that will be followed for nameplates in the final release?  If the file names are changing from "nameplate" and "capital01-05a" I will need to redo all campaigns I have released with the new naming convention to support the MediaVPs.

[Zacam]

%ShipType%_%ShipName%

Ex: GTD_Bastion.dds, GTCv_Warspite.dds, NTSc_Hinton.dds.

Mind, thisi is simply what I set when I re-did the campaign nameplates. Frankly, as long as the File Name and the $New Texture: "%Name%" match, it can be whatever you want it to be. Unless you are using official campaign ships.

[Admiral Nelson]

The filename is at issue.  This has changed at least for the Orion with the elimination of the "a" suffix.  What did you do to the FS2 nameplates; it was I who made those in the current media VPs.

[Zacam]

The changes in the Orion were brought about by the DDs'ing (with mip-maps) of the original ship textures. So, for the orion, the name of the texture being replaced is just minus the "a".

All others are still nameplate.

Changes made to the campaign nameplates: Unified font size with anti-aliasing applied to the font and the alpha-mask, all saved as DXT3. End results are much prettier to look at without relying on the alpha channel to mask out left-behind stuff from where the font as a bitmap had been resized. The unified font size and centering conveys a much better military precision in the nameplates application as well. I also made a nameplate for every vessel that supports nameplates that was listed in the FS2 Notable Ships Wiki entry.

The campaign missions have already been updated with all changes made. Again, the texture being replaced is only loosing the "a" in the file name if the high-poly model now has a mip-mapped base texture. Refer to the final model release texture associations in the POF's for any uncertain models. The texture for the replacement nameplate (for consitancy) should follow the example of %Class%_%Name%.dds.

*Edit: I just Finished the FS1 Named Terran Ships in the Wiki as well.