aua668

I followed the threat - but I definitely did miss your message. Now I got it. Reinhard

Hi Pete, The error 267 is clear. According to your posted INI file section you have installed the fiber accelerator in E:\FSPS Fiber Accelerator\ If you now try to run it from E:\FSX\FSX Fiber Accelerator\ you will get this error, as this path really don't exist. Rgds Reinhard

Oh thanks - I didn't read this thread as I don't use WIN 8.1. at the moment. But in any way I will wait for the official release. But This might be a help for those, who did the upgrade already and are now grounded. Rgds Reinhard

Hi, Starting with the version below you should also save your Profiles directory. Rgds Reinhard

Hi, As P3D V2.3 is out now, be informed, that you should wait, until Pete publishes the adopted FSUIPC version. Otherwise you will experience CTDs according to the LM forum posts. So let's wait until next week with the update ;-) Rgds Reinhard

Hi, Check page 50 of the FSUIPC user guide. It's described there exactly, what to do, if the throttles are not in sync. Rgds Reinhard

So please go for holidays. You have fun and the growing P3D community gets new features and improvements from LM ;-) Rgds Reinhard

Pete, I tested the version 4934a und FSX and P3d V2.2 under Windows 7/64 . In both simulator versions the profile files were created as stated in the supplied documentation. I tried to change settings and they were set in the correct file. I then changed settings in the profile files via editor and reloaded the setting in FSUIPC. Also this test went well. The files are now much less cluttered and easier to handle. So for me it worked perfectly (as always with your products). Great job! Thanks Reinhard

Hi, Thanks for that information. As soon as you have something to test just let me know. And you didn't commit in which year you will do it - just not earlier than Jan :razz: Rgds Reinhard

Hi, You need just one entry in your C750 Profile: [Profile.CX750] 1=Eaglesoft Citation X 2 As you have setup the ShortAircraftNameOk=Substring this should detect all your C750 aircrafts and apply the button profile to it. To avoid later conflicts with other planes you should consider also to create a seperate [JoystickCalibration.C750] profile. Rgds Reinhard

Hi, Look for "AXIS PAN HEADING", "AXIS PAN PITCH" and "AXIS PAN TILT" in the FSX controls document. Rgds Reinhard

... if the weather is better again for a walk :razz: Rgds Reinhard

Pete, Fine for me too. Whatever is simpler and more compatible to the existing implemention is always the best thing. You are the master. Your proposed solution will perfectly fulfill the requirements. Rgds Reinhard

Hi, I try to give a simple example. Let's say you create a axes profile named "TwinPropPitch" as usual defining some assignments and calibrations. [Axes.TwinPropPitch] 1=0X,32,D,1,0,0,0 2=0Y,32,D,2,0,0,0 3=1Z,128,D,4,0,0,0 4=1R,128,D,3,0,0,0 5=1U,128,D,5,0,0,0 6=1S,128,D,6,0,0,0 [JoystickCalibration.TwinPropPitch] UseAxisControlsForNRZ=No Aileron=-16384,-128,128,16383 Elevator=-16384,-128,128,16383 Rudder=-16384,0,0,16383 Throttle=-16384,16383 Mixture=-16384,16128 PropPitch=-16384,16128 ...etc  Normally you would assign all the aircrafts using this profile as follows assuming you use "ShortAircraftNameOk=Substring" : [Profile.TwinPropPitch] 1=Baron 58 2=King Air 350 ... You only need to assign and calibrate your yoke and axes once for all your twin props. But then you are limited with your button assignments to either the default settings or to the profile specific button assigments. As the layout of panels and the necessary assignments of buttons are varying more often than the assignment of axes, you must create for each panel type a profile and therefore you are duplicating also your axis assignment and calibration sections, although this wouldn't be necessary. So one method to overcome is, the way proposed above. Another and maybe more simple approach to implement is, that you should be able to reference for each value in a profile setting to another profile. Something like this: [Axes.BE58] 1=Alias.0X=TwinPropPitch 2=Alias.0Y=TwinPropPitch 3=Alias.1Z=TwinPropPitch 4=1R,128,D,11,0,0,0 5=1U,128,D,7,0,0,0 6=1S,128,D,9,0,0,0 [Axes.350] 1=Alias.0X=TwinPropPitch 2=Alias.0Y=TwinPropPitch 3=Alias.1Z=TwinPropPitch 4=1R,128,D,8,0,0,0 5=Alias.1U=TwinPropPitch 6=Alias.1S=TwinPropPitch By that you can either reference to an assignment in another profile and you are just replacing the value by the corresponding value in the generic profile. Or you can define specific assignments for some axes as you need them. And this concept can be used for axis assignments, calibrartions and button assignments in the same way. And then you are free to create individual button profiles or you are also able to reference to the assignment in another profile. And with an implemenation like this you should stay compatible. If someone doesn't use this feature, all stays the same. It's the extension of the concept you have implemented with your default profile. You are now able to either assign default behaviour to a button or override it by a profile specific setting. With that method you get suddenly several default profiles: one for TwinProp, one for TwinJet, etc. Hope this makes it more clear. Maybe at your next walk you have again another genious idea. I like that approach :???: Best regards Reinhard

