Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. No. Not if you don't know if you need it. Why should it? That's just a download site. The explanation is in the User Guide which is installed for free when you download and install for free. You never have needed to register it to read it's why's and wherefore's! Pete
  2. Yes exactly. And it worked with the hardware VRInsight provided at that time. Provided you followed the instructions exactly. BUT the radio stack also worked with just SerialFP2. FSUIPC was only needed if you wanted to use non-standard assignments. Yes, of course. As I've said several times before, that port IS where youre radio stack is! You'll see that the entry in Device Manager will go if yo unplug the device! That tells you it is connected to COM3, which is what you need to know to use it! No, actually, VSPE needs two different ports. Sorry if i confused you earlier. It is now all coming back to me. (It was years agao and I am 74. I should have retired vback then). FSUIPC needs to be told COM3 as the first. VSPE links COMx to COMy, two other COM ports which are free. The second port in FSUIPC is COMx, and SerialFFP2 is assigned to COMy. I'm sure the documentation you keep referring to says as much. Let me look: Yes, it says: After installing it and registering it (you have to cut and paste the long key!), proceed as follows: 1. From the Device menu, select Create. 2. In the Device Type drop-down, select Pair, then press Next and Finish. 3. Repeat steps 1 and 2 for the number of VRI devices you want to connect this way. 4. Note down the pairs made. For example: COM5 <-> COM6 COM7 <-> COM8 then later on, for editing FSUIPC4.INI it says: As an example, supposing I have one VRI device on COM3 and another on COM9. With my two pairs as set in the example on the previous page I could have: 1=COM3, COM6 2=COM9, COM8 Note here that COM3 and COM9 are NOT part of the VSPE pairs at all. They are the real devices, just like your COM3 for your device.Then, as it goes on to say, SerialFP2 should find these two devices on COM5 and COM7, the other end of the pairs linked by VSPE. All this is what is written. you've not followed what is written despite saying you had. I'm sorry I didn't check, but i believed you! This is NOT "COMMs" it is simple logic. Look at the later section where it shows the links: SerialFP2 <-> COM5 <-> COM6 <-> FSUIPC <-> COM3 <-> VRI Device1 SerialFP2 <-> COM7 <-> COM8 <-> FSUIPC <-> COM9 <-> VRI Device2 See? There are 3 "COM" numbers involved for each device, to get the flow of data as it sohwns. Pete
  3. I read don't read anything about a "deal price", nor an upgrade price, just an early buyers discount for the first three months. I'm sure i said that. If you've paid for it how can you be made to pay more later? You seem to be making a simple thing veryt complicated. Pete
  4. Okay. The MFD devices return 4 entries each, two of which have good values, though no response to normal Joystick reads. I think those need a driver. Are these your MCPs, or do you really actually mean "MCP" not "MFD"? Because no devices calling themselved Joystick types register. Where's the HidScanner log file? Pete
  5. Sorry, I don't think so. The facility is very much bound into the way FSX works. Pete
  6. As I said, and as is made clear in the documnetation, WideServer is part of FSUIPC And in any case why should it be in the Add-Ons menu? Pete
  7. What exactly do yo mean by "I choose to run WideFS". What exactly do you think you are running? WideServer is part of FSUIPC, and if you registered it in the FSUIPC installation process it will be running in any case -- unless you opted to stop it in the About tab in the FSUIPC Options after FSX starts. There's nothing else to run "along with FS". The other part of WideFS, the WideClient program runs on your client PCs, across your Network. Pete
  8. Blimey, on some foreign site. I can't find it on the English language site. And it shows €28.80 not €24, at least till the end of August. The discount is an "early buyers" one, not a "existing users" one. It's more straight forward. FSUIPC5 is not ready yet. Not sure when it will be, but was hoping to get it finished sufficiently this week. It will need further developments. Pete
  9. What "demo" version? FSUIP5 is not rready or released yet. Do you have a link to your findings? I can't find any reference. What are SimMarket doing? I've not seen any announcement there yet. I'll have to write to them. Pete
  10. There's no change in WideFS. Existing registrations will be fine. Version 7 was the version released with FSUIPC4 in 2006. The nmuber will keep pace with FSUIPC because the Server is part of FSUIPC, but the Client program is the same for all versions of FSUIPC and FS/P3D. Pete
  11. Is it listed already? Surely not. It isn't ready yet! Do you have a link? Pete
  12. This indicates a crash when calling DirectInput to "release" joystick ID 0. I suspect it is only 0 because that's the first. For some reason it doesn't like free up the joysticks before termination, which is rather odd. I can try removing that which may fix the crash on termination, but I'd be worried about what then happens if the joysticks are scanned again when one of them is reconnected, or you enter one of the joystick tabs in the options (FSUIPC rescns then too, to make sure its up to date for assignments. I'll experiment here. Wow! I'm away from the 15th to the 20th. I'll work on it anyway. Do look for a later version on your return. Pete
  13. Well, I've found the difference, but it wasn't between 4.964 and 4.966c, but from 4.959. I don't know why it worked for you in 4.964. It's a entry in a large table which got changed "WROK" to only "WR". And only for 3102. the equivalent 281C was still WROK, even for the same SimVar! It was a problem that "WROK" wa no good in P3DV2 and later (though its okay in P3D4). i've been concentrating on P3D so much in the last weeks that I didn't notice it was going to be wrong for FSX. Very naughty of me, there's so much to re-test even on minor changes. Sorry. It'll be okay in 4.967. Pete
  14. There's no "center brake" axis in FS. All you need to do, since you have a spare axis, is assign it to bother Left Brke and Right Brake in the same assignment tab. You can assign up to 4 thinmgs to the one axis. that's why there are 4 slots, if you look. What I was saying was how impossible it it to do that as well as left and right with one axis! Oh dear. We go back a few messages now. Since, you say, LT and RT are ONE AXIS there's only ONE VALUE, -16384 to +16384, depending which side you pressed. One axis input CANNOT GIVE TWO DIFFERENT VALUES AT THE SAME TIME!!! So how can anything detect both pressed as the sme time? It there were two separate axes there'd be no problem in the first place! Pete
  15. Yes, and you CAN handle that in FSUIPC but maybe not by a simple assignment, even with a bit of filddling at the end of the assignment line. The easiest way is via a simple Lua plug-in, to receive the values, test the sign, and send (after negation for the LT one) to either left or right brake. But you STILL cannot get both brakes together, which was your original problem. How would YOU propose using those both for separate and both brakes together. what signals to the PC that 'both' is what you want - because in order for RT to got towards 16384, LT would reduce to 0. Do you see the problem now? I don't see how it is possible with one axis to know your intention. it cannot read your mind. Pete
  16. No, you misunderstand. The button would only indicate that you were switching the axis from accelerator to brake or vice versa, and to hold the other setting. The pic you've posted looks very much like my Microsoft SideWinder which I use occasionally for assorted tests, However, the buttons on the front, which you've labelled brakes, are buttons, not a single axis -- you are saying both buttons are the same axis with variable values being input! I am certainly not understanding muchof any of this. You tell me you have one axis. But show two separate brakes. The "Z axis" label is presumable that white knob with the cross on it? I think you might be in the wrong place. You need a forum dealing with that device. Once you understand what it is doing then maybe you can program it to do what you want? Pete
  17. Maybe when you press one side or the other it also presses a button. Have you checked? You could make it work with a button detected. But it would need to be a Lua plug-in programmed to handle it. What do you use for a rudder if you are using what it effectively a rudder pedal arrangement for brakes only? Surely a rudder is more inportant? for brakes it's just as easy to use one or two buttons. Pete
  18. Seems very unlikely. From what DTG are saying FSUIPC will be impossible. Though if they've implemented SimConnect properly I don't see why. They've deliberately snubbed be over this despite my full cooperation and bug reporting for all the FSX-SE betas. I think they don't like it that FSUIPC is not being made available for them to supply via Steam. Currently i'm not interested in any case, but i might review this in due course. Far too much to do on other fronts at present, especially P3D4. Pete
  19. Enable button and event logging (both event options) and press the button more than once. then disable those logging options before the log gets too large. Let me see the resulting log. One thing does occur to me. If you aren't using the same axis at all for anything else, then the sim is not seeing any change on the axis -- setting value x then setting value x is no change. Instead try assigning "press" to x+y and "release" to x where you might need to experiment with 'y' in order to make it see it as a real change, but not have any "blip" effect in the sim. If you are assigning through FSUIPC, set the "Delta" to 1 then make y = 2, say. If you stil have the same problem then enable button and event logging (both event options) and press the button more than once. then disable those logging options before the log gets too large. Let me see the resulting log. Pete
  20. You can press it both ways together? I'm now confused. Is it two pedals or one bendy one? If there's only one axis input, vaying from say -16384 to +16383, the standard range, with 0 in the middle, how are you maipulating it to get to the +16383 side without it changing from -16384 and through zero? How does your driving thing know that you are going to press the brake when you have the accelerator pressed, or vice versa? I used to do F1 racing on a sim using two pedals, one accelerator and the other brake. The pedals had a "rudder" option which effectively linked the two so you couldn't try to make the rudder go two ways at the same time. Is yours like that? If so, use the switch to separate the pedals if you want separate braking. Pete
  21. And your picture shows it as Joy# 7! As in my previous reply, the log shows it as device #1. So something changed between your last submission and this. In fact several things, judging by your INI: [JoyNames] AutoAssignLetters=No 3=USB Controller 3.GUID={848199F0-C162-11E5-8001-444553540000} 4=Button Box Interface 4.GUID={8EE7B440-C938-11E6-8001-444553540000} 5=BU0836X_1 5.GUID={CE02BA90-7BF8-11E6-8001-444553540000} 1=Pro Flight Yoke 1.GUID={56E55BC0-41B4-11E7-8001-444553540000} 6=Mad Catz Pro Flight Rudder Pedals 6.GUID={56E55BC0-41B4-11E7-8002-444553540000} 7=USBAXES-PLUS V2 7.GUID={37E9E100-17C5-11E7-8001-444553540000} So, the Yoke has moved from 0 to 1, the Pedals from 2 to 6, and the tiller to 7! Have you beed unplugging them and reconnecting them? I can't think of any other reason for them to jump around like this. I see you aren't using JoyLetters, which means all your assignments t devices which move about are going to get scrambled. If I were you I'f mmediately start using letters. See the chapter on this in the User Guide. Otherwise, you look set now? You'll need to change the numbers back manually in the list in the INI and duplicate the lines with appropriate letters. Here, I've done an example for you: 0=Pro Flight Yoke 0.GUID={56E55BC0-41B4-11E7-8001-444553540000} 2=Mad Catz Pro Flight Rudder Pedals 2.GUID={56E55BC0-41B4-11E7-8002-444553540000} 3=USB Controller 3.GUID={848199F0-C162-11E5-8001-444553540000} 4=Button Box Interface 4.GUID={8EE7B440-C938-11E6-8001-444553540000} 5=BU0836X_1 5.GUID={CE02BA90-7BF8-11E6-8001-444553540000} 7=USBAXES-PLUS V2 7.GUID={37E9E100-17C5-11E7-8001-444553540000} Y=Pro Flight Yoke Y.GUID={56E55BC0-41B4-11E7-8001-444553540000} R=Mad Catz Pro Flight Rudder Pedals R.GUID={56E55BC0-41B4-11E7-8002-444553540000} C=USB Controller C.GUID={848199F0-C162-11E5-8001-444553540000} B=Button Box Interface B.GUID={8EE7B440-C938-11E6-8001-444553540000} A=BU0836X_1 A.GUID={CE02BA90-7BF8-11E6-8001-444553540000} T=USBAXES-PLUS V2 T.GUID={37E9E100-17C5-11E7-8001-444553540000} The ones I don't know I've lettered A, B, C. Change them it you wish. I note now that you have weird axis assignments: 0=0X,256,D,36,0,0,0 -{ DIRECT: SteeringTiller }- 1=0Z,256,D,22,0,0,0 -{ DIRECT: Spoilers }- 2=1X,256,D,36,0,0,0 -{ DIRECT: SteeringTiller }- 3=1Y,256,D,36,0,0,0 -{ DIRECT: SteeringTiller }- 4=2Y,256,D,8,0,0,0 -{ DIRECT: RightBrake }- 5=2R,256,D,3,0,0,0 -{ DIRECT: Rudder }- 6=5X,256,D,36,0,0,0 -{ DIRECT: SteeringTiller }- 7=7X,256,D,36,0,0,0 -{ DIRECT: SteeringTiller }- Delete all the Tiller lines which are wrong. And use the letters, so: Check this. Not sure where your Spoilers and Throttle are. On the Yoke? Only right brake, no left? No aileron or elevator? 1=YZ,256,D,22,0,0,0 -{ DIRECT: Spoilers }- 2=RY,256,D,8,0,0,0 -{ DIRECT: RightBrake }- 3=RR,256,D,3,0,0,0 -{ DIRECT: Rudder }- 4=TX,256,D,36,0,0,0 -{ DIRECT: SteeringTiller }- Or maybe you are better off starting from scratch -- delete the assignments and start again? I notice you have no default generic assignments at all, only profiles. You are much betteroff doing all your standard assignments with no profile selected, with a default aircraft. THEN make the profiles which only then need to contain those things which are different. Much easdier, shorter, and easier to maintain. For buttons, profiles ones override general ones. For axes you can opt to "base" the profile on the general ones, so they get copied first, THEN make your changes. Pete
  22. Ah, sorry. Should have checked. It's just that the problem you have was a bug in P3D2 and now I find P3D3, but I've now found it is okay in P3D4 so they finally fixed it. It has never been a problem with FX or FSX-SE, so I'm puzzled. I CAN make the "P3D" fiddles work across the board but I'm rather concerned why it is necessary and why it appears different between 4.964 and 4.966c when there's certainly been no changes which could affect that area. I've not really got time for a while to investigate this further so I'll just do the "fiddle" for the 4.967 release, by the end of this week. Pete
  23. That just has to be down to a crash on a previous closedown. You need to re-run the installer then, without running FS, copy in the updated copy. The ONLY change between 4.966n and 4.966p is the longging of crashes when releasing the devices at the end of the session. I am now thinking that if this isn't down to joystick drivers, your FSX installation is corrupted. There have been a number of cases where a complete re-install was the answer. You say: but that cannot be true. You are using FSX-SE and reinstalling that is easy andvquick. You can start with only reinstalling FSX-SE, not all of your add-ons. Just leave them where theyare. Maybe save the ProgramData and AppData/Roaming files for FSX-SE (I always make a copy of those in any case, right after installation). I have around 600 scenery layers and a similar number of DLL and EXE add-ons to you, plus a load of stuff to do with a hardware 737 cockpit, ad all this for both FSX-SE and P3D3 (and now 4) and a complete reinstall, on a new PC with a virgin Windows 7, took me less than three days recently. Pete
  24. That's actually the strangest thing, because exiting a flight really isn't something which provokes any action in FSUIPC. It's barely detected, only as a "STOP" event from SimConnect, which is optionally logged. Also, you said the crash on exit now occurs in 4.966c -- so what's changed? And 4.966c is in use on thousands of users systems. I'd have surely heard a lot more if it were an FSUIPC bug. It would be useful to know what happened on yur system to change a program's behaviour like that. Apart from corruption on disk on hardware deterioration or other changes can do that. 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.