[Mobius]

The odd fade in/out behavior can be easily fixed in FRED by setting the initial fade out condition under an event that is triggered by default (trigger condition: true).

The consequent fade in effect is to be activated by a different event, set at mission start (trigger condition: has time elapsed "0" or similar).

Any extra fade in/out SEXPs result in weird effects.

[themaddin]

The odd fade in/out behavior can be easily fixed in FRED by setting the initial fade out condition under an event that is triggered by default (trigger condition: true).

The consequent fade in effect is to be activated by a different event, set at mission start (trigger condition: has time elapsed "0" or similar).

And that's what the original author did. Their mistake was to set the time to fade-out over to 1ms, which of course means one frame of a normal monitor. I don't know if that SEXP required an argument back in 2009, but I've found that simply removing it fixes the issue.

[Mobius]

That's correct, the initial fade out setting should not have a transition time. It should be a pure fade out, activated directly.

The fade in effect that follows soon afterwards can have any transition time as per the designer's taste.

[themaddin]

Thanks for the advice. I've got two new questions, maybe you could help me there as well?

When opening any mission original mission file in FRED-FASTDBG, im getting this:

Code: [Select]

Warning: +Team: value was out of range in the mission file!  This was probably caused by a bug in an older version of FRED.  Using -1 for now.
File: missionparse.cpp
Line: 5042

I've found +Team in the wiki only as argument to #Events, so I'm guessing this means to which player team a given event applies?
As this is a single player campaign, can this be safely ignored / left with the default FRED sets?


Other thing is, this mod contains outdated models for Apollo, Valk & Athena. These have in the meantime been included in the current
MediaVPs, with which I aim to make this campaign compatible.
What's the best practice for enabling these craft? The default load order means MVPS get loaded before this mod, this shp.tbm takes precedence, the older models override. I can think of splitting shp.tbm out to a package that loads before MVPS, loading MVPS last in general, or patching shp.tbm with MVPS entries wherever they differ.

Thanks in advance!

[Mobius]

Running debug builds (FRED included) may result in warnings popping up, and sometimes these warnings don't cause any serious trouble. I've recently played mods despite their several hundred warnings/errors, and the gameplay was very smooth in most cases (for instance, I did not experience CTDs). In this particular case I'm no coder but, to my knowledge, FRED processed the inconsistency rapidly and realized the reported "Team" value is indeed a multiplayer setting. Consequently, the game itself is now resetting the value to -1 (which means "all teams", IIRC) and no further intervention is required. It even reports this may have been caused by a bug affecting older builds, so it must have been a known issue back then.

If all necessary changes have been made to the missions, maybe you should let MjxMixael know so that a new update can be released soon. He monitors the thread anyway so he'll definitely notice this.

The issue with outdated FS1 models can be solved too via quick packaging changes - I admit I didn't even realize the models were outdated, and that's mostly due to the fact that I play in FP.

[Iain Baker]

Does this still need the gramma fixing? I saw on the first page that it needed it, but that was 2009. Has it been updated since then? If not, I would be happy to give it the once over :-)

[themaddin]

@Iain Baker: I'm currently engaged in editing the fiction. manwiththemachinegun already offered to give it a read when I'm done, but I'd be happy to have your additional feedback, if you're interested.

@ Mobius: I can explain in greater detail what I already changed and which problems I see with the various solutions to the outdated models when I'm back at my PC

[themaddin]

Back now. At the risk of making this a noob's yakshaving rant, gonna give you my thoughts
on how best to update the Apollo, Valkyrie and Athena.

Hidden Text: Long-winded situation analysis • Show

As far as I can tell, models for these three craft and indeed whole sections of the shp.tbm
were copy&pasted from fsport. IDK if there've been changes to these within the port,
their addition to MVPS would logically have come at a later date or these models would have
simply been referenced.

In this importing, a mistake was made: Neither the drive sounds (192 & 193 of FS1) nor
their defining table were imported, causing the drive sounds of these craft to be missing,
and so to differ from their performance in FS1 and fsport. I've already corrected this,
copying these missing parts from current fsport.

Now correct me if I'm wrong, but the table data included in the MVPS
for these three are insufficient to use on their own (I tried), served in a way so as to easily override
fsport versions, and therefore marked +nocreate.
So before MVPS are loaded, these ships must be created, or the overriding data in the MVPS' shp.tbm
must be applied "manually".

This leaves several courses of action:
1) Patching the vega_apo-shp.tbm (which is a partial copy of fsport ship.tbl) with all the additions
and overrides normally applied by the MVPS. At loadtime, mvps_shp.tbm definitions are ignored,
and these craft created not before vega_apo loads. models from mvps are accessed.
Pros: minimal changes to mod architecture, bugs easily traceable, little work (was going to go with that)
Cons: don't update with either fsport or MVPS, leaving us with the same situation in a few years

seems to work
2) Changing load order (in knossos) to load MVPS last. Not touching tables. Table entries get overridden
as they are when launching fsport with FSPortMediaVPs, and therefore, MVPS.
All other table entries also get overridden, which will bring back a "illegal weapons" warning in FRED
which I previously fixed by overriding the Myrm's and Zeus' $Allowed SBanks.
EDIT: No they'll stay overridden as they weren't overriding MVPS but only retail.
Pros: no work at all, updates with MVPS
Cons: stuff getting overridden all over the place, bugs hard to find, doesn't update with fsport

Hidden Text: doesn't work • Show

3) What I thought  I should go with:
Adding a package to load before MVPS, which contains only the old shp.tbm entries.
Only this would be overridden.
Pros: bugs easily traceable, updates with MVPS
Cons: severe changes to mod architecture, much work
EDIT: Doesn't work, can only set load priorities between mods.


4) What I thought I should go with:
Adding a dependency to fsport (which story-wise exists, using craft of that era), to load first,
before MVPS and vega_apo. This was the scenario the MVPS table entries were written for, I assume:
fsport assets get first modernized and then customized at loadtime, as is logical.
Pros: updates with fsport & MVPS, maximum deduplication, can toss old table entries & copied sounds.
Cons: Unused imports everywhere; BLOAT (But everyone's got the port lying around anyway, haven't they?)
EDIT: Okay forget that. fs2 tables get overwritten with fsport tbls.

[Mobius]

Does this still need the gramma fixing? I saw on the first page that it needed it, but that was 2009. Has it been updated since then? If not, I would be happy to give it the once over :-)

You've just become a pro at proofreading fs2 files via Notepad or Notepad+, it'll be an easy job for you (SerRes docet). I guess you may edit The Apocalypse: Vega once these FRED fixes themaddin is talking about are fully implemented.