Pete Dowson

If you still have your FSUIPC.KEY file (the one my document advises you to save a safe copy of) then you can find all your details there. If you still have any Log files from FSUIPC, then your name and email will be at the start of the Log as well. If you've not got any of that, then it will be difficult. Have you really forgotten your own name and email address, or at least those you were using when you got the registrations? If you bought the keys at SimMarket, then I would normally say go to http://www.simmarket.com, log into your account and retrieve the keys, but you have those already and I suspect you can't get into your account without knowing the name and (probably) email address. So I think you are stuck, sorry. You can ask SimMarket's Customer Services, but really I don't think anyone can help anyone with unknown name and address, and without those you cannot even prove your purchase. How did you manage to get into such a situation? (It's a first!). Regards, Pete

Stutters are NOT the same thing as low frame rates. A stutter is a short change in frame rates, or even a slight stoppage, a "jerk". Stutters are much more likely at high frame rates than low ones, because a momentary 30 fps or worse a short stoppage, when things are running at 60, is so much more noticeable. At lower frame rates FS is more likely to keep up, and when stutters do occur they are less noticeable because the contrast is less. In fact the whole point of limiting the frame rate as I do is to achieve smooth, consistent, non-stuttery performance despite enormous variations in the amount of work FS has to do in different circumstances. Renaming in the process I hope. Or, for a one-off exercise, just include the code in your project instead of linking in a library. Sorry, I don't think I understand the question. If you mean what I supposed WidevieW was doing -- i.e. read/writing data at intervals leading to the 32 IPX blocks per second -- then the interval it chooses is no doubt determined by it. Maybe there's a parameter for it? I expect he could try to send stuff every single millisecond, but I doubt that you could achieve your 60 fps then as nothing else would get much done -- or his performance would be anything but smooth as it tried to achieve 1000 fps and failed. Regards, Pete

30 fps, 60 fps? I have FS2004 running on a 3.2Gb P4 and my FS frame rate limiter is set to 20! Unless you are flying helos, I don't see the point of 60 fps -- the system is smoother with everything maxed out and a lower limit set. Maybe that's the timing loop in WidevieW? Well, mainly Microsoft I suspect. I think it's the "not invented here" syndrome. Gradually less and less official stuff is supporting this old original highly efficient Novell protocol. I expect the treatment of the protocol in the Explorer is minimal and reluctant. No doubt if you tried one of the third party file transfer programs it would be faster than TCP/IP. For the program on PC2 to read "through WideFS", PC2 must be running WideClient. WideFS has at least two ends to it -- a server (WideServer) and at least one client -- WideClient. It makes no sense having WideServer running on one PC with no clients to talk to. FSUIPC contains no Network code at all, if that's what you were thinking. No. You have to get WideClient.exe running alongside FS in PC2. This is not normally possible because both want to be class "FS98MAIN" and this is the prime IPC interface class. But there is provision in WideClient for it to start up with another classname, then it is possible. You set ClassInstance=n where n is a number from 1 to 99. This goes into the [Config] section. Then WideClient starts with a class name of "FS98MAINnn" (where nn runs from 01 to 99 according to your parameter). Your interface program would have to link (via modified library code, or your own code) to WideClient via FS98MAINnn and to FSUIPC inside FS using the standard method. You can have multiple instances of WideClient this way, each linking to a different Server by different Server names and port numbers. This isn't documented for good reason -- I don't want to support it used this way. So, have fun, but please don't ask me too much! :) Regards, Pete

If you got it from SimMarket, go there. http://www.simmarket.com. If you get into your account there I think you can retrieve your keys directly. Otherwise you have to ask their Customer Services. I don't have any keys, or any data base here, except for those keys I issued for the early donors. Regards, Pete

Oh, right. I can send it again, then. No need. I've found the original email and have forwarded another copy to you. Regards, Pete

Have you tried doing it using the assumption that the FS LAT/LON/ALT are its x/y/z? In all my explorations within FS I've never come across any other internal method, only the LLA in FS units. Ah, yesbut wasn't it in FS4 that you couldn't fly from one part of the Flat Earth system, like the USA, to another, like Europe, for instance -- Europe was added on, after using the same limited coordinate system. The Lat/Lons were sort of plastered on top. Maybe I'm remembering it wrong, and that was FS3, but I don't think so (Someone will correct me I'm sure! :D ). FS5 saw quite a change in most of that stuff. I don't remember any of the original coordinate system being brought forward. Sorry, Pete

