Pete Dowson

"AIfreezer.lua" was prepared ready for the next full release. I don't remember where I mentioned it. Can you give me links to those two mentions, please. It would help me check that we are thinking about the right thing. Pete

I have had time to add code to allow me to test here without the requisite hardware, but having tested that this code works, i've run out of time to use it on this problem. I might find time on Sunday or Monday, though this is looking unlikely, otherwise it will be the 18th or later as I said. Pete

Where does it show this? Just in the log? Is that an axis command with a changing parameter, or just an on/off control? Does the NGX have such a control? FSUIPC won't generate commands just because you move the mouse, unless you have programmed this in a plug-in, so either it is something the NGX is doing, or an add-on you have. It will simply be logging what it sees arriving. Why did you enable logging, by the way? BTW, please always post support questions to this, the support forum. You posted to "User Contributions", which is a reference repository for useful contributions from users. Pete P.S. Please always state the actual version of FSUIPC and FSX/FSX-SE or P3D.

MOVED TO SUPPORT FORUM so it can be answered!

I couldn't sleep, so I am up early and have an hour or so to look at this problem. But I realise i do need some clarification of the above. Looking at the Log, this is the ALTair switch action in your "without macro" log: 16297: Device #1 received: AltAir[0] = 0 16297: Full macroname for decoded switch = "PFC:AltAir", mask = X00000000 16297: ... IPCwrite 3800[8] = 0.000000 16297: ... IPCwrite 3740[8] = 0.000000 16297: ... IPCwrite 3680[8] = 0.000000 16297: ... IPCwrite 35C0[8] = 0.000000 and 17875: Device #1 received: AltAir[0] = 1 17875: Full macroname for decoded switch = "PFC:AltAir", mask = X00000000 17875: ... IPCwrite 3800[8] = 1.000000 17875: ... IPCwrite 3740[8] = 1.000000 17875: ... IPCwrite 3680[8] = 1.000000 17875: ... IPCwrite 35C0[8] = 1.000000 And it is identical with the Macro present. So the macro is being ignored. Do I take it the macro isn't optional for your aaircraft, that the offsets above don't work for it? I don't remember any statement that Altair as also a problem on this aircraft, but I assume that must be the case? So you weren't actually expecting it to work without the Altair nacro in any case? Pete

I think so. This is going to take some serious addittional logging. That's the trouble with not having any way to reproduce it here. At least the last change did make a difference, though not a good one. But perhaps it points to the area needing more examination. The problem now is that I have really run out of sufficient time before my next trip away with my good wife. I might not get to it now till possibly the 19th October. Perhaps you could remind me then by another posting on this thread. Pete

You provided exactly the same again. I thought your complaint was surely that the Alt macro didn't work when there was an Altair macro present? As here: Or have I misunderstood? That's what iwas looking at! Reading again your more recent replies, was that a red herring (as we say here -- a false lead)? There's no sign of an Alt masro in the log, as before, and that's what I asked about! Anyway, just in case, please try this version and let me know. This is the one i had ready a week agao, help awaiting the Log I requested. Let's try and get the right story between us this time. http://fsuipc.simflight.com/beta/PFChid64_5126_TEST.zip Pete

Yes. you've just only told me what you reported before. I still need a comparative log as i said. I did build a revised version for you to test, but I've held it over waiting for the confirmation i need from that -- i.e a log with ALT used without AltAir. Please do re-read my previous message. Pete

I'm sure it tells you in the documentation. Multiline data goes to the SimConnect Message Window, single line to the SimConnect Text (what you call "the green bar". A mult-line message is determined by the presence of a New Line (ASCII 10) or Return (ASCII 13) character code, even if followed by nothing else. This is similar to the action taken in all previous versions of FSUIPC and FS in which these facilities have been supported.. It was done this way as the closest to some sort of ongoing 'compatibility' that could be achieved. Pete

As I already explained, there is NO DEPTH information provided in the METARs. I explicitly told you that FSUIPC just uuses estimates based on cloud type! Pete