Hi, I personally found the original idea much better and creating profile aliases for several sections of the profile would really be great. Think about the situation, where you have to recalibrate some devices as they change behaviour over time or you have to replace them. Then you would do it only once for one group of profiles. And often some settings will always be the same across several profiles (e.g. throttle calibration) while other must be different according to different panels (e.g. button assignments). And only referring to one single default profile is not enough in most cases. Therefore we duplicate typically a lot of things. It was a nice idea. The solution with different INI files looks really to complicated for most users being in many cases not able to manage one single INI file correctly :???: Rgds Reinhard

Hi, Have a look in the HidDemo.lua file in the Example Lua Plugins. This demo can be run also in Wideclient as specified in the comments of the Lua programm. Maybe this points you in the right direction. Rgds Reinhard

Why don't you use the same syntax for the hex value in both statements? First is right. Second one should read: ipc.writeUW(0x943E,MyData) like above. Beside these syntax errors: As mentioned above, you must activate this code. Otherwise it will never execute. Either by registering an event of the offset of CRS1 or if you only want to have it synchronized on demand then by registering a button to trigger this piece of code. And as I don't own the iFly: Are both offsets R/W or maybe only R/O ? Rgds Reinhard

Hi, I fly this plane under FSX. So I can only speak for this version. But what I assume is, that you didn't enter all the necessary inputs in the FMC. Have you went through all pages of the FMC? Didi you get the confirmation question for setting the V-speeds? Have you entered the environmental data for take-off? And how is your loading for the flight? So that bird is not easy to fly. Following the intended procedures is a must. What I think is, that FADEC reduces the power for takeoff maybe because of wrong or missing data. And without FSUIPC you have no FADEC and therefore you are controlling the thrust. And I don't takeoff with 100% - it's always far below. Have a look here too (also far below 100%): http://www.youtube.com/watch?v=sx7VJm6d0Zw Rgds Reinhard

Hi, Just came across this thread. I am not sure, if you are aware about the possibilities with the camera definitions. Have a look into the definition of the several cameras (cockpit view, virtual cockpit, etc.) in the camera.cfg file. And then have a look at the parameters set. A description of the possibilities can be found here: http://msdn.microsoft.com/en-us/library/cc526984.aspx Especially look at the panpbhreturn parameter. You can even define your own camera and adjust the settings accordingly. I have the feeling, that you try to solve your problem at the wrong place. Rgds Reinhard

Hi, I think, you didn't understand correctly, what I did and I didn't completely understand, what was ongoing. And obviously I also didn't describe it good enough :???: There was no "measurement of 1". First the screen not responding was showhing a 45 degrees view. When I want to set it back to 0 it didn't work, because the last control sent (to a different view) was also 0. By that the event in this view didn't fire. With 1 it switched back to forward view. So a pure "optical measurement". No logging at tht time. And the only thing I wanted to express is, that 0 or 1 makes no visual difference looking forward. Where I went wrong was, that I didn't realize, that calling this control in other views before with the same parameter 0 inhibts the event in the actual window. So the non-working zero was just a result of the sequence by which I set the views. It could have been with any other number too. So if you have to set the same view angles in seperate views by that contrrol (or even more realistic: if you want to set pitch and tilt by the respective controls), then this won't work, if you don't do a little trick. You have to set the parameter first to a different value and then to the final value to be sure, that the axis in that view is set correctly. This only applies, if you use multiple views. In a single view environment this makes no sense. ipc.control(66504,pAngle+1) -- dummy call to be sure, that the next value is set ipc.control(66504,pAngle) -- this sets the angle to the actual value Another misunderstanding: I don't switch to a view and back again fast. I switch to look 45 degrees to the left and later I switch back to normal view. That's all. Don't know, how you got the impression, that I am doing this so fast. It was only the sequence of the control calls, which produced the strange results. And as I then manually sent first a 0 (with no reaction) and then a 1 setting the view to forward again I thought in the wrong direction. And the timing problem was another wrong direction ... my fault. Trial and error. That's how mankind evolved :???: And the main reason for all these problems: I didn't know, that sending a control doesn't always produce an event. I expected, that every single call of the ipc.control really triggers that event. In the case of the AXIS control this obviously isn't the case for the reasons you mentioned. I have not been aware of this. Hope this explains all ... I have a stable and working solution now. Reinhard

