Alex_rcpilot

Well that was some serious burns. Did the stick come in contact with any suspicious metal right before it went dead, or did it just die when you were flying? If it's the former case, then you probably don't have to worry about any hidden threats, but if no particular cause comes to mind, then your friend really has something to inspect. You will also need to check for proper insulation after getting it back and trying to assemble the unit.

Thanks guys. To this point I think it's more than clear that pilots don't necessarily depend on sight to operate instrument control inputs. I finally had my speculations confirmed - no mater how obvious they seemed from the beginning. I guess this is also a huge difference using touch screen will make when it comes to home cockpit building. You get to fly multiple types of aircraft in the same pit, but non of them will really give you the sense that it's an extension of your physical body, due to the fact that you need to look down to find the control drawn on the flat surface. At least I would hate pressing on a flat panel without looking. lol

Yes I was talking about real life, didn't know real life HOTAS was dead fixed. The point of my doubt in reply #18 is actually about how well the HOTAS does its job by its very definition. If it proves perfect, then perhaps the pilot does have time to glance before reaching out elsewhere, because the hot situation either hasn't started or is already over.

How about chaff and flare dispenser? :D

Oh wow, I've never read that book, but I enjoyed this discussion here. I wonder how the head mounted sight would affect pilot operation, I mean the mini display gear mounted on the helmet. I presume when the pilot rolls into action with this device, he isn't supposed to touch anything besides the collective and stick units?

I kinda wonder how well a pilot can plan his sortie by programming the HOTAS so properly that he won't need to reach for anything else when situation gets hot. If it's really not such a big deal to achieve, then perhaps his sense of touch doesn't require much training?

Ah....forgive me then, as I didn't figure out this part in the first place. Well, that does look wrong, actually I changed the title more than 3 times to find a shortest one that fits the content. The initial "Question:" wasn't there originally, I put it there seconds before submitting because I didn't want readers to feel like I was introducing a piece of new technology before entering the thread. I admit that I've made a terribly organized thread with questions mixed with speculations. I hope things will start to make sense as the replies develope.:D

Yes, those signs are essentially what led me to wonder about real pilots. You reminded me of those gloves, I don't know how thick they are, but they certainly disturb the perfect sense of touch on bare hands.

This info helps, thanks Cali. Yesterday I phoned a friend who spoke to a commercial pilot, and he told me that commercial pilots are required to look before touching. However, such guidelines are not strictly enforced during routine practice. Commercial pilots focus on safety, and don't concentrate their sight outside of the cockpit as much as fighter pilots. I think that's why the guidlines emphasize looking at the controls. The pilot whom my friend spoke to knows how to feel the position of flaps lever, and he's used to setting flaps' position without looking at the unit during most landings.

I made a whole bunch of speculations only based on reasoning when I wrote this poorly organized thread. The point is just to prove or disprove whatever I wrote there with the help of people who have the knowledge of real fighter aircraft. No matter how reasonable a speculation is, it doesn't stand upright until proved. Thanks for your information.

Sorry, I must misled you into thinking somthing fancy by using the word "haptics". I didn't mean to imply that haptic feedback technology was used inside a cockpit, such stuff fits some cellular devices pretty well though. I just meant the sense of touch.

After looking through cockpit photographs of numerous real life fighter jets, I can't help wondering how the designs have been put to practice. It looks pretty obvious that in places of highly populated instrument panels, fences and other protruding structures are located between buttons or switches. Some of the structures are built to prevent false inputs, a good example will be a toggle switch with a locking detent which only disengages when the pilot pulls out its control rod. In cases where the pilot inadvertently slams his finger on some of these toggles, they'd remain still. But others seem more helpful to pilots when it comes to locating a desired component, rather than protecting undesired ones. The "5" button on the CDU numberpad of A-10C for example, protrudes a little higher than the rest. This would probably help the pilot speed up numeric inputs just like a home PC keyboard does with its numberpad. Is it also appropriate to assume, that a pilot can find most pushbuttons, toggle switches, dials etc. only by touching, just like what he does with a HOTAS system? I'm asking this because the pilot's vision is heavily occupied by the exterior view during an intense air combat. Taking his sight off the target or whatever important external reference, and using it to visually locate a button inside of the cockpit may cause him to lose his situation awareness, even his life. Maybe most of the vital functionalities have been programmed into the HOTAS, but is there still anything left over that requires extra attention? Do pilots sometimes choose haptics over vision for instrument inputs? If they can, are they allowed to do that?

I know it sounds a bit odd, but try unplugging all your game controllers and then launch the game. I had problem launching the game as well, searched all over and found a guy complaining about his joystick causing the problem. Then I realized it wasn't just FC2, a couple of other games with joystick support wouldn't start either. I renewed the controller firmware and things were back to normal.

Noticed some patterns: Each take off or landing waypoint, will generate +1 waypoint in the list. Having a -1 waypoint seems normal, it appears to be the last waypoint's "next" value. When one of the waypoints in the list has its "next" value = 0, it could mean one of the way points is a take off waypoint. Hope I won't have to rediscover something others already worked out pretty thoroughly.

