[Rodo]

I wouldn't say they're "messed up" but you are quite correct. The old Retail Orion-style nameplate texture is no longer used, so these science vessels will appear without nameplates. The Faustus now uses the same nameplate style as every other high-poly ship.

All FS2 and FSPort missions have been updated. This is just one of those things that project leads ought to do if they want full 3.6.12 compatibility.

This applies for Orion destroyers as well?, I mean I can now use simple nameplates for orion destroyers and not a moddified capital05 file?

if so, WIN.

[Macfie]

I think it only applies to the Faustus.  The old Orion nameplates still show up on the Orions

[Zacam]

All the nameplates for the GTSC Faustus vessels are messed up.  In the mediavps_3612, the texture name for the nameplate was changed from "science01-name" to "nameplate".  This means the ship nameplate created for any Faustus previously will not work with the mediavps_3612 and all the affected missions will need to be revised.  

I wouldn't say they're "messed up" but you are quite correct. The old Retail Orion-style nameplate texture is no longer used, so these science vessels will appear without nameplates. The Faustus now uses the same nameplate style as every other high-poly ship.

All FS2 and FSPort missions have been updated. This is just one of those things that project leads ought to do if they want full 3.6.12 compatibility.

Uh....the Faustus _never_ used the "old orion style" unless by that you mean they had a baked in background. The image dimensions were completely different to an Orions (or by extension, any other vessels, the only reason the Orion one is distinct is because it HAS to have a baked on under-surface to the map) and it is different in .12 than it was in .10 and not just in terms of name.

This applies for Orion destroyers as well?, I mean I can now use simple nameplates for orion destroyers and not a moddified capital05 file?

if so, WIN.

No, for that to apply to the Orion as well, the existing Orion needs to be re-converted and re-wrapped (at a minimum) or we need a different model.

[Galemp]

The old retail Orion-style nameplate texture will still work, you just have to go in and redo the texture replacement in fred to use nameplate instead of science01-name.

Not really. The new nameplate is at a different aspect ratio, so not only will it be stretched but the background texture won't match. It'll look horrible. Just make new nameplates, they're much easier to do than the previous style.

I mentioned the revision in the internal forum, sorry I didn't say anything about it out here.

[origin]

I finally upgraded to mediavps 3.6.12 and now the ship thrusters only show the glow that is seen from the back of the ship.  So whats the deal?  Do I need to change something obvious?

[The E]

Screenshots please. And an fs2_open.log on top.

[origin]

Screenshots please. And an fs2_open.log on top.

Thanks E!  I solved the problem - just knowing that you would slap the bejesus out of me for a stupid error, made me look closer and I found my stupid error.

[origin]

You should be able to replace the preload splash screen and the loading screen by simply putting new ones in the interface flile in your mod folder, right.  It seems to not work that way now...

Edited:  solved

[Macfie]

•Tauret now has a visible modeled cockpit, my bad
Quote by Zacam

It would appear you are still bad.  The fix is not in the Update.

[Zacam]

Try it again.

[Fury]

I don't like the current "patching" scheme. It always assumes people have all the mediavps vp-files and use them all the time. It's kinda silly approach when so much trouble is put into making those main vp-files optional and then patch just assumes you have all of them.

I think creating separate patch vp-files for each main vp-file would be better. You can include them all in single and separate downloads like the main vp-files. While not necessarily a problem with 3.6.10 and 3.6.12 patches per-se, but these current patches don't take into account that certain vp-files have files that override files in other vp-files.

While a minor issue, the 3.6.12 patch already breaks cache files in the core vp-file. People who only play using the core vp-file and patch, now have to regenerate all cache files when playing with antipodes 6 or trunk. This probably happens most often in multi. People either set up different mod dir for multi, or simply rename the vp-files to disable them. This results in caches being generated again into data dir. And when they enable the vp-files again, caches will have to be generated yet again. This becomes endless cache generation loop if same mod dirs are used to play both single- and multiplayer.

Not to mention that those who play only with core and patch vp-files, now have maps and models from assets as well as a tbm from effects. This likely results in inconsistent visuals and in the case of tbm, might even cause debug errors due to missing files.

Personally I'd do away with patches entirely and just update the main vp-files. Sure, people will have to download a lot more when updates are released. But let's face it, it's by far the simplest method and mediavps updates aren't released that often.

[Kolgena]

That solution is also a lot more idiot friendly. A person could find all the up-to-date files in one post without having to look around for additional details on how to get patches working and where the patches are.

It's also a lot harder to maintain, and for people who don't have great bandwidth, a lot more expensive.

[The E]

Actually, it's far easier to maintain. Yes, people who don't have much bandwidth will be screwed, but someone always will be.

