Jump to content

Topic: Homebuild cockpits


Recommended Posts

[...] although probably preferred by the real guys.

Not really. Cockpits often need to be quickly reconfigurable, and you can only do that with screens. But as I've written in one of these threads, I think 3D instruments would work just as well for the 'real guys', as long as each gauge is a completely separate entity that can be easily rearranged on a blank 3D panel at will. If, on the other hand, everything needs to be pre-baked into one single virtual cockpit 3D model, as is the case with FSX, it wouldn't work that well.

Judith

Link to comment
Share on other sites

It's a small market, but as we think about a new simulator it would be silly not to think about them.

First, this is my first post in Aerosofts Forums.

Second, my english is not that good.

Third, I'm very glad that Aerosoft has started this project. Even thinking of it is a start in my eyes. So the project is moveing on.

About the homebuild cocpits, i agree that it's a must to support it. What is a cocpit, or a "pit" that some of us cal it? Well that is a wide deffinition. My pit is as we speek a stikk(with trottle), a monitor and the keybord. In the future I'd like to add the track IR. That is a must. After that I'd like a hardware for the autopilot, and after that a hardware for the gear and flap levers etc.

So the "pitt" does range from a smal sett of hardware, to fully integrated cocpits that look like the real thing. There is a lot of people that have a pit in some sort of way. And i don't think that it's a that smal market. Anywhy, I think that the "pit" market will gett bigger in the future.

So I'm happy that you do not forgett the "pit" builders, and the realy hardcore sim fans are cocpitbuilders

Link to comment
Share on other sites

Well, I think we're talking about setups that consist of considerable amounts of external, often home-made hardware and software here. A monitor, keyboard and joystick doesn't count: that's considered minimum system requirements, so to speak. Or put another way, I think we're talking about setups FSX doesn't support out of the box. For me, the term cockpit, in the context of flight simulators, means something that doesn't need a keyboard during flight.

Judith

Link to comment
Share on other sites

Well, I think we're talking about setups that consist of considerable amounts of external, often home-made hardware and software here. A monitor, keyboard and joystick doesn't count: that's considered minimum system requirements, so to speak. Or put another way, I think we're talking about setups FSX doesn't support out of the box. For me, the term cockpit, in the context of flight simulators, means something that doesn't need a keyboard during flight.

Judith

Well, i know that the a single stick is standard, and "minimum". I was talking about the market, and that the word cocpitt is wide, spanning from some few extra hardware to a fully working cocpit that looks like the real thing. The market is there, and as I said, I wan't to build my own pit, but the extent of it will not be as a complete 737 cocpitt. There is a lot of pits around. My pit will be a allround pit for flyeing what ever I'd like.

Link to comment
Share on other sites

  • 2 weeks later...

I will look forward for a throttle with full functioning flaps, spoilers, four levers and four "reversers", which only could be found in goflight and few very realistic throttles which costs more than $2000. It would be really nice if I can have one in a budget $300, not caring about the design. For some reason, those "reversers" are very important to me and I really want those stuffs.

Link to comment
Share on other sites

First of all, please get rid of FSUIPC. No, really. Don't get me wrong, FSUIPC is a great program - but it shouldn't be necessary. The work-around and convenience functions available to the 'ordinary' user should be either not necessary in the first place, or included in the sim itself. The data access functionality available to programmers should be provided by the sim itself, too, and should take a radically different approach, in my opinion. Each and every piece of data the sim knows and processes should be accessible through one coherent, clean, and extensible API, in their natural unit and data type. No more read an int, divide by 65536 and multiply by 360 to get some useful floating point value stuff, please. If a piece of data is not inherently integral, it should be accessible as a float or double, and in a unit that makes sense. As a side note, even data that is inherently integral at first glance, like the state of an on/off switch, could be a float that quickly goes through the range between 0 and 1 when the switch is flipped, instead of changing instantly, to facilitate smooth animation of the switch in the virtual cockpit, for example. Also, no more prehistoric BCD stuff, please. That being said, there needs to be an add-on or plugin that translates between the sim's native interface and the FSUIPC interface, of course, but that can (and should, in my opinion) be external to the sim. There is already such an interface for X-Plane, which could probably adapted to a different API rather quickly.

Possible scenario: The data access API is the central place through which everything, including the sim itself, accesses simulation variables. Each piece of data is referred to by a unique, speaking name (not some arbitrary, hard-to-remember number), which by convention forms a hierarchy. The system is extensible in that every part of the sim as well as every add-on can register new names/variables, which it has to provide an accessor function for. Every part of the sim as well as every add-on can access every piece of data, no matter where it comes from, as long as it knows it's name (probably derived from user/content creator input). For example, it doesn't make any difference if the animation of an instrument needle is based on sim/aircraft/engine[1]/manifold_pressure_inch_hg, a built-in variable, or whichcraft_inc/voodoo/magic_wand_angle_degrees, an arbitrary variable added by an add-on. The panel system just makes a request of the data access API for each variable/name it needs, and is handed the corresponding value in return, no matter where it comes from. The data access API also handles triggered actions through the same, unified system. There are only a handful basic commands that can be triggered, like toggle a variable/name between two given values, increase or decrease by a certain value, set to a certain value, etc. For cockpit builders, this system means they can easily access everything any add-on will ever implement and either display the data as they see fit, or change it (if the data is writable), possibly triggering a corresponding action.

