[iadesdragon]

Ahhh, to bad, simply having the Game Engine Rendering the Instruments / MFDs to a extra pane would have eased things ( thats what flight sims often offer to have the cokpit fiew rendered to another monitor.

OK then i believe we have an idea what to do i would think about an single MDF unit that can be 3.5" to aprox 5" (same Hardware different LCD module ).

This unit comunicates via USB or Ethernet ( Ethernet beeing prefered ). Display area will be touch senitiv ( why should a interface in 2335 be wors then todays smartphones ;-) ) surounded by a bunch of buttons that can be lit in several color and gave the option to insert text masks ( named buttons )

So if you like you can use several of those to build whatever cockpit you like.

This is ( besides the ethernet IF, what makes me quit happy because this setup will work for other sims as well making this an even more worthwhile project ) something i have on my drawing board anyway...

I think i can build a 3.5" version for aprox 3 time the price of the Nokia Add On board.

let me think....

SO i teak it you are quit eperineced in C / C++ are you?

With the Microchip MUC we get the worst for free (TCP/IP, Graphics, SD_Card Support, FAT16/32 etc... ) and the Dev tools are ( almost ) free ( besides buing a pickit2 debugger for 50$

[chief1983]

You guys should look into how the Battletech Firestorm pods are set up, the ones Virtual World takes around to conventions and such.  They're more than happy to talk about it with interested parties.

[Nuke]

ive heard of those but ive never seen one. id just love to sit in a mech simulator for awhile.

SO i teak it you are quit eperineced in C / C++ are you?

i wouldn't say im an experienced programmer, im just apparently very good at learning technology. i have no formal education in programming and electronics, aside from some highschool classes. i do have a 2 year degree in network admin (and zero experience in the field). that said programming on the pc is a lot of headaches for me. huge bloated libraries that theirs no hope of learning the internals of, and of course inconsistancies between compilers. at least with microcontrollers the code is kept simple so theres not a whole lot of hidden magic that makes your code work.

[iadesdragon]

Nuke,

thats a good starting point right away. While I'm more like a long time pro with this stuff, I'm not to good with PC stuff, nor do i believe i`ve got the slightest chance getting into SCP Code Base.

While i believe I should be able to design the Hardware as well as the Embedded Software and a White-paper about how the system works, i really think we need a Pro in SCP Code to discuss the hows and whens of the SCP integration. We need to figure out how we get the HUD info out of FSO, as well as the 3 Dimensional Dynamic status of the Player ship. (6 DOF values ). Additionally there might be the need to have FSO listen to "key presses" reported over TCP/IP.

ANYONE willing to do some advanced thinking on the topic?

MODERATORS: Any chance we change the topic of the thread? I believe we really lost the original point now :-)

[chief1983]

Swifty is rewriting the HUD code, asking for some kind of hook system now would probably be a good idea.  He may even already have something like that in mind.  Of course you'd want input as much as output support which is  likely beyond what he's working on currently.

[Nuke]

we really just need a way for the game to talk to other things from the scripting system. scripting has access to physics data, position data, some facilities for rendering, ect. should be able to code up some kind of serial interface with only a few lines of code and provide an interface to it from scripting, of course if you want to talk to usb or the network, youre probibly gonna need more code. the interface would probibly consist of read/write buffers, a send command, a read command, probibly a command to check if any bytes were received, a setup command, and possibly some conversion functions to accomidate lua's weak typing (lua would convert any data to a string and send it as chars, these could be read at the other end as binary).

Swifty is rewriting the HUD code, asking for some kind of hook system now would probably be a good idea.  He may even already have something like that in mind.  Of course you'd want input as much as output support which is  likely beyond what he's working on currently.

pretty cool. if theres support for spewing out individual gauges as textures, then we would only need a lua function to read that image's data, get its format information, convert as neccisary and send it out (over whatever communication interface we use) to an mfd device. il need to see what swifty is up to because i wanted a few hud related features (lua hook as gauge for example, but thats for something entirely different).

[iadesdragon]

Using the script system sounds good, might be quit flexible and one could even implement MOD / Mission specific actions ( like special Target screens and such )

I will have some time off over the weekend, so i got some time to spend on doing a sketch and white paper on the stuff. I thing what is required is some kind of a mapper application that connects whatever the script tells to the actual hardware setuo that might vary from person to person (1-3 MFD extra switches e.g.)

If we can get swift to support this, i think we can manage to implement this. I think i even can get the help of a friend on the Mapper Application stuff.

In this case there should be all the people available to do this. ( if you like to Nuke and if we get some support by swift if needed )

I planed to do a MDF style system for OSX anyway ( because there is non available right now ) and tweaking this to have a specific mode that is perfect for FSO will be fun.

( I even found a way to implement real smoke if the MDF is destroyed ) ther can be several defekt animations on an MDF so flickering, dead, broken screen, Flash & Smoke :-)

As i although still like to make it move, is there a way to have a script executed permanently so that i can get the 6DOF vectors several times a second? I thing i figured out a software scheme that should give unbelievable cool motion feedback with reasonable simple hardware & electronics ( still heading to archive 500 Bugs material for the Moving seat )

 

[Nuke]

i talked to swifty and i think he was already planning for hud gauges to be rendered to texture. if so then we would just need an communication interface to send the data over, and something to convert a texture from bmpman into a stream of characters. the comm interface should be kept as application agnostic as possible. its not really that hard to come up with a command protocol.

as for the vectors, scripting has access to ships velocity, orientation matrix, rotational speed and so on and can run every frame. if acceleration is needed you could just compare last frame's data with the current frame. it should be simple compared to some of my other scripts.

im currently looking for an api that can handle inter-process communication with an external application. im trying to find something that will work on all currently supported platforms, and probably something that has a comparable license.

[iadesdragon]

Thats good news in fact. AT least my hardware is able to handle JPG decompression hardware wise.

I Spoke to newhaven today about displays and they can provide a wide variaty of Sizes. So actually my hardware will be roughly the size of a credit card. and you can hook up displays 2.4, 3.5, 4.3 or 5.7"

to ease design all of them initially will be 240x230 full color. in front of or surrounding every panel there will be a mezzanine board what allows for a selection of switch arrangements to complete the MFD.

I hope to finalize the schematic in the next few days and have layout done quickly so i can have some 2-3 PCBs done on my next PCB run.

the layout will support USB, Ethernet or Both additionally micro SD is supported so there is the option for vast storage up to several gig of Flash ( for small money ) the graphics sub system has a additional quarter meg of RAM for display buffers and is able to decode jpeg on its own ( additionally mjpeg seems possible ) the smallest version might go for 100$ while the 5,7 will be like 60$ extra so 160.

Landscape as well as portrait will be a simple means of software config. Anyway every kind of data will be excepted either raw data ( text strings, menu arrays, speed velocity percentage whatever ) and the hardware should even be able to render wire frame ship models. ( processors will be in the range on 10$ each )

i`ll start working now on the sketches to further detail what i plan to do and design.

[iadesdragon]

btw. got my trackIR today... way kewl now i really need some ships with good internal cockpits. For some reason i did not figure by now your mod is not working with my 3.6.12 RC2... ( lots of errors & chrash )

Thanks for the link to your scripts, i followed your work for a while and thats one of the reasons i´m willing to do open source work here ( seriously this will be my first open source project after we failed badly 15 years ago (which in fact has manly been because 15 years ago we still had the dark ages Internet wise  ))

[Nuke]

i kinda want to roll out a nukemod mainenance release to fix some of the bugs (last release is nearly 4 years old!). theres some stuff thats almost ready to be added, a couple htl models that are very near complete. haven't really added anything new mainly because i was working with the scripting system. il probibly release it after the 3.6.12 rc phase, since new bugs may manifest before the code is finalized. the scripts on the svn are still in development, but you might want to check out the cockpit demo. it has cockpits with animated interior and render to texture radar and camera panels (also has things like uav drones, laser guided missiles, multitargeting, and a bunch of input related features.). i tested it against 3.6.12rc2 before i uploaded it so it should be working.

[iadesdragon]

Yah! Cockpit Demo sounds pretty cool, is there i zip? or do i simply fetch it from svn?

[Nuke]

fetch it from svn. i havent provided a zip yet because its still in testing. once i make it more user friendly il throw a zip together. its not obvious how to use some features of the game. you can edit input.tbl to change settings (just be careful, my tbl parser doesnt spew out useful warnings yet) and controls for the mod. there should be some missions to play. if youre using a hotas you may want to consider using the split throttle feature, theres also a way to use the mouse to control latteral thursters if you so happen to be using a joystick with a trackpoint mouse on it.

im also looking at named pipes for getting data into and out of freespace. should be able to get at them with file i/o functions. however im not sure how multi-platform they are.  but it might already be possible to use them from scripting with cfile. it would still require an external program to talk to hardware (but ive already written a few of those).

[Tomo]

im currently looking for an api that can handle inter-process communication with an external application. im trying to find something that will work on all currently supported platforms, and probably something that has a comparable license.

Here's a really off-the-wall idea - how about using CITP to do this?

CITP is an open, royalty-free protocol for Media Servers and Lighting Control applications designed to stream multiple video plus a lot of 'background' data, and includes automatic discovery of 'sources', 'sinks' and controllers.

It's multicast and TCP/IP, so works on any IP network.

The protocol definition is available from http://www.citp-protocol.org/ - I'm pretty sure I've got a reference implementation somewhere.

Admittedly, using it for game data is about as far away from the core idea of CITP, but it's a pretty robust protocol that's used pretty widely in the theatrical, TV and 'live event' industries, where 'real time' is extremely important!

[Nuke]

the idea is to talk to another program on the same computer, and then that program could in turn talk to whatever interface(s) you require. since this interface program is running in an entirely different thread, it wont slow down the game with interrupts (serial for example is notorious for this). any api or protocal can be implemented into the middleware as needed. since simulators are a major diy project with a number of custom hardware and software components, it is good to leave the interface to the game as general as possible.

[Tomo]

The network stack is a perfectly fine way to communicate with other applications - it's probably the most platform-agnostic method, and it lets you run that 'other stuff' on a completely different PC if necessary.

Pipes are quite different across the various operating systems.
- *nix tends to do pipes much better. They always feel like a bolt-on in Windows.

That said, there's a lot of better ways to send video streams, for example it would be cool to use the same protocol as used by Windows Media Player and MythTV etc for sending television across a home network. However, I do not know where licensing stands on that one, and there appears to be less capability for metadata (though I could be wrong)

[Nuke]

sounds too specific though, and the last thing i want to do is throw a new api into the engine without looking at everything first. im sorta screwing around with named pipes right now to see what they can do. good ol quake style ip loopback is a good idea though, but id have to look into how it would work with the existing netcode.

[chief1983]

The planned memory tracking application was going to be communicated with via TCP.  This could function similarly.  Would be good to make the system for that generic enough to be utilized by various interfaces.

[iadesdragon]

Hi All,

promised to have some updates on the hardware stuff, however there has been some drama in the last days so i did not have a chance to sketch anything ( my father in law managed to lose our family dog in the woods and we had to SAR it :-) for three full days )

