Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Very strange. FSUIPC can't invent those values by itself. It merely records the size it finds, when the Window is displayed. Are you loading a flight which was saved a previous time that the window was like that? I think the sim saves them too. Or maybe even in the main CFG file. I''ll be releasing an interim update either tomorrow or Monday which will, by default, not alter these windows. Meanwhile, can you just try changing it your self -- stretch it, drag it, to whatever position or size you need. Let me know what happens then, please, and show me the [Window ... section of the INI afterwards. Are you running the sim in Windowed mode? If so can you try full screen? (ALT+ENTER). Pete
  2. Ah, now it is clearer. The elevated session appears not to receive broadcasts, so it doesn't know the name of IP addressof the Server. See, the successful connection in the "regular" log: 156 Attempting to connect now 156 Trying to locate server: Need details from Server Broadcast 156 Failed to connect: waiting to try again 1172 Attempting to connect now 2188 Server = LUCAPC 2203 Trying TCP/IP host "LUCAPC" port 8002 ... 2203 ... Okay, IP Address = 192.168.1.10 2203 Connection made okay! compared with this for the elevated log: 156 Attempting to connect now 188 Trying to locate server: Protocol not yet decided 188 Failed to connect: waiting to try again 1219 Attempting to connect now 22531 Trying to locate server: Protocol not yet decided Try putting the ServerIPAddr parameter into the WideClient.INI file, and Protocol=TCP or UDP, as you wish. This is the first thing to try when connections aren't being made -- it is documented in the WideFS User Guide, in the part imploring readers to read at least part of it! Pete
  3. You might be ble to do it using a Lua plug-in, using the mouse facilities there. But, no, whilst there are controls to view different panels, and of course cameras, there seems to be nothing for selecting specific views when you have more than one open. Pete
  4. There's no separate "WideFS server", it is part of FSUIPC. The number 7.971 just indicates it is running in FSUIPC5 but is at the same level and FSUIPC 4's 4.971 version. When you have a communication problem betwen Server and Client you should provide the loags -- wideserver.log and wideclient.log. Nothing to do with network exchanges should be affected by process privilage levels. How is it producing data if it isn't receiving any? It only pases on what it receives. I have never needed to run WideClient in elevated privilage mode for any application, so something is odd in that Client system somewhere. VSPE presents a virtual port, which is at system level, nothing user or admin level at all, so those are really irrelevant. Pete
  5. The INI shows only one set of brakes: 9=CU,256,D,7,0,0,0 -{ DIRECT: LeftBrake }- 10=CV,256,D,8,0,0,0 -{ DIRECT: RightBrake }- So where are your "First Officer" brakes asigned? You need similar or identical hardware for good dual controls. Otherwise you'll either need to settle for the best compromise between the two OR do some manipulation of the ranges in the assignment lines, using airthmetic, before calibration. See "Additional parameters to scale input axis values" on page 46 of the Advanced User's manual. Anyway, you only have one set of pedals assigned. two yokes however. Why are you submitting a different problem now and then, one at a time? Does a subsequent one replace all previous ones? Pete
  6. Your logs all relate to an old version of FSUIPC, 4.965, which I really cannot support. Please, before posting ANY support request, do check that you are using an up-to-date supported version. At present the earliest supported version is 4.971. See the Download Links subforum, Updated Modules thread for details. Then, assuming you update: Again, with no information I cannot possibly forulate a useful "idea". At least the INI file is needed. Pete
  7. Oh sorry. misprint. Yes, 5.121b is the latest and thev supported version. If it isn't working with 5.121b I'll need more information please, like those Windows sections. Pete
  8. Why does PMDG say that? FSUIPC doesn't touch rudder or steering or have anything to do with it unless you tell it to. Teere's a known problem between A2A and PMDG aircraft, and possibly others, and P3D4.1 -- problems which can be aggravated by EZDOK or any other method of controlling rudder and steering. A2A have already changed their aircraft. L-M have already confessed to a change in 4.1 which does this. Please, PMDG, do your research more carefully in future. It is an easy to simply blame FSUIPC for everything, even though it is very rarely the case. It is just laziness by their support. If simply moving the FSUIPC.INI file out "solves" the problem, then the problem is apparently in the FSUIPC settings, because that is what the INI file contains! It is reltaed to what FSUIPC is being told to do! FSUIPC is just the passive vehicle acting on user's requests and settings. Pete
  9. I don't know what all of the P3D/FSX controls do -- are such actions assignable at all in FSX/P3D assignments at all? If not then probably there is no way other than mouse. I think I've always used the "S" method (or rather its generated control) to cycle through standard views, but I don't know if that works with created views. Possible these controls may help (found in the List of controls in your FSUIPC Documents folder. VIEW_AUX_00 VIEW_AUX_01 VIEW_AUX_02 VIEW_AUX_03 VIEW_AUX_04 VIEW_AUX_05 Pete
  10. There's no "function" field. Do you mean the two alternative Buttons & Switches assignments sections? Are you selecting "Select for Key Press" or "Select for FS control"? Whichever you select, the other will stay grayed out. Is your pressed button correctly shown at the top? Assignment facilities are also grayed out (both sides) if there are already multiple assignments to the same button. For handling multiple assignments you need to edit the INI file, as described in the Advanced User's manual. Please alsways state which version (the number please) of FSUIPC you are using. Pete
  11. Weren't you using FSUIPC before with P3D4.0, because it hasn't changed. It sets the window size and position to the way you set it, and this is recorded in the FSUIPC5 INI file. Several Simconnect Windows are remembered, so that you can move them where you wish and size them and have them return the same next time. This facility was documented in the Changes document, thus: 13. SimConnect Window positions (including Menus) are saved in the INI file and (normally) restored. and 20. Version 5.121 quickly followed the release of 5.1 2 to fix a serious bug involving incorrect cursor movements and Window sizes If you aren't using the currently supported version of FSUIPC (5.121a) please upgrade now! Otherwise, if you are on 5.121a, Isn't it working correctly for you? Have you tried resizing / repositioning the window to suit your needs? Alternatively you can delete the [Window ...] sections you'll find in the INI, so that they revert to default next time. I might make this feature optional, enabled by an INI file. it seems to work fine for many, but not for one or two. I'd like to get to the bottom of this, really. Pete
  12. Oh, I see. No, I think it is used to mean "please pay this attention, I feel I'm being ignored", from "bump it to the head of the queue". Use "Please delete" next time please. I'll delete this thread this after noon after I'm sure you've read this. Meanwhile I did answer your main thread, requesting information really. Pete
  13. I need the log and the INI file, and the joyscan CSV file. And make sure you are using a currently supported version (of FSUIPC -- 4.971 for P3D3). Does P3D3 see those devices? I cannot help with virtually zero information. Sorry. Do supply a driver? if the device(s) are normal jotstick type devices you probably shouldn't be using it if so. I see you are the person who posted another thread here just rudely saying "bump"? Please do not do such things. It wont be taken kindly. if it was meant to attract faster attention, it didn't work. You only started this thread 3 hours ago! How fast do you expect a response? With most support sites you'd be lucky to get one the same day. I only caught it now because i tend to do a quick scan befor going to bed -- it is gone midnight here! And I won't be around much tomorrow. Many other things to attend to! Pete
  14. Pardon? Why start a new thread in such an odd way? Pete
  15. Do you mean this one? Attempt to set the ACL entries for Modules access permissions failed, error = 1332 Error 1332 is documented as meaning "No mapping between account names and security IDs was done.", whatever that means. So my questions would be: 1. Did you run the installer "as administrator" as instructed? 2. Was the end result effective? i.e are there FSUIPC5.INI and FSUIPC5.LOG files in the Modules folder? 3. What does the Security tab in the modules folder properties show? Is "Everyone" included as a user name, and if so, when selected, are there ticks below against "Full control" and "Modify"? Pete
  16. I just scanned the L-M support forum, and there are complaints about loss of sterring in other aircraft, like the A2A ones. L-M have found a bug in version 4.1 which may account for it. You ought to go check. Pete
  17. Does it work on other aircraft, particularly default? Have you got the latest P3D4 version of the PMDG 737NGX. I believe it has been updated a few times. If the rudder command is going to the aircraft (does it operate the rudder as well as the nose wheel?), the there's really nothing wrong with the assignment, whether you are using FSUIPC or not. Certainly FSUIPC cannot interfere at all. The other places to ask folks are the AVSIM P3D forum, the PMDG forums, and the L-M support forum. Pete
  18. Rotary controls are much easier to program / assign. Potentiometers are only really good for axis-type controls, and I doubt the the PMDG controls (assuming they exist?) are such. They are more likely to be simply "inc" and "dec" types (or maybe one control with the inc or dec indication as parameter) But you should check first. I think those PMDG panel controls where you right- or left-click the mouse to increase or decrease use controls with paramters effectively giving the mouse parameter value for INC and DEC. I'm afraid I don't have or use any PMDG aircraft myself. Pete
  19. I don't know what they can fix. Either they save the data so the aircraft can resume exacty correctly if you need to load the saved fight, or they don't. If they didn't then presumably when you reload the flight you'd have a lot of setting up to do first, some of which may not even be possible when in the air. But by all means ask in the PMDG support forums. PMDG are particularly afflicted by this because of the detail of their simulations. There will be others with similar problems, like, probably, FSL and one or two of the Aerosoft offerings. Simpler aircraft don't have so much data to collect and save. Pete
  20. There are no offsets to control anything in PMDG aircraft. Offsets relate to the sims own systems and values. PMDG aircraft use "custom controls" (their own series of control numbers (or "events"), and these are listed in the.h document in their aircraft's SDK subfolder. You can assign custom controls in FSUIPC. Just use the <custom control> selection and enter the number of that control. Pete
  21. The delay is not caused by FSUIPC or the sim itself, as the autosave call is simply the standard "save flight" call you can make normally in the menus. It is caused by aircraft such as (especially) the PMDG series, which freeze the sim whilst collecting al the systems data for their aircraft for saving too, in their own files. And the only way to avoid that is not to use such aircraft, or not use autosave. Pete
  22. What functions are you using to read the data? For com.read, data read is just stored in a buffer, which certainly isn't severely limited. The event merely signals there's something received. so you should loop reading until there's no more! Yes, there's only one flag which triggers the call back no matter how much is in the buffer. And more can accumulate whilst you are in the function. Yes, which is exactly what it is for. It assumes you only want the latest, and deletes the earlier stuff. This is usefulwhen you just want the current state of things, not a history of events like multiple increments or decrements. The reading of data arriving is completely asynchronous with everything else, in a separate thread. What you are describing is expected results of this implementation, which is the only way to do it without freezing things waiting. That way your data would certainly be lost. BTW the usual way, and one I've always implemtned in things like radio stacks (I did the drivers for FlightLink gear in the early days, and PFC more recently), is to accumulate increments and decrements when they are occurring withing 200-300 mSecs of each other and send them as batch commands, like "inc by x" rather than just "inc". Send one batch at most every half second. Fast enough to make the results visually work, but not so fast that the sim clogs up. Pete
  23. I see you did make a post in User Contributions. Thank you! Pete
  24. That's very ingenious! Well done! Would you care to post that in the User Contributions subforum, using an appropriately descriptive title? That way it is preserved where folks can find it instead of scrolling off (as this thread will). Thanks! Pete
  25. The "0" keycode is 48 (as listed in the Advanced User guide), so in your 20= assignment, the 0 is the 48. The 8 just means "on its own, no shift, CTRL, ALT or TAB added". All this is in the Advanced Users guide, which is provided for your reference on things like this. 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.