YAME64 suite

roccio

Y.A.M.E. v1.2.1 release

Read the manual with all the news and download the latest (1.2.1) version from the http://www.yame64.com/ site!
One quick note, the layout files of v1.1 are NOT compatible with this new version, so you have to do some work again.

Roccio, Focaldesign and BVT_Scorpion (our new team member!)

Note if you used the previous version of YAME and the Direct3D hook:
as the dll hook is no more compatible with the previous version you have to delete the old hook manually. Go to <falconbmsdir>\Bin\x64 and delete the file d3d9.dll (it’s a YAME file, so no problem with Falcon itself).

Y.A.M.E. v1.1.0 release

by Roccio and Focaldesign

Y.A.M.E. (Yet Another Mfd Extractor) is a suite composed of various parts for a complete interaction with Falcon 4.0 BMS 4.33. It allows flight data & texture extraction, sending callbacks to BMS, launch external programs. It can be used via network or on the same pc running Falcon. You can create your preferred layout using the build-in layout editor.

Here some examples (all made by Focaldesign)

Via DirectX hook you have the possibility to even display MFDs, RWR and DED in front of the Falcon window!

Imeges for tha gauges are from real pics and from the wonderfull TomCatz hires textures.

As you can see in the images various gauges are included, so you can build your cockpit with PW engine gauges, older block, MLU specific and plus some fictional like the ATD, CenterPedestal block 60 (with moving map) and some futuristic digital gauges.

With the correct settings (you will find more infos in the manual) you can build a instructor/trainee system, with the instructor viewing all the instruments in real time.

Update 30 Nov 2016
v1.1 has been released.
Get it at http://www.yame64.com/download/
See what has changed/fixed/added over at http://www.yame64.com/download/changelog/

Take a look at the manual for more info and see all the possibilities!</falconbmsdir>

Raptor

Will test and let you know, thanks!

roccio

