Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. I get the same for that -- the APU Starter control definitely starts it according to the internal variables as supplied by Simconnect. I think it's just the local gauges which are rubbish. There's no SimConnect variable for that, so I suspect it's a local value only in the gauge, not in the actual simulation. The simulation supplies RPM and generator voltage -- the latter only after the generator is turned on of course. You shouldn't get any amps either without the generator. Regards Pete
  2. From your WideClient log earlier, this line: 2996 Trying to locate server: Need details from Server Broadcast indicates that you allow Wideclient to find the Server by itself. That's fine, and then you can choose the protocol in the [WideServer] section of the FSUIPC4.INI file. It's "ProtocolPreferred=UDP". Please have a read of the first feew paragraphs in the "Configure Your Network" section in the WideFS user guide (about the 4th page). However, if you have both wired and wireless services in the Server, with different IP addresses, you'd need to use both the ServerIPAddr and Protocol parameters in the WideClient.INI file in order to make sure it chooses the right one. Are you sure there's nothing around which might be generating intereference at certain times. Some machinery maybe? Anyway, the wired connection test should eliminate airborne intereference. Regards Pete
  3. You posted a support question in the Download Links subforum, where it won't get answered. I've moved it for you. Please always use the Support Forum for support! There's no change in FSUIPC except for the removal of the signature. Did you delete your settings? By "I loosed all function ..." do you mean you LOST all functions in previous versions? I don't really understand this wording (loose = not tight). And what flight simulator are you using -- FS98, FS2000, FS2002, FS2004, FSX or P3D? How is your GF-MCP driven -- using GoFlight drivers, or by FSUIPC assignments? If the latter, note that FSUIPC does not provide any support directly for any displays or lights, so either you used GFDisaply, or you had a Lua plug-in for it. If you deleted anything before installing then you probably lost all your settings and registrations. Never delete things when updating, just run the Installer. Pete
  4. Sorry, I don't know. Maybe you have to keep sending APU Start until it starts, a bit like the spring-loaded prop starter (on the Magneto switches). Is this the default FSX 737? The real APU switch has 3 positions, with the "start" position spring loaded against it. The opposite "off" position latches. I don't think I've ever used the FSX APU. [LATER] After checking, the "APU Starter" and "APU Off switch" assignments in FSX appear to do exctly the same. Since all FSUIPC does is send the same thing, it will obviously have the same results. Whether the on-screen switch is used, or the FS control, the APU does actually start and stop with these controls. This you can verify by monitoring the APU RPM percentage at offset 0B54 as a FLT32. And when it is running the APU Generator switch does provide a good voltage as seen in offset 0B5C (another FLT32). But the APU EGT dial on the default FS Overhead doesn't do anything, and the switch doesn't show the actual status of the APU either. I think the overhead in the default 737 is merely cosmetic, it does very little to show you what is going on. Regards Pete
  5. I always recommend hardwiring if possible, in any case, and it's worth a shot here just in case the wireless link is glitching. Yes, puzzles me too. Hmm. Maybe, but why only WideFS? But it's an area I know little of. I only run AV and Firewall stuff on my development PC, where I also do all my support and download/upload activity. Whilst the cockpit PCs are also all connected to the Internet, I don't do email or interact on websites specifically on any of those. I rely on good security settings in the Router. Regards Pete
  6. Hardware problems are things which develop, unlike software which stays the same unless it gets its data corrupted. BTW you are lucky that you don't get intermittent cross-interference on the wi-fi link. In my house i find WiFi is fine for short-term data exchanges, eg with iPhone and iPad, or even file transfers to/from a laptop, but I can't rely on it for regular continuous connections such as that needed by WideFS when flying -- at least, not in rooms with lots of electrical equipment running like my cockpit room! It might be worth trying it even if only as a way of eliminating things like the router and the hardwired ethernet connection. If you were to adopt this permanently it would be best to keep your internet (router) connection hardwired, for speed, and, using a different (fixed) IP addrerss for the wireless side, put the explicit IP address into the Client INI file so it uses that wirelss link, not the one to the router. I don't know. It might well imply a problem at the client end, or with the Wireless part of the router. Do you still have good internet connection from the Client after WideFS disconnects? Is ActiveSky running on the Client, then? UDP is the protocol that SimConnect and Windows Explorer uses. One problem is that I'm by no means a Network expert. Whenever I've had problems in the past I've always had to narrow things down by trial and error, eliminating things bit by bit. What seems odd in your case is that it started when you changed your Server PC, so it is more likley to be related to that, unless you can thing of something else that's changed. Regards Pete
  7. The issue seems to be simply that all of a sudden neither end can see any requests or replies arriving from the other, just like a physical disconnection : And it isn't temporary. Retries (attempts at complete reconnection) aren't working: So, things get stopped or blocked or disconnected after nearly 24 minutes, and the reconnection doesn't work -- not 'refused', just ... nothing, no response. The error 10060 is from Windows. The identical problem really, reflected at the Server end at the same time. This really is looking like some sort of hardware problem. Maybe overheating, or a real intermittent fault in the Ethernet hardware at one end or the other. Are they both using motherboard-based Ethernet? Any chance of trying a separate Network Interface Card instead -- first one end, then the other, which should clearly identify which end is responsible. Or if you are using a separate card, moving it to a different slot perhaps. If I thought it was a software issue, maybe network drivers, I'd suggest trying UDP protocol instead of TCP. It might be worth a hot, but it does look like hardware to me. Regards Pete
  8. I knew of them. In fact till recently I owned an ATC610 analogue flight simulator console, designed for IFR training. All the aspects of flying, the inputs and results, carried out by interacting analogue circuits. Amazing! I even had the maintenance manual showing most of the circuitry. Too complex for me -- digital systems are so much simpler really! Pete
  9. The event.intercept function only does what it is documented as doing -- intercepts any write to the nominated offset by any client application, module or gauge. The write internal to FSUIPC from your assignment is not going to be seen as it is not from an outside agency! All you need to do to accomplish exactly what you are trying to do there is assign the axis directly to Lua TestScript and have that simply do this: ipc.control(64104, ipcPARAM) because the axis value is passed as ipcPARAM. Of course it would be more efficient to assign it directly to that control in the first place, but I'm assuming here that you are experimenting in order to do something more ambitious? Also, it isn't clear why you might want to stop 66C8 from receiving the value, it being a free user offset in any case. The normal reason for an intercept is to prevent something doing something, or modifying it first. To use an event you'd be better off allowing the offset to be written and use event.offset to call your function each time it is changed. Regards Pete
  10. What's the "cabin high"? Do you mean the equivalent cabin altitude for the current cabin pressure? If so, then I'm afraid all the SimConnect pressurisation values are read only (the ones mapped to offsets 0318 to 0328). These are only used to drive default pressure gauges on some asircraft. If you wanted to change a real gauge reading FSUIPC offsets you could use the "spoofing" options for offset values, (see offset 0024 and the Lua example). Pete
  11. Any of several ways, depending what other weather you want, what weather mode you are using, and which interface you are using. With FSX you can't simply set one aspect of the weather -- SimConnect expects to see a full METAR. If you use something other than the New Weather Interface then FSUIPC has to fill in the rest from the weather it is reading. Pete
  12. In that case it would have been identical except for the removal of the signature check. If you have no backup of your earlier INI file then you wil need to find the method of assignment which works for the A2A aircraft. Either try them, or ask around, mabe in an A2A support forum? The different methods are: Direct to FSUIPC calibration To the FS controls AXIS_<type>_SET, which is what FS itself would do To the FS controls <type_set> Then, in calibrations, you have the option for No Reverse Zone or not, and in the INI file the option to use axis controls for No Reverse Zone. All in all 3 assignment methods x 3 calibration options = 9 to try. Regards Pete
  13. That exception code isn't "unknown", it is defined as "SIMCONNECT_EXCEPTION_UNRECOGNIZED_ID". The parameter position -1 is the first parameter in whatever the call was, and the send ID is simply the ID assigned, by SimConnect, to the request. Without the context (where are you looking, SimConnect log?) nothing more can be derived from that. Such errors are not always a problem. For instance, something which is reading details of AI trasffic, monitoring their position perhaps, may get such an error when a monitored aircraft is deleted, because it has finished or left the FS "reality bubble". This will happen en bulk if you reload a flight or change the traffic sliders. Sorry, that's almost gibberish to me. What's a "host UGT" and what's "advancing to a next hop"? Regards Pete
  14. Version numbers -- before and after -- would actually help identify changes in FSUIPC. Surely you didn't delete your settings (the INI file)? The installer most certainly doesn't change them. I'm afraid I really don't know what is different specifically about A2A aircraft. Maybe if you do a search you might find clues from others. But first if I were you I'd try to find a back up for the settings file you must have deleted. Regards Pete
  15. I started as a test programmer on Leo Computers, way back in 1963. Not even assembly code to begin with -- pure binary bootstrapping hand punched on tape (using a unipunch!), to load in a Hex Loader so I could then feed in programs written in hexadecimal machine code typed on a telex machine. When we got as far as getting Assembers working it was pure luxury! I then wrote my first multi-tasking engineer's supervisor to build the rest of the test suite upon. Of course each level had to test its way through. This was all for large mainframes being developed and built whilst we worked! I later dabbled in higher level languages like Algol, Fortran and APL, but really only used assembly language until the Pet 2001 computer came out in the late 70's. Then it was a mix of that and 'Basic' (ugh). My first serious program for PCs (Wordcraft) was developed mostly in BCPL, a predecessor to C from Cambridge University. Showing my age, aren't I? ;-) Pete
  16. No idea. I for one, for sure. I don't like to be too far away from the hardware. i use Assembly code as well when I feel it can do a better job! ;-) Pete
  17. Maybe part of the cut-down to make it an "Express" edition? Pete
  18. Seems an easy enough fix: Pete
  19. Paste text files into your message. It is easier. If it is very long, just extract the relevant part, and a bit before for context Haven't you looked yourself for anything suspicious? Pete
  20. You've double checked that nothing is assigned in FS itself? In FSUIPC that merely makes it rescan USB HID devices. That would have no effect on a COM device, but it does make one suspicious about interference from a USB device, or maybe a USB driver with no actual device now connected. With PFCFSX i don't think simply going into the options and coming out again does anything. What's this "reloading settings" message? From which? Well, I certainly don't know that one way or the other. I must have been referring you to someone else's findings. There are many add-on aircraft which respond quite normally to the standard FS flaps, spoilers and reverse facilities in PFCFSX. Which issue is that? Regards Pete
  21. What is a "usual C/C++ project" if it isn't a 32 bit Windows program? Sorry, you've lost me. The Microsoft development systems are challenging to everybody, I assure you. I have been a programmer now for nearly 50 years and I gave up on figuring out most of the confusing options in MS VS. You have all the source, for UIPCHello and even for the library. in fact it was another user who recompiled the library for VS2010, not I. If you cannot build a small C/C++ program with the sources of what you need, I think you need to refer back to basic C programming? If it's only Microsoft's systems which are defeating you, join the club. Only Microsoft Help may help. If I were you I'd start by considering why you aren't wanting to build a Win32 program. What other sort of program would you think be able to interface to FS, which is itself a Win32 program? Regards Pete
  22. Odd when wsprintf is a standard Windows API function, defined in the standard WinUser.h header. Seems you omitted to specify a needed library file? I just tried building it with VS2010, allowing VS2010 to convert my old VS2003 project file into the new VS2010 format and it compiled and linked okay. In the Command Line entry in Properties-Linker it lists all these libs which I didn't actually specify but which it seems to include in any case for a Win32 project: Maybe you've not selected a Windows 32-bit project type? "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" Only the Microsoft documentation ro set up a normal Win32 project. I'm really not well up on all the little incompatibilities Microsoft builds in between its assorted releases. All development systems are different in their own ways. I still have to use VS2003 to build FSUIPC3 even though i use VS2010 to build FSUIPC4. And for many of the other FSX-related DLLs I use VS2005! I found sticking to the original versions of VS far easier than trying to figure out their arcane settings. Regards Pete
  23. I've moved your post, which you placed in the Announcements subforum. It obviously is not an announcement! Please use this, the Support Forum, for questions. A registration for FSUIPC3 is valid for the lifetime of FSUIPC3, no matter which version of FSUIPC3. It just is not valid for FSUIPC4 (nor vice versa). You don't need to change the Email, and you cannot. It isn't used as an Email address in any case, only a means of identifying you uniquely. Names are insufficient to do this alone. Pete
  24. Through FSUIPC offset 3110 you can send any FS or added FSUIPC control you wish (except for the FSUIPC offset controls of course). Pete
  25. Strange. I use PFCFSX.DLL for my cockpit controls (the full dual control 737NG 'pit from PFC) and have no such problem. And certainly there's been no change in this for years. Are you sure you don't have some conflicting assignment in FS or FSUIPC? No, nothing's changed for a long time in any such area. And you've really proved that it works okay by saying "The ONLY repeatable way to fix the issue is to restart PFCFSX.dll and FSUIPC.dll- then all is well- usually for the rest of the flight.". But, I don't understand really what you mean by "restarting" PFCFSX.dll and FSUIPC.dll. The only way to "restart" FSUIPC is by restarting FS. You can get PFCFSX to restart by changing the COM port to none and then back again, as if the COM port had changed, Is that what you are doing? All my PFC axes are assigned and calibrated in PFCFSX except for Rudder and Steering Tiller, which are mapped direct to calibration in FSUIPC so that I can get the gradual transfer of steering from tiller to rudder as groundspeed increases when on the takeoff roll. But if I didn't have a tiller they'd all be in PFCFSX. Of course I don't fly the PMDG aircraft (as it won't work with Project Magenta or without its own cockpit), but I wouldn't have thought that would make a difference -- though it might be worth checking what happens with other aircraft. Also check that it isn't some simulated fault or problem, like engine icing for instance. Maybe your anti-ice switching is only operating on Engine 1. Otherwise all I can suggest is logging axes in FSUIPC to try to identify where or how the inputs are being lost or overridden -- it does sound more like interference than real loss of input. Pete
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.