YAME64 suite
-
yes, or just copy the desired xml from <yame_installation>\layouts\ to the destination file.</yame_installation>
-
Just wondering, are there any plans to “replace” what GPT does? Specifically, I need the sharedmem transmit/receive and keys transmit/receive… YAME already does the displays and gauges, so it accesses the sharedmem data from the main PC, I just need the sharedmem data to be “open” on the slave PC so that Helios can use the data as well. I know that there are already plans for key transmit/receive as YAME already has the Keyserver function, but I wonder if it’ll support external input?
-
Just wondering, are there any plans to “replace” what GPT does? Specifically, I need the sharedmem transmit/receive and keys transmit/receive… YAME already does the displays and gauges, so it accesses the sharedmem data from the main PC, I just need the sharedmem data to be “open” on the slave PC so that Helios can use the data as well. I know that there are already plans for key transmit/receive as YAME already has the Keyserver function, but I wonder if it’ll support external input?
It already can in a way.
If you look in the Yame folder you’ll find a htdoc subfolder. There’s an ICP html file in there. If you check the key server option in the yame server tab and run the server, then browse with your pc or tablet on the same network to your local ip port 8080 to that html page (e.g. 192.168.0.17:8080/ICP/index.html) you’ll see the ICP.
In the subfolder “js” there’s a sender.js which requires you to set your local IP address too manually (for now) on the 3 relevant javascript lines.
Every touchable zone in the html has the BMS callback as id. When clicked/touched that ID is sent via the send.js to the ip:8080 and the key server will translate that callback to the corresponding keystrokes found in your keyfile (if you pointed to on in the yame UI program). So if you make something that sends callbacks to the key server, it should work in theory. -
Yeah, managed to get that to work but Helios operates differently…. just slightly differently…
-
Just wondering, are there any plans to “replace” what GPT does? Specifically, I need the sharedmem transmit/receive and keys transmit/receive… YAME already does the displays and gauges, so it accesses the sharedmem data from the main PC, I just need the sharedmem data to be “open” on the slave PC so that Helios can use the data as well. I know that there are already plans for key transmit/receive as YAME already has the Keyserver function, but I wonder if it’ll support external input?
I too “need” that feature. Funny thing is that due to my config, the server PC for the MFD extraction is the client PC and key receiver of all the key commands other than the ICP which is attached directly to the main PC. A total mess… But works… [emoji13] [emoji13] [emoji13] [emoji13]
Although it would be nice to have this feature implemented in YAME, there is a simple “workaround” which is to add the GPT key transmitter and recover in the RUN tab as one of the auxiliary programs to run before running BMS.
But to be able to do so YAME should support the addition of .bat files to the run menu, since the hot key transmitter/recurved are Java applications that are run through a .bat file.
Devs already told me that this suggestion is noted. You know… 3 or 4 weeks…[emoji12]
-
jcenzano, can you help me configure GPT’s key transmitter? Can’t seem to get it to work again… it did before. Check out my post in the GPT thread please! Thanks!
-
I too “need” that feature. Funny thing is that due to my config, the server PC for the MFD extraction is the client PC and key receiver of all the key commands other than the ICP which is attached directly to the main PC. A total mess… But works… [emoji13] [emoji13] [emoji13] [emoji13]
Although it would be nice to have this feature implemented in YAME, there is a simple “workaround” which is to add the GPT key transmitter and recover in the RUN tab as one of the auxiliary programs to run before running BMS.
But to be able to do so YAME should support the addition of .bat files to the run menu, since the hot key transmitter/recurved are Java applications that are run through a .bat file.
Devs already told me that this suggestion is noted. You know… 3 or 4 weeks…[emoji12]
See my respons to ice. Keyserver is in there.
Running bat files is ready in 1.0.1 (already tested it). Still need to test some other features roccio already did for 1.0.1 but I’m not at home til Monday evening. -
GPT keytransmitter is annoying the feck out of me! I am writing this post using the keyboard that is attached to the slave PC. I’ve also opened Notepad++ on my slave PC so I’m essentially typing this once but it’s being typed out twice… one on this thread which is on the main PC and another on Notepad which is on the slave PC. So I KNOW keytransmitter is working. But why does it not want to transmit any of my Helios keystrokes?
I’ve also confirmed that Helios outputs keystrokes. You have to load up a .key file just so that it knows that CALLBACK ABC is SHIFT+D and CALLBACK WXY is SHIFT+Z but if I have Notepad++ open and I have two push buttons on Helios and I press the first one, “D” will appear on Helios and if I press the other one, “Z” will appear. So Helios does NOT output callbacks, just the keystrokes associated with those callbacks.
So why is it not working in GPT keytransmitter??
-
Has anyone used YAME64 successfully with the F-18 in BMS?
All the best,
Uwe
-
I am another who fiddled for a couple of hours trying to get the hook functioning on a client-only PC, naturally launching BMS with the YAME/Run button. Non-hook texture rendering functioned fine. I tried everything, grasping at any potential straw, then all of a sudden, it magically began working using the same settings I had tried several times previously. The last protocol I experimented with before the hook began working was to restart YAME and change the global BMS folder setting to bin/X64. Of course BMS would not even launch then; however on changing the global settings back to the main folder, the hook began working. Probably a totally spurious event, but it does now function properly. I guess the message is “Be persistent.”
-
Has anyone used YAME64 successfully with the F-18 in BMS?
All the best,
Uwe
Uwe, this first Y.A.M.E. version dos not work properly with the F-18 the same way as GPT did not work with it unless you changed the coordinates of the different areas to extract from the texture with the MFDs, HUD, RWR and DED.
In YAME, there is no way to change those coordinates, but Devs took note of our request. So we will have to way until a version of yame that support f-18 displays extraction is released.
In the meantime, you can extract F-18 displays using GPT a modified version of the “gpt-displaysreceiver-cfg.json” file, with the correct extraction coordinates for the F-18.
-
I am another who fiddled for a couple of hours trying to get the hook functioning on a client-only PC, naturally launching BMS with the YAME/Run button. Non-hook texture rendering functioned fine. I tried everything, grasping at any potential straw, then all of a sudden, it magically began working using the same settings I had tried several times previously. The last protocol I experimented with before the hook began working was to restart YAME and change the global BMS folder setting to bin/X64. Of course BMS would not even launch then; however on changing the global settings back to the main folder, the hook began working. Probably a totally spurious event, but it does now function properly. I guess the message is “Be persistent.”
This, ^ I just installed new yame last night and spent a while getting it setup, single pc running client, with just mfd’s to start on another monitor. Couldn’t get the hook to function. Starting bms through the yame button, it worked fine if bms was windowed, but not full screen. bms would load as usual then dump me back to windows with an error I think that related to the d3d9 dll. Spent another while trying various things, not much luck. Went back to original settings, and got it working. But bms crashed when I exited, tried it again and it worked fine, will do more testing. Looks a great app, thanks for all your work guys
-
Small issue:
I’ve been loading up YAME on three different computers in my attempt to run my setup over a networked PC and during one of those moves, I configured YAME to work as I want but I can no longer edit the EW tab… I was fiddling with the RWR settings so that I’d get the standard background, got that, and saved my layout. Now, everytime I go to CLIENT -> GAUGES -> EW, the program crashes. -
Small issue:
I’ve been loading up YAME on three different computers in my attempt to run my setup over a networked PC and during one of those moves, I configured YAME to work as I want but I can no longer edit the EW tab… I was fiddling with the RWR settings so that I’d get the standard background, got that, and saved my layout. Now, everytime I go to CLIENT -> GAUGES -> EW, the program crashes.Known issue. It’s caused by the rwr image not found. To solve this, for now, open the layout xml file ith a text editor and set the correct path for the rwr image.
-
Hi,
thank you for your very nice tool! I like the Block 60 mod with moving map! :-))) I run it in server / client mode over network.
After setup it works with “hook” or “rtt” setting in network for me. The “hook” setup only, if the server runs in client mode with “also run server” option activated. Never got “server only” to run.
Only big problem I have are big stuttering in all instruments, if I switch TGP and WPN screen (maverick) on. Then all instruments are laggy whether texture instruments are activated or not. Problem persist, if only gauges are activated on client too. In both modes!
Server runs with about 40-50 frames. Tried multiple “refresh rates” settings and “smooth textures” setting on server or client! No joy.
No problems with MFDE over network or Duncs RTT extractor.
About same frames in game with “hook” or “rtt” setting. It differs only around 3-5 frames. I have an AMD R9 290X on both computers…
cu
Cop
-
Known issue. It’s caused by the rwr image not found. To solve this, for now, open the layout xml file ith a text editor and set the correct path for the rwr image.
That was it, thanks! My RWR image was under a different drive directory so naturally, when going to a different PC, it wasn’t there. Sorted now!
-
Hi,
thank you for your very nice tool! I like the Block 60 mod with moving map! :-))) I run it in server / client mode over network.
After setup it works with “hook” or “rtt” setting in network for me. The “hook” setup only, if the server runs in client mode with “also run server” option activated. Never got “server only” to run.
Only big problem I have are big stuttering in all instruments, if I switch TGP and WPN screen (maverick) on. Then all instruments are laggy whether texture instruments are activated or not. Problem persist, if only gauges are activated on client too. In both modes!
Server runs with about 40-50 frames. Tried multiple “refresh rates” settings and “smooth textures” setting on server or client! No joy.
No problems with MFDE over network or Duncs RTT extractor.
About same frames in game with “hook” or “rtt” setting. It differs only around 3-5 frames. I have an AMD R9 290X on both computers…
cu
Cop
Never had stuttering issue in all tests. Please send me (better in pm) all your configuration file (YAME64.xml and <your_layout>.xml) I will test them and try to find the issue.</your_layout>
-
Spent the last 2 days testing and gathering data and it seems that YAME with HOOK is slower than just using YAME? I’m getting an average of 48fps with just YAME and I’m getting 46fps when using HOOK.
set g_bExportRTTTextures 0
set g_nRTTExportBatchSize 2From page 11 of the manual:
For BMS shared memory , so check that you have set g_bExportRTTTextures to 1 in your falcon bms.cfg file
(located under \User\Config of your FALCON installation folder).
Max clients works as for the flight data.Use Direct3D hook (which is mutually exclusive with Export texture data) for enabling the texture extraction
via Direct3D hook. You do not have to have set g_bExportRTTTextures to 1 in your falcon bms.cfg file. It’s
even better to turn it off (set g_bExportRTTTextures 0) to have better performance. On some systems using
the hook seems to be much smoother and saves up to 20 FPS, so try it for yourself.I wonder what the specs were of the test system and what methodology was used to test for fps?
-
Hi Ice, what we write was the results of months of tests in our systems. Maybe for your configuration it’s better not to use hook. Use it the way it runs better, we give as many possibilities as we can, so one can fine tune with his own system.
-
Spent the last 2 days testing and gathering data and it seems that YAME with HOOK is slower than just using YAME? I’m getting an average of 48fps with just YAME and I’m getting 46fps when using HOOK.
I wonder what the specs were of the test system and what methodology was used to test for fps?
Definitely not my case.
As I stated in earlier posts, I get a very nice fps boost, specially when displaying the TGP and/or WPN page.
But important thing is that now we have different options and everyone can try what works better on their rigs.