Wesjet

After some troubles testing my DCS server, I found a solution. Problem & Solution outlined below. Problem: DCS VOIP would not show myself and another user in the room list. We could only see ourselves, and we can not hear each other. Local Configuration: DCS Server on LAN IP 192.168.1.127 Client on LAN IP 192.168.1.5 Public IP will not be included for privacy, but will be referenced by "A.B.C.D" Router has port 10308 forwarded to DCS Server @ 192.168.1.127, and working for over a year. Connection to Public Internet is by IPv4 only. Router Info: Make: ASUS Model: RT-AC3200 Firmware: 3.0.0.4.382_51640 Tested Setups: No Port Forward on 10309 - leaving this to UPNP Port forward enabled for 10309 Results: Clients still cannot see each other. Observations: My local client sees the DCS server in the listing (and as the last IP in the "Connect by IP" dialog) as its IPv6 link-local [FE80::/10 series] address. Subsequent Test: Attempting to connect to DCS server on same LAN via IPv6 does not allow VOIP traffic. Attempting to connect to DCS server on same LAN via A.B.C.D (IPv4/Public) fails "Address Unavailable". [Not particularly an issue, should be using a LAN IP anyway] Attempting to connect to DCS server on same LAN via IPv4 192.168.1.127 succeeds, with functional VOIP traffic. Results: VOIP traffic does not appear to be able to cross between IPv4 and IPv6 clients, at least for LAN. DCS server could also bind/broadcast LAN IPv4 in addition to public IPv4 and IPv6, so users on the same LAN as thier server can connect from the list using LAN IPv4. (If this is feasible)

I have the VOIP configured on my server, Hollo Pointe North (EST timezone located / Toronto). Port is manually forwarded, since it wasn't working when I left it to uPnP, even though the DCS log said it successfully opened the port.

I have had no luck with my server. Had a router port conflict at first from an old mapping, resolved that and restarted the DCS server. Log showed it successfully made the uPnP setup for Port 10309, yet none of us can see each other on the list or hear each other.

BigNewy, would it be possible to add a packet loss indicator on the scoreboard (like how we have ping)? That would give us players another way to at least diagnose the network connectivity during these type of events. Perhaps a log entry as well.

Just wanted to follow on to this report - the issue is present in the current DCS: OB. You can view the barrel issue with the MSTA's LOD model in the model viewer. File: 2-c19.lods Location: DCSWorld/bazar/world/shapes/ Parameters: -A non-default turret rotation and/or barrel elevation (sliders #0 and #1). -Camera distance of 100.00 or greater. The machine gun showing as firing with the main gun at this detail level appears to be an issue outside of the model itself.

The E would potentially get the go ahead from my wallet. The F definitely would. It would be great to help teach fellow players to fly a Hornet by just being in the same aircraft. I would be equally happy with the legacy D model for the same reason.

Nineline, Tried again with the new hotfix. Not only does CCIP release of the Mk82's seems to work properly again so far, the sidewinder seems to be back to normal too. I'll add to this again if I see this return.

I certainly agree WIP, that's why I was thinking meters - perhaps they haven't done unit conversion for display yet. I checked at other ranges as well and found that the number typically works out to a metric conversion of the displayed NM range within a small margin of error.

From some quick math I did, it seems the range is shown in Meters currently. Take a look at my screenshot, you'll see I am 11NM from the target (I know the Hud wouldn't be as precise) and the readout is 20308. 11NM converts to 20372 metres, so it's within acceptable rounding margin of error.