[jr2]

Err.. isn't there a way to have a program extract the current vp, replace the patched files, and re-package it into a new vp?  And back the old vp up optionally?  Seems the better solution to me.

1) Copy vpfile.vp to old-vpfile.old and delete vpfile.vp
2) Extract vpfile.old  to a tempdir
3) Overwrite with new patch files
4) Package into vpfile.vp

-OR-

1) Copy vpfile.vp to old-vpfile.old and delete vpfile.vp
2) Write new patch files to vpfile.vp
3) Package contents of old-vpfile.old into vpfile.vp, skipping existing files

-OR-

1) Write new patch files into vpfile.vp, overwriting existing files (not sure if this is possible)

EDIT:

Could probably use the 7-zip engine since it's open source and .vp files are basically uncompressed .zip files (how true is that?  Is that actually the case or is it a different format entirely?)

[Fury]

I don't think so
- Too prone to errors, particularly user ones
- No decent cross-platform patch framework exists that is idiot proof. Xdelta tools do exist, but making use of it idiot-proof would be difficult.
- VP-files aren't zip-files, the format is proprietary format by V.

A patch file that would be usable in windows, mac and linux would be good alternative for those who don't want to re-download the main vp-files. However, for windows and mac users you'd need idiot-proof GUI that works with a few clicks of a mouse. I haven't encountered any such solution.

However, there does exist a good patcher for windows. VPatch. http://www.tibed.net/vpatch/
Mac users would be left out though and linux users would need xdelta patches.

It'd be just a mess and most of all, support nightmare.

[The E]

Err.. isn't there a way to have a program extract the current vp, replace the patched files, and re-package it into a new vp?  And back the old vp up optionally?  Seems the better solution to me.

1) Copy vpfile.vp to old-vpfile.old and delete vpfile.vp
2) Extract vpfile.old  to a tempdir
3) Overwrite with new patch files
4) Package into vpfile.vp

-OR-

1) Copy vpfile.vp to old-vpfile.old and delete vpfile.vp
2) Write new patch files to vpfile.vp
3) Package contents of old-vpfile.old into vpfile.vp, skipping existing files

-OR-

1) Write new patch files into vpfile.vp, overwriting existing files (not sure if this is possible)

You really don't want to do something like this. The potential for corruption is just too big imho.
 

EDIT:

Could probably use the 7-zip engine since it's open source and .vp files are basically uncompressed .zip files (how true is that?  Is that actually the case or is it a different format entirely?)

No. VP files are not related to zip files in any way.

[Kolgena]

Err.. isn't there a way to have a program extract the current vp, replace the patched files, and re-package it into a new vp?  And back the old vp up optionally?  Seems the better solution to me.

This is only good if you want to conserve HDD space by killing redundant files. It sucks for about everything else. It has all the problems of our current VP patching solution and then some.

[Iss Mneur]

Could probably use the 7-zip engine since it's open source and .vp files are basically uncompressed .zip files (how true is that?  Is that actually the case or is it a different format entirely?)

Yes I know this has been answered already, but I thought I would clarify it some more.  A .vp file is the same idea as a .zip in that it stores a bunch of different files including their path and name (and uncompressed as was already mentioned), but that is the only similarity a .vp has with a .zip, how the data is actually stored is completely unrelated to a .zip file.

Regarding the other ideas, delta patching the game data is a endgame plan for wxL2.  The delta patching of the .vps does have it critics as well though, and wxL2 is a long way off.  Otherwise, I agree with The E, tinkering with the .vp files is not a good idea, for the reasons that he already outlined.

Fury, I think having separate patch .vps for each the main vps is actually a very good idea, and probably the best middle ground, especially when subsequent patches are presented as rollups of all previous patches.  That is, you end up with the original release .vps and zero or one patch .vp for each of the original .vps.

[jr2]

Mph.  OK... I see.  However, isn't it possible to do a checksum to eliminate the possibility of corruption (that's where the backup comes in handy, if it fails).  Although, for the other reasons given, I guess it's not a good idea anyways.

[PMY]

First of all, i'd like to thank the Freespace Upgrade team for all the great work you've done upgrading Freespace graphics. The latest 3.6.12 MediaVPs are very impressive (as were the previous versions). The new flaming debris is great, the new shiny capital ships explosions are cool, the new beam piercing effect is awesome and so on.

But there is one change in .12 MVPs that seems pointless to me: the new small craft explosions. Particullary the sound effect. It is like... not juicy enough. And there is bug concerning new explosions already mentioned in this thread: http://www.hard-light.net/forums/index.php?topic=70737.msg1413634#msg1413634