Pete Dowson

Didn't you try setting -4, as documented? Pete

You don't need to "keep scaling", you can calculate it now you know the inputs! Look, it is simple arithmetic. Your input is -16384 to +16383, which makes 65536 total range, right? You want a total range of just 1024, so the "scale" is 1024 divided by 65536: 1024/65536 = 0.015625 (use a calculator to check if you wish). So the first part of the 'scaler' is *0.015625 This would give you -512 to +511 and you want 0 to 1023, so now you need to add 512. So the total part to be added is: *0.015625,+512 See? Nothing magic, nothing mysterious just simple arithmetic! Pete

Aha! The [General] section is not re-read at all, and you cannot make permanent changes there whilst FS is running. The only "dynamic" sections are those which can be reloaded -- Profiles, Buttons, Keys, JoystickCalibration and Axes. Yes. And especially for this type of parameter because it controls the way FSUIPC initialises everything -- the value determines whether certain FS events are intercepted ("hooked"), and this interception is only set once, at the beginning. Regards Pete

Offsets range from 0x0000 to 0xFFFF and except for certain areas free for users they are either all allocated already or should be applied for before use so I can ensure they do not conflict with anything else. The values you have a meaningless. Ah, so you do not mean "offsets" at all, but "controls"! Those are always known in decimal in any case. Well, that's not surprising, is it, when you are adding 1023 to the result? Why are you doing that? Since I have no idea what numbers your throttles are providing, I can't possibly advise how to scale them to the range you need. You will have to measure the minimum number and the maximum number, that multiple it by a suitable number to get a range of 1024 and add whatever it needs to get it to start at 0. You should be able to see the numbers you are getting in the FSUIPC axis assignments tab -- but remove that +1023 from your assignments first! Regards Pete

Hmm. Very odd. The "reload" function does not read nor write any of the [General] section parameters, it is only concerned with the section of the INI which relates to the options tab in which you are operating the button. Additionally, there is no retention of '4' as the default value once it is changed in memory, so that's even odder. Can you therefore be more specific. Which particular 'reload' are you pressing. Each attends to its own area. I'll investigate this later. Gotta go just now ... Pete

Yes, because entries can be shortened (i.e. not full titles) and ambiguity becomes dangerous even for semi-automatic actions. Also the user interface was already getting more complicated than I wanted. The problem is that once you are using the profile in one section (eg Buttons) it becomes the automatic selection (naturally) for the other three sections -- axis assignments, joystick calibrations and keypresses. The user may know what he's doing for the tab he is in at the time but not realise that removing it from one would remove it from the others. And then there's the problem of what happens when the last aircraft in a Profile is removed? You can't have empty sections, so the [Profile.name] section disappears, leaving all the settings for that profile orphaned. If I automatically deleted the orphaned sections (which would be the correct thing to do), the user could suddenly lose all of his carefully devised settings in all four categories just by answering "yes" to a delete request. There may be good solutions to these things, but it gets a little complicated when you realise this was all bolted onto a previous system of Aircraft-Specific assignments which also had to be supported for existing users at the time. I suppose in the end a separate tab, or even utility, specifically to manage profiles would be a way towards tidying it, but it would be a lot of work and quite error prone at this late stage of FSUIPC development. I think the compromise of a little INI editing is reasonable on the few occasions it is really needed. Regards Pete

Okay. All done. Download FSUIPC4921g The instructions for TimeForSelect options are explained in the Changes document included in the ZIP. Please confirm it solves your problem, as I've no affected add-on to test it with here. Regards Pete

Yes, indeed. When you load an unassigned aircraft and select Use Profile you will get a selection list. It includes those profiles you have already, and also "New" and "New, based on". With "New" you start afresh, but with "New, based on" you get to select one of the existing profiles which will be copied with the new name you give. Easy! ;-) Pete

Why would you even suspect so, when FSUIPC is an FS DLL, not a free-standing program?. It cannot be installed on any PC which doesn't have FS on it, as it installs INTO FS! And you cannot run both WideClient and FS together on the same PC because the whole point of WideClient is to pretend to be FS so that applications on that PC can connect to it! Full instructions for WideFS are given in the WideFS documentation. The FSUIPC package has its own, separate documentation. All you need to know is actually explained in the WideFS user guide. That's what it is for. Regards Pete

It isn't FSUIPC which does such things. All it is doing is calling the SimConnect function to save the flight, and that should operate exactly the same as if you went into the FSX menu to save a flight. Oh, and it also, of course, removes the oldest saved flight in the cycle of however many you set it to keep. In case the latter action has anything to do with it, try using the "AlsoSave" function instead -- there's no cycle of saved files for that, it merely saves with a fixed filename overwriting the previous ones. If this alleviates the freezing then I'd suspect your hard disk or Windows caching, because it must simply be related to disk file operations. Incidentally, I have only seen these delays mentioned in connection with certain specific add-on aircraft -- the PMDG 777 in fact? I think PMDG were also investigating why this should be so when it didn't occur on the 737NGX. Perhaps you might check if it is aircraft specific in your case? Regards Pete

