StandingCow

Newy, wrong file. This is dots.fx. Can ED at least improve the dots before removing our ability to alter them? Maybe implement the mod as a permanent change so that playing at a higher resolution isn't a negative?

It's pretty hilarious that this doesn't break IC... but I am also glad it doesn't so that the community can fix what ED has been seemingly ignoring.

Ok, this is fixed, Thanks to a suggestion from Special K in the discord I moved the MFDs to the right of the screen instead of under it. Works with the default ED file now. The George AI must have been hiding under my displays due to the resolution going downward.

Hey all, I recently moved to a cockpit that is separate from my other monitors (in different rooms). I haven't been able to figure out how to get my George interfaces to show up though. Here is the display setup: monitor.lua file: _ = function(p) return p; end; name = _('Cockpit'); Description = 'Sub Displays' Viewports = { Center = { x = 5360; y = 0; width = 2560; height = 1440; viewDx = 0; viewDy = 0; aspect = 2560/1440; } } LEFT_MFCD = { x = 5360; y = 1440; width = 525; height = 525; } RIGHT_MFCD = { x = 7395; y = 1440; width = 525; height = 525; } F14_JESTER_MENU = { x = 5360; y = 0; width = 2560; height = 1440; } GU_MAIN_VIEWPORT = Viewports.Center UIMainView = Viewports.Center George AI file: --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 Any help would be appreciated!

Agreed. Thanks for your help. Hopefully one day I can switch to Helios as it does seem to be the better way to do what I am doing. I guess I'll have to deal with the black screens.... but the George AI display not working is a real issue.

ED please.... before you implement something that breaks current user created tools... ED needs to supply us with something equal or better.

Does helios break pure script servers though? I fly primarily MP so don't wanna do that if it's avoidable. Hopefully ED eventually allows access as requested here:

Greetings folks, I was hoping someone would be able to help with some questions I have. My set up is my main monitor (set as primary in windows) and a left monitor are in my office, these are no longer used for DCS. My TV and MFDs are part of my cockpit setup in another room. Currently everything is working but the way I have it set up... my 2 office monitors have a black screen (since I am stretching DCS's display out). Is there a way to set this up without having to do that? Or without having to set my TV in the other room as a primary display? I've attached a graphic showing my displays as well. Here is my currently monitor.lua file: _ = function(p) return p; end; name = _('Cockpit'); Description = 'Sub Displays' Viewports = { Center = { x = 5360; y = 0; width = 2560; height = 1440; viewDx = 0; viewDy = 0; aspect = 2560/1440; } } LEFT_MFCD = { x = 5360; y = 1440; width = 525; height = 525; } RIGHT_MFCD = { x = 7395; y = 1440; width = 525; height = 525; } F14_JESTER_MENU = { x = 5360; y = 0; width = 2560; height = 1440; } GU_MAIN_VIEWPORT = Viewports.Center UIMainView = Viewports.Center I am also having issues with my current config getting George AI to show up in the Apache. I've been following that thread --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

Take your time and do it right fellas. We know HB puts out quality products.

Nice, hopefully ED can investigate and find the cause. Anything to help MP performance is a win for everyone.

What's the effective range of the A and B missiles now? I know it depends a lot on altitude, speed, etc but vs an aim120c how much extra range do you think we will get out of each missile now?

Are the vehicles that are the wrong color for the mode freshly spawned in by chance? A buddy and I noticed that freshly spawned vehicles, even if moving, take a while to warm up.

Seems like something is indeed incorrect:

Yea, it feels like sometimes threads are marked "correct as is" without much thought, not saying that's what is actually done but it feels like it. That thread you linked could possibly be related to this "issue" if it is actually even an issue, hard to know. And before this thread was marked correct as is... was the team asked about it? Was the f16 tested with the fuel door open after the FM changes? So many questions...

Ok, this seems resolved in the latest patch. Thanks ED!

Has anyone tried A/A refueling since the FM changes? A buddy and I did (or in my case attempt to) A/A refueling and it felt like there was a dead zone which made minor pitch corrections really difficult to accomplish, you'd suddenly be pitching up or down way further than expected?

I'll try next time I fly and report back. I think reproducing could be as simple as scrolling through contacts quickly, I'll see if it still happens with the new patch.

FYI the mashing isn't what triggers it, that was just frustration, the mashing only happens after the bug triggers.

Weird that he is switching missile type for no reason. Another workaround might be having George laser your target then take control of the missiles yourself. I attempted that but forgot to flip the trigger safety, so I'll try doing that next time I fly.

Also added a twitch clip of the bug in case that helps: https://www.twitch.tv/videos/1316452913 I probably could have fired as a pilot in retrospect but forgot to flip my trigger safety, still a bug though since George stopped being able to fire.

What happened that resulted in the issue? George will stop lasing targets and you lose hellfire symbology (no box). What were you doing that caused, or seemed to cause the issue? Possibly scrolling quickly through targets on the George target select screen. But I am unsure. I made it happen, as you can see in the track file on the instant action target range mission. Could you reproduce it? Yes, this happened to me on multiplayer servers multiple times, and I recreated it in an ED provided mission, possibly by scrolling through targets quickly in the George target select screen. What module where are you using, and does it happen with others? Only happens in the apache as it's the only thing with a George AI. I have no mods installed, this is an ED provided instant action mission. apachebug.trk

@NineLine@BIGNEWY Can you poke the team? They still haven't fixed this even though they inserted some of the thanks to Asto. We still have to alter the file after every update.

Yea, even worse on planes like the Tomcat.

Someone emailed Jello from the FPP on this as well: “Military power. If you happen to go into afterburner, so be it, but afterburner is not required.”

Yep, agreed. Some folks found a few videos where ABs appear to light up on carrier traps, but many think that's just the force of the trap putting them into AB by mistake.