I don't want to seem evul stupid and bad... But "WAT" should we do about this beam problem, guys?
It's an intriguing problem because the files themselves are, apparently, completely intact when examined in the VP so this pretty much blindsided us entirely - there is no immediately apparent reason why one effect would consistently get corrupted in the process of getting the textures from HD to on-screen graphics, but there it is and happening. It's also problematic because as far as I know, none of us team members have been able to replicate it so we don't know what would work on the hardware that is susceptible to the problem, so we don't even know if it's a media problem (if so, table or texture issue), code problem, driver problem or hardware problem.
The fact that it only affects one effect (probably just one texture) makes me think that there's
something in the Shivan beam texture files that triggers fail in the GPU, but I don't know what it could possibly be. Basically if I had a rig that could produce the error I would probably have isolated the offending texture already and would have tried to fix it first with a re-save, then with different format and so forth, and if wishes were horses I would eat steak every day.
Oh and, sorry for the stupid asking, but: Is this gray trail thing a bug now or is it not? Not that it would be a mayor problem to me, but it just looks very... unfamiliar.
It's not a bug but it isn't the ideal situation either. It works as intended, but opinions of it may vary. Basic premise is that now the missiles use an upgraded effect (albeit monochromatic) instead of retail effects, but to be honest converting the gray missile trail to different colours would've been nearly trivial if I had noticed the need for them. Expect this to be fixxored in either patch or next version of VP's, whichever we end up doing...
Also, regarding your debug log - I spy with my little eye something more that doesn't belong there:
Found root pack 'D:\Games\FreeSpace2\shaders.vp' with a checksum of 0xe13995b9
Unless you really, REALLY want that to be there, I would recommend moving that somewhere else. The mediaVP's have a set of shaders integrated onto them, but if you want to use your own set of shaders (for example to get rid of the blackening nameplates effect), then I would move the shader VP either in with the mediaVP's and name it a_shaders.vp (alphabetical order before the mediavp shaders) which makes tehm override the shaders inside the MediaVP's... but if you don't know for sure what you're doing, just put it somewhere else where it doesn't cause confusion. Apart from the nameplate problem, the shaders provided with mediaVP's really do yield best results to date, mainly because they make environmental mapping take the normal maps into account, which... produces a plenty cool effect.
Also, this definitely shouldn't be happening:
Ships.tbl is : INVALID!!!!
Weapons.tbl is : INVALID!!!!
If you're still getting this after removing the ItDoH VP (and Lightspeed and Shader vp though they shouldn't have effect on this), something might be hiding in
..\FreeSpace2\data\tables\ or
..\FreeSpace2\mediavps\data\tables\ directories...
Unrelated to mediaVP's, I'd really love to get an explanation to this:
Max elements vertices: 2147483647
...because there's no way in hell that can be true.
It seems to be something ATi-exclusive...
Regarding the older swirly subspace effect, the one you're looking for is Axem's oldie goldie with the warp.pof having it's UVmap twisted to create a swirly effect... it can be found from
here, but as the starting message says - you edit things, you're on your own.
Replacing the subspace vortext should be a breeze though, just slap the a_subspace.vp in the same dir as the mediaVP's and it should work just fine.
The thread also has some immortal quotes from takashi a few pages forward from the link.
Hanyuu271, I quote myself:
Third party mods built to depend on now-obsolete MediaVP resources can have problems playing nice with new mediaVP's. That shouldn't be a surprise. Things that are built based on how things worked on 3.6.9 builds and 3.6.8zeta VP's may or may not have issues with 3.6.10 builds and VP's, depending how deep the dependancies are and how radically things change between versions. Our testing priority has been on compatibility with retail campaign partly because the project is, after all, FreeSpace Upgrade, and partly because we simply don't have the resources to test every campaign as well.
Most things *should* work without gamestopping errors. We try to maintain a level of consistency but this is a major overhaul of the VP structures and content, and we can't keep everything to work to exactly same specs as the previous VP's. If there's a problem with a mod/campaign that relies on 3.6.8zeta VP's, you should use 3.6.8zeta VP's with them and/or report the errors on the campaign's forums and request a patch. FSUpgrade team can't start troubleshooting each third party campaign to work with 3.6.10 mediaVP's, but as individual forum members we'll likely help other modders to patch their stuff to take the most advantage out of new VP's. That process should be done on Modding forum or campaign/mod's dedicated forum, though.
(...) We can't support all campaigns/mods that have critical dependancies on older MediaVP's; those campaigns need to update themselves if they decided to depend upon specific MediaVP's in the first place. Independently functional campaigns/mods should work fine with any mediaVP's, as they don't slave themselves to specific resources in specific MediaVP's.
My opinion is that unless it's a MediaVP error, it should be solved at FS Modding forum, or campaign/mod's dedicated forum if such exists.