Pete Dowson

Where's the IPC write logging? If you have that enabled and no writes are logged then no writes have actually occurred! (I seem to remember I already told you this?) Here, I've just tried it. This is with the default FSX 738. I started the engines, engaged A/T and A/P, then wrote a value for the N1% hold value, and then set the RPM hold. Here are the log entries for the latter two actions: 1400405 WRITE0[6204] 07FA, 2 bytes: 00 30 .0 1413899 *** EVENT: Cntrl= 65900 (0x0001016c), Param= 75 (0x0000004b) AP_N1_REF_SET 1457034 WRITE0[6204] 07F4, 4 bytes: 01 00 00 00 .... 1457034 *** EVENT: Cntrl= 66711 (0x00010497), Param= 0 (0x00000000) AP_N1_HOLD 1457158 Monitor IPC:07F4 (U32) = 1 1457158 SimRead: 07F4="AUTOPILOT RPM HOLD" INT32: 1 (0x00000001) Notice I wrote 12288 to 07FA to set 75% Here I'm not actually sure whether FSX wants the 0-100% value of the 0-16384 values. Perhaps you can tell me when you get it sorted. I don't know anything about RPM holding. You'll see, in any case, that setting the N1/RPM hold at 07F4 is confirmed by SimConnect. The logging I an using here is ipc Write and Events (non-axis), and I am monitoring offset 07F4. If I try all this without starting the engines and enabling the AT and AP I may not get the hold set. I don't know -- I haven't tried all combinations, so I'm not sure, but it makes sense that you need to have everything set correctly for the Hold to take effect. If you still can't figure it out, and can't use the logging I keep suggesting, I think you need "pyuipc" help. Try writing to 07F4 using a Lua plug-in or using FSInterrogate2 just to see it is okay. I think then that something may be wrong with the pyuipc code, but I'm afraid I can't help with that as I am totally unfamiliar with it. Pete

Well, you have more than one thing wrong there: This most certainly means that you are making an error in entering you registration details. Cut and paste ALL THREE PARTS from the SimMarket account data. All three parts must be exactly correct. The other problem is: which indicates that you have not correctly installed the 10437 update -- some of the modules are still older copies. You need to copy EVERYTHING in the hotfix ZIP into your P3D folder. Pete

In that case it is most definitely compatible with P3D 2.2 build 10438. And your registration details are also good. So what is the problem? Maybe you nered to show me the Install log and the FSUIPC4 log, both from the Modules folder. Earlier you said you hadn't been able to register since "FSX", implying you never had an FSUIPC4 key! Pete

If Norton has quarantined it you won't be able to run it, will you? You'll need to tell Norton it's okay after all. Pete

You posted in a SubForum. Please don't. All support questions should come here, to the Support Forum, or they won't get answered. As clearly stated in the pinned thread at the top of this Forum, you need the current version, 4.931 (or later) for P3D 2.2. Yours is out of date and not supported in any case. An unregistered FSUIPC will not provide any button or joystick facilities. FSUIPC4 is not the same product as FSUIPC3. You need to purchase a new registration. Pete

It's a false positive. WideFS is scrambled, there's no code Norton can test, only random patterns. Pete

No, I don't know. I don't use the PMDG aircraft. That is why I suggested that you monitor 0D0C to see if it changed when you operated the lights! You should find it easy enough to use the numerical controls for all of the 737NGX switches though -- see that document provided by PMDG I referred you to. Pete

It does link to 4.931, however. I can control the items that page points to, but i can't change the text -- I don't have any control over Mr. Schiratti's websites. I have already asked him to update the text but it usually takes him a while .. I answered this in my previous reply to you. BTW my name is "Dowson" not "Dawson". Pete

I wasn't referring to assignment of buttons/switches. Just where the keypresses were assigned. FS has default keypresses as well. There are, I believe, assignable controls implermented for virtually everything in the 737NGX though. Take a look towards the end of the file "PMDG_NGX_SDK.h" in your PMDG 737NGX SDK older. As far as I recall there are numerical commands there for everything in the cockpit, and I added support in FSUIPC for assigning to "custom controls" by number. Ah, in that case you'll also need to refer to the document "Offset Mapping for PMDG 737NGX.pdf", installed for you with FSUIPC. You'll find all the light switch states at offsets 64F4 to 6503, along with the other switches in that part of the overhead (Starters, Ignition and APU). Regards Pete

