Pete Dowson

FSUIPC doesn't recognise it where? In the Axis assignment facility (FSUIPC 3.60), or only in the Joystick Calibrations? If it is the former, then it seems like it isn't one of the standard 6 axes supported by the Windows joystick API (X Y Z R U V). What puzzles me about what you say, though, is what you mean by FS displaying it but not making use of it -- how can it "display it" if you cannot assign it? Or do you mean you assign it okay, but it doesn't operate the thing you've assigned it to? If the latter then all that means, probably, that FS has got the sensitivity set to zero -- go to the Sensitivity slider and move it full right. Whilst you are there, move the null zone full left. If that makes FS work with it, then it should also make FSUIPC's calibration section see it. Regards, Pete

Oh, right. Sorry, I misunderstood. And I assume you aren't using software with flexible user programming like the pmSystems from Project Magenta? I am reasonable sure that it just counts the voltage down as juice is used up before the generators are on, so you might get away with just writing a value once, but some experimentation would be needed. Used in conjunction with FSUIPC's "magic battery" option (to extend the life) maybe you'd only need to be able to write something small to it. Trouble is it is 64 bit floating point, so with current FSUIPC facilties the only value you can easily write is zero, but you'd need to write two 32-bit zero words to do that. Best actually for me to add new FSUIPC offset controls, to write 32-bit and 64-bit floating point values calculated from, say, a normal 32-bit value representing the amount needed times, say, 1000. I would probably add these to the list in the Advanced User's document: 0x7000zzzz Offset Float32 Set 0x7400zzzz Offset Float64 Set I'll check first that offset 2834 does operate as I thought. If you think you could use this I could supply a test version of FSUIPC for you. What do you think? Another alternative is, of course, to simply use FS's master battery switch, and invent your own which only operates the FS one when the APU is running correctly. You could achieve such simple logic using FSUIPC's conditional button facilities. Regards Pete

Okay. Please give the attached version 3.608 a good going over. I've been testing here and it seems okay so far. I'll continue over the weekend too. Basically this is now what happens: 1. FSUIPC only loads the default Axes or the ones specific to the current aircraft (allowing for the shortened name option if that is set and used). The decision is based not on the presence of an [Axes ...] header, but on there actually being valid assignments in that section. In other words, you can't have an aircraft-specific section with no assignments -- it will be ignored. 2. Everything in the on-line editing works identically for the general and aircraft specific assignments. 3. When running with the general assignments (i.e. for an aircraft not provided with a valid section), selecting "aircraft specific" will bring up a message box asking if you want to use all the general assignments for this aircraft. Here you can cancel (go back to general) , or select Yes to work with the general ones, changing them as needed, or select No to start with a blank sheet. In either Yes or No case you may be asked if you want to save any changes in the general axis assignments you may have made so far (else they will be lost). If you select "No", to start from scratch, but then don't assign anything, FSUIPC will revert to the general assignments for this aircraft (it will reload them automatically when you Ok). 4. The converse is a little different. If you enter the dialogue whilst running an aircraft with existing specific assignments, then try to de-select "aircraft specific", you will be asked if you want to delete all the specific assignments. No or Cancel will retain the status quo, otherwise the general assignments will again prevail for this aircraft. This actually represents a new facility -- before this it was only possible to lose aircraft-specificness by deleting every such assignment via the dialogue, or by deleting the section in the INI file. Note that FSUIPC does not (cannot) delete the [Axes....] heading in the INI file, but it will be emptied, making it ineffective. I hope this is all clear! Have fun, and let me know how you get on. Best regards, Pete FSUIPC3608.zip

This is only because it is controlled by something in the Aircraft.CFG file, and gets overridden all the time. You don't really want to do it that way, I assure you. I'm not sure what aircraft you are looking at, but most of the airliners I know of won't power the buses for the instruments unless the battery is on in any case. The APU just provides more power and keeps the battery charged up. No, but you can control the battery voltage by writing to offset 2834. That's the better way. You can drain the battery and charge it. More realistic, no? ;-) Regards, Pete

