Pete Dowson

You should really read it and OR bit 3 in, in case other programs or add-ons are using the other bits. In other words: ipc.writeUB(0x310A, logic.Or(ipc.readUB(0x310A),8)) However, even so ... Sorry, this makes no sense to me and it isn't reproducible here. I need more information. Please enable IPC write and Axis logging, and also Monitor 310A ("normal log" selection, type U8) to the log, and show me the log fragment relating to this. Regards Pete

Great! Do you think what you've done might be useful to others, even if only by way of a learning experience? If so, perhaps you'd like to post a copy with a few notes on the "User Contributions" subforum? Thank you for the feedback anyway! Regards Pete

Okay. That should be okay, but it might be a good idea also to try the very latest interim update. It will be 4.637 or maybe 4.638 -- get it from the Download Links subforum, Updated Modules. Regards Pete

And thank you too, for your appreciation! Regards Pete

The main thing is to make sure all PCs are in the same WorkGroup. Don't take it for granted that they are. If they are you DON'T NEED ANY INI FILES. The defaults WideFS generates will suffice. This only applies if all PCs are on XP, Vista or Win7, mind. If you are still using Win98 or (horrors) WinMe, then you have to add parameters to the Client INI file. Here you say: but you don't say what file it is. WideServer.INI or WideClient.INI? If Server you do NOT need the ServerName=Main-PC line. If client then if you have that line for some reason, then you MUST also have the Protocol specified! These things are in the first few lines of the User Guide section called Configure your Network . There's no large manuals to read, just a couple of paragraphs, pointed out by red text!! Much faster, in fact, than posting here and having to read the reply some hours later! In future, if you have a problem please show the LOG files which are always much more important than the INI files (which normally contain only defaults which of course I know). Also, for WideFS, always remember there are TWO ends to a connection, so showing details about one end only is half the story, and an unknown half if you don't even say which it is! Regards Pete

Sorry, there's no published protocols. I think I did suggest ways of assisting someone many years agao to implement something on different machinery, but I don't know if it came to anything, and that was so long ago I wouldn't be able to locate the details. WideFS and its protocols date back to 1994 or so and have become rather obscure even to me. I'm afraid the work of documenting them sufficiently for others to implement to would be far too much for me. It would actually be far easier for you to write a Lua plug-in using the Lua sockets library, as a direct interface into FS via FSUIPC. There is a example provided already in the Lua plug-ins Zip of a Client-Server link between two FS installations using such a technique. Ah, but it's really always been a hobby rather than a job, and who counts hours spent on a hobby? ;-) Regards Pete

No, it was certainly added by then. Sorry, I have no explanation. It gets the GUIDs from the registry. Why not, in your case, I do not know. But things have come a long way since 3.98a and I don't want to spend time finding out why if it seems okay with my current version. Thanks. Pete

This means that whatever you are pressing is simply not amenable to such methods. The mouse macro method relies on a specific way, which was once standard in add-on aircraft, of programming gauges -- this is for C/C++ gauges written using the Microsoft gauge SDK. Although Microsoft themselves did not use it for the default aircraft, many FS8 and FS9 developers did and it works for those. However, since FS9, and much more so in FSX, there are other ways of writing the gauges for aircraft, usding XML, which is a type of scripting language. In FS most of the default aircraftas are written this way, and more and more add-ons now. These are simply not amenable to the mouse macro way of assigning, and never will be. There may well be alternative methods using Local Variables ("L:vars"). These are named variables declared and used inside the XML gauges. When these are discovered thery can sometimes be written to, via FSUIPC macros, to change settings, switches and so on. There is some data about Lvars in the FSUIPC documentation, but I cannot say that discovering and using them is an easy process. You can make FSUIPC log them, and there are Lua plugins provided which will log changes so you can see how they operate. [LATER] I just noticed: There is a user contribution about the PMDG MD11 in the "User Contributions" sub-forum. Have you checked that? Pete

Use the FSUIPC SDK. If you've written it to interface to FSUIPC, it will interface via WideFS automatically. There doesn't need to be one because all WideFS does is extend the published FSUIPC interface to client PCs. That's the whole point of it! Regards Pete

Probably the version actually running is before the GUID check was added. Check the Log. What version does it say at the top? There's a version 3.989m available in the Download Links subforum. You might want to try that. Pete

Whereabouts in Simmarket are you getting this earlier version? There's only one proper location for the main releases, over on the "Dowson" page on www.schiratti.com. I'll have to tackle Simmarket it they're publishing someplace else now. Regards Pete

