Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Okay. Thanks. Pete
  2. Since you need to know how it is activating the action you need, it has to be running. You put a breakpoint on the place called when you click the mouse and trace through, one instruction at a time ("single-stepping"), carefully observing what it is doing, until you find out how to do it yourself. Then you write that code, or code to call the right parts. This can take many many hours. Only recently I spend over two weeks, at about 12 hours a day, trying to decode parts of one FS module in order to dynamically remove the default push-back vehicles. After following numerous clues I gave up. Maybe in my younger days I'd have kept on for another 200 hours. Luckily FSDreamTeam then came out with GSX which did the job by patching the graphics to make it invisible instead! ;-) I started out working life as an assembly code level programmer, in 1963. Even with 49 years experience with this sort of hacking and debugging I still can't do many things, and some are just impossible. If you don't know assembly level code thoroughly I don't think you stand a chance, and even if you do it is entirely possible you'll reach a dead end. It is so easy for the original programmers (PMDG/FSLabs) to make things quite obscure so that only they know how to interface to it. If you are dead set then the only way I can think is for you to borrow an Engravity CDU and use a debugger to work out how that does it. But I cannot help you there as it is a violation of their rights. It might be different if you bought one. It's quite normal. It is likely they all do something similar initially, like push a register which is going to be used onto the stack so it doesn't get overwritten. Quite usually it's a "push ebp" which saves the parameter pointer for the previous stack level, followed by a "mov ebp,esp" to set a new parameter base ("stack frame" being the more technical term). Regards Pete
  3. No need to be sorry. As someone once said, I think, "the only stupid question is the one you should've asked but didn't!", or something like that! ;-) Glad you are sorted. Pete
  4. What on Earth are you doing in the assignments? [Axes] 0=2Y,256 1=2Y,B,-16384,16383,66420,0 2=2Z,256 3=2Z,B,-16384,16383,66423,0 You aren't actually assigning to a normal axis at all, you are trying to do advanced things with ranges on the right-hand side of the assignments tab. Why? What are you trying to do? I suggest you delete the [Axes] section in the INI and try doing straightforward assignments, do not mess with things you don't want and apparently don't understand. The facility to send different controls in up to 10 different ranges, with different directions, and so on, has uses in advanced cockpits, but not much for throttles in any case. Why not just follow the instructions for assigning normally? Stick to the left hand side, the normal assignment methods are there. And when you get to the calibration section, please do not use things like Filtering until you have done the calibration, and then only if it is really needed -- it does alter the response. Pete
  5. Ah, sorry. I'm reading too fast, I misread "Been working on it for 3 days now but nothing works..." as "Been working for 3 days but now nothing works..."! Sorry. After you make sure you are up to date with the FSUIPC version, please enable Axis logging in the FSUIPC logging page, and operate the throttles. Keep the FS session short. Then close FS and show me the FSUIPC.LOG file and also your FSUIPC.INI file. Both of these are in the FS Modules folder. They are text files -- you can open them with Notepad and paste their contents into a message here. Regards Pete
  6. This is my only 'site'. Maybe you mean the Schiratti "Dowson" page. I'm not sure what version that installs. Nevertheless there really has been no changes to how axes are assigned and calibrated. You need to work out what has broken in the three days. Regards Pete
  7. Send it back. If it doesn't work it needs fixing under warranty. Does it work when assigned in FS? Assigning to Axis Throttle 1 and 2 in FSUIPC is identical to assigning to throttles 1 and 2 in FS. FSUIPC makes no distinction between Saitek or any other axis inputs. Sounds like you are looking in the wrong place. the separate throttles are on the third page in calibrations, not the first - the throttle there is the generic single throttle for all engines. So it was working after you just received it, and then stopped? Doesn't that suggest a hardware failure? Software doesn't change. BTW the current version of FSUIPC for FS2004 is 3.998m, and there's a later one in the Download Links subforum. Version 3.999 is being rleeased tomorrow and then earlier ones will not be supported. Regards Pete
  8. I did think of a couple of things like that but didn't suggest them because I did not think changing the view back and forth would be acceptable. So I am glad you don't notice the flicker and find it a good solution! Regards Pete
  9. I used to have the MCP, years ago, but I never made any software for it. Andrew Maclean did his own drivers. Where in my documentation have you seen me refer to it? I'm intrigued. I know folks are using that MCP with Project Magenta. I would think also that it could be used with default aircraft, and I seem to recall he implemented a system where you could reprogram the buttons to do other things, maybe through FSUIPC. I'm afraid it is all so many years ago I've forgotten most things about it. Regards Pete
  10. Can you point me to it, as I don't recall anything about "Aerosoft" stuff. Do you mean Aerosoft in Germany, or the Aerosoft in Australia, from whom I have the GA28R cockpit and who made the 747 style MCP? Or are you talking about their new software gauges rather than any hardware? Sorry, I don't know because I don't know exactly what it is you refer to. Regards Pete
  11. No, I couldn't know that. you didn't say, and there are a lot of hardware units with displays around, even at the normal consumer level -- Goflight and VRInsight are two others in a similar price range, though probably better quality, as Saitek. Not that i know of, at least without hacking into the PMDG code. I think some folks did find some offsets for some FS9 PMDG aircraft, but I could not publish them here even if I knew them as that would be a violation of PMDGs copyright. They simply did not publish such information and, though they did originally say they were going to publish an SDK (for sale, not free), they never did. I believe the larger hardware makers did purchase data or drivers from PMDG (and/or FlightSimLabs) to allow hardware interfacing to work well -- but not many, as it was apparently a steep price PMDG quoted. Regards Pete
  12. A hardware panel? Wow! You certainly needed to say that up front! Panel displays in FS are normally on screen, presented by Gauge files in the Panel definition. FSUIPC doesn't actually drive any hardware panel displays. What driver are you using? There's no easy way of reading out add-on panel values when they don't use the FS values, as in the case of PMDG add-on aircraft. Quite often the only way of doing it is to update your local hardware dispay at the same time as sending the updated value to FS. Did you write the driver for your hardware panel? Else, perhaps you can find a driver for your hardware panel which works this way? Of cause it won't display values set automatically by the autopilot, or by loading a new flight into FS -- for that you'd need some specific driver which knows how to get values out of the PMDG code. Without knowing anything more about your hardware or its drivers I cannot really advise further, but I suspect you are on a lost cause as far as PMDG aircraft are concerned. Regards Pete
  13. Sorry, I still don't understand. What do you mean by "panel display doesn't refresh"? What would it "refresh" from or to? I'm not picturing what it is you are doing or having a problem with I'm afraid. Pete
  14. Sorry, I don't understand the question. What "panel display reading problem"? As well as explaining whatever problem it is you want advice about, could you also please state the version of FS you might be talking about? Regards Pete
  15. The programming language isn't really relevant because you don't have access to any source code. You'd need to plough through and understand the machine code, or rather the assembly code shown by the debugger. I use the one built into Microsoft's Visual Studio system. The entry is 0x10AD0 bytes offset from the beginning on the DLL or GAU file identified in the Macro. The 0x8B00 value is just a check -- the first two bytes at that offset. They are just used to prevent FSUIPC crashing FS should the GAU or DLL be changed and the entry point moved. Yes, it would be easy for the original programmers to provide an interface. The FSLabs one wouldn't have been free. Maybe the maker of your CDU can bribe PMDG or FSLabs to give them a driver too, or perhaps the FSLabs one can be used for your CDU? I don't think folks in either company would deal with individual users on this. They would be looking to make money for such support, no doubt. In the end I think you'd find it easier and cheaper (especialy in terms of your time) to sell your CDU and buy the Engravity one. Don't you think? An easier wild goose chase than ploughing into disassembled code I assure you! Regards Pete
  16. Most of the functions aren't implemented in FSUIPC, they are simply FS functions being exposed by FSUIPC. All of those you are using above are FS functions. Unfortunately I cannot find a function which swaps leyboard focus back to the last outside view. Generally it doesn't arise because there are specific functions which can be assigned to buttons to do all the individual things you are doing, separate INC/DECs for each value, and Zoom functions for the current view. In fact I don't recall the question arising in the many years of FS and FSUIPC. A function to specifically transfer focus to an external view could be implemented, but the general way FS can be used does not make this straight-forward. You can have several different outside views (opened for instance with the [ keypress and closed with the ] keypress. Which one should it revert to? Or to each open one in turn each time pressed? It would need to operate by Window names, too (to get the Window handle for the focus), and they vary according to the Panel configuration. That isn't difficult to resolve by program (by ennumerating all open windows), but it isn't easy, if indeed possible, to differentiate between panel windows, only full of gauges like the throttle and radio stack windows, and external windows, because the names can be arbitrarily chosen. Your best bet is to use the Zoom functions, which always operate on the last selected external window, instead of +/-. Regards Pete
  17. It's an 8-bit binary value, like an integer but taking up only 1 byte (8-bits) instead of 4 bytes (32 bits). The integer data types in FS/Windows/FSUIPC are: BYTE = 8 bits = 1 byte (character) WORD = 16 bits = 2 bytes (short integer) DWORD = 32 bits = 4 bytes (integer) QWORD or __int64 = 64 bits = 8 bytes (__int64 or long long). I normally use the C library functions "sprintf" or "itoa" to convert binary numbers into decimal strings. Cast 'chTime' to an int. Regards Pete
  18. The FSUIPC_Open will make the connection and read some basic stuff like FSUIPC and FS versions, but the FSUIPC_Read and FSUIPC_Write functions don't do anything other than add the read/write request to a list. You've no performed the actual read/write until you call FSUIPC_Process, which you've omitted. Please do re-check the documentation and examples. I've no idea what a QT Creator is. How is this supposed to work? Assuming "QString" is some clever type or class which converts basic numerical values into printable characters for you, how does it know the correct representation (decimal, hexadecimal and so on? Regards Pete
  19. I assume, then, that you've tried all the assorted ways of modifying and augmenting the mouse macro encodings, as described in the User Guide? (the section in The Mouse Macros chapter a box entitled "Variations for Mouse activated switches which might be made to work by editing the Macro file"). Assuming you mean a "PM", I don't get them so can't open them. Sorry, I don't know. If you want to hack into their software then the starting place is the offset into the GAU or DLL recorded in the mouse macro for the keys you are concerned about. That will give you the entry point into the code. You'd need to trace it through using a debugger in disassembly mode to see how to make it work. It's the sort of thing I used to have to do with FS itself before SimConnect was invented, and used to take a long time, weeks, at 100 hours per week, and still often ending up with no results. If they didn't want you to do such things they can find many ways of stopping you or making it so difficult you'd give up. Well, either it is simpler than you've found, or they hacked it skillfully, or they got together with PMDG to solve it -- I would guess the latter with a commercial arrangement between them. Have you asked PMDG? Regards Pete
  20. It's not so bad. Why not take a look at some of the examples, both those supplied with FSUIPC and installed in your Modules\FSUIPC Documents folder, or those in the User Contributions sub-forum? I can help with programming questions when you get into it, short of writing it for you. Regards Pete
  21. Sorry, it is not possible in FSUIPC to have different calibrations for the same axis. The calibrations work on the axis control for the intended aircraft surface, not on the joystick inputs. There are two things you can try to match them a little better. One is using the scaling options you can add into the assignment lines in the INI file. The Advanced User's guide is the reference for this. The other is to assign the joystick axes to Lua programs (in which they get the axis value as their "ipcPARAM" variable) and do your own calibration, or pre-calibration, there, before sending the results off to FS via the original controls you are currently assigning to. The calibration in the Lua would only be a matter of comparing the axis values with a preset minimum and maximum (measured using normal calibration) and scaling the input value between those to the range -16384 to +16383, assuming you then send them as normal AXIS controls and use FSUIPC calibration if you need reverse zones. The other variations are also easy enough. Get back to me if you need more. Regards Pete
  22. Okay. Those files show everything is fine on the Server. Why do you have WideClient files on the Server? That config file is the defalut except for the addition of the ServerIPAddr parameter. Does that relate to anything? Okay. The config file is the default, but the log clearly shows the connection is okay, and that the server IP address is indeed as in the Server copy of the config file, even though it was obtained okay be the automatic connection: And the log certainly shows no problems whatsoever with the Server or Client, and that WideFS is working fine. So, now we come down to your error message: Here, I now understand you to mean that the program you are trying to run, namely "TRCLink", is saying it cannot run with FSX, that you need FS2002 or FS2004. It seems to me that either you have an out of date version of TRCLink, one which was written and released before FSX was known about (6 years ago), or that the company who made it (TRC?) have never updated it. You need to contact TRC. See if they have a website with a later driver. Er, by whom? Me? Are you offering transport, as I do not drive (not allowed with my limited eyesight). Why would you think it would be useful for me to be there? It sounds like you need someone from TRC if you cannot update drivers. Regards Pete
  23. I think you need to put this sort of question on the FSX Forum, here or over in AVSIM. It isn't a query about any of my software. Regards Pete
  24. I shouldn't think so but i don't know. Do the add-on products you are talking about say they need a registered install if FSUIPC? What products are you talking about in any case? What's this "practice area" anyway? You aren't revealing any details at all. Also make sure your FSUIPC is up to date. The current installer is for version 4.758. Regards Pete
  25. It's "Dowson", actually, but call me Pete. Same issue as what, exactly? I've read through the other two, different, problems in this thread and neither were concerned with any "stuck rudder" --one was a definite USB port problem and fixed using another port, the other was one of dual assignments because controllers had not been disabled in FSX when assigning in FSUIPC. Well, all visiting the FSUIPC menu does is cause the USB connections to be rescanned, which sends a re-initialisation code to the joysticks, so it certainly seems as if the specific USB connection to the rudder is going to sleep and/or stalling in some way. Since it is the same through the Saitek hub it would certainly argue against being a USB port problem, and instead suggest a power probem in the unit itself, or the connecting wires to the unit, or the actual circuitry inside it. I really can't advise how that could be fixed. 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.