new mission: dynamic CSAR and Air Mobility mission for SP and MP

[Sven2157]

Hey guys - i'm pretty new to DCS Huey. When I play this mission, and there's a radio call coming in, all I hear is LOUD static noise. is there supposed to be voice or if not, how do I turn down the static radio noise?

 

Thanks and great mission, btw!

 

The static is to notify you of a mission specific item incoming; no there is no voice. The ADF noises, are to let you know that you have the correct ADF frequency for a mission specific objective. There are other NBDs broadcasting navigational ADF signals - those won't make any noise. To turn down the volume of them, rotate your GAIN knob on the ADF panel.

 

Thanks, we are still trying to get the bugs worked out, so we can add more functionality! ;)

[impostor71]

The static is to notify you of a mission specific item incoming; no there is no voice. The ADF noises, are to let you know that you have the correct ADF frequency for a mission specific objective. There are other NBDs broadcasting navigational ADF signals - those won't make any noise. To turn down the volume of them, rotate your GAIN knob on the ADF panel.

 

Thanks, we are still trying to get the bugs worked out, so we can add more functionality! ;)

 

ahh, good to know. Thank you for the help!

[docbrown]

impostor71 you can turn down the radio static noise by lowering the "headphone" volume in the audio settings. It does get quite loud when multiple messages appear and the sound stacks up on one another.

[impostor71]

impostor71 you can turn down the radio static noise by lowering the "headphone" volume in the audio settings. It does get quite loud when multiple messages appear and the sound stacks up on one another.

 

Excellent! Thanks for the tip docbrown!

[Sven2157]

Excellent! Thanks for the tip docbrown!

 

Keep in mind that this will turn down the volume for ALL sounds that are 'broadcast' through the 'headphones' of the helicopter. i.e. ATC instructions will be harder to hear, as you are lowering that volume too.

 

By rotating the Gain knob( same knob you right click on to turn the ADF on/off ), you are ONLY lowering the ADF static and the ADF beeping volumes. ;)

[marker]

Never got the opportunity to actual have some time to myself last night, will try and get on tonight.

 

Got a new 27" monitor today, desperate to try it out :)

 

Let's hope the 3D fix for the hueybis out soon ;)

[Sven2157]

Never got the opportunity to actual have some time to myself last night, will try and get on tonight.

 

Got a new 27" monitor today, desperate to try it out :)

 

Let's hope the 3D fix for the hueybis out soon ;)

 

Haha, no worries I didn't get back until about 1 or 2 am your time. Congrats on the new purchase! :cry: (<-- me a little jealous! :music_whistling: )

[fangav]

I was on last night for about an hour with no crashes but the ADF was all over the place? Wouldn't have found anything without F10 map.

[marker]

I found that as well mate, although at times it did kick in properly, usually at when I was at a decent height.

 

Myself Sven and Wolle were discussing it, and we came to a conclusion, maybe right or wrong that the hills and nap of the earth were distorting the signal at a lower altitude!

 

What do you think, possible?

[wolle]

I was on last night for about an hour with no crashes but the ADF was all over the place? Wouldn't have found anything without F10 map.

 

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.

[fangav]

Sure mate. Is the latest version the one on Sven's server last night?

[wolle]

Sure mate. Is the latest version the one on Sven's server last night?

 

Yes

[Grimes]

This is in response to Wolle's question in the mist thread. I have no idea what could be causing the issue, but its extremely difficult to debug any code that isn't written by yourself. Also I haven't played the mission so I have no real frame of reference for what is going on. It could be anything really. You could try:

 

-Replacing player interaction stuff with slmod

-Using Ka-50s instead of Hueys to see if the problem exists with a different aircraft

-Cut down on bits of code where-ever possible

 

I suspect that the reason this seemed to work in Single Player verses Multi-Player, is that MP may reserve 32 groups for a possible 32 player server. This would then take away from the total allowed groups, thus the crashes. I could be wrong, and again we can't find any limits for the Mission Editor, nor the DCS Game Engine itself. We do know that there is a limit. If anyone can shed some light on this, it would be much appreciated.

 

Doesn't matter. Client groups are still normal groups with a known group and unit Id. Assuming the script uses sct to spawn in the new groups, then it will automatically assign non used groupId and unitId for any dynamically added group. I'm not sure what will happen if you manually use an existing group or unit Id shared with a client, I suspect that since clients are fairly special nothing will happen. If anything it'd just despawn the client, but I doubt that would occur.

 

