Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Great. From you earlier message, where you said you were mapping to 4 throttles I assumed you were using the facility for the single generic throttle, because that's the only place where there is such an option. The calibration is defined in the FSUIPC INI file. There's no way it can "lose" those numbers. Are you sure the pot in your yoke isn't loose and twisting? Or else you are using a trim on the yoke which actually physically changes the centre position -- CH used to have such things, but they should never be used. I don't know if the still do this. You have 4 throttle levers, not two? Why are you using any "mapping" whatsoever? The picture you showed in the first post shows you have throttle 1 mapped to throttles 2, 3 and 4. Why? Why on Earth would you do such a thing if you actually have 4 throttles anyway? I don't understand what you are trying to do. The 4-throttle mapping facilities are for folks with one throttle lever only! With 4 levers you never have to map anything! That's completely and utterly irrelevant. None of the three sections for engines 2,3,4 are being used in any case. Do you not see the words "axis copied from Thr 1" as well, prominently displayed for each axis? Don't you think it a wee bit odd that you are using a copy of throttle 1 on all 4 engines when you have 4 throttle levers? What did you intend to do with the other three? It actually did not need to be any "more clear", because I told you about mapping in my first reply. Please review it. You are completely misunderstanding the facility to map one throttle to 2, 3 or 4 engines. I don't understand why. You apparently have 4 throttles so why on Earth map throttle one to all others? It makes no sense, as I said in my first reply. Please read it again and tell me what you still don't understand. Pete
  2. 4 throttles are no different from 2. How many do you actually have, real ones that is? So you only have the one throttle lever? What did you do for the 737? So it sounds like you have something else assign to throttle 2, preventing the correct mapping of your one and only throttle to throttles 1,2,3 and 4. Er .. hang on a moment. You have TWO throttles? If so, what are you doing even considering using the generic all-engine throttle on Page 1, and then, worse, mapping it to all 4 throttles? How did you expect your throttle 2 lever to contribute without a complete mix-up? You have a fundamental misunderstanding. How? I can't imagine how you even got anything working on the 737. The page 1 throttle is the basic FS single throttle for all engines. The same as using the keyboard throttle (keys 9 and 3, or F1 - F4). If you have 2 throttle levers you NEVER EVER use that! You assign throttle 1 to throttle1, and throttle 2 to throttle2 (logical, eh?), and use the 4 throttles page to calibrate. For 4 engines you select the "map 1->12, 2->34" option on that page. All exactly as documented. There's also a 3-engined option with 1->12, 2->3. The same sort of thing with the generic throttle happens in FS as well, without FSUIPC. In the assignments there 's a "throttle" as well as a throttle 1 and throttle2 etc. The generic throttle is just that, one for all. NEVER use it if you have more than one! How have you managed to miss all this? Pete
  3. Not that I know of, at least not by such a name. Is this simulated in the default FSX aircraft at all? I know it is by some add-ons with FMCs (I use Project Magenta which of course includes it). There are these controls listed for FSX: AP_N1_REF_INC Increment the autopilot N1 reference. AP_N1_REF_DEC Decrement the autopilot N1 reference. AP_N1_REF_SET Sets the autopilot N1 reference. I don't know if these work, but if they do the autopilot variable which seems to relate to this is the AUTOPILOT RPM HOLD VAR, which is found at offset 07F4. Regards Pete
  4. FSUIPC is, at root, simply an interface into FS for FS applications and some add-on aircraft. If you use something which needs FSUIPC, it will tell you. If you nothing you use needs it you don't need it, it becomes optional. It started, back in FS98 days, as just that: an almost invisible interface. Since then it has been expanded to provide lots of extra facilities for users. Those require a purchased registration code (unlike the application interface -- at least for most licensed FSUIPC applications. Some require purchase). WideFS is just an expansion of the application interface provided by FSUIPC to other PC's on a local network. it allows some applications to run on PCs which aren't actually running FS, enabling them still to interface to it to extract and inject information. Really, to find out a lot more than anyone here can tell you, you should simply download and install it, then browse the documentation supplied with it. That costs nothing. If you simply want to read the documentation instead, first, then check the Updates and other Goodies Announcement here in the Forum. Regards Pete
  5. Sounds like you tried to change it when FS was running. All the main parameters, those in the [General] section, can only be changed when FS is not running. FSUIPC doesn't care about UAC. And "latest version" is meaningless to me I'm afraid. Folks have said that in the past and meant "the latest version I have seen". In some cases it's been a year out of date. Please always quote the version number. it is easy to find -- on screen, in the Log, in the documentation, and even in the DLL's file properties. Regards Pete
  6. As it says in the documentation, at SimMarket. There's actually a link to the exact correct place on the FSUIPC download website page. Pete
  7. Ah .. that'd be "GPSCRSR ". Sorry, typo. Got it as "GPSCSR". Not enough R's. I'll fix that. Your log showed no difference, and in any case the codes they return, GPSPAGE+ and - and GPSGROP+ and - leave no room for the usual "fast" indications of ++ and --. The VRi protocol seems to have 8 characters as the limit. Yes, and it is exactly the same for all VRi units, and as documented for the FSUIPC facilities. Unlike with normal joystick buttons which can be detected being pressed and released, the VRi devices only send anything when pressed. Therefore the signal they send has to act as a "toggle" -- one press switches on, the next press switches off. The Buttons tab in FSUIPC only detects "off to on", not "on to off" to avoid complications. As it surely tells you in the documentation, if you want every press to count you have to program both the press and release actions in FSUIPC. Regards Pete
  8. If it works in FSUIPC 3.987 for FS9 then it should also work (same code) in 4.611 http://fsuipc.simflight.com/beta/FSUIPC4611.zip I've started work on some documentation for other new facilities I've added lately (mainly sound playing facilities in Lua and via offsets), and I hope to post both versions, as interims still, in the Updates Announcement early next week. There's this GPS5 facility and Squawkbox Transponder facilities still to confirm working. Regards Pete
  9. Thanks! I'll certainly take a look! Meanwhile I have been working on it too, and interim version 4.611 or FSUIPC contains the code to drive the SB4 Transponder too. http://fsuipc.simflight.com/beta/FSUIPC4611.zip I've tested it insofar as it does what I think it should do, but I've not tested it "live" with SB4 running because, to be honest, it's been several years since I tried using it and I've completely forgotten everything about it. I've not got time to do any revision at present, but if you are a regular SB4 user (or anyone else reading this), please do test it for me and let me know. This is what I've done: 1. Used the SB3 offset method (7B91 for mode, 7B93 for ident) to determine when to send the Client Data changes to SB4. This basically should make any program or assignment which worked with SB3 on FSUIPC3 also now work with SB4 and FSUIPC4. This applies, for instance, to the hardware transponder driver in my PFCFSX.DLL driver for the PFC centre console that I use in my cockpit. 2. Added assignable controls to operate those offsets. This is "icing on the cake" really, but it makes it easier and more obvious. I've also added them to FSUIPC3 for SB3 (with the appropriate control name change of course): Xpndr stby (sb4) Xpndr on/mode c (sb4) Xpndr toggle (sb4) Xpndr ident (sb4) I hope all these workthey should do! Thanks for your help! Pete
  10. No, only that the two flaps controls aren't going through the SimConnect chain at all. they are being "swallowed" before they get to FSUIPC's logging. I explained that this is what I thought must be happening if you recall. FSUIPC can do the same sort of thing -- steal controls before anything lower in the chain can get them. This is how it can re-map some of the axis controls, for instance. Your stream of other events happens with some aircraft gauges -- usually they are repetitive and very very wasteful of FS performance. I don't know why some aircraft designers do such things. I'd avoid such aircraft myself. Yes, as I explained in a previous message which it now seems you must have missed? Your aircraft code receives it at a high, maskable, SimConnect level and prevents it being passed down to FS code. It must be simulating its own flaps, not wanting FS code to interfere. Regards Pete
  11. It's almost that easy, but FSUIPC4 uses DirectInput for the axes whilst FSUIPC3 uses the older Windows "joy" interface. The two don't quite match up. You will need to check. FSUIPC's "XYZRUV" names for axes don't quite match in the same way. Your X/Y (e.g. aileron and elevator) should be fine, but check the others. Some assignment editing in the INI might be needed. Regards Pete
  12. ErC is probably the most powerful high-level programming language in terms of scope and flexibility, so I don't really know where you are coming from with that statement. I started with assembly language (well machine code originally) and C is about as "high" as I want to get because I find other languages definitely limited in comparison. But a long list of calls to a "generic read" procedure, followed by a Process call, then a long list of extractions of variables with specific types, seems much more cumbersome than a simple list of FSUIPC_Reads into the correct variables in the first place, followed by one Process call, and you are done! You seem to be wanting to make it complex and long-winded for some reason I don't understand. As I said, if you want to engineer your own style of interface, do please look at the source code for the library calls. They build up the requests in an irregular array as it is. If you want to go down that route you can bypass the FSUIPC_Reads and Writes and build the data structures yourself. Just make sure they follow the rules you'll see implemented there. If you are simply trying to make something data- or table-driven, possibly with parameters like offset, size and type specified by external data input, then I can see where you are coming from. But you'll need some sort of data type code and use that on a switch both for data length and variable receptor type. This is basically how FSinterrogate works -- I assume you've played with that? It is in the SDK. It was written in Delphi by Pelle Liljental. Regards Pete
  13. If you wish, but this is really what the FSUIPC_Read procedure is doing internally in any case. Why bother? You are replacing one call to FSUIPC_Read, to get your value into a variable you can use directly, by a call with parameters into another procedure of your own which is then doing the FSUIPC_Read, and, on exit, following the FSUIPC_Process, you still have to access the correct type in the correct element of your array in order to use the values. It seems a rather inefficient and long-winded way of doing something which was deliberately made simple by the library provision of the FSUIPC_Read, Write and Process calls in the first place. If you simply don't like the mechanism provided for you why not interface directly to FSUIPC, not using the library calls at all? The library source is provided in the SDK so you completely at liberty to do as you like at a lower level. The Process call should be once per cycle, not "after a certain number of read requests", unless you are talking about building up requests involving more than 30 kbytes! You should be basing your actions on a polling cycle like 20 - 100 mSecs, or longer is you don't need such resolution. Regards Pete
  14. Well, I'm glad, but I can't understand how any conflict on the controllers would cause SimConnect problems such as those logged. Are there now no errors in the log? The normal symptoms of dual assignment of joysticks etc are unpredictable axis changes, that's all, not a raft of failures. Regards Pete
  15. Ouch, ouch, ouch! There's some sort of SimConnect or AI traffic problem there. And FSUIPC never sees the Sim as "ready to fly". I don't know if the two are connected, but it smells like some sort of corruption somewhere in your FSX installation. Apart from all of the SimConnect errors reported, these "Ready flags" show no sign of allowing flight to continue: 2558 Ready Flags: Ready-To-Fly=N, In Menu=Y, In Dlg=Y ... 101869 Ready Flags: Ready-To-Fly=N, In Menu=N, In Dlg=N ... 138934 Ready Flags: Ready-To-Fly=N, In Menu=Y, In Dlg=Y 138934 Sim stopped: average frame rate for last 37 secs = 9.7 fps 142881 Ready Flags: Ready-To-Fly=N, In Menu=N, In Dlg=N ... 164441 Ready Flags: Ready-To-Fly=N, In Menu=Y, In Dlg=Y 164441 Sim stopped: average frame rate for last 21 secs = 9.8 fps I've never seen anything quite like that before. You say you've changed nothing? Not installed anything new? I'm not sure what to advise here. Are you using default AI Traffic? Are you using many add-in programs (those loaded by SimConnect as EXE or DLL modules like FSUIPC)? I might be able to glean more information from a SimConnect log file. There's information on how to get one of these in the FSX Help announcement above. You could also update to the current interim FSUIPC4 release you'll find in the Updates announcement, though I don't think that will make any difference. If you get a SimConnect log, don't post it here -- it will be very large. ZIP it and send it to petedowson@btconnect.com . Regards Pete
  16. A couple of things worry me. After this stage: 4290 Initialising SimConnect data requests now 4290 FSUIPC Menu entry added 4383 \\PETER-FSX-PC\Users\peter\documents\flight simulator x files\EHAM default.FLT 4383 \\PETER-FSX-PC\FSX\SimObjects\Airplanes\Aircreation_582SL\Aircreation_582SL.AIR 412279 C:\Users\Peter\Documents\Flight Simulator X Files\KEWRKATL.PLN there should be entries like this: 107328 Advanced Weather Interface Enabled 107703 System time = 27/05/2010 12:59:13, Simulator time = 12:57:40 (11:57Z) 108032 Aircraft="Boeing 737-800 Paint1" The fact that these are missing indicates that FSUIPC never saw your Sim "ready to fly" -- it looks as if you closed the session from the opening menu. It never even identified your Aircraft title. Until the sim is fully ready-to-fly WideServer won't be started. Same goes for many other FSUIPC services. If you think it was, I'll need more information. Edit the INI file and change "LogExtras" from "No" to "Yes", then run FSX again. Show me the log again please. The extra logging will show me if FSUIPC ever got a "ready" message from SimConnect. The other worry is your frame rate: 553944 Sim stopped: average frame rate for last 54 secs = 9.8 fps Is that your normal average, or is that just because of the start-up loading et cetera? Regards Pete
  17. Show me the complete FSUIPC4.LOG file please (with FSX terminated), and the WideServer section from the INI file. They aren't relevant. Regards Pete
  18. Okay. just as well. It seems that if I use the CREATE_NEW_PROCESS_GROUP flag, it disables CTRL-C signals to your process. I'd still be able to send Ctrl-Break though. Regards Pete
  19. I did explain what it does -- it sends a WM_CLOSE message to the process's main or only Window handle. The problem is presumably that you don't have a Window. Does a console have an HWND? The method used is to keep the thread ID from when the process was created, then, when it comes time to close, to enumerate the thread windows (EnumThreadWindows), sending a WM_CLOSE message to all top-level Windows thus enumerated. This method has worked without problems reported for twelve years now. If you know of some way for me to get you the signal you need, please tell me and I'll add this to the CLOSE actions in FSUIPC (and WideClient). The most likely thing I've come up with so far is: GenerateConsoleCtrlEvent(dwCtrlEvent, dwProcessGroupId); It looks like this can send either a CTRL_C_EVENT or a CTRL_BREAK_EVENT. To get a Process Group ID I'd need to set the CREATE_NEW_PROCESS_GROUP flag in the CreateProcess call. Do you want me to try this for you? If you think it might work I can add it to an interim version of FSUIPC (FSUIPC3 or FSUIPC4?) for you to test. Note that you can ignore Ctrl-C but not Ctrl-break, but which one do you need? Or both, one after the other? Regards Pete
  20. The Lua "event.control" check is performed in the exact same place, where Events are intercepted, as the Events are logging in the FSUIPC4 log file. Are you saying that the log shows the event but it isn't triggering the Lua call? (I'm talking about the event logging which gives lines starting "*** EVENT: Cntrl= ..."). If so I don't understand how that could happen as the two parts are inseparable in the code. The Lua call occurs in the next line of code after the Log entry is written. If the log entry is not occurring, then your aircraft is intercepting the event and swallowing it at an even higher priority than FSUIPC does. I've not seen that before -- the FSUIPC priority is highest. In order to do that it evidently must get in the chain before FSUIPC (naturally, I suppose as Gauges load later). There's really not much i could do about that. Regards Pete
  21. The third parameter is merely a pointer to an array of bytes to receive the data. Their is no type for the data exchange as such. The type is set by the way you read it. Strings have to be read into strings or character arrays, integers into integers, and so on. The "double" floating point reception you are giving everything is completely wrong for nearly everything available in the FSUIPC interface. Only those entries which are 8-bytes in length AND which are specifically documented as being a double or floating point are in this format. As I said, you don't pass any types to the function, only a pointer to a receptacle, an area of memory to receive any sort of data. If you want generic code you could define a union to hold all types in one place, thus: union { double d; __int64 n8; BYTE b; signed char ch; WORD w; signed short s; DWORD dw; int n; char str[256]; } genericvalue; FSUIPC_Read(param_offset, param_bytes, &genericvalue.b, &dwResult); Then access whichever member of the union is appropriate to the value. Please remember, however, that it is extremely inefficient to do lots of FSUIPC_Process calls. You should do all of the reads and writes and then one process call per cycle. The reads and writes merely build up the request list, but the process sends messages to FS and has to do a process switch. If you are doing a generic read into one location, you can obviously only do one per process. That's too inefficient. You'll slow your program down and FS. You'd need to define a different location for each read, so defeating the "generic" option you seem so keen on achieving. Regards Pete
  22. Sorry, I don't know POSIX. How are you getting such "signals" under Windows? How do you normally terminate your program? I can look at providing other methods, but only ones which can be instigated through Windows. If you know how it is done, let me know and I'll see if i can add it. I looked at your reference http://en.wikipedia.org/wiki/Signal_%28computing%29 and this talks either about sending keystrokes to it (which I wouldn't know how to do because there's presumably no Window handle and therefore no way to set focus or send keyboard messages), or using the Kill facility which you already tried. It does also say, however, "The kill(2) system call will send the specified signal to the process, if permissions allow ", and lists a SIGKILL signalcouldn't you use my KILL option and process that signal? Regards Pete
  23. Did you get it working okay first without detentes? Unless it is properly calibrated without detents then you'll struggle to get the detentes set correctly. That's almost always due to having more than one assignment to the same function, i.e. in this case the flaps. You must make sure it is only assigned in one place -- FS or FSUIPC, never both at the same time. Regards Pete
  24. No, nothing wrong unless it says there's something wrong. Remember, it did say the omission of the SimConnect.xml was okay, and the searching for FSX.CFG was successful otherwise you'd have had an error and a prompt. Pete
  25. If it is only a T8 or P8 unit, the ones with 8 buttons/switches and indicators, the Lua logic for driving the indications on those is pretty easy -- nothing to worry about. I can help with those if you wish. But certainly dealing with a complete MCP or radio is not so easy. GF have now sent me an MCP Pro so when I get a little time I will be working on the complete Lua example for that unit which I promised last year. 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.