george interface with 3 monitors

[yeldraw1]

With 3 monitors the interface is pretty much hidden to low to read or use them....

[Oceandar]

Same here. Anyone have workaround for it or we should wait ED to fix it (if they ever consider to even to fix it)

[wholehawg]

I am working on this right this very minute.  What I am trying is placing the export monitors above my main monitor as opposed to the right and left.  I am not sure if it will work but I will let you know.

 

EDIT  This worked. I had to change my monitor configuration.

Edited March 19, 2022 by wholehawg
Adding to previous comment

[TAIPAN_]

Solved by a guy on Reddit

 

[mkiii]

Messing with lua files like this (as we currently have to do to position the control indicator for example) is not a "solution". It is a hack that could be broken by next week. Don't worry guys. It only took a few years to make the Kneepad movable, and in a few more, we may even get an option to select a start position in the main menu, for in-game UI, so you never know. That may also apply to the Control indicator & the AI menus. 

Edited March 20, 2022 by mkiii

[Asto]

IMPORTANT: PLEASE SEE A BETTER SOLUTION IN MY FOLLOWING POST (BELOW, March 26th)

----------

Why is the bug report locked? Workarounds would fit there far better than in new threads?
I've looked at the code and guess I've somewhat fixed their calculation. So you shouldn't need to fiddle with those numbers as stated in the reddit post above.

The file you need to edit is the following one: *InstallPath*\DCSWorld\Mods\aircraft\AH-64D\Cockpit\Scripts\AI\PrestonAI_page_common.lua
The changes are multiplayer compatible.

You need to comment out the old calculation and add the new one below, as seen as in the screenshot. Their calculation just calculates an offset to the center, so that's why the tool is placed there. The other part of the calculation is missing in their version. And the "afaik" comment tells me they didn't exactly know what they are doing there - but as a Software Dev I can relate to that. Giggled anyways

After commenting out the old two lines via `--` add the code selected in the screenshot below the old two lines: 

local control_pos_offset = {(ULX + SZX / 2 - total_w / 2) / total_w * total_aspect * 2, -(ULY + SZY / 2 - total_h / 2) / total_h * 2}
weap_control_pos = {0.8 * aspect + control_pos_offset[1], -0.75 + control_pos_offset[2]}
compass_pos = {-0.82 * aspect + control_pos_offset[1], -0.7 + control_pos_offset[2] * 2}

Afterwards it should exactly look like in the screenshot.
Start DCS and enjoy the fixed positions.

Disclaimer: I couldn't test all varieties. You may need to tweak this a little bit. But it would be nice if you share your corrections with us

Edited April 7, 2022 by Asto
Update Link

[AngryEchoSix]

On 3/20/2022 at 5:11 AM, DanDegen said:

Solved by a guy on Reddit

My internet life is complete - I've officially been referred to as "A guy on Reddit".

Thank you kind sir. lol

[BIGNEWY]

Thanks for the work around, I have reported it to the team. 

[TAIPAN_]

13 hours ago, AngryEchoSix said:

My internet life is complete - I've officially been referred to as "A guy on Reddit".

Thank you kind sir. lol

It's mostly anonymous there for most people is my excuse

14 hours ago, Asto said:

Why is the bug report locked? Workarounds would fit there far better than in new threads?
I've looked at the code and guess I've somewhat fixed their calculation. So you shouldn't need to fiddle with those numbers as stated in the reddit post above.

The file you need to edit is the following one: *InstallPath*\DCSWorld\Mods\aircraft\AH-64D\Cockpit\Scripts\AI\PrestonAI_page_common.lua
The changes are multiplayer compatible.

You need to comment out the old calculation and add the new one below, as seen as in the screenshot. Their calculation just calculates an offset to the center, so that's why the tool is placed there. The other part of the calculation is missing in their version. And the "afaik" comment tells me they didn't exactly know what they are doing there - but as a Software Dev I can relate to that. Giggled anyways

After commenting out the old two lines via `--` add the code selected in the screenshot below the old two lines: 

local control_pos_offset = {(ULX + SZX / 2 - total_w / 2) / total_w * total_aspect * 2, -(ULY + SZY / 2 - total_h / 2) / total_h * 2}
weap_control_pos = {0.8 * aspect + control_pos_offset[1], -0.75 + control_pos_offset[2]}
compass_pos = {-0.82 * aspect + control_pos_offset[1], -0.7 + control_pos_offset[2] * 2}

Afterwards it should exactly look like in the screenshot.
Start DCS and enjoy the fixed positions.

Disclaimer: I couldn't test all varieties. You may need to tweak this a little bit. But it would be nice if you share your corrections with us

When I saw "AFAIK" I blinked and thought "have I been here before?" lol

