Pete Dowson

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

Sorry, I don't know such hardware, but if it is an assignable axis, then of course -- just assign it to the spoiler in FS. It sounds like you are trying it on the ground. If you try to arm the spoiler on the ground, FS deploys them 100%, as if you just landed. You can't move them into any possition without going through the ARM detente. Try testing them in the air. If they are still the same then you badly need to re-calibrate the slider in the Windows game controller. :-( Did you check the documentation at all? Joysticks tab, look through the pages till you see "spoiler". Regards, Pete

I don't see why. I'm not sure why you even ask me. The PFC MCP can be used separately (direct to the PM MCP program), or in line with the console (the latter connects to it) with my PFC.DLL. If you mean other makes of MCP, what possible interaction could they have with the PFC gear? Certainly my PFC driver doesn't touch them, so it depends what software you are using, doesn't it? Regards Pete

Sorry, I don't really know any of that sort of stuff. I've provided mappings in FSUIPC for a number of failure types -- they are all I know of. I have never heard of specific types of engine failure, only a generic one. Check offset 0B6B -- I think you can fail individual engines. If you are an ex-Adventure writer, have you considered using the replacement for APL, the ABL or whatever it is called? Regards, Pete

Goodit must have been scenery/texture loading progress messages then. I haven't got them here, under test, but that's the only explanation. Regards, Pete

Good. Thanks for the feedback. Pete

Does the mixture lever control the mixture in FS already? If so, and if you have a user-registered FSUIPC, simply go to the Joystick options, page through to find the Reverser, and calibrate it as described, step-by-step, in the FSUIPC user guide. (FSUIPC defaults to using the mixture axis for reverser in any case). There's an option to do this only for jets, so you still can use it for mixture on props. If your mixture lever isn't already working in FS you need to fix that first. Regards, Pete