Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. FSUIPC itself cannot identify the crucial defining part of an aircraft name, it just has to use whatever it is given. However, you can make life much easier for yourself. All you need to do is check that "ShortAircraftNameOk=substring" is set in the [General] section of the INI file, then, in each of your [Profile.<name>] sections shorten the aircraft name to whatever identifies it sufficently. For example, if all 737's should have the same Profile, set the name in the list to 737. Remove, then, any unnecessary duplicates. Sorry, but there is no way FSUIPC can do such things automatically. The name of an aircraft is just an arbitrary string. Only you can determine which parts really matter. Regards Pete
  2. Once you've selected a Profile for a specific aircraft name, then that aircraft is listed in the INI file as belonging to that Profile. This is entirely automatic. Either you are loading a different aircraft (one with a different name, eg livery) each time, or possibly your INI file is corrupted and the updating is going wrong. I've never heard of the latter occurring in this way, but if you think this may be the case, paste the INI file contents into a message here and I'll check. If you've ever edited the INI file yourself with something like WordPad or a word Processor it may be in completely the wrong format, and that would certainly cause problems which are difficult to spot. The latest updates to both FSUIPC3 (3.999b) and FSUIPC4 (4.801) are able to correct for this mistake. You can get those in the Download Links subforum. Regards Pete
  3. Not at present, sorry. It hasn't really been a frequent enoguh need to warrant the extra complications. You need to find the [Profile.<name>] section in the INI and remove the aircraft name from the list below. Actually, I've not tested this, but I think it might work without doing that if you make sure that aircraft is not currently selected in FS, make the INI change, then go into the FSUIPC options (one of those where your aircraft has specific settings, like buttons, Keys, Joystick or Axes) and select the Reload button. Regards Pete
  4. All three parts, not just the Key, but also name and email, must match EXACTLY. You are making an error. I've no record here of that number for FSUIPC3 ot FSUIPC4. If entering the correct details doesn't work you'll need to check your purchase or raise a problem ticket with SimMarket. Regards Pete
  5. Best ask them, then, to support the mousewheel as you wish, because i'm not hacking into third party programs. They probably use SimConnect object manipulation facilties in any case, which is an application not an interface function. Have you not even tried the facilities I put into FSUIPC4 yesterday at your request? :-( Pete
  6. Okay, try version 4.801, now available in the Download Links subforum. Here's a summary of the new facility: -- added "mouse wheel move" option, in Miscellaneous tab. This enables use of the mouse to change the eyepoint, using the mouse wheel. Forward/back on the wheel, left/right if you have a left/right enabled wheel and are using Vista or Win7. Note1: pressing the wheel (middle) button in wheel move mode resets the eyepoint. Note2: if wheel trim AND wheel move modes are both enabled, trim mode defaults, and you can swap between them by double-clicking the wheel (middle) button. Note3: if mouse look mode is in use then the wheel operates the zoom as usual. The left/right facility on the Wheel is actually only available on a number of modern mice, and only owrks in Vista or later, not in XP it seems. I think this modern addition is one reason I was initially puzzled. Regards Pete
  7. Okay, we have to go back to basics on this: The arrow keys in my install of FSX operate Elevators and Ailerons. They are used for flying the aircraft without a joystick. Therefore I must assume either that the add-on you are using interprets them differently for its own actions, or that you have reassigned these standard keyboard functions to other FSX controls. I have investigated the mouse programming side of it, and it is easy, no problem. If folks had this "move" facility enabled and the mousewheel trim option both selected I would probably implement the centre mouse button (mouse wheel click) as a request to toggle from one to the other. However, I simply do not know which controls, if indeed there are FSX controls, to program to get the results you are asking for. Please therefore enable Event logging in the FSUIPC Logging tab, and use the four arrow keys, and either tell me what it shows, or paste the resulting Log file into a message here. Then I'll see about adding the functions. [LATER] Aha! It's okay, don't bother. The FS controls are Eyepoint Forward, Back, Left and Right. I tried assigning them to the arrow keys, and they work fine in VC and VC Slew mode, but do nothing in 2D Cockpit mode. Question, though: how do you regain your original position, or don't you care? There is an Eyepoint Reset control. I should really implement that, maybe on mousewheel press, but that gets a little complicated for the user if I also use that fr mousewheel trim toggle. What did you have in mind? Maybe centre button double-click = toggle, single click = reset? Regards Pete
  8. Thanks for the FSUIPC and SimConnect logs. It most definitely looks like SimConnect is stalling, possibly due to memory problems, but I cannot tell. You have a lot of SimConnect clients running simultaneously. Here's this list of those connected with open transactions: I don't know which programs some of them are related to, though. The number on the left is the SimConnect-assigned ID. This list is the order they connect: 64 System Event 65 Couatl 66 Aivlasoft 67 Addon Manager 68 VimaCore 69 PMDG Options 70 PMDG Events 71 PMDG Sounds 191 Squawkbox AI control 190 <one with no name!> 72 IVAO Ivap bootstrap 73 FSUIPC4 189 Squawkbox Transponder I find it a little odd that you have both IVAP and Squawkbox running, though I suppose they shouldn't conflict. The time SimConnect records for FSUIPC4's connection is 18.15 seconds after SimConnect starts. This equates to something between 13.16 and 13.65 seconds in the FSUIPC4 log. Going then to the end of the logs, which you say should take us to a couple of seconds after it appeared FSUIPC stopped, the SimConnect log finishes at 1105.49 seconds whilst FSUIPC is continuing to operate, receiving and logging Writes from the aircraft, at 1163.48 seconds, -- actually 63 seconds AFTER Simconnect appears to have stopped logging, allowing for the 5 seconds difference in the two timings as noted above. Scanning back in the FSUIPC log I note that the aircraft writes had been looping doing the same thing -- disconnecting both throttles and setting both to almost idle. It had been doing that since time 1093.26 seconds, before which the throttles were still disconnected but being slowly reduced from their previous maximum at 1084.64 seconds. These times relate to times 1088 and 1079 seconds in the Simconnect log, whilst Simconnect was still actively logging. Hence my conclusion that Simconnect is actually stalling, which makes me again question the activity of the Aivlasoft EFB, which you claim is still registering the positions of the user aircraft and the AI traffic even after this apparent stall. The SimConnect log records the last interaction with the EFB at 1104.64 seconds, shortly before the stall. What I don't understand, however, is why, when SimConnect stalls, FSUIPC doesn't time out the arrival of data from it and log this and attempt to reconnect. That's what it normally does. So, to determine what FSUIPC sees of SimConnect from its viewpoint, could you possibly do another FSUIPC4 log please? Edit the FSUIPC4.INI file 9with Notepad or a basic text editor), remove the "LogWrites=Yes" line and instead add these lines: Debug=Please LogExtras=x4411 Let FS run a bit longer after the apparent stoppage -- say a minute, not 2 seconds -- and again please ZIP the resulting FSUIPC4 log and SimConnect files and send them as before. Thanks, Pete
  9. Same as any other offsets. Or are you asking how you interface to FSUIPC? The interface to FSUIPC for reading/writing offsets is defined in the SDK. If you are using .Net you might find Paul Henty's "FSUIPC Client DLL" method the easiest way. However, if you are trying to interface to FSUIPC from a DLL or Gauge file within FS itself, I don't think you'll be able to use a Managed language like C#. Regards Pete
  10. Just to finish this thread off with a conclusion: The crash in 3.999 with your INI file wasn’t due to any corruptions – those could have been tidied up automatically. The problem was that the INI file had been edited and re-saved in Unicode format, not plain ASCII. This really wrecked it as an INI file. Although it did not crash 3.991 it was mostly effectively ignored. When editing such files, please only ever use a plain text editor, not WordPad or any Word Processor. In version 3.999b, now available in the Download Links subforum, I’ve added a check for this incorrect encoding, and do an automatic conversion. However, this does take a little while longer. It will then save the corrected file. There were some other problems. Some of the Aircraft names had “[DXT3]” in them. The [] brackets would have stopped Windows recognising the Sections correctly, so even on 3.991 or earlier those aircraft might never have actually had their assignments loaded. I’ve fixed this too by checking for extra [] inside [] section names and replacing them by (), which will let them match correctly. I'll be making the same improvements to version 4.8 in due course. I've emailed a tidied up INI file, using Profiles. Regards Pete
  11. There are still free offsets which can be allocated to programs or other add-ons such as new aircraft gauges or DLLs. You need to work out how many offsets your program needs (number of bytes), and send me an email giving the byte count, and the program or add-on name using them. I keep a record of assigned offsets so that they don't clash. Email to petedowson AT btconnect DOT com. If you only want some offsets for personal use on your own system, not for publication, then use 66C0-66FF which are kept free for personal use by all. Regards Pete
  12. You can of course run Lua plug-ins via the facilities at offset 0D70. But also you can handle them through that offset by using LuaKill, LuaSet, LuaToggle, LuaClear and LuaValue. Thus you have ways of sending simple flag and numerical information to them and starting and stopping them. To get information from them, or sending strings like L:Var names, you would have to communicate with them via Offsets, for example the free user offsets 66C0-66FF. You'd use these to exchange data or instructions or strings. I have considered also to allow Lua Global variables to be accessible via the Offset system, but it gets rather complex and the need is small. Regards Pete
  13. Maybe you installed LINDA and that in turn installed those? Have you checked the User Contributions subforum here? I'm sure there are several useful NGX macros or Lua plug-ins there already. Just take a little care because if they use Mouse Macros there will be a difference for the different updated versions of the NGX gauges and DLLs. And likely they'll change again when SP3 (?) comes out. If you want to free your assignment dropdowns of unusable iFly737 and levelD entries just delete or move those macro files elsewhere, or rename them with, say, ".xmcro" filetypes. Regards Pete
  14. I am planning to look at it later today, or maybe tomorrow. I'll add it if it is easy, but first I need to investgate what it is actually doing. This will be for the default FSX. I really cannot do things for that walking add-on, but maybe it uses the same fS controls. Regards Pete
  15. Version 4.6 is almost TWO YEARS old! Have you not updated all that time? I assume you must mean 4.80, the current version, because there is no version 8. Please refer to the thread entitled "FSX fails to run after FSUIPC4 first installed" in the FAQ subforum. Regards Pete
  16. It doesn't say that. I think you are misreading it. It says it is the axis value which is applied to the trim if allowed. It is not writeable, it is a read-out in case an autopilot program wants to disconnect the trim input and modify it to control pitch whilst still monitoring the axis input values in case it should disconnect. This is particularly useful when the trim is a motorised trim wheel also being moved accorfing to the actual applied trim (0BC0). The facilities to disconnect axis inputs works on axis inputs, not on offsets being written to. There are some exceptions though, that have arisen historically through assorted developments. Why are you writing to an offset to control the trim? If you want to do that and have it treated like an axis you'd either need to send it as an FS axis control via offset 3110, or, perhaps easier, send it to the free axis offsets at 3BA8, which are now scalable to suit input types other than the PFC ones they were originally intended for. If you use the latter method you'd need to assign the resulting axis input in FSUIPC -- it'll be on one of Joysticks 16-18. Regards Pete
  17. No, it's a mess i'm afraid. But I'll deal with it nonetheless. Okay, but you don't know what FS controls they are? You see, I would deal in the underlying FS controls, not the keypresses assigned to them. But never mind. Either I can find out, or I can let you assign to any controls you like -- but in the latter case you'd need to identify them. You can do this using FSUIPC event logging as I suggested. Ah, but is that add-on using FS controls? It may simply be intercepting the keyboard. If so, then even if I added facilities you might not be able to use them! Perhaps it is now even more important for you to idntify the FS controls involved, or confirm there are none? No, I understand, but I need more information, as i keep saying -- the names of the actual controls, not the keypresses assigned to them. The alternative is simply to allow you to assign mouse functions just like assigning joystick functions. But you still need to know what the controls are that you want to use. When I get time I'll load up an aircraft with a VC and see what the controls are. Maybe that will be quicker than expecting you to identify them for me. But I don't know if or when I'd be able to add facilities, and I'd have to find a way to avoid negating the current mouse facilities, trim and mouse look/zoom. Pete
  18. Got it, thanks. And I confirm that with this file I can make FS9 crash in the same way as you. That’s good. I't is getting a bit late now so I’ll start work on the in the morning, and I’ll also send you back a tidied up version of the file. If all of the livery variations are using the exact same setting, shall i make them just one for you? Or would you like Profiles? If so, tell me what Profiles you’d like and I’ll merge the aircraft appropriately. Regards Pete
  19. Right. But I've no use for the new files you posted as they are nothing to do with the problem! So you still have the original? PLEASE PLEASE Zip it and send it as I requested! I need it to fix the bug! I will also tidy it up for you and send it back. You will have no work to do! Yes please, yes yes, of course. How else can i fix the problem? I'll tidy up the file for you too. Regards Pete
  20. You posted into one of the subforums, where it wouldn't get answered. I've moved your post to the Support Forum. I do not know the card. What sort of inputs does it provide? Buttons or Axes? What button numbers? FSUIPC4 uses exactly the same mechanism for reading devices which Windows classifies as 'joysticks' as FSX. I don't know of any way it won't see your card if FSX does. But please state the Version number of FSUIPC4. If it isn't the current supported version, 4.80, please update first amd try again. Then close FSX and show me, please, the FSUIPC4.LOG and FSUIPC4.INI files from the FSX Modules folder. You can paste the contents into a message here. Regards Pete
  21. Whatever I may do I'll have to be careful not to wreck existing facilities lke the trim. It won't be any time soon in any case. Regards Pete
  22. Not sure you'd read anything about those. They must be the result of Macro files (.mcro) added into your FS Modules folder. Macros and Lua programs both create assignable entries into Button, Keys and Axis assignment drop-downs. That's the whole point of being able to add such things. You probably got the macros from the User Contributions subforum here, or possibly they were created or added by LINDA? I don't know LINDA at all well, but I thought it just did the work in FSUIPC which you would have to do otherwise. It is intended to make life simpler for you. If you dispense with it you'd need to do such things yourself -- THEN you'd certainly need to read more documentation! ;-) Regards Pete
  23. I understood that, but I don't know what the controls are. I've never used them. Can you lease check and tell me what FS controls it is that do that? (Use FSUIPC event logging if you don't know). Oh, so it has! Do you know, I've never noticed that! How clever! Ah, I know about Slewing. Is the forward/back you want slewing too? Is the moving side-to-side possible in non-slew modes, and if so what controls? It cannot at present, as I already told you. The only mouse treatment in FSUIPC at present was added to replace "mouse look" which is disabled if you disable controllers in FS. What you are really asking for is what I suggested, to treat the mouse buttons as assignable assets just like joystick buttons. Then you could do the assignment you are talking about yourself. Is that not so? I'd still like to know what these FS controls are, that you activate using the arrow keys. Are these only in Viryual Cockpits? Maybe I don't know them nbecause I've never used a VC? Either way it would be a complete new facility which I'd need to plan and implement as a project. I think I would only be inclined to do it in FSUIPC4, not FSUIPC3 which is really so old now I don't want to have to mess inside it any more. BTW yours is the only request ever received for something like this. I wonder why? After all, FSUIPC has been going now for over 12 years. Maybe few really use the mouse so much? Regards Pete
  24. I think you must be mistaken. There are no built-in facilities for any add-on aircraft whatsoever. There is no way FSUIPC, which is a general purpose interface for applications into FS, can know about the specific ways add-on aircraft makers go about providing their controls. There is no way I'm ever going to add individual controls for individual aircraft to FSUIPC. It would be a never-ending job and, knowing how things go, a continued maintenance job too. The facilities in FSUIPC are perfectly adequate as they stand for dealing with any aircraft which allows itself to be dealt with. LINDA is, after all, only using those facilities, so you can already dispense with it if you wished and do what it is doing by yourself. But the whole point of LINDA was to make it easier -- it would be harder without, so I don't understand why you do want to dispense with it. The only other hope for the NGX on the horizon is that when PMDG finally release their SDK someone will write an interface for it to FSUIPC much like others have done for the Level D 767 and the iFly737. I assume that those interfaces, written by others, are confusing you into thinking I had anything to do with them? Regards Pete
  25. Best to use Profiles really. Makesw it all much much easier. But with the older Aircraft Specific facilities, you just need to set "ShortAircraftNameOk=substring" and then you can choose a suitable section of the aircraft name with encompasses them all, such as "737" or maybe "PMDG 737", whatever. 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.