Conversion questions using the Flight Toolkit

#21
The 0-3 index, is not mean the variable has 4 values. It means there are 4 different bool values for each variable. One for each engine. So you can have Engine.LeftMagnetoSwitch:0, Engine.LeftMagnetoSwitch:1, Engine.LeftMagnetoSwitch:2, Engine.LeftMagnetoSwitch:3 and each one is on or off. The enum values of off, left, right, both & start are probably combinations of those three variables, for each engine.
 
#22
Steve, would it be possible to add a ribbon of some sort - on to the Addon Builder - to indicate which file is currently being processed (i.e. when the "Refresh" button is pressed in the "Content" panel)*?
Occasionally, when a faulty file is added, the Addon Builder would freeze along with the Status Bar, but I have no idea which file is causing the problem. :banghead:

Kind Regards,

**EDIT:**
* when you have the time of course! :)
 
Last edited:
#23
Is anyone getting a compatibility error whilst trying to run the SimPropCompiler on Win10?
"Access is Denied" + "This app can't run on your PC"- even with the .exe running in compatibility mode.

**EDIT:**

Nope...just me! Repaired installation and works fine!
:)
 
Last edited:
#24
Just one question:

Is there a way to get an oversized bitmap gauge to fit correctly in the panel? For example, I have a Clock which has a large bitmap image but when added to the aircraft, it does not fit into its corresponding slot. The FSX .xml gauge shows the following:
Code:
     <Image>
        <Position X="115" Y="115"/>
         <Image Name="Clock_NeedleHours.bmp" ImageSizes="23,88,23,88">
       <Axis X="11.5" Y="77"/>
     </Image>
Is there any way to get this into gauge into Flight and does Flight support resizing or the "ImageSizes" tag?
 
#25
Ah! Thanks for the clarification, Stonelance. That makes sense.