however... to get an idea of what i plan to design in means of motion...

have a quick look to www.bluetiger.com

Tonight is sketching time anyway...

[iadesdragon]

OK, a little update for now.

I Figured a way to design the motion platform so that it is able to perform the same range of movements that you can see in the Bluetiger Demos.
Basically i will build a 3DOF moving platform like the part underneath the seat platform. My design is different tough because i thing this should not be bigger then the usual office chair.

On top of this there will be a construction that is very similar to a deck chair with some prolonged arm rests to hold throttle, stick cockpit. Additionally it will  support a mount for an reasonably sized  LCD Screen.

All the g-force magic will be done in a micro-controller that controls the three motors used to move the platform. All that is required to do is to permanently send the orientation and velocity of the craft ( FSO Fighter, X-Plane Aircraft, M$ Flightsimulator etc.. ) to the Moving Base using UDP ( Thats easy did that on quit some of the machines i designed in the past, this one e.g. http://www.datacard.com/products/products.jhtml?contentId=96316UdabtieZ2 ). UDP is fast and easy to use and you do not need to care about re-transmitted data blocks.

Target is to make this moving base as well as the cockpit controllers as easy to build and especially cheap as possible.

THe Bluetiger Solution e.g. STARTS at 6950$ ( thats only the moving base + the platform atop )

I believe they do not sell a lot of those...

I am, right now, at a BOM cost of approx. 1200$ for the base and still am working hard to get below 1000$. However this is the price for all the stuff required so a kit might be a little more costly.

You can build any style of Seat / Cockpit / whatsoever upon this base as long as total wight ( including pilot ) is below 200kg total. ( Maybe 250 need to have a friend calculate the mech. numbers in detail ).

The Cockpit panels now are similarly simple in design. A CPU board talking UDP that supports a range of LCD`s size of 2.4, 3.2, 4.3 and 5.7 inches all of them 320*240 Full color. ( the 5.7 might be used with a higher resolution as well.  ) in front / surrounding the LCD a Switch / Button / Knob assembly is mounted allowing for several ( easy to change ) configs of your cockpit setup ( you know, i do not only play FSO for fun but although other SIMs since I used to have my on plane and once had a pilots licence ).

You can set up this cockpit in any way you like using one or more CPU boards. This will allow for very classical meter style cockpit for General Aviation as well as futuristic "All Glass" cockpit layouts like one would use for FSO. All the LCDs are equipped with touch screens by the way.

The CPU boards handle pre defined graphics as well as basic animation and text display, additionally there will be the ability to stream low res digital video ( format TBD maybe MJPEG because hardware might support this directly )

Main target here will be to keep hardware cost as low as possible.

Still the main goal of my little ( or not so little ) Project is to build something that really adds to the realism and involvement into the game but still be very affordable ( Today you can build something like this that really is close to ONE specific aircraft nut you will need month to build it and a reasonable amount of money )

This should be fun i believe not an obsession therefore i think a usable moving cockpit for "Gaming" ( not ultra-realistic sim ) should not exceed 2000$ in a basic configuration and it should not take more then some evenings to assemble it and get it up running.

i´ll design this anyway for use with X-Plane on my MAC ( there is almost nothing like this with mac support right now ) but would love to use it with FSO as well (PC and/or Mac).

SO if there is interest to have FSO supporting this, let me know and we can setup a sub-project ( might even host it on my server ) that opens the gate on FSO.