• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Regarding dialog actions, proxtriggers and timers

Horst18519

Horst18519

Moderator
Resource contributor
Messages
2,385
Country
germany
Recently I came across some problems regarding timers or proximity triggers, experiencing that they didn't fire the way I wanted them to.
Then I realised that at the moment when the trigger should be fired a dialog action was playing. It took me a while to figure that the trigger actually fires no sooner than the dialog action is completed.

For timers (especially for races) and proxtriggers attached to very small areas this can mean that a dialog action may cause the trigger not to fire at all or have a delay - which in case of races is not what we want at all.

The only option I see there is to ensure that no dialog is played while you approach a sensible trigger - or you use a soundfs-action instead. It won't be captured, but it won't interfere with the trigger too. :)

I hope this helps you mission designers out there, because if anyone would have told me I could have saved half a night's work... :o


btw: Paul, I know that you read along here from time to time. Thanks alot for the nice documents about mission building at FSInsider.com. Allthough most of the problems you describe there already costed me some sleepless nights it is very well done and a great help for all of us! Most of all I enjoyed the part about the waypoints at the DragTruck race - a mission which I consider the most difficult to create of all the default missions.
 
Hi Folks

Thorsten -
I'd also come across this.

There's another way to have it work correctly -
Place the sound so it fires last in the sequence, after all the triggered nodes.
Either as lowest in the on-enter list, (use move down),
or move the dialog to fire on-exit.

PS
In the OPT,
does the 'Play Sound' button work for anyone ?

My SDK is installed to a non-standard path,
and I can select the sound files in the dialog,
they just don't play on clicking the button.

HTH
ATB
Paul
 
Last edited:
Thanks for that, Kevin. :)

There's another way to have it work correctly...
Click to expand...
Actually I was talking about cases where a dialog action maybe triggered by an AI object for example or by a user variable.

But you're right: Sometimes it is even neccessary to open the xml and reorder the actions by hand - the mission UI often doesn't display the related actions in the correct order.
 
'Sometimes it is even neccessary to open the xml and reorder the actions by hand'

Thorsten,

This comment surprised me somewhat. I've never had to reorder the xml by hand and I've had some pretty complex triggers with up to say, 20 events, ordered in a specific way.

Ordering of events in the trigger has always worked for me. YMMV.
 
Hi Folks

Thorsten -
Understand what you were specifically referring to now.

AFAIK,
you shouldn't need to manually edit though.
AFAIK the OPT works ok for this.

In the OPT -
Select the parent item in the top RH 'All items' list.
Select the child node you wish to reposition in the References: box.
Click the 'Move Up' or 'Move Down' radio buttons as required.
That should move the item correctly.

EDIT
Ooops RNO
you beat me to it whilst I responded to a second post.

Likewise I was also surprised.
Thorsten, could you please expand on the above ?

I'd only needed to really manually edit
to save myself a lot of unnescessary clicking in the OPT
when replicating a large number of nodes to another function.

HTH
ATB
Paul
 
Last edited:
Guys, you just maybe right. Coming from scenery design I am quite used to work with XML though. Maybe it's just my need for having everything under control. And in the xml I sometimes have a better look at things than in the mission UI.
Anyway, sometimes I really find that if I click onto some actions that sould be triggered they don't seem to be orderd the way I wanted them.
But of course, moving them with the "up/down"-option should do the work.
So sorry for the disturbance. :)
 
Hi Folks

Horst -
I'd forgotten to follow this up earlier.

The OPT appears to groups the items in the 'References' box as follows -
On-enter actions.
Area Reference.
On-exit actions.

Items cannot be moved up/down across groups.

HTH
ATB
Paul
 
You must log in or register to reply here.
Back
Top