I have also noticed that this map leaves weird ME icons on the F-10 map screen. I am assuming that the LUA code is not properly terminating, and this could be the reason that the Clients quit updating.

Thats just a bug that occurs in MP missions regardless of the use of lua. I'm pretty sure it is reported.

[fangav]

After testing the adf freq found that 200 and 220 couldn't be picked up. others seemed ok. Can be hard to lock into sometimes but 200 and 220 had no lock.

[xcom]

Just a little suggestion -

1. make sure everyone is using network connection on LAN.

2. disable allow_object_export = true.

[wolle]

Just a little suggestion -

1. make sure everyone is using network connection on LAN.

2. disable allow_object_export = true.

 

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.

[wolle]

After testing the adf freq found that 200 and 220 couldn't be picked up. others seemed ok. Can be hard to lock into sometimes but 200 and 220 had no lock.

 

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...

[xcom]

Regarding LAN setting, it's been tested widely and it always comes down to this issue when "connection interupted" is involved, from running the DCS Israeli server we've noticed that changing this setting helps, also on heavy mission disabling the export helps because it reduces the processing on clients and therefore reduces timeouts and lag.

[Sven2157]

Ok ... So I think, I may have it almost pin-pointed. These issues may be because of the way that the 'Player Groups' are created and organized in the LUA environment.

 

At first I thought it was because of Players joining and leaving. Since there is no known garbage collection, a player joining 'Player Unit #3' would theoretically set the variable, for 'Player Unit #3', to 'Player Unit #3 = "=170= Sven2157"'. However, if that player leaves, or even switches to 'Player Unit #2', then 'Player Unit #3' is set back to nil. However, the previous assignment is still in memory, and has now become Unreachable. ( "Garbage Collection Tutorial", 'The Unreachables' )

 

It may even become, and here comes the irony, cyclic! ( "Garbage Collection Tutorial", 'Simple collection algorithms' )

 

As I delve deeper into the code, I think the problem may just be the way the group is initially created. If you can spawn in fairly quickly, at the very beginning of the map, you will see a table( or what looks like an array ) of the available Player Units displayed. I believe that this assignment, when other players do not exist, might be the problem; as the other units' variables are declared at that moment. Coupled that with players connecting/disconnecting, or even switching helicopters. It could even be as harmless as just selecting a unit, to make the unit selection window 'scroll-able', may have an impact on this; not quite sure, and will have to do a bit more testing.

 

All of these actions, do the same thing: assign the variable 'Player Unit #N' to an actual player - i.e. '=170= Sven2157'. Then when that player switches/leaves, the variable is set back to nil, BUT! the table that was created is still in memory, and has now become "unreachable. If these variables are referenced by another variable, and then referenced back to the original, "They are now a group of objects which are unreachable and mutually permanent because of cyclic referencing."( 'Simple collection algorithms', paragraph 1, line 2 ). Thus, "The island will never be freed unless the reference counting collection algorithm is expanded.( 'Simple collection algorithms', paragraph 1, line 3 ).

 

This was highly noticed when one of my friends tried to re-join after leaving the mission. When coming back in, he selected 'Player Unit #2', as that was what he used before he left, and weird things happened. At first he was taken to the 'Spot Plane' view with no helicopter insight. Then trying to join again, same thing. The third time, he was loaded into the helicopter, and then just after getting in, sent back to the 'Spot Plane' view. I figured that his original join, created the table, and then his subsequent joins where 'confusing' the lua environment, as they 'appeared' to be the same.

 

I have a 3 monitor system, but I only use my center main monitor when flying( for now ). On my left-hand monitor I have a set of gadgets that I use to monitor my system( CPU/GPU temp, CPU/GPU usage, RAM usage, page file usage, etc, etc ... ). When I load this map, or join the server, my RAM usage immediately jumps up ~2.5GB. Please know that is not jumps up to 2.5GB, but rather jumps up an additional ~2.5GB! As the mission progresses, the RAM steadily increases. After about 25-30 minutes on this map, I have increased my RAM usage by ~4GB. Upon exiting the map - or server - my RAM immediately drops back down to a reasonable level. Can someone else confirm this?

 

I am guessing here, but I believe that the server is running out of available allocated RAM for the mission. This occurring would cause the system to 'wait', as what is already in memory is executed, and the new chunks are then written.

 

