Pete Dowson

It is Dowson, actually, but please call me Pete. Sorry, but I'm not really sure what you are asking me. As far as I can see it must be one of two things: If your software works with FS2002 and not with FS2004 using a registered version of FSUIPC, then perhaps it needs some values out of FS which I've not yet found. You will need to make a list of those you need and I will try to find these for you. It is the only way really that I can continue to extend coverage for FS2004, there are simply too many values for me to check them all myself very quickly. If all you are asking is for us to reach agreement for your program to become accredited, for access to an unregistered FSUIPC installation, please write to me at petedowson@btconnect.com and I will send you details of the Registration scheme. This will be included in the update to the SDK, but I'm running a bit late with that I'm afraid. Regards, Pete

I don't know how arrestor cables works in the first place, so I have no idea why it doesn't in FS2004. If you ask the author to get in touch with me I'm sure it can be sorted out. It may just be that it needs to access values in FS2004 which have not yet been located. In the worst case it may depend on things that cannot be done in FS2004, but let's hope not. Pete

Not working with a registered copy of FSUIPC? If you are talking about an unregistered copy, then I'm not surprised. I've never heard of any of those and no one has asked me for any keys for them. Regards, Pete

I have added the recognition of the AXIS_FLAPS_SET control to FSUIPC version 3.03, being released at present. But it was not just a matter of recognising the new control. It seems that the range of vlues changed from FS2002 as well. In FS2002 and before, the FLAPS_SET control provided a value from 0 to 16384 to set flaps from zero to full. In FS2004 both the old FLAPS_SET control and the new AXIS_FLAPS_SET run from -16384 to +16384. I've dealt with this by secondary scaling within FSUIPC, so it does work well now, but it wasn't as straight-forward as I thought! Regards, Pete

Ah, I don't know about the receipt you get by email, but right at the top of both the FSUIPC and WIDEFS order pages, in the table with all the details, and right against thw word "DELIVERY", it has the following words: Never mind, glad you are sorted now. Regards, Pete

I did actually use WidevieW for a while, it was before FS2000 though. I remember this because WidevieW was the inspiration for my WideFS, and in fact the very first version of WideFS, over 6 years ago, rode on the back of WidevieW, using its communications over the internet to hold its own messages. However, I have not used WidevieW for some years now. I know Luciano did a "Light" version for FS2000, and ported it to FS2002, but I have not heard from him for a while and I do not know if he is making an FS2004 version. The dependence on FSUIPC within WidevieW is only for the weather, I think. His application is only one of two I know of which uses the Advanced Weather Interface I added for FS2000 and carried on thereafter. For all the other things he has to pass on from one PC to the other, Luciano did his own thing. I am pretty sure that it was not FSUIPC dependent for anything other than weather. So it will certainly need some work for FS9 I'm afraid. I use three monitors connected to a Matrox Parhelia. That is the only video card I know of that can do this at present. In full screen FS2002 will run at 1920 x 480 across the three screens, but FS2004 reaches a splendid 3840 x 1024, or more if you have bigger screens. Naturally the frame rates take a bit of a knock at such resolutions, but it is worth it. I aim to upgrade my processor when I can, soon I hope. Thank you. But I am not quite in the position of being able to update other folks' programs for them. Have you contacted Luciano to ask his plans? Didn't he have a web-site, and if so is it still operational? Sorry I cannot be of any direct help. If Luciano wants help in adapting WidevieW to FS2004 I would be ready. Regards, Pete

Well that is REALLY weird. I do hope you get to the bottom of it. Please keep us posted, I am very curious. Regards, Pete

No, no! That isn't true. They make the keys for me. The keys are then send by email. But, strangely, like me, the folks at SimMarket are actually human too. They take breaks and probably have other things to do. They offer 24 hour turn-a-round but it is usually faster. If I was in the loop I would have to take much longer than that, or get nothing else done. I don't know why folks expect things to be instant. They do say allow 24 hours. Pete

They send them within 24 hours. Has it been 24 hours? If so you have to write to them. Pete

