-
Posts
38,265 -
Joined
-
Days Won
170
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by Pete Dowson
-
No, only in Flights and in the Themes. When you say you are loading "actual" weather, I assume you mean you are using the built-in FS facilities for downloading weather from the Internet? Where exactly are you seeing this "clear" report? I didn't think it gave reports before or after loading. I must admit I don't really use FS's own weather much, but I've not heard of any bad discrepancies. Maybe your question would be better on the FS2004 forum? Regards, Pete
-
Can you control AI Traffic AND ATC?
Pete Dowson replied to vstokes's topic in FSUIPC Support Pete Dowson Modules
Turning slew on individually for a specific AI aircraft doesn't change the user simulation into slew mode. Your own flight continues as normal. It simply allows the position and path of the particular AI aircraft to be changed, or frozen -- for instance to precent AI traffic encroaching onto a runway which a third-party ATC program has cleared you for landing. It is worth experimenting with MS's own Traffic Toolbox to see what can and cannot be accomplished with AI traffic. I would hope that MS will provide a programmable interface for it in future FS versions. Regards, Pete -
Can you control AI Traffic AND ATC?
Pete Dowson replied to vstokes's topic in FSUIPC Support Pete Dowson Modules
The latter two are trivial. That is a user thing, nothing to do with Radar Contact. Sorry, but you will have to wait to see what has been accomplished, or experiment for yourself. I did tell you how to start! :wink: Regards, Pete -
I may well become one, once I'm a decent flyer again! I find it hard to remember the last "fun" flight I did. I do a lot of short and repetitive flights, testing things. I'm afraid I let things get on top of me, saying "yes" to almost all requests I get. :? I'm going to have to start dividing my time and reducing the number of additions and changes I make. Trouble is, that's what I decided last time, and then FS2004 was on top of me! I am here hoping the next FS version is a couple of years off, giving me some time to fly! Fat chance, eh? :wink: Regards, Pete
-
Using POV hat buttons with FSUIPC
Pete Dowson replied to David Cox's topic in FSUIPC Support Pete Dowson Modules
That wasn't me but Hm. :) Regards, Pete -
I hope someone else can help you here, because I really have no idea. I don't know or use any of those programs and have never flown on-line. Sorry. Don't the VATSIM sites have someplace you can ask questions of other on-line flyers? Regards, Pete
-
Using POV hat buttons with FSUIPC
Pete Dowson replied to David Cox's topic in FSUIPC Support Pete Dowson Modules
Well, that's not really true, that's why. It's just that if a button is programmed in an aircraft-specific section, and that aircraft is currently loaded, then the specific programming for that button takes precedence over any programming for the same button in the generally applicable section. You can have the same button programmed for completely different things in each aircraft-specific section and also in the general [buttons] section. The latter programming simply becomes the default action for when you load an aircraft with no specific programming. What you were effectively trying to do was have a single button, with a number of different conditions attached, spread over a the section and a specific aircraft section. It's not only horrible to contemplate programming that way (well, it is to me :) ), but it would be a devil of a job to understand what was going on when it went wrong (as it, in fact, did! :wink: ) Is that by measuring the sending of the commands in the Log (Event logging), or merrely by seeing the results? Other things conspire to slow things down. I also noticed that for several functions you were using FS keypresses rather than the equivalent commands directly. That will slow things down too -- each of those keypresses get looked up by FS in its assignments list and converted to an FS control then posted back to the same window for execution. Why not simply assign the control you want in the first place? Regards, Pete -
I've not really got a "main page". The nearest to that is the page that Enrico Schiratti maintains with all my stuff. I am not providing full new releases yet. I'm targetting those for the end of the month or early March. I'll just be posting test versions for folks to try and, if applicable, feedback problems and so on. These will be within announcements here, at the top of this forum. They will contain the modules as attachments, if I can keep the size down to what I'm allowed here. This is an experiment at a wider Beta test period than the very restricted ones I've been operating till now. I'm doing this because there have been some relatively serious problems recently which no one in my normal circles of testers found. I'm also trying to get folks to expect a slower rate of updates than in the past. Getting a serious update ready, tested and documented every month is exhausting me! :wink: Regards, Pete
-
Yes, it is here on my list. I'm afraid I am running rather later than I'd hoped. So many things have been happening on other fronts. I do hope to get the outstanding PFC things wrapped up before I go on holiday in four weeks, though, so please watch this space. Sorry for the delay. Regards, Pete
-
Can you control AI Traffic AND ATC?
Pete Dowson replied to vstokes's topic in FSUIPC Support Pete Dowson Modules
You can do that, but Radar Contact 4 (in Beta still, as I said) will deal with AI aircraft and you are better turning the MS ATC volume right down. Well, I think you'll be surprised what Radar Contact will be able to dobut it has taken a lot of development work and experimentation, and there's no release date set yet. I really don't know so much about VoxATC. I think its main claim to fame is the voice control side. I saw a brief presentation by the Author at the Birmingham FS Show last year, but didn't have enough time for questions. If you want to do your own thing be aware it is a very big job. The ins and outs of ATC are many and varied even if you are going to only concentrate on one area of the world and with one type of flight. For AI interaction you will need to experiment with the areas I mentioned. Regards, Pete -
Can you control AI Traffic AND ATC?
Pete Dowson replied to vstokes's topic in FSUIPC Support Pete Dowson Modules
Check out Radar Contact and VoxATC first. Version 3 of Radar Contact doesn't deal with AI traffic, but version 4 is in Beta and looks very promising in this area. No. And Microsoft themselves says you can't have both operating together. No, only the density setting, which you can change via added FSUIPC controls (see the User Guide and Advanced User guide). But these won't accomplish anything in MP mode. You can do some things with AI traffic through the control interface FSUIPC offers via offset 2900. You would need to experiment though. Mostly I think you have to put them into slew mode to make them do what you want -- changing A/P settings and so on doesn't seem to help. Best thing is to download Microsoft's own traffic toolbox and experiment with that -- you can try sending the AI aircraft all sorts of FS controls there, then apply what you learn via FSUIPC's offset 2900. Regards, Pete -
Using POV hat buttons with FSUIPC
Pete Dowson replied to David Cox's topic in FSUIPC Support Pete Dowson Modules
Okay, curiosity got the better of me in the wee hours last night, and I worked out what was happening here. It's the "Repeat" action which defeats the anti-duplicated button check. In fact the initial "Press" is still eliminated -- what you are getting is the first and subsequent repeats. These are effectively defeating my duplication checks because a repeat action is neither a press or release -- there's no change in the button state. I'll work out a fix for this and it will be included in the interim version uploaded here later today or tomorrow. Sorry for any confusion this has caused! BTW on the question of repeating for so many seconds, etc, I forgot to mention that you can set the Button repeat rate using the ButtonRepeat=20 parameter. This is covered in the Advanced User's guide. Regards, Pete -
Check the thread a little way below entitled "Brakes no Longer Work off Joystick" (not too obscure a title, really?) :wink: Sorry. It is a bug in FSUIPC, affecting those who have calibrated Throttle 1 separately in the multiple throttles page. I have fixed it several weeks ago and sent out a few interim releases for folks to use -- again you can locate one via the threads. However, an "official" pre-release of the next version of FSUIPC will be placed here in an announcement either later today or more likely tomorrow, so your best bet is to wait a few more hours or so and use that. Apologies for the problem. Regards, Pete
-
The title makes this ambiguous. If the title you have used here ("Keyboard Buttons") is meant to imply a keyboard emulating device, not a joystick button device, then the answer is "it doesn't matter" because your HID is looking like a keyboard, so it must produce keystrokes. The keyboard interface is all in Windows, not in my programs. The rest of my reply is on the other assumption, that this is a question about a joystick type device. I'm not sure what a HID is defined as, apart from an "input device". FSUIPC and WideClient use the Windows joystick API (joyGetPosEx), not the over-complicated C++ COM-style stuff in DirectInput, which I really can't get my head around. In the Windows joystick API everything revolves around a unit called a "Joystick". The maximum it can handle on one joystick is 6 axes, one POV (point of view or "hat") and 32 buttons. The API supports a maximum of 16 such joysticks, 0-15, making the total number of buttons per system equal to 512 (not counting POVs, which I handle as up to 8 more buttons, just like FS2000 used to). This is the same interface FS always used, from FS95 through to and including FS2000. They changed to the DirectInput interface in FS2002. If it supports the joystick API as well as DirectInput it would have to appear as 4 joysticks at minimum. This is how the EPIC does it -- up to 16 joysticks for the ISA EPIC using my VXD (Win98), up to 8 with the USB version using the WinXP drivers. I am not sure, but I *thought* the DirectInput standard joystick driver only supported up to 64 buttons (and 2 POVs) per joystick, but of course companies can make their own drivers for USB devices and bypass the whole joystick and DirectInput APIs. In that case the question is moot because neither FSUIPC nor WideClient would handle them, in the same way it doesn't handle any non-joystick HID. Regards, Pete
-
I don't have anything called "UIPC", so I assume you mean FSUIPC. And the only version i support is the current one, which is 3.45. As far as I know there are no panels which "flat out don't work" because of anything to do with FSUIPC, but if you have specific gauges which use FSUIPC then they should have access keys built in for this. The documentation that comes with the aircraft or panels should tell you if you need to enter anything manually. There is no way I can support all the programs which use FSUIPC. It is really up to the individual authors. If you have some freeware gauges needing access and for some reason the author hasn't bothered to program in the key, you may find one in the Freeware Keys list above. To determine which gauges are suffering this problem you can look at the FSUIPC.LOG file (in the FS modules folder). But I'd advise you to check the documentation or support for your panels first. It should be all explained or programmed for you. Pete
-
Why do you think that FSUIPC can stop a panel working? Panels don't use FSUIPC and don't need keys. Some individual gauges do. If one needs a key and isn't supplying it (they should do it automatically), then FSUIPC will tell you, and you can find out which gauge it is by looking in the FSUIPC.LOG file. There's a list of Freeware keys in a sticky thread above and this includes several gauges. Regards, Pete
-
Using POV hat buttons with FSUIPC
Pete Dowson replied to David Cox's topic in FSUIPC Support Pete Dowson Modules
Okay, so the bug in FSUIPC is that I am allowing the line 2=CR(F-0,10)(F-0,11)0,0,K190,8 to work in the [buttons] section when I shouldn't? Hmm. That's odd. I'll try to reproduce it here, but it will be in a few days from now, as I explained. No, no: that isn't how it is intended. The programming is for button 0,0. If you program button 0,0 in an aircraft-specific section then it should be ignored in the general section. That applies to all instances of it as the prime operating button. I thought I already explained this? Why do you think it should be opposite to what I say? Do I have it documented wrongly some place? Regards, Pete -
Is that what the 'bug' is? No one has actually explained it to me yet. In that case it is a possibility! Sorry to have disbelieved you! Well, the airborne aircraft are transferred from the airborne TCAS table to the ground TCAS table pretty soon in any case. Let me check the code: The actual distinction between airborne and ground, for FS2004 only, is currently: If state = 138, "Taking off", then the "on ground" flag is used. If state is one of these, it is on the ground: 128 Initialising 129 Sleeping 130 Filing flight plan 131 Obtaining clearance 132 Pushback (back?) 133 Pushback (turn?) 134 Starting up 135 Preparing to taxi 136 Taxiing out 137 Take off (prep/wait?) 143 Rolling out 145 Taxiing in 146 Shutting down and it is airborne in these states: 139 Departing 140 Enroute 141 In the pattern 142 Landing 144 Going around AHA! I see a bug! There's a typo! The first check above should be: If state = 138, "Taking off", or If state = 142, "Landing" then the "on ground" flag is used. The Landing, like TakeOff2, is a transitional state and I need to determine it by the on ground flag. In the code the second comparison is actually for state = 114 which doesn't even exist! This could have been fixed months ago if only folks had reported the details. Your suggestion is the first which even mentioned to me what the problem actually was. Thanks! I have fixed it in the code here and it will be in the interim test version I will be uploading here in a couple of days. Apologies again, Regards, Pete
-
Right, but you do need to get it all working properly before FS can use it then. My software certainly doesn't come into it till it is working in FS. I'm afraid I'm really not the person you ask about EPIC any more, especially the USB version. I think it's all to do with the way you define and declare things in your EPL but I never actually figured it out and haven't touched it for years. You'll need to seek help from the EPIC folks. Sorry. Regards, Pete
-
Why would that cause a problem for FSHotSeat? All that does is move some TakeOff2 and maybe "Landing" state aircraft from one TCAS table into another. The FS "on ground" flag goes through a bit of on/off indecisiveness when aircraft are bouncing about on the runway. Regards, Pete
-
Using POV hat buttons with FSUIPC
Pete Dowson replied to David Cox's topic in FSUIPC Support Pete Dowson Modules
In that case any button programmed for the PMDG will operate according to that section, not the general section. At least that's how it is designed to work. The general section provides the default action when there's nothing for that button in the aircraft specific section. But all the entries are actions for the one button, 0,0, so, unless I've made a big error someplace, none of your lines 24 to 28 in the general section should work when the PMDG aircraft is loaded. If it is not working like that I will indeed have to look at it and fix it! Well, apart from the fact that it shouldn't anyway (see above), how can you tell? It is exactly the same as line 2 for the PMDG aircraft, look: Okay, thanks. I am deep into something else at present and must get it done. I am trying to make ready an interim release of WideFS, FSUIPC and a new package "GFdisplay" by the end of tomorrow. Then I have a couple of days of family stuff to see to, but I'll be ready to have a proper look at any problems at the weekend, or shortly thereafter. In the interim version of FSUIPC which I'll be uploading here (check announcements) there will be extra logging for button programming. I've had to add it to help with GFdisplay programming. Maybe this will help resolve your problems too, or identify the bugs more exactly. Well, the only thing I can think of it to have that button also programmed to Repeat with an Offset Byte Increment control, adding 1 to a free offset in FSUIPC (66C0-66FF are available for general user application). You'd have an offset test condition for the byte to get to a certain value, then do something different. if the repeat rate is reasonably predictable that should do the trick. In other words something like: 100=B66FF&C0=0 R1,1,Cxxxx,0 ; Your main initial control repeated till 66FF >= hex 40 101=R1,1,Cx110066FF,x00400001 ;Increment 66FF on each repeat till hex 40 102=B66FF&C0 R1,1,Cyyyy,0 ; Your different control after n seconds 103=U1,1,Cx010066FF,x00000000 ; Reset count to zero on button release You'd have to adjust this for timing. Incrementing Byte 66FF by 1 on every repeat till it gets to 64 (hex 40) will only give 5 seconds if the repeat rate is somewhere close to 12/sec. Unfortunately this won't work with the current FSUIPC because I found a bug in the offset condition testing. Strange no one reported it. It is fixed in the version I'll release here soon. Regards, Pete -
Registration problem
Pete Dowson replied to wild ol' dog's topic in FSUIPC Support Pete Dowson Modules
I never saw it. According to the records here, the message you sent earlier was the first and only one from you in the whole set of Simflight forums! Maybe, if you had your private key and email showing in the graphics it was deleted quickly by the forum administration. It is strictly against all the conditions to publish these details for others to use. If you send me an email attaching the notification you had from SimMarket I will check the Key here. Send to petedowson@btconnect.com. I should warn you that in the 18 months this system has been operating, virtually all cases of keys being rejected have turned out to be because of incorrect entry of the details. I notice that you say: but you don't mention the name and Email details -- they too must be absolutely exactly the same as in the notification email. Did you cut and paste those too? All I can do is check that the details in the original email are self-consistent. The rest is up to you. Regards, Pete -
Using POV hat buttons with FSUIPC
Pete Dowson replied to David Cox's topic in FSUIPC Support Pete Dowson Modules
Hmmm. that's strange. Is this when the PMDG aircraft in question is loaded, or another? I think, logically, if the current aircraft is the PMDG 737-700 then, since all of the above actions are for button 0,0, then none of the entries 24-28 should work. They should be completely ignored in favour of that button's programming for the active aircraft. On the other hand, if the current aircraft is not PMDG 737-700, none of the section so headed is even loaded by FSUIPC, so that should have no effect on the general part at all. Can you clarify please? Also the U stuff. It certainly should be. If there's a problem there, it's a bug, and I'll need to fix it. But first I need that clarification. Then I need to boil it down to the simplest reproducible case. I don't provide those, PM does. All FSUIPC does it toggle the bits PM tells me about. What exactly takes 3 seconds? Just incrementing/decrementing by 1? There's a problem there somewhere if so. It's really a question for the PM team I suspect. I must admit I am rather disappointed at the speed of reaction of the PM MCP to most of the offset controls it supports. It seems to have got slower and slower as more things have been added. I think the main concentration these days is supporting hardware MCPs directly connected, like the Aerosoft, CPFlight and PFC MCPs (all connecting by COM port). It's fine then. Maybe you can change its cycle time to make it look more often (see the MCP.INI file). Are you running the PM MCP on the same PC as FS? I've always found that's best. The MCP is the hub. As I say, all FSUIPC does it toggle or set a bit (it varies form control to control) in an offset. the rest is up to PM. For PM use, of those, your best bet is CPflight I think, but ask on the PM forum. Go-Flight at present don't support PM directly (it can be done via FSUIPC and a new program I'm working on now). Aerosoft don't make their MCP any more. The PFC one is really super but probably over the top (too expensive) unless you are very serious or very rich. Many PM users seems to be using the CPflight stuff. Regards, Pete -
Neither EPICINFO nor FSUIPC normally have anything to do with EPIC (or any other) axis inputs. Axis inputs go direct from EPIC through Windows to FS. You need to check first whether Windows recognises them as correct axes (in Game Controllers), then make sure they are correctly assigned in FS (Options-Controls-Assignments). Make sure that the sensitivities in FS are at maximum and the null zones at minimum or close. Don't try calibrating in FSUIPC until they work in FS. Incidentally, having an aileron trim axis is an odd selection if you are only connecting five axes. Shouldn't that be elevator trim, which you do need all the time? You'd only need to change the aileron trim in cases of aircraft damage or asymmetric thrust. Regards, Pete
-
Registration problem
Pete Dowson replied to wild ol' dog's topic in FSUIPC Support Pete Dowson Modules
Sorry, I'm lost. I see nothing else from a "wild ol' dog". What question was it and when did you ask? Is there a thread about it somewhere here? This seems to be the only message you've ever posted, anywhere in SimFlight forums. :? Regards, Pete