Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. When you install FSUIPC, it places a number of documents, including its User Guide, in the "FSUIPC Documents" folder in the FS Modules folder. This, and the list of documents installed, is documented in the Installation instructions. One of the documents is a list of FS controls, in both alphabetical and numerical order. Pete
  2. Why did you install the FSUIPC4 Loader? Did you not read the Installation instructions? That is only for special circumstances and generally not advised. Remove the FSUIPC Loder DLL from the Modules folder, then re-run the Installer. Pete
  3. Sorry, that was just a typo. I did not know what "FSC 4-3" was. I don't criticise foks for their typos!! Aha, so not when "trying to extract the EXE". Was that a typo? ;-) So, where is the EXE when you run it? It must be in the main FS folder, where the FS EXE is. Next to MakeRwys.EXE there will be a Runways.txt file. That is the Log. It will show you (or me) what is wrong. Pete
  4. Sorry, I don't understand one word of that. Do you mean you cannot extract the EXE from the ZIP? What does "FStarRC rwy files gender" mean? It isn't one of my messages. What is "FSX 4-3"? Pete
  5. I'm not sure what to advise at present. It sounds as if the TCP/IP buffers on the Client are filling up and not being freed. Those are a function of the Windows network drivers. Could you try UDP protocol, to see if it makes a difference? It's only problem, used with something like Radar Contact, is that the sequence of data packets can get out of order, and any bad packets will simply be discarded. However, anything serious in that should be reported in the log, even without extra loogging. Pete
  6. The currently supported version is 4.942. The "cut-and-paste" advice really applies to all three parts. Folks seem to have many ways to spell their names, and also sometimes change email addresses and forget that the registration stays with the original one. Pete
  7. The only way to get a message on the screen is either by writing a program interfacing to SimConnect directly, or easier, a Lua plug-in writing to FSUIPC offsets. Yes, 32FA and 3380 are the offsets to be written. The message is written to 3380 and then you write a control value (defining things like how long the display should stay, and whether it should scroll) to 32FA. The relevant Lua functions are ipc.writeSTR(0x3380, "string to be displayed") ipc.writeSW(0x32FA, controlvalue) where, for example, the controlvalue would be 3 for a 3 second display. You can have a small Lua plugin, with just those two lines, for each mode, and assign that Lua to the button (plus condition if applicable) which sets that mode. Of course, alternatively, or as well, you could use the Lua sound library to play a wave file, annunciating the mode. Pete
  8. Ah, you should have said that! ;-) So what is the "straight on" value for their tiller, then? 8192? Right, the spoiler internal value is never negative. But assignment in FS would get the range -16384 to +16383 also for the INPUT from the device. It is how FS then applies it to the spoiler which uses 0-16384. And FSUIPC does the same when you calibrate -- check for yourself. If they are reading the axis directly, and not the Spoiler value, I'm not sure how they manage for non-FSUIPC users because there will always be a negative range. How are you assigning? Are you calibrating? You can scale any axis input to FSUIPC using the scaling parameters you can add to the axis assignment line in the INI file. This is covered in the Advanced Users guide. To convert a range of -16384 to 16383 to 0-16383 just use *0.5,+8192 Thay's actually one of the examples in the doc (page 37 I think). Pete How are you actually assigning it?
  9. Yes but if pressed momentarily, not held down with repeat enabled, you could lessen the fierceness somewhat. Not easy though. Pete
  10. PLEASE please only post support questions here, to the Support Forum, NOT to a subforum like FAQ! You are making an error. Don't just cut and paste the key, do the same with your name and email. ALL THREE PARTS must be exactly right! In future please state the actual version number of FSUIPC, do NOT just state "latest version" (folks have said that and found to have been using a year old one -- the "latest" they'd actually noticed), Pete
  11. If you are using Win7 and you get control disconnections even with Windows USB power management disabled, then I can only think it is faulty hardware somewhere -- device, cable or USB chips. Evidently, whatever it is, it is intermittent. Pete
  12. Sorry, I don't know how you expect an axis assigned to spoiler axis can ever control the tiller! About the 'range' of the inputs: Depending on what controls you assign to, either FSUIPC takes care of mapping -16384 - +16383 to the range needed by the control, or FS itself does. Generally ALL commercially made axes, calibrated in Windows, have that range. It is the way it is interpreted which makes the difference. Even FS's default throttles have no -ve range themselves -- the -ve input part is mapped, so that -16384 is idle (0 internally). The only throttle controls with reverse as -ve are the old FS98 ones, which FSUIPC uses when using reverse zones. Pete
  13. Seems it's still early days for Win10. I expect it'll improve with time. I think I'll stick to the brilliant Win7, at least until the 12 month free upgrade period for Win10 is nearly up! Pete
  14. If you are not calibrating in FSUIPC, merely assigning, then it is only doing exactly the same as FS would do. So deleting INI files or changing versions accomplishes nothing, it changes nothing. All of the problems reported with Saitek devices concern complete loss of input from them. It must be something to do with power, but that is usually easily fixable in Windows 7. It seems to be Windows 8 and 8.1 users with all the problems. Are you on Win8? Thought about taking the free upgrade to Win10? That might do it. Pete
  15. There are no errors detected by WideClient. over a period of nearly 10 hours! Total time connected = 35637 seconds You fly in real time for 10 hours? Phew! Not sure why you bothered showing the FSUIPC log, which has nothing to do with the networking part. The WideServer log is relevant, of course, but you don't show that. It sounds like something in the client application's process is getting corrupted, or there are memory problems on the client PC. Certainly nothing looks amiss on the WideFS side. BTW the currently supported version of FSUIPC is 4.942. Yours is out of date. Pete
  16. Something else changed, then, most likely to do with the USB power to the device. The "Exclude THROTTLEn SET" and "Sync Pos" options are totally ignored when the axes aren't processed. When the axes aren't processed they are not even intercepted by FSUIPC, they just get sent directly to FS, exactly as when assigned in FS. The complete calibration section doesn't apply to axes which aren't processed because they aren't even seen! Pete
  17. Version 3.999z4 is not the currently supported version of FSUIPC3. You should install 3.999z8 or 9. I don't recognise the code. What language is that? What is "token"? Why aren't you checking the assorted results? Maybe those would tell you something? In the C/C++ version of the Interface, which is what I understand, the data is provided in a variable and the FSUIPC_Write call provides a pointer to that data and a length (i.e. number of bytes to write). I don't see that in your code. Is that the whole program? Haven't you opened a connection to FSUIPC? Try using FSInterrogate to read and write offsets first. It's a good way of learning what you can do, and it will also test that you are doing it correctly. You should also be using the Logging facilities in FSUIPC, which are available to you even in an unregistered install. Pete
  18. It's a common Windows 8 problem. I suspect there are ways of stopping it happening so frequently, Windows settings to turn power management off, things like that, should work, but I think there are some more harder-to-find settings. And it may be fixed in the free upgrade to Windows 10, but we are still awaiting feedback on that. For some reason it seems to afflict Saitek devices much more than any others, although that might be just because there's a lot around. Perhaps some other users can help. And you might try the Saitek support forum. BTW, not that it'll make any difference in this matter, but the currently supported version of FSUIPC is 4.942. Pete
  19. It's a bug in SimConnect, during the closing down sequence, in some of the later updates to P3D. It's definitely fixed in the next release of P3D but I'm afraid I don't know when that'll be. It was actually quite difficult to track down the precise cause as it tends to be intermittent -- on some systems it may be 100%, on mine it was 50:50. But L-M seems to have fixed it since the last HotFix to 2.5. Luckily, in the meantime, is does no real harm except possibly not getting the Prepar3D.CFG file updated with any setting changes you made. Pete
  20. Use toe brakes. Pete
  21. There are several add-on aircraft which do their own processing of throttle input controls. You might have to assign to the regular throttle controls instead (axis throttleN set). You can still assign in FSUIPC, and of course using Profiles you can have different assignments for different aircraft. if you must write to an offset, rather than assign an actual joystick input to a control, you could use one of the offsets in the 3BA8-3BC4 range, THEN assign in FSUIPC. (Those offsets are like regular joystick inputs, assignable). It might also be useful to ask such questions over in the A2A support forum. Pete
  22. If they work okay in other aircraft, then the most likely reason is that this aircraft likes to see the actual FS controls, at the top interception level. If so then you can assign in FSUIPC, but only to the FS "axis..." controls, and you probably won't be able to calibrate in FSUIPC. It might be worthwhile asking in the iFly support forum. Pete
  23. Okay. i don't see there any reason why the event.cancel would fail ... but: How does the error in even.cancel get logged if P3D crashes? Is there are time difference? Perhaps you should show me the Log file from FSUIPC? Well obviously something has changed, but it certainly is not anything in the event.cancel facility. The most likely thing is something else is corrupting something in memory which destroys the listed function being cancelled and probably results in P3D crashing. But there's no way in the world I am ever going to be able to determine what is wrong with virtually no information. I need the Windows crash data and the FSUIPC log file. I ALWAYS need this sort of information, there is rarely any point at all in reporting a problem without providing such data! You should note that you have many commented out uses of event.cancel in that Lua plugin. Do ALL of those you've commented out cause the same problem? You also have two not commented out: event.cancel("Boarding") event.cancel("Catering") Really? Are you sure you know where to look? The Windows event viewer retains error data for a long time. Why would you deliberately delete it all? No, I don't think it's specifically directly related to Lua, which has not changed. I suspect something else is causing some memory corruption. It may always have done, but just different versions of compiled code place data in differet locations. Please also confirm which version of P3D this is with, and whether it happens without changes in P3D or other addone or sceneries. I can't do anything about this at all without more information. Pete
  24. Thanks Thomas. The OP will have to see if the PMDG implementation does this. Best Regards Pete
  25. First, please PLEASE always post support questions to this, the Support forum, NOT to subforums like "Announcements". Strangely, "Announcements" is actually for Announcements, and you'll get no answers there! I do not understand an Event value like x1000148A4. Are you sure that should not be just x148A4? The very high bits might be ignored, but I don't think they should be there. No, sorry. I don't have any PMDG aircraft installed. If you mean the 737NG then I think you can get all the event values from the .h text file found in the PMDG SDK subfolder installed in your NGX folders. If you cannot find the details I suggest you ask in the PMDG support forum. 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.