2019-10-21 15:00 EDT


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002344FSSCPSEXPspublic2010-11-25 13:47
ReporterFury 
Assigned ToThe_E 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
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

-Relationships
+Relationships

-Notes

~0012488

Fury (reporter)

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 (administrator)

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 (administrator)

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.
+Notes

-Issue History
Date Modified Username Field Change
2010-11-25 12:19 Fury New Issue
2010-11-25 12:48 Fury Note Added: 0012488
2010-11-25 12:50 Fury Note Edited: 0012488
2010-11-25 12:50 Fury Note Edited: 0012488
2010-11-25 12:51 Fury Note Edited: 0012488
2010-11-25 13:03 The_E Note Added: 0012489
2010-11-25 13:04 The_E Note Edited: 0012489
2010-11-25 13:05 Fury Note Edited: 0012488
2010-11-25 13:46 The_E Note Added: 0012490
2010-11-25 13:47 The_E Status new => resolved
2010-11-25 13:47 The_E Fixed in Version => 3.6.13
2010-11-25 13:47 The_E Resolution open => fixed
2010-11-25 13:47 The_E Assigned To => The_E
+Issue History