-
Posts
38,265 -
Joined
-
Days Won
170
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by Pete Dowson
-
FS98 user with FDC and Meteo
Pete Dowson replied to tp142's topic in FSUIPC Support Pete Dowson Modules
That's a bad check in FDC then. There were some faulty applications which did some strange things with the version numbers, but I never thought FDC was one of them. No idea, but i'd advise you to seek an update with the bug fixed so it doesn't baulk at 3.999. If you wish to stay with 3.71 please note I can offer no support. Pete -
Okay, thanks. I'll look to see where that is. I think it might be optimistic to expect a log message to get out in the few milliseconds event.terminate gives you. Best to just make sure things are closed before the thread is killed. In fact let it kil itself, thus: function kill() ngxSDK2Lua.kill(); ipc.exit() end[/CODE] The proof of whether this helps is if it prevents CTDs. Regards Pete
-
FS98 user with FDC and Meteo
Pete Dowson replied to tp142's topic in FSUIPC Support Pete Dowson Modules
Sorry, I don't know what you mean by "conflicted", and I am pretty sure FDC works even now with current versions of FSUIPC and most if not all versions of FS. There really is no way to use a mix of old versions. Sorry. Pete -
It isn't easy. In fact it is almost impossible unless I can trap the error in FSUIPC or get a full stack trace. The information you posted would be very useful IF you were using the exact same version of FSUIPC as me, because I could then find exactly where in the code the FSUIPC crash was. To that end please reproduce it using FSUIPC4812f On this one: If your DLL is creating another thread then you need to have it terminating itself when the main Lua thread terminates. To do this try using event.terminate which should allow you to call some function in your DLL to close down. Regards Pete
-
FS98 user with FDC and Meteo
Pete Dowson replied to tp142's topic in FSUIPC Support Pete Dowson Modules
I moved your support question to the Support Forum. You posted it into the FAQ subforum where it won't get answered -- that's a place for collecting standard answers. You should be using 3.999 not 3.71 or 2.73 which are not supportable. I don't know any reason for those two products to get into any trouble with later versions, as great care is taken to maintain compatibility. although some programs incorrectly state they need a specific version, they really mean they need AT LEAST that version, no earlier, because they need some facility which was not added till then. Facilities are never actually removed (though i'd dearly love to, sometimes!). Regards Pete -
Assign pots and keyboard flaps
Pete Dowson replied to sisoffi's topic in FSUIPC Support Pete Dowson Modules
Aren't they simply sending the normal FLAPS UP, DECR, INCR and DOWN controls as assigned in FS by default? If so I would have thought FLAPS SET would work too. FSUIPC and WideFS do not handle two PCs with FS running, so I assume you mean "can multicrew do it"? If this is what you are asking you need to ask them as I do not know that product at all. If you meant to ask whether you can assign regions of an axis to FS or FSUIPC controls, and thereby send the flap controls, or if necessary the key presses, as you move the lever, then the answer is 'yes' -- that's what the right-hand side of the Axis assignemtns tab is for. You can assign actions to up to 10 regions of the axis movement, with different actions moving up and down and in and oout of each region. For 5 flap positions I suppose you'd assign 5 regions, with Up assignments = Flaps up -- flaps incr -- flaps incr -- flaps incr -- flaps down Down assignments = Flaps up -- flaps decr -- flaps decr -- flaps decr -- flaps down Just then make sure you start full up or full down or they may not be synchronised. If you must use keypresses instead of FS controls you can assign to the FSUIPC-added key press/release controls. Regards Pete -
Sorry, no. Really it isn't software support or development at all, which is what i do. Try raising a problem report with Simmarket or PayPal. Regards Pete
-
If you were running RC and you asked for ATIS via RC, then it most certainly will ask FSUIPC for the weather and this will be logged. I believe RC checks the weather at other times too, to get the QNH when descending to altitudes, for example, and to determine runway to use (as well as looking at whatever runway the AI traffic are using). If RC is not reading the weather then it cannot give you the wrong winds -- it can't give you any winds. I don't think it invents them on its own! Currently it seems that either RC is not reading any weather, or RC is not running, or it is running but it is not connecting with this install of FS. If RC is actually running you need to ask RC support why it isn't reading weather. You'll probably be asked to supply an RC log. Regards Pete
-
Sorry,"replicate" ==> reproduce the symtoms. Reproduce the problem of RC asking for the weather and getting it wrong. Logs showing normal weather-at-aircraft entries with no requests being made don't tell us anything. So far you've not shown anything asking for any weather, not at all. Regards Pete
-
In that case RC is not asking FSUIPC for any weather. Tyoes 1 and 5 are the standard weather offset populating requests done by FSUIPC all the time, for weather at the aircraft, and don't use ASE. Well you can usually attach them if they are Zipped, but i don't really want them. If i need to look, I'll say so. But first you'll need to replicate RC asking for weather. Regards Pete
-
Acars development - Flaps
Pete Dowson replied to eamello's topic in FSUIPC Support Pete Dowson Modules
What version of FS are you aiming this at? If for FSX you can get the index number from offset 0BFC. (0 = full up). Pete -
Sorry, I misled you. I had extra logging enabled in my example. I forgot to disable it. The sort of entry to look for in your case, with weather logging enabled, is this: 98766 Weather Read request (At Lat/Lon) to area 3: Lat=50.00, Lon=-0.00, Alt=0.0, Req=0 98938 Weather requested from ASE for Lat 50.0000, Lon -0.0000 99031 WX Received in (null), WX request type 3, ICAO=EGCC 99031 Weather received from ASE: "???? 021529Z 22501KT&D457NG 340V060 30302KT&A914NG 28104KT&A1829NG 24710KT&A2743NG 26713KT&A3658NG 26425KT&A5486NG 26425KT&A7315NG 26131KT&A9144NG 26630KT&A10363NG 28025KT&A11887NG 29416KT&A13411NG 29717KT&A14935NG 51KM&B-2000&D4000 3ST114&ST000FNVN000N 1ST159&ST000FOVN000N 10/03 06/M06&A914 00/M12&A1829 M01/M13&A2743 M10/M22&A3658 M24/M36&A5486 M36/M48&A7315 M49/M61&A9144 M55/M67&A10363 M55/M67&A11887 M55/M67&A13411 M61/M73&A14935 Q1007"[/CODE] Search the log for "Weather requested from ASE" or "Weather received from ASE". There is no request for weather from any outside program logged in the section of Log you posted, so you won't find it there. You shouldn't click any other buttons really, but that's up to you. it will stop one log file and start a new one. I don't need to see these files, i just want you to look for the right things so you can see the METAR being supplied. If for some reason ASE doesn't supply the weather, the equivalent log entries for a request for weather at Lat/Lon will be like this: [CODE] 62500 Weather Received (type 3 request, Interpolated): "????&A0 021559Z 10809KT&D304NG 101V115 7000&B-1500&D2040 CLR 15/12 Q1013 " 62516 WX Received in 110 mSecs, WX request type 3, Lat=50.0000, Lon=-0.0000, Alt=0.0m[/CODE] The METAR here is one from FSX, not from ASE\AS2012. That's because i didn't have ASE/AS2012 running. The common thing between these is "[color=#ff0000][b]type 3[/b][/color]" so you could do your search on that. All type 3 requests are from external programs. BTW, I assume you've checked that you don't have [b]"UseASEweather=No[/b]" in your FSUIPC4.INI file? That parameter shouldn't be there, and it then defaults to using ASE/AS2012 if the latter is set to DWC mode. You can set it to "Yes" to force it to use ASE/AS2012 all the time, even if DWC is not being used. Found what? Sorry, you've lost me. Regards Pete
-
That should be working fine, then. It does for everyone else. That log entry certainly means that, in DWC mode, FSUIPC will be getting the weather from AS2012 or ASE, whichever it is, when it is being requested by any program. Check for yourself. Enable Weather Logging in the FSUIPC Logging tab. This will probably cause a lot of logging, and when something asks for weather at a particular Lat/Lon there'll be an entry like this (this is for a single request made for Lat 50/Lon 000): 127485 Weather requested from ASE for Lat 50.0000, Lon -0.0000 127500 NWIread: ### NWIR ### Weather read: ICAO= , Lat=50.000, Lon=-0.000, Elev=0ft 127500 NWIread: Pressure=1010.0, Drift=0.0 127500 NWIread: Visibility[0]: range=24.9sm (39992m), from=0ft, to=0ft 127500 NWIread: Temperature[0]: alt=0ft, Day=11 C, NightVar=0 C, DewPt=4 C 127500 NWIread: Temperature[1]: alt=3000ft, Day=5 C, NightVar=0 C, DewPt=-7 C 127500 NWIread: Temperature[2]: alt=6000ft, Day=0 C, NightVar=0 C, DewPt=-12 C 127500 NWIread: Temperature[3]: alt=9000ft, Day=-1 C, NightVar=0 C, DewPt=-13 C 127500 NWIread: Temperature[4]: alt=12000ft, Day=-10 C, NightVar=0 C, DewPt=-22 C 127500 NWIread: Temperature[5]: alt=18000ft, Day=-23 C, NightVar=0 C, DewPt=-35 C 127500 NWIread: Temperature[6]: alt=24000ft, Day=-35 C, NightVar=0 C, DewPt=-47 C 127500 NWIread: Temperature[7]: alt=30000ft, Day=-49 C, NightVar=0 C, DewPt=-61 C 127500 NWIread: Temperature[8]: alt=34000ft, Day=-55 C, NightVar=0 C, DewPt=-67 C 127500 NWIread: Temperature[9]: alt=39000ft, Day=-55 C, NightVar=0 C, DewPt=-67 C 127516 NWIread: Temperature[10]: alt=44000ft, Day=-55 C, NightVar=0 C, DewPt=-67 C 127516 NWIread: Temperature[11]: alt=49000ft, Day=-62 C, NightVar=0 C, DewPt=-74 C 127532 NWIread: Surface wind: to alt=1500ft AMSL, dir=207T, vel=2.00, gust=0.0, turb=1, shear=0, var=260.0 127532 NWIread: Wind layer 1: to alt=6000ft AMSL, dir=345T, vel=1.0, gust=0.0, turb=0, shear=0, var=0.0 127532 NWIread: Wind layer 2: to alt=9000ft AMSL, dir=239T, vel=5.0, gust=0.0, turb=0, shear=0, var=0.0 127532 NWIread: Wind layer 3: to alt=12000ft AMSL, dir=225T, vel=10.0, gust=0.0, turb=0, shear=0, var=0.0 127532 NWIread: Wind layer 4: to alt=18000ft AMSL, dir=252T, vel=14.0, gust=0.0, turb=1, shear=0, var=0.0 127532 NWIread: Wind layer 5: to alt=24000ft AMSL, dir=257T, vel=24.0, gust=0.0, turb=0, shear=0, var=0.0 127532 NWIread: Wind layer 6: to alt=30000ft AMSL, dir=260T, vel=27.0, gust=0.0, turb=0, shear=0, var=0.0 127532 NWIread: Wind layer 7: to alt=34000ft AMSL, dir=267T, vel=32.0, gust=0.0, turb=1, shear=0, var=0.0 127532 NWIread: Wind layer 8: to alt=39000ft AMSL, dir=272T, vel=32.0, gust=0.0, turb=0, shear=0, var=0.0 127532 NWIread: Wind layer 9: to alt=44000ft AMSL, dir=279T, vel=26.0, gust=0.0, turb=0, shear=0, var=0.0 127532 NWIread: Wind layer 10: to alt=49000ft AMSL, dir=301T, vel=17.0, gust=0.0, turb=0, shear=0, var=0.0 127532 NWIread: Wind layer 11: to alt=52000ft AMSL, dir=306T, vel=15.0, gust=0.0, turb=0, shear=0, var=0.0 127532 NWIread: Cloud[0]: type=8, from 17700ft to 18200ft (+/- 0ft), cover=4, turb=1, topshape=0 127532 NWIread: Precip=0, base=0ft, rate=0, icing=0 127532 NWIread: Cloud[1]: type=1, from 27700ft to 27900ft (+/- 0ft), cover=3, turb=0, topshape=0 127532 NWIread: Precip=0, base=0ft, rate=0, icing=0 127532 NWIread: **** End of New Weather details for ICAO= 127563 Weather received from ASE: "???? 021233Z 20702KT&D457OG 330V070 34501KT&A914NG 23905KT&A1829NG 22510KT&A2743NG 25214KT&A3658OG 25724KT&A5486NG 26027KT&A7315NG 26732KT&A9144OG 27232KT&A10363NG 27926KT&A11887NG 30117KT&A13411NG 30615KT&A14935NG 40KM&B-2000&D4000 4ST177&ST000FOVN000N 3CI277&CI000FNVN000N 11/04 05/M07&A914 00/M12&A1829 M01/M13&A2743 M10/M22&A3658 M23/M35&A5486 M35/M47&A7315 M49/M61&A9144 M55/M67&A10363 M55/M67&A11887 M55/M67&A13411 M62/M74&A14935 Q1010"[/CODE] The crucial parts there are [CODE] 127485 Weather requested from ASE for Lat 50.0000, Lon -0.0000 [/CODE] and [CODE] 127563 Weather received from ASE: "???? 021233Z 20702KT&D457OG 330V070 34501KT&A914NG 23905KT&A1829NG 22510KT&A2743NG 25214KT&A3658OG 25724KT&A5486NG 26027KT&A7315NG 26732KT&A9144OG 27232KT&A10363NG 27926KT&A11887NG 30117KT&A13411NG 30615KT&A14935NG 40KM&B-2000&D4000 4ST177&ST000FOVN000N 3CI277&CI000FNVN000N 11/04 05/M07&A914 00/M12&A1829 M01/M13&A2743 M10/M22&A3658 M23/M35&A5486 M35/M47&A7315 M49/M61&A9144 M55/M67&A10363 M55/M67&A11887 M55/M67&A13411 M62/M74&A14935 Q1010"[/CODE] The latter is the actual extended METAR string received from ASE or AS2012. All the intervening stuff is the decoded data which goes to the requesting program (WeatherSet2 in this case, Radar Contact in yours, it's all the same no matter who asks). One thing which may be going wrong in your case. I know that RC does not correctly follow the protocol for reading the weather, in that it doesn't check that the weather data supplied is the weather for the location is asked for, and it doesn't protect its request with a unique lock code. So anything else also reading weather at sepcific locations from FSUIPC can mess what RC reads up. Check what other programs you have which may also be reading the weather. Some weather radar programs do, like SA_WXR for instance. Regards Pete
-
P3D Ver 1.3 + FSUIPC 4.812 - Crash in Multiplayer
Pete Dowson replied to FSMP's topic in FSUIPC Support Pete Dowson Modules
I made some other changes to try to detect MP changeover (It seems I can't -- the requested events never arrive, like everything else, hence the "stall" diagnosis), but i also removed the "is Simconnect receiving from FSUIPC?" check. maybe that'll help in the crash case, as that was where P3D appears to be stumbling. It doesn't appear to like the Event State being changed whilst it is loading or reloading things. Try FSUIPC 4812f Regards Pete -
Sounds like FSUIPC cannot connect to AS2012. Are you running AS2012 on the same PC as FSX? If so, does the FSUIPC4 log show a connection? Show me the FSUIPC4 log file if you aren't sure. If you are running AS2012 on a separate PC then you need WideClient on that PC reading the AS2012 weather instead. What version of Wideclient are you using? maybe it is out of date? Pete
-
The METAR block for the predominant wind speed is not the only relevant block. Watching a static block won't make things any clearer. And if that was what was really happening, would you seriously expect the ATIS tape to be continually revised to say so? Even if there is no other block in the METAR specifying the degree of variablility (and there need not be for such light winds), it doesn't mean there shouldn't be. It really sounds to me like FSX doing its thing, and all quite reasonable. If you want absolutely fix air movement (totally unrealistic) I don't think you want to use FSX, but maybe FS98 or similar, before they introduced an atmosphere simulation. If you were exactly AT the weather station being reported, I don't know whether RC reads the weather at the WX station's Lat/Lon, or simply reads the local weather at the aircraft. In the latter case the weather is what is simulted at the aircraft inside FSX. FSUIPC only gets METARs from AS2012 when asked for "weather at Lat/Lon" or "Weather at XXXX" (ICAO ID). If RC is asking for weather at a Lat/Lon, which it usually does for the ATIS, I think, then FSUIPC passes that request to AS2012, and regurgitates that back to RC in FSUIPC's format (as in FS2004 and before when METAR strings weren't used in FS). I don't know if the Lat/Lon must be EXACTLY on the WX station shown on the AS2012 screen or not, but it probably won't be, so there will probably be some small degree of interpolation going on as well. Furthermore, it may be that AS2012 keeps its internal data up to date and changing more often that it updates its screen display, to replicate a notmal ATIS update cycle. There are so many possible variables going on here that I can't really help you go into it further. As it is I see nothing wrong. I don't know why you do, but if you want it explained further I'd have to point you to AS2012 support. Yes. Nothing can "nail" anything in a realistic simulation in any case. Wind smoothing is totally separate from any of this. It is not involved in any way in the passage of METAR data from one porgram to another. It is simply an attempt to stop changes occurring too fast -- but NOT prevent turbulence, gusts or variations. If you don't want those you have to suppress them separately. Their simulation is superimposed on the basic wind setting. Both FSUIPC and AS2012 have suppression facilities. You'd need to use both if you really do want more straight-jacketing. Pete
-
Is this with the default 738? 0B5C is not really the correct offset for "APU active". That'll only go non-zero when you atart the APU generator AFTER the APU is running. To detect APU running okay check for 0B54 (FLT) being above 99 (it never quite reaches 100% exactly, 99.99933 is the highest I see here). All the other offsets will then be zero until you switch on the APU generator, after which you'll get both Generator bytes set to 1 and the voltage non-zero. Here are two pictures showing the relevant offsets displayed by FSInterrogate. The first is with the APU started but the generator off, the second with the generator on as well. It does work (with the 738), so you are doing something wrong. Regards Pete
-
CH Yoke for pushback and turn ~~~
Pete Dowson replied to Ken Hall's topic in FSUIPC Support Pete Dowson Modules
Moved from the FAQ subforum where it won't be answered ... You'd probably be better off assigning direct ot the FS controls rather than to keypresses which are then assigned in FS to the controls. Why use the keyboard when it isn't necessary? The pushback control is "toggle pushback" and the 1 - 4 selections are "select 1" through to "select 4". Of course, keypresses grabbed by other programs will take precedence. I reassign all the RC controls to Control+Shift+X combinations in any case to avoid all possible conflicts. Buttons? Sorry you've lost me there. Sorry, I'm confused. You are assigning to keypresses and it is the keypresses which are getting mixed up or overridden. What are buttons to do with that? I cannot find the "inference" you mention either. My #2 point on page 30 (right at the botton) is cpncerned with Aircraft or Profile specific button settings. What version of FSUIPC and Manual are you looking at? Oh, saw this after. Still, I hope the above is still useful -- controls, when available, are always prefereable to keypresses. Regards Pete -
No. Why not use PayPal? Pete
-
For you, WHAT doesn't work? You need to be more specific. Pete
-
Neither of those is in any way related to FSUIPC. Both programs se SimConnect directly. Pete
-
If you mean clodbase (coud height it not detectale nor conmtrollable in FSX), then check whether you are comparing AGL with AMSL -- what's the ground altitude at the weather station? Sounds like there's some variability. Without showing the actual METAR I can't tell you. ALWAYS check against the METAR, not a partial interpretation. No one is deliberately distorting or lying about weather. The data is simply passed through, but it sounds like you are not interpreting everything correctly. Regards Pete
-
What version of FS? What version of FSUIPC? Those offsets certainly work with FSUIPC4 in FSX with the default 737-800. I don't know if they work with anything else. They are just the values SimConnect supplies for the FSX APU. If you are using an add-on aircraft which doesn't use the inbuilt FSX APU then you'll probably need to look elsewhere. BTW Offset 0B5C is a 32-bit float. Checking only its lowest 8 bits ("UB" == Unsigned Byte) is wrong. If could be zero or anything. Always use the correct type designation for the variable being read. Of the ones you mention only 0B51, 0B52 and 0B53 are "UB". Regards Pete
-
It means the Server is not seeing any messages from the Client, but messages sent out from the Server are getting to the Client. Once Clients have registered their interest in specific data they contnue to receive it regardless. Nevertheless, the Server will normally give up on a client if it doesn't see messages from it for a long enough period (a value changeable in the INI file, but defaulting to something like 20 seconds). Maybe it is getting a fleeting connection now and then, enough to get it to continue transmissions -- but I've never actually seen a situation such as the one you are describing. If you'd like to paste your WideServer.log and WideClient.log files into a message here, when you have a situation sch as you describe, then I can look to see what is going on. Regards Pete
-
P3D Ver 1.3 + FSUIPC 4.812 - Crash in Multiplayer
Pete Dowson replied to FSMP's topic in FSUIPC Support Pete Dowson Modules
Could to reproduce that please, but first check the "Log Extras" option in the FSUIPC logging tab (or set the number in the edit box to 1, if there's one showing). I could do with seeng the timings of "Sim Stop" and "Sim Start" events, which that will then show in the log. There's something changed between P3D 1.2 and 1.3 which really messes up FSUIPC's recovery attempts on timeouts. It seems to revolve around the business of closing and opening SimConnect connections -- which, of course, incldes removing the Menu and adding it back afterwards, which was aone of the areas changed in 1.3 to fix the crash on exit problem. I have no way of tunnelling into what is actually happening in the P3D code to do this. All I can think of doing is just completely avoiding some of the checks I do, which worked okay before and work okay in FSX, and risk of having a non-operative FSUIPC in a running P3D remain rather than attempting recovery. Maybe the risks are neglible in any case. I don't know. with FSX any heavily loaded system can sometimes result in a SimConnect stall, though this seems to happen far less with FSX SP2 than it did in earlier releases. After I see the log with Extras logging I'll decide what to do. Regards Pete