Pete Dowson

That's where I mean, yes. Ouch! Is that checkmark BLACK or GREY? If the check mark is GREY I think it simply means that probably at least one file in the folder or its subfolders is or may be read-only, or something like that. It may even mean "leave this attribute to individual cases", whereas no check means all read/write and a solid black check means all read-only. If it is BLACK, then Yes!!! That would stop everything writing to that folder! It isn't anything to do with sharing -- it would stop things writing there on the same PC too! Regards Pete

It really isn't in English or French, but in Maths. Maths is pretty much the same in any language. Just read the two values into _int64 variables, then copy them to doubles (the conversion to floating point will be done by the compiler) and then simply multiply and divide as shown. It isn't at all complicated, there are only multiplications (*) and divisions (/) involved! Regards, Pete

The name after the \\\ part is the SHARE name you gave it in Windows explorer when you told Windows you wanted to share it. By default, for Drives, Windows offers the drive letter (sometimes the drive name), but not for folders. Either way, you should know its name as you chose it. It should be unique on that PC -- I doubt that windows would allow anything not unique. Be sure you also gave permission to all to both read AND write files on that share. I noticed in the update (SU1), which I just installed and tried, that it wanted my Application Data folder sharing too -- which I've done as "AppData". Maybe it wanted that last time, but the mess with my partial FS installation (now all cleaned up) on the Client got it diverted. Regards, Pete

I've done this now. It's in FSUIPC 3.522. Please see the interim versions announcement at the top of the Forum. Regards, Pete

I've done this now, in 3.522. Please check the Interim Versions announcement at the top of this Forum. Regards, Pete

I don't know whether it will help or not, but I've just been informed that there's a Service Update for ASv6 available now. See the sales.hifisim.com site. Pete

There's also an ini which needs the path in the graphics folder. Pete

From a program, via the FSUIPC interface, all the details you need are in the FSUIPC SDK. Download that from http://www.schiratti.com/dowson. Distance convered from one place to another, you mean, or the whole squiggly route of a meandering aircraft? Obviously place-to-place distances have to be computed by normal spherical trigonometry given the two lat/long pairs. For the actual distance along a random route I can only think that you have to measure it from turn to turn, continuously, and sum it yourself. Regards, Pete

I installed it yesterday. It looks a lot like ASVE and ASV before it, which I've been using since they appeared. No, of course not. File access is a Windows thing. WideFS has no such powers over Windows. Why should it, even if it could? Did you edit its INI files as the install notes mention? It seems easy enough to get the weather part working, but I had more problems with the grahics part which wanted to backup my cloud textures. Seems you also have to enter the correct network path for the Graphics thing -- I edited its INI file too, but it still needed me to change it in its dialogue. Seems okay now. It's a bit of hassle during installation and first start up, I agree. It wasn't helped in my case by my having remnants of an FS installation on the same client as AS6. Can you see them, in Windows explorer? If the Explorer can, then anything else should (unless possibly you have firewalls excluding specific programs -- but I don't think they operate on simply file access, do they?). To make paths easier I always share my FS9 path explicitly on the FS PC, with a short share name. So, for instance, the path to my FS9 looks like \\fspc\fs9 This make it much easier to enter (and check) than using the horrible default FS install path. Regards Pete

Search? Oh, you mean heresorry, I think I already pointed out the ways it was solved -- one time a different video driver, others changing settings. I suggest you try different settings. Right click on your windows desktop, select properties, settings, and see if you can reduce the anitaliasing setting from 8x to something less. I think that was one of the fixes. One of the ohers was getting a slightly older nVidia driver -- I've noticed quite a few problems (not just with AdvDisp mind) with the more recent ones. I tend to keep a few steps behind with those as they often add more problems than they solve. Regards, Pete

The video card or its drivers are not coping. Advdisplay's window is just that, a standard Windows window. It has no relationship with anything else in FS or elsewhere. It doesn't even use anything complicated like DirectX or 3D acceleration. It is just a bog-standard window. But your vide settings are somehow precluding having such a simple operation in the middle of something very complex. Try changing some of the video driver settings -- if you look though this Forum you will find others who had similar problems (and not just with AdvDisp, but other games than FS too) solved them either with different versions of the drivers, or with changes to things like anti-aliasing settings and so on. Regards, Pete

