• 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.

Smoke effect binding to switch in cockpit

zlin142

zlin142

Messages
48
Country
hungary
I'm still working on my own project and decided to add some custom smoke.
I found some tutorials on YouTube but they are not up to date, things have changed in the SDK since then.
Does anyone know how to assign a smoke effect to an empty switch (modify systems.cfg, interior.xml, exterior.xml files and create VisualEffectLib)?

I already have a good base for the effect: a working/clickable swhitch in cockpit with this code:

<Component ID="Smoke_FX">
<UseTemplate Name="ASOBO_GT_Anim">
<ANIM_NAME>SmokeSwitch</ANIM_NAME>
<ANIM_CODE>(L:CUSTOM_SMOKE, bool) 2 *</ANIM_CODE>
<ANIM_LENGTH>2</ANIM_LENGTH>
<ANIM_LAG>600</ANIM_LAG>
</UseTemplate>
<Component ID="SmokeSwitch" Node="SmokeSwitch">
<UseTemplate Name="ASOBO_GT_Interaction_LeftSingle_Code">
<LEFT_SINGLE_CODE>(L:CUSTOM_SMOKE, bool) ! (>L:CUSTOM_SMOKE, bool)</LEFT_SINGLE_CODE>
<TOOLTIPID>Smoke On</TOOLTIPID>
</UseTemplate>
</Component>
</Component>

This code added to the exterior xml:

<Component ID="Smoke">
<Component ID="Z142_Smoke_Node" Node="Smoke_Helper">
<UseTemplate Name="ASOBO_GT_FX">
<FX_CODE>(L:CUSTOM_SMOKE, bool) 2 *</FX_CODE>
<FX_GUID>{784ff864-c447-410f-97bf-01fa5911927c}</FX_GUID>
</UseTemplate>
</Component>
</Component>

Smoke_Helper added to exterior model of the aircraft.
These rows added to systems.cfg:

[SMOKESYSTEM]
smoke.0 = 9.28315,-0.720677,-2.013151,fx_smoke_w

[LOCALVARS]
LocalVar.1 = CUSTOM_SMOKE
LocalVarDefault.1 = 0

I already created a simple smoke effect in Effect Editor, but doesn't work outside of developer mode, I have no ide what I miss...
Any help would be greatly appreciated!
 
zlin142 said:
<ANIM_LENGTH>2</ANIM_LENGTH>
<ANIM_LAG>600</ANIM_LAG>
Click to expand...


These two parameters are not in the proper range, animations are measured as percentages so you are only allowing 2% of your switch animation to play and I don't think a lag value of 600 will register, it might, but if it did, you are telling the engine to play that 2% of your animation 600 times faster than it currently does. Animation lag for a half speed animation is .5 if I am not mistaken. All of this just affects the switch animation, it does not affect whether the switch changes the state of the smoke effect.
zlin142 said:
<Component ID="Smoke">
<Component ID="Z142_Smoke_Node" Node="Smoke_Helper">
Click to expand...

You have two ID arguments for one component. I cannot predict this will have good results in sim. Similarly, you have two closing tags and these formatting errors will be flagged by the Console, if you use the out of sim FSPackagetool.exe compiler. The two Console displays, between DevMode and desktop are so dissimilar that I strongly endorse developers to to at least test problem packages with the desktop compiler to obtain the extra information that Console report provides.
 
=rk= said:
These two parameters are not in the proper range, animations are measured as percentages so you are only allowing 2% of your switch animation to play and I don't think a lag value of 600 will register, it might, but if it did, you are telling the engine to play that 2% of your animation 600 times faster than it currently does. Animation lag for a half speed animation is .5 if I am not mistaken. All of this just affects the switch animation, it does not affect whether the switch changes the state of the smoke effect.


You have two ID arguments for one component. I cannot predict this will have good results in sim. Similarly, you have two closing tags and these formatting errors will be flagged by the Console, if you use the out of sim FSPackagetool.exe compiler. The two Console displays, between DevMode and desktop are so dissimilar that I strongly endorse developers to to at least test problem packages with the desktop compiler to obtain the extra information that Console report provides.
Click to expand...
Thank you very much for your suggestions!

In fact, as I have experienced, these errors have no effect on the operation. I always compile the project outside the simulator with fspackagetool.exe - as you suggested.
It compiled the project flawlessly. Now I have made the changes you suggested, still no error when compiling, but no change in the simulator, the effect does not work.
My guess is that the error is somewhere around CUSTOM_SMOKE, I don't understand how and what creates the connection between the effect and the switch?
 
Oh, I forgot...

The smoke switch in the cabin was working before, moving up and down as needed. But with the SimVar Watcher I can't check if it has any effect, because I don't know which simvar value it sets? :( I have already found some smoke-related simvar, but these values are not affected by the switch.
 
The way I learned to understand the situation is that code logic cannot directly drive effects. That may be a limitation from FSX days, or it could be something I've construed in my head. The end result is that we have to change variables and there are several types. "Local variables," are what we're dealing with here, SimVar Watcher see's none of that, unless we use a simulator state to drive an effect, like pitot deice, which is also an option. In fact there are many variables and ways to change them, some by simply changing altitude, you see.
In DevMode there is a tool from the drop down called "BehaviourDebug," indeed with the "u," that has a page called, I believe, "Local Variables." There you can watch for your particular variable and better understand where in the flow your code is hanging. You probably know that on the main page you can trace down your component xml and even override to manually drive the animations, as part of the testing process. It provides information about what components are active, which are missing variables and it sometimes illuminates issues with the component XML itself.

I feel odd writing components with CGPT that I have to copy/past information generated by one algorithm into another. A bit like Bartleby the Scrivener.:)
 
=rk= said:
The way I learned to understand the situation is that code logic cannot directly drive effects. That may be a limitation from FSX days, or it could be something I've construed in my head. The end result is that we have to change variables and there are several types. "Local variables," are what we're dealing with here, SimVar Watcher see's none of that, unless we use a simulator state to drive an effect, like pitot deice, which is also an option. In fact there are many variables and ways to change them, some by simply changing altitude, you see.
In DevMode there is a tool from the drop down called "BehaviourDebug," indeed with the "u," that has a page called, I believe, "Local Variables." There you can watch for your particular variable and better understand where in the flow your code is hanging. You probably know that on the main page you can trace down your component xml and even override to manually drive the animations, as part of the testing process. It provides information about what components are active, which are missing variables and it sometimes illuminates issues with the component XML itself.

I feel odd writing components with CGPT that I have to copy/past information generated by one algorithm into another. A bit like Bartleby the Scrivener.:)
Click to expand...
You write well, you're absolutely right.
This time I forgot about this Behaviour menu item indeed - even though I use it regularly ☺️
Unfortunately, I didn't get much new info from there, maybe because I don't know what to check, or what I see is good or bad code? In any case, I couldn't find any attention lines anywhere (possibly highlighted in red), and all I could find out is that the smoke switch what I created changes a certain value from 0 to 2 when I flip it.

The code itself came from the freeware RV-4, and works flawlessly there. I don't see any difference between the two planes in the Behaviour window.
 
I finally found the error: the GUID was different for the switch than for the effect... ☺️ 😁
 
You must log in or register to reply here.
Back
Top