It is not a bug in either, I don't use PMDG aircraft but I am pretty sure that it is related to the way the PMDG 737NGX handles the throttle controls -- it intercepts them at a higher level (a completely non-standard practice), partially defeating FSUIPC's calibration, so in the end two conflicting values reach the sim. As far as I'm aware the normal way round it is to set the "No Reverse Zone" (NRZ option) in the calibration tab, and make sure that "UseAxisControlsForNRZ=Yes" is set in the INI, possibly only in the Profile being used for the NGX. However, for specific aircraft you are always better off talking to folks in the aircraft specific forums. FSUIPC is an interface to FS, not to the specific add-ons, though I've weakened in places to provide more specific as for instance the mapping of NGX values to a large area of offsets and of course, the provision of the "UseAxisControlsFor NRZ" option. Pete

Not a "specific name", a less specific name! Just abbreviate one of the names already there to something which includes all of them, and delete the rest. And please see that the "xxx" in the [Profile.xxx] section I mentioned is the Profile name you chose, not "xxx" literally! Pete

But my point was, are you sure the aircraft does not respond to the standard FSX light controls, that you have to use keyboard assignments? Where are those keys assigned -- in FS or in PMDG options? What 'lua' is this? I never mentioned needing a Lua plug-in, did I? Anyway, if you going to be experimenting with plug-ins for some reason then, yes, whilst developing and testing them it would be best to load them by assigning to a key or button. but when working you simply need to include the "Lua <name>" call in an [Auto.<profile>] section for the relevant profile. The only Lua plug-in loaded automatically without such steps is "ipcReady.lua" which is run once when FS is ready to fly. Of course if you are only using a Lua plug-in to do something when you operate a switch or press a button then you simply assign it to that switch or button. The automatic running is really for continuously running plug-ins doing clever things in the background, or for specific initialisations automatically upon loading an aircraft. If you merely want to see if the offset 0D0C works with your aircraft, enter it as the offset in the Monitor facility (right-hand side of Logging tab) as type "U16" and select "display" or similar below so it shows on screen. See if it changes when switching lights If 0D0C does work then you can assign switches to the Offset Word SetBits and Offset Word ClearBits controls to turn lights on and off. This is what I meant when I mentioned 0D0C before. Pete

I had a job finding it too. Please see the Updated Modules thread in the Download Links subforum where I've now put a link to the thread in which it is provided.. Pete

Sorry, mistake in my rush to get 4931 out. I'll fix it now. Pete

Okay. The problem was I didn't know that (a) you only operated one switch, and (b) which switch was assigned to the light you mentioned -- after all key presses aren't normally used. This line: 230570 JoystickValues PCnum=0, dwCount=1, data[2]={0000006d 000000fb} shows that on the T8 you do already have the 7 other switches in the ON position. (fb = 11111011, each 1 is a switch in the "ON" position. What happens when there's a change in the switches, any one of them on the unit, is that the GFDev driver from GoFlight sends the state of all 8 switches. Obviously you left them all in the 'On" position (upwards). If you left your lights all off they should surely have all been left in the Off (downward) position? Ah, sorry. I thought you meant I'd helped you programming the light switches -- there is an offset (0D0C) which has bits to switch on or off every one of the 10 possible lights on default aircraft (and most add-ons). Using that you can actually program distinct On and Off actions. You are probably using toggle controls which obviously don't suit latching switches. Aren't there much better ways to operate PMDG aircraft switches rather than horrible keypresses? Have you checked the User Contributions sub-forum for your aircraft, see what others do? Pete

I think his second question belongs back in the Beginner's Forum, though? ;-) Pete

Yes, of course, because the aircraft is recognised by name, and the names are different for each livery. You can of course make a Profile apply to all liveries by editing the [Profile.xxx] list in the INI file and changing the full aircraft name to an abbreviated one which is common to all but nevertheless still identifies the aircraft. With the "ShortAircraftNameOk" parameter being set to "Yes", or, better, "Substring", FSUIPC will match an abbreviated name quite readily. Do NOT rotate at V1 -- that's the speed above which you haven't enough runway left to abort. You shouldn't rotate until Vr. Then, after lift off and attaining V2 you lower the nose sufficiently to accelerate. Do NOT hold the ortation attitude all the way or you will lose speed and sink. And check that you aren't taking off with a gross weight above the maximum. I think perhaps some studying of your aircraft is in order? ;-) Pete

