Saruman

If you are going to use AIM9 and lock a target in RWS/TWS mode, you will not always have a "Shoot" indication (it seems randomly happen to me) If you lock the target by using an ACM mode or the HMD, you will have always the "Shoot" indication instead. Track attached. In the track I locked the target by using RWS and had no "Shoot". I undesignated it and locked again by using HMD and the "Shoot" appeared all of a sudden. AIM9X.trk

It works for me too (thanks), but it's a temporary workaround. I guess the Maverick should not do the quick continous lock/unlock thing when the SOI is on its own DDI.

As per request, attaching trackfile. server-20200930-233140.trk

It happened to me that AGM65-F, since last OB update, is (again) suffering the same issue reported here. When you lock target by using TGP or, most of all, TGP offset, Maverick, in its own DDI, moves back and forth the target and loops into lock/unlock state really quickly, without stabilising. To fire the Mav, you have to quickly continuously press the fire button, hoping to press it while Mav is looping through the lock state. Or, while the Maverick is going back and forth from the target (locking/unlocking), you have to quickly cage/uncage the Mav and, only then, it goes far from the target and then moves back to it in a stable way. When you lock target by using Maverick sensor on its own without TGP aid, instead, all runs well. EDIT: realistic TDC slew here. But the TDC slew method is not part of the issue.

If you select a channel different than 1 on radio 2 and you enable GRCV, GRCV is enabled but you see no visual colon aside "GRCV" label. You only see the colon appear all of a sudden if you switch to channel 1 on radio 2 and then continue browsing the channels.

Oh, never noticed that. Thanks for the feedback to all of you Inviato dal mio BLA-L29 utilizzando Tapatalk

As per thread title, since latest update using the autopilot emergency disconnect paddle also disables Pitch SAS. I never noticed that before and I guess whether it is now intended. Besides, when I configure autopilot switches I cannot see any more the light on the right brow of the front monitor telling me that I must enable autopilot by depressing the autopilot reference button.

Premise: Supercarrier, F/18, simple single player mission (ANY mission of mine) with me and wingman (ace combat level). We are in the same group, of course, and therefore same freq. Now, open whatever mission in the mission editor, select to start your flight (the one with you and the wingman) from ramp start and run the mission from inside the ME (by the green button in the toolbox on the right): after startup, when you move, wingman tells you "2 - Rolling" and it continues talking and receiving your orders for the rest of the mission. So far, so good. BUT run the same mission by loading it from "Mission" in DCS' main menu and you will notice that wingman will never talk nor he will receive any order, after startup! This does not happen if you edit the mission and choose to start from runway or parking hot, but only if you choose to start from ramp. If you start from runway or parking hot, in fact, wingman always talks to you and reacts, regardless of the fact you run the mission from inside the ME or run it from "Mission" main menu. P.S.: by the way, to add to this issue, wingman maybe cheats ramp start, because he always starts with canopy closed. EDIT: solved it. I noticed that start time for the flight (waypoint 0) had a red contour (I don't know why). I edited the start time for the flight, put the same start time (the red contour disappeared for no reason...), saved the mission and wingman runs well.

Here's a pretty long list of things unimplemented/not working as intended for a study level sim outside of EA: https://forums.eagle.ru/showthread.php?t=285495 Inviato dal mio BLA-L29 utilizzando Tapatalk

+1. I had the same CTD right now, same .dll, same messages after the access violation. I already sent a crash report to ED when it happened

Same thing happened to me while refueling by Texaco. Another F18 (AI) crashed into me like he didn't see me

