Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. You don't have to assign unused axes to anything. just don't assign them. That will actually save FSUIPC time reading themn and sending values to FS to do nothing useful. You could assign both to the same functions at the same time. This will work fine PROVDED that when left alone, untouched, they provide no changed values (or, with FSUIPC's assignments, that the changes are within the "delta" value, below which changes are ignored). The easiest way is to create an extra variant of the aircraft in the AIRCRAFT.CFG file, making some change or addition to the Title so that FSUIPC will select the correct settings automatically. e.g. just duplicate the [Aircraft.0] section as [Aircraft.1] and add "Yoke" to one title and "Joy" to the other, then use this difference to identify the aircraft. If you are already using a short-name section (substring) for this, obviously the change will need to go next to it in the title. Regards Pete
  2. There's no easy way to do that. You are really talking about 4 separate buttons. You could do it by using two flags I suppose, with some complicated logic, using parameters edited direct in the INI file, but there is nothing geared to what you want to do. Are you sure you want to venture into such strange fiddles? Start by programming the button to set your 25% in the FSUIPC options. i.e Control "Traffic Density Set" with parameter 25. Then look in the INI file. In the [buttons] section you'll find a line like 1=P1,1,C1008,25 The number on the left is simply a parameter sequence number. The "P1,1" here says "Press joystick 1, button 1" (yours will be different. 1008 is the internal number of the traffic Density Set control. Now you need to use two flags to give you 4 alternatives. Flags are nominally associated with buttons, but they don't need to be real buttons you actually have, so I'll choose buttons on joystic 15: buttons 0 and 1. Make the first parameter conditional on both flags being off: 1=CP(F-15,0)(F-15,1)1,1,C1008,25 The red parts I've inserted make this conditional on those two flags being clear (the '-'). Now, on the same condition we need to set one of those flags in order that the next time though you get a new result: 2=CP(F-15,0)(F-15,1)1,1,C1003,3840 The 1003 control is "set flag" and the parameter 3840 is 256 x 15 (the joy number) + 0 (the button number). Now the rest follows similarly: 3=CP(F+15,0)(F-15,1)1,1,C1008,50 ;Flag 0=ON, Flag 1= OFF, set 50% 4=CP(F+15,0)(F-15,1)1,1,C1003,3841 ; and set Flag 1 ON 5=CP(F+15,0)(F+15,1)1,1,C1008,75 ;Flag 0=ON, Flag 1= ON, set 75% 6=CP(F+15,0)(F+15,1)1,1,C1004,3840 ; and set Flag 0 OFF 7=CP(F-15,0)(F+15,1)1,1,C1008,100 ;Flag 0=OFF, Flag 1= ON, set 100% 8=CP(F-15,0)(F+15,1)1,1,C1004,3841 ; and set Flag 1 OFF After steps 7 and 8 it's all back to the start again, for 25% next press. Pete
  3. Okay. That's interesting, but I still don't understand it. I've always had all my axes (not from CH equipment though) sent "direct". It is more efficient, if you are calibrating in FSUIPC, because the other method involves three times as many messages flying about between FSUIPC and SimConnect -- one lot to send the axis values to FS, then the same stuff being sent from FS to FSUIPC for calibration, then back from FSUIPC to FS after calibration. With "send direct", your axis values are calibrated then sent to FS, by-passing the circuitous route. One set of transfers, so it should be simpler, less error prone, and three times more efficient! In theory. So, now I have to find out what there is about that which could possibly make a system crash. Pete
  4. Isn't this a matter for GoFlight support? If you've programmed it in FSUIPC (why?) then you probably need to program both the "press" and "release", as most rotaries send an "off-on" and an "on-off" alternately, hence the two "clicks" to the next "press". Pete
  5. Ah. There you are then. FSUIPC can handle 70 keyboad presses, no troubles. ;-) No, I understand, but your question was why can't FSUIPC see the 70 buttons on your device, and the answer is now made clear -- because they don't look like buttons, but keypresses. Use the "Keys" tab in FSUIPC, not the Buttons one. I assume that this "Mjoy Mapper" is the driver provided with your hardware, so it knows how to read the buttons. It converts them to keypresses, so, effectively, that's what you have to use. You have no choice. If you want anything to recognise the buttons as buttons instead you'd have to go back to the makers and ask for an appropriate driver for their hardware which does such things. Not you, perhaps, but whoever designed and built the hardware. Who else could do it? Who else knows the hardware? FSUIPC can only handle hardware it understands, or which Windows understands and handles for it. There are defined interfaces for this, and FSUIPC uses them. If a hardware manufacturer wants maximum flexibility for their product they need to consider what interfaces to support, and then provide the appropriate drivers for them. Evidently, for your hardware, they thought providing a keypress capability was sufficient? Regards Pete
  6. FSUIPC uses interfaces it knows. I cannot use interfaces it doesn't know -- you figure it out! You say "the only way you can read" these 70 buttons is by using this mapper -- how do YOU read them? What known standard interface are YOU using? I can design my own hardware with any amount of switch capability and write my own driver for it, but unless that presents itself to Windows in a standard way, the only way anyone else can ever use them is by using some SDK or interface I tell them about, for my specific design. That doesn't answer any question at all, it simply avoids it. how are YOU reading the buttons??? Saying "by MJoy Mapper" means nothing to me, that isn't a standard Windows interface, is it now? Yes, write a standard Windows HID driver (HID = Human Interface Device) to present the device to Windows as a number of standard joysticks, exactly as the EPIC driver does. Regards Pete
  7. Don't the calibrations work for any plane? Surely once you have the min/max/centre and response slope sorted, the same applies to all -- well, all except helos possibly? You don't have to "undo" anything -- just save a copy of your FSUIPC.INI file someplace. Everything you do is saved there, no where else. I thought I said? Last change. I'll repeat the relevant bit from my last message: Depends how much you move it -- if more than the Delta, the bank will be affected immediately (until the next change from the one you are using). The innards don't know where the values are coming from -- they are simply thrown at it by the multiple axis assignment. Pete
  8. Why is telling the straight truth, that you don't need to change anything, unhelpful? I don't understand. How does altering one recorded detail in one little file on your disk let anyone know anything? Unlike other complex systems, FSUIPC does not touch the Internet. It doesn't "tell" anyone about you. It isn't spyware or anything so complex. It keeps itself to itself and just works by a key tied into an ID (any old ID) which you yourself chose originally. I hate all those complex systems. With FSUIPC to remove it you just delete it, to install it you just do. Nothing complicated, nothing to misunderstand. I don't know what's got you so aggravated -- you evidently like over-complex systems? :-( On your second insulting message, Why are you saying it is "flakey"? It works perfectly and easily and has done so now solidly for five years, without there being anyone like you before. If you want to re-re-register you can simply delete the KEY file (which contains your registration) then re-register with whatever Name/Address/Key you wish, provided those are properly purchased and are therefore tied together. I really don't understand why you think you can simply change your ID and expect the same Key to work, nor why, just because it is a nice, simple, completely self-contained system, you call it "flakey"! Can you explain yourself, or do you just like being rather offensive? Pete
  9. That's 32 buttons on each of up to 16 joysticks. Neither the Windows joystick interface nor DirectInput can cope with that, so how are you reading them in Windows? If you have your own driver it must have a non-standard API, so how on Earth could FSUIPC handle it? It only knows DirectInput and the main joy API. The EPIC card had up to 512 buttons. It looked like 16 joysticks to Windows. 16 x 32 = 512. How are you currently getting 70 buttons read on one joystick via a standard Windows interface?? Regards Pete
  10. I don't really think that's very relevant. I only found out by swapping memory chips. Don't forget, there's no parity checking on the current DDR memory in most motherboards. Stress testing doesn't properly test long-term retention nor pattern interference. The best way always is to try alternatives. Pete
  11. If you change your address in the registration the Keys will not be valid and you will have to buy new ones. Why on Earth do you want to change them? The Name, Address and Keys are tied inextricably to each other. There's never any need to change any of that. The name and address is only there to ensure the key is unique and belongs to you. It is never used as an address. Regards Pete
  12. Can you give me details of the references you are using, please? As far as I remember these there was a temporary testing facility I added for this, for Enrico Schiratti, when he was thinking of implementing a new autopilot, but I don't recall releasing them generally nor maintaining them through to FSUIPC4. I wasn't aware anyone was using them. Incidentally, please never just say "latest FSUIPC4". That's meaningless -- I've had cases where folks have said that and it turned out they were using a year-old version. they'd not seen an pdate on whatever site they went to, and they never referred to the "supported versions" announcement in this Forum. Please ALWAYS quote the actual Version number. It is easy enough to find, after all, being displayed in the Options, logged in the logs, etc. Pete
  13. Two possibly relevant stories to relate. First, one which happened to me this week: I'd updated a PC with new video Card, DX10 capable, installed vista 64, and was about to upgrade memory from 2Gb to 4Gb. Between each step I was re-testing FSX + FSUIPC4 + my cockpit drivers (working through Axis assignment & Calibration in FSUIPC4). I suddenly noticed, on Tuesday this week, that on one particular Joystick Calibrations page, one of the normal "min" Set buttons was always disabled and the two right-most axes couldn't be calibrated because the main Set buttons did nothing. Now nowhere in my code do I enable/disable Min/Centre/Max "Set" buttons, I only ever change whether they are visible or not. And I've no idea what the non-operative Set buttons were trying to do. So it was a struggle. Annoyingly, with a Debug version it didn't happen, nor with a previous version. Thursday after wasting nearly three days looking for an impossible software bug, I gave up. I decided it was impossible for these things to happen UNLESS some pixie was actually change values (bits) inside memory ..... Clunk! Memory! Luckily I had another pair of 1 Gb sticks (as I said, I was about to upgrade from 2 Gb to 4 Gb), so I swapped them over. Bingo! no more weird inexplicable problems! The second story is actually more elongated, a long thread here relating to a crash which was occurring in FSX on longer flights. It seems it all started when wind smoothing was added to FSUIPC, so this was under suspicion. All sorts of things were tried, till, finally, the fault went "solid" and turned out to be a memory problem also -- new memory chips and all was well. All I'm trying to point out here is that when things worked once and then don't for no apparent reason, it is not always something you've done, and not always a software bug. With two recent incidents both costing a lot of time and both down to memory chip problems, I am beginning to wish PC memory never started leaving off the Parity checking. My new PC, just arrived today, has parity checked memory. I realise it might be a bit slower but in the long term it might save me a lot of bother! ;-) Regards Pete
  14. I don't know, there may be. I use a program called "FlightKeeper" which logs loads of things, not just track. Regards Pete
  15. I don't know of any software which will do exactly that, not send a mouse click without previously moving the mouse to a given location. Though you could check Luciano Napolitano's "Key2mouse" to see if it has such a provision. I don't know. But if you are trying to do away with the mouse, how will you move it to the right position before the click? For specific places on screen you would need Key2mouse. It allows you to assign a Key to a mouse. Then, in FSUIPC, or maybe your joystick driver, you can assign that keypress to a button. FSUIPC's "mouse macro" options allow buttons or keys to operate some (not all) mouse-only functions without the screen being involved at all. Regards Pete
  16. FSUIPC cannot easily itself cause FSX to crash -- all cases so far have been either due to the actions of programs using FSUIPC or to bad FSX data which just happens to be accessed more thoroughly or frequently when FSUIPC is running. The prime instance of the latter are the weather files associated with flights which are notorious ofr crashing FS when corrupted. This shows FSX crashing immediately on loading the Flight c:\documents and settings\mhf\my documents\flight simulator x files\Chap_10_Lost_and_found.FLT Previous to that it had loaded three flights quite happily. When you say "entire tree", can you explain, please. Obviously you cannot mean exactly that, as that contains most of your system information, not just flight sim stuff. In particular, it is important to note that for a clean install there are at least THREE FSX folders needing removing in the Systems area: 1. The "My Documents/Flight Simulator X Files" part you presumably meant. 2. Your "C:\Documents and Settings\mhf\Application Data\Microsoft\FSX" folder, where your FSX CFG and other vital files are kept 3. Similarly the "C:\Documents and Settings\All Users\Application Data\Microsoft\FSX" folder, where the scenery configuration goes. Also, because SimConnect is a "side-by-side" system installation, is doesn't get uninstalled. I think the only way to be sure a corrupted Siconnect is replaced is to actually delete its folders -- as described in the FSX Help announcement above. When you uninstalled FSX did you also delete any folders left behind? With the Modules folder having been added by FSUIPC's installer, the FSX uninstaller won't remove it, so the re-install would not have given you a "default" FSUIPC. You'd need to delete the folder entirely then rerun FSUIPC's installer. There's really no other information in the stuff you've provided to indicate what might be happening. Something is either corrupt on disk, or is getting corrupt in memory. Things like a memory fault can give results like this, so after thoroughly eliminating possible software suspects it may be time to look at the hardware. The fact that it all used to be okay then suddenly started doing this consistently does smack of something getting broken or failing. Regards Pete
  17. Do you? On flight sim, you can left or right click anywhere. What is it you want to do? Ermost add-on gauges and some default gauges have mouse-only functions, yes. The default RIM is one such. But yyou can use left click from the mouse. Inn fact that's all you can use, so I'm not sure how you say you cannot? I assume you mean Luciano Napolitano's "Key3Mouse" program? What is not like it? In recent versions of FSUIPC I've provided a facility to generate "mouse macros" to allow some (not all) mouse-controllable functions to be added to FSUIPC's control list, for assignment to keys or buttons. Have you looked at this? Regards Pete
  18. There's only ever one actual contact no matter what -- Sending a message, using "SendMessageTimeout" (the timeout is there to prevent the application hanging if the receiver never replies). The application first needs to get the window handle for window class "FS98MAIN", which is FS. The Message sent provides an Atom ID, registered with Windows, which allows the memory filename to be reconstructed by FSUIPC so it can open the same memory file, already created by the application. That's it, nothing else. If the application can't connect, as if it never sees FSUIPC, it is surely because of one of these reasons: 1. Windows prevents higher privileged Windows from being detected (which I certainly cannot believe), or 2. Windows refuses to allow messages to be sent to them and forces them to timeout instead (which I also find hard to believe), or 3. Windows allows all that but won't allow FSUIPC to open the memory mapped file. Actually, there's a way of finding out. If you go into FSUIPC's Logging options and enable IPC Read and Write logging, it logs any errors trying to establish the connection when it receives the message. If it never receives the message then one of 1 and 2 above are correct. Otherwise there should be an error, one of these: IPC ERROR: zero Atom Id IPC ERROR: Atom Id not recognised IPC ERROR: Offset >= 65534 IPC ERROR: Cannot OpenFileMapping (Error=N) The third is a simple data error and not likely here. The last is the one I suspect. The error number will be one of Windows system error numbers. Regards Pete
  19. Ah, my error in trying not to make the User Guide so large and encyclopaedic that not even the one person who currently reads it would! ;-) In fact the release notes for the release in which it was provided (now part of the History document) explained it in a little more detail: I'm always a bit reluctant putting all that sort of stuff into the user guide. It's too big already. I'd need to start taking facilities out! ;-) But maybe, in this case, I'll add the word "single". Won't make it significantly larger. Does that happen? Just because MyTrafficX doesn't use real-world schedules doesn't mean it has unrealistic placements. i've found it pretty good in fact. Also, with ONLY real world "schedules" you get no unscheduled flights, charters, etc. MyTrafficX seems to cover a lot more, just not actual schedules. If you do get wrong airlines in places, let Burkhard know. He's very responsive and his support forum is very close. Regards Pete
  20. I'd be interested to know more about this, if you do find out. However, in FSUIPC's case it is the application which creates the memory file and tells FSUIPC about it so it can open an access to it to retrieve the request data and dump back the results. The application keeps it, FSUIPC doesn't know about it except whilst processing the requests. That way each application has its own area, nice and tidy. Since it is that way round, I don't see how the higher-privilege process (FSX) can mark the area as safe for lower-privileged access when it is a lower-privileged process which created it and owns it. I suspect the same would apply to SimConnect, as each application instance would, again, need its own space, presumably created when it calls and opens SimConnect.DLL. Regards Pete
  21. No, it does not. It only deletes ONE, the nearest on in the "line of fire", so to speak. Please read the documentation. It's only function was to remove a blockage in front of you on taxiway or runway. It is certainly possible for someone to write such a utility, but not I. Sorry. I think you are wrong here (though please do go check). I think the number of cycles provided to traffic diminishes considerably with distance. The real cycle-guzzling stuff is the stuff within visible distance. I'm pretty sure that it doesn't even draw them after about 10 nm or so, and the update frequency for distant ones is low. So, if someone bothered to write such a utility you'd find it made very little difference at all -- in fact it might make it worse as the utility itself would be guzzling cycles reading data and sorting it to decide what to zap. Best to instead only ever use AI which is designed for efficiency. For FSX the MyTrafficX program with the DX10-only traffic seems to give excellent performance everywhere with lots of traffic. It's the autogen which kills my system's performance. Regards Pete
  22. Really? Having UAC on makes vista almost unusable for me. It's just a P.I.T.A. Vista is much nicer without it. What are you afraid of? Are there other users accessing your system with your user log-on credentials? UAC only protects you from you, and that makes it very restrictive and for me completely unnecessary. Pretty much all current SimConnect programs are designed to work with FSX RTM and SP1 as well as SP2/Acceleration, so they don't take advantage of the improved efficiency of the shared memory/pipe system available in SP2/Acceleration. The latter may well fall foul the the same protections. Regards Pete
  23. Sorry, old versions are not supported. Please refer to the Announcements above. 3.65 is very old. Use the latest version then re-ask your question, but first of all please try using the facilities provided for you to check things yourself. Look in the FSUIPC Options and you will see a "Logging" tab. Go there and check IPC read logging. See if your requests are being logged correctly. Logging is provided to help developers. Pete
  24. It's called "hacking" these days. I've been a programmer since 1963 and always worked at machine level upwards, so the nuts and bolts underneath were more easy for someone like me, together with my own tools and some anyone can purchase (e.g. including Microsoft's own excellent debuggers). However, it still takes many 1,000's of hours for each new version, and it has been getting more and more difficult as they use more and more convoluted code ("object-oriented", so called. Ugh). Additional multi-threading and multiple core usage make things tougher. I'm nearly 65 now so I'm glad SimConnect is 'taking over'. One day it'll do the whole job. :-) Pete
  25. As far as I know, provided you are using the latest version of FSUIPC (eg, for FS9, FSUIPC 3.81) where some of the defaults were changed, there's nothing special to do for either of those add-ons. If you have been using FSUIPC before, you may want to delete your FSUIPC.INI file and go through setting your options (if desired) again, just to make sure the revised defaults apply. Get them working in FS without calibrating or assigning in FSUIPC first. This avoids confusion as to what is going on. Regards 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.