Pete, To answer your question about "measurement": That was pure calculation: 1 = 1*180/16384 degrees = 0.01 degrees. No measurement. To explain my script more in detail (not the test script above but the one I use for setup of my views). I have three screens for the outside views. By default I set the left screen to 47 degrees left (47 is for bezel correction). Middle screen to 0 and right screen to 47 degrees to the right. With the mode selector switch on my Saitek yoke I can shift all three camera views by 45 degress to the left or the right. And with another switch I can set left screen to Tower view, middle screen to outside plane view and right screen to map view. By that I can orient if I got lost during taxi. So for switching between these view modes I have to set the camera and the view angle for each screen. But in the meanwhile I did more testing with logging and I found the real reason: The ipc.control for an AXIS doesn't produce an additional event in the logging, if you call it with the same parameter you used at the last call. So calling: ipc.control(66504,-4096) ipc.control(66504,-4096) ipc.control(66504,-4096) produces only one AXIS event in the log. And that was my problem, if I switched to the left forward view and then back to forward view again. Why? It's simple. For left Forward I called the control with the following parameters: Screen 1: ipc.control(66504,8556) Screen 3: ipc.control(66504,0) Screen 2: ipc.control(66504,4278) I call screen 3 as the last screen, so that the forward screen has the focus at the end of my setting. Just for optical reasons because of the white pixel border of the active view. But when I switch back to forward view again, I have the following values: Screen 1: ipc.control(66504,4278) Screen 3: ipc.control(66504,-4278) Screen 2: ipc.control(66504,0) And as the first call of the control in this second sequence is the same as the last call in the first sequence (4278), this contol produces NO event - although it is directed to a different view. So the lesson learned: If you send AXIS commands to different views/cameras and you have the same parameter, then the control fires no event. By using a parameter 1 before setting it to the desired value, I had success, as then the AXIS event was triggered. Thanks again for pointing me to logging. Didn't think on it. I just had added some ipc.log calls in my scripts to check, if I call the right functions, before posting here. But as the called sequence was correct, I went the wrong direction during my analysis. But by logging the events the root cause is now found. Rgds Reinhard

Hi, I did the test with the following script: ipc.control(66504,4096) ipc.sleep(2000) ipc.control(66504,0) ipc.sleep(2000) ipc.control(66504,-4096) ipc.sleep(2000) ipc.control(66504,0) It produced the correct logging: 1035924 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 4096 (0x00001000) AXIS_PAN_HEADING 1037937 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 0 (0x00000000) AXIS_PAN_HEADING 1039949 *** AXIS: Cntrl= 66504 (0x000103c8), Param= -4096 (0xfffff000) AXIS_PAN_HEADING 1041961 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 0 (0x00000000) AXIS_PAN_HEADING And it produced the correct result on the screen. In my code I change the camera too before setting the view angle by using ipc.control(66851) as I also switch between outside view and cockpit view. And if the camera has to be changed, then the view is not always changing although it's logged correctly. So the conclusion: It's obviously a timing problem. The changing of the camera takes longer and therefore the setting of the view angle comes too early before the view is ready. Thanks for helping to analyze this strange behaviour. Reinhard

Pete, I will test with the direct assignment via a key tro check, if this works on my system too. Thanks for investigating in this topic. I need this out of a LUA script, as this is part of my cockpit setup procedure. I run a multi-monitor setup (3 screens for the outside view and 2 touch screens for the panel). With this setup I have implemented several aircraft types (F100, A32x, C172, ...). With the LUA scripts I arrange depending on the aircraft type all the panels and I initialize the outside views accordingly. I tested this (as always) with the default FSX C172 to avoid influences from third-party aircrafts. So this is not the reason here. I did the same what you did with the keys in my LUA script. I changed the axis value to 4096 and tried to change it back to 0. But with 0 I had no success in my setup. So maybe passing the parameter 0 via the LUA ipc.control call is different to non-zero values. I can live with 1 too, as this 0.01 degress, which makes no difference in the outside view. I will try the logging for my LUA as you did it for the keys. Thanks for pointing me in this direction. Best regards Reinhard

Pete, In my multi-monitor setup I use three seperate camera windows for the outside views (left, fwd, right; 45 degrees FOV each). In a LUA script I am able to set the heading of each view with the AXIS PAN HEADING control. For looking 45 degrees to the right I use ipc.control(66504,-4096) etc. I have a switch triggering a LUA script, which is shifting the view angle in all three outside views by 45 degrees to the left or right. By that I could look out for landing traffic for example as I am limited to the 135 degrees with my three monitors. But If I want to switch back to the forward position (angle=0 degrees) this doesn't switch the view back. I have to use ipc.control(66504,1) instead. But 0 as the parameter doesn't seem to change the axis value. Would it be possible, that you check this in your code ? I use FSX+Accelleration under Windows 7 and use FSUIPC 4.911 Best regards Reinhard

Jean Louis, Why don't you just set the offsets of the FSUIPC Exporter according to the documentation of Eric? It's all in the enclosed manual. Setting starter switches is just seetting offsets to the correct value. Nothing else. Rgds Reinhard