Hi guys, I'm testing my LOFC2 Ver.1.2.1 export script with a simple mission I built. The mission has a total of 6 waypoints, but I got 8 in the exported data. The script goes like this: local route = LoGetRoute() if route then socket.try(c:sendto(string.format("Goto_point :\r\n point_num = %d ,wpt_pos = (%f, %f ,%f) ,next %d\r\n",route.goto_point.this_point_num,route.goto_point.world_point.x,route.goto_point.world_point.y,route.goto_point.world_point.z,route.goto_point.next_point_num),host,port)) socket.try(c:sendto(string.format("Route_points:\r\n"),host,port)) for num,wpt in pairs(route.route) do socket.try(c:sendto(string.format("point_num = %d ,wpt_pos = (%f, %f ,%f) ,next %d\r\n",wpt.this_point_num,wpt.world_point.x,wpt.world_point.y,wpt.world_point.z,wpt.next_point_num),host,port)) end Nothing fancy here. There're only a couple of prefixes to help visually locate each section. And here's what came in through socket: Goto_point : point_num = 2 ,wpt_pos = (-284889.062500, 45.000000 ,683853.750000) ,next 3 Route_points: point_num = 1 ,wpt_pos = (-285204.406250, 45.000000 ,682643.937500) ,next 2 point_num = 2 ,wpt_pos = (-284889.062500, 45.000000 ,683853.750000) ,next 3 point_num = 3 ,wpt_pos = (-307471.406250, 45.000000 ,610423.750000) ,next 4 point_num = 4 ,wpt_pos = (-337618.312500, 45.000000 ,617159.125000) ,next 5 point_num = 5 ,wpt_pos = (-293402.687500, 754.000000 ,790813.812500) ,next 6 point_num = 6 ,wpt_pos = (-260895.734375, 1086.000000 ,783488.937500) ,next 7 point_num = 7 ,wpt_pos = (-284889.062500, 45.000000 ,683853.750000) ,next 0 point_num = 8 ,wpt_pos = (-285204.406250, 45.000000 ,682643.937500) ,next -1 Obviously "for num,wpt in pairs(route.route) do" went a little too far and we can see the "next 0" and "next -1". Did I do something wrong? If there's no way around this I can still filter off the corrupted messages by recognizing the off range "next" values, but I'm just curious. Thanks for reading.

Yup, if that was really their concern they're probably on the right track. Raising the bar for its users does keep unwanted attention away, at least for a while. And that leads to a new question here: do we see 3rd party translators as volunteer promoters for game producers, or accessaries for piracy? Make no mistake about my standpoint here, I'm totally against piracy. We run our forum with stringent rules - nobody talks about pirated sims. In a country filled with $1 movies and games, one would naturally point out the downside of this operating model: we piss people off, especially those who don't wanna pay a penny for what's already sold at a cheap price. For most sites this would be unacceptable as every other site may easily out number their click rates. But over time this stringency paid off in other ways. After all, click rate isn't the only treasure for a site, and we don't reject piracy for treasure, we do it just because it's wrong.

Interesting discussion here. I'm by no means dependent on any form of localization. But as 110 stated the vast majority in here are really having a hard time with English. Making mods is totally feasible as Pyroflash said, and that's exactly what has been going on since the Flanker series more than a decade ago. However, that's not quite the answer to the question here - why does ED have to depend on 3rd party organizations to adapt to the Chinese market while they've made official support for a number of other regions? If it's just a matter of lacking man power, that won't be a problem at all. IMHO, outsourcing this non-confidential part of a software won't hurt anything. One of the advantages with an official release is safety. 3rd parties don't always provide clean files, and players don't always know how to avoid it. I don't mean to suggest what ED should do. I'm just saying there are possibilities which can make things better.

by "the board" I meant air brake.

I never liked the so-called precision slider on X52, it's not even stable, not to mention precise. The linear potentiometer inside wears out pretty soon. I think putting the board on a hat switch would resemble a toggle better than a slider does.

Nice carpet.:D

Way to go! Now you can do some serious damage with your gear set up. lol

I Think that's uncleaned flux, probably rosin left over by workers. Honestly I wouldn't consider purchasing this product since I've seen this picture. to -odin-: You need to make sure the probes are properly connected to the power supply output, and that it's not connected to the board when taking voltage measurement. If that's all done right and you still conclude the power supply is faulty, I think you can use your computer PSU as power supply. BTW, what LED are you talking about? Is there an LED on your power supply? IC13 looks like an LM2576, a DC-DC step down power supply capable of generating 3A output. The black stuff near the power connector marked "FUNC****" is a fuse, "160" looks like 1.6A to me. Please check the rated output voltage and current on your power supply. The board must consum less than that much current in order not to blow the fuse. I guess you may easily find a rail with 1.6A+ margin on your 1000W PSU. Just check the spec of your hardware and do the math. With the fuse as a protection and the National Semiconductor chip lying there, it doesn't look very risky to me for you to mess with your PSU. But I still want to remind you to be extra cautious with your hardware. A 1000W PSU is an expensive piece of investment, at least compared with a separate power supply.

This event wouldn't have been possible without FC2 and DCS, we really appreciate ED for providing such an awesome platform.

Thanks for watching, Jim. 3GO server currently hosts all missions with Flaming Cliffs 2, the parade mission was joined by Black Shark clients. An edited video is at the top on our todo list, we will see if we can get a discrete soundtrack for it. A lot has been going on since the planning of this event. I've only participated in a tiny fraction of the whole. Honestly, we've been taken by surprise numerous times. The parade was scheduled on a weekend evening, nice time for pilots to gather but also a rush hour for internet usage. That makes a very unpleasant recipe when combined with the crappy network infrastructure in China. Inside the fleet, a couple of pilots were getting really high ping values and were having a hard time keeping a nice formation. On the ground, direct livestream hosts had just enough bandwidth to keep streaming video with the game connected. As one of the relay hosts, I kept losing connection on both downstreaming webpage and upstreaming Procaster service. I kept reconnecting more than two dozen times during just a couple of hours, and I guess viewers on my channel got pissed off really bad. Other relays had similar issues, few of us knew what was going on until we saw the replay and mission track screenshots. Anyway, we've overcome as much as we could with what we had. I need to ask the guy who took the screenshots for permission to share them here. I will come back with some more info later. Cheers!

It be even more awesome if that can be exported to a second computer, i.e, not having the local graphics card rendering the image.