The data access API also handles distribution of simulation variables across multiple networked instances of the sim, again independent of whether they are built-in or added-on. It has to take care that the precision of data is not degraded in that process (which happens in X-Plane, for example: Instruments running on the master machine are smooth as silk, but on a slave machine, some instruments stutter, while others are still smooth). To prevent network overload, every slave instance of the sim has to register each piece of data it needs for it's specific role with the master's data access API, which will then only send the requested data, not just everything it has. Also, the transmission rate is adjustable for each slave individually (no need to send data at 60 Hz to a slave that just displays an FMS).

Another important aspect for cockpit builders is the visual system. It should be possible to create real multi-channel (i.e. multi-monitor/projector) visual systems, either using individual PCs for each channel, or feeding all channels from a single, very powerful PC (with a many-core CPU and multiple graphics cards), or a combination thereof. Options should include the super-wide, but flat projection surface known from FSX and TripleHead2Go; dome and/or cylinder projections for the real hard-core cockpit builders and the professional market; and the typical multiple flat, angled screens configuration you get by arranging multiple monitors in a semicircle. For each channel/screen, you should be able to individually set the FOV, the angles between the screen and the pilot's view axis, and lateral and vertical offset from the view axis. For seamless projections, edge blending as well as some distortion parameters to correct various imperfections of the projection system (like keystone distortion) would be useful. Furthermore, synchronized screen refresh across all channels would be handy. I.e. each instance renders the next frame individually into the back buffer, and signals the master when done. Only when all display channels are ready does the master signal each channel to flip the front and back buffers. Of course, this only works correctly if the screens themselves are synced, too, which is probably a bit to advanced for the average cockpit builder - so this would be more for the professional version.

For copy protection, how about offering several options, like online activation, DVD check on start-up (but please skip the root kit stuff), or even USB dongles (to be purchased separately). If your licensing model will allow it, slave instances could verify themselves through the master. On the other hand, I think that if you spend thousands of bucks on hardware, even a couple hundred for individual licenses for each PC won't matter much.

If any of this sounds like X-Plane, yes, that's where many of these ideas come from... smile.gif

Judith

I know that's a lot to 'quote' from, but YES, I agree pretty much with all of this. I dont care about XPlane at all, but considering the limitations,etc. FS9 (and slowly FSX) is a great place to start when building a home cockpit. The problem is that it's really the only place to start unless you run the Aerowinx 747, and I believe that only a very few do that.

It's well known that the current way to run a home cockpit (I myself have a full scale Learjet 45- fully enclosed) is to have the simulator software running on one machine (Server) and then 1 or more clients running the networked avionics software. It's that simple. However, if Aerosoft has a way to offload CPU intensive extras such as AI, etc. onto a 2nd machine then by all means go for it. However, seeing as 4 cores are coming more and more popular Im not sure this is really required. However, getting back to the basic structure of what sets apart a home sim from a desktop is basically the mandate to run multiple machines to seperate our avionics from the view/world diplay. Definately make the FOV and everything associated with the views as flexible as possible and easy to 'stick' so that once perfected they wont require contstant resetting. Also, please make sure that the sim has an application that easily transmit whatever data we need across the network with minimal lag and performance hit so that gauge/avionic packages run as fluid and in real time as possible on their clients. I dont see why we would need to run a full version of the sim on each client- only a client app (like Wideclient) would be required and then just as important please document all of this so that 3rd party developers can easily get their avionics packages compatible with your new sim ASAP.

<side note: I have recently began playing Call of Duty 4 MW both online and in campaign mode as a stress reliever while rebuilding my sim. I am amazed and the fluid graphics I get in this SUPER Duper detailed environment. I know folks have argues, 'Well, it's a limited map and not as big as FS and, blah blah'... Please use a modern graphics engine that can do the graphics justice with performance first and foremost. I fail to understand how a flight sim with all of the horsepower we have nowadays with the huge monster graphics cards and quad core CPUS cannot run smoothly if it's designed that way from the begging. END side note>

As a must, I'd like to see a core sim that generates the scenery, flight dynamics, handles real world weather, basic ATC interface (even if it doesnt have ATC but can accept addons like Radar Contact or VATSIM), and a very open architecture for the 3rd party devs. If FS wasnt open, there would be no home flight decks.