Added an “engine” window setup (just as an example.

And here the modifications to make on the config.xml of the YAME64_client

In the <windows>section add

    <window><name>ENGINE</name>
        <width>500</width>
        <height>850</height>
        <posx>0</posx>
        <posy>0</posy>
        <fullscreen>false</fullscreen>
        <border>true</border>
        <visible>true</visible>
        <background>2F3438</background></window> 

Then below, on the gauges:

 <oilpress><width>100</width>
    <height>100</height>
    <posx>0</posx>
    <posy>0</posy>
    <visible>true</visible>
    <window>ENGINE</window></oilpress> 

 <nozzle><width>136</width>
    <height>136</height>
    <posx>0</posx>
    <posy>100</posy>
    <visible>true</visible>
    <window>ENGINE</window></nozzle> 

 <rpm><width>136</width>
    <height>136</height>
    <posx>0</posx>
    <posy>236</posy>
    <visible>true</visible>
    <window>ENGINE</window></rpm> 

 <ftit><width>136</width>
    <height>136</height>
    <posx>0</posx>
    <posy>372</posy>
    <visible>true</visible>
    <window>ENGINE</window></ftit> 

 <fuel><width>200</width>
    <height>200</height>
    <posx>0</posx>
    <posy>508</posy>
    <visible>true</visible>
    <window>ENGINE</window></fuel> 

 <hydpressa><width>100</width>
    <height>100</height>
    <posx>0</posx>
    <posy>712</posy>
    <visible>true</visible>
    <window>ENGINE</window></hydpressa> 

 <hydpressb><width>100</width>
    <height>100</height>
    <posx>100</posx>
    <posy>712</posy>
    <visible>true</visible>
    <window>ENGINE</window></hydpressb> 

 <epufuel><width>100</width>
    <height>100</height>
    <posx>220</posx>
    <posy>712</posy>
    <visible>true</visible>
    <window>ENGINE</window></epufuel> 

 <cabinpress><width>150</width>
    <height>150</height>
    <posx>334</posx>
    <posy>684</posy>
    <visible>true</visible>
    <window>ENGINE</window></cabinpress> 

 <clock><width>200</width>
    <height>200</height>
    <posx>287</posx>
    <posy>467</posy>
    <visible>true</visible>
    <window>ENGINE</window></clock> 

 <fuelflow><width>145</width>
    <height>126</height>
    <posx>227</posx>
    <posy>107</posy>
    <visible>true</visible>
    <window>ENGINE</window></fuelflow> 

```</windows>

roccio

Standard Central Pedestal

And as usual the config file updates:

in <windows>```
<window><name>CP</name>
<width>471</width>
<height>683</height>
<posx>0</posx>
<posy>0</posy>
<fullscreen>false</fullscreen>
<border>true</border>
<visible>true</visible>
<background>2F3438</background>
<showkey>F3</showkey></window>

and in the gauges set:

<vvia><width>96</width>
<height>218</height>
<posx>372</posx>
<posy>240</posy>
<visible>false</visible>
<window>CP</window></vvia>

Focaldesign

alright, will be testing this in the future.
RWR & DED are bitmap extraction out of sharedmem I assume? So it will correctly show non default block 52 rwr like carapace & other MLU’s also?
Any chance in the future we can have something like MFDE has for ATD RWR screen, but with correct symbology for the other RWR types? That’s what I’m missing in MFDe now.
Is EHSI also extracted or only HSI possible?
Are there MLU specific versions of VVI (needle instead of tape) and RPM that only goes to 100%?

roccio

@Focaldesign:

alright, will be testing this in the future.
RWR & DED are bitmap extraction out of sharedmem I assume? So it will correctly show non default block 52 rwr like carapace & other MLU’s also?
Any chance in the future we can have something like MFDE has for ATD RWR screen, but with correct symbology for the other RWR types? That’s what I’m missing in MFDe now.
Is EHSI also extracted or only HSI possible?
Are there MLU specific versions of VVI (needle instead of tape) and RPM that only goes to 100%?

Yes, DED and RWR are extracted from the texture. Shared memory if you enable it or via DirectX hooking (for me think it’s smoother). It will show the RWR that is presented in the cockpit.
For new gauges, like ATD RWR screen (sorry but I don’t know how it is, need to study) and EHSI there is no big problem in adding, just need to know the functions and get some images.
The MLU VVI is already implemented, check documentation.

Arty

any thought or help for guys with shofth that already have a d3d9.dll?

bigot

Thanks for the effort and sharing roccio!

One small (and excuses me if stupid ) question, any chance the client is available for a 32 bit system? (while server runs on 64 bit system?

roccio

@Arty:

any thought or help for guys with shofth that already have a d3d9.dll?

For now you can use standard shared memory extraction, no need to use the d3d.dll hook. I wil look in the future if it’s possible to integrate the two.

One small (and excuses me if stupid ) question, any chance the client is available for a 32 bit system? (while server runs on 64 bit system?

No stupid question, I have not tested it, but I can try to compile the client in 32 bit version and make some test. I don’t think there will be problems.

bigot

@roccio:

No stupid question, I have not tested it, but I can try to compile the client in 32 bit version and make some test. I don’t think there will be problems.

would be awesome, thanks!

Arty

Since on it…

Could you please give it a try and for Linux systems?
I’m talking about the client.

My thought. Many of us have old pc’s laying around that can’t cope with win7, or there are drivers problems non existing for win7 and older ones don’t do the trick, so xp is the only way, even though and xp are a bit heavy.
A unix system on the other hand run’s rocket high on those systems.

Finally if no unix a xp 32 bit is a must I believe as it will take advantage of current hw.

gofrm

having a linux client would be great. I 'm thinking of having a couple of RPis instead of a “full fledged” desktop pc for displaying the MFDs and gauges in a networked pit-setup.

roccio

I have used SFML libraries for the client for portability pourpose. So I think it would be quite easy to port the client to Linux systems, but for try it I must install a virtual machine.
For WinXP 32 bit it’s far easy, in fact it’s just a matter of compiling the source with the 32 bit version of SFML.
All in my to-do list.

roccio

Added the 32 bit version for the client. I don’t have a true 32 bit machine, so have not tested :).

Link is in first post.

bigot

Haaa, RPi would also be so nice…
It looks SFML could be ported to RPi as well…: http://blog.aldeo.io/post/116365980469/raspberry-pi-and-sfml

bigot

@roccio:

Added the 32 bit version for the client. I don’t have a true 32 bit machine, so have not tested :).

Link is in first post.

now this is what we call best service
thanks, will give it a try,

roccio

@bigot:

Haaa, RPi would also be so nice…
It looks SFML could be ported to RPi as well…: http://blog.aldeo.io/post/116365980469/raspberry-pi-and-sfml

I have a Raspberry Pi 2, but the only problem is that SFML is based on OpenGl for the rendering and it’s not fully supported by RPi, so the rendering will be very slow. Maybe in the future I will write a client version with custom libs for the pi.

bigot

server doesn’t start (windows 10, 64): “MSVCP140.dll missing” ?

roccio

@bigot:

server doesn’t start (windows 10, 64): “MSVCP140.dll missing” ?

There are two dlls that are part of the Visual C redistributable runtime. You can google it and put in the same folder of the exe, od on Windows/system32 folder, or download the package here

https://www.microsoft.com/en-us/download/details.aspx?id=48145

bigot

ok, copied 2 dll’s from freedll (msvcp140 and vcruntime140) and errors dissapeared.
however, nothing happens when server starts and program ends.
Have to go now but will try later on.

YAME64 suite

HOT LIST

System Specs:

HOT LIST

System Specs:

43

10.0k

21.7k

357.1k