Its beta so understandable

[Sydy]

Thank you for the work around, specially the "guy on Reddit"... And @Asto!

[Sydy]

Gents,

I took the liberty to make a JSGME fix with your instructions and made it available on User files download.

I mention the credit for both @Asto and @DanDegen.

Available here, on User Files Download page.

All the best,

Sydy

[MatveyTsivinyuk]

@Asto wow, big thanks for correcting my code. This part was copypasted from Mi-24 and it seems that nobody tested it with exported MPDs. Expect your code to be in the next update. As a main developer of George I grant you kudos.

[Sydy]

1 minute ago, MatveyTsivinyuk said:

@Asto wow, big thanks for correcting my code. This part was copypasted from Mi-24 and it seems that nobody tested it with exported MPDs. Expect your code to be in the next update. As a main developer of George I grant you kudos.

Thank you also, Sir!

[Asto]

vor 55 Minuten schrieb MatveyTsivinyuk:

@Asto wow, big thanks for correcting my code. This part was copypasted from Mi-24 and it seems that nobody tested it with exported MPDs. Expect your code to be in the next update. As a main developer of George I grant you kudos.

Wow thanks for the open communication!  

If the team has the possibility to test a few more setups with that code that would be great. I'm quite limited here

Edited March 22, 2022 by Asto

[MatveyTsivinyuk]

41 minutes ago, Asto said:

Wow thanks for the open communication!  

If the team has the possibility to test a few more setups with that code that would be great. I'm quite limited here

 

Sure, I'll ask the QA team.

[MatveyTsivinyuk]

@Asto your code has been tested and proven working very well. Expect in the next update.

[Asto]

[Deezle]

Asto's code DOES NOT work with my monitor setup. The menu disappears completely. By default, the menu appears right in the middle of my main screen which is very annoying. Frankly, after many years of this happening with all sorts of modules, I'm very annoyed. Many of us use multi-monitors, someone at ED needs to be testing with multi-monitor setups.

 

Edited March 25, 2022 by Deezle

[Asto]

vor 21 Stunden schrieb Deezle:

Asto's code DOES NOT work with my monitor setup. The menu disappears completely. By default, the menu appears right in the middle of my main screen which is very annoying. Frankly, after many years of this happening with all sorts of modules, I'm very annoyed. Many of us use multi-monitors, someone at ED needs to be testing with multi-monitor setups.

That's what I was afraid of, that's why I've asked for the QA test. It would be nice if there would be a standard test for vertical and horizontal layouts before each release, nothing fancy. Just two monitors. That would also show that the Apache export doesn't work correct, with always exposing the CPG MPDs to the LEFT_/RIGHT_MPD, even as a pilot, where we need some hacks right now.

Thanks for testing this before the release of the update

Offtopic: Assuming 3440x1440 and 1920x1080 monitors in your setup, you should thinking about placing them horizontal to save your graphics card (in theory) a big amount of work:
Horizontal setup: (3440 + 1920) * 1440 = 7,7184,00 Pixels to render
Your Vertical setup: 3440 * (1440 + 1080) = 8,668,800 Pixels to render

Edited March 25, 2022 by Asto
typo

[Deezle]

1 hour ago, Asto said:

Offtopic: Assuming 3440x1440 and 1920x1080 monitors in your setup, you should thinking about placing them horizontal to save your graphics card (in theory) a big amount of work:
Horizontal setup: (3440 + 1920) * 1440 = 7,7184,00 Pixels to render
Your Vertical setup: 3440 * (1440 + 1080) = 8,668,800 Pixels to render

 

I've considered it, but I use the lower monitor for other things besides DCS and rewiring my brain to move the mouse to the left or right to get to the physically lower monitor just isn't going to happen.

[Asto]

I've spent a few more hours into this problem... It's really hard to understand what's going on there. The following code should fix it for both of our setups.

The file you need to edit is the following one: *InstallPath*\DCSWorld\Mods\aircraft\AH-64D\Cockpit\Scripts\AI\PrestonAI_page_common.lua
The changes are multiplayer compatible. You have to replace the entire part between "--viewports stuff" and "--end viewports stuff":

	--viewports stuff	
	local v = find_viewport("GU_MAIN_VIEWPORT", "CENTER")
	if v ~= nil then
		if v.width ~= total_w or v.height ~= total_h then
			ULX = v.x
			ULY = v.y
			SZX = v.width
			SZY = v.height
			local aspect = SZX/SZY

			local offsetX = (ULX + SZX / 2 - total_w / 2) / total_w * total_aspect * 2
			local offsetY = -(ULY + SZY / 2 - total_h / 2) / total_h * 2
			local padding = math.min(total_aspect, aspect) * 0.2
			compass_pos = { -math.min(total_aspect, aspect) + offsetX + padding, -1 + offsetY * 2 + padding}
			weap_control_pos = { math.min(total_aspect, aspect) + offsetX - padding, -1 + offsetY * 2 + padding }

			compass_size = compass_size * v.height / total_h
			weap_control_size = weap_control_size * v.height / total_h
		end
	end
	--end viewports stuff