Not sure what you mean be "change from one WX station to another". If you are jumping about amongst weather stations with different weather set, then you'd expect things to change suddenly. If you mean flying between them, then it isn't the two specific weather stations controlling weather at the aircraft, but many from the neighbourhood. I don't know FSMetar. With the latest versions of FSMeteo and ActiveSky, the weather is set at surrounding weather stations, and what is being experienced at the aircraft is supposed to be interpolated between them (many more than two). This should guarantee smooth changes, and is exactly the same as what you'd get in FS's own dowloaded real weather. I've not noticed any "brutal" pressure changes with any weather source, but then I've not tried FSMetar so I don't know what it is doing. If it is feeding Global weather only to FS then certainly the pressure smoothing in FSUIPC should work, but I cannot recommend global weather in FS2004, for reasons explained in my documentation. The only real "brutal" changes I know about are the 180 degree swings in the wind direction, which is the interpolation going wrong. I'm pretty sure that's an FS bug as it can be reproduced with downloaded weather too and no add-on in sight. Oddly, the wind speed changes are quite smooth. If I were you I'd contact the author of FSMetar and see what he/she says. Regards, Pete

Except for any Button and Joystick settings, yes, I think so. I'd have to compare each page to be truly sure. If you want to simulate an unregistered copy, though, all you need to do is temporarily remove the FSUIPC.KEY file from your FS Modules folder. Regards, Pete

What cartesian coordinates? Surely the position in the world, whether in the real one or in FS, is by Latitude/Longitude/Altitude. The whole mechanics of FS's position system is based on something abbreviated to "LLAPBH" -- the six degrees of freedone, Lat, Long, Alt, Pitvh, Bank, Heading. Cartesian coordinates are only valid on a flat space and you also need to specify your origin position (in the real space being simulated) and the relative orientation of the x,y,z axes. If you have your own such reference, then the conversion from LLA is a matter of spherical trigonometry. Regards, Pete

The current version of FSUIPC is 3.14 -- as listed in the "Supported Versions" list near the top of this forum. Download the latest from http://www.schiratti.com/dowson. Regards, Pete

Ahthat makes two things, and the second more than makes up for the first! Well done! :D :lol: :D Regards, Pete

Unless you are asking FS to load or save a FLT file, or something similar, 99% or more of the time taken by the FSUIPC_Process call is occupied by two things -- the time to change processes, and the time the message is queued, in order, in the FS message queue for attention. Almost all requests, except obviously those involving FS in disk activity, are completed in FSUIPC from the time it receives the message, in well under 1 millisecond. No, the effect of multitudes of requests is miniscule, just processing in a loop. The memory is shared in any case so the amount of data isn't relevant. It may be more efficient, but I don't really think you'll measure any difference -- and certainly not if in the process you include stuff you don't want. If using WideFS from a Client PC on a Network it is really a waste of time as WideClient does that for you, automatically, before sending the request to WideServer. Of course, with Network access there's no message queing nor process switching penalty in FS, but there is the time taken by the Network exchange. No. Some requests (all weather ones, for example) are certainly synchronised with FS frames, and some others are, but mostly reads are dealt with from memory -- possibly populated on an FS frame basis, of course. None of the frame-synchronised requests hold up the return from the FSUIPC_Process call, though. Writes are a bit different, and can take a bit longer, depending on many things. Many will need a message sent by FSUIPC into FS and will await a response, though in FS2002 and FS2004 I have tried to make most of the more important ones direct calls into SIM1.DLL. Programs like Project Magenta are reading many values continuously, at reasonable FS frame rates even across a Network, and still providing external autopilot control as well, over the same mechanism. You should have no trouble whatsoever maintaining anything from 20 to 50 frames per second on the FS PC, depending on processor speed and your own program's processing requirements -- I have 4 client PCs and PM running at 20+ fps with no problems, and that includes Network overheads. Of course I set the frame rate limiter in FS to allow the Network more time. Maybe, even on the same PC, you need to use the limiter to give your program enough time? Maybe once FS gets control, from your "FSUIPC_Process", it is slow in relinquishing it? Regards, Pete