I don't understand what you mean by "no functions are there any more". FSUIPC will not delete your assignments. Do you mean that there's no response from your devices that you can see in FSUIPC? The usual reason for losing operations from devices is the Windows power management setting -- go into the Control Panel -- system -- Device Manager, find the USB hubs listings and in the Properies of each ensure that the power management option is disabled. Also, please make sure you are using recent versions of FSUIPC -- not earlier than 4.60 -- as some earlier versions did time out responses from devices. By the way, why mention specifically the LVD 767? Are you implying that the same doesn't happen with default aircraft, or others added? If this is the case then the answer must lie in the LVD 767 code. Regards Pete

Ask me a again in a week. Tied up this week. My main difficulty is that on the only PC I have with two screens not using Matrox TripleHead2Go to make it look like one screen, FSX simply won't run in full screen mode -- crashes every time. So I can't test it at all at present. Next week I'll have to think about moving a screen to another PC, or maybe my laptop. Pete

Evidently you missed reading the Installation and Registration instructions within the ZIP, or somehow didn't even see the Cancel button? There's no other reason you "can't get past" -- that makes no sense whatsoever! Never heard of a yoke brake, but I do not support Saitek and cannot recommend them. You'll have to ask them what they are on about. Pete

Thank you for your appreciation of my work! Regards Pete

Where do you (mis-) understand this from? There is only one version of FSUIPC3 (for FS9 and before) and one version of FSUIPC4 (for FSX, ESP and Prepar3D). What facilities each offers depends on whether you pay for a Registration key or not. The facilities you pay for are documented in the User and Advanced user's Guides which you can read for free as they are installed when you install FSUIPC3 or 4. Pete

Because patterns of bits in encrypted files are different according to what's in the file! If all files contained the same data you'd only ever get one program, wouldn't you? Think about it for a few seconds! Different programs contain different things, that's what makes them different! Different VERSIONS of the same program will look different too, but whether sufficiently different for your virus checker is another matter. I repeat: there is no virus, it is a false result -- you really should tell the virus check folks. That's the only way they ever improve things, by feedback. It happens spasmodically with different files and different virus checkers. This is why any decent virus checker will allow YOU, its user, to override it when you know better. All the virus check programs I've ever used do! Regards Pete

What "doesn't work" about it? The link doesn't download anything, or the contents of the ZIP can't be used because of your virus check? If you mean the link still downloads the wrong thing, then your cache needs clearing. The link is perfectly okay. It downloads a ZIP containing "WideClient.xxx" for you to rename. Pete

PMDG have used the same Gauge and DLL coding for each model -- I think only the performance, loadings etc change for the NG series they've implemented. The iFly 737 series may be different? Have they got different gauges for each model? You can tell by comparing the Gauge names in the PANEL.CFG files. Maybe some of the gauges are common and some aren't. The "mouse" macros generated by FSUIPC rely on finding the correct place within the actual gauge code to call to perform the required function. Two different gauges only need to have this location one byte shifted in either direction and the known address to be called no longer applies. In such cases the only way is to make new macros. You may have to have more than one "iFly" profile. Regards Pete

Well they should be notified of false positives. Both built with the same tools on the same Pc, but both a compressed and encrypted. There's virtually no true code for the checker to check. It's just seeing patterns in the gibberish. No. You must have clicked the link whilst I was still editing it! Please do it again. It only contains WideClient.xxx for you to rename. Regards Pete

All new questions should be in their own thread. These aren't "topics" but "threads" -- exchanges between usually two people, maybe others jumping in to help or confirm things. But adding you own queries to an existing thread which may or may not have some similarity is just confusing. Sometimes people have added something to a long dead (months or even years old) thread saying basically "me too" to a problem that was long fixed. It's okay to look for similar threads to see if you can find the answers, but if not then there's unlikely to be anyone else with exactly your question in any case. The documentation does actually contain a LOT of information on joystick calibrations, so you should not have any problems or questions in any case. Everything you mention should be a doddle. Pete

It can't be the same -- 6.833 was withdrawn in favour of 6.834 the other day. Or do you mean 6.834? You need to get your virus checker updated, or change to a better one. It won't make any difference. Your virus checker will block it in any case. Possibly renaming it other than an EXE might work. You'll have to rename it afterwards. Try WideClient 6834 renamed Pete