It may also explain, why the 'Client Update timeout' kicking is seen as 'random'; if you are in the currently processing memory chunk, then you are safe. However, if you are in a chunk 'waiting' to be written to the system memory, you are kicked. It may also explain why setting the timeout threshold to 'infinite' doesn't seem to matter, as the system possibly just declares the client completely gone at that moment.

 

Further, it could explain why MY computer hosting, will kick players much later into the mission; as opposed to my SERVER computer, which kicks players closer to mission start. My computer has 32GB of system RAM, while my SERVER has only 8GB of system RAM.

 

I will keeping looking at the code, and see if I can find a way to fully prove, and then remedy this.

 

@wolle

 

I hope you are enjoying Hawaii; you really need to stop coming in here, and GO TO THE BEACH! :megalol: . There is plenty of time to deal with this, when your vacation is over! ;)

 

But, while I have you here :smilewink: ... I have also found that more system RAM could be freed up, by re-writing your code a bit. A couple simple changes. I was reading this: Lua Performance Tips by Roberto Ierusalimschy. Particularly page 17 and 18( or page 3 and 4, in the Adobe PDF file ).

Edited July 4, 2013 by Sven2157

[Sven2157]

After testing the adf freq found that 200 and 220 couldn't be picked up. others seemed ok. Can be hard to lock into sometimes but 200 and 220 had no lock.

Thanks for the feedback fangav! I will look at this, and maybe just set them to different frequencies. Those frequencies may already be in use for static NDBs within the DCS World main map. I will have to look at my charts.

 

Just a little suggestion -

1. make sure everyone is using network connection on LAN.

2. disable allow_object_export = true.

 

The LAN and Internet LUA scripts, as far as I know, are the same. This is evident by the requirement "... AN INTERNET CONNECTION IS REQUIRED FOR MULTIPLAYER INCLUDING LAN PLAY" from the module downloads page.

 

I don't think that there are any objects being exported. I will look, but I have not set this; in my server, SLMOD or the mission. wolle have you set this in the mission?

[wolle]

@ 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:

[Cobra99]

Just a little suggestion -

1. make sure everyone is using network connection on LAN.

2. disable allow_object_export = true.

 

If number 2 is the reason for the crashes then all that would mean is that TARS would be offline for those missions utilizing this script or a similar coded one. Definitely not a game stopper since this really is a well thought out and enjoyable mission

 

Regards,

 

AEF Cobra 161 SQN

[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

[xcom]

I just wanted to add here that we are also doing tests, for example just a few days ago we tried to run a mission with around 600 moving units and 20 players, the mission was totaly too heavy, most of the units were lagging and eventualy player would disconnect.

 

I'm trying to find out what are the limites at the moment as shown in this thread -

http://forums.eagle.ru/showthread.php?t=110143

 

I've found out that these tweaks help alot -

Client side -

1. LAN in the network option as suggested by many admins and by some testers.

2. Pings under 150.

 

Server side -

1. render3d = false.

2. SLMod or any other Mods are off.

3. Server is run through a repair before the mission start.

4. Mission is saved in the server mission editor prior to startng the mission.

5. allow_object_export = false.

 

These tweaks are in no way a fix for the unstable MP at the moment, it will help on heavy missions.

159th_Falcon have suggested the following limits -

16 players and about 300 to 400 units.

 

We have managed to run a 200 unit mission with around 21 players, I should add that most of the units were static and not mobile.

 

I'll make sure to add any finds we have.

[fangav]

AEF observations of the July18 version.

After testing the exact version available in Wolle's post #123 and having no problems we decided to do some stress testing.

-We added "4 more Huey's for a total 8 heuy's, 2 A10c's and 3 F15's to the blue side and 1 su27 and 1 su33 to the red side. All flyable.

-The map setting was friendlies visible only.

-No external views.

-Network connection speed set to Lan.

 

Results

Most number of players on at one time was 10

About 20 people coming and going over the 4 hours

After 4 hours we had NO disconnects.

We named the A10c's as "Springfield ##" so they were able to call up the "request to-do list" and get lat/longs for tasking.

We did have 3 cases of pilots not getting in Huey's but they got in a different Huey so put that down to the DCS gremlins.

We had a great time and we will continue to add aircraft and objectives for balance and enjoyment.

 

The AEF would like to thank, Wolle and everyone one else, for their perseverance in solving the bugs.

Happy flying.

Fang.

Edited July 19, 2013 by fangav