Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Most of the work is actually in designing a usable user interface to do it correctly. If, as a temporary measure, you wouldn't mind measuring things, as you have done, then entering the numbers as parameters into the INI file by hand, then maybe I could do something for you much quicker. What do you think? I could look into that for you this week. I don't know. Maybe someone knows of one. Regards, Pete
  2. I'm afraid it doesn't work that way around as it stands. You have to set the positions of your flap detentes to match what FS needs in the way of input on the axis -- i.e. match the hardware to the software, not the other way around. Neither FSUIPC nor FS has a translation table for axis inputs to flaps positions. The whole range is simply divided into equal numeric intervals, as in fact is documented. I did have it on my list to implement a more sophisticated system, but it never made it to the top. It could certainly be considered for a future version, but I couldn't even consider looking at it until February at the earliest. Regards, Pete
  3. No. In this case you are interpreting the value incorrectly as unsigned when, of course, pitch and bank (and magvar) are signed. Most of these angular values are given in the same units -- such that the maximum possible precision can be accommodated in the space available. It is -2.79. Draw a circle and plot its position. You'll see that. Pirch and Bank have to be signed as they can be up/down or left/right. No, because then a position pitch or bank would turn out to be a big negative number. Please used signed values where that is sensible, unsigned where that is sensible. Regards, Pete
  4. It's okay. I found the problem! Please go to http://www.schiratti.com/dowson and get FSUIPC 3.53. You should be okay then. Seems I forgot to extend the life of FSUIPC version 3 into 2006. When FS2004 came out I expected FSUIPC 3 to only have to last two years -- the normal Flight Sim interval. Duh! Regards, Pete
  5. WideFS can be purchased separately. You don't need to purchase FSUIPC as well, but you must do so for WideFS. These are typical symptoms of a bad registration. If you purchased it legitimately from SimMarket, please ZIP up the FSUIPC.KEY file (found in the FS Modules folder) and email it to me at petedowson@btconnect.com. Please include the email from SimMarket with the details too. Regards, Pete
  6. Is the registration a legitimate one? If you want me to check, ZIP up the FSUIPC.KEY file (from the FS Modules folder) and send it to me at petedowson@btconnect.com. Preferably include a copy of your original notification from SimMarket. Regards, Pete
  7. From the Logs you sent me it appears you are using FSUIPC version 3.14, which clearly is NOT "3.44 or later", and is about two years old, totally unsupported. Please always make sure you are up to date before asking for Support. It would save a lot of time! ;-) See "Supported Version" announcements above, and go to http://www.schiratti.com/dowson. Regards, Pete
  8. Thanks! The same to you and yours too! Good flying as well! ;-) Pete
  9. Yes, of course. Dropdown FS controls AP ALT VAR DEC and INC. You could probably do it directly in FS Options-Controls-Assignments too, but I've not looked. Regards, Pete
  10. Yes, and please post useful answers here, so others can benefit too. Happy New Year! Pete
  11. Thanks. I cannot see anything wrong at all there. Seems that WideClient does connect, and even sends the first data block (that's how the Server knows its name and logs that, also making an entry into its INI file). This is rather a puzzle. All I can do at present is ask you to log more data. Please edit the WideClient.INI file (on the problem Client only) with Log=DebugAll Edit the WideServer.INI with Log=Debug Start up the Server FS, do NOT run the working client (it will cloud the issues on the Server), then start the problem Client. Get as far as running an application on the Client to prove it isn't working, then close everything down. Please ZIP up both logs (they may be very large) and send them to me at petedowson@btconnect.com. I cannot say whether there will be enough information there, but it is all I can do at present. With those logging options, WideFS logs just about everything it does. If it is "hanging" I should be able to see where, and then maybe provide a version with yet more logging in that area. This is the first time I've seen any problem like this in six or more years of WideFS so I am very puzzled by it. Regards, Pete
  12. Something that got added for the .NET Classes (VB and C# it seems). All I know is, if I don't specify it, it doesn't work. From the comments in the example code, it's a Variable holding a returned token index. I got a copy of an email to you from Bob Scott, author of the VB.NET stuff, which seems to explain something about the need for a Token. I still don't understand the ins and outs of it -- the VB.NET stuff apparently needs separate "Gets" to transfer the contents of Reads to your program. I assume this is all to do with the fact that VB.NET isn't real "code" at all, but interpreted stuff (they use the term "managed" these days). It seems to make what I think are simple things much much more complicated. For the benefit of other reader's I'm taking the liberty of reproducing Bob's explanation of the Token here: Regards Pete
  13. All of the things FS does for you from key presses involve what I call "FS controls" (but which gauge writers know as KEY EVENTS). I include a list of them with FSUIPC -- it's in the Zip if you look. I am afraid I have never had time to check them all and document them. But they are there to try. Some won't work and some won't do what you think they will -- this comes from MS changing their minds or hooking things up differently. it's the price paid for using stuff MS don't document. But all those with an "AXIS" or a "SET" in the name will take a parameter, some of the others might but most don't. You can also use FSUIPC to discover the FS Control name for any FS assigned button or keypress -- simply turn on Controls logging (in the FSUIPC Logging page) and look at the log. There are separate options for axis controls and others. Regards Pete
  14. Sorry, I've no idea at all then. You will need to refer to a VB programming book I think, unless someone else here spots this and comes to your aid. I really don't know VB at all. It seems to be deliberately designed to confuse -- at least it always confuses me. C may look more complex to some but it seems far more logical. So "Variant" is some really magic type, is it? I've no idea how VB can reserve the correct space if you give it no dimensions. Why 48 in any case? Where do you get this 48 from? I asked you before but you don't answer. The table at D010 is an array of 96 structures each 20 bytes long, so overall it is 1920 bytes long, not 48. The number 48 doesn't figure in it anywhere. Regards, Pete
  15. I don't know anything about multiplayer, but programs written to inject aircraft into FS using Multiplayer can, if they wish, also inject details of those aircraft into FSUIPC's TCAS tables. It depends how you are getting these MP aircraft. There's a utility called AIBridge from Jose Oliveira which used to do this job for Squawbox 2, but I think (I am not sure) that SB3 does it by itself now. I'm not sure about the other programs. You'd really need to talk to whoever is doing the multiplayer program which you are using. The other way, of course, if you only ever want to deal with multiplayer is for you to write to the MP interface in FS directly, not to FSUIPC at all. It seems a roundabout system to have a utility interfacing to MP just to inject information into FSUIPC so you can read it out again, when you could do it all directly. The only reason the facility for injecting MP data into FSUIPC's tables was added was so that existing TCAS gauges and the like, written for the FS AI traffic, would work with MP traffic too. Regards, Pete
  16. Well, I assume the size is somehow derived from the type -- in this case you'd need the "ByVal Param As Short" (a Short will be 2 bytes, or 16-bits. However, I've no idea how the overload system selects the correct version when you give a literal value, as you have, like 1 or 0. If it assumes it's an integer, that will write 4 bytes, which will rather wreck the result -- see the next value in the offset list. I could tell (YOU could tell) what it is actually doing by logging the IPC reads and writes in FSUIPC and checking what is happening. Didn't you do that? I'm sure I advised it -- the logging facility is one of the major tools you need to use when developing programs. The other is a debugger. I do hope VB.NET comes with one of those! With that, since you have the whole source, all the Read/Write routines, the lot, you should be able to step through everything to see what happens. Regards, Pete
  17. FS does not support both multiplayer and AI traffic simultaneously, so there is no AI information to obtain in multiplayer modes. I think, in VB, you indicate hexadecimal by that leading & so I don't know why it would fail. However, the Microsoft compiler stupidly sign extends the D010 making the value FFFFD010 which will cause problems. You have to postpenf an & too I think: &D010&. Do you mean "variable", not "variant"? Offsets are hexacimal numbers and are containable in an integer. You must be talking about the data to which the offset relates? Data can be of any length. This message I am writing now, for instances, can be thought of as one string which is several hundred bytes long. You will see from the FSUIPC Programmer's Guide that the data at D010 is an array of structures (TCAS_DATA2) each of which is actually 20 bytes long. There can be 96 of these, so the real data length at offset D010 is 96 x 20 or 1920 bytes. Where exactly are you reading "48" from? You find the one you want in the complete list of planes within range, of course. How else? How are you identifying the plane? By position, by an ID of some kind? Regards, Pete
  18. Version 3.48 is an old version and isn't supported. Please keep up to date. Get 3.52 from http://www.schiratti.com/dowson. There's a link for AIBridge on the web page I just gave you, but if you are using Squawbox3 or the other up-to-date on-line flying packages I don't think it is needed. However, on-line flying isn't my subject, sorry, so I may be mistaken. Regards, Pete
  19. Hangs? I've not had a case of it hanging for many years! There are separate threads in it for different things, so it is almost impossible. It sounds like the process is being stopped down in the network drivers. Don't you even have a WideClient LOG fragment for me to see? And I always need to know the version nmuber, always! What's in the current log, and what version is WideServer? Ah, you've not looked at the documentation then? When Wideclient and WideServer start they rename the PREVIOUS log to "0.LOG" before creating the new one as simply ".LOG. That way, if there's ever a need to restart Client or Server PCs you can do so directly without losing any useful information held in the Logs. I need more information to start, please. Logs, INI files, version numbers at minimum. Regards, Pete
  20. Good. Well, they most certainly both use the same single mixture control used by FSUIPC's original single reverser. It sounds like as well as setting the reverser you also did some things with the "aircraft specific" facility, which enables you to make completely separate settings for each aircraft. Each such individually-tailored aircraft data would have its own "Joysticks" parameter section in the FSUIPC.INI. It's an easy enough facility to use, just a check box to be clicked. Regards Pete
  21. Well, there are 5 (five) reversers supported by FSUIPC, the main one which has been around since FS200o days, and four separate ones which were added more recently -- version 3.47 in April. None of these are active by default. If they are selected (activated by pressing the SET button in their selection of the Joysticks options) then, by default they take over the relevant mixture axes (as documented). This assignment can be changed, in the INI file, of course. There is an option to make them active only if the loaded aircraft is a jet, so then they wouldn't interfere with props and turboprops. It sounds likely that you have actually set the single reverser, as I mentioned. I suspect the aircraft for which the mouse could adjust the mixtures were multi-engined. If it was the other way around then this would indicate that the single (original) reverser is reset but the separate reversers are not. This is easy enough to check, just by going to the appropriate Joysticks pages -- the Set button in the top left of each axis section reads "Set" if the axis is NOT being controlled/calibrated, but "Reset" if it is -- just press "Reset" to free them. The alternative of deleting the FSUIPC.INI file just reverts all your FSUIPC settings to default, and is easier if you don't really understand all this. However, it does mean you'd have to go through each page selecting those options you really still want and, of course, re-calibrating any axes you really wanted FSUIPC to help with. Regards, Pete
  22. I think you are in the wrong Forum. The PMDG forum is over in Avsim somewhere, I think. Regards, Pete
  23. Well, the only thing in FSUIPC which has anything to do with the mixture control is the jet reverser, in the Joysticks page. If you've calibrated that (i.e. pressed its "Set" button so that it now reads "Reset") then the main mixture control will be reset to be the Reverser -- on all aircraft, unless you checked the "jets only" (or whatever) checkbox. Multi-engined props and turboprops will be using the separate engine mixture controls, so won't be affected. Only the single engined aircraft will. If you don't know what you've been doing with FSUIPC's options and facilities just delete the FSUIPC.INI file so that everything is defaulted again. This is not something that has been changed in the many years that the reverser facility has been available. it won't be an "old version" vs. "new versions" phenomenon. And it is exactly the same for FS2002 and FS2004 (and FS2000 for that matter). Please, just delete the FSUIPC.INI file before loading FS. It sounds like you've done something in the joysticks section you simply don't remember. Regards, Pete
  24. Though everyone always blames FSUIPC for everything, there is really no way this module can possibly interfere with any mouse control over anything in FS. Even when I have been asked to do something with mouse contorls in FS I have found no way to do it. You will have to look elsewhere. Sorry to disappoint you. Regards, Pete
  25. This is actually the checkbox at the bottom of the 4-throttle calibration page in the options that I mentioned, here, in my last reply: Did you not see that? I'm not sure why you have resorted to editing the INI file when these things are accessible in the on-line options. But, as long as it works now ... 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.