Hey, don't be sorry! Your question was okay, and I tried to help. But there will be more knowledgeable folks on Project Magenta matters in the Project Magenta area I think. I just want you to get the best answers. Meanwhile, I did just check the PM FSUIPC details and it does say the bits in 5414 are to be toggled, so this is probably your main problem. Okay? Regards, Pete

But why not get a free access key for it and be done? Then it is accredited. But if it is the first such application to fail in this session, a Message Box should appear from FSUIPC, and a log entry will be made every time. This is how it is anyway from FSUIPC 3.02 on. Please note that when run under WideFS on a remote PC, it is always accredited in any case, but FSUIPC may not be indicating this to you as it is WideServer which is then accredited. You can tell if it is WideFS or FSUIPC if you are using the FSUIPC access library in the SDK. I've looked at using 330C for a maerker. It is already used internally for some flags, but 2^1 bit is free. I may use that. Regards, Pete

Yes, but by then your access will already be noted as failed. I'm not sure what application there is for this, but it is easy enough to provide a way. Is it that you don't want to use an access key? Is this for freeware or something commercial? Well, I'd rather not use that as this indicates that the FSUIPC version and the FS versions are valid, which they are and can be read legitimately. I'll probably just use the following word or byte (330C), so that the block 3304-330D can be read without problem and the word at 330C is zero if access elsewhere will fail, non-zero otherwise. If this is read before sending the Key on an non-registered FSUIPC then it should be zero, if it is read after sending a good key then it will be non-zero. Leave it with me. But I'd still be interested in the application for this. What is it? You aren't trying to derive the algorithm for key formulation this way, are you? with 36^12 combinations to get through it'll take nearly forever I reckon. Anyway I shall probably not accept more than 3 attempts from the same process. . Pete

Are you using the documentation from the Magenta site? Doesn't it say that the bits in the MCP control (5414) operate by TOGGLING? This means the MCP has to see them change. You have to read the word, change the bits you want, then write it back. I think for good help with interfacing to PM you will be better off in the Project Magenta newsgroup, as the data is dealt with by PM code, not by any of mine. FSUIPC is just the postman. Regards, Pete

Probably there's a small difference in your name or email spelling. They have to be exactly the same. Send me details of both to petedowson@btconnect.com and I'll a new key for you. Pete

Do you mean checking it from inside the application? At present, you could only do that by reading a location which you know should always be non-zero, and seeing if you get zero back. However, that attempt could provoke FSUIPC into displaying a Message Box, and it will certainly log it. If you would like to have a safe place to read which is legitimate but which is pre-set in FSUIPC to be non-zero for "OK" and zero for "No access", then I think I can add that easily enough. Let me know today, I'll see about slipping it into this next version. Pete

Not off-hand. certainly the spoilers should be the same. It doesn't look like that axis code has changed. I'll need to work out what is going wrong. Maybe there are new codes which I need to list for you. No logs at present, but can you Zip up the FS9.CFG file and send it please? You'll find this (in Windows XP) in someplace like: Documents and Settings\\Application Data\Microsoft\fs9 I'll try some assignments here, later, but I'm a bit tied up at present so your CFG may be useful. Not at present. I've changed FSUIPC so that it will see the new Flaps Axis in any case, this'll be in the next version -- later today or possibly tomorrow. Regards, Pete

FSUIPC has never dealt properly with "localised" weather -- which in the past meant FS downloaded weather, but now includes the themes too. The problem is that there are hundreds of separate weather stations, and FS interpolates between them. Whatever FSUIPC does to interfere in that just results in unpredictability and possibly nasty failures. Most all the weather features in FSUIPC have always been related to weather injected externally, by add-on weather programs using its interfaces. Some of the facilities have also been applied to "global" weather, and this is still true. However, whilst this may appear to result in *less* facilities from FSUIPC, in fact I've managed to make much better use of the completely re-vamped FS weather engine. The "New Weather Interface" allows external programs to read the weather at any weather station in the world, no matter how it was set, and also to write weather for each weather station. The NWI opens up new opportunities for improved weather programs, and you'll be seeing these appear quite soon, I hope. Try reding local weather stations using WeatherSet2, included in the ZIP. Also countering the argument about less facilities, I would strongly argue that the weather engine is so good in FS2004 that mostly the FSUIPC manipulations are either not needed or really could simply ruin the realism you would otherwise get. There are no taxi-wind facilities for FS2004 for the reasons I give above. I think you'll find there's no need. the ground friction is better and the aircraft don't weather-vane unrealistically now. Regards, Pete

