Pete Dowson

Well done! All this complication and obscure inefficient-looking code does make me wonder -- why choose C#? It seems to have the worst of VB and C++ with none of the flexibility and power of the latter or ease of the former. Regards, Pete

No holidays planned yet. Need to get my eyes working properly first -- I'm committed to regular attendances at the hospital at present. My left eye (operated on 2 weeks ago) is okay at present, but the first one done (6 weeks ago), the right one, still is unable to focus and has a smaller image. Seems this isn't the brain getting confused as they first though, but a swelling at the back of the eye. I'm on medication for that now. The only problem with all this is that my time in front of a PC (or reading for that matter) is limited. I'm keeping up with support messages and emails, but I'm not doing any new programming at present. So that's a holiday of sorts, I suppose. :lol: :wink: Regards, Pete

Ah, I'm afraid I would be stuck even before you! But: "Marshal.ReadInt64" will presumably read an 8-byte (64-bit) integer. Can you use casts in C#? If so just copy the int64 you read into a double using an explicit cast. Regards, Pete

That's more than me! :wink: If C# supports the double type, why can't you use that directly, like the other numerical types? Can't you add a further 'overload' (whatever that is, forgive my ignorance)? Regards, Pete

500 msecs is very slow. I wouldn't worry about that. If that is adequate for your purposes, stick to it. There are programs looping every 20-50 mSecs which seem to run fine without noticeable impact. If you are running your program on the same PC as FS you are more likely to affect its performance by hogging the processor for your own purposes than by giving it control via FSUIPC_Process. If you run your program on a Client PC under WideFS, your Process calls aren't actually relayed to FS at all except once for each new location read, though of course all the writes are forwarded. Once WideServer knows you are reading a location it sends it out on every single change. For locations changing on every FS frame (and there are many), that should be the rate the memory in WideClient is updated -- even if you only read it at 2 fps. Regards, Pete

That's probably not the horizon -- it may be the dark band above the horizon which I think was deliberately put there by MS to represent the normal surface murk. Except it doesn't look too good. Check -- look for a sunset or sunrise. If you can see the sun through it, that's what it is. Limit the maximum visibility to mask it. The other possibility it a difference between the maximum scenery drawing range and the visibility - I think there are sliders in FS to fix that. Check the FS FAQ's in other forums hereabouts. Regards, Pete

For 3 minutes!? Phew!. I cannot imagine what would be 'held off' for that long. Certainly with 1Gb memory it shouldn't really be down to the memory getting tidied up. Yes, try that. The slow down (not the speed up) could possibly be due to the message queue getting heavily laden with panel commands. The advanced panels in these add-ons seem to do a lot of that. Microsoft's recommendation is to fly with it set to "unlimited" and observe your average frame rate, with the sort of aircraft and scenery you normally use. Then set the slider a bit below that value. This helps the sim keep 'up' to that rate, therefore making it smoother, and also allows more time for other things to happen rather than it spending all of its time only re-drawing scenery -- for instance, the AI traffic may get more attention, things like that. However, there are some different recommendations. For instance, the UK VFR scenery is said to run best with the slider set to unlimited, otherwise I think it implies that the "fuzzy" look appears more regularly. If you use my WideFS I recommend setting it low enough for WideServer to operate smoothly in relation to the frame rates expected on the Client PCs. Also, I expect the limiter would also come in useful for those trying to use FS to play back flights from external applications. Regards, Pete

Yes, as you will see when you read the Access Registration document. However, I didn't realise you hadn't even started yet. You can certainly delay the access key part until much later. You do not need a Key to test your program with a registered copy of FSUIPC. Regards Pete

It isn't really a meaningful question like that. Over a period of 24 hour I excpect you could do millions of reads and writes without impinging on anything. It is the rate at which you call FSUIPC_Process which will be limiting performance. If you mean the number of reads and writes in one FSUIPC_Process, then the only limit is the total size of the request. Count each separate FSUIPC_Read call as about 16 bytes and each separate Write as 16 bytes plus the data length. The total before the FSUIPC_Process shouldn't be more than that allowed by the interface programming, which is about 30000 bytes or so -- if you are using my Library then it checks this in any case and you will get an error on the first Read or Write which won't fit. One thing that is bad is doing lots of Process calls when you could combine all the reads and writes and do one Process call -- the reads and writes are local to your process and are merely accumulating data ready for transfer by the process call. Regards Pete

"Goes crazy"? Why is distant visibility crazy? I don't see a problem reported here. Please check the FSUIPC user documentation and try some of the visibility optins if you want limits placed. Please note that Version 2.975 is about 15 months old and is not supported any more. The current version is 3.30. Regards, Pete