Wags, Thank you for looking into this. This morning I have spent some time trying to narrow it down. So far these are the conditions: -Multiplayer Only -Must perform and A/G release first, I used MK-82's in CCIP. -Subsequently AIM-9 seeker will begin to track, but not lock a target. Since I had to be in MP, the track file is about 14MB, too large to upload. Please see a copy of it here from my OneDrive: https://1drv.ms/u/s!Au6nuN4_FUp2gqIgxxcWqkTvT-aKDg?e=ukW6sr In the track I attempt to lock both from a head-on and tail-on aspect, caging and uncaging the seeker a few time to make sure it's trying. I was able to watch the problem in the track file myself, locally. Excuse my takeoff, I had de-selected the DCS window by accident! In a previous flight / track file (not uploaded) in the same mission, flying head on with an L-39 in the same fashion without first having done a CCIP weapon release did not recreate this issue, and a valid lock was acquired. And of course, a tail-on aspect was also no issue. Using the same pattern in SP (although with an air start) did not reproduce the issue.

Yes, that is it. The right side appears to be primarily ownship data as far as I can tell. To me it seems to be too specific of data for what we’d be getting from radar.

Will grab a screenshot in the morning, but I noticed that with an A2A missile selected and the radar locked on that what appears to be debug information shows up on the SMS page under the aircraft stores diagram.

I have been having issues getting the AIM-9M (and have seen this with the X but not thoroughly tested yet) to lock onto aircraft even in favorable conditions. I had tried this both with the un-assisted boresight mode, uncaged the seeker and it will start to growl but not lock on most aircraft. Similar results occur when using the radar-assisted mode. Conditions testing have included from 10nm initial down to 1nm in both head-on and tail-on aspects. Aircraft I have had an issue with: -SU27 -MIG29 -L39 -F/A-18C (following a friend online) In some cases it still does work, for example swooping in on some friendly AH-1s I had no problem getting a lock. I will try to make a shorter track if possible, currently my MP tracks are over an hour so unsuitable for bug testing.

Update to this thread: No issues from the DCS server in the time since the repair that replaced MissionScripting.lua I will try to catch a "Bad" copy of it the next time an issue pops up, before running the repair.

Can confirm. Re-arm menu shows they have been loaded but I cannot get the CMS system to acknowledge. Tried full turning off the CMS and then on again, no luck.

I would like to report a potential issue with the Dedicated Server in regards to performance with the server hanging with only a few clients and a moderately busy mission which seems to be partly caused by an issue with the updates and/or updater potentially. My server is pretty low-key hardware wise, but we have been running this mission over the course of the summer without incident. It's only been in the last two patches that I have had an issue. With the last update, I ran a DCS repair which replaced Scripts/MissionScripting.lua and seemed to fix the issue. Come this patch, our first run has encountered the issue again just alot more pronounced. We get pauses/hangs, aircraft jumping around as the server hangs then catches. I ran a DCS repair again, and the same file was replaced this time, according to autoupdate_log.txt. Both cases I ran the repair a second time, to ensure a clean result by seeing the "INFO : Nothing to install." line in the log. Today's autoupdate log file attached. Will be restarting the server post-repair now, will monitor and advise. A Note on the Hardware Setup: Attached is an image showing resource usage while in play, the one spike is the moment I connected via TeamViewer. Resource usage even during this issue is roughly the same, even during the hangs. DCS appears to be running on core 4 (bottom right) primarily, and it's share of the RAM usage is ~2GB-2.5GB. autoupdate_log.txt

I know a couple guys who would be more than happy to fly a DCS tanker, or transport plane. With a tanker, being able to put it on autopilot and fly the boom or spot for the drogue could be fun and would beat listening to “ready pre contact” “return pre contact” until you find the perfect spot...... I’d even fly a transport sometimes. As previously mentioned, an AC130 would be golden but maybe too ambitious to start. You’d want something with as few stations and roles as possible, and get multicrew perfectly set before you get into 2+ crew aircraft. Plus, to be fair to single player guys you’d need something like Jester in each seat for those flying solo. Doing multiple of those in one aircraft simultaneously has yet to be tried. Later on you could hope to do paratrooper drops........:thumbup:

I can reproduce this. The issue comes when you set the country to Canada, but use the "default livery" (which is actually american). Track, Mission and Screenshot attached. TextruesTest.trk TexturesTest.miz

