Jump to content
The simFlight Network Forums

rcbarend

Members
  • Posts

    44
  • Joined

  • Last visited

Everything posted by rcbarend

  1. Hi Pete, I see in FSUIPC 4.0 you no longer check a gauge name against the embedded key in a freeware gauge. Does this mean your policy has changed ?? I.o.w. : 1. Does a freeware gauge still need a key to allow non-registered FSUIPC users to run the gauge in FSX ? And if so: 2. We have a gauge for FS9 (with freeware key), but we want to release a modified version for FSX , but under a different name to avoid mixup with the FS9-version. Do we have to apply for a new key or not ?? Best regards, Rob Barendregt
  2. Thanks Pete ! And Yes, as you are painfully aware yourself :lol: , there will always be users that succeed in not properly reading/executing usage/instalation instructions (or don't read them at all :cry: ). Best regards, Rob
  3. Hi Pete, First of all, my best wishes for 2006 !! As Doug said above, this RCBco-20.zip package is specifically for FS2004 and did contain FSUIPC V3.44 (not Read-only). So the original poster must have gotten his very old version somewhere else. About the inclusion of FSUIPC in my freeware package(s): It has become a habit of mine, when I release a package that requires FSUIPC, to include the (at that time) latest version of FSUIPC.dll, just for user convinience. Of course with all credits to you, and an instruction for the user that they never should overwrite a never version they might have, and a statement where they can download the latest version if needed. This "habit" comes from the FS2002 days (V2.**) a few years back, when I did ask your permission include FSUIPC in another freeware package I created (which you gave). Now, if you want me to stop including FSUIPC, or ask your permission on a per-upload basis, of course I'll respect that. Just let me know your position on that .... Best regards, Rob Barendregt
  4. You are probably right about that. In fact the only reason I noticed it, was because I made a Brake Pressure gauge for FS2002 and (during testing) found this peculiar behaviour. But never bothered to give it a followup, since I found it a non-issue. The only reason I mentioned it now, was (being a technical person) tried to fully understand how it worked. Which I do now ... Case closed :-) Have a good holliday ... Regards, Rob
  5. Mea Culpa :-) What I described came from my "Notes"list I maintain, and was observed in FS2002 with FSUIPC 2.97. But since you mentioned in a previous post that your braking system was still the same as made for FS2000 (based on FS98 behaviour) I assumed this wasn't changed in 3.* as well. Shows again.. Never makes assumptions, always check the facts :lol: Regards, Rob
  6. You're right, they don't. The BrakesPosition value instantaneously and lineairly follows the Axis value. Remains the question what a realistic "pressure release" is. I don't fly aircraft in real life, so I can't really judge. But what I notice when I have calibrated my toepedals with FSUIPC: if I give full brake pressure, and slowly let the pedals come up again, the brake pressure remains 100% untill I have fully released the brake pedal, after which the pressure returns to 0 in a few steps. Is this how it is supposed to work, and how brakes work in real aircraft ?? (I mean: that you have to fully release the brake before any pressure is released) Regards, Rob
  7. Hi Pete, Actually I wouldn't have been using event monitoring for someting like this; I would just be reading the value of LeftBrake, and if it has changed since the previous read, command the RightBrake with the same value. Using the event monitoring is a very usefull function, but only if know exactly which events you need to intercept. As you just illustrated :-) But it's irrelevant now, since Doug's (my favorite competitor :lol: ) "module" implementation is easier (no gauge installation per aircraft). However, your explanation DID make another thing clear about FSUIPC that puzzled me. As you may know or not, FS2004 will DISABLE the standard key/button brake functions (AllBrakes, LeftBrake, RightBrake) if it detects an event AXIS_LEFT_BRAKE_SET or AXIS_RIGHT_BRAKE_SET, as generated by toebrake pedals or from a gauge. Don't ask me why, but it does !! But now it's finally clear to me why this "problem" does NOT occur if one uses the toebrakes calibration function of FSUIPC :-) Cheers, Rob
  8. Hi Pete, Ok, that clear. Thanks for the info. regards, Rob
  9. Hi Dave, Another solution would be a small gauge that reads the value of the Left Brake, and continuously (that is: only if the Left brake value changes) sets the Right Brake to the same position. If you contact me by Email at rc.barendregt@planet.nl , I'm willing to make that gauge (in XML) for you.. Question for PETE: If the brakes pedals are calibrated via FSUIPC, does FSUIPC still use the old-style brake setting (via your own algoritm) or directly the FS AXIS_LEFT_BRAKE_SET and AXIS_RIGHT_BRAKE_SET events ?? Rob Barendregt
  10. Hi Glen, Labla..? Well, I have a slightly different opinion :lol: Especially if you use FS9. FS9 supports a Flaps Axis by default; it just devides the calibrated range of the axis by the number of flap positions defined for the aircraft you are flying, to get a discrete ranges of the axis for each flap position. In fact, I use the Throttle lever of my CH yoke as Flaps axis (since I use an external throttle quadrant). But it works fine for any external axis. Regards, Rob
  11. Hi Pete, Thanks for your clear answer.. Saves me a lot of "educated guesswork" based on external observations; which (I learned the hard way) sometimes leads you to the wrong conclusion :) I guess I just have to do some testing to see whether these events can still be trapped if generated by FSUIPC. Regards, Rob
  12. Hi Pete, In FS(9), an assigned throttle axis on an external controller generates Axis_Throttle_Set events (Not: Throttle_Set) when the physical throttle lever is being moved. In an XML gauge, I can "monitor" these events (i.e. observe that they occur). Now, if the throttle axis is calibrated via FSUIPC, can I expect the same behaviour ??? The reason I ask: as far as I know, you cannot assign negative values to an Axis_Throttle_Set event, unlike to Throttle_set. That is, if I try that in an XML gauge, I get very unpredictable throttle read-out value. Now, if in FSUIPC someone assigns ReverseThrust on the throttle axis, is FSUIPC : 1. Still generating Axis_Throttle_Set events (with possible negative values) ? 2. Or Throttle_Set events ? 3. Or no events at all, because FSUIPC write directly to memory ? (and the same question if you use individual throttles for each engine, using the corresponding *-EngineNumber events). Could you please eleborate on this ??? Thanks in advance, Rob Barendregt
  13. Hi Michal, Pete, From my "FS9 peculiarities" archive: ****************************** Spoiler(/airbrakes) behaviour in FS9 ==================================== Note: the following is decribed for operation of the spoilers via keys/buttons, with the default keys being: - "Shift-/" : Arm spoilers - "/" : Toggle spoilers on/off But the same effect is probably true when operates via an axis. FS9 has a spoiler "feature": 1. If you ARM the spoilers while the aircraft is on the ground AND the throttles are idle, the spoilers are not set to ARM but to FULL instead. 2. If you open the throttles now, the spoilers are fully retracted again. 3. If you ARM the spoilers while the throttles are NOT idle, the spoilers are set in the ARM position; but if you now set throttles to idle, they are set to Full. And setting the throttles idle now, reacts the spoilers fully again. 4. Toggling the spoilers on/off has the "normal", expected behaviour. Which means that if you toggle the spoilers On with "/", they are extended fully (independant of throttle position); and setting throttles out of idle now, the spoilers remain fully extended. Since this Arming behaviour is dependant on throttle position, it seems intentional; i.e. a "feature", not a "bug". Whether this is realistic or not, I can't tell :-) Note that the above is only true when the function "autodeploy" in the .airfile is set to True. (which also makes the spoilers automatically deployed, when armed, if an aircraft lands). If False, the entire ARM function is disabled, i.o.w. "Shift-/" doesn't do anything in any situation. **************** Cheers, Rob Barendregt
  14. Hi Pete, In my experiance these "select exit" problems are always caused by bad-designed gauges or addon programs, which , as you already said, continuously fire FS events, which make FS loose the releation between the "toggle exit" event and the following "select .." . If someone has this problem, he will also have the same problem with pushback (followed by Left/Right) or "select engine" (followed by the engine number). Example: there are a few XML gauges published that, depending on a certain condition, set the Smoke on/off. And they give an On or Off event every 55 msec, causing all these timed keystroke sequences to be messed up. Rob
  15. Hi Pete, I had another question/observation about the FS2004 braking system. First of all, if I understand your previous post correctly, FSUIPC only processes the toebrake axis commands when given from physical toebrake axis, and the NOT brake commands given from the keyboard or from a gauge. Right ? If so, maybe the following is of interest to you. 1. Using toebrake pedals in FS2004, without FSUIPC. If you load a flight, and press a pedal once (so FS2004 "sees" that brake pedals are connected), from that moment on the non-proportional brake commands, either from the keyboard (default keys "F11", "F12", ".") or from a gauge, are no longer working anymore. The only solution: reset the flight. Now, I wasn't sure whether to call this behaviour either a "bug" or a "feature". See also 3. 2. Using toebrake pedals in FS2004, WITH FSUIPC. I'm not sure what happens now in detail. What I can understand from your previous explanation, FSUIPC still uses the old (non-proportional ?) braking system of FS, using it's own algoritm to emulate proportional braking. Does this mean that the effect described under 1. therefore should not occur now ?? 3. Using FS2004 without toebrake pedals. Note:If my opening statement is true, it's not relevant here whether the user has FSIPC installed or not. Since the user now would normally uses the keyboard functions ("F11", "F12", ".") for braking (or joystick buttons with the same functions), the same effect as decribed under 1. occurs if he is using a gauge (like mine) that (temporarily) uses the FS functions for differential, proportional braking: once one AXIS....SET command is given from the gauge, the non-proportional brakes commands ("F11" etc) are disabled again. This I DO call a bug.. Several FS2004 users have confirmed the behaviour mentioned under 1. and 3. Since still a lot of FS users do not use toebrake pedals, and the fact that a major function of FSUIPC is about solving/bypassing deficiencies in FS, I have the following questions: - Can you confirm this behaviour in FS2004 ? - If so, would you also qualify this as a "deficiency" ? - And if so, is this something you are able c.q. willing to solve in FSUIPC ? Best regards, Rob PS: About the "-ve" abbreviation: by now, you should be used to the fact that not everybody you correspond with has English as their native language :-) :-) To me, the only thing I recognised was the syntax of a UNIX command line option :-)
  16. Ok, I'll grant you the 2.285% extra :P I have been trying to find those (as xml K:event), but I cannot find them in controls.dll. What did you mean with the "-ve" ? Best Regards, Rob
  17. :oops: I'm truely sorry, I missed that one :oops: That is the explanation I was looking for, why my ParkingBrakes "trick" doesn't work with FSUIPC installed AND toebrakes calibrated with FSUIPC. FYI: I also found the cause of the original "problem" I was trying to bypass. Which, as I expected, has nothing to do with FSUIPC. This is what happens (without FSUIPC installed): In FS2002, the Left/Right brake axis (both via pedals and via the AXIS...Left/Right..SET in a gauge) has the "bug" that when applying a certain pressure, you have to release the pressure fully before a lower pressure is seen by FS2002; i.o.w. in FS2002 only reacts to more pressure, not less (untill the pressure is released fully) In FS2004, this problem is solved: FS2004 accurately and instantaneously follows the pressure (=position) of the toebrake pedals. And now the error I made in my gauge: unlike eg. ThrotlleSet you have to command the AXIS_LEFT/RIGHT_BRAKE_SET with a value between -16000 and +16000 instead of 0 - 16000, with: - 16000: 0% pressure 0: 27% pressure +16000: 100% pressure Since this is obviously is not linear, and knowing the problem of FS2002, I just jumped to the wrong conclusion. Anyway, thanks for your help, and sorry to have bothered you. Best Regards, Rob Barendregt
  18. Hi Pete, Yes, of course I tried setting the axis values to 0 (or any value smaller than 3000 (without using the ParkingBrakes trick at all); that's how I detected the problem in the first place :-) If you want I can send you a small test gauge (with description) so you can see for yourself what the problem is and that I do the right things in the right order. If you want that, where can I mail that to ? Best Regards, Rob PS: Maybe I should emphasise that I don't expect you to clear up all (percieved) problems with FS2004 in FSUIPC; my first intention is to understand why my workaround does work without FSUIPC, and fails when a (registered) FSUIPC is installed. But I obviously can't do that without your help :-)
  19. Hi Peter, My name is Rob Barendregt and I am the author of much used (freeware) taxispeed and pushback XML gauges. I have the following problem (not caused by FSUIPC, but related to it). As you may know, the brakeshandling implementation in both FS2002 and FS2004 is not really bugfree (to put it mildly). In FS2004, in my gauges I use the Left/Right axis-brakes-set to manipulate the brakes. Now, with toebrakes pedals enabled and in idle position (in a deadzone, so there is not pedal "trigger" to FS), these gauge commands work fine (and proportionally), except that, once one command is given, the brake pressure never goes below 20% anymore untill the pedals are touched (which resets the brake pressure to zero again) I have found a workaround for that, by, from my xml gauge, give two consecutive ParkingBrakes commands immediately after another, which also resets the brakepressure to 0. Now, this "trick" works always, except when a user has a registered version of FSUIPC and has the toebrakes pedals caliberated in FSUIPC. Can you think of a reason why ? (I could imagine that these ParkingBrakes commands are lost because of the scheduled nature of FSUIPC, or something like that) And if so, is this something you can solve in FSUIPC ? (either that the ParkingBrakes "Reset-trick" works again, or a solution for the underlying FS problem which causes that the brakepressure cannot be commanded from a gauge below 20% ) If needed, I can give you more info on the peculiarities of the braking commands in both FS2002 and FS2004 (they have different "bugs"), since I have made rather a study about their behaviour :-) Regards, Rob
×
×
  • 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.