EntropySG

+1 pleeeease!

Hi, one easy thing to do is swtich from POINT or AREA mode into INS mode (TMS down short). This way your TGP won't lock on a hill in front of the target, but look 'through' the hill and stay at the actual position. The best (and imo correct) procedure however is TMS right short to make a Markoint for your target or location. Then you can always slew sensors back to it with Chinahat aft long, whenever your TGP 'jumps'

I have SLAW's Dora pedals since 2-3 years now. They are awesome and the interaction with Slaw was very friendly and professional

Thank you!!

As I said in me previous posts, its from our end less about individual performance, but rather about a problem we're having in multiplayer. FPS was fine, we had net code issues like desync and warping. Anyway, as requested, here is my dxdiag. BIGNEWY, I hope you were not offended by my post Sir, we greatly appreciate your help, really and all the time you spend in an effort to help. DxDiag.txt

hi! you will love your rift, it changes everything imo :) In fact, you only need one sensor, the second sensor is needed for handtracking (which doesnt work in DCS yet). However, having the second sensor will improve tracking, when you look down and to the side for example. I would run the setup and you will see that its ok to place them apart, it does not need to be 2 meters, I have mine about 120 cm or so apart and about 60 cms from my head, it works perfectly

sorry for the rant, but its a touchy subject however to joke about. Its not about joking, its about the perception that such things are not just a little bug, but a MAYOR HEADACHE for some of us who play multiplayer. I could link now our event page for yesterdays mission, with the mission brief, pictures of intel, threats and photographs and coordinates of targets for the strike and whatnot This took some time to set up, time to plan the event, do the work in the mission editor, make maps and pictures etc etc. This material was then handed out and the flightleads together with the package leader started to plan their combined time on target attack, with careful planning of the ingress routes, IPs, gameplans for the attacks and egress routes. Add to that the coordination to come up with an orchestrated attack plan, codewords for various checkpoints in the execution of the strike etc etc. What Im saying is, considerable effort goes into such events from both the mission makers but also the pilots, especially the flight leads and JTACs. Then everyone reserves their precious Sunday evening and sees that their kids are in bed and their wifes are not too angry, and then you start the mission, pilots punch in a dozen coordinates and waypoints etc etc and... well, THEN you realize as you taxi out of your hangar that everyone is going sideways and the entire evening turns into a waste of time and effort. Worse than that, people step out of their virtual planes with a sour taste in their mouth. Do this often enough and multiplayer groups will lose members eventually if it keeps on going for too long or happening too often. Let it happen often enough and people will go play something else instead. I do not intend to criticise without reason, I do intend to get across our point of view as multiplayer group and that we think gameplay updates like 1.5.7, despite the latest hotfix, have a serious and very negative impact on the multiplayer side of DCS and it would be my hope that very high priority could go into finding a solution for the problem

Hello BIGNEWY, many thanks for replying and posting here, it is appreciated greatly! Be advised, I also never had any stutter and our entire squad had no problem running our training mission file on 1.5.7. However, the combat mission (which contains in contrast to the training mission active red units) was completely unplayable for any of us, regardless of specs. We never had the problem under 1.5.6 edit: if it helps, when I was alone on the server, everything ran fine. With more people joining (we only had 15 or so max in total) it went downhill and the warping began

well, while it was working in the training mission, yesterday we ran a combat event in a simulated warzone. The very same miz file that never gave us any problems in 1.5.6 yesterday made for some unwanted comedy. We had people warping all over the place, helicopters flying backwards and ground units warping in and out the terrain. It was a gigantic cluster and a major waste of time for all involved. We will, once again have to roll back to 1.5.6 even if it means that we are at this time apparently the only MP server on the old version.

Thanks will definitely use this!!!!

Based on what I saw above, in an attempt to reproduce the issue, I opened a new miz file. and added tons of air defenses. In fact, every type of air defense there is on the red side. In addition, I added a couple of dozens blue A10s to get shot at. I expected this to result in heavy stutter but it runs buttery smooth. I start to wonder if it is 'something' that is in older miz files, but when you start a fresh file, the problem is gone?