All in all, Im very thankful you have considered the development of this package- Im looking forward to seeing what it becomes!

  • Upvote 1
Link to comment
Share on other sites

  • 4 weeks later...

well heres my 2 cents. why not just have a completely different package for cockpit builders. IE it includes 2 licenses one and 2 separate installers if it works that way, one for the interments and one for everything else. what ya guys think?

edit: as long as the poster above me is talkin about graphics, my suggestion is to make the game dx11 compatible. I am planning on getting a dx11 card ie: 5970 when i get the cash. so imagine dx11 AFS2012

  • Upvote 1
Link to comment
Share on other sites

You hit the nail on the head, Tomlin!

@evilgnomes: Just an FYI... Mathijs already said they wouldn't think of using anything but DX11 because they need the real-time tessellation.

And you're right -- just imagine a DX11 simulator! :blink::D

Link to comment
Share on other sites

It's a small market, but as we think about a new simulator it would be silly not to think about them. So let me know what FSX does wring for you pit builders.

I do understand you like to split sims into two parts, one that does the cockpit and one that does the external views. Something we fully agree with, they should be able to run on separate systems.

Talk to me.

Nice that you consider this...

One thing I hate with FSX is the way you setup your hardware... Not all options in the Sim are availble in the Setup... Therefor I use FSUIPC to control all my hardware and delete all settings in FSX setup...

It could be great if you made all possible options availble in some advanced setup and link it to an fully documented SDK

About license...

What about to make a volume license ?? Buy one for $ 99.- buy 2 for $ 159.- Buy 3 for $ 199.- (just price examples) - And with a later possibility to uptain more licenses when you need it and then collect the volume discount...

Another thing I would like to have, is a "2 core system"... One core the Server computer there give it all, and then a (near)free core from multiply client pc's, there have a two way communication, with the server PC, where you can setup aditional panels, Maps, you name it, but no hard graphics (external views, VC etc.)

*EDIT* Another thing I would like to have included is a fully integrated Shared Cockpit funktion over LAN and Internet (tcp/ip)

I hope you understand what I mean..

Best regards,

Leif Bramsing

Denmark

Link to comment
Share on other sites

  • 3 weeks later...

I'd like to add to the comments on a "multi-pc license" for simbuilders. One way that licensing could be allowed and assured woul be to allow the installation on the main pc and multiple on the same subnet IP address. you would have to license the main one through Aerosft over the internet and then if you installed it on additional pc's for use you would authorize through the internet also but would be required to be located on the same subnet as the main pc which was running anytime the additional pc's were on also. Someway of authenticating all this might work I would think. This would assure several things:

1 That any additional installs were for additional pc's and not a seperate standalone installation.

2 Ip address would be cross referenced with each other at startup to ensure that the 2nd, 3rd, etc installs wer in addition to the main install and are running concurrently.

3 If they were seperated that the one that was tryin to be used as the main pc could not be used as it did not communicate with the one that was initially authorized as the main pc.

Essentially the main PC would act as a license server and any additional installs would need to be on the same subnet with the "master" PC running in " Main FS mode"

I know this probably doesn't make sense in the way I worded it... maybe it does. In any case it should be relative easy to do.

Any questions let me know

Hank Jr

Link to comment
Share on other sites

Keep in mind that cockpit setups, especially professional ones, are often purposely kept away from the internet, so any activation scheme needs to work offline as well (e.g. via phone). And no, connecting to the internet just once for activation tends not to be an option, either.

Judith

Link to comment
Share on other sites

Hey there,

being someone who builds his own (generic) homebuilt cockpit I´d like to make you aware of a webssite (you may already be aware of) again, which to me sets the stage and documents the standards/state of the art for almost any aspect of this type of endeavour

http://www.fscockpit.com/index.html

