Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Well if you have a way for me to correct it before mapping to the offset, let me know please. If it can be accurately derived from the other accelerations (which surely it must be?) then maybe that's what I should do? Though since it needs to be a frequently updated value I wouldn't want any resulting performance degradation. Regards Pete
  2. The Install log looks okay. Is there an FSUIPC4.LOG in the FSX Modules folder? If so, please show it to me. If not, then FSUIPC4 is not being loaded. Please paste in your DLL.XML file, which you will find here: C:\Users\Racklefratz\AppData\Roaming\Microsoft\FSX Regards Pete
  3. I understand that, but it's a bit odd pushing FORWARD for more REVERSE thrust -- certainly not like any real aircraft I think. You can do it pretty easily using a Lua plug-in. When you assign, in FSUIPC, an axis to a Lua plug-in the latter gets the axis value as a parameter ("ipcPARAM"). It can then use it as it likes. In this case you'd want to change it according to a flag. i.e. Leave it be or negate it. Then you'd send it on as the parameter for the relevant FS control (THROTTLEn_SET). The plug-in would also have to convert the normal Axis range -16384 to +16383 to the correct forward thrust range (0 to 16383) or negative range (0 to -4096 or less, for 25%). You also need a plug-in for each button, which toggles a global Lua variable (called, say "THRn_BUTTON"). [by "toggle" I mean sets its value to 1 - its previous value]. Then, in the plug-in for each throttle axis, in order to only change direction when the axis is at 'idle' (or close) you'd COPY the global "THRn_BUTTON" to another global, say "THRn_REVERSE", but only if the axis value is idle, or close (e.g < -16000). In the main part of the throttle axis plugins you'd test the latter global variable, THRn_REVERSE to see which range to convert the axis into before sending it on as the parameter to THROTTLEn_SET. Regards Pete
  4. It's no good to me, really. All I can do is provide what FSX gives me. If it is wrong, if it is a bug in FSX, then I would need some expert, maybe yourself, to give me the correction factor or formula. In the past I've tried to check what I am providing against the values saved in the FS FLT files. i.e. these, in the [simVars.0] section: PVelBodyAxis BVelBodyAxis HVelBodyAxis XVelBodyAxis YVelBodyAxis ZVelBodyAxis PAccBodyAxis BAccBodyAxis HAccBodyAxis XAccBodyAxis YAccBodyAxis ZAccBodyAxis PVelWorld BVelWorld HVelWorld XVelWorld YVelWorld ZVelWorld But FS doesn't appear to save instantaneous values for World-relative accelerations. I suppose with some spherical trig you could derive them from the saved values though and compare the result with the values SimConnect is providing me. Regards Pete
  5. No, that is not necessary -- unless the version of FSUIPC you were using was VERY old. (The oldest supported version for FS9 is 3.98). Regards Pete
  6. Hmm. There's something else interacting with it. First, could you please update to the currently supported version (4.60)? Your 4.53 is pretty old now and unsupportable. Please always check you are using the latest. Then try the interim update available in the Updates Announcement here in the Forum (4.627 at present). Assuming this doesn't help, it will be a process of elimination. Try stopping all other SimConnect applications which are being loaded initially (i.e. via the DLL.XML and EXE.XML files), makes sure FSUIPC+FSX then works okay, and then enable each of the others in turn. You can do all this by simply editing the XML files. If you aren't sure how, post them here and I'll explain (just paste them into a message). Probably, though I suppose it could have reset something in the trust mechanism which is now causing FSX to do multiple trust calls into Windows -- it is those which clash and cause the problem. It was a well known bug in FSX on release, and the SimConnect programmer in the FS team tried to solve it but only succeeded in lessening its chances of happening -- that was in SP1 or maybe SP2, so making sure your FSX is up to date would help too. Regards Pete
  7. FS does this sometimes when it is loading and checking multiple add-ons. It occurs before FSUIPC is even running. It's some sort of trust checking conflict. According to all the reports if you just tell it to carry on regardless then next time it's okay. It seems it can happen with any pair of SimConnect add-ons, not just with FSUIPC. Regards Pete
  8. Seems you unplugged it some time, and either plugged it into a different USB socket, or plugged something else in in the mean time which took the COM5 id? Yes, of course. Also SerialFP2 may or may not need to be told (again) to look at COM2, as that is the other side of the VSPE pair you've set up. But only do this if it comes up prompting you to find the device. Regards Pete
  9. Hmmm. Glad you sorted it so quickly. Seems strange, though, that this affected the Server's performance -- unless there's something accessing the culprit PC's disc from the Server, something accessing NETDIR perhaps? Otherwise you'd expect the programs running on that PC to suffer poorer performance, not somehow inflict it on another! Regards Pete
  10. Could it perhaps be different in different updates to FSX? Are you using RTM, SP1 or SP2/Accel? Maybe it was buggy and is now correct, or vice versa? Pete
  11. It doesn't. A single byte or even a single bit in a byte (along with 7 other switches) would have been more economical on space. But evidently Microsoft felt they had no need to be economical. It is probably a bit faster too to have everything in 32-bit variables when using a 32-bit machine. Also, if you are lazy when writing code in C or C++ (or most others too), then by default variables will take up the word-size specific to the compiler and target machine -- 32-bit compilers will compile "BOOL" (a boolean value, TRUE or FALSE, 1 or 0) into a 32-bit value and 64-bit compilers will use a 64-bit ("QWORD" or quad-word) value. Regards Pete
  12. Ah. Apologies! I missed the fact that you were referring ot the LuaToggle control, not the Lua one! Have you checked the FSUIPC log file? The most likely thing is that the Lua plug-in is failing to open the link to the device. If you've unplugged USB devices and re-connected them it is likely the COM ports have changed and the VSPE link is broken or the ports need reassigning in the FSUIPC INI file. i.e. the line: [VRInsight] 1=COM5,COM3 may no longer be referring to the device (COM5) and the port paired to the one the SerialFP2 program is using. The FSUIPC log file will contain any error reports from the plug-in. It is always the first place to look. Pete
  13. It's unknown to me. I don't know about others. For nearly all of the technical stuff in offsets I've always been dependent upon what other folks tell me. Because in FS9 and before folks said that dividing the value in 11BA by 625 gave good results, that's what I documented. In FSX and ESP SimConnect provides a variable called "G FORCE", and that is what I provide in offset 11BA, but to keep compatibility with FS9 and before, I multiply the value supplied by FSX by 625. So at least the FSX copy will be "accurate". If you can reproduce exactly the same G-force conditions in FS9 and FSX then comparing them should show how good the FS9 one is. It's ft/sec/sec, as documented, not m/sec/sec. The value there is from the SimConnect variable "ACCELERATION WORLD Y". I've been advised by others that is compares correctly to the same thing in FS9, so I'm not sure what you're getting. The Simconnect SDK states this variable is: "Acceleration relative to earch, in vertical direction, Feet per second squared" (including the typo in Earth). Regards Pete
  14. Sounds very much like you have it assigned in more than one place. Either that or you have two axes assigned to the elevator (perhaps one not even connected) and this is causing cross-interference. Check both FS and FSUIPC assignments. This line in your INI file shows you have left the Elevator calibration completely to default values, as these are FSUIPC defaults: Elevator=-16380,-512,512,16380 Why not try calibrating, as documented, and see if that helps? You only showed me the JoystickCalibration section of your INI, so does that mean you aren't even assigning any axes in FSUIPC? (They would be in the Axes section). If not then all of your problems will be found somewhere in the FS assignments. Regards Pete
  15. That Lua plug-in is designed to be run automatically from the parameters in the INI file. If you then re-run it like that you kill the properly running version and the new one starts without having the correct parameters. If you looked in your FSUIPC Log you'd probably see the error reports it gives you! Yes, and here are the sections which run the VRI_SetBaro plug in for you: [VRInsight] 1=COM5,COM3 [VRInsight.MPanl] Lua=VRI_SetBaro DriverWrites=Filter WrFilter.1=BAR? DriverReads=Filter RdFilter.1=BAR?+ Please do read the instructions and follow them. Do NOT assign a key to that plug-in unless you've edited it to put in the correct COM ports and are doing it that way to test some changes. Regards Pete
  16. Hmm. In that case I've really no idea what is going on. I supect it must be something to do with normal file access over the network, because the Logs show everything is fine. What does that mean? And can I do something here? It means only what I said -- that overall the programs on that PC are sending commands to FS at a fairly frequent rate, as I say -- 77 (max) 33 (average) per second. It just seems rather high to me. However, it is probably just the communications between the PM components via their shared FSUIPC offsets, in which case it shouldn't affect FS performance. Have you tried with both of them not running to see if you get the slow down effect on FS? They show things are even better than the last, and even the transmission rates from the "suspect" PC look better: So, sorry, I can see nothing wrong at all in the operation of WideFS on your system. Assuming you find no difference when not running pmGetWeather and SA_WXR, then whatever is slowing FS is related somehow to what your CDU or pmSystems is asking of it. Maybe something conflicting with the aircraft you are using? Regards Pete
  17. Sorry, do you mean that without both CDU and pmSystems, all is well, but with either (or both?) it is not. Looking at the NEW log you supplied: The system performance seems okay -- averaging 30 frames/sec at this client. I do find the maximum and average transmission rates quite high though77 and 33 respectively. Additionally you have two more Client applications on there than you mentioned: pmGetWeather and SA_WXR. I'm pretty sure they shouldn't both be used -- one or the other, surely? SA_WXR seems to be making a large number of requests itself. Strange. It seems quite quiet on my system (I'm using SA_WXR but not pmGetWeather). Try without both of those, see how it goes. The explanation is documented. Each time they are restarted they save the previous log (the one with the .0) before creating a new one. That way we can find problems without messing about stopping everything -- a restart doesn't lose the valuable data. Apart from WideFS activity, could it be some sort of disk access? Have you de-fragmented your main FS disk recently? Does the disk activity light come on a lot? The OLD logs show nothing different from the NEW logs. All seems okay internally to FS and WideFS. I suspect it's some other activity going on in your FS PC, though why it should be caused by one of those programs you have running on that specific client I don't know. Where do you have the CDU's common folder (NETDIR, I think?), which SA_WXR and pmGetWeather and other parts of PM access? It should be on the same PC as the CDU for efficiency. If it is on the FS PC it may well be affecting performance, especially with both pmGetWeather and SA_WXR competing to provide the bitmap for the ND, which isn't a trivial file in itself. Regards Pete
  18. You shouldn't even need to do that provided both PCs are in the same WorkGroup. For many years now the Server has sent out identification messages so that the Client can find it automatically. If it is not showing, then WideServer is not running. Did you remember to put WideServer.DLL into the FS Modules folder? It seems significant that you show the Client log and the FSUIPC log, but no WideServer log!? Regards Pete
  19. Sorry, I've no idea either. The first thing you should always do is check the Log files -- they tell you what is happening and may indicate some disconnection/reconnection problem with that PC. Look at the WideServer and FSUIPC logs in the FS Modules folder, and in the WideClient log in the WideClient folder on the client PC. Have you tried a process of elimination -- having WideClient connecting on PC6 but with no applications running? If that "solves" it, try running the others (PM CDU, PM MCP, pmSystems) each on their own, see which is causing a problem. Such behaviour cannot be caused by WideFS reading data from FS, as all data requested by clients is only sent out when it changes, and the change rate is dictated by the frame rate. However, it could happen if a program is writing some critical changes to FS very frequently, and FS has some problem keeping up. If changing what is running on that PC has no effect and you still get the problem, then it may well be down to something going wrong with the connection. The logs should show if this is the case. Pete
  20. The sorted list of the AirbusX L:Vars i attached to another thread near here contains these TCAS related variables: L:ASC_TCAS_ClearOfConflict L:ASC_TCAS_ClimbClimb L:ASC_TCAS_ClimbClimbNow L:ASC_TCAS_DecentDescent L:ASC_TCAS_DecentDescentNow L:ASC_TCAS_SystemTestOk L:ASC_TCAS_TRAFFICTRAFFIC L:TCAS_Mode L:TCAS_Mssg_Trigger I should imagine the emboldened one is relevant, but without using the L:Var logging whilst operating the selector I couldn't say what values it takes. I attach another copy of the complete list. Regards Pete AirbusX Lvars.zip
  21. That is only true if you want to use different controllers for different aircraft. If all you want are different calibrations, response slopes and other settings for different aircraft then you can still assign the controllers in FS and simply calibrate and make settings in FSUIPC. In the title you gave to this thread you specifically said "throttles" yet in the text you seem to imply all controls -- elevator, aileron, rudder? Which is true? Also in the title you said "sometimes" yet again in the text you imply that it is always the case. Can you clarify these issues please. Different symptoms would lead to different conclusions. Is this with only specific add-on aircraft, or all including defaults? I've never heard of any such symptom at all asnd FSUIPC has been in use for things like this for 12 years now. Evidently a lot more information is needed: 1. Version number of FSUIPC4 (if not at least 4.60 then please update and re-test before replying). 2. Update state of FSX 3. Your FSUIPC4.INI file 4. The identity of the aircraft concerned. It sounds to me as if these problems are related to very specific add-on aircraft which may be reading the controls themselves in any case, so how you actually assign them becomes critical. Apart from assignment in FSX itself (which is the easiest way and which you shouldn't have abandoned so lightly), there are several ways of assigning in FSUIPC4 -- direct to calibration, or via FS controls. If you assign direct to FS, bypassing the FS controls, you can defeat the inputs which some (but very few) add-on aircraft expect. The answer for them, if you must assign in FSUIPC, is to assign to the correct FS controls. Regards Pete
  22. Have you tried to uninstall and re-install FSX or moving it about? Because something has messed up your FSX SimConnect installation quite severely, and attempting reinstalls seems to be one of the more common causes.. It appears that: (a) you've installed the SP1 update for FSX, but not the SP2 or Acceleration updates, and (b) the side-by-side installation of SP1's SimConnect appears to me corrupted somehow, and the original default SimConnect is not compatible with the updated main program. Hence the "version mismatch", which is being reported by FSX (and only relayed by FSUIPC). You could try two easy things: 1. Try installing the FSX SP2 update. I'd strongly advise this in any case as it fixed lots of FSX problems, and / or 2. Try the interim FSUIPC4 update (4.627 or later) available in the Updates announcement in this Forum. It has a slightly different way of attaching to SimConnect which might (or might not) work. Please let me know what happens either way. Note that even if #2 works, it is a work-around and it might not help other SimConnect client programs. If neither of these work then I'm afraid it gets a bit desperate. You could try a complete uninstall and re-install, but I think this doesn't fix Side-by-Side library problems, and this is what you have. The only alternatives then are either a roll-back to an earlier Windows restore point, if you have one, or a complete Windows reinstall. Regards Pete
  23. For a button operation the only choice is the THROTTLE DECR control. You should reduce thrust to idle first, then have the button repeatedly send THROTTLE DECR (for all engines) or THROTTLEn DECR for n=1 to 4, separate engines. THROTTLE DECR is the control FS assigns by default to the F2 key. Pete
  24. That's okay. Hope you find more interesting things to do too! ;-) Pete
  25. If the laptop is a WideFS client, then it only needs one installation of WideClient no matter what version of FS is running in the Server PC (from FS98 onwards). Both WideClient and WideServer produce log files which tell you (or me) what is going on. The Client log is in the same folder as the WideClient.exe, the server log is in the FS Modules folder. show me those. I also need to know the VERSION numbers of FSUIPC3 and 4 being used. If these aren't at least 3.98 and 4.60 then please do an update and try again. No. 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.