Where else do I contact you, according to your website, you only accept conversations in this place, that was not my design, but yours. I was not suggesting you contact me on this subject! The questions you want resolving, about assorted ways of confiuring FS and the many display options there are have been and are still often discussed elsewhere. Here I support my programs. You really haven't got to that stage yet -- you still need suggestions about ways of doing what you want to do. I don't write or support applications, only tools for applications, and you may not need anything outside of FS to do what you want in any case! No. A way of discarding the second PC. You don't even need a triple head if you only want the two screens you mention. Almost any modern video card supports two monitors out of the box. Join the club. I'm 63 this year and at this rate won't see 64. :-( No you are not! You are a customer by accident or mistake. And I am very sorry about that. You should find out how to do what you want first, not how to use tools which may or may not be anything whatsoever to do with it. In fact, there is really nothing my programs will do to solve your problem. You need to look at FS itself, which has many capabilities already, then, if you desire, look at external gauge programs. They may or may not use my software as tools -- there are some which do and others which don't. Either way, the instructions which come with the applications are the most important part, not my instructions which are mainly for reference in any case, at least after the first page or two. BTW I see you are in Cheshire. Far from Stoke-on-Trent? If you were to become a bit friendlier, so i wouldn't be frightened of you as I am now, then possibly you could visit? I have some interesting stuff here, accumulated over the years (I've been programming things with FS since FS4 days, more intensively when my eyesight problems stopped me getting a pilot's license). Pete

You did not ask "HOW", you just launched into an insufferable barrage which I found quite insulting and not in any way inducing one to answer kindly. If you browse some of the threads here you will find I answer questions as helpfully as I can. You apparently came here to rant and rave, not really to seek any guidance. If you look back on your messages perhaps you may see that -- imagine you or your projects are the object of your own outbursts. I have worked full time on these programs now since FS98 days, and not earned one penny until I nearly went broke in the year FS2004 was released. I have never wanted to "sell" just develop and support, but circumstances forced the issue. FS9 is nothing remotely like a "simple program" I assure you. And it was never designed to do what you want of it. Maybe the next version will. Perhaps you came into this at the wrong time. Almost everything outside of FS's base capabilities has been produced by third parties and for the most part with no help from Microsoft. When I look around at what has been achieved with what Microsoft provides I am constantly amazed, yet you come along and deride it all as "simple" and wonder why everything for it is not too. Anyway, to answer your question, if all you want to do is have views on one screen and instruments on the other, just make sure your main PC has a video card which supports two monitors, then discard the second PC, attach its monitor to the first, and simply undock the panel parts and move them over to that monitor. You need nothing of mine nor any other add-ons, and it'll all run just as fast, better, in fact, than with two PCs. I don't have a Web site. If you mean Enrico Schiratti's page where he provides my software, that is a service he provides, for downloads. It in no way tries to explain what any of the packages do. The problem is that you are starting from the wrong end. You need to decide what applications you want to run, and then see what they need to support them. My programs are background, they are tools for other programs and do little useful on their own. There you go again! :-(. That is most certainly completely untrue! Where on Earth are you getting this stuff? You do NOT need to purchase FSUIPC to use WideFS! You only need to install it. Purchase gives loads of other benefits, which you don't even have to read about (it would presumably only confuse you). It isn't in that BOXED note -- the ordering of things in the documentation is deliberate, besed on the misunderstandings which have occurred over the years. WideFS is now in its 10th year and a lot of learning and experience has gone into the way those important parts are presented. You appear to choose to quote things out of context to distort this. Exactly, because folks, not unlike you it seems, constantly assumed it would run FS internals or do the job WidevieW does. From experience I judged it best to get all of the warnings right up front, because 90% of folks never read much further, even if they read that far. Most folks just install, try things, THEN think of reading the manual. This is even worse if they've paid and find out they can't do what they thought. Believe me, the order is correct and for very good reasons. If you don't like it, don't use it, but please don't come here with these attitudes. I can help if you ask for help, but I'm not going to take unjustifiable criticism apparently spoken out of ignorance. Please do come back if you decide to be more friendly in your attitudes. I cannot deal with you otherwise. Sorry. Pete

Yes, but that does mean you can have view on one (the client) and panels on the other. Of course that is a waste of a PC, as you could do that with no loss of performance by having two monitors on the one PC, something almost all video cards can handle readily these days. WidevieW is one solution to the need for a wide outside view, typically used for forward, left and right views in collimated displays in a built cockpit. There are others which use one PC, like the triple head Parhelia card, now not one of the fastest though, and the new Matrox triple head adapter, which fortunately can be used with any of the newer fast cards. The only disadvantage of a multiple monitor solution is that the whole width of the three displays must be encompassed in one window, not three separate windows as this reduces FS's frame rate to unflyable levels. By careful use of the Zoom factor, though, one can get a nice wide view which I find acceptable at 0.50 Zoom. You can stretch it further round, but verticals are definitely getting that fish-eye effect towards the edges then! ;-) Regards, Pete

If your WinXP is not at least SP1 level, yes you would. Also I suspect your other problems are partially down to the mixture. I found my Networks all ran much better when I updated them all to XP -- an admission I was pretty reluctant about, I can tell you, as I was a staunch "Win98 forever" person before! ;-) Well, WinXP is okay with IPX/SPX, but the mixed network may make it more of a problem. Sorry, I don't know. I never went back to Win98 after I found that all the Network problems seem to have been fixed in XP (SP1 at least is needed). Maybe, but be prepared to try other things with TCP/IP too. When I mentioned IPX/SPX it was really only to try it as a work-around for this dial-up thing you've got going on, or at least a proof that it couldn't possibly be WideFS. I didn't know you had a mixed network then or I probably wouldn't have mentioned it. Regards, Pete

