YAME64 suite
-
Uninstalling via Control Panel throws an error that it is already uninstalled. Which it is not.
YAME uninstall works though. -
Icarus, check PM.
-
That’s not what I’m doing at all.
I have v5 all set up.
I go to the CLIENT > MISC page, click SAVE LAYOUT, and select v6.
It asks me if I want to overwrite, I say yes. I also click APPLY.
For lolz, I click SAVE LAYOUT again, and select “overlap version”.
It asks me again if I want to overwrite, I say yes. I also click APPLY.
I go to the RUN page and start YAME client.It shows me the overlap version layout.
I stop the profile, go to CLIENT > MISC page again, click LOAD LAYOUT, and select v6. I click APPLY.
I go to the RUN page and start YAME client.Same deal, it shows me the overlap version layout.
I stop the profile, go to CLIENT > MISC page, click LOAD LAYOUT, and select v5. I click APPLY.
I go tot he RUN page and start YAME client.It shows me v5 layout.
Note that I don’t change any settings or anything at all, I’m just overwriting v5 into v6 and “overlap version” but this doesn’t seem to be the case.
Interestingly, I seem to have stumbled upon the solution. I noticed that when loading v6, it gives me a wonky picture of the gauges. I started up the sim and noticed that the gauges worked but the picture was not right. The issue was that under v6, it saves the gauges similar to v5, but it had the masking properties of “overlap version.” I had to nudge one gauge on RIGHT WINDOW and one gauge on LEFT WINDOW to force YAME to re-calculate masking values for both windows, then save the profile.
I love how YAME is mimicing the program it was designed to help out…. there’s the Falcon dance, now there’s also a YAME dance…
Lol.
Aha, so the issue is related to the masking. The mask is actually a png file saved of the negative/inverted view. So the black parts will be left as is and the white parts will be made transparant during client loading. The reference to the mask file is saved in the layout file IIRC (not behind my pc right now), so I’m guessing when you save, it saves the reference to another mask file which isn’t going to work properly or something.
Logging the above details in our bug tracker. -
This is odd because like I said, I’ve got v5 up and running, so the masking for v5 is up as well. However, when overwriting v5 into v6 (and into “overlap version”), it seems to only rewrite the gauge info but not rewrite the masking info.
Yay, I foung a bug!! L337 b3t4 t3st3rz!! :bdance:
-
This is odd because like I said, I’ve got v5 up and running, so the masking for v5 is up as well. However, when overwriting v5 into v6 (and into “overlap version”), it seems to only rewrite the gauge info but not rewrite the masking info.
Yay, I foung a bug!! L337 b3t4 t3st3rz!! :bdance:
Yeah, to avoid to have to slow “calculating mask” thing every time you start the client, we’ve made the logic that the client reads the path to the mask file and then checks if the layout xml is newer then the mask file. If so, the layout has changed and the mask should be regenerated. Something is going wrong there I think.
I’ve tested masking a lot, but never came up with the idea to save into a new version and change things afterwards.
Nice catch. -
So I’m guessing the masking data is different from the saved gauges data? Can you not tie the two together? ie, something like
v5 gauge data - v5 mask data
v6 gauge data - v6 mask data
v7 gauge data - v7 mask dataThat way, I can generate mask data for each of my versions and can swap between versions easily and always have the correct mask data for that version. Sure, I’ll have to run the “calculating mask” each time I update a version, but I shouldn’t have to calculate if I’m just loading up one version or another, right?
then checks if the layout xml is newer then the mask file. If so, the layout has changed and the mask should be regenerated. Something is going wrong there I think.
Well, I overwrote v5 into v6 and “overlap version” so the .xml files for those should be “newer” than the “overlap version” mask file… so it’s not a timestamp that it checks but rather compares the values of the .xml versus an older copy?? And since the new .xml file has the same values as an old copy, YAME thinks it’s the same so the mask file is not re-done?? Just my thoughts on what might be happening…
-
It works fine on my main rig, it just does not like my server rig for some reason.
-
Hook. In the end I didn’t check with RTT as I said I would do. I’ll try to do it tonight and report back if the problem persists with RTT extraction
Well, I don’t know why but i could not ge YAME to work with RTT extraction to check the vertical tearing issue. i will keep on trying.
What I can tell you is that I was using GPT with texture extraction and the tearing effect was minimal almost imperceptible if any.
-
Well, I don’t know why but i could not ge YAME to work with RTT extraction to check the vertical tearing issue. i will keep on trying.
What I can tell you is that I was using GPT with texture extraction and the tearing effect was minimal almost imperceptible if any.
For testing rtt extraction try to look in your falcon bms\bin\x64 folder and if present remove the d3d9.dll file
-
Hi,
I use a 2 PC Client/ Server configuration. I have a small problem with the moving map. Are there any rules, to get the latest flight plan overlay in the map?
I only get the current flight plan, if I restart yame server and reconnect the client after every flight?Other than that I get the flight plan from the flight before or no flight plan!
Thx for help…
-
Save the DTC in 2D while YAME is active.
-
Thx, eventually this works in a 1 PC configuration. But the problem persist in 2 PC configuration. If I press the DTC before flight no update in moving map?
-
Thx, eventually this works in a 1 PC configuration. But the problem persist in 2 PC configuration. If I press the DTC before flight no update in moving map?
Should work even in network configuration. You need to press the “SAVE DTC” when you are in 2D in falcon bms. All data are taken from <your callsign=“”>.ini file, so if it’s not correcly saved it won’t display the infos.</your>
-
Ok. I retried that, but no success.
Yes, it should! But the network client didn t get the update for the new flight plan for me.
If I fly a second mission without restart BMS, the flight plan of the mission before appears in the map, although I press “SAVE DTC” in the BMS UI on server PC.It is not enouph to restart network client only. I have to restart server application. It seems, no update happened on client network application.
If nobody have the same problem, I have to live with it…no prob… -
Ok. I retried that, but no success.
Yes, it should! But the network client didn t get the update for the new flight plan for me.
If I fly a second mission without restart BMS, the flight plan of the mission before appears in the map, although I press “SAVE DTC” in the BMS UI on server PC.It is not enouph to restart network client only. I have to restart server application. It seems, no update happened on client network application.
If nobody have the same problem, I have to live with it…no prob…So the problem is when you fly second mission? The first one is ok?
-
Yes…first mission is correct.
I tried different settings on client application. I tried with network path to callsign.ini and without network path to callsign.in. No success… -
Updated first page for the v1.1.0 release!
-
Nice. Thanks
So, now I can run 64 bit server with a 32 bit client, yes?
-
-