ruprecht

Simple answer: if you get a launch authority in Auto mode you know you're within parameters. Manual is for those situations where you know you're a little out of parameters but you're OK with that for whatever reason.

Also the correct trimming procedure is to set and hold the correct attitude with cyclic and pedals, then hit trim, then centre the controls. If you're using 1.0 trimming you have to do the "centre the controls" bit fast to avoid rapid attitude changes. With 1.0.1 trimming you can take your time, but you still need to centre. With a FFB stick the FFB will hold the stick in the trimmed position, but you still need to centre your pedals after trimming (unless you built yourself FFB pedals).

Yes, reset. If the alternative is crashing because you have accumulated trim settings that are throwing you off, it is useful. And the OP seems more concerned about trim issues in the hover or near to, where the trim reset won't "easily get you killed". it also fixes the trampoline issue on the ground if one lands with significant trim on. So yes, it's useful.

Everyone's been there mate. You will get it - you just have to "do your time" before the hover fairy taps you with her wand and it all slots into place. One tip - map a HOTAS button to "cancel trim" - if it all seems too weird, hit that and at least you know your trim is centred. Another tip - use the flight director when not hovering. Much smoother. Just don't forget to turn it off when you try to autohover :) Good luck man.

Have had an X45 and now X52, been using them for over five years, no problems with stick, drivers or software. Would agree that they like to be used. I notice if I don't fly my pit for a few weeks, it gets cross at me and something stops working.

Your GetDevice() code won't work on 1.0. LoGetModelTime() works because it is a 1.0 function that was preserved in 1.0.1, but most weren't.

Are you using the 1.0.1 patch? If so, that's very weird.

Everyone here started out just like that :) It gets better. Practice till your fingers bleed on your HOTAS.

Aaaagh my eyes! :) Dunno mate, it looks good to me. Maybe check out the TcpListener and Socket classes to see if there are any methods you can call to check that they're properly connected? Put a whole bunch of debug console writes in there and see. I suspect it's hanging on the data = reader.ReadLine() line, blocking for input, which means that the socket somehow hasn't connected? That's a guess though. Try specifying 127.0.0.1 instead of IPAddress.Any?

Your Lua looks fine, I suspect if your client is throwing an exception that you should probably check that out :) Can you post your client code? I hate VB with a passion, but I'll have a look. Also note that my code was C# .Net, not VB!

Get a new friend :) I believe it is possible, depending on the options set in the mission.

If you have the english version there is an option in the menus to turn on english cockpit labels. The forum search button is your friend.

In modern airliners the pilots are there for 3 reasons: - passenger confidence - emergencies - sequencing with ATC They are not technically required to pilot the aircraft from A to B, but airspace is dynamic and the existing ATC systems are not advanced enough to manage fleets of autonomous aircraft mixing it up with bugsmashers, thunderstorms and plain old idiots.

In Export.lua: in the LuaExportStart() and LuaExportAfterNextFrame() methods. My current LuaExportAfterNextFrame() was posted earlier, my current LuaExportStart() is as follows: function LuaExportStart() package.path = package.path..";.\\LuaSocket\\?.lua" package.cpath = package.cpath..";.\\LuaSocket\\?.dll" socket = require("socket") host = "192.168.2.104" port = 8080 c = socket.try(socket.connect(host, port)) -- connect to the listener socket c:setoption("tcp-nodelay",true) -- set immediate transmission mode end Note also this: -- Please, set EnableExportScript = true in the Config/Export/Config.lua file -- to activate this script! Yes, the Export.lua is executed by the game if (any only if) EnableExportScript = true in Config.lua. Yes it's still in use, but the data hooks are slightly different now in BS 1.0.1. Much of the example code in the Export.lua file as it relates to getting data out of the sim is obsolete in 1.0.1 as described on the wiki. For example the old call: ias = LoGetIndicatedAirSpeed() Now looks like this in 1.0.1: local MainPanel = GetDevice(0) local ias = MainPanel:get_argument_value(51) Yes See my config posted above. Yes Not as far as I know. The sim has to be running to drive the scripts. I use instant action for testing.

snap!

