m0jo

Problem solved, I created a script to shuffle the position of grounds units. I will continue to work on this script to include a dynamic campaign The files can be found at I will create a thread tomorrow detailling the script

You can use Oakes script available at google code to interface OC cards with BS : dcsbsexport. Also, some information can be found in Oakes thread. My config files with Oakes export script are available at

The first solution is to program a client to SIOC and this do not need any interfacing with BS. This program could be coded in C or any other language as long as it can connect to the server(sioc.exe) and read the variable of SIOC. When a switch is pressed in the physical cockpit, a variable change from 0 to 1 inside sioc.exe and the new client program see this change and send the right keystroke. The solution #2 can work directly out of the box but is not as clean as the first one

That is normal because on the BS computer, only the sim itself is connected to the IOCards server (sioc.exe). The emulated keystroke is only working on the computer where sioc.exe is running because sioc.exe is sending those keystroke directly to the OS. There are 2 solution to this problem, the first one is to program a client to SIOC and this program could read the variable value of SIOC and send the appropriate keystroke to the OS. Another solution is using a program like synergy to relay the keystrokes between the computer running sioc.exe and the computer running the simulator.

Reverse the magnet (polarity / North-South) on the pitch axis but don't touch to the polarity of the wiring, the hall effect sensors is not built to be wired incorrectly.

From my config siocConfig.lua, lamp number are in bold: [330] = {0,[b]437[/b]},--AUTO_TURN [331] = {0,[b]440[/b]},--GROUND_MOVING_TARGET [332] = {0,[b]441[/b]},--CLEAR [333] = {0,[b]439[/b]},--FORWARD_HEMISPHERE [334] = {0,[b]438[/b]},--AIRBORNE_TARGET [335] = {0,[b]330[/b]},--PPR_button_K [336] = {0,[b]332[/b]},--PPR_button_H [337] = {0,[b]333[/b]},--PPR_button_B [338] = {0,[b]331[/b]},--PPR_button_T [339] = {0,[b]334[/b]},--PPR_button_DIR

Sol 7 have been replaced by Nthusim few months ago: http://nthusim.com/

I have developed a modified Export.lua designed for multi-player server. This modification is able to block certain function used for cheating while conserving some export ability for genuine use. This file will work with the integrated integrity check of DCS:BS/FC2 so the admin can force which function are allowed on their server. For example, the admin can choose to deny the use of LoGetLockedTargetInformation() while letting the LoGetAltitudeAboveSeaLevel() available for pit-builder. Also, the user can use their own script because these will not be check by the server for integrity problem. I have modified Oakes SIOC export.lua and BSVP to work with my modification without any problems. With the default configuration, these 2 tools have all the information they need to work. Some others script like ERI might not work with the default configuration. My script includes Oakes SIOC export.lua and BSVP. You can download it at this location: https://www.simonguilbault.ca/upload/dev/dcs/functionblocker/functionblocker20100701.zip Somebody with a good knowledge of Lua should verify if this script don't have a major security hole because I don't really know Lua well enough to see theses problems:music_whistling:(edit: found one, IC "luabit-0.4/bit.lua" to correct the hole) Alternate download link if the first go down: http://www.mediafire.com/?ymmtxk0wyek Edit of July 2, 2010 : "luabit-0.4/bit.lua" should be checked by IC because this might be a export/security leak if modified by the end user.