It will do if you enter everything correctly: name, email and Key, EXACTLY as originally notified to you. It sounds like you are making an error in at least one of those places. Please, next time, make a safe copy of your FSUIPC.KEY file, as instructed in the documentation. There is never a reason to re-register just because of FS re-installation, only on a Windows re-install or moving to another PC. Regards, Pete

If you don't use FSUIPC joystick facilities, then FSUIPC isn't touching any of the things relating to throttle or autothrottle. It just leaves everything alone. I'm not at all sure what you mean by "lost my autothrottle", but I think you will need to ask PMDG to look into this for you. Regards, Pete

Open when your program starts, Close when it ends. It is really really really inefficient to open/close all the time. It is using memory mapped files and atoms. Each time you open Windows is asked to supply unique atom numbers for uniques strings and to open a file in memory. Each time you close, those things are closed and freed. Think of Opening and Closing files on disk. If you wanted to read/write a single data file a lot of times, you wouldn't dream of opening it and closing it every time, would you? This is why the terms "Open" and "Close" are used. They are just as heavy. The Reads/Writes are merely data shuffling in your own program, very very light on processor and resources. You pile as many reads and writes together as you need and as will fit into the memory file size (no bigger than a total of 30k though). The Process call is a Message being sent from your program to the FS process. This needs a process switch to FS, then, when the response comes back, a process switch back to your program. So this is a lot heavier than Read/Write calls, but nothing like Open/Close. As far as FSUIPC is concerned (and Windows and C/C++ for that matter), a Boolean is an integer -- a non-zero integer is TRUE and a zero one is FALSE. The BOOLEAN type is only there to look pretty and to make code more understandable. Hmmm. Doesn't make sense to me. My questions: 1. Is the order switched around in this VB>NET interface? It is most confusing. The original C/C++ interface was defined with: extern BOOL FSUIPC_Read(DWORD dwOffset, DWORD dwSize, void *pDest, DWORD *pdwResult); extern BOOL FSUIPC_Write(DWORD dwOffset, DWORD dwSize, void *pSrce, DWORD *pdwResult); where you will see that the 2nd parameter is the SIZE of the read/write (in bytes). You have 1 or 0 there instead of the length? 2. I still don't understand this "token" thing, which you define as 0. What is that for? 3. You define the size for the writes as 2 but don't use it anywhere (doesn't the VB compiler tell you about unused variables?). How do the Read/Write routines (which are in YOUR code, they are part of what YOU can see and deal with!) know how many bytes to use? As an example of what the C version would look like here: FSUIPC_Write(0x0262, 2, PauseGame, &dwResult); That's it. You wouldn't even really need a function/procedure for that! Your version is complicated and, to me, very confusing. I don't know VB or VB.NET, but surely you do need to give the size someplace? I doubt if it is doing anything much. What does the FSUIPC Log say? Surely you ARE using the Log to check these things? Just enable IPC read/write logging. Regards, Pete

Okay. i am using that version, and it works okay too with FSUIPC unregistered. At least, it does here. Looking at the log, however, it is most definitely not registering itself at all with its given Key. The PMDGoptions DLL is, here: Now I don't understand why it works fine here and not there. Possibly AISmooth is multithreaded and for some reason one of its threads is running ahead of the other, I don't know. And I'm not really in a position to find out why -- only the programmer can determine what he is doing wrong here, I'm afraid, as it needs a knowledge of the source code. Here's exactly the same version (1.12) registering itself on an unregistered install of FSUIPC here: You'll see that its sequence of Reads are the same as in yours, but it has not attempted to register itself at all (the part that does that in my log is 110156 WRITE0 [P2640] 8001, 12 bytes: 4F 5A 38 4B 30 37 46 51 46 42 5A 4A Sorry, but you will need to seek support from the author. He should be able to work out what is happening with his program on your PC. If you want to try manually registering it, in FSUIPC's "About" page, just enter the program name (AISmooth) and the Key (OZ8K 07FQ FBZJ), which is actually shown in my Log extract above in its hex ASCII format. Even if you do this, I think you should report it, with all the data we have here, to the author. Regards Pete

It is certainly logged as AISmooth -- the ID (3608) is the clue. What version are you using? I have 1.001 through to 1.12 and they all register themselves okay. Maybe you are using a very early version? If not, please enable IPC Read and Write logging, in the FSUIPC Logging page, and try again. Don't keep FS running after the error. Close it down then show me the whole log. Regards, Pete

Okay. Not sure what you mean by "scrolles through f switches (what are they?), but if there's nothing recognisable appearing at all there's one of the following things wrong: 1. the PFC device you have is not one of the devices PFC.DLL controls, but an older (probably non-digital) version. You must have had a completely different driver for it -- certainly not one of mine, or 2. it is a correct device but it is switched to the wrong mode -- possibly Elite mode. Remove the quadrant and look for the switch. If it isn't there it may be permanently set for Elite, not for FS. 3. it is the correct device in the correct mode but there is something wrong. Maybe it is set to run at a different speed to all their other devices, or maybe you have a faulty or incorrect COM cable or a faulty COM port. Or maybe the unit itself has an fault. For most of these possibilities you need PFC support. No, none of that is at all related to anything FSUIPC does. Regards Pete

I'm sorry, I don't know this "iFly747" -- in fact I'd failed to notice that you meant a non-default aircraft when I replied to the last message, otherwise I may have said some different things. If I were you I'd set up your throttles etc to work perfectly with the default 747. Otherwise you really don't know whether you are doing the right thing or not. When it is all working well with the default, try the add-on. If there are then problems, you know who to ask -- the iFly folks. Okay? One thing they may do is use the older FS98 axis controls to set the engine thrust rather than control it directly. If they do then you will probably have to check that option at the bottom of the 4-throttles calibration page in FSUIPC. That stops FSUIPC calibrating the older axis controls. Regards, Pete

The lever positons are controlled by the A/T when the A/T is armed and a thrust mode is set. Possibly you are getting interference from the levers, preventing the A/T taking full control? When you move Thrust lever #1 with A/T enabled, does the engine spool up and down with it? If not then you have something else going on with that aircraft. If it does then your original problem is probably that the levers are giving too much jitter. If the filtering in FSUIPC doesn't help, then all you can do is make sure that you "park" the levers when using A/T -- non-jittery positions can be established atound the idle position and at the full max thrust position, provided you have calibrated the levers with some leeway allowed for variations. When I used a throttle quadrant with jitter problems I used to park them at max thrust when on A/T in climb phases of flight, and at idle when on cruise or descent. The other thing to do is check that you don't have any other (maybe all-engine) throttle axes still assigned in the FS Options-Controls-Assignments dialogue. If it is a throttle interference problem and you can't resolve it, there is a special FSUIPC-added facility to disconnect throttle levers, three controls in fact -- "Throttles off", "Throttles on" and "Throttles toggle". You could program a button or keypress for this in FSUIPC -- these controls will be found in the drop-down. Regards, Pete

View changes? Mags cut? On quadrant axes? Phew -- the codes coming from your quadrant must be really screwed up. What does the TEST page in the options show? Are codes from anything seen correctly? The test page says the yoke and rudders are working (which simply means it has seen correct signals which may or may not be from them). Are they working, in FS, in the flight controls option screen? You say "I recently changed my Pc and went over entirely to Fs9 (my old Pc having Fs8 and Fs9). Im running XP pro and a 3 gig system. Ive downloaded the latest drivers for my PFC digital console from both shiratti and PFC" ... ... which implies you had things working before. With what drivers? You haven't actually said what PFC equipment you have, by the way, nor how the bits are connected, so I'm not sure what to tell you to check, but it is sounding as if you do really need help from PFC. However, it would help to know what you've changed, i.e. what you were using before. Merely changing PCs isn't going to break external hardware. Er .. so the driver still sees the yoke and rudder WITHOUT the correct COM port set? That's very difficult to believe. It isn't going to be able to read them at all with the wrong or no connection!? Regards Pete

Is the aircraft on the ground? With most of the FS2004 aircraft, if you move the spoiler lever through the "Arm" position (a little away from "down"), FS automatically deploys ground spoilers (100%) just as it wouls on touch-down. Always test the spoiler axis off the ground. Meanwhile you should be able to retract them with the keyboard shortcut for it (is it / ? Something to do with that key). Regards, Pete

Even that sounds rather high for just those types of applications. I have nine PCs on my cockpit network running around 20-24 FSUIPC/WideFS applications, with the main ones being all the real-time instrument and control with Project Magenta. There you are talking at least 10 times your rate as an overall session average, with peaks a lot busier. That's the problem with capacilty really. It's a bit like what happens in water pipes, or on motorways/freeways. The overall capcilty needs to be a lot more than the average usage, otherwise you get queueing and bottlenecks. even those wouldn't matter for most applications, but they do when your main flight instrumentation and autopilot control is routed through a jam! ;-) BTW if you are using FSUIPC 3.52 (as you should be), trying reducing the AISmooth delay from the average default 50 mSecs to zero. If was only non-zero originially because of FSUIPC's limited queueing mechanism for AI control -- in 3.52 it's direct so there are no queues to overfill. Regards Pete

This happens when using a VERY OLD version of FSUIPC (16 months old or more), which was made for FS2004 long before the FS2004 (9.1) update came out. Microsoft's own READ.ME for the update does point this out. All versions of FSUIPC provided since September 2004 work fine with the FS2004 update. You don't "OPEN" a DLL. Who told you to do that? The DLL comes out of a ZIP file, and you simply put it into the FS Modules folder. It is extremely easy to install FSUIPC. When you downloaded the FSUIPC.ZIP file, and opened that, did you not see the documentation, the User guide? Please PLEASE look at the documentation. You don't need to read all of it, but the one step you need to take is documented under the heading Installation! Regards, Pete

You cannot have more than one FS9 running at one time. Everything will go wrong. This is why FSUIPC detects it. There are very very few add-ons which crash FS in such a way. Just don't use them, or find the update for them which fixes it. Just downloading something for FS will rarely if ever cause such crashes. It will be one bad Gauge or add-in -- the original version of ActiveCamera for FS2004 did this, for instance, but it was fixed pretty quickly. If you can't find what it doing it or get a fix, your only recourse is to use CTR_ALT_DEL after closing FS and terminating the FS9.EXE process, if it is listed. If it is not listed you will not get the problem you describe from this cause. If this happens when there is no "FS9.EXE" process running, then it is literally true -- you have multiple copies installed and being loaded by FS. This can only happen if you have a renamed FSUIPC.DLL in the FS Modules folder (NEVER do that), or, some say, if you have an FSUIPC.DLL (by any name) in the main FS folder. Regards, Pete

The switches in FS's cockpit will be set the way you saved them -- they are saved in the FLT file. All you need to do is to use all your switches to preset them the way you wish, then save a flight. When you reload that flight, they will be set that way. You now just have to be sure NOT to change your mechanical switches when FS isn't running. The initial button facility is nothing to do with specific FS controls nor is it anything to do with being "on" or "off". It is merely a way of you telling FSUIPC to PRESS the nominated button at the beginning of the session. This is the same as YOU pressing the same button. It has to be a button you have programmed to do whatever it is you want to do. So, if you don't want to program one of your own buttons to do this, you have to define it using a button number you don't have. However, this still won't help you with a control such as 66494 "TOGGLE ..." because that will switch it on if it was off, but off if it was on -- the end result would STILL depend upon what state it was in FS when you loaded the flight. The only sane way to initialise cockpits is by using saved flights which have everything set as you want them. For example, I always start cold and dark, so ALL my saved flights have everything off. All I need to do is to make sure all my cockpit switches are off too, ready to start FS. Regards, Pete