You are talking about physical CPUs. You are not considering virtualization environments (like ED probably didn't consider them, thinking only in physical terms while patching). Though a CPU inside the physical server does usually have SSE 4.x instruction set (they are almost always modern CPUs, after all), very few providers enable it and make the instruction set transparent to the virtualized environments they provide on a single server machine, so DCS, inside a virtualized VPS, cannot usually see the instruction set although physical CPU does support it. Provider's fault? Of course, they are a bit lazy and they are the ones to blame for this, but, since the issue concerns the great vast majority of virtualized environments, this change could have been thought a bit deeper by ED before applying it in the patch. For example, ED could have provided a real dedicated server .exe, that is, a command-line only dedicated server specifically aimed to virtualized VPS.

Alas, this issue persists even in new version.

Thanks for your feedback. Nonetheless, as I stated, the issue persists with ALL missions, even simple one without any script. That said, by trial I discovered it's VAICOM's fault. You can read about it in this thread, where you can find a solution too, thanks to a regular user.

Thank you very much! Your feedback and your help are really appreciated. I'll try your modded file by preserving its read-only attribute. Hope VAICOM's developers can give a glance to this too.

By trial, I discovered that VAICOM, at least on my system and/or my configuration, disables autoscroll of messages and therefore makes comms menu overlapped by said messages (see attached image). More precisely, I observed by clean installation of DCS and VAICOM and by using Winmerge, that VAICOM modifies at least five files in the scripts folder of root DCS installation (I currently use OB): - common.lua - speech.lua - RadioCommandDialogsPanel.lua - TabSheetBar.lua - gameMessages.lua VAICOM's modifications on these files, at least in my case, impede scrolling of messages, as described above, and makes the usage of comms menu pretty difficult, while messages are displayed onscreen. After restoring the original files, messages start scrolling again, going UNDER the comms menu when you open it and so making it accessible (of course, unless you start again VAICOM, which will modify the files again). Any idea about how I can prevent this misbehaviour?

Since last OB update, it happens to me that comms menu is hidden and overlapped by popup messages (see attached image). I use no mod and the issue persists even with simple missions without any script. Clean and repair didn't work either.

If you have no JTAC and you only know about a large generic area where targets should be and/or are constantly moving through, you can trace them more easily by radar than by TGP.

Any guide for mission designers interested to the framework? Thanks.

Yes, I was hosting the mission (and I opened the port 8090, that I use to connect to WebGUI instead of default 8088). The mission uses Moose framework (latest version), and the mission seems to run well (afaik mul_chat.lua belongs to DCS and is called by the framework, I don't know why it errors though nor which feature it provides to framework). Lastly, yes, I use vanilla OpenBeta without any mods or modifications and I cleaned/repaired the installation (no file was found to be unexpected and/or modified while cleaning). Thanks Inviato dal mio BLA-L29 utilizzando Tapatalk

Thanks for the feedback. Here's the log file. dcs.zip

It happened to me twice today that, after opening F10 map to check some TACAN channel, I couldn't come back to my aircraft by using F1 nor F2-Fx keys were functioning too. The game got simply stuck in the map and freezed and I had to close it by task manager. If it can aid you, I was the one hosting and the mission I was flying prevents F10 map from showing anything else than airbases, therefore it does not show any unit of any side and does not show player's aircraft either. Besides, every time I experienced this crash, the mission had been running for at least a couple of hours before the issue arised (I didn't try to use F10 map earlier though). The log file does not report anything and I would exclude swap problems, since the hard disk wasn't working and I have 32 GB of RAM (DCS uses around 16-20 GB on my system)

It seems to me like the well known flickering bug indeed. It's happening to me a lot since about a couple of OB releases only but I discovered that many people were experiencing it since much, much earlier. https://forums.eagle.ru/showthread.php?t=227646&page=44

Today I've been flying for hours without any flickering, so in my case it was due to SSA (maybe too few VRAM on my side?). I can't say about other cases, but disabling SSA might be worth a try for some people Inviato dal mio BLA-L29 utilizzando Tapatalk

I never experienced it before. Therefore, I think it might be correlated to SSA, because I activated SSA only recently and all of a sudden began to have this issue. I made a try, disabling SSA again, and could fly with no flickering at all.