KavindaJD: I'm not 100% sure if Flight auto-resize images, but I'm pretty sure it does not, as the new paradigm is for gauges to be built into the model. In my work, I've been resizing and sometimes rotating the "inner" bitmaps to fit within the borders of the background image. So, if the clock background is 100 x 100 pixels, I'll open up the image in my photo-editing application, open up the needle image, then resize it, as required, to fit within the background. I also will rotate the needle image to point to North (0 degrees), if needed, as this makes creating the rotation code a bit easier to write. It also helps in determining the X,Y coordinates of the center of rotation for the needle, which will be (if pointing North), usually mid-point along the X axis, and some where towards the bottom of the Y axis.
If your background image is too large, then you;ll need to resize that too. One caveat. I think some changes were made in Flight w.r.t. where centers of rotation are defined. Simply "importing" the values from FSX creates some odd-looking & behaving gauges. It took quite a while for me to get gauges to work correctly. So, following the guidelines in the FSX SDK do not always work.:(

W.r.t. my work on the Baron, it's been another busy week at the FSX conversion hangar. I finally got around to creating a new Aerodynamics.simData file for the Baron, which allowed me to start proper test flights for the first time. The aircraft is quite flyable, but the aerodynamics require some tuning to meet some basic specifications, such as stall speeds. This work will take some time, I think.

Gauges:
Some problems surfaced this week, after I started filling in some scripts with data from Stonelance's simdata file. (Note: All gauge files are converted to .spb files before including in the .pak file).
First, trying to get the turn rate using this script (snippet only):
('S:FlightInstruments.TurnRate', 'radians_per_second', 0, 0)
or variants using units of 'radianspersecond', 'degreespersecond', or 'degrees_per_second' gives this error in the ContentErrors.log:
Gauge: No gauge loading...Need units for (S:FlightInstruments.TurnRate)

What is accepted is this:
('S:FlightInstruments.TurnRate', 'rpm', 0, 0)
'rpm' being revolutions per minute (not radians per minute!). However, even then, when there is no error in ContentErrors.log, it just does not seem to work - the variable seems to be inoperative. The rest of the code appears to be OK, as if I replace the variable with ('S:BodyState.BankVelocity', 'rpm', 0), the gauge animation for the turn rate aircraft icon works OK. But gauges with turn rates work in default aircraft, so I need to do some more investigative work here.

Second, ContentErrors.log also reports that this variable does not exist:
Gauge: No gauge loading...Undefined Simulation Variable: "Avionics.AudioPanel".
So this variable also seems to be inoperative too.

Stonelance, I've found that the Sim Data Debugger to be incredibly useful for flight testing, ensuring that my scripts are both operational and that the gauges show the correct values. I'm compiling a list of additional variables that will be useful to display in the application - I'll send it to you once completed.

I've also converted the remainder of the liveries for the Baron, so now there are four deluxe aircraft in the FSX conversion hangar:
upload_2015-8-20_13-9-33.png


I also took some time out to work on adding some variants to the default Maule. I was quite surprised, when the Alaska Pack was released, that there were no aircraft with skis. This is now rectified!:
upload_2015-8-20_13-10-17.png
upload_2015-8-20_13-10-42.png


I'm using the interior model from the default aircraft, so only needed to convert the exterior model from FSX. The front skis can be raised & lowered (I remapped them to the default landing gear animation in ModelConverterX), but there are no external lights on the model. There are landing light effects, however, as those are modeled in the internal (default) model. So, at least I can see the runway when landing at night, even if other aircraft cannot see me!:D

There is also the Swiss variant for those who want to fly in the alps:
upload_2015-8-20_13-11-27.png


Finally, I was wandering around a deserted airport recently, when I saw something quite odd. The are not supposed to be any aircraft there, nor, for that matter, any crates either. I managed to take this picture before being chased away by some very unfriendly guards:
upload_2015-8-20_13-11-52.png

I wonder what is going on? Hmmm.....
regards,
FS-Tester
 
#27
@FS Tester: Again, great to see the progress you are making, both in the Baron and the Maule! Thanks for the info on the gauges, I guess that I'll have to resize them manually and see how that goes.

@stonelance: Does the ContentConverter read the texture.cfg when converting aircraft? I'm finding that when it comes to generating the liveries, it crashes and doesn't read the fallback texture path.
 
#30
KavindaJD: Yup, the tool does parse the file. What I've been doing, just to make sure that the tool does not crash, is modify the .cfg file to only point to the .texture folder, where I put all the common texture files. Then I use .texture.1, .2, .3 etc. for the livery-specific files & thumbnails (I've found that these folders often have duplicates of common files). It also means copying one or two textures, such as those for fresnel & chrome, from the FSX root/texture folder, but then I know if the tool crashes, it is not due to a missing texture.

I did not spend much time on the Baron this week, but did work out why one anomaly was occurring.

Radios
w.r.t my comment last week about the Undefined Simulation Variable: "Avionics.AudioPanel", it appears that one can get this message in two scenarios:
1. The variable does not exist, or
2. The variable does exist, but one is trying to write to a variable type that is read-only (i.e., is not settable).​

So, just changing the script from:
varget ('S:somevariablename', 'variable units', index)
to
varset ('T:somevariablename', 'variable units', index, value)

won't work in many cases. You need to know the variable names for both "getting" & "setting" the value. For example, for reading & setting the transponder, these would be:
decodeBco16 (varget ('S:Avionics.Transponder.GetCode', 'Bco16', 1))
and
varset ('T:Avionics.Transponder.Set', 'Number', 1, '0x'..<somevalue> )

The complete code to increase the 1000 digit of the transponder can be accomplished thus:
local currentSetting = decodeBco16 (varget ('S:Avionics.Transponder.GetCode', 'Bco16', 1))
local newSetting = currentSetting + 1000
varset ('T:Avionics.Transponder.Set', 'Number', 1, '0x'..newSetting )