Even with my eye problems, I've been dealing with all mail within the same day. I'm just not doing much programming at present -- takes too many prolonged hours at the PC. I just found a message from a "Jason Springer" -- I take it that's you? It arrived at 0129 BST on the 27th and I replied to it replied to that at 1601 BST on the same day. The question was: and I replied: You should have received that by now, surely? All I did was click the "Reply" button as usual, so it would have gone back to whatever email address you used - a Yahoo one by the look of it. It hasn't bounced back here. Regards, Pete

I've never found one. I did find some route data which is used in the GPS -- see offsets 6000 onwards. You do get the last waypoint ID and the next. Regards, Pete

For how long? One second, one minute, 5 minutes? There might be a clue there. :lol: :lol: :lol: No, I don't think things work quite like that. But it may have something to do with message queues or memory allocations. Are you running a complex add-on aircraft panel by any chance? Some of those are prone to piling up messages. Do you have at least 512 Mb of main memory? If not it might be worth increasing it to at least 512. With Windows XP and any add-on programs also running I'd go for 1 Gb anyway. Is this behaviour the same when you don't run AS2004? Maybe it holds off whilst you are in menus, and takes a while before starting again? I wouldn't recommend any such thing even if I knew of one. I think you are making a mistake watching the frame rate counter. Turn it off and just see if the flight feels smooth. The frame rate does not tell you if it is smooth or not. I've had great flights where it rarely got outside 10-15 and terribly jerky ones where the frame rate was never below 30. Frame rate is not a measure of smoothness, and it is misleading to watch it. Regards, Pete

You mean, into FSUIPC options dialogues? ALT M F? When you say "doesn't seem to last a long time", how long do you mean? Do you get the same effect with other Menu items? after all, all FSUIPC options does it effectively stop FS for a while whilst Windows runs the standard dialogue code. All of the other FS menus are basically the same, except they are using fancy DirectX graphics whilst mine is standard Windows. The PC doesn't "use FSUIPC". FSUIPC just bolts itself into FS, it is just another component of FS like all the others. And, unless you have some applications actually using it, it doesn't even do much most of the time. I would be quite concerned that you've not got smooth flight in any case. There should be no reason for any jerky flights. Maybe you have something else going on in your system? How exactly are you observing "smooth" as opposed towhat, exactly? Jerky? How frequent and severe are your "normal" stutters or jerks? What else have you got running as well as FS, and what are you using FSUIPC for? What is your hardware, and what have you set the FS frame rate limiter to? Oh, and are you using Win98 or WinXP, or something else? Regards, Pete

This is a question about how Windows file system works! When you copy a file into a Windows folder then it cannot co-exist with another bearing the same name. Therefore it will be overwritten. Being overwritten or being deleted amounts to exactly the same thing. What truly happens at the low level on the disk is probably that the system writes the new file afresh, adds it to the folder directory, and removes the folder entry for the previous copy -- but not necessarily in that order. If you need to know I'm sure there are detailed books on the hardware and software operation of file systems to be found. But I really don't understand why you need to differentiate between "deletion" and "overwritten". What is the point of the question, please? If you want to install an updated version of FSUIPC just follow the instructions in the User Guide. They are simple enough, after all, just amounting to "copy the FSUIPC.DLL into the FS Modules folder". That is all you have to do. Why the questions? Regards, Pete

If you stay with UDP you might want to investigate whethere you have the TCP/IP protocol set in a mode where it coalesces short blocks into one -- I think this is the default action. It waits foir so many milliseconds to see if you are going to send soimething else so it can send them together. This makes sense on the Internet proper, as it cuts down on overheads substantially, but it is a pain when trying to use it for real-time interaction between two local machines. In Windows "WinSock" the option is turned off by a SetSockOpt with TCP_NODELAY. Before I discovered this, when I changed WideFS over to TCP/IP from IPX/SPX I had a lot of stuttering problems. Every so often loads of small changes were bunching and being sent in one block. Regards, Pete

Oh dear. You didn't understand my last reply at all, then? Surely you must be reading 16-bit numbers from the interface for other values in your program? Why is it that you are stumbling on this, one of the easiest 16 bit numbers to deal with? Do NOT read 037C into two separate bytes! It is one 16-bit word. Read it into a "short", or whatever a 16-bit integer is defined as in your language. As a 16 bit word the above value is 1111111111111011 which is 0xFFFB which in decimal is -5, so it is 5/512ths of the way to a 2-minute left turn. Please, please, always try to view the values in FS in the way that they are defined. The length of a 16 bit number is 2 bytes, just as the length of a 32-bit integer is 4 bytes and that of a 64 bit double float is 8 bytes, but for numbers occupying those bytes you view them as numbers, not individual bytes. The length is only important in the Read and Write statements, because the interface doesn't know what your data is, it is just allocating and transferring memory blocks. Pete

