wolle

stable MP version, July 18 After quite a number of days of testing and bug hunting, we have been able to come up with a version (attached) that was stable for us for a couple of hours of continuous play testing (no problems have occurred during that time). The main stability problem is related to "client time-out" errors, which kick players at apparently random times. Although we have not been able to pin-point the ultimate root cause of this problem, we have found a work-around similar to that originally suggested to us in this forum. As you enter the multiplayer screen in DCS world, there is an option button that allows you to "throttle down" the multiplayer data communication. We found that if you set this throttle to a high setting, such as "ADSL1024", the mission becomes quite stable, at least for clients with reasonable pings. With "ADSL1024" we could accommodate clients with pings up to 300ms. Therefore, if you have a good internet connection, this mission should work for you. We are looking for testers with relatively slow network connections, to test if setting the network throttle to ADSL1024 works even for them. Also disallowing "allow_object_export" (thereby disabling programs like TACVIEW and TARS) helped significantly, although we are not yet certain about the relative importance of the two fixes, and whether one can do without disallowing "allow_object_export". Sven will have this mission up on his server. We have not yet sufficiently tested the mission's long time behavior, i.e. after the mission has been running for hours. Of course, as more and more players have gotten kicked unexpectedly (which hopefully will not occur any more), this will probably have some negative effects on game play. We would like to thank the many people that have provided feedback, and we are definitely much closer to an ultimately stable mission. Please feel free to host and/or test play the attached version and provide us with feedback in this forum. AirCavFullMPJuly18.miz

@ Sven Who says that I am not at the beach when I am checking the DCS forum. In fact, right now, I am at the beach, typing with my right hand and holding my Sangria in the left :thumbup: I will read your links about unreachable variables, etc. Can you check if the large memory use that you report also occurs for other MP maps? How about if you play AirCav in SP (where it never hangs up), does it also use do much memory. Any idea what could use that much memory? Does the memory usage jump each time a new player joins, or an old player de-joins, and joins again? I am not at my computer that has DCS installed, but does xcom refer to the following setting: After you enter the multiplayer screen, in "tools" you can choose the connection setting to speeds such as 128,256,512, etc, and there is also a choice "LAN". What be great to test if setting it to "LAN" would help. Since I am not at my computer I can't check whether I have allow_object_export set to true or not. But I am pretty sure I have it on true, since I use "TACVIEW" which requires allow_object_export to be set to true. Have to go now, my Sangria is empty, need to order a Mai Tai now.:smilewink:

Thanks fangav. Could it have been that 200 and 220 just happened to be inside a ravine or behind an obstacle or something? Or did you notice anything else that is special about 200/220? Have you experienced any disconnects? If so, any idea what situation typically leads to them? Desperately looking for any clues...

Thanks xcom. Would you be so kind and elaborate on your suggestions. What do these do, and why do you think they would help? Your help is greatly appreciated.

Yes

