Creating a Virtual Cockpit for Level-D 767

Hello fellow designers:

I don't know if I can carry through this project, but I'll give it a good go.

I plan on creating a virtual cockpit for the Level-D 767.

Whether it will be working in sim I'm not worried about yet, it would be good just for the practice. I plan on using Blender for my 3D model and port it into MDL format through MCX.

Yes I understand that there's a LOT of work, but is my idea feasible? As in, if I throw in enough time and devotion, is it technically possible. Or are there existing barriers that prevents this? (i.e. non-FSX native model, no seperate VC and exterior.mdl)

Thanks in advance for a reply!

Help me out here, as from what I can tell the plane already has a VC.

IMHO the main part is to understand that the 3D model is only one part of the VC. The other is the systems simulation in the gauges, the gauges themselves and the animation control. This requires programming skills and at least as much time (if not more) than the 3D modelling. Even if you re-use all the original gauges, you will still have to at least analyze how they are tied into the animations in the VC (a switch does not visually flick to another position on its own, you have to write code for that to happen). And you might run into restrictions in the systems simulation, as LD built it to suit their own model, not yours. Reengineering things that other developers did without any code documentation is quite the challenge.

 

I would estimate a full rebuild of the VC to be something around 1000 hours of effort, plus/minus a significant portion depending on your current skill level. Double that, if you start implementing you own systems simulation.

The plane will have to be a fsx native model to be able to replace the VC.

Thanks for the replies, guys. Looks like it's going to be an undertaking. I need to learn the gauge programming from scratch, I assume it's written in C++? I originally planned to use LD gauges, but figuring it out requires me learning the language as well. I'll go with 3D model first, then (attempt to learn and) write. Don't have high (or any) hope of this becoming a final product, though. I'll see this as a learning experience, or maybe even do something easier before a 767. Thanks for the feedback, and are gauges written in C++?

Try a vc merge first. To get a more clear idea of what replacing a VC entails.

 

"Create" an aircraft to try it with. Like so:

-close fsx.

-copy folder b737-800 in Simobjects.

(so you en up with the 737 installed twice. One folder still called b737-800. the Other folder called "b737-800 - copy")

 

--------------------------------

rename "b737-800 - copy" to: "b737-800_merge_747VC"

Some more steps required then. All title= lines in the aircraft.cfg are the same, and fsx does not like that.

Also, the "new" 737 would have the same name as the "Original" one. Because in the aircraft.cfg the "ui_type=" and "ui_variation=" lines are the same as well.

You want to change that too.

 

Make a copy of the aircraft.cfg before you make changes.

THen open: aircraft.cfg

change every title= line simply by only adding:

--747VC at the end of the line.

 

The first one is:

title=Boeing 737-800 Paint1

change that to:

title=Boeing 737-800 Paint1--747VC

Do that with all title= lines in the file.

 

Do the same with the:"ui_type=" line.

For the first paint:

ui_type="737-800"

change that to:

ui_type="737-800--747VC"

Again, do that with every installed paint. Every ui_type= line.

The planes will then show in you Aircraft selection list,( as: 737-800--747VC), seperate from the default 737.

 

Because they are separately listed, (still as boeing, but not simply as 737-800), there is no need to also change each:

"ui_variation="

line.

--------------------------------------------

 

This would show every paint of this pnew plane in the list.

While you are installing the VC you may not want all the paints showing in your aircraft selection list.

If you just want to see one while testing:

Open the aircraft.cfg file in "b737-800_merge_747VC" again, and

For every paint you don't want showing, change:

panel=

to:

panel=***

(that means, for this paint, use the panel in folder: panel.***)

As there is no such panel installed, the paint's won't show.

When you are finished installing the VC, you can easily undo this, by just changing the lines back to:

panel=

.

 

--------------------------------------------------

 

After these steps, you have a seperate b737-800 you can mess around with without risking the original.

Try installing the 747VC in it. A VC merge.

 

For installing the VC, here's one guide. THere are many more though. Some clearer then others.

Just google: vc merge

https://forums.overclockers.co.uk/showthread.php?t=17996209

 

 

----------------------------------------------------------------------------------------------------

All this only works for native fsx aircraft models. In an fsx plane you will see three files in the model foder.

"plane name".mdl

"plane name"_interior.mdl

and model.cfg

 

In an fs2004 plane there is in the "Model" folder only two files:

"plane name".mdl

model.cfg

 

Some fs2004 planes do have a VC, but that is part of the "plane name".mdl file.

As you can't edit mdl files, that VC can not be edited or swapped with another.

 

You can't edit FSX .mdl files either. But there you can swap the *******_Intererior.mdl file with another.

 

How to see if a "plane name".mdl file is an FSX or FS2004 native model is explained in the guide explaining how to merge a VC.

are gauges written in C++?

 

Not exclusively. The standard implementation is an XML based proprietary dialect in postfix notation. It is described in detail in the SDK.

 

The next step above that (in terms of flexibility) is a "mixed" implementation of XML gauges incorporating a DLL (written in C++) as data source.

 

The next step again are purely C++ based gauges. These come in different flavours too, using either DirectX, GDI+ or Scaleform (FSX is limited to GDI+).

 

Making gauges requires a sound knowledge (or online searching strategy ;o) ) of Simulator variables and events, plus SimConnect if you want to do really advanced stuff.

 

The SDK documentation is a real treasure chest, with code examples of just about everything. But be prepared to run into dead ends too. A lot of the online suggestions and examples on the net are based on FS9 technology - this often works in FSX, but it is basically against the spec. I have spent many hours chasing virtual rabbits until I learned to ignore less helpful online advice and to just stick to the specification.

 

An example: programming a custom radar gauge in C++ / GDI+ took me about 100 hours. Granted, I have never done this before, but still - I have been a professional software developer for three decades now, and at first glance it didn't seem much of a challenge...

 

Come to think of it, my initial estimate is probably wrong. Rather triple that, a solid two years of full-time development should yield a fully functional and modelled VC. All that is left of the original airplane then is the aircraft definition files (how it flies) and the external model with liveries.

 

And you should ask for permission. Almost every EULA states quite forcibly that altering or reengineering the product or parts of it is forbidden. You should check that you don't stray into license-breaking territory.

 

btw. "figuring out the existing gauges": that is only possible for the XML based ones. All binaries (DLLs) that were written in C++ are compiled into machine code - there is no going back to the C++ source code from those. So IMHO you can scratch that part from the list, noone can reengineer binaries without help and source code from the original developer.

Thanks for the replies and insights, even less chance of me finishing this. I understand how to do VC merge, but thank you very much for that EXTREMELY detailed and easy to understand guide. I'm starting on the 3D model of a E135 in Blender, and I'll see where that goes. Which conveniently brings up one question: if the lighting is wierd in Blender's rendering, is it going to show up in the same wierd way in FSX/P3D rendering?

It's true that EULAs don't allow it, but if I can do it, I'm going to convince LD somehow. If it was possible, it might've have opened up a new market for them. As it stands, it's not possible, and if I want a better 767 VC, I'll need to start from scratch. That's why I'm starting with an E135, much easier goal. SDK documentations, I have read. Doesn't mean that I understand them though. I'll see what I can do. Thanks for the insights.