plane icon Welcome to Microsoft Flight Simulator’s SDK Q&A Platform!

You have questions regarding the SDK? DevMode Tools? SimConnect? You would like to submit an idea for future improvements, seek help or exchange knowledge? You’re in the right place.

Please take a moment to read the platform’s guidelines before you get started!


For HUDs issues management, please read the article here !

article

SonantAlpaca avatar image
SonantAlpaca posted SonantAlpaca edited

[SU6] Changes you must make on your FXs

Manual changes required after SU6 update

Several parts of the new Visual Effects system have changed for this release. Some properties have changed or been made obsolete and you may be unable to build your VFXs. Don't worry, you can restore them to a working state using the Visual Effects Editor !

If you do not use source control, make sure to backup your VFX sources before attempting to restore the intended behavior !

Visual effects already built before SU6 can be loaded in the game, but their behavior will likely not be what is intended. Visual effects sources can also be loaded for edition without manual intervention to fix the xml files.

When you create an effect in the Visual Effects Editor, two files are created to store its properties. Let's assume your effect is called my-effect, in your package sources you will find my-effect.xml and my-effect_edition.xml. We will call these files the "data file" and the "edition file" respectively.

Some properties have been marked as obsolete. Their presence in the source files of an effect is not a problem. They will be loaded and ignored and then will not be serialized again. this article will go over the changes introduced that will affect your effects' behavior or ability to be built.

EmitterList

The purpose of this property is to store the references to all the emitters defined in your VFXs. It is located inside the VisualEffect block definition in the data file. It may contain more data than needed, and probably will include a useless InstanceId attribute. Now it can contain only ObjectReference properties. If it contains anything else the effect won't build ! However, effects built before SU6 can still be loaded in the game.

To remove undesirable data all you have to do is open the visual effect in the Visual Effects Editor and save (hit ctrl+s).

untitled.png

Diff between a visual effect data file before and after SU6. The EmitterList property has been automatically cleaned, keeping only ObjectReference child properties

AttachToEmitterTranslation/Rotation

These two parameters were part of Emitter blocks. They have been replaced by a single one, EmitInLocalSpace, and made obsolete. They should only appear in the data file if they were checked in the graph editor (i.e. set to true in the file). Open the data file of your effect and take note of what parameters were checked (open your backup if you have already opened and saved the same effect after updating to SU6). If the parameter was checked for your effect it should be serialized in the file with a value of True like so:

<VisualEffect.Emitter InstanceId="{AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}">
<ParticleRate>{00000000-0000-0000-0000-000000000000}, 1.000000</ParticleRate>
<AttachToEmitterRotation>True</AttachToEmitterRotation>
<ParticleInit>
<ObjectReference InstanceId="{BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB}" id="BlockParticleInit"/>
</ParticleInit>
</VisualEffect.Emitter>

An Emitter block on which AttachToEmitterrotation was checked and AttachToEmitterTranslation was not


When you have collected that information, you can open your effect in the Visual Effects Editor and restore the intended behavior with a few modifications. We will detail common setups before SU6 and how to recover the intended behavior. These instructions assume you were not setting positions for your particles at the Init or the Update stage because positions were unreasonable to work with before this update. If you do not find something that suits your situation, please let us know on the SDK Q&A platform and we will try to help you.


Both AttachToEmitterTranslation and AttachToEmitterRotation parameters checked

Check the EmitInLocalSpace parameter. The only difference with the old behavior is that the particles that have already spawned will follow the rotation of the emitter. It is a true local space emission, which was not possible with the old system.

Only the AttachToEmitterRotation parameter checked

Do NOT check EmitInLocalSpace!

Replace the Vector3 nodes used to compute velocities with LocalDirection nodes This new node transforms the three dimensional vector defined in local space by its input into the coordinate space used by the graph (the "working space"). If EmitInLocalSpace is checked, the working space is local and the node doesn't perform any transformation. Otherwise (in your case here with only the AttachToEmitterRotation option checked) the working space is world and the node transforms the input direction vector in that space.

untitled-1.png

Removing the lonely AttachToEmitterRotation from the Emitter definition

untitled-2.png

Typical pre SU6 setup

untitled-3.png

Equivalent setup post SU6

Both AttachToEmitterTranslation and AttachToEmitterRotation parameters unchecked

If you were using velocities with this setup before SU6 they will no longer be valid. The coordinate space for velocities in this setup used to be x west, y up and z north. Since this was an arbitrary setup and not reliable at all time, we will assume it was used for a vertical emission of particles, possibly with a randomized variation around the up axis. With the SU6 update, when the EmitInLocalSpace parameter is unchecked velocities use the same world coordinate system as positions, i.e. ECEF. Depending on what your VFX was emitting from there are different ways of recovering the intended behavior. Emitting from a static object

Check the EmitInLocalSpace parameter and set your VFX orientation so that the y axis is pointing up (you can use position and rotation offsets in the spawner tab of the Visual Effects Editor and replicate them in your model behavior component). You should not need to change anything else regarding velocities.

Emitting from a (possibly translating) object rotating locally around the up/down axis

Do NOT check EmitInLocalSpace!

Set your VFX orientation so that the y axis is pointing up (you can use position and rotation offsets in the spawner tab of the Visual Effects Editor and replicate them in your model behavior component). Replace Vector3 nodes used to compute velocities with LocalDirection nodes.

Emitting from any other rotating object

Do NOT check EmitInLocalSpace!

Use the GravityVector node to get a vector with a direction along the up-down axis. Positive scale points down and negative scale points up. Unfortunately with this kind of setup there are now way to add some randomized variation to this direction using axes parallel to the ground. We are working on ways to facilitate this with future updates.


vfx
untitled.png (90.5 KiB)
untitled-1.png (30.7 KiB)
untitled-2.png (154.1 KiB)
untitled-3.png (145.3 KiB)
2 comments
10 |10000 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

I really appreciate the heads up on this.

Thank you!

0 Likes 0 ·

Great heads up - appreciate this.

Is SU6 still on pace for late October ?

0 Likes 0 ·

Article

Contributors

SonantAlpaca contributed to this article

Related Articles