Having a name with a dot (.) in it seems a bit unusual, but if the system accepts it I suppose it should be okay -- but there is a slight possibility that something en route may not like that. Well, of course, there's no parameter "ServerName" in the Server's INI file -- it doesn't need to know the server name as it never needs to contact it, being in the Server PC itself already. :) But it won't do any harm either. FS9 doesn't (can't) run on the client. FS9 runs the Server. There is no "WideServer" on the Client side -- the Client runs WideClient, the Server runs FS with WideServer. That's why the parts are so named, of course. ErThe Server is where FS9 is running, and WideServer needs to be installed there, in FS9's modules folder. Nowhere else! Conversely, the Client is where your Client applications go and where WideClient.exe is run. You do NOT have any FS9 nor WideServer there at all. I am now completely confused by your statements. Only one PC is the Server, any number of PCs can be Clients, but none are both! You seem to have everything either the wrong way around or completely duplicated! How many FS9 installations are you talking about? Ouch! Sorry, but how do you read that FS9 goes on the Client PC and runs WideServer whilst the Client applications go on the Server PC and run WideClient? Don't the terms "Client" and "Server" mean anything here? I'm sorry, but I cannot possibly imagine how you work that out from my documents. Can you explain how, please, so I can correct them (after all these years? :( :cry: ) Thanks & Regards, Pete

Are you sure it was I and not SimMarket? Is this a user key which you paid for? If so and you have lost it, go to http://www.simmarket.com and ask Customer Services, or, easier and quicker, just log onto your account and you should find the key there. Screwed up the key for Squawkbox? That's Freeware and has a key listed in the list of Freeware Keys near the top of this Forum. If you are concerned about a paid-for FSUIPC user key, just look at the first (About) page in the FSUIPC options. It will tell you if it is a registered copy or not. No, all you do is copy the FSUIPC.DLL file into your FS modules folder. There's nothing else to do, at least until FSUIPC version 4 sometime in 2006 (perhaps :) ). Regards, Pete

Yes, I just went there and checked it. I don't know what Enrico was thinking here -- that Key definitely doesn't fit that program. It only fits the details he provided me. Oh, well, I've sent him a message to ask him to sort it out, but meanwhile, try this Key which should work with the details you've supplied: 9K03 WBCO 30JG As usual take care with the 0's (zeroes) and O's (letter Ohs). I'll add this to the Freeware list in this Forum. Regards, Pete

There's the reason for the problem -- the Key was generated for a version of the program which had Product name "pmTCAS". The one you are using has "Boeing-Type Glass Cockpit" there instead. I generated the keys at Enrico Schiratti's request, using the information he provided. Evidently the version of the program is either older than the one he intended to be used, in which case please see if you can locate a more up to date one, or it is more recent and he forgot to request a new Key. Let me know and I'll see what I can do. Regards, Pete

That program is not mine, you'll need to ask at PM support about its INI files. It is FSUIPC which reports this error. Check the FSUIPC.LOG for more details - you'll find it in same Modules folder as FSUIPC.DLL. Also, look in the file, in the same folder, called FSUIPC.KEY. Is there a line there saying pmtcas=J2LQXOMT450K? That's where FSUIPC stores any program keys you enter manually. If not, or if it is incorrect, you are not entering the key correctly in the Program registration dialogue. Regards, Pete

Yes, if you don't register your FSUIPC with a user Key, then any add-on which accesses it must provide its own key to gain access. I don't know it. Is it truly freeware? Eric has applied for and received keys for his products but he's not mentioned any free gauges. Even if it was free, if it is written with an incorrect access method (using the external interface, not the internal one) then it cannot be granted a key -- the interface method would be wrong and unsupported. You can check by looking in the FSUIPC.LOG file (in the Modules folder, with FSUIPC.DLL). It should be listing details of the invalid access. If the details give FS itself as the culprit then the only way you could use the gauge would be by getting an FSUIPC user registration. Please make sure you are using an up-to-date version of FSUIPC (3.14 is current) so that the logging is as I expect it to be. Regards, Pete

You don't need to if you don't want to use any of the facilities it provides. The extra it does give to PFC gear is the ability to program most of the buttons, knobs and switches to most anything in FSUIPC's repetoire. As for paying for it and entering the registration, all that is explained in the User Guide, supplied in both PDF (Acrobat) and DOC (Word) format within the ZIP file. Regards, Pete

All I can say really is what it says there -- for some reason your Server PC is refusing to allow the Client to connect to it. Maybe you have a firewall blocking it? There's a firewall facility in WinXP, maybe that's enabled? Or perhaps you are running ZoneAlarm or something similar, and need to make some changes there? Again, another possibility is that the connection is via a router or switch which is blocking it? The message being logged is simply what the Windows Netwrok interface is telling WideClient when it tries to connect. I don't really know enough about networks to help any more explicitly, but maybe someone else will read this and help. Otherwise, Katy Pluta over in the FS2004 Forum knows quite a bit about this sort of stuff. Regards, Pete

I don't have a website, and you cannot legally register FSUIPC with a key obtained from one. Please tell me where you got this key in case it is being illegally distributed. :( Pete

Yes. that is correct. This is not actually a PFC.DLL function, it is merely reading an indication from FSUIPC which, in turn, is reading the indication from FS. I really don't know what the "RealityXP" GPS is doing, but evidently it is not setting the FS OBI 1 to the correct radial in order to fix this. Sorry, but I cannot undertake to support every add-on. I don't even have that one, and I'm afraid I am not particularly on excellent terms with its creator. Please try the FS2004 GPS and see if you get the same. I'm not sure what is supposed to happen when the FS A/P is following the GPS rather than the NAV indications, but if there is something obvious I can look at making a change --- probably merely detecting that the GPS is driving the A/P, not the NAV and so not activating any LEDs at all. Regards, Pete

Two questions here: assuming you are using buttons via the EPIC to activate the KeySends, are you certain that the Buttons are working, that they are being seen? One way to test is using the Buttons page of FSUIPC. In fact that's by far the easiest way to program your Keysends -- scroll through the FS control list for the KeySend control and set the parameter to the KeySend number. Secondly, although you imply that all you have changed is ISA to USB EPIC, you also say you have "moved wideserver files over". What does that mean? Why would changing EPIC necessitate moving WideServer at all? WideServer should remain installed in your FS Modules folder, otherwise it won't work. I am assuming you have rewritten your EPL program for the EPIC USB. The system has changed a lot, and in particular the button numbering is different I believe (sorry, I am no longer an EPIC expert as I don't really use it these days). If it isn't seeing the buttons it won't know it is supposed to. Try programming the keysends in FSUIPC. At least you know for sure that you have the right buttons then. I changed the documentation a long time back to recommend this way. The old WideServer KeySend parameters are only left in for compatibility with existing setups. BTW you don't mention what software it is you are sending these KeySends to. If it's Project Magenta then it would be far more efficient and reliable to use the PM controls programmed into FSUIPC already -- again, see the drop down control lists on the Buttons page (enable the PM controls checkbox first). Of course, they work via the PM MCP so if you don't use that you do have to resort to keystrokes. If you still cannot get anywhere, I would need to see more details. But at present it is simply sounding like the buttons aren't being seen, or are arriving with different numbers because of the change in EPIC. Both of those can be dealt with easily by using the FSUIPC Buttons page. Regards, Pete

Yes, as documented. However you can launch 6 altogether, as the other three (RunReady1 - 3) are independent. The only different with the RunReady entries is that the launch doesn't occur until there is a connection to FS. I've no idea, you'll need to ask the author. You can make WideClient "sleep" more by use of some of the parameters in the INI. The Timeout one I think might be instrumental -- this is what it says in the WideFS documentation: Is this what is happening? You cannot use the mouse or access anything else? If so, then certainly it needs attending to. However, bear in mind that this parameter will apply to ALL applications, not merely S-Combo. On the other hand, if there is no adverse effect of 100% utilisation then what is worrying you? Many programs do soak up all the idle time without any dire consequences -- FS is itself one of them of course. Is it truly a "load" or is it just soaking up the otherwise unused time. If there are no adverse effects, don't worry. Regards, Pete

No, please don't. Ahtoo late. After experimenting with different values via FSInterrogate, I found that adding 256 to the value (which is in 1/65536's of a metre) did the trick, without messing up the good values. 256 is equivalent to 0.0039 metres (i.e. 1/256th). The result is PFC DLL version 1.831 which is being released as I write this -- I have sent a copy of the DLL (only) to yuo (too big to attach here). I am not surprised, you ought to be! I've had a brief glance at XML from time to time and can't make head nor tail of it! Looks nothing like any sort of programming language I've ever used and doesn't look something I'd want to mess with! :) :o :? :? Regards, Pete