Source Code Project Mantis - FSSCP
View Issue Details
0002344FSSCPSEXPspublic2010-11-25 12:192010-11-25 13:47
ReporterFury 
Assigned ToThe_E 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product VersionAntipodes 7 
Target VersionFixed in Version3.6.13 
Summary0002344: Post-processing sexps are broken
DescriptionRequires mediavps 3612 since retail doesn't have post_processing.tbl.

When you add a new event in fred2_open and set it as set-post-effect, you can't select any post processing effects that are defined in post_processing.tbl.

When this sexp is added manually in notepad, fred2_open loads the mission up without any errors. You still can't add any new pp effects to the sexp though, but it does display the manually added ones.

Now in-game with post processing enabled, the sexp does nothing. Fs2_open doesn't give any errors but the sexp does nothing.

To add a post-processing sexp manually, paste stuff below just before #Goals in notepad to a mission file. It's obvious when it works.

$Formula: ( when
   ( true )
   ( set-post-effect "saturation" 0 )
   ( set-post-effect "film grain" 100 )
   ( set-post-effect "contrast" 100 )
)
+Name: postprocessing
+Repeat Count: 1
+Interval: 1
TagsNo tags attached.
Attached Files

Notes
(0012488)
Fury   
2010-11-25 12:48   
(Last edited: 2010-11-25 13:05)
Some additional findings.

fred2_open: Works perfectly in 3.6.12 final. Set-post-effect action operators become gibberish and blanks in Antipodes 6b and is still gibberish or blanks in Antipodes 7. Newer trunk builds display no gibberish, but they're all blanks now. In builds The E has compiled for BP staffers, fred2_open doesn't show even blanks.

fs2_open: Works perfectly in 3.6.12 final, Antipides 6 and 7. Works in trunk builds as well.

Edit: Edited multiple times because fs2_open issue ended up being an user error. >_> God I hate not noticing missions of same filename taking priority elsewhere in -mod commandline...

(0012489)
The_E   
2010-11-25 13:03   
(Last edited: 2010-11-25 13:04)
Okay, tracing through FRED, specifically get_listing_opf_post_effect() (sexp_tree.cpp 5737), I can see weird stuff happening. In particular, everything seems to work OK right up to line 5747, at which point head.next became utterly and irrevocably corrupted.

This is on trunk builds, BTW.

(0012490)
The_E   
2010-11-25 13:46   
Fixed. Cause was the simple fact that SCP_Vectors get deallocated with extreme prejudice when they go out of scope; this caused the sexp_list data to become invalid.

Issue History
2010-11-25 12:19FuryNew Issue
2010-11-25 12:48FuryNote Added: 0012488
2010-11-25 12:50FuryNote Edited: 0012488
2010-11-25 12:50FuryNote Edited: 0012488
2010-11-25 12:51FuryNote Edited: 0012488
2010-11-25 13:03The_ENote Added: 0012489
2010-11-25 13:04The_ENote Edited: 0012489
2010-11-25 13:05FuryNote Edited: 0012488
2010-11-25 13:46The_ENote Added: 0012490
2010-11-25 13:47The_EStatusnew => resolved
2010-11-25 13:47The_EFixed in Version => 3.6.13
2010-11-25 13:47The_EResolutionopen => fixed
2010-11-25 13:47The_EAssigned To => The_E