Makes sense, thanks. In my limited understanding, the general difference between TCP and UDP is that TCP is designed for accuracy - so each packet is error checked, and can be re-requested. UDP just bangs the packets out there, and no error checking or re-requesting is possible. So for something like downloading a file, or using the internet, where it's important that what ends up at your end is exactly the same as what left the other end, TCP is the go. Theoretically UDP is faster and lower bandwidth because there is less overhead to do with the quality control. And for sim data, if a particular frame's data is lost, there is another frame's data right behind it. You toss each frame away and grab the next one, accuracy is less important than speed and bandwidth. UDP is slightly different to implement in Lua and in your client though. I'm using TCP at the moment cause I have it working, but re-engineering for UDP is on the list.

You don't really need to understand the protocol, just the API that the various languages use. All the low level stuff is abstracted away by the API. The data sending Lua code has already been posted and in any case is included in your Lua files in the DCS:BS directory. The other end, it's a relatively simple matter of listening on the socket and reading in the data. My example using C# .Net: private void readSocket() { StreamReader reader; String data; TcpListener listener = new TcpListener(IPAddress.Any, 8080); listener.Start(); Socket sock = listener.AcceptSocket(); NetworkStream serverstream = new NetworkStream(sock); reader = new StreamReader(serverstream); while (true) { Console.WriteLine("receiving from server..."); data = reader.ReadLine(); Console.WriteLine(data); } }

You still use a TCP or UDB socket, but you send it to and connect from 127.0.0.1 (localhost) instead.

Colin, would you mind awfully posting a LUA code extract on how to do this? And do you use TCP or UDP? Cheers

yes

You can either write the export to a file, or you can stream it to a TCP or UDP socket. I recommend the latter. You can then use basic socket networking in your .Net program to stream in the data. As per Trigger's second link, setup using a TCP socket: -- 2) Socket dofile "lua.lua" socket = require("socket") host = host or "localhost" port = port or 8080 c = socket.try(socket.connect(host, port)) -- connect to the listener socket c:setoption("tcp-nodelay",true) -- set immediate transmission mode

Note that the second link is a bit out of date now, as 1.0.1 changed a lot of the exporting stuff. The Wiki link is the current state of the art. If it helps, my current export line is: function LuaExportAfterNextFrame() local t = LoGetModelTime() local MainPanel = GetDevice(0) local slip = MainPanel:get_argument_value(108) local ias = MainPanel:get_argument_value(51) local mc = MainPanel:get_argument_value(44) local vsi = MainPanel:get_argument_value(24) local turn = MainPanel:get_argument_value(437) local aa = MainPanel:get_argument_value(438) local gmt = MainPanel:get_argument_value(440) local hoa = MainPanel:get_argument_value(439) local rst = MainPanel:get_argument_value(441) socket.try(c:send(string.format("t = %.2f, slip = %.2f, ias = %.2f, mc = %.2f, vsi = %.2f, turn = %.2f, aa = %.2f, gmt = %.2f, hoa = %.2f, rst = %.2f\n", t, slip, ias, mc, vsi, turn, aa, gmt, hoa, rst))) end This is sim time, the slip ball position, indicated airspeed, master caution lamp status, vertical speed, and the 5 lamps on the targeting mode control panel. And that results in the following output: t = 3.16, slip = 0.31, ias = 0.47, mc = 0.00, vsi = 0.02, turn = 0.00, aa = 0.00, gmt = 0.00, hoa = 0.00, rst = 0.00 t = 3.37, slip = 0.32, ias = 0.47, mc = 0.00, vsi = 0.02, turn = 0.00, aa = 0.00, gmt = 0.00, hoa = 0.00, rst = 0.00 t = 3.59, slip = 0.33, ias = 0.47, mc = 0.00, vsi = 0.02, turn = 0.00, aa = 0.00, gmt = 0.00, hoa = 0.00, rst = 0.00 t = 3.81, slip = 0.33, ias = 0.47, mc = 0.00, vsi = 0.03, turn = 0.00, aa = 0.00, gmt = 0.00, hoa = 0.00, rst = 0.00

Using simplified flight model buggers up autohover. Sounds weird, but that's my experience in a mission that "forced" simplified FM. It was all over the shop as you describe. Make sure Flight Director is off if you're using autopilot/autohover.

There are stacks of threads on this in the Game Controllers forum - http://forums.eagle.ru/forumdisplay.php?f=96 Also look here: http://www.vaaf.net/wiki2/index.php5?title=Black_Shark_MultiMonitors

There are stacks of threads on this in the Game Controllers forum - http://forums.eagle.ru/forumdisplay.php?f=96 Also look here: http://www.vaaf.net/wiki2/index.php5?title=Black_Shark_MultiMonitors