Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. I think there used to be, but only if you purchased the older version not long before. I think it was 6 months. The purchase pages on SimMarket might tell you -- if not, there isn't one any more. It really isn't a lot to do with me, but I think it was was more of an incentive to get folks moving over from FS9 to FSX so we didn't need to maintain both versions for too long. Didn't work! ;-) Pete
  2. Those values represent the absolute maximum range which can be accepted by FS. Those are the values you'd expect AFTER calibration. So, where are you actually reading those numbers? And how are you assigning the axes? The input values shown in the Axis assignments tab in FSUIPC options are those supplied by the joystick drivers, directly, with no manipulation. FSUIPC cannot invent values outside of the range shown there. But the values you mention are so ideal that I find it difficult to believe they are the raw input values. Please also state the version of FSUIPC (and the version of FS for that matter). You should be using 3.999z for FS9 and before, or 4.86 for fSX and P3D. I'm afraid it is late here now and I'm off to bed. I'll check your reply in the morning. Regards Pete
  3. You reported tw messages, with different lists of FS DLL modules. I've a feeling that you are reporting the message incorrectly. Well, if you want to fly FS9 you would need to fix it. You don't normally need to reinstall any add-ons when reinstalling FS -- unless you delete things first as you seem to have done in error. Pete
  4. If you've already bought WideFS, it will still be yours after any updates to FSUIPC. Updating does not cancel your purchases. If you have not purchased WideFS yet, then you would need to purchase it if you want to use it. This has been the case throught all versions since 2003. Regards Pete
  5. Two important points here: 1. NEVER EVER post your confidential Key! 2. There can NEVER be more than one copy of FSUIPC.DLL (or any other DLL) in one single folder -- Windows does not allow two files with the sames name! So I am sure you are mistaken. None of the DLLs listed are "add-ons" and none of them are in any way related to FSUIPC. They are all parts of FS itself. Evidently you deleted some important parts of FS! There is NEVER any need to delete ANYTHING before installing FSUIPC! You should have simply followed the installation instructions! If you are now missing parts of FS because you deleted them you will have to reinstall them. If you have a back up copy of FS, copy the contents of its Modules folder over to the active copy. Otherwise you need to reinstall or repair FS. Pete
  6. Sorry, no notifications. Just check here in the Download Links subforum whenever you have cause to ask a question or report a problem. Last year there were over 50 updates, and you don't need every one, but it always helps to make sure you are up to date when requesting support, as then we are both on the same page, so to speak. ;-) As an example, there's already a 4.861, but it is for a minor addition (a thread near here carries it, only, at present). Pete
  7. Okay. I've added all 4 remaining values, in spare offsets as follows: 081E, 1 byte, Boolean, ROTOR BRAKE ACTIVE 081F, 1 byte, Boolean, ROTOR CLUTCH ACTIVE 0820, 1 byte, Boolean, ROTOR CHIP DETECTED 0821, 1 byte, Boolean, ROTOR GOV ACTIVE These are in version 4.861: download it using this link: FSUIPC4861 Regards Pete
  8. Two things: 1. Version 4.852 is out of date and not supported. Please update to the current release, 4.86. 2. FSUIPC does nothing unless you tell it to, so it sounds like you have lots of incorrect assignments, possibly dating from a previous hardware add-on? Detelte the FSUIPC4.INI file from your FS Mondules folder, and start afresh. Pete
  9. Okay. These are the variables I can get for the R22 through SimConnect: ROTOR BRAKE HANDLE POS *** Percent actuated Percent Over 100 ROTOR BRAKE ACTIVE Active Bool ROTOR CLUTCH SWITCH POS *** Switch position Bool ROTOR CLUTCH ACTIVE Active Bool ROTOR TEMPERATURE *** Main rotor transmission temperature Rankine ROTOR CHIP DETECTED Chip detection Bool ROTOR GOV SWITCH POS *** Switch position Bool ROTOR GOV ACTIVE Active Bool ROTOR LATERAL TRIM PCT *** Trim percent Percent Over 100 ROTOR RPM PCT *** Percent max rated rpm Percent Over 100 [/CODE] If what you need is amongst those I can add them. Currently I supply those I've marked ***. No one has asked for the others before, and they weren't availbalbe in FS9. Regards Pete
  10. Thanks. Is it the same wording for FSUIPC3 and WideFS6? Pete
  11. Use the "REV" checkbox in the FSUIPC calibration. That's what it's for! You'll need to re-calibrate afterwards. Pete
  12. What version of FS are you talking about? Are you sure the SimKits implementation didn't derive these warnings from whatever values are measured to sgnal them? That's how most warning lights are driven in the FS gauges themselves. If you can be more descriptive I might be able to help -- I don't really know what "main, and tail rotor gearbox chip" means nor what the warning is telling you. Some measurement going too high or too low, I would guess, and that is probably the only way to detect it. Pete
  13. Okay. Don't forget, I will help construct a plug-in to play a sound when the trim value changes. If you want to have a stab at it, check the Lua library documentation. You'll need the event.offset function, referring to the trim offset, a WORD value at offset 0BC2 (you'll see this if you check the FSUIPC Offsets list -- if you've installed FSUIPC 4.86 you'll find one in your FSUIPC Documents folder), and the sound functions sound.play, and sound.query. The entire plug-in would only be about 6-9 lines long. You'd have it loaded atomatically when FS starts, either via ipcReady.lua, or by using the [Auto] facility in the INI file. Regards Pete
  14. It does and is already integrated, and always has been. They work together, completely. Any PFC button or switch can be overridden by assignment in FSUIPC, and all of the PFC axes can be assigned in FSUIPC. You would simply need to disable in PFCFSX the axes you assign in FSUIPC. Most of my own 737NG cockpit is "legacy PFC", as you put it, and it works extremely well. There are also bits of the new USB ones, driven by my PFCHID.dLL, and my overhead is by Cockpitsonic driven by another of my modules. All these additional modules are free and I get no income from any of them, only from FSUIPC and WideFS. I wrote the drivers for my own use, because i had the hardware and did not like the original drivers. The PFC drivers i wrote are simply extensions to FSUIPC. The USB equipment now supplied by PFC is handled by another extension, "PFCHID.DLL", and the Aerosoft (Australia) Piper cockpit is handled by another. In fact there's a range of add-on drivers for a range of different equipment made by several different firms, even including the now antiquated EPIC and FlightLink stuff. If I put everything into one bloated add-on no one would be pleased! Regards Pete
  15. Oh, of course it can be done. If you know what offset contains the event acting as a "trigger", then a short Lua plug-in could be written to play a wave when the trigger is set. This plug-in would have an event.offset function call for that offset, which executes a function which uses the sound.play function to play the sound. It isn't difficult. There are lots of examples of Lua plug-ins supplied in your FSUIPC Documents folder, and a lot more in the User Contributions subforum here. And i can help too. You need merely to identify the trigger and the sound you want to play. Sorry, very little of that makes any sense at all to me. Maybe you need to talk to ProSim support about this? There we go again. You are persisting with your misunderstanding of offsets. Offsets contain DATA. "Trim Up" and "Trim Down" are actions, or commands, or controls if you like. Not "data". You can read, from an offset, the current trim value, and therefore see when it changes. But if you play a sound lasting, say, 1 second, and you change the trim value say 10 times a second (quite easily), it gets complicated. With a simple plug-in you'd end up playing the sound ten times simultaneously, overlapping. so you'd need to also test if the sound is already playing, and avoid starting it again. I can help with this if you wish. You'll need to identify the sound wave file. Wouldn't the best place to ask be the ProSim forum then? ... Ah, I see you have. Didn't they understand you there, then? Pete
  16. Hmm. "Offsets" really don't have anything to do with sound. But how do you trigger the sound to play? What are you hoping to use for this. There's really no such thing as a "bit number" of 050A. That number is hex for decimal 1290, and there are no numbers used in any computers I know of with that many bits! A "normal" integer in an x86 computer has 32 or 64 bits. If you meant to say "offset 050A" then that is an offset assigned to Project Magenta, with individual bits assigned to control certain actions in the PM MCP such as TO/GA. I really dn't know where you are getting your odd information from. I've no idea about what ProSim is asking, but the CONTROLS listed in my documents in the 65535 and upwards range are simply the FS commands or controls which you can assign in FSUIPC or in FS iself to buttons,, keys and axes. There are hundreds of them and not to be confused at all with offsets. you dont "input" "offset nmbers"! They are merely references to data positions, as I already explained. No no no. Those are NOT "offsets" but "controls" or commands if you like. Some MS documents calles them "events" or "key events". They are all actions, not data. The complete list of FS command names and numbers is provided for you in a PDF in your FSUIPC Documents folder. I think you should explain what it is you want to do. If you want to trigger a sound, provided by you in the form of a wave file, then the only facility my programs provide for this is via Lua plug-in programming with the Lua sound library functions. you can certainly play any sound using that and trigger itby a value in an offset of by a key press or axis movement. Pete
  17. Sorry, I think you misunderstand. "Offsets" are just numbers -- the distance in bytes, in a block of memory, from its base to the position of some data or functional facility trigger. There's no possibility of any general tutorial on them because there are many different forms of the data and facilities, for doing different things. What you really need to do is state what you want to do and ask advice on how to do it. There's no other way. You need the purpose first. Pete
  18. Is this the same with a default aircraft too? Sounds like the settings for that aircraft profile might be corrupted. Have you checked the assignment and calibration in the Options? That's the first thing to do. Not the whole INI, just the [Axis] and [JoystickCalibration] sections for the Profile you are using for that aircraft. Please also, first, make sure you are using the current version of FSUIPC -- 3.999z for FS9 and before or 4.86 for FSX and P3D. Regards Pete
  19. Sorry. But they are all the same size, throughout all of the options. Pete
  20. Well, that's evidently ambiguous. I don't have anything to do with the product page, but i would guess it is intended to mean that if you have a registered FSUIPC the key must relate to the same name. Pete
  21. You posted a support query in the FAQ subforum. I've moved it to the proper place, the Support forum, so it can be answered. Please use the Support Forum next time. As the Installation Guide included in the download ZIP actually tells you, all the documentation, including the User guide, is provided in the FSUIPC Documents folder, in your FS Modules folder! As a "new user" you would do well to read the one document actually provided in the download ZIP, surely? Pete
  22. Looks like a firewall issue. The server isn't seeing the client at all. You either need to disable the firewall or let the FSX.EXE and WideClient.EXE through. Regards Pete
  23. Seems you need to ask at their Support Forum then. Regards Pete
  24. Correct. A Lua script finishes and disappears from memory if its execution runs off its end, past the last line -- UNLESS it has an "event" command which keeps it in memory ready to respond to the declared event(s). The only other way of keeping a script in memory is having it running all the time, in a loop.(eg with "while ..."). But that isn't generally a good idea, though it does have its uses too. 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.