Let me clear some totally misleading things you are spreading. I hope this is innocence ignorance on your part and not malicious. Yes, FSUIPC is essential for WideFS, because WideFS uses it to interface to FS. It is NOT essential that you pay for FSUIPC however. If you'd take the trouble to do a little more research before buying things you don't need and then ranting and raving about them you might see that more clearly. WideFS is NOT the mechanism I invented to join two PCs together over a network to run two copies or anything of the sort. Merely reading the first easy paragraph or two would tell you that. WideFS is simply a way of providing the FSUIPC interface on multiple computers, interfacing to an FS running on one of them. And you DON'T need to know what FSUIPC does in order to use it. All you need to know, before you invest in any of this, is whether the applications you want to run need FSUIPC or not. Neither of my packages are applications, they are background tools. You should be concentrating on the applications you want to use, not on the tools to support them. The folks who make the applications can help with that. Or at least they can and will if you have a better attitude towards them than you show here. No. What you want to do is absolutely nothing to do with FSUIPC, WideFS or Project Magenta. You can do what you want to do with WidevieW, which is not supported here as it is nothing to do with anything here. Project Magenta does provide high quality "gauges" amongst its programs, but they are not FS gauges, they are separate programs which interface to FS via FSUIPC. For speed and smoothness. I don't use WidevieW, I use a Parhelia video card with three monitors -- one very wide view from one copy of FS. You just need a very powerful PC. There are other options. You should ask these things over in the FS2004 or Cockpits Forum, not come here and vent your frustration and ignorance at us. 25 of those pages are reference material only, and the others are installation (easy) and answers to frequently asked questions. your writings here are actually more like toilet paper quality -- go try reading them again yourself! In view of your persistent bad and intolerble attitude I won't be replying in future. If you want to spread malicious lies go do it someplace else. :-( Pete