See the FSX METAR string definition (but note that it isn't complete: upper winds and air temperatures are encoded separately after the @@@. Also there are subtle differences when WRITING the METAR strings. It was a nightmare trying to sort it out back in the day -- something I hope never to have to delve into again!). SKY CONDITIONS (has an extension) Note cloud heights are coded: If NNN is 999 the level is 100,000 feet, otherwise it is 100 x NNN in feet. CCCNNN Where NNN is the coded height, and CCC is one of:: CLR or SKC - sky clear FEW - few clouds SCT - scattered clouds BKN - broken clouds OVC - overcast NTT - N/8ths cloud coverage of type TT, which is one of: CI Cirrus CS Cirro-stratus (maps to CI) CC Cirro-cumulus (maps to CI) AS Alto-stratus (maps to ST) AC Alto-cumulus (maps to CU) SC Strato-cumulus (maps to CU) NS Nimbo-stratus (maps to ST) ST Stratus CU Cumulus CB Cumulo-nimbus Note that not all of these cloud types are supported within Flight Simulator, so a number are mapped to those which are. This does mean that a write followed by a read of Metar data might not give identical strings. Flight Simulator extension: &TT000FTPQBBBI where: TT - Cloud type, one of: the list above (for example, CI or CB). If this entry is different from the NNN entry above, this entry will take priority. 000 - Unused. F - Top of cloud, one of: F (flat), R (round), A (anvil) T - Turbulence, one of: N - None (default), O - Light, L - Light, M - Moderate, H - Heavy, S - Severe P - Precipitation, one of: V (very light), L (light), M (moderate), H (heavy) D (dense) Q - Type of precipitation, one of: N (none), R (rain), F (freezing rain), H (hail), S (snow) BBB - Coded base height, the precipitation ends at this height, set to 0 for it to land on the ground I - icing rate, one of: N (none), T (trace), L (light), M (moderate), S (severe) You'll note that there's no place for cloud depth. FSUIPC has to use estimates based on cloud type. Even so, I'm not convinced your post shows related values: To compare properly, please enable some logging: In the FSUIPC INI file [General] section add these lines: LogWeather=Yes Debug=Please LogExtras=x80 Run the sim, find the log file, and show here a suitable extract. The log shows both the METAR and the decode into offsets etc. Here's an example of what you should show: 807289 Weather Read request (Nr Station) to area 5: Lat=51.47, Lon=-0.49, Alt=0.0, Req=1 807305 Weather Received (type 5 request, Nearest): "EGLL&A24 000000Z 30110KT&D900NG 300V302 30125KT&A1001LG 295V307 80KM&B-448&D3048 6CI328&CI001FNMN000L 20/12 15/12&A1001 Q1010 @@@ 34 15 301 25 | " 807305 WX Received in (16 mSecs), WX request type 5, Lat=51.4709, Lon=-0.4858, Alt=0.0m 809333 Weather Read request (At Aircrft) to area 4: Lat=51.47, Lon=-0.49, Alt=28.2, Req=2 809349 Weather Received (type 4 request, Interpolated): "????&A0 300729Z 30110KT&D900NG 300V302 80KM&B-424&D3048 1CU033&CU001FLLN000N 6CI328&CI001FNMN000L 19/12 Q1010 " 809349 WX Received in (16 mSecs), WX request type 4, Lat=51.4709, Lon=-0.4858, Alt=28.2m 811392 Weather Read request (Nr Station) to area 5: Lat=51.47, Lon=-0.49, Alt=0.0, Req=1 811408 Weather Received (type 5 request, Nearest): "EGLL&A24 000000Z 30110KT&D900NG 300V302 30125KT&A1001LG 295V307 80KM&B-448&D3048 6CI328&CI001FNMN000L 20/12 15/12&A1001 Q1010 @@@ 34 15 301 25 | " 811408 WX Received in (16 mSecs), WX request type 5, Lat=51.4709, Lon=-0.4858, Alt=0.0m 811408 >Change: Pressure=1010.0 mb 811408 >Change: Surface wind: to alt=3030ft, dir=301T, vel=10.0, gust=0.0, turb=0, shear=0, var=2.0 811408 >Change: Wind layer 1: to alt=6360ft, dir=301T, vel=25.0, gust=0.0, turb=1, shear=0, var=12.0 811408 >Change: Wind layer 2: remainder cleared 811408 >Change: Visibility[0]: range=49.7sm (80000m), from=-1390ft, to=8610ft 811408 >Change: Cloud[0]: type=9, from 3300ft to 7300ft (+/- 0ft), cover=1, turb=1, topshape=0 811408 >Change: Precip=0, base=0ft, rate=0, icing=0 811408 >Change: Cloud[1]: type=1, from 32800ft to 33000ft (+/- 0ft), cover=6, turb=0, topshape=0 811408 >Change: Precip=0, base=0ft, rate=0, icing=2 811408 >Change: Cloud[2]: remainder cleared 811408 >Change: Temperature[0]: alt=80ft, Day=19.0 C, NightVar=0.0 C, DewPt=12.0 C 811408 >Change: Temperature[1]: alt=3360ft, Day=15.0 C, NightVar=0.0 C, DewPt=12.0 C 811408 Results: FS98 Wind0: ground (82ft) to 2950ft AGL, dir 302M, vel 10, gust 0, turb 0 811408 Results: FS98 Wind1: 3030ft to 6360ft AMSL, dir=300T, vel 25, gust 0, turb 64 811408 Results: FS98 Wind2: 0ft to 0ft AMSL, dir=0T, vel 0, gust 0, turb 0 811408 Results: FS98 AmbientWind at PlaneAlt=92: dir 301M, vel 10 811408 Results: FS98 Vis: range =50sm, (raw value=4971) 811408 Results: FS98 Cloud1: type=9, from 3300ft to 7300ft (+/- 0ft), cover 1, turb 72, ice 0 811408 Results: FS98 Cloud2: type=1, from 32800ft to 33000ft (+/- 0ft), cover 6, turb 0, ice 2 811408 Results: FS98 Temp0: to 80ft, Day 19.0C, NightVar 0.0C 811408 Results: FS98 Temp1: to 3360ft, Day 15.0C You'll see the decode DOES match what is arriving. Note that "the nearest" means the nearest weather station - EGLL here -- and "interpolated" is at the aircraft. I was at EGLL so they are pretty much the same. There's also a GLOB setting which is used as default for unset stations, read at about the same time. Here's the entry corresponding with the above: 813451 Weather Read request (Global set) to area 1: ICAO="GLOB", Req=0 813467 Weather Received (type 1 request, AtStation): "GLOB&A0 000000Z 30110KT&D900NG 300V302 30125KT&A1025LG 295V307 80KM&B-424&D3048 1CU033&CU001FLLN000N 8CI328&CI001FNMN000L 18/12 05/04&A1025 Q0999 @@@ 34 5 301 25 | " 813467 WX Received in (16 mSecs), WX request type 1, ICAO=GLOB Pete

A 64-bit double float is 8 bytes long (8x 8 = 64), but an 8-byte offset is not always a double. you have to read and understand the context. They may be characters (bytes), 4 x 16bit "words", or 2 x 32 bit integers. Flight Sim does sometime uses 64-bit integers, not always floating point. The 4-byte offset you are using to trigger a virtual button indication is made of 4 x 1 byte values, as documented. Not the 8 you were writing. And the bytes must be in the correct order. So see my suggested value. Pete

So, it is the Lua language not accepting it. I suspect other programming languages are similarly restricted. In fact I wonder if my FSUIPC source would compile if I saved the files in UTF-8. I somehow doubt it. (No, i'm not going to try). Pete

You always need to ZIP files! They are both pure text files and Zip up really small! Pete

The input "number" is not relalted to the button number you choose. Why choose 16, Why not 0 or 1, etc? What language are you using? Is an "integer" defined as a byte (i.e 8 bits)? You need bytes if sent as an array, though it would be much easier to write it as one 32-bit value, as suggested in the documentation. For example, your values would be: $00014010 I don't know how the language or library you are using works on this. If you are using .NET and Paul Henty's DLL, then I think you should get his advice on your style. Virtual buttons act like real buttons. J64, B16 will show in Button assignments as joystick 64, button 16. That's the point! You then use it as you wish! Don't forget, you are setting the bit (pressing the button). If you want it to be seen again you'd need to clear it (release it) some time. The alternative, if it isn't supposed to be a latching switch, is to toggle. Pete

Yes, for event.offset, the initial values make events. That is so that you get changes from then on. Else what are "changes" from? This is documented in the section on event.offset, thus: "The function is also executed initially, when the plugin is first run, in order to initialise things. This saves using an explicit call to do the same" If only subsequent changes are of interest (which would be unusual) you could use a flag to indicate when the channel to the Arduino is open, and open it in an event.timer function a few seconds or so after the plug-in is started. But it would be better, of course, for the Arduino to simply keep up. I'm surprised it is so much slower -- perhaps a lower speed should be set at the PC end? But your solution of a larger buffer and a deley between each transmission also works, of course. Pete

I'm afraid I don't know much about the Arduino. you'll need to find out what it needs. Wouldn't just sending it some dummy (not-real) values work? Isn't the Arduino something you program yourself? If it is your Arduino program, wouldn't you know best what it is doing and what to do about it? Pete

Sorry, I don't understand. Of course, deleting sections from the FSUIPC5.INI file removes any settings you made, irrespective of what version of P3D4 you are using. Pete

I can't support LINDA -- you need their support. But I thought it wasn't possible to use a lever axis for reverse on those models? In fact I thought it was problematic using any FSUIPC calibration on the throttles. Shows how much I know about some of these add-on aircraft. Does the Aerosoft support forum offer any hints? Please also see other threads near here about problems with Airbus Pro throttles: Pete

Not just a rebuild, a substantail amount of changes, and all of them error prone. There's a lot ringing on one byte characters. It couldn't be due to something simpler like the numberic encoding (, and . inverted), could it? Did he try compiling the Lua to see if that's accepted? Of course, if compiled Lua actually uses any real x86 machine code then it wouldn't work with a 64-bit FSIPC, but since Lua is really interpreted in any case Ione might expect that the interim language is a type of "P-code". Pete

Why are you posting these URLs, sometimes not working? Why not just type "FSUIPC5 Install.log" and "FSUIPC5.DLL"? That would be much much easier for me, and I'm certain quicker for you! Append the Install log for 5.14. please. And also the DLL.XML file, because currently that is still the prime suspect and you've not actually shown it to me properly yet! Pete

Sorry, I don't know why the program needs it pressed twice on your PC. Maybe it is related to the keystroke combination you have chosen? As the documentation says, L-M have provided no way to remove the Menus. If you are using WideFS why not use the ButtonScreen facility top operate your Memus etc. That's what I do. The ButtoScreen facility makes use of the Virtual Button facility, which was one of the first solutions I suggested to you in this thread, and that works well, with ProATC/X, yes, as I used to use, but also GSX. I am using Pilot2ATC for my ATC now. Pete

For P3Dv4 only, 95% via SimConnect. The rest is via a the PANELS.DLL interface (as used by the few C/C++ Gauge writers left) and more and more PDK -- a closer interface than SimConnect and with some additional features of use. That is developing apace. In the 32-bit versions quite a few things were done by direct hacking.into the 32-bit code, continuing what had been done with FSX before it. Of course, before FSX and SimConnect it was almost all hacking into the code. P3Dv4 is ongoing and L-M have been very responsive to requests and suggestions, so I agreed with them to avoid hacking altogether. I didn't want to in any case because it is a different ball game from 32-bit -- and I am now too old to learn new tricks. No, that isn't so. There may occasionally be an FSUIPC change which depends on a newer facility in P3D4. A case in point did arise with P3D4.1 and all recent editions of FSUIPC won't run on 4.0. That may well happen in future, but i'll try to make this painless for those needing to stay on older versions of P3D4 -- though hopefully that should never be the case. Pete

When you used offset 3110 and 3114 before you correctly set the number of bytes to 4. Now you suddenly use 8. So when you write 8 bytes to 3110 you set 3114 to zero (3110 + 8 = 3118)., so overwriting your keystroke encoding! Otherwise it looks okay. You just need to be a little more careful. Pete

So, as I first surmised, it is probably a version number check which they apply -- maybe they don't like FSUIPC version 5. Pete