That appears to be a GPU monitoring overlay program running in that large window. Is that something you used before, but is now non-functional? If so, try without it. Is that GPU monitor new? If so, reboot and go into BIOS and see if you can disable it. Failing that, the motherboard may have pushed it to Windows, as some Asus boards can do with drivers. Check your Programs list in Windows for new entries installed on that day that appear to along that line of a monitoring application and test uninstalling them. Edit: this is based on the dialog saying “Powered by GPU Tweak II”.

Just wanted to report that this is still an issue in the current Open Beta. The barrel shows as "broken" at a certain zoom point. If the turret is rotated, the breech end of the barrel's section will not only be shown in the lowered position, but also pointing forward relative the to chassis. See the images labelled "Barrel". Another issue with the Msta is that when firing, units in the distance also show the effect of the machine gun being fired. See the images labelled "MG" - look at the units near the end of the column. I have not seen this issue with other artillery units so far.

Due to the limited amount, my programs are very restricted - but I have no issue repeatedly using the button on the HOTAS Warthog where I mapped CMS to the Hog’s CMS hat. Prog1: Single Flare, no repeat. Prog5: Single Chaff, 2x, 0.5sec. Should we get larger quantities I would definitely make some more “aggressive” profiles.

Noticed a bug with the HSI screen keeping a ghost image from a previous flight in the A-10C. First appeared in MP before today's patch, reproduced today in SP & MP with patch. Steps: Fly an A-10C with Mavericks Display MAV Screen (I used the right MFD) Eject Spawn into an F/A-18C (Cold start is better as it only lasts a frame or so when the map loads) Notice ghost image of MAV screen from A-10. Track, Screenshot and Mission included. Edit 1: Note, this persists between flights and modes (SP -> MP, after producing this it was there when I joined a MP server) until DCS is restarted. Ghost_Image.trk HauntedHSI.miz

Just to add to this, did some testing with friends today. It's not just carrier spawned Hornets. I spawned in at Gudauta, landed on the Stennis, then landed at Sukhumi and the issue was there too. Just to see if we had to "sync" to the last airfield, I took off again did a lap and landed once more at Sukhumi, the issue still existed. (Test A) We are looking to test other A/C and see if it exists there too (Test B). Looks like landing on "objects" is safe, while the ground itself is not. Overall, inconsistent: going "object"(building) -> "ground" (grass or airfield tarmac) one time was OK, the other not. Hopefully some of this information is of use. Test 'A' Results: -Hornet From Gudauta to Stennis -Hornet Lands at Sukhumi (Problem) -Hornet does a lap, lands again (Problem) -Hornet Lands on Ground/Roadway (Problem) -Hornet Lands at Sukhumi (Problem) -Hornet Belly Lands at Sukhumi (Problem) Test 'B' Results: -Harrier from FARP goes to Tarawa -Harrier Conventional Lands at Gudauta (Problem) -Harrier continues mission -Harrier VTOL lands on warehouse at Sukhumi (OK) -Harrier hovers to ramp nearby (OK) -Harrier Conventional lands at Sukhumi (OK) -Harrier goes to Tarawa -Harrier VTOL lands on Ramp (Problem) -Harrier hovers to adjacent Warehouse (OK) -Harrier hovers back to Ramp (Problem) -Harrier continues mission -Harrier VTOL lands on ground (Problem) -Harrier hovers over to adjacent FARP (OK) -Harrier Taxiis to ground, damaged, repairs -Harrier hovers to ground (OK)

Yes, there is a known bug in regards to higher altitude drops. I am not sure where it starts off in terms of height though. You can swap to CCIP a bit early and release or fly lower (during practice). You can tell it’s going to go long if you haven’t hit the release point yet, but notice the TGP is nearly looking straight down (in which case, don’t release and make another pass). See this post: https://forums.eagle.ru/showpost.php?p=3995623&postcount=24

Nineline posted some additional info along with the tutorial video on the Mudspike forums: “There are known issues regarding the damage level the Harpoon can inflict and guidance of multiple Harpoons without re-setting launch parameters.” So the targeting issues when using more than one are to be expected for now, I gather.