Thanks for that insult. It is a sure fire way of getting help. And I am neither of those things, I've not even got a degree. I'm just a very old programmer. In any case WideFs needs almost no configuration whatsoever these days. It's been improved to the point of install and run. You shouldn't have bought it then. I hope somewone else helps you, because with your attitude you are not likely to get any from me! :-( Pete

Hmm. Sounds like your internet connection settings need changing then. It is far better (more efficient) to have fixed IP addresses for each of your PCs. I've never let any automatic assignment operate here and the Internet connections are fine. If you use a router it is a matter of assigning that an IP Address and turning off its own assignment mechanisms. Also, I didn't know you could mix them like that. I thought for a single workgroup you had to either have them all fixed or all automatically assigned. Seems you need really to talk to someone about Networks. I only know what I've used and written about. Katy Pluta over in FS2004 Forum may be able to help. Have you tried letting all the Pcs get their IP addresses automatically, and simply used the Computer Name in the WideClient INI file ("ServerName"). If all computers are using WinXP or Win2K and you use WideFS 6.51 or later you should not need to specify any server in any case. The client finds the server provided it is in the same workgroup. Regards Pete

By "long after", what do you mean? Can you check the AI status in TrafficLook and see what changes to cause it? Reversers do not normally get used until some time after touch down in any case -- all wheels down, then time to spool up. I don't have the program and I don't know what it is doing. Certainly, the fix I put in was specifically for a problem with FSHotSeat, and the user who reported it tested it and approved. Sorry, I really cannot do anything without the author investigating and telling me what the problem is. I suggest you contact him and ask him to investigate. We can resolve it between us then. Regards, Pete

Nothing else other than ASV6 is connecting to it that early. If anything else is doing it it must be hooking into the normal TCP/IP access through Windows. Why not try IPX/SPX protocol? Pete

3.40 is very very old. I'm sure that was fixed -- it's to do with the classification of AI aircraft states into "on ground" or "airborne" -- FSHotSFX only looks at one of the tables. Just checking the History document for FSUIPC, this is the relevant item, in the list of changes for 3.47: That was well over a year ago, and was confirmed as fixing it. The current version in 3.60. Please keep up to date. Regards, Pete

Yes, but there are big exceptions, like a helicopter with its own separate controls altogether. I think a Message Box "Yes, No, Cancel" would be okay. Yes, this already works for Axes too -- same method. You have to edit the [Axes.aircraft name] in the INI -- it works on the aircraft name in all cases, Keys, Buttons, JoystickCalibrations and Axes. Regards, Pete

Okay. I think there's enough here. I think I see how the logic is twisted in my original design. I think, here, that the program is assuming you want to Edit the existing default assignment and make it aircraft-specific only. This is why you get the correct entry, but only in the specific section. Although what you expected to happen does also seem logical, to be honest I never edited them this way. I always started programming aircraft-specific with a clear (no programmed axis) screen. I suspect it is this changeover step which is causing all the problems. Let me explain: Unlike buttons or keys, FSUIPC only uses one set of assignments at a time -- the "default" ones in [Axes] if the current aircraft has no aircraft-specific assignments, or the assignments actually made for this aircraft and no others. Hence, once you have an aircraft loaded which has such a set, you should only be able to edit those assignments. The default ones should never be visible nor editable. I should auto-set the checkbox and disable it. The other way round is not the same of course. If you have loaded an aircraft with no specific assignments, so I load the [Axes] ones, what should I do when you change to aircraft-specific? Start with a blank sheet, or copy all the default settings to the specific section, ready for editing? Thinking back I think I tried to do something not quite either of these two, retaining the default settings in the table, but simply not using them until you've selected them into aircraft-specificness (so to speak ;-)). I am going to have to think about this before changing anything. Easiest would be for me to only ever hold one set in memory -- either the defaults from [Axes] or the specific ones for this aircraft. This would mean that as soon as you started to make an aircraft-specific assignment for an aircraft not already so, you have no previous assignments to work with -- you make them all. The alternative is to copy ALL the defaults into the specific section, so that you then have to edit them to change whatever you need. This would not be difficult either. I think, rather than try to debug my existing code, I will do one of these two. Maybe, when you first click "aircraft specific" I should simply come up with a message box asking whether you want to start afresh or edit the existing assignments? This would give you both methods to choose from. What do you think? Thanks for all the help. Regards, Pete

It isn't WdeClient doing this. As the Log shows, you have ASV6 running even before WideFS gets a chance. Now ActiveSky will probably want to go to its website to download the weather for you, or maybe it is part of its validation if you have not been through that yet. See the log: 19007 C:\Magenta\MCPSee -- ASV6 loads, the whole process then presumably stops waiting for the dial thing for ASV6, then WideFS connects to the server and continues. Now you aren't loading ASV6 through WideFS, so presumably you have it loaded beforehand and it is just waiting for an FSUIPC-type interface to become present before it starts doing something. There is no way WideClient is going on the Internet itself, not with an internal servername. You'd have to give it an Internet IP address for that to happen. Regards Pete

I am not as tired as I thought so I checked the first steps this evening. Yes. that's all good. Not even that duplicate line we had before. I'm ready to press on when you are. It probably all starts going awry either when doing aircraft specific stuff, or maybe re-eding previously entered stuff. Lets do the straight-forward things first and if it is still okay (as is my experience here) we'll try editing in whatever fashion you normally do it. It is obvious that there's something wrong, and all I need to do is be able to reproduce it to nail it! ;-) Thanks. See you tomoorow. Pete

:D :o :wink: Well, yes, with your emboldening I see how you CAN interpret the "One" as being the number 1 rather than, as was intended, just talking about "one of the other two options". Sorry, it is ambiguous I suppose, but I would never have thought of reading it your way. If you take the whole context, the "First", or main option is of course the one the whole section is really about -- the new FSUIPC window option which saves using AdvDisplay for programs such as Radar Contact. The two bulleted paragraphs are about two additional, lesser, options associated with this and presented in the same area on screen. So, in your numeric terms, your "ONE" is the "second" option. However, it really shouldn't be read like that, because (a) that option may not be there, as explained (when it isn't relevant), and (b) neither of these two additional options are really anywhere near as important or significant as the one the whole new facility and section is all about. I'll change "A third option" into "The other option" in some future update, so instead of reading them, as you somehow did ;-), as "1" and "3" they read in ordinary English as "the one and the other". Okay? Pete