client update timeout Hi Grimes (and others), We have been working on a dynamic MP mission for the Huey (http://forums.eagle.ru/showthread.php?t=108056&page=10) that uses mist extensively. It works fine in SP, but in MP it is plagued by apparently randomly occurring "connection interrupted" events, i.e. it kicks out one or several clients, while other clients can keep playing (DCS does not crash or anything). We have been struggling with this for a week now. Given your extensive experience with DCS and mist, can you give us any hints what might be happening. The log states "client update timeout" (or something similar, I am away from my computer now).

Hi Fangav, Thanks for the feedback. Can you test next time if the ADF kicks in when you get closer to the desired map object. This would tell us if the ADF is really missing (which it shouldn't be, but then again we have had all sorts of surprises when playing the mission in MP), or whether it is just masked by terrain. I have found previously that the problems get worse the higher the ADF frequency becomes, that's why we try sticking to lower ADF frequencies.

GOT IT (we think) Sven and I did MP bug hunting all afternoon. The good news, we think we figured it out (and it looks like it wasn't a bug after all). Here is what we learned: 1) The code as posted here in this thread earlier generates 16 groups of randomly positioned enemy AAA near the beginning of the mission. The code crashes. If one reduces the number of AAA groups, say to 4, the code runs fine. Our theory: there is a maximum number of total groups that can be on a map. (does anyone know if this is really the case, and what that maximum number of groups is?). The safest option therefore would be to simply completely remove the AAA groups, then you will have some more room for groups that get generated in real-time during the mission (each pilot down adds two groups, the pilot and the enemy Charlie group that will attack you as you rescue the pilot), each convoy will generate another group (the spotter group) once it got detected, and so on. All these additional units will get destroyed after their job in the mission is done. So the number of groups changes during the mission, and may lead to a crash if it exceeds a certain number. I attached a mission with I believe either 4 or 8 AAA groups that does not crash, but as I pointed out earlier it could crash later on if the number of groups grows during the mission. The safest thing may just be to completely remove all the AAA groups, this is done by simply deleting the trigger that loads the "createEnemyAAA2.lua" code. Otherwise, open the "intialization and common routines" lua file with note++, and change the global variables that specify the total number of AAA, convoys, etc. You may also try to remove some groups from the ME itself. 2) At some point we had problems when SLMOD is running on the server. This led to an immediate crash upon entering the mission, but reducing the number of AAA groups also made this problem disappear, so we are not sure if there is a problem or not. But disabling SLMOD is another thing you might want to try if you have crashes. AirCavFullMission.miz

Should we make it 3.30 (in 20 min)? Once I am hosting, I will call the server "Wolle's AirCav mission testing, no password. Hope to meet you virtually in 20mins. If not, let me know what other time works for you. Wolle

Hi Sven, Thanks for your tests. Yes, all my dynamically created units have "player can drive" = true. I also noticed mention of SLMod in your logs, whereas there is no mention of that in my logs (attached, for Full Mission, no crash, I am hosting and the only player on my personal home computer. I host via "Multiplayer New Server etc"). Could it be that SLMod is imcompatible with my lua code, which is based on mist? Would you be willing to fly the mission with me while I am hosting it sometime tonight or tomorrow (I am on US central time). Any time works for me, just need to know ahead because I have m,any other chores to do this weekend. My feeling is more and more that the fact that missions never crash on my computer is related to a difference in setup. I do not have teamspeak3 setup on my computer. Would I have to set this up first, or can we use another TS3 server? Let me know FullMission.zip

Hi Sven, What do you think are your conclusions, what tests should I run next? Thanks for your help, Wolle

Hi Sven, Thanks for the feedback. Are you the only player, or are several people flying cooperatively? I am asking because I have never had any problems entering a helicopter when I am the only player. I have tried it when I was hosting my mission, and switching helos by first becoming a spectator, then selecting a different helo. Never an issue. I see in your logs further below that you joined sometimes as "Soldier M4". Does that mean you are running CA also? I don't, do you think this might cause the problems "driving player number 2". There is nothing special about player number 2...

mission with varying complexity for testing The radio problem should now be fixed, all active clients should have all radio items now. On Sven's suggestion, I moved the execution of the lua code further back in time. I will look at Sven's more sophisticated suggestions later this afternoon. I attached missions with varying complexity for MP testing. It would be enormously helpful for me to know what is the lowest complexity mission that crashes, then I can focus on this much simpler code. The missions range from the latest version of the full mission, to the plain old CSAR mission without any dynamic troop movements (my suspicion is that the dynamic troop movements are involved in the crashes). Any help would be greatly appreciated. AirCavFullMission.miz AirCavNoStrafe.miz AirCavNoStrafeNoAM.miz CSARNoMovement.miz

help interpreting crash files Thanks to the help of Marker and Fangav I could collect several crash files. Does anybody know how to interpret them, or even recognize a clue in them? # -------------- 20130626-180050 -------------- # C0000005 ACCESS_VIOLATION at EF315902 00:00000000 00000000 00000000 0000:00000000 EF315902 0016DD70 0000:00000000 ?setLeader@wNetGroup@@QEAAXAEBV?$cPointerTemplate@VMovingObject@@@@@Z()+C2 EF316651 0016DDB0 0000:00000000 ?onMemberBirth@wNetGroup@@QEAAXAEBV?$cPointerTemplate@VMovingObject@@@@H@Z()+31 3FFCE04F 0016DE10 0000:00000000 3FFD09C2 0016DEA0 0000:00000000 40017ECA 0016DF00 0000:00000000 40017F3B 0016DF90 0000:00000000 4001EBE1 0016F1D0 0000:00000000 EFC59E6D 0016F210 0000:00000000 ??1Reader@Mail@@UEAA@XZ()+23D ED6F928E 0016F280 0000:00000000 ED6F9341 0016F2D0 0000:00000000 ED6FBDC8 0016F470 0000:00000000 ED707827 0016F4D0 0000:00000000 ED71C6D3 0016F500 0000:00000000 ED732623 0016F530 0000:00000000 400AF3A5 0016F590 0000:00000000 400C60A4 0016F5C0 0000:00000000 400C5F7B 0016F5F0 0000:00000000 40156918 0016F660 0000:00000000 40157DEE 0016FC60 0000:00000000 4015AA1F 0016FD10 0000:00000000 76E3652D 0016FD40 0001:0001552D C:\Windows\system32\KERNEL32.dll BaseThreadInitThunk()+D 7706C521 0016FD90 0001:0002B521 C:\Windows\SYSTEM32\ntdll.dll RtlUserThreadStart()+21 # -------------- 20130629-042931 -------------- # C0000005 ACCESS_VIOLATION at EC2960A5 00:00000000 00000000 00000000 0000:00000000 EC2960A5 001DEE00 0000:00000000 ?onMemberDeath@wNetGroup@@QEAAXAEBV?$cPointerTempl ate@VMovingObject@@@@@Z()+25 3F66FBC4 001DEE60 0000:00000000 3F6677D4 001DEE90 0000:00000000 EC2939AB 001DEEE0 0000:00000000 ?netDiscard@MovingObject@@UEAAXXZ()+6B EA5B70D0 001DEF10 0000:00000000 EA5BC1D7 001DEF60 0000:00000000 EA5B9AC3 001DEFA0 0000:00000000 EA5C8E70 001DEFE0 0000:00000000 EA5C35CB 001DF0A0 0000:00000000 EC8F9E6D 001DF0E0 0000:00000000 ??1Reader@Mail@@UEAA@XZ()+23D EA5B928E 001DF150 0000:00000000 EA5B9341 001DF1A0 0000:00000000 EA5BBDC8 001DF340 0000:00000000 EA5C7827 001DF3A0 0000:00000000 EA5DC6D3 001DF3D0 0000:00000000 EA5F2623 001DF400 0000:00000000 3F74F3A5 001DF460 0000:00000000 3F7660A4 001DF490 0000:00000000 3F765F7B 001DF4C0 0000:00000000 3F7F6918 001DF530 0000:00000000 3F7F7DEE 001DFB30 0000:00000000 3F7FAA1F 001DFBE0 0000:00000000 7784652D 001DFC10 0001:0001552D C:\Windows\system32\kernel32.DLL BaseThreadInitThunk()+D 7797C521 001DFC60 0001:0002B521 C:\Windows\SYSTEM32\ntdll.DLL RtlUserThreadStart()+21 Client Crash log. # -------------- 20130629-041443 -------------- # C0000005 ACCESS_VIOLATION at EC9FFD1A 00:00000000 00000000 00000000 0000:00000000 EC9FFD1A 0015E290 0000:00000000 ?GetLoadStep@JSmokeMaterial@Effects@@UEAAHXZ()+5B5 A EC9FEFBB 0015E320 0000:00000000 ?GetLoadStep@JSmokeMaterial@Effects@@UEAAHXZ()+4DF B EC9FE610 0015E740 0000:00000000 ?GetLoadStep@JSmokeMaterial@Effects@@UEAAHXZ()+445 0 ECCFFC71 0015E770 0000:00000000 ?DrawNormalLights@DXRenderer@Graphics@@AEAAXPEAPEA VRenderObject@2@H@Z()+A1 ECD02AED 0015E7B0 0000:00000000 ?DrawObjects@DXRenderer@Graphics@@UEAAXPEAPEAVRend erObject@2@I@Z()+16D EC5CDEC1 0015E800 0000:00000000 ?DrawTransparent@RenderParserImpl@@QEAAX_N0MM0@Z() +1D1 EC5DF189 0015EAC0 0000:00000000 ?RenderScene@SceneManager_Implement@@QEAAXPEAVsmCa mera@@_N@Z()+3E9 EC5E1834 0015EDC0 0000:00000000 ?RenderMain@SceneManager_Implement@@UEAAXAEBVdPosi tion@@W4vCameraType_e@@AEBUViewport@smSceneManager @@PEAVContext@Graphics@@@Z()+4F4 EC5E2A3C 0015F0C0 0000:00000000 ?Render@SceneManager_Implement@@UEAAXXZ()+63C 3F95CA5B 0015F150 0000:00000000 3F95F42D 0015F1B0 0000:00000000 3F9760A4 0015F1E0 0000:00000000 3F975F7B 0015F210 0000:00000000 3FA06918 0015F280 0000:00000000 3FA07DEE 0015F880 0000:00000000 3FA0AA1F 0015F930 0000:00000000 7752652D 0015F960 0001:0001552D C:\Windows\system32\kernel32.dll BaseThreadInitThunk()+D 7765C521 0015F9B0 0001:0002B521 C:\Windows\SYSTEM32\ntdll.dll RtlUserThreadStart()+21

Hi Sven, Thanks so much for your feedback, I am desperately looking for clues. Indeed, I load everything right at mission start. What I will do is move all the various codes back by several seconds. Let's see if that helps. Regarding the F10 menu, are the F10 menu items not functional (but appear in the F10 list), or do they not even appear in the list. If the latter, it would be important for me to know which ones are missing: there are two kinds of menu items, ones that apply to all clients equally, and ones that are specific to each client (those can be recognized by having the client unit name at the end of the radio item text. The idea of selecting a task from a list, and then "owning" that task is great, and I will definitely do that, but first the code has to become stable in MP. Many thanks again. Any further clues would be mighty helpful.

need help from a lua guru In this thread we are discussing my CSAR etc. mission, which should work in SP and MP. Turns out it crashes regularly in MP, whereas it is quite stable in SP. I think I figured the problem out, and will likely get to test it in MP tomorrow. Nevertheless, in case it doesn't work, I would appreciate if a lua guru could tell me if I am on the right track or not. Here is what I think has happened: My code makes extensive use of mist.scheduleFunction, which allows you to run a given function with given parameters a given time later, say as an example: make enemy infantry unit run towards Huey client position in 10 seconds. This would look something like (in simplified syntax): mist.scheduleFunction(Move,Enemy,HisPosition,HueyPosition,10s) The problem is that lua passes the argument by reference, not by value. That means that if in the intervening 10s HueyPosition is changed (in my code I often loop over all clients, and HueyPosition can change to the position of another client Huey), when the function will actually run it will have a different HueyPosition as the argument than initially intended, causing it to crash. Make sense so far? I am trying to overcome this problem by making a socalled deep copy of all the variables, such that the function will run in 10s with the original argument. This problem does not occur (as often) in SP, because there is only one HueyPosition, for example. Specifically I replaced mist.scheduleFunction with this: deepSchedule = function(f, vars, t, rep, st) local deepVars = mist.utils.deepCopy(vars) mist.scheduleFunction(f, deepVars, t, rep, st) end Will this work? Would appreciate any help on this...

Did it happen after a certain message was displayed? Anyway, are you guys flying now, I am at my computer

regarding stability problems Hi guys, Many thanks for your valuable feedback. Last night I wrote a new version, with the following changes: - client Hueys get automatically recognized. - whenever creating a new dynamic group, the program checks if the point (randomly) chosen is on land or on a road. Otherwise the creation command is ignored. - whenever dynamically moving a group from point A to B, the program checks if the (randomly) chosen points A and B are on land or on a road. Otherwise the moving command is ignored. - I have added some more instances where the program checks if a unit or group actually exists, before executing any command on it. - I have included on screen messages whenever the code executes a command that I suspect could lead to crashing problems. The idea being that when the program crashes, the last message on the screen identifies the likely culprit. These debugging messages can be turned off be simply setting a flag to false. I testflew it 3 times last night and did not have a single crash in the roughly 3 hour period, but of course that does not mean it will also be stable in MP. My plan is to testfly it some more tonight, and if stable, post the updated version here in this thread, and see what people experience in MP. Of course the best way for me to figure out these problems would be if I could join someone who is willing to host and testfly this mission in MP with me. In this case please PM me, I am on US central time.

Hi Vulcan, Thanks for the feedback. If a player gets only the first two F10 radio messages, the first client-specific message is missing. This would occur if the client is not in the client list used by the program. Did you guys add any clients, or change any of the Pilot Unit names? Although this can be done, in that case one must correctly update a list of clients in the program. Furthermore, the code does not presently check if there is an unknown client, and this could lead to an erroneous execution of the code, possibly explaining the flashy messages. What I will have to do is to write a routine that automatically determines the list of all client helos at the beginning of the mission. I have also encountered a couple of "DCS stopped working" problems even in SP. Could imagine this problem get much worse with a larger number of clients simultaneously playing. I think it has to do with the DCS internal routine that makes units move around the map. It can take a lot of time to find a suitable route, and then there can be a long lua "stutter", and this gives the tendency for the sim to crash. But I will keep looking into that. Does anyone have experience with looking for crash causes in the log and crash files that could give us some tips?

Hey Vlerkies, Thanks! Please make sure to let me know how the MP action was, and how the mission plays in MP. Wolle

That would be a substantial change. I was going to hold off on doing this until the Mi-8 module is out.

new mission update: June 23 I expanded/updated the mission some more: change log: - added third kind of task: strafing an enemy supply convoy: HUMVEE patrols are monitoring the "Ho-Chi-Minh trail". If/when they spot a supply convoy, they will alert you. Follow the spotter's ADF. Once close to the spotter, he will inform you about the target convoy's relative position. Should the spotter loose sight of the convoy, he will tell you to abort. Otherwise, strafe the convoy. - CSAR task: now all landings within 500 m are valid. However, the further you land from the pilot down, the longer it will take him to run to your chopper. During that time, Charlie, who spotted your chopper during approach, may catch up with you and he will want a piece of you. - smoke marker release height has been reduced from 100m above ground to 10m above ground, for a more realistic look. - mist's messaging system is now used, that means that new messages will not overwrite old messages any more. Useful, because there are more and more messages as the mission grows. - a battle between a M113 and a BMP-1 platoon is now included. You will be kept updated on M113 loses, but there is no task for you built around this, yet. AirCav.miz

Well, in Matt's "change log" there is a section on DCS Huey, mentioning things such a mast bumping... Is it then that some changes are mentioned, and others not?

I have just read the June 21st update by Matt, which includes planned features for DCS world version 1.2.5. I was a little bit surprised that there wasn't much news regarding the Huey module. With Huey being in beta, I would have hoped that it receives the largest number of additions/improvements of all the modules. I would have hoped for things like visible crews in cabin if you take on human cargo, sling loads, door gunner AI, etc. But I guess things take time, and I need to be more patient...

Resource manager? I saw that the June 21 update mentions a resource manager. I am not familiar with that, is that described in one of the manuals or elsewhere? Would greatly appreciate it if someone pointed me in the right direction...