What do you mean, -355 to 255? A 2-byte (16-bit signed short) can accommodate -32768 to +32767. The use here for a range -512 to +512 is easily accommodated! A single 8-bit signed byte can accommodate only -128 to +127. So where do you get -255 to +255 from? You convert metres per second to knots by *3600 / 1852. This is what FSInterrogate is doing. Both are correct, please note the difference in units. All the information you need is in the document, you just need to read it a little more carefully. Okay? Regards, Pete

The above worked Fine but please note that you can do all this stuff through the FSUIPC options dialogue inside FS. It should be far easier! You don't need to know the control number (2999) nor the keypress codes, only the parameters needed -- and for those the best, most up-to-date, reference will be the PM FSUIPC offsets documentation provided by the PM site. Regards, Pete

Not yet, but I am expecting one soon! Ah! I see (I think)thanks for the explanation, and I am so glad it is not an FSUIPC bug! :D No, I prefer to leave these things inthey are all educational in their own way and I'm sure it will help more than hinder! Regards, Pete

Always use the latest version unless there's good reason not to -- I cannot support old versions. It is not possible to actually have two copies of FSUIPC.DLL in the same folder (Windows won't allow multiple files with the same filename in the same place), but check that there's not one that has been re-named -- renaming is NOT a good idea. Also, check the main FS folder too. Apparently both FS2002 and FS2004 can load modules from there too, and that IS a problem! Sorry, I don't understand this part. What is the word "overight"? Do you mean "overwrite"? If so, it isn't FSUIPC which overwrites anything. With any Windows file system, if you copy a file into a folder which has the same name as one already there, it will either replace it -- or it simply will not copy! You will normally get a prompt warning you. This is Windows stuff, nothing to do with FSUIPC. Regards, Pete

Not sure that using keypresses is a good way in any case. FSUIPC does supply PM controls which operate through PM's offsets. You would probably be better off using those rather than keypresses directly. They will then work no matter where in the Network things are placed. You can program them in FSUIPC's Keys page. But... I cannot imagine how to use PM offsets from FSUIPC. Worse, I don't know how to uses the parameter feature in FSUIPC. I must be searching in the wrong places, because I could not find anything related to this in the documentation. There's plenty on this in the User guide, even an example of using the parameter facility in an FS control to set the standard pressure setting for the altimeter. How did you miss that? There is no direct PM control programmed into FSUIPC for offset 04F8. You can use that but you would need to use the Offset Word Set control. When you select this control in FSUIPC's drop down list you will find you can set both the offset AND the value (parameter) to be written. The Offset controls are referred to in the documentation in both the Buttons and Keys programming section, but the fuller section is under Buttons. Cross-references are also provided. I'm surprised you missed all of it. However, probably easier than setting offset 04F8 directly, you could use the PM GC controls (by param) facility instead. This most certainly does include parameters for the whole ND Map range, including 5nm and 640nm. Details of the values are actually given in the PM FSUIPC offsets documentation on the PM site, and mostly reproduced (though probably out of date) in the FSUIPC Advanced User's Guide. Regards, Pete

In the Goflight software or in FSUIPC's Buttons page? If both the general assignment to the button and the new one were both done in FSUIPC, then only one should operate at a time -- the aircraft specific one when that aircraft is loaded, and the other one for all other aircraft. That is the way it is designed to work, and it is the way itr operates here. On the other hand if one of the assignments was done in GoFlight software or in FS's own assignments then FSUIPC will know nothing about that and so would not be able to overrise it. Please clarify. I need to know if you have come across a bug in FSUIPC. I would need to be able to reprocudice it. Are you using FSUIPC 3.30, and were both assignments in FSUIPC? I'm still anxious to identify the problem, please. If it is a bug it needs to be fixed. BTW there are FS controls for panel selection. Using the keypress is okay but not so efficient. FS will look up the keypress in its keypress assignments first to see what to do. They don't have to be Shift+1 to 9. Regards, Pete

Yes, but FSUIPc is not actually reading the joystick values, it is intercepting the final FS control values -- in this case for the throttle. There's no actual axis assignments nor handling at present in FSUIPC, only manipulation of the parameters being sent to the simulation engine (SIM1.DLL). All the assignments need to be first sorted out in FS. The latter is where at least one misunderstanding lies -- you do not tell FSUIPC anything via the FS9.cfg file. That is telling FS, so it is in fact exactly the same as assigning the axis in FS assignments (except the latter is a lot easier! :wink: ). I don't understand what the GoFlight software is doing assigning axes separately. Guess I'll have to wait until I get a TQ6 to understand that part. No no, it isn't messed up. Just a tad confusing. Sorry. Regards, Pete

I don't know, sorry. There used to be two versions of WidevieW -- a full version and a "Lite" version. In the full version you could actually configure what sort of stuff was sent to the clients. I think the Lite version was intended for the majority the users, where all that was needed was support for the outside views -- time, location, weather, basically. If the current FS2004 version is that Lite version, then you are probably correct. Not sure how important that is to the current question though. Regards, Pete