It looks like some other aircraft possibilities were removed. I think the first 'elseif' should just be 'if'. Pete

If I can, I will. I'll take a look. Pete

If you are not the programmer of "it", you can't. Sorry, but you appeared to have injected your request into a thread started by and 'solved' (potentially) by a developer. If your question is not related to the original one where a solution was already proposed by the OP, then see the part of my answer about an update to FSUIPC instead. Perhaps you'd like to consider that and answer it instead? Regards Pete

Apart from the solution using SimConnect events as stated above, you mean? If this is important then I can disable the entire "TimeforSelect" facility when the value is set to 0. but I can only do this when FSUIPC is first started -- so it won't be changeable in the Options. I can do this in an update tomorrow if you need it. Pete

You can do that, and with FSInterrogate if you like (but you'd need to make your own FSI data file using its editor) -- ,but, much easier, if it is only a few (e,g, 16) offset values you could use a Lua plugin saved in the WideClient folder. Please see the Lua library document for a pictorial example of what you can easily get from the Lua display library (see back page of that document -- the example "MyDisplay.lua" is included in the examples Zip). Regards Pete

Sorry, I don't know the aircraft. What have you assigned Ctrl+F1 to do? Is it pre-assigned? Are the throttles working? Maybe that aircraft uses different throttle methods -- there are several ways of assigning and calibrating throttles in FSUIPC, you need to select the method which works for the specific add-on. Have you tried RAZBAM support at all? They would know the aircraft. I can only support the default aircraft directly, because FSUIPC only knows about default FS methods. You should always update to the currently supported version if you want support because I cannot support old versions. Regards Pete

Sorry, I don't understand. Why do you need different settings for selecting flaps going up to those going down? You only need 8 areas whichever direction you are going in. How do you work out you need 10 or more now? That makes no sense at all! Also it sounds like you are using the right-hand side of the Axis Assignments tab. Why not simply assign to Flaps and calibrate the positions in the calibration tab -- there's already a ready-made system for calibrating flap detentes. Why do you need different positions going one way from those going the other? Even if you persist in using the axis ranges, why not use the same ones for both up and down? Why do you think you need different positions entirely? It makes no sense. Regards Pete

"Radiator flap"? I've never heard of such a thing. Is it possibly the same as the "cowl flap"? If so, assign to the cowl flaps axis. One other thing you can try -- assuming it does actually use an FS axis -- enable axis event (and possibly alse the normal event) logging in FSUIPC's logging tab, then operate the on-screen flap control, and see what control, if any it actually uses by examining the log file saved in the FS Modules folder. If it isn't equated to any aspecific standard axis or control in FS, then you might have to resort to other methods. I'm afraid you'll need A2A Spitfile documentation and possible support for that. Pete

Thanks! I will certainly check for myself (not that I don't believe you, just that I need to be 100%), and then update the dox! Best Regards Pete

I assume you are using iFly2FSUIPC to map iFly data to FSUIPC? The data files supplied with FSInterrogate are really only for the default FS offsets. You can add offsets definitions as you wish. All is explained in the FSInterrogate documentation. It is not my program, and I cannot maintain data descriptions for all the add-ons wihch use their own offsets. If you simply want to monitor certain offsets to see what they are doing, look instead at the FSUIPC logging tab, the Monitor options on the right-hand side. If you run FSX in Windowed mode you can enable the Console log window to see them in real time. Regards Pete

No, sorry, Ther's no way of ending a DLL unless it, itself, has a function which tells it to quit. Then you'd need something to call it. If it uses SimConnect it probably has the function which SimConnect calls to tell DLLs to tidy up ready to exit, but otherwise it will just have the normal DLL exit function called by Windows when the program is closing -- the program here being FSX of course. Pete

Probably because the events are still "hooked". I would have to change the code to not hook any of those events if the time is set to 0. I could consider that for a future update. Well, you are probably sending the events at the same priority level as FSUIPC sends them, so not hookable by FSUIPC. If you are happy going this, it is excellent, because a lot of folks do depend on FSUIPC's "time for select" option on some add-on aircraft, and it isn't easy to make this action aircraft or profile specific because of all the unhooking and re-hooking required. Regards Pete

In the axis assignment section FSUIPC recognises all the standard Windows joystick parts -- up to 8 axes and 4 POVs ("Points of View" controls, or Hats). If your second hat is not recognised as such by Windows it won't be recognised as such in FSUIPC. If you want it recognised, instead, as a set of buttons I'm afraid that is not supported in FSUIPC -- only button numbers 32-39 for the first POV are supported. Try the axis assignments instead. You can still do assignments to up to 10 of the values it sends by using the range assignments on the right-hand side. Pete

Hmm. Odd, since it should be blank by default in any case. Pete

Could you clarify, please? What's a "blank action"? Normally you wouldn't program anything on the release. What is it you actually found you needed to do? Regards Pete