Why post twice, and incorrectly into a subforum too? Please see the existing thread about this, just below. It's not just that link, it is the whole of Project Magenta.. Mr. Schiratti is investigating. Not sure what you want, but all of my stuff is available here in any case, in the Download Links subforum. Pete

As documented, the parameter value gives the upper limit. The increment is always 1. If the altitude is already set >= 1000 your macro can't do anything. If it is less than 1000 it will try to increase it by 1, but I expect the altitude is rounded down to the nearest 50 or 100 in any case. The INC and DEC options are really intended to operate multiway switches, not operating values like altitudes. The only way to increment an L:Var by 1000 would be to have a little Lua plug-in which reads the value, adds 1000, and writes it back. Regards Pete

Er ... Where is the light switch operated? You seem to have just assigned buttons to loads of different keystrokes. I don't know what those are assigned to -- not in FSUIPC for sure. You've made the log impossible to resolve by pressing loads of buttons or switches and sending lots of keypresses! Surely all you should do for this test is operate just the one toggle switch? I see nothing there but standard FS controls and assorted key presses. Why do you think FSUIPC is having anything to do with what you are seeing? Earlier you said But I see nothing there which I would have helped you with. Pete

I'm afraid you need to explain more. How are your toe brakes assigned? All aircraft or only one specific one? What other offset were you testing? Please use the FSUIPC logging facilities to see what is happening. Monitor the offsets and log the events which occur when you press your toe brakes. Don't forget, also, that on most (if not all) aircraft the parking brake is merely the latched application of both toe brakes. In fact if programmed correctly, you have to press both toe brakes then pull the lever to lock them on. Releasing them is then a matter of pressing both toe brakes sufficiently. If assigned through FSUIPC there's actually a threshold value you can set for this in the INI file. Pete

FSUIPC only does what you ask it. I've no idea what operates switches in the PMDG 777, I don't have it, but i'd be very surprised if changing one switch operates every single switch in the whole aircraft. If it does there is something very wrong with the 777! Perhaps you only mean all of the light switches, not all the "rest of the switches in the Virtual cockpit" as you said? If so them it will probably be related to how you've programmed the switches. Do two things 1. Enable button logging and also event logging (not axis) in FSUIPC's logging page, operate the switch, then turn the logging options back off. Show me the resulting LOG file. 2. Also show me your FSUIPC4.INI file. Both files are in your FS Modules folder You can paste their contents in a message here. Pete

No. That's exactly like a corrupted FLT or WX file being loaded by default -- i..e. \\PC\Flight Simulator X Files\Last Flight.FLT As soon as FSUIPC starts doing things, it is accessing the weather through SimConnect. A corrupt WX file, saved with the FLT, can cause problems. Try deleting just \\PC\Flight Simulator X Files\Last Flight.WX In fact, after doing a search on EV_MENU I found an earlier thread in which the Menu wouldn't appear for exactly the same sort of reason. There is another file which can get corrupted -- WXStationList.BIN, in your FSX.CFG folder. You can delete that too -- FSX will build another. Pete

Yes, as I've now discovered trying to send an email to Enrico. I tried his hotmail address ... ah, he's just replied! He says "I really do not know what is going on… SQL, Mail, FTP and all sorts of other things are fine. They are working on it to find out what is going on." Pete

Those are the two instances of the menu being called. In the first the "dwMenuEvent=0" value says that SimConnect is not at present in Dialog Mode, so the very next thing FSUIPC does is ask SimConnect to enter dialog mode. It then has to wait for a response from SimConnect saying that dialog mode has been successfully enabled. This event is never seen! So FSUIPC cannot display the actual dialog. The second time you selected the menu entry, "dwMenuEvent=15" occurs, which tells FSUIPC that SimConnect has exited dialog mode. So, something in your system is preventing SimConnect from sending the confirmation event, or, more likely, is stopping FSUIPC receiving it. The DLLs will be running no matter what aircraft you are flying. They should only do something when needed, but they are running as SimConnect clients all the tim, receiving and handling all the events they have registered. I'd mostly suspect the "PMDGoptions.DLL" module -- early versions of that did cause problems. Please try renaming just that module, so it doesn't load, and see if this is the case. If so I think you need a PMDG update installed, because it was fixed some time ago. If it isn't this then, please, as a test, rename both your DLL.XML and EXE.XML files, so no add-ons/ins load, then re-run the FSUIPC4 installer and test again. If that works, then there's a process of elimination to be followed on each add-on/add-in in turn. If none of this gives a result then I can only think your SimConnect installation is faulty. Regards Pete