Yes. That's what this says, isn't it? Each time any button is pressed (goes from off to on) FSUIPC4 toggles its flag. (third time! ;-) ) Not if you only want to use the button flag owned by that button, else it would be done twice and you'd get odd results of course. Besides which, using the parameter of 0 with control C1005 would toggle button 0 flag which you aren't using in any case! As I already explained. It's for setting something which you can test elsewhere, like a memory. That's what flags are for. But your main mode buttons are actually held "pressed" ("on" is a better term for such switches) by virtue of the switch position, right? So no need for flags there. I assume you are talking about button 16? It is clearly stated in the documentation too (in the main User Guide in fact). Aircraft or Profile specific assignments for the same buttons or keys take precedence over generic assignments when that aircraft is loaded or a profile is in operation. It would be rather stupid for them not to, causing all sorts of confusion with double actions, don't you see? Sorry, what IS the problem? You forgot to say ... In your later post: "Workaround"? Workaround for what? You still haven't described a problem! :-( If you want things to operate for all aircraft you put them in the generic section. Anything in a Profile will override assignments for the same buttons in the generic section. Think about it -- there's no other way it can work. Pete

Ah, so the "middle" button is used only when one of the 3 main modes is selected, so giving you a toal of 4 sets, not 3 or 6? If it's intended as a mode selection, than of course that is exactly what you want. Each of its three positions is "pressing" (turning "on" is a better notion) a particular button. As long as it isn't constantly turning it on and off, that's fine. Why wouldn't it work. The condition "(+0,25)" is TRUE if button 25 is on, or pressed. Now it gets confused again. Are you meaning that when you say as you did just above, that the button press of 23, 24 or 25 is momentary? You seem to be contradicting yourself. The mistake of assuming "momentary" when, as you stated, it is anything but? In your Button assignments: Why have you still got a Flag value here instead of the simple button pressed state? A 'true' (+) flag value will only operate on every other time you set 24, because the button flags toggle on every press (press = change from off to on). 5=CP(F+0,24)0,15,C65615,0 6=CP(F+0,24)0,14,C65607,0 And what on Earth are all these flag toggling controls for when you aren't using button 0's flag anywhere? 10=P0,22,C1005,0 12=P0,20,C1005,0 19=P0,21,C1005,0 27=P0,16,C1005,0 28=P0,19,C1005,0 If buttons 16 and 19 are real buttons which you press, why are you using flags here? Are you wanting alternate actions each time they are pressed and released? 29=CP(+0,25)(F-0,16)0,14,C65651,0 30=CP(+0,25)(F+0,16)0,14,C65652,0 31=CP(+0,25)(F-0,16)0,15,C66455,0 32=CP(+0,25)(F+0,16)0,15,C66456,0 33=CP(+0,25)(F-0,19)0,17,C65653,0 34=CP(+0,25)(F+0,19)0,17,C65654,0 35=CP(+0,25)(F-0,19)0,18,C66457,0 36=CP(+0,25)(F+0,19)0,18,C66458,0 What strange conditional issue? Sorry, you've lost me again. Er, no. That is really nonsense, sorry. If the parameter is 0 then it toggles the button flag for joystick 0 button 0. The computation 256*j + b is so you can get the parameter correct to operate that particular button flag. How would the C1005 command know which button flag to operate if you didn't give it a proper parameter? But it works DESPITE these lines 10=P0,22,C1005,0 12=P0,20,C1005,0 19=P0,21,C1005,0 27=P0,16,C1005,0 28=P0,19,C1005,0 which will do nothing whatsoever for you if you have no conditions testing button 0! All those are toggling button 0's flag, nothing else at all! You seem to have not read the part of the manual I even quoted to you in my last message, espevially the part I deliberately put in red! I'll repeat it here: For every possible “normal” button (16 joysticks x 32 buttons = 512 buttons) FSUIPC4 maintains a “Flag” (F). Each time any button is pressed (goes from off to on) FSUIPC4 toggles its flag. This makes the buttons flag a sort of “latching” switch. Please please please READ this again. What do you not understand? The button flags operate AUTOMATICALLY every time you press the relevant button. You do NOT need to control them. The only time you need to control button flags are when you need flags NOT operated by real buttons!!! Actually, I'm rather hoping they read further and not get as confused as you! ;-) Regards Pete

Phew. Much easier to use profiles, or even just using the "ShortAircraftNameOk=substring" facility so you can use shortened names for all aircraft with similar names, like "B737" to cover all of those. There's a Chapter on Profiles in the User Guide, and an Appendix giving detailed instructions, supplied by a user, for using short names. Is the other aircraft the same identical aircraft except for livery -- i.e. all the gauges you are covering in macros are the same? It's the same Aircraft.CFG? If not, you'd need to generate new macros because the code being called wil be different. If it's the same aircraft however, it should work unless you used the wrong name from the Aircraft CFG file. Best really to create an aircraft-specific section automatically via FSUIPC before copying other assignments into it. Then you know the name is correct. Better still to use an appropriate abbreviated name and only have one section in the first place. You can easily check what is happening when you press your buttons by enabling Button logging (FSUIPC options, Logging tab), and looking in the FSUIPC Log file after pressing them. Regards Pete