Yes. Only axes controlling the same function can conflict really -- switches and dials would be simply dormant until used. In any case, if you have a user-registered FSUIPC you can re-program the MCP functions on the Jetliner to do other things for you. Well, it should be better, of course, more realistic and more fun! ;-) Regards, Pete

Okay. My wife and I were out this evening, just got back. I will print each instalment out and analyse it before we move on. I'll attach three devices to my test system and try to do exactly the same as well. I have two handy, and I think I have one tucked away in a cupboard somewhere ;-) I'll start on this in the morning and be back to you then. Thanks, Pete

Okay. You realise, unlike buttons and keys, the axis assignments change completely (or should do) if you change to an aircraft specific set? In other words, unassigned ones do not default to the 'global' assignements. Hmmm. You example does, indeed, seem very strange. Let me see: you made how many assignments to "aircraft specific"? Let me list them from what you said. 1X aileron Direct 1 (and slew side, 38?) 1Y elevator Direct 2 (and slew ahead, 39?) 1Z prop pitch, Direct 5 0X pan heading, Direct 33 0Z throttle, Direct 4 I assume all these and only these were programmed before what appears in the second listing from the INI? Ignoring the numbers left of the "=" (which aren't relevant), we have, in axis order for the first set before changes: Just stopping there first, it is odd that there are TWO identical entries for 2Z. That shouldn't happen. I'd like to know how that came about. Now listing the second (default) set in the same way: Comparing these, we appear to have completely lost the three entries for Joystick 0, and the 1Z mixture, and gained more duplicates -- 1X and yet another 2Z. A net loss of two entries -- which appears to be the number placed in the Aircraft Specific list. Looking at that: the 2X entry appears to be a duplicate of the default 2X entry, whilst the new 0X entry here is actually one which, as I listed earlier, is one you assigned and appears to be the only correct change. The other 4 assignments you mention appear nowhere, not in either section. This is indeed a puzzle. I seem to be able to edit these things here without problems -- something in the sequences you go through must be different. I'm not saying they are wrong, but in order for me to reproduce these problems and so fix them I think we'll need to help each other in more detail, step by step. Best to start with no assignments, so either delete those sections or move them out someplace. Then, sorry this is going to be long-winded, I need you to go through what you do, keypress and mouseclick one by one, writing down each step and what you see. Sorry, I know it's going to be a pain. It would be good to see/check the result of each assignment as you do it, but that would mean "okaying" out of the dialogue and saving the sections each time -- and this alone may "fix" it. So it might as well be done in the two parts as you just described. I'll try to do the same here then. I really do want to fix this, so sorry if this takes time. It is very puzzling. Something is evidently getting messed up in the internal tables as the editing process proceeds -- and judging by the duplicate entry you had BEFORE even going to "aircraft specific", it should be reproducing somehow. Thanks Pete

If both are kept connected, then Windows should be consistently assigning one as Joystick 0 and the other as Joystick 1. FSUIPC can then be used to assign different axes and buttons for different things, whether aircraft specific or not. You could then disable joysticks in FS. Correct -- you should leave them both connected and let FSUIPC make the changes in assignment automatically. Some of this thread does sound as if you are using Win98 or WinMe, which certainly do have an unresolvable problem in that each time it is started up it assigns joystick numbers quite randomly to the USB devices attached. In Windows XP it seems pretty consistent and stable in its assignments so there should be no problems. If this is the problem the solution is to update your operating system. If anyone does have a problem with FSUIPC, it would be best reported, IN DETAIL, to me so that it can be resolved. Most of this thread occurred whilst I was on holiday and I am sorry I could not intervene earlier as there seems to be a fair amount of misinformation flying around. Please, if there's a problem, give me details. The facilities for axis and button assignment in FSUIPC are working fine here with multiple devices. Let's sort it out! Regards, Pete

It does here. I can have three or four separate USB devices all plugged in together, and have different ones assigned for different aircraft. There is no problem at all in the saving to the INI file. It sees them in whatever way Windows reports them. It doesn't know nor care what type of device they are -- they are, indeed, just numbered joysticks (0-15 actually), each with up to 6 axes (XYZRUV), 32 buttons (0-31) and one POV (treated as 8 buttons, 32-39). As long as you don't keep unplugging them and plugging them in again there should be no problem. Can you please be more precise and tell me what you think is the problem here? Regards, Pete

Ercan you be more specific please? It is quite thoroughly tested now, and works in every respect. Pete