Okay, I found the problem. It seems that FSUIPC version 3 is not enabling the weather interface reliably on FS2002. I'm fixing it now. I'll try to get a revised version up some time tomorrow (Wednesday). Many apologies. Regards, Pete

There is no way this can be due to FSUIPC, UNLESS you have configured individual throttles in FSUIPC's joysticks section. Just close FS down, edit the FSUIPC.INI file and delete the entire [JoystickCalibration] section, if there is one. If there isn't one, then it isn't FSUIPC doing this. Most likely you've got FS into a selected engine state. You can select which engines you control by keystrokes: E then 1 2 3 4 (the numbers on the main keyboard), just press the numbers you want to select. Regards, Pete

Ouch! Big ouch! There is something really wrong there! I would first suspect video drivers, then sound. See if upgrading (or even downgrading) video drivers helps. Pete

LOL, registration is 3 days old, so it wouldn't have played any part in that year in any case! Which version of FSMeteo is it please? I seem to have a few here. I try to check it out with the same one as you. Also, can you just do a short run with FSUIPC logging IPC reads and writes. Just run it till you know it isn't going to do anything, then Zip up the FSUIPC Log and send it to me at petedowson@btconnect.com. Please also report it to Marc and send him the log too. Marc has been involved in the Beta testing and hasn't mentioned any similar problems. I'll probably need him to look at it in any case and tell me why it is not running. I do already have a few good reports of it working fine, both on FS2002 and FS2004 so I can't imagine what the glitch could be without more data, sorry. Regards, Pete

That's both the same then, the only differences betwee FSUIPC 3.01 and 3.00 are in the Registration. So it is indicating a problem with PFC, or possibly only with the COM port when FS2004 is running. How weird. I measure absolutely no difference here with PFC installed or removed. It is sounding more and more like some sort of resource problem associated with the COM port. Why it should affect FS2004 and not FS2002 I don't know. But, wait, we don't KNOW that it isn't affecting FS2002, do we? Try this, just to check. Change FS2002's frame rate limit to, say 40. Check the achieved fps in a known situation. Now close it, remove PFC.DLL and load it again. Re-check the fps. Any difference? If there's no difference in FS2002 then I'm a bit at a loss I'm afraid. I can't think of anything in FS2004 which should be interfering with the PFC operations. There has certainly been lots of testing on FS2004 and PFC equipment -- apart from my own system there are quite a few in the FS Beta group. One thing to check, anyway, as a matter of course -- make sure the COM port IRQ isn't shared with anything else. Oh, and try another COM port if you have one. I'm not surprised. PFC 1.55 = PFC 1.55 and the difference in FSUIPC 3.00 and 3.01 doesn't matter once you've registered. Didn't you copy the FSUIPC.INI and PFC.INI files over from FS2002, as I suggested? At least it would save you re-calibrating everything. Sounds definitely like some sort of COM port screw up, though I've never heard of one so bad before. If you have everything full on, FS2004 is bound to be much slower than FS2002. There's a lot more in it. The clouds especialy take a toll, but there 3000% better. The autogen is more varied and denser. You can easily get comparable rates to FS2002, but you have to make compromises. It is always like this on each new version. Regards, Pete

Actually, that's not quite true. I do the freebie ones for those who donated enough. That's been enough to inundate me. I'd never make a good shop keeper! But the folks at SimMarket are human as well, and they cannot operate 24 hours a day. I think they do guarantee turn-round within 24 hours, so the time to complain is after 24 hours -- there's an email address there to deal with that I believe. Regards, Pete

I know, you emailed me too. I tested it, and you are correct, the WideFS key was bad for some reason. I notice that you applied for a WideFS key and an FSUIPC key separately, rather than jointly with the special offer. Did you perhaps use a slightly different spelling of your name or email address? If so, then this will be the reason. FSUIPC and WIDEFS use the one name and address for both Keys. Pete

Have you registered FSUIPC? Pete