[Jeff Vader]

Also,
You seem to have the older incarnation of the 3.6.10 MediaVPs. Please download the current ones (including the patch!) from the release thread.
If I recall correctly, MV_Music.vp hasn't changed, though, so you don't need to redownload that.

OK, downloading now. Still, I doubt that is the issue. 

Yes, I too am quite certain that isn't the issue. But old 3.6.10 MediaVPs might cause other issues, so it's good to get them straight while at it.

I got the sdrs and the post-processing tbl. I did say that I do get post-processing out of RC1, so I must have the required files, don't I? They just don't work with RC2

That is rather strange, since I got post-processing working on my fffffuuuuuuu-**** laptop with RC2.
Hmm. You said that you placed the files to \freespace2\data\tables\ and \freespace2\data\effects\ . Try moving them to \freespace2\mediavps\data\tables\ and \freespace2\mediavps\data\effects\ . I can't think of a reason why your setup wouldn't work, but then again, we're talking about technology; you never know.

[Enioch]

Nope, still doesn't work. Got new mvps and tried the RC2 with the shaders in *\data\effects and again with shaders in *mediavps\data\effects (the tbl I put in the corresponding \tables folder, of course)

RC1 still blooms like a darlin', but RC2 is being a pig. Or I'm being pretty stupid

Windows 7 Pro, BTW. NVIDIA Geforce GTX 260M. Tell me if anything else is relevant...

[Fury]

Enioch is the second guy here who's having problems with post processing in RC2. So I decided to try it out myself and sure enough, PP is not working in RC2.

Here is debug log of RC1 loading a mission: http://scp.pastebin.com/LybdeUks
And here's RC2: http://scp.pastebin.com/cKVkGaUf

Notice line 794 in the RC2 log, "Post-processing disabled." Considering current post processing implementation in FSO is known to cause memory leaks and crashes, could this be in fact intentional?

[Commander Zane]

Kind of odd that it's working for some, not working for others.

[headdie]

is it build dependent i mean there are 6 builds of RC2

[Enioch]

Tried it with the first and second builds of the first post. Fails on both.

[FUBAR-BDHR]

Well this definitely appears to be 2 different issues.  Fury's turns off during or after a mission.  Enioch's clearly states it can't find the table and disables because of that. 

[Waistless]

Enioch is the second guy here who's having problems with post processing in RC2. So I decided to try it out myself and sure enough, PP is not working in RC2.

Here is debug log of RC1 loading a mission: http://scp.pastebin.com/LybdeUks
And here's RC2: http://scp.pastebin.com/cKVkGaUf

Notice line 794 in the RC2 log, "Post-processing disabled." Considering current post processing implementation in FSO is known to cause memory leaks and crashes, could this be in fact intentional?

Well this is exactly this issue I was having, by setting the AlwaysOn flag for the film grain to true (leaving default at 0.0), Post Processing went enabled again. Could you try this and see if it works for you as well?

As for your issue Enioch, strange that it would complain the table file that you're editing is missing, and work in different builds. Maybe you have multiple table files in different places and the newer version is more strict. I'll try various things to get that error myself.

Edit: Can't get the error unless I physically delete the file. If I intentionally corrupt it I get a debugger error (not what you get I assume.) I found something else though:

RC1 doesn't care if the table file is missing or not, it will enable post processing regardless. On that basis, the reason RC2 will not work with PP is purely because it cannot find the table file, whether it is not in a directory its looking or its missing stuff without giving a debugger error.

Try deleting that table file and redownloading the shaders file, and put the table file where it needs to be (\mediavps\data\tables) and don't edit it, just run FS2 (with mod mediavps) after that and if the log says something along the lines of:

Code: [Select]

 Compiling special shader ->  post-v.sdr / brightpass-f.sdr ...
render_target: creating new 640x640 FBO
render_buffer: creating new 640x640 render buffer
texture_pool: creating new 640x640 texture
  Compiling special shader ->  post-v.sdr / blur-f.sdr ...
render_target: creating new 320x320 FBO
render_buffer: creating new 320x320 render buffer
texture_pool: creating new 320x320 texture
texture_pool: creating new 320x320 texture
Post-processing disabled.
At the start of any mission (after clicking accept it should occur), then the game has found the table file, and all you need to do is in that same table file edit the AlwaysOn flag from "false" to "true" in the film grain entry, and hopefully it will work.

[neogoki]

not sure if anybody posted it but:
i get the "there is no disk in the drive, put a disk in \Device\Harddisk3\DR3" warning everytime when i use the fred2_open_3_6_12 exes, don't matter which!

[chief1983]

I _think_ you can fix that by deleting a certain file that FRED creates in the /data folder, but I'm not positive.

[Vrets]

FRED2_OPEN loadout manager is still insane.

I apologize if this escapes the purview of this release.

[The E]

If you would be so kind to tell us just what the hell you mean by insane, there may be a chance to fix it.

[General Battuta]

The loadout manager seems pretty straightforward to me...it's a checklist!

[chief1983]

I think there was an issue with the new Team Loadout code.  Don't recall what was up with it, Kara was supposed to have taken a peek at it.

[Vrets]

If you would be so kind to tell us just what the hell you mean by insane, there may be a chance to fix it.

The loadout manager functions in a manner that is less than reasonable.

The loadout manager seems pretty straightforward to me...it's a checklist!

It's a collection of tubes.

Honestly: setting "600" of weapon x" in the new editor is insufficient for "600 of weapon x" to appear in the weapon selection screen. A quantity of weapon x is subtracted that has no apparent basis in anything happening anywhere. We're missing a tube, I think.

[General Battuta]

Isn't it based on how many of said weapon are equipped on Alpha, Beta, Delta, Gamma, and Epsilon wing ships in the mission?

[Vrets]

Even if that were the case, it would still be quite a byzantine system. I'm really not sure how it's supposed to work. I gather that the original purpose was to allow variables to modify the loadout for missions in a campaign. A frightfully good idea, although something went awry.

Original thread.

[karajorma]

Did anyone ever stick that in Mantis?

If not how do they ever expect it to be fixed?

[Fury]

I think there's a good chance that there is a bug in the weapon calcs somewhere. I'll have to take a look into it.

Would be my guess.

[karajorma]

Yeah but this is why using Mantis is a must for things like this. The link to the original mission is now dead. So I have nothing to test this with. Nor do I have an exact set of steps to reproduce.

So basically until someone can be bothered to get me those I'm not likely to have the time to fix this one.