All the details of my little modification are inside Oakes thread (http://forums.eagle.ru/showthread.php?t=45377)

I have modified ExportSuport.lua to include potentiometer support, this work fine for the 3 potentiometer of the Shkval and the pot of the Abris brightness. To make this work, only add this following code to the bottom of ExportSuport.lua: function SimplePotentiometer(pValue, pDevice, pNumber) GetDevice(pDevice):performClickableAction(pNumber + 3000,(pValue /256)) endExemple: to control the brightness of the HMS, add this code to siocConfig.lua [701] = {SimplePotentiometer, 23, 1},--Helmet device brightnessAlso, some switch 3 positions switches like the baro/ralt altitude do not work like the burst length switch. To make this particular switches work correctly, a value of 1 6 11 must be used instead of 1 2 3 The SIOC code for this switch is: Var 0518, name BaroRalt, Value 1 Var 0906, name Baro, Link IOCARD_SW, Input 279 { IF &Baro = 1 { &BaroRalt = 1 } IF &Baro = 0 { &BaroRalt = 6 } } Var 0907, name Ralt, Link IOCARD_SW, Input 286 { IF &Ralt = 1 { &BaroRalt = 11 } IF &Ralt = 0 { &BaroRalt = 6 } } And the code inside siocConfig.lua is this: [518] = {SimpleRotary, 33, 6},--Autopilot BARO/RALT altitude hold mode My configuration files can be found at https://www.simonguilbault.ca/upload/cockpit/

Maybe this picture can help you

You can use a potentiometer for the brightness knob of the Shkval and Abris with opencockpits usb card. I modified a bit oakes lua export code and the Shkval pot seem to work fine. I will finish my Shkval panel this week, re-test the code and I will post my little modification.

Its possible to drill large hole (~15mm) into thin acrylic, put tape on both side, clamp the piece to the drill press and use medium-low speed (~800-1200 rpm). Also, lighten the pressure when the drill bit is about to pierce the acrylic to prevent cracks. I have successfully drill 25 larges holes into a 3mm acrylic piece for the PVI-800 without any problems.

This could solve the AI problem in multi-player: at 1:55 One player could control one coalition while another player could control the other coalition and these player could move their respective ground forces and strategically engage the enemy forces. This seem to be already implemented for the BS/FC engine. Also, this player could serve as a ATC/commander for his team if he have access to the AWACS and ground radar

FC2 support FFB on pedals (steering wheel) at least for the vibration. I hope BS will support those pedals in the future because my FFB pedals are pretty useless in BS ATM :(

I never found out a way to completely remove the return to center when the FFB is not detected. This could be easily corrected by ED in a future patch:helpsmilie:. A small workaround is to send "Z" and "X" while pressing the trim button, this will cancel the virtual trimmed position and the ingame position will match the real position. This is not perfect because the ingame position will jump to the center until the axis is moved a bit. The quick re-enter cause by the XZ keypress is even worst than the default spring axis behaviour.

A custom version of Mumble might work because the source code is available. Also, Mumble can be interfaced with the radio in-game and mute communication between player when the LOS is lost Mumble >>> (Ventrilo and TS) in term of quality and latency

I think the problem might be with the driver of the logitech wheel. The software "forcetest.exe" is not working on the wheel and "fedit.exe" only work if I exclude the Y axis (not the main axis) from the force-feedback. Maybe Blackshark do not work with the wheel ffb type and only work with the joystick type of force feedback. Maybe a dev from ED could check if wheel base ffb are supported by the sim right now

According to the manuals, the GNSS is correcting the INS drift, so the INS drift might be corrected if the GNSS is working correctly

I finally built myself a set of FFB pedals but they are not working like they should… My pedals are base on a Logitech Driving Force wheel and the game doesn’t detect the FFB on the wheel axis (rudder in the helicopter). The FFB is always forcing toward the real center of the pedals and not the trimmed position, also the trim change the virtual center position of the pedals (like a spring axis). The force-trim is only working on the cyclic, the rudder behave like a normal spring axis Also, when I start the game, the MSFFB2 shutdown the FFB while im in the menu and the Logitech Driving Force have still the FFB activated, this might be an indication of the FFB of the pedals not being detected by the game. Any ideas for solving this FFB problem? :helpsmilie:

Don't worry, the CERN have a received a red crowbar :http://blog.reddit.com/2008/11/crowbar-arrived-at-cern-freeman-was.html

This is the KA-50 before the ABRIS was introduced, this is another KA-50 without the ABRIS :

Router documentation is not needed On windows, you need to open the command prompt (cmd.exe), and then write "ipconfig". This will print the IP address of the computer and other information about the network connection If the router use dynamic DHCP, you will need to use the command "whoami" instead. This command will show the name of the computer. The part before the / is the name of the computer and this name can be used instead of the IP address

RTS module would be great in MP, a player on each side could control ground forces, should be "easy" to implant, ground unit already have movements and attack commands

What is the purpose of the Archos media player above the gamepad ? recording footage ?