I personally learned a lot and - once in a while revisit this page to get an impression where the field is heading to. I just recognized however, that the actual flight sim is the one and only notable exception. When visiting this site it´s becoming clear immediately, that there already exist(s) quite an enourmous amount of cockpit interface solutions to integrate the signals of all kind of cockpit elements available/on sale already as well. Any kind of new an approach should be generic enough to take these existing solutions into account seriously ( to vavoid uncoupling the actual sim from a lively development community.

Still, I very much appreciate aerosofts new initiative to - hopefully - solving some of the remaining big issues, that to me still exist

* Improved, state of the art plug and play technology

* More appropriate flight models

* Lack of multiprocessor usage cability, i.e. shear processing power !!

Link to comment
Share on other sites

  • 4 months later...

Hi there,

As a cockpit builder myself I would like to see proper support for the IOCards of Opencockpits. Most cockpit builders use these cards, are are supported by FS2004 and FSX.

Furthermore, control assignments for EVERY control is always fantastic. It eliminates the need to create FSUIPC Offsets or Macros. For example, I want to see a control assignment for Left IRS Mode Selector "OFF" position, that's how detailed.

Jack

Link to comment
Share on other sites

  • 3 weeks later...

It's a small market, but as we think about a new simulator it would be silly not to think about them. So let me know what FSX does wring for you pit builders.

I do understand you like to split sims into two parts, one that does the cockpit and one that does the external views. Something we fully agree with, they should be able to run on separate systems.

Talk to me.

As others have said, we need to access variables, tons of variables, from ground speed, longitude-latitude positions to translational and rotational accelarations, etc. I am currently building and FTD for a Boeing 767-300ER. If nobody develops a products that is somewhat compatible with what Peter Dowson created(a list of variable offsets with read-write access through IPC), I am through with the project. That is as simple as that. Or, I stagnate with FS9, forever.

Thanks for asking a paramount question.

Regards,

Fabrico

Link to comment
Share on other sites

  • 4 weeks later...

I'd like to add to the comments on a "multi-pc license" for simbuilders. One way that licensing could be allowed and assured woul be to allow the installation on the main pc and multiple on the same subnet IP address. you would have to license the main one through Aerosft over the internet and then if you installed it on additional pc's for use you would authorize through the internet also but would be required to be located on the same subnet as the main pc which was running anytime the additional pc's were on also. Someway of authenticating all this might work I would think. This would assure several things:

1 That any additional installs were for additional pc's and not a seperate standalone installation.

2 Ip address would be cross referenced with each other at startup to ensure that the 2nd, 3rd, etc installs wer in addition to the main install and are running concurrently.

3 If they were seperated that the one that was tryin to be used as the main pc could not be used as it did not communicate with the one that was initially authorized as the main pc.

Essentially the main PC would act as a license server and any additional installs would need to be on the same subnet with the "master" PC running in " Main FS mode"

I know this probably doesn't make sense in the way I worded it... maybe it does. In any case it should be relative easy to do.

Any questions let me know

Hank Jr

Hankjr,

You can't do the subnet thing. Most people use a service provider for access to the internet. That Service provider gives you 1(one) public IP address. The subnet they use is for your entire neighbourghood. Understand...in that subnet, there are a bunch of people, your neighboughs, the bakery shop on the corner, etc. Now that is why we use a small router/switch from D-Link or Cisco...at home. These will provide us the opportunity to create 'Private' IP addresses in a given subnet, i.e.(192.168.100.0 to 192.168.100.255 if your subnet is 255.255.255.0) Do you realize how many people on the planet have their PC on 192.168.100.1, millions, with the same subnet. So there is no way, Aerosoft can license a software and permit it to run on your subnet at home, because millions will be able to do that without ever registering.

Link to comment
Share on other sites

I think the intent was for all involved PCs to be on the same local network (i.e. reachable from each other without going through a router), rather than to have the same IP address. Such a scheme could easily be implemented via broadcasts, which aren't routed.

Link to comment
Share on other sites

  • 2 weeks later...

I think the intent was for all involved PCs to be on the same local network (i.e. reachable from each other without going through a router), rather than to have the same IP address. Such a scheme could easily be implemented via broadcasts, which aren't routed.

Well, in a switching environment, the Ethernet frames are switched from ports to ports according to the switching table that recognized which mac address is reachable through which RJ-45 connector on the switch. You don't have to use broadcasting of Ethernet frames. As a matter of fact, you don't want to use broadcast if don't have to. As long as each network element know which mac address the frames are destined to, broadcast is not happenning. Only when a mac address is not in the switching table, will there be a broadcast to get an answer from the 'newly added' network element. And then, its mac address added to the switching table and bye bye broadcasts.

Broadcasting Ethernet frames generates a lot of traffic for no justifiable reason in such a LAN setup. the point I was making earlier however was that a software company cannot grant a license for a software peered with the IP address a given PC will have, because as stated above, PCs have a lot of the same private IP address and that license could be copied and sent to anybody, and they'd just need to put their PC on this address and the 'otherwise protected' software would run on an unlicensed PC. So this scheme has no viability.

Regards,

Fabrico, CCNA

Link to comment
Share on other sites

Once again, as far as I understand, the proposed licensing scheme would not work with specific IP addresses, but with reachability on the same subnet. The fact that multiple PCs on different, unrelated subnets happen to have the same private IP address is not an issue, because these PCs aren't able to connect directly to each other. The actual IP address wouldn't be used directly in this licensing scheme. And besides, the details of how packet propagation is handled in specific pieces of hardware are kind of moot from a software design point of view.

Judith

Link to comment
Share on other sites

  • 5 weeks later...

You should offer a stripped version of the game, with only the graphical engine, that will only able to connect to a complete version.

This stripped version won't need any protection because, by design, it will be useless and unusable if not connected to a master install.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy & Terms of Use