Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    37,910
  • Joined

  • Last visited

  • Days Won

    155

Everything posted by Pete Dowson

  1. How can the lack of drawing of part of the image be a driver problem? I don't understand? Everything else is working. I've NEVER been able to use the smoothing options in any case. On my Athlon 700 (the one I'm using now), but with the GeForce II Ultra I had on there before, those options cut the graphics frame rate from around 80 down to 10 or so and everything ran very jerky. On the other PC (now disused thanks to the Parhelia) which was an AMD 450 MHz PC using an nVidia MX card, switching those options on consistently caused the PFD display to hang or crash. I tried to sort all this out with Enrico a number of times, but it never got resolved so I ALWAYS ran without smoothing. To me, the new fonts looks horribly thick and too bold with smothing enabled in any case. Without the smoothing some characters are badly formed, but at least everything runs smoothly and is very readable. Regards, Pete
  2. No way. You may be confusing WideFS with WidevieW which is entirely different. You may have missed the entire point of WideFS. It is explicitly designed to link FS applications on a Network to FS running on one PC. This is an alternative to running the applications on the same PC as FS. There is only ever one copy of FS as far as WideFS is concerned. All WideFS is providing is a Network-wide FSUIPC interface for applications. Please read the documentation which explains it all at length. Regards, Pete
  3. Hi again Stuart, RightI reverted my code to the way it used to be before I made it work on XP, and it DOES shut down Windows 98 okay. The problem seems to be that on Win98 the "SHUTDOWN" keyword is needed to power off the PC, whereas on WinXP the POWEROFF keyword is needed. If I use the POWEROFF keyword on Win98, it merely logs off the user (AND, I notice, leaves a WideClient process running in the background!). So much for Microsoft reference documentation! Sorry about that. It'll be fixed in version 5.50 of WideFS which I'll release soon, maybe over this weekend. I've changed the default to TCP/IP and made a few other tidy-up/cosmetic improvements too. Regards, Pete
  4. Okay. I've tried this now. They seem to be interlinked. If I turn on Font Smoothing, Line Smoothing comes on any way. If I turn off Line smoothing, font smoothing turns off too. they act as one option. Other odd things. When I first tried it, the whole right hand part of the PFD (the VSI scale and indications, including vlaues above an below) just disappeared, and the display frame rate sank from 30-34 on each of the three windows to about 11-16. This seems to be solved by going back into the Menu and disabling line Smoothing (not Font smoothing, which menu item seems non-operative -- though they BOTH switch off together). This brings back the missing parts of the PFD. THEN re-enabling font or Line smoothing makes it all work, the whole PFD, and at about 21-26 fps on all three, not too bad. BUT, and here's the catch. If I close them all down and start them all up again with this smoothing on, they come back with the partial PFD display and poorer frame rates. Each time I load up, I have to CTRL M to enable the Menu, switch off, then switch on the smoothing, then CTRL M to turn the menu back off. That is intolerable, so I'll do without smoothing. Seems some attention is needed to this area of PM? I doubt if Enrico will be reading this, he doesn't like Forums, so could you copy him please? Best regards, Pete
  5. But it doesn't do a thing on Win2000 or WinXP. I sent Enrico the code amendment to get it to work on XP. Both his code and mine were once the same. This should mean that WideFS 5.30 or earlier would have shut down your PC -- but that uses the "SHUTDOWN" call, not the "POWER OFF" call, and folks complained that it didn't power off, only went to the place where Windows said "you can now turn your PC off". I'll try reverting the code to the way it was (and, I think, PM still is) and check it on my one remaining Win98 PC. It is VERY confusing! Regards, Pete
  6. Ah .. thanks. Now we're getting somewhere. The other PCs now don't say that it is inaccessible! They then asked for a User Name and Password. I had to go back to the XP Pro PC and re-enable the drive sharing that I'd already enabled before! Why do they bury these options in such obscure and apparently unrelated places? Thanks! It all works (again) now! Pete
  7. Oh, it's a Menu item? I didn't realise that. I'll check. I can't use that PC for PFD at this moment -- having installed WinXP I've just converted from FAT32 to NTFS (using Partition Magic) and now PFD needs a new Key. I'm sending off for one now... Before that I got rid of the jerkiness by setting "UserTimer=On" in all three copies of PFD that I'm running. before, on an nVidia card, and with only the one PFD.EXE running, I found it smoother with "UseTimer=Off", but it looks like the PFD code needs to relinquish the processor via UseTimer in order to allow the other copies of itself to get regular time slots. I had the same problems (or so I thought) on two machines. One is XP Home the other XP Professional (I had to go to Pro because I was using Win2000 pro on it before). I managed to sort the Home one out by copying ALL of the Advanced properties in the TCP/IP section of the Network properties -- I think the stumbling block was probably the "NetBIOS over TCP/IP" option which wasn't selected, but it might have been one of the other things. But I have EXACTLY the same selections on my XP Pro system AND no firewall, yet, whilst that PC can share files on all the other PCs, none of the others can see files on it. They all simply say it is inaccessible. Odd. Something different in XP Professional perhaps? Any ideas please? Regards, Pete
  8. Hi again Stuart, Well, I found a way of ennumerating all the Processes (using ToolHelp), and having found the EXPLORER process, obtaining its Process Handle and using this to Terminate it before trying to shut down forcibly, and ... ... it made no difference! So much for Microsoft knowing their own programming! Sorry, I can't find any way at all of actually shutting down a Win98/Me system from a program. If any other readers know how to do this, please let me know. Meanwhile I'm afraid I'll just have to change the WideFS documentation to say that the shut down option can only be used to shut down the PC on Win2K or XP. Regards, Pete
  9. Go to the Flight Simulator Options-Controls-Assignments and simply reassign the axis to the spoiler -- you'll find it near the end of the Joystick Axes list. FSUIPC cannot see the spoilers axis changing because it isn't assigned by default. Once you've assigned it then FSUIPC should be able to see it. FSUIPC does NOT read any joysticks itself, it is only manipulating controls inside FS. Regards, Pete
  10. The second comment simply means that it is by-passing NT/2K/XP-only code which I found I had to add to make it work at all on those operating systems. That code isn't even valid on win98. All the shutdown code is doing, and this is immediately after the message above, is calling ExitWindowsEx(EWX_POWEROFF, 0); According to the Microsoft MSDN reference this does the following: "EWX_POWEROFF Shuts down the system and turns off the power. The system must support the power-off feature. Windows NT/2000: The calling process must have the SE_SHUTDOWN_NAME privilege." HOWEVER, I have just found another note in the same source, one I'd not seen before: "Windows 95/98: Because of the design of the shell, calling ExitWindowsEx with EWX_FORCE fails to completely log off the user (the system terminates the applications and displays the Enter Windows Password dialog box, however, the user's desktop remains.) To log off the user forcibly, terminate the Explorer process before calling ExitWindowsEx with EWX_LOGOFF and EWX_FORCE." Now I'd not noticed this before because I am not using "EWX_FORCE" -- it warns me specifically NOT to use this by the statement "This can cause the applications to lose data. Therefore, you should only use this flag in an emergency." So, I'm in a bit of a quandary. Seems I need to somehow terminate the Explorer processI'm not sure how to do that. I'll see if I can fit time in to experiment. Regards, Pete
  11. Can you tell me how to do that? The parameters in the PFD.INI totally confuse me I'm afraid. These are the only relevant ones I can find. What should I do with them? Quality=Lo PolySmooth=Off SmoothLineWidth=1 PolyDither=Off BitmapSmooth=Off FontFactor=1 NavFontFactor=1 FontQuality=0 What's the best things to set here? Bear in mind I am running this on an Athlon 700MHz. Three copies of PFD.EXE are running simultaneously, each with a graphics frame rate of 33. WideClient tends to keep to the FS frame rate with no problem, but I am getting some jerky behaviour on ONE of the PFD displays at a time -- I think there are problems with them all trying to get WideClient's attention at the same time. I'm working on optimising just the WideClient timeslicing at present, I'm sure I can sort it with some small timing changes. The service from WideServer is not at all jerky and only one of three PFD instances act jerkily at a time. Whilst I have your attention, could you help with another matter entirely, please? In order to run the Parhelia I have had to upgrade from Win98SE to WinXP Home -- Matrox don't provide Parhelia drivers for Win98. But now I cannot access files/folders on that PC on my Network. I don't understand what is going on. I've been through all the File Sharing stuff on it. I thought XP would operate the LAN okay -- the other two copies of XP I have running are fine and I cannot see any difference in any of the settings. It took me all day yesterday and I got no where. WideFs is okay, it's just the file sharing. Thanks, Pete
  12. Sorry, there is no setting nor facility in FSUIPC to lie about your position to anything. FSUIPC does not touch, interfere with or otherwise mutilate positional information. It only provides a window to where FS deposits it. It sounds like something is going wrong on the Squawkbox or Multiplayer side of things -- in fact doesn't SB deliver MP data through the Internet, not data read from FSUIPC? Multiplayer is nothing to do with FSUIPC and vice versa. Maybe in transferring things over you got Squawkbox using an older MP protocol (I believe it changed in FS2002?). Regards, Pete
  13. They're respectable enough -- not as fast as the nVidia Ti 4600 I was using before, but then with that I only had a resolution of 1280 x 1024. P4 2.4GHz with 512Mb memory. I've just acquired a 256Mb version, which I've used to replace the 128Mb version, and it is now driving 3 18" TFTs. I'm preparing for FS9 which will support the 3840 x 1024 resolution I can now handle! I've moved the older 128Mb Parhelia to another PC where it is driving the three small 15" TFTs, with separate Project Magenta instrument panels on each. This is possible with the Parhelia -- it is the first consumer card to support multiple accelerated OpenGL windows. By doing this I've freed up two old delapidated PCs which were helping (poorly) with the PM instruments. Yes, you could say I'm happy with the card. One day soon I shall be happy with the drivers too! Regards, Pete
  14. You've got some really weird serious problem there. I've never seen Winsock respond like that. Maybe you have a corrupted copy of WideFS? If not I can only suggest going into the Device Manager, deleting your Network Adapter cards, and letting Windows re-install everything from scratch. There really isn't anything in WideFS to go wrong. It is simple code, copied direct from Microsoft examples, and has been working now for nearly 6 years. In all that time I have never once seen this error response. Sorry I cannot be of much help. I really don't know that much about Networks, so I always re-install when I get a problem, and if that doesn't work I go get a new Network card. Regards, Pete
  15. I've not programmed any support for a PIC757. In fact I didn't even know there was one. Can you clarify? If you check my documentation, and the labelling on thebuttons in the PFC options, it all deals only with the PIC767. If you really mean the Wilco PIC767, then I would have difficulty now checking this again as I don't have it installed. Ever since the developers were very rude and refused to add programming facilities for external hardware I de-installed the panel altogether. I only re-installed it the once to hack into their 1.3 modifications to provide better A/P control. Are you saying that the 767PIC has two different heading bugs and that they can sometimes disagree with each other? Are you running Project Magenta at the same time as 767PIC? If so then PM takes precedence. I cannot control both at the same time. You need to modify 767PIC to allow PM's A/P to take over. Be aware that if you terminated PM's MCP "untidily" (for instance, if it was running on a WideClient and you terminated the client program first) then PFC.DLL will still think the PM A/P is running -- the flags telling it so won't have been cleared. [Later] I've re-installed the 767PIC cockpit to re-test, and, provided the APS.DLL is in the Modules folder, and PM is not running, the A/P controls on the PFC equipment work fine. It sounds like you have a bad installation of the 1.3 767PIC. The APS.DLL I am using is dated 20th July 2002 and is Version 1.2.4.0 according to its right-click version info. Try re-installing as I just did. Regards, Pete
  16. Okayin that case they know how to display windows on top of a full screen FS. Others can find out too. (Can they let me know how when they do, please?) But FS9maybe that's another matter. I wonder what they will do then? Regards, Pete
  17. I think you'd find the FSInterrogate display MUCH more useful and informative if you loaded the FSUIPC.FSI file I provide with it, in the SDK. This has all of the values in the tables in the Programmers Guide pre-defined so that the display becomes much more meaningful. Is is VERY disheartening to see you ignoring all this work!! Please go and do all that research again using the proper definition files provided, then come back if you still don't understand. The OMI values are used in many cockpit situations perfectly. I have them here both on the PFC avionics and on the flightLink KR-1. There is no problem with them. PLEASE go find the FSUIPC.FSI file supplied specifically for use with FSInterrogate, load it up and look again. NEVER EVER try to interpret a 16 bit value as 32-bit or Float64. you are only confusing yourself more and more! Pete
  18. I have no idea what is going on there. Certainly there is no wind change which will be synchronised with your banking. It sounds like something is seriously wrong with the aircraft modelling, but I am not an expert in that area. I've never heard of this phenomenon occurring anywhere else -- maybe others can chime in and help here. Regards, Pete
  19. Sorry, what does "down the image of scenery and cockpit ..." mean? What program are you running under Wideclient? What are you expecting to happen? As it says in the documentation, WideFS links FS Application Programs to FS across a Network link. It extends the FSUIPC interface for application programs from the FS computer across to the client computers. You still need to run the application program which use FSUIPC on the clients. WideFS cannot actually guess what you want to do and find and run the programs for you! Please re-read the documentation supplied with WideFS. I fear you have misunderstood something. You certainly don't need to tell the Server what IP address it is -- the Server does not need to connect to the Server, it is already there! How come the Server IP address has changed? There can only be one server. You can't have two with different IP addresses! Anyway, your logs show everything is working. now all you need to do is run whatever program you installed WideFS for. What image? What happens on the client depends upon what program you run there. I don't know what image you are expecting. Regards, Pete
  20. Are you getting the variables through the panels interface, as Token Variables? That is what FSLook does. The values at FSUIPC offsets 2F28 and 2F30 should be the same -- they are mapped to the same place -- but I don't know that they work. Those values are in the second table in the Programmers Guide, the one I cannot easily support. If you are writing a gauge for a panel, you need to use the gauge facilities. If you say that the mapping of the Concorde parts to those IPC offsets doesn't work in FS2002 (which is contrary to what I was told at one time), then I will have to change the "Ok" column for FS2002 to "No". I really still don't know what you are doing. for FS gauges you should be able to get all you need from the gauges interface to PANELS.DLL. Are you using FSUIPC interface from a gauge? If so, why? Pete
  21. What 32 bit and Float64 parameters? The Marker values in the IPC interface are as documented, 16-bit (short or WORD) values at 0BAC, 0BAE and 0BB0, respectively. In fact you only need read one byte (8 bits) for each, at 0BAC, 0BAE and 0BB0, as it is that which will be non-zero for "true". It sounds as if you are misinterpreting the FSInterrogate display completely. Please check the documentation and use the appropriate columns for the different values. You are making it MUCH more cdomplicated that it really is. Effectively only one bit will be changing, forget all that 32-bit and Floating point nonsense. It isn't applicable. If yur FSInterrogate display is showing these columns then you are not loading the FSUIPC FSI file into it to define the vlaues correctly. Regards, Pete
  22. Not 3 3D views. It is is one 3D view at 0.50 (some prefer 0.30) zoom, spread across three monitors as 1920 x 480. In CFS3 and the forthcoming FS9 the resolution will be able to be increased, but FS2002 is limited to 2048 max in any dimension because it uses DX7 which had that limitation. Such a low resolution is no good for FS panels, but I don't use any FS panels -- I am, today, fitting a Parhelia to a second PC to allow me to have three monitors showing Project Magenta instrumentation (currently on two monitors on separate PCs. Scenery is actually pretty good in any case at the low resolution, and the view across three monitor widths is very impressive. The Parhelia drivers still have problems. I don't get any hangs now with either the 042 or 043 build drivers, but there are some artefacts and flashing and lost textures with either version. I know Matrox are aware of these problems and I expect improved drivers to arrive in due course. I also expect FS9, when it arrives, to have less of a problem in all these areas --- some of the problems are undoubtedly due to the DX7 use in FS2002. I also use the display with Grand Prix 4 and that runs fine in 3072 x 768 resolution and is spectacular. I will be trying it in 3840 x 1024 resolution when I upgrade to 18" TFT screens (currently using 15"). Regards, Pete
  23. I've not looked at any variety of Direct3D. I don't know if you can actually "share" full screen mode with some other process or thread. I know you can with DirectSound, but that wasn't easy either (Esound actually uses DirectSound). Maybe there's a way -- but it is certainly something I won't have time to look at till I've sorted all the main things out. If you do find a way, please keep us informed! Regards, Pete
  24. I'm afraid I can't help with Visual Basic, but I can say that you should be checking your results with FSInterrogate, to see how long the Inner Marker is actually flagged as being received. I've found that such signals tend to be very short-lived indeed. To start with there aren't actually many runways equipped with them these days, and secondly they are usually almost on or very near the runway threshold. By then you are so low that the passage through the "cone" of radio reception is very short indeed. Maybe you have nothing wrong -- certainly if your code is working for the other Markers, it seems unlikely to be broken in this one instance. Regards, 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.