Sven2157

Thanks!. Sorry to necro an old post, but some of us, "old-timers" need help. now and again! <0

Is there a date for possibly getting the icon in my account? Bought or not?

850w may NOT be enough power. I highlight my reasons above. I also see that Sea Sonic Electronics Co., Ltd. is listed on the 80+ Certification website, but since I do not know the exact model, I can't say whether or not yours is certified. Why is that important? Very loosely explained ... Because of the ways that electronics are quality controlled, tested and a slew of other reasons, their wattage rating may be VERY inaccurate. If a PSU is tested and maintains a steady 350w, but spikes up to, say 700w, then the manufacturer can stamp a 700w sticker on it, instead of the 350w sticker it should have. However, 80+ certification came to be after years of this kind of misleading promotion of products. This organisation tests each MODEL - NOT manufacturer! - for 80% efficiency or better. That means that on a 80+ 1000w PSU you are guaranteed to have available 800w at any load. They also have then Bronze, Gold, Platinum, etc, etc, which offer better performance at any load. Now, just because your PSU's manufacturer is listed on the 80+ website, does not necessarily mean that your actual PSU is certified. Certification is a long grueling process, and if one little thing changes to that model, it has to be tested again. So let's look at your main issue with power: 2x 780 GTX SLI watercooled. According to EVGA's website, their lowest GTX 780 Hydro has the following power requirement: Now let's say your PSU is 80+. That means that you have a guaranteed 640w at your disposal. However your 2 GTX 780 Video Cards are eating up 250w X 2 = 500w, leaving you with 140w for the rest of the system and peripherals. This may be safe, as I don't know your exact build. This can also be slowly killing your hardware. DCS may be using your hardware closer to the maximum, and therefore this is only noticeable when you run DCS. Under-powering your system is way worse that overpowering your system; both are bad! This brings me to my next point. Do you have any other games the have a 64 bit executable? I ask because, 64 bit games are not limited to the 2GB of RAM that 32 bit games are. That is a concern, as this - as of now - no-name brand could be the culprit. Are there more than one stick of RAM; i.e. 4 x 1GB, 2 x 4GB? If so, pull one stick out, and try again. If it fails, try JUST the other stick. However, if it does not reboot the computer, let itt go for a day or so. Then try the other stick. If your computer can run the game, without rebooting on both sticks - being used one at a time - then your memory is probably not the issue. But, if it reboots on one stick and not the other, then you will have found your Anti-DCS component. Hope that helps! ;)

For some reason I couldn't get this page to load yesterday. :huh: Anyway, I was going to ask what power supply you have. As, @AtaliaA1 has mentioned, this sounds more like an under powered rig, than anything. For a descent video card, flight stick, pedals and system - you should have no less than a 700w-800w power supply. I recommend a 900w+, 80+ certified.

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

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

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

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

Well the difference in the UH-1C( Bell 204 Civilian ) and UH-1H( Bell 205 Civilian ) models is the engine size and fuselage/tailboom length. The C uses a smaller 1,100shp( 820kW ) turbine, while the H is uses a 1,400shp( 1,000kW ) turbine. So, combined with the extra length and extra turbine weight, the 'H' should technically be holding the 'bubble' center, with the mini's forward. Perhaps, they have - for the first time ever in a helicopter simulation, in my opinion - modeled the additional weight properly?

Correct me if I am wrong here, but I remember my old CAP Captain saying something about the ability for the pilot to 'cut' the blades for auto-rotation. Meaning that there is some way for the pilot to disengage the rotor from the rotor shaft, effectively making the main rotor free-spinning. Is this actually possible, and if so is it modeled? My thought on it is that the main rotor is still receiving friction from the main rotor shaft, and causing it to slow too quickly ... I will dig the net and see what I can find on that( I know Belsimtek has properly researched this, so please don't think I am questioning that ). :book: Awesome, another six-stick! I thought about this too, but quickly brushed it off with the whole difference in mass 'thing'. Though, there may still be a valid argument there. It could just boil down to, Belsimtek still 'tweaking' the flight model, perhaps? :huh:

How did this thread go from asking questions about using the UH-1H, to what you would prefer when receiving your updates? Thus the title: 'DCS UH-1H QUESTIONS '.

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! ;)

If you raise the collective to 'full max' with the engines running full, you will lose power too. Watch your engine RPM gauge, and listen to the engines when you do so. They bog down; and they will even lower to the point of audible 'Low RPM' warning sounds. Keep in mid that the collective adjusts the blade pitch while collectively controlling the engine speed. You want to keep the 67/320( i.e. 6700 RPM on the main rotor, and 320 RPM on the tail rotor ). Auto-rotation is not an easy skill to master; not by far! The key to performing what you are asking is: TIMING! Think of this as the ramp used by skateboarders( the half-pipe ). There is a point in your descent that will be too shallow, resulting in too slow rotor rpm, with little forward speed. Consequently, there will a point in your descent where it is too great, and you will have really high RPM, with too much forward speed. To start - your best approach is to try to get a 45°-50° angle from your current height to the ground, between 20-40knts; maybe even a little steeper. You will have to practice, but will eventually find that 'sweet spot'. The really trick to Auto-rotation, is when to precisely add the collective. If you add it to early, you will lose the energy to maintain flight. So, if you have a high forward speed, leave the collective down, and use that forward momentum to stop descent while also slowing the aircraft to a hover - pulling back on the cyclic. As the helicopter starts to want to drop, apply your collective - BUT REMEMBER! You only have a couple seconds to set it down before the blades run out of inertia! Open your Mission Editor, start a new map, click the little helicopter icon on the left. On the right there is a drop down, select the UH-1H( should be yellow ), under that is the 'Skill' dropdown, select 'Player' - also should be yellow. Now click on the map several feet from the end of a runway at any airport. Again on the right, you will find a box where you can adjust speed and height. Set your height( alt ) to say 1500 ft MSL. Save and load that flight. You can then just keep starting in a ready to die - I mean auto-rotate position. Practice - Practice - Practice! Good luck! ;)

We have already tested it on a couple different computers, and the random booting persists. I would rather keep it in a 'controlled' environment( i.e. one computer ), while the testing happens, as it - in theory - will make hunting down the cause easier. I will be adding some debug scripts today, and hopefully can see what is going on, when it kicks everyone. 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. Could definitely use your help, again, marker! And others too, should they fancy. 4:30 EST, is 3:30 Chicago time, and I will be here! You can just jump in TS when you're ready. ;)

Unfortunately not yet ... The only issue that we are trying to hunt down, is why it just all of a sudden disconnects everyone. If you would like to test map, you can join the server posted above, and fly all you like. But rather than release another broken copy, we would like to nail this last problem. Then everyone can download, and we can focus on more updates/functionality( or wolle can, as it is his map originally ).