Note that, logically ( to me, anyway), the "opposite" of "GetCode" would be "SetCode", but that is not the name of the writable instance of this variable. o_O

This is often the case. Another example of "logical oddities" is when increasing or decreasing radio settings. Two of the variables (in this case, to decrease the setting) are:
varset ('T:Avionics.Nav1.WholeDec') and varset ('T:Avionics.Nav1.FractDec')

You can do the same for the COM radios, e.g. to increase the setting, the code is:
varset ('T:Avionics.Com2.WholeInc') and varset ('T:Avionics.Com2.FractInc')

but if you replace "NAV" or "COM" with "ADF" to increase or decrease the ADF setting:
varset ('T:Avionics.ADF1.WholeDec'), varset ('T:Avionics.ADF1.FractDec'), varset ('T:Avionics.ADF1.WholeInc'), varset ('T:Avionics.ADF1.FractInc')
the Content.log with record the variables as unknown /undefined.:(

Switches
I also did some more investigative work on the magneto switch Issue:
Looking in the converted Baron interior model with Granny Viewer, Addon Builder converts the magneto switches as follows:
Left engine magneto-starter switch: ('S:Engine.LeftMagneto', 'bool', 1)
Right engine magneto-starter switch: ('S:Engine.LeftMagneto', 'bool', 2)

The conversion also reduces the animation by 50% (I'm not sure why this is). The full code is:
local result result = (varget ('S:Engine.LeftMagneto', 'bool', 1) *50) return (result *0.010000)
local result result = (varget ('S:Engine.LeftMagneto', 'bool', 2) *50) return (result *0.010000)

Also note that, as only one engine instance is modeled in flight, the variables ('S:Engine.LeftMagneto', 'bool', 2) & ('S:Engine.LeftMagnetoSwitch', 'bool', 2) are inoperative in Flight (at least, I cannot get them to work!)

Furthermore, as far as I can tell, in Flight, the Engine.Left/Right Magneto variables cannot be set, irrespective of the index #. So, if I'm understanding what is going on here correctly, a better mapping would be to just to map all the engine magnetos in FSX to one magneto variable in Flight, without the 50% reduction in the animation:
return varget ('S:Engine.LeftMagnetoSwitch', 'bool')

Lights
Again, based on some investigative work, light and light switch indices appear to be mapped based on the index value given to the animation within the model file. I'm not 100% sure of this, though, as in the Baron, the conversion has skipped over indices 1 & 2, starting at #3 and continuing to #7. Numbers 3, 4 & 5 work fine, but 6 & 7 do not work, a problem that I'm still trying to resolve.

On the plus side, I took the aircraft up for a test flight a couple of evenings ago, climbing to 15,000 ft without any problems, so aerodynamically, it is flying quite well, though with no lights, I was pushing my luck on this late-evening flight!
upload_2015-8-27_12-33-35.png


FYI, progress will be somewhat slower in future, as I have some other work that I need to focus on in the months ahead.:(

regards,
FS-Tester
 
#31
@FS-Tester: Seems like everyone is getting busier nowadays! :( Keep up the good work!

@stonelance: Hey Steve, could you help me clarify some problems I'm having with getting the right shader working? I'm quite new to this, so my understanding is very little....

Anyways, here goes:

ContentErrors.log shows me this:
Code:
(0.000000, 0.000000): MaterialVariation '{D9701CBE-5699-4046-A0E7-7B041103AD1C}' failed to load because the ShaderPipeline '{C211B4EC-B30E-4740-A692-0EB3FAF62260}' does not support the supplied vertex format.
MaterialVariation Format:
  FLOAT16_4 POSITION0[1]
  UBYTE4 BLEND_INDEX0[1]
  FLOAT16_2 TEXCOORD0[1]
  FLOAT16_4 NORMAL0[1]

Supported Format:
  FLOAT16_4 POSITION0[1]
  FLOAT2 TEXCOORD0[1]
  FLOAT16_4 NORMAL0[1]
  FLOAT16_4 TANGENT0[1]

  FLOAT16_4 POSITION0[1]
  FLOAT16_2 TEXCOORD0[1]
  FLOAT16_4 NORMAL0[1]
  FLOAT16_4 TANGENT0[1]

  FLOAT16_4 POSITION0[1]
  UBYTE4 BLEND_INDEX0[1]
  FLOAT16_2 TEXCOORD0[1]
  FLOAT16_4 NORMAL0[1]
  FLOAT16_4 TANGENT0[1]

  FLOAT16_4 POSITION0[1]
  UBYTE4 BLEND_INDEX0[1]
  FLOAT2 TEXCOORD0[1]
  FLOAT16_4 NORMAL0[1]
  FLOAT16_4 TANGENT0[1]

  FLOAT3 POSITION0[1]
  UBYTE4 BLEND_INDEX0[1]
  FLOAT16_2 TEXCOORD0[1]
  FLOAT16_4 NORMAL0[1]
  FLOAT16_4 TANGENT0[1]

  FLOAT3 POSITION0[1]
  FLOAT16_2 TEXCOORD0[1]
  FLOAT16_4 NORMAL0[1]
  FLOAT16_4 TANGENT0[1]

(0.000000, 0.000000): MaterialVariation '{D9701CBE-5699-4046-A0E7-7B041103AD1C}' failed to load.
(0.000000, 0.000000): Failed to load aircraft material variation '{D9701CBE-5699-4046-A0E7-7B041103AD1C}'.
... whilst trying to make the glass more "realistic."

The closest supported format from the MaterialVariation I am currently using is:
Code:
  FLOAT16_4 POSITION0[1]
  UBYTE4 BLEND_INDEX0[1]
  FLOAT2 TEXCOORD0[1]
  FLOAT16_4 NORMAL0[1]
  FLOAT16_4 TANGENT0[1]
... but what does it all mean? How would this look like in .xml and what is the "vertex format"? :banghead:

Thanks,
 
#32
It looks like the shader pipeline you are using requires a per vertex tangent, but the mesh that it is applied to does not have one. That is something that is in the granny file. I don't think there is a way to edit it other than modifying the FSX model before conversion.
 
#33
It looks like the shader pipeline you are using requires a per vertex tangent, but the mesh that it is applied to does not have one. That is something that is in the granny file. I don't think there is a way to edit it other than modifying the FSX model before conversion.
Thanks Steve for that info. Don't think I can edit the model without source so nothing I could do about it... might just change to a different shader.
 
#34
FYI, I had similar problems with Flight shaders that could not work due to 'problems' with the original model. I found that many of the FSX models would display, in the exterior model, "black" glass rather than transparent, when converted. The glass in the interior model would be 100% reflective. I resolved this by both changing the shader and using modelconverterX. Often, the glass texture is a separate file in FSX. If so, I would remove all but the diffuse texture, and replace the original file with one of my own. I'd then tweak the material settings in modelconverterX to make it transparent. KavindaJD - I'll try to remember to send you a zip containing my glass texture & screenshot of the settings for it in modelconverterX next week, so you can see an example.

Cheers,
FS-Tester.
 
#35
@FS-Tester: Thanks, looking forward to it. Sorry, a little late to reply since I'm getting busier by the week!

@stonelance: Hey Steve,

I did get to some experimenting yesterday and today and realised that I needed to change the camera definitions. I noticed that the converter does covert camera definitions from the aircraft.cfg file but in my case, I need to adjust them a little. How do I do this?

I tried making a Camera.cfg file and adding a Camera.cfg.meta file as well, ensuring that the file is unique.. But to no avail. Where does the camera definitions go when the aircraft is initially converted?

Thanks,
 
#40
I haven't looked at anything in months. Can you give my a brief list of what you need again, and I can look into if I can get any of it done quickly?
 
Top