Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. WideFS does absolutely nothing at all except allow programs on the client to talk to FS through FSUIPC. You most certainly have something else making these changes. Maybe you have some Lua plug-in installed in the same folder as WideClient on the client PC? Any .lua file there will be automatically run as soon as WideClient connects. If not then you have some other program or assignment doing it. Don't forget that buttons and switches on the Client PC can also be assigned in FSUIPC on the FS PC. Regards Pete
  2. Such an implementation could be achieved, but certainly not through simple assignments. I've never even received such a strange request in the whole 16 year history of FSUIPC! ;-) In order to accomplish something like that you'd need to program it in a Lua plug-in script, assigning the said axis to that Lua plug-in and having that decide what to do with the resulting value based on the switch setting. Regards Pete
  3. Well, to calibrate one assigned to a reverser axis, yes. Yes. You are looking in the wrong drop-down list. The "FS Controls" do not feature a reverser axis. You have to first select "Direct to FSUIPC" in the axis assignment choices, then the drop down list shows all the FSUIPC axes. Those assignments go direct to calibration and so are more efficient (the FS axis controls go to FS and, if calibrated, are then intercepted by FSUIPC). The reason the default is for FS controls is that some add-on aircraft don't like the controls FSUIPC uses, as they need to be sent to fS at a lower SimConnect priority level. FSUIPC supports a common reverser for all engines, or up to 4 separate ones. Pete
  4. Assuming you aren't starting in Paused or Slew mode, which can sometimes result in a stall initially, I suspect the messages needed by FSUIPC aren't arriving from SimConnect because the latter is overloaded at start-up time. In the log you posted initially, how long were you actually flying for? It looks like you closed down after a few minutes. You said you weren't running anything on the Network, so what do you use WideFS for? When you say "when i boot up FS Commander it cannot find FSX and likewise a program i used as part of my flight logging for BA Virtual is connecting either", are both of those, then, running on the same PC as FSX? If so then they should connect -- the only thing which might stop them s if you are running FSX at a different privilege level to those programs -- either run everything normally, or everything "as administrator", not a mixture. Pete
  5. The only thing FSUIPC will be doing is rescanning all connected USB joystick type devices. Maybe this is waking up an sleep device, or causing one to stop doing something odd. Have you made sure that Windows power management is turned off on all USB hub devices in the Windows device manager? BTW you can stop FSUIPC doing this by adding "AutoScanDevices=No" to the [General] section of the FSUIPC4.INI file. Pete
  6. "LVar" stands for "Local variable", and these are used commonly these days in Gauges -- especially those written in XML. FSUIPC provides a way of setting values to these variables, using a macro from a macro file. To discover if there are any LVars or interest in use in that aircraft the first step is to get FSUIPC to produce a list of them. That's done by assigning a button or keypress to the control called "List local panel variables". It will then simply list all those it finds for the currently loaded aircraft, along with their values. If any of them look to be of likely use, the next step is to see how they change. That's a bit more complicated. You need to put the Lua file called "log lvars.lua" (from the Examples ZIP in your FSUIPC Documents subfolder, in the FS Modules folder) into the Modules folder, then load up FS and assign a button or key to "Lua log lvars"., then use it to start the program. Now the L:Var values will be shown on screen as they change, so you can operate switches and see their affect. After that it's a matter of constructing the macros to operate those switches through their L:Vars instead. There is documentation for all this stuff, but if you need further help come back. First you need to see if L:Vars might be the way, or not. Pete
  7. You have a bad P3Dv2 installation -- its SimConnect part is not installed. .That's essential for most add-ons and is heavily used by FSUIPC4. Try finding and running the SimConnect.msi file. Maybe you can get help in this in the P3D forum, as I personally don't understand why it hasn't been installed when you installed P3D. You might need to redo the installation completely. Pete
  8. Okay.the log shows you using the DHC6, which is in profile "Twin Engine Turboprop" with only these axes assigned: 0=AX,256,D,7,0,0,0 1=AY,256,D,8,0,0,0 2=AR,256,D,47,0,0,0 i.e. the toe brakes and the rudder/slew combo. You have no assignments to your controller B for that profile, unlike the other profiles. Pete
  9. The "blah blah blah" bit is the important bit. That error can only occur if you asked Wideclient to run some program or other, as in a "Run" command. Ah, hold on -- didn't you say you were trying to run a Lua program using "RunKey"? That won't work. Lua programs are not recognised as such by Windows. Only a Lua interpreter can run a Lua program. Yes. "setbtnstate" is for Toggle buttons, whilst "setbtncol" is for non-Toggle buttons. They are two ways of doing effectively the same thing for the different types. What buttons are you thinking of testing here? I'm completely confused about what you are trying to do. If you want a button to change colour when it is toggled, use the toggle facility. If you want the colour to reflect a state of something in FS it is the offsets in FSUIPC you need to be testing, and you can have events for those. So you need to test the switch states by having events on the appropriate offsets which reflect the switches in FS. I really don't know why you are concerned with testing buttons, which you can't do anyway on the client except for the relevant offsets which reflect the buttons states in FS. Pete
  10. If it is on-screen then it isn't FSUIPC. I thought you meant in the Log file -- FSUIPC only deals with VRi devices if there's a VRinsight section in the INI file. e.g. something like [VRInsight] 1=COM3 but if the device isn't there there would simply be an entry in the Log file -- same as if it was there in fact but with a "not" or similar. Try the VRinsight support forum. It probably just needs something disabling in the VRi control program. I think it is all new since I last got involved. Pete
  11. Your choice entirely. I don't know Saitek pedals from any others I'm afraid. Don't mix up the notions of assignment and calibration. FSUIPC's calibration works on FS controls, not axes, and works no matter where you assign. Be aware that if you have FS's controllers enabled, then it can and often does automatically assign axes and buttons, especially if it, for any reason, thinks the controller is newly attached. If you are assigning in FSUIPC you should really disable controllers altogether in FS for this reason. But if you are only using FSUIPC for calibration, you can assign everything in FS instead. Your choice. The main advantage of assigning axes in FSUIPC is simply that you can have different controllers for different aircraft, something you can't do with FS assignments. Pete
  12. Just remove whatever you added to make the VRi COMBO work. I don't recall any of the VRi stuff myself (not been involved with it for years), and I'm away from the PC containing the documentation. Can you look it up? It's be an appendix to either the User Guide or the Advanced Users guide, or maybe even a separate document. All the documentation for all things to do with FSUIPC is found in the FSUIPC Documents folder, within your FS Modules folder. Pete
  13. Software doesn't change on its own, and nothing touches settings you have made. I can't tell from the files you uploaded because though you called one "INI" and the other "LOG" they both contain the same identical LOG file!! Your settings are in the INI file. However, you seem to have enabled all sorts of logging and the log does show plenty of inputs arriving from somewhere -- probably controllers. For axes is shows Mixture1 and Mixture2 inputs. After what appears to be a USB device reconnection (you were unplugging things and re-plugging them?), rudder and toe brake inputs. I'd guess that your controls are swapped. The usual problems folks have is when they have multiple controllers connected and either don't keep them plugged in, so that each time they are reconnected in a different order they acquire a different ID, or you do some update to Windows which also changes the IDs. The way around both problems is to always use joystick lettering so that FSUIPC can track the movements of the controllers. There's a chapter about this in the User Guide, listed in the contents. Pete
  14. Enable event logging in FSUIPC and see if those mouse clicks send normal FS controls. If so you can assign to those. If not, the next step is to see if they are susceptible to the FSUIPC 'mouse macro' option, and lastly, failing that, log L:Vars and see if you can operate them using L:Var macros If the MD11 you are using is the PMDG one, then have you looked at the User Contributions subforum? This thread: http://forum.simflight.com/topic/63151-pmdg-md11x-commands-upd16thdez09/?hl=md11 certainly appears to show that the mouse macro method works well. Regards Pete
  15. Yes, that's the general idea. Ooops! Well spotted -- the red [Not WideClient] notice should be there. Sorry, it isn't possible to use LVars on a client Pc. They are intricately bound into the gauges which use them. 193? Reported where? By Windows? Windows error 193 is "bad EXE -- not a valid EXE program". I don't know how that can be connected to Lua. LUA files are simple text files. Just use Notepad or any text editor! Any file or filetype .lua placed in the same folder as WideClient will be run as soon as WideClient connects to FS. This has never failed. Check the logging -- Lua files run there are logged. I assume this Lua was NOT placed in the same folder as WideClient, then? Where do you find "ipc.btnstate"? What does it mean? And how is (40,0) button 1? You can't just invent your own library functions. You can only use what is there. That line would give you an error, logged in the log for that Lua plug-in -- didn't you look? And note that ipc.setbtncol can't be used on button spaces declared as Toggle. Pete
  16. Yes, the logging was for your information, not mine. It simply shows which lines in the Lua plug-in were being executed in relation to changes in the ground speed. none of those lines restore the original frictions. Which is what I've been saying. Really, if you think there's something wrong with the frictions being set by the plug-in you'd be better off going to the AVSIM FSX forum and finding the original very long thread there about the whole matter. I'm sure it's been thrashed to death. I've never used any friction patch myself because the aircraft model I use performs quite as expected and verified by real pilots. Regards Pete
  17. If you are assigning the throttle via FSUIPC, then as well as the assignment on the left in the Axes tab, on the right you can assign FS controls to operate when the lever is moved through or into defined regions. F1 by default is assigned to the FS control "throttle cut", so try assigning Throttle Cut to the range near and into your idle zone, selecting only the down direction (so it doesn't get sent when trying to increase throttle). Pete
  18. That's just a log of it starting and ending. To see what it actually does you need to enable the Lua Debug/Trace option. BTW, when you apply brakes, there's a delay after releasing them before they are fully off. Pete
  19. Okay. Let me know how it works out. If folks bounce they it should be recorded in any case! ;-) Pete
  20. Not sure why you felt you needed to download the Lua package when it is installed automatically for you in the FSUIPC Documents folder along with all the documentation and examples. Anyway, all FSUIPC is doing is overwriting the values in the ground friction tables with new values. I've really no idea what these do -- I added the facilities when others had already experimented with manually patching SIM1 to do similar things. The facilities in FSUIPC are more flexible as they allow dynamic changes, which facilities are utilised by that DynamicFrictin package written by Bob Scott. As far as I can see, it only changes the frictions for taxi speeds above and below 30 knots GS. There appears nothing specific to whether you apply brakes or not apart from the GS changes. The [LuaFiles] section keeps an index of the first 127 Lua plugins placed into the Modules folder. The index is used when assigning buttons or keypresses to Lua plug-in actions, and the index is needed to provide consistent assignment. As far as I am aware it works as intended as it is. Certainly, once the table is changed it stays changed until it is changed again -- there's nothing in FS which changes it as FS regards it as a fixed, constant table. I don't know how you are verifying that things are reverting when you press brakes, but you'd need to check by writing a Lua plug-in to read the values and log them. Meanwhile, you can also of course enable Lua logging to see when and what the existing plug-in is doing. Since the plug-in is started when you start FS you'd need to enable logging then restart FS. Pete
  21. Sorry, can you clarify? There's no page 3 in the Axis assignments tab. Do you mean the Calibration tabs? If so then the exclusion options at the bottom, which are normally enabled, merely prevent the calibration of those specific FS controls. Don't forget how FSUIPC calibration works -- it intercepts controls before they arrive in FS's simulation engine and adjust the final values. The excluded controls are often used by add-on aircraft for internal direct control, as with a special autopilot. Those then should not be altered as if they come from a joystick input. The explanation is actually in the manual. It is in step 12 of "THE EASY STEP-BY-STEP WAY TO CALIBRATE YOUR CONTROLS". Pete
  22. I see you have specified the Server IP address rather than let things sort themselves out, or by specifying the host name (UTILISATEUR-PC). Why? Have you checked that the IP address is still correct (192.168.1.12)? Because it is not getting through. If it is correct then you have some firewall preventing access completely. There is no sign of a connection at the Server side. Pete
  23. So please explain to me, then, why it is referring to WAV files in PC-Seldon. If it is only a shortcut to a "proper" folder elsewhere, the shortcut should include that folder as the place to get its files from. That's the way a normal shortcut works. I think you need to check the shortcut properties because you most certainly have it wrong.. By itself is no good. It needs all the WAV files and the R4.CSV file, probably others. Why don't you just do the simple thing I suggested, delete it all and start again with a clean install from a download, as I just did? Pete
  24. What Lua plug-in? You mentioned one before. What plug-in are you using? And what security problem? This exchange seems to be taking a weird turn. I don't know where you are going with these extra mentions of other things. But the normal way to unclutter the desktop is to group SHORTCUTS into folders on the desktop, not complete sets of program files! I've never seen that done before, and I honestly think it is a bad idea. And it obviously is a bad idea for FSRAAS as it can't find the files it wants and points to WAV files which evidently aren't there either. Are you REALLY sure you didn't mean to use a shortcut in the PC-Seldon folder on the desktop, but instead incorrectly have the actual EXE there instead? It would explain why the sounds aren't found and why r4.csv isn't found. What's that part about? I don't understand your context. Why is C++ simple, if that's what you mean? Pete
  25. I've downloaded and installed FSRAAS 2.0, and just tried it taxiing to and onto a runway. I enabled the same logging as you so you can see what you should get. I installed it in E:\FSRAAS, not in my FS folder (E:\FSX) but next door. I do not run either "as administrator". All the sounds played correctly. Here's the relevant part of the log. you can see that I get status 1, meaning it is playing, and I get the relevant messages after each sound showing it completing. 132757 LogOptions changed, now 00000000 00000211 133131 Ready Flags: Ready-To-Fly=Y, In Menu=N, In Dlg=N 141056 Memory in use: 1172Mb, Avail=2924Mb 201241 Memory in use: 1235Mb, Avail=2861Mb 216950 Sound: Ref 37, via IPC: Cmd=1, Wave="E:\FSRAAS\Approaching.wav" 216950 Sound: Id 256, PlayNow("E:\FSRAAS\Approaching.wav") 216950 Sound: Id 256, PlayTheSound("E:\FSRAAS\Approaching.wav") 216950 Sound: EnumDevice=Primary Sound Driver 216950 Sound: EnumDevice=Speakers (5- High Definition Audio Device) 216950 Sound: EnumDevice=Digital Audio (S/PDIF) (5- High Definition Audio Device) 216950 Sound: EnumDevice=Realtek HDMI Output (Realtek High Definition Audio) 217075 Sound: Ref 37, IPC: Status Response=1 218011 Sound: Id 256 DeActivate: sound not playing now ... 218011 Sound: Id 256 EndPlay: releasing buffer 218011 Sound: Id 0 EndPlay: all done! 218074 Sound: Ref 6, via IPC: Cmd=1, Wave="E:\FSRAAS\06.wav" 218074 Sound: Id 256, PlayNow("E:\FSRAAS\06.wav") 218074 Sound: Id 256, PlayTheSound("E:\FSRAAS\06.wav") 218120 Sound: Ref 6, IPC: Status Response=1 219306 Sound: Ref 40, via IPC: Cmd=1, Wave="E:\FSRAAS\Left.wav" 219306 Sound: Id 255, PlayNow("E:\FSRAAS\Left.wav") 219306 Sound: Id 255, PlayTheSound("E:\FSRAAS\Left.wav") 219322 Sound: Ref 40, IPC: Status Response=1 219337 Sound: Id 256 DeActivate: sound not playing now ... 219337 Sound: Id 256 EndPlay: releasing buffer 219337 Sound: Id 0 EndPlay: all done! 219961 Sound: Id 255 DeActivate: sound not playing now ... 219961 Sound: Id 255 EndPlay: releasing buffer 219961 Sound: Id 0 EndPlay: all done! 241240 Sound: Ref 38, via IPC: Cmd=1, Wave="E:\FSRAAS\On Runway.wav" 241240 Sound: Id 256, PlayNow("E:\FSRAAS\On Runway.wav") 241240 Sound: Id 256, PlayTheSound("E:\FSRAAS\On Runway.wav") 241287 Sound: Ref 38, IPC: Status Response=1 242566 Sound: Id 256 DeActivate: sound not playing now ... 242566 Sound: Id 256 EndPlay: releasing buffer 242566 Sound: Id 0 EndPlay: all done! 242644 Sound: Ref 6, via IPC: Cmd=1, Wave="E:\FSRAAS\06.wav" 242644 Sound: Id 256, PlayNow("E:\FSRAAS\06.wav") 242644 Sound: Id 256, PlayTheSound("E:\FSRAAS\06.wav") 242659 Sound: Ref 6, IPC: Status Response=1 243845 Sound: Ref 40, via IPC: Cmd=1, Wave="E:\FSRAAS\Left.wav" 243845 Sound: Id 255, PlayNow("E:\FSRAAS\Left.wav") 243845 Sound: Id 255, PlayTheSound("E:\FSRAAS\Left.wav") 243861 Sound: Ref 40, IPC: Status Response=1 243861 Sound: Id 256 DeActivate: sound not playing now ... 243861 Sound: Id 256 EndPlay: releasing buffer 243861 Sound: Id 0 EndPlay: all done! 244469 Sound: Id 255 DeActivate: sound not playing now ... 244469 Sound: Id 255 EndPlay: releasing buffer 244469 Sound: Id 0 EndPlay: all done! 245311 Sound: Ref 54, via IPC: Cmd=1, Wave="E:\FSRAAS\Flaps.wav" 245311 Sound: Id 256, PlayNow("E:\FSRAAS\Flaps.wav") 245311 Sound: Id 256, PlayTheSound("E:\FSRAAS\Flaps.wav") 245343 Sound: Ref 54, IPC: Status Response=1 246528 Sound: Id 256 DeActivate: sound not playing now ... 246528 Sound: Id 256 EndPlay: releasing buffer 246528 Sound: Id 0 EndPlay: all done! 251021 Ready Flags: Ready-To-Fly=Y, In Menu=Y, In Dlg=Y 251021 Sim stopped: average frame rate for last 117 secs = 29.7 fps 261816 System time = 04/03/2014 15:54:19, Simulator time = 15:53:01 (15:53Z) 261816 *** FSUIPC log file being closed Average frame rate for running time of 170 secs = 28.2 fps G3D fix: Passes 13920, Null pointers 0, Bad pointers 0, Separate instances 0 Memory managed: 136 Allocs, 136 Freed ********* FSUIPC Log file closed *********** Hope this helps. I really don't think I can do any more. Maybe your two major problems are linked, maybe not. First off, though, I suggest you delete all your FSRAAS stuff, download version 2.0, just place its folder somewhere near FS (not on the desktop), and see how that goes. I would be wary of using the desktop for whole folders of programs. Folders of shortcuts, yes, but not programs and wave files. I do see that your "r4.cvs" file is really "r4.csv", and you should consider replacing that with a freshly generated one if you have any add-on airports. Pete
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.