Hello all, I think I found something. So, we have this huge combat mission in the 132nd that we made. Its full of scripts (mainly moose) but also CTLD, MIST, AutoGFT. We have hundreds of units in the mission, full sets of tankers, multiple awacs, patrolling CAP, all doing their thing, ground units patrolling areas and constantly (!) moving around, you name it. When I host the mission on our server and join as client then join as game master, then outside view zoomed out I get 180-200 fps. When I open the SAME mission file and go into the mission directly from the mission editor, I get what people are describing. Gentlemen, I go down from 180fps to a whopping TWENTY fps with stutters that are so bad that I cant even zoom or pan, as the rotations of my mousewheel wouldnt even register between the stutters. That info surely must help to solve the problem? EDIT: 1st test: I deleted ALL triggers, so the mission will now not run a single script, nor will it spawn any units that are spawned dynamically via MOOSE. No ground units will move or patrol. Result -> same stutters 2nd test: In addition to 1, I now deleted ALL helicopters from the mission. Result -> stutters 3rd test: in addition to 1 and 2, now ALL planes are gone. -> stutters 4th test: in addition to the above, ships gone -> stutters 5th test: in addition to the above, remove statics -> stutters 6th test: its the ground units. revert mission, put everything back in, scripts etc, everything. Remove ground units -> stutters completely gone 7th test: put in 200 APC AAV-7 into the mission file -> no stutters at all 8th test: put in another 100 AAV-7 those now all have waypoints so they will move around -> no stutters at all 9th test: remove all BLUE ground units -> no stutters at all 10th test. It might be the SAM untis. When I take them out, stutters get reduced by a lot (but still there). However, its a combination. When I create a blank mission with just sams, I get no stutter. Preliminary Conclusion from a 30 min test: The problem, at least in this test scenario is clearly tied to the host, and not a MP client. Furthermore, it appears that it is tied to ground units, but not any ground units rather it might be a problem with specific ground units, now it remains to see who is causing the problem. EDIT: Im on version 1.5.7.8899

MI-8 in VR -> awesome!

thanks!

ok we finally took the step and upgraded to the latest version (1.5.7.8899.335) in the 132nd. During today's training we had 6 A10s, 2 Mi-8s, 2 Mirage and 3 Ka-50s, as well as 3 players as ATC/AWACS connected via LotAtc and nobody had any lag or spikes. We were very happy with the performance of 1.5.7 maybe it helps to know that some users and not all have the issue, in order to track down what is causing it for those who have it.

that is very bad news for us. We will also be testing internally, but if we find the same as what Drexx reports (I dont see why we would not), it means our members still won't be able to update DCS in order to fly on our server, yet at the same time, are not able to fly on other servers which updated.

todays patchnotes for 1.5.7 are live https://forums.eagle.ru/showpost.php?p=3227902&postcount=53 I wonder if this line indicates the fix for the problem with fps and stutters we described in this thread. - FPS drop when multi unit SAMS are used fixed

I so hope ED will bring us good news for 1.5, we are still on 1.5.6 due to the heavy problems with large multiplayer missions and heavy use of ground units

wow, just wow! we just ran this for a casual event, one GFC/JTAC and 2-ship A10-C. Was super fun and the mission seems very very very well designed! We will definitely run this as a large scale event withing the 132nd on a casual mission night and report back. So far all triggers and scripts in the mission seemed to fire correctly. Very good work Sir, thank you so much!

nice!!!!

update wednesday!! Yay :D

I ordered with them twice and had nothing but excellent experience. As other have said it is worth the wait!

You rock!

I dont know if that helps with troubleshooting, but I ran a very fast quick test. 1. Ran MOOSE example mission scheduled spawning -> which keeps on spawning more and vehicles over time. Initially zero stutter, when it reached a count of 50 or so vehicles -> Stutter. 2. Blank mission, no MOOSE, zero scripting. Simply placed 50 vehicles in the mission editor manually (copy paste) -> same stutter (if not more) so it does not have to do with scripting at all, just the new version of DCS not being able to handle many objects?

a quick test seems to completely confirm Flightcontrol's finding. Stock mission "surrounded" -> running perfectly 132nd combat mission (with heavy scripting thanks to MOOSE framework) completely unplayable heavy stutters. 132nd won't be able to update to this version of DCS 1.57 unless there can be a fix found as we rely on MOOSE scripts for our training environment. Thanks a ton BIGNEWY for looking into it, hopefully it can be fixed :) edit: this has nothing to do with settings, Im testing on my work laptop with every eyecandy completely turned off