But I didn't test it with monitor setups where the center viewport is in the middle or other special setups. I bet this is even far from perfect, but could work for the most setups for now. 

@MatveyTsivinyuk you (ED) have some serious issues there regarding the positioning of UI elements, as it seems. The behaviour is totally counterintuitive. You should always place those UI elements based on the center of the main / center-view and not based on the total center of the selected resolution when you support multi-monitor setups. This makes it way too complicated and explains why it is broken so often and why the kneeboard spawns on the MPDs etc... That makes no sense, at least to me.

The other weird thing is the grid you guys & girls have created there:

• The center is [0, 0]
• The y-axis always reaches from [0, 1] (top) to [0, -1] (bottom)
• And now the x-axis behaves really weird: Its from [-total_aspect_ratio, 0] to [total_aspect_ratio, 0]
  This creates multiple problems when positioning UI elements:
  • When I'm using a total resolution of 4240x1440 (MPDs horizontal), the total_aspect_ratio is about 2.94
  • When using a total resolution of 3440x2040 (MPDs vertical), the total aspect_ratio is about 1.69
  • The consequence: Every used relative value behaves totally different for each total resolution. You've used 0.8 and 0.82 as an example, but that is always another position on the screen. And when applying proper offsets. That's why I had to add math.min(), because normally the aspect ratio of the center view would in both cases be the same. But using the total_aspect_ratios makes this weird.

Another hint from one software dev to another: I would recommend structuring the code in smaller pieces / objects and functions as far as LUA can handle it. This makes it easier to maintain and understand. And you could use automatic tools to clean your files from trailing whitespaces, since they are "useless". Even most IDEs should support that, maybe even with an .editorconfig file for the entire team 

If this works, you owe me a beer  

@Deezle If this still doesn't work for you, could you send me screenshots where those elements are placed, if visible?

Edited March 30, 2022 by Asto
Typos

[Deezle]

Thank you @Asto, that code works for me now!

[Asto]

vor 3 Stunden schrieb Deezle:

Thank you @Asto, that code works for me now!

Thank you for giving it another chance. Glad to hear that :)

[skypickle]

This solution does not work with the following monitor config:

 

 

monitor config

 

--4096 x 3240       4096 screen with a 1920 screen below it
_  = function(p) return p; end;
name = _('Camera + 2 MFCDsLG');
Description = '2 MFCDs on the bottom and camera on the top'
Viewports =
{
     Center =
     {
          x = 0;
          y = 0;
          width  = 4096;
          height = 2160;
          viewDx = 0;
          viewDy = 0;
          aspect = 4096 / 2160;
     }
}

LEFT_MFCD =
{
     x = 20;
     y = 2160 + 240;
     width = 810;
     height = 810;
}
RIGHT_MFCD =
{
     x = 1080;
     y = 2160 + 240;
     width = 810;
     height = 810;
}

GUI = 
{
      x = 0;
      y = 0;
      width = 4096;
      height = 2160;
}

UIMainView = GUI
GU_MAIN_VIEWPORT = Viewports.Center

The 'george' window is offscreen somewhere.

 

Please note that monitor one which is off to the left is for browsing pdf files , websites and other flight instructions, etc while in DCS which plays on monitor 2

The MFDs properly render A10 MFDs.

[Asto]

vor 15 Stunden schrieb skypickle:

This solution does not work with the following monitor config:

 

 

monitor config

 

The 'george' window is offscreen somewhere.

 

Please note that monitor one which is off to the left is for browsing pdf files , websites and other flight instructions, etc while in DCS which plays on monitor 2

The MFDs properly render A10 MFDs.

That's weird, since it should be similar to Deezles layout, ignoring monitor 1.

What did you set in your DCS preferences as resolution and aspect ratio?

Can you send me screenshots from DCS? Are those ui elements (pilot and cpg) anywhere visible on those screenshots, maybe in a black area?

 

Are they visible anywhere, if you use the following positioning? Change the two lines in my last posted code snippet. I'm wondering which offset is incorrect.

			compass_pos = { -math.min(total_aspect, aspect) + offsetX + padding, 0}
			weap_control_pos = { math.min(total_aspect, aspect) + offsetX - padding, 0 }

Edited March 28, 2022 by Asto