Pete Dowson

Unless there were no button events, it looks like you only logged AXIS events, not the normal Events. There is no sign of any spoilers axis being operated in this log. So, if during the period of this log the spoilers deployed by themselves, it isn't an axis control which is doing it. You need to log the normal (button) events, because there are FS key controls for operating the spoiler too (those assigned to / and shift+/ I think). Please don't start a new log next time. Don't touch any of the buttons in the Logging tab, only check the logging options needed -- the three relevant ones are: Buttons and keys, Events (non-axis) and Axis controls. Pete

You started a new thread, so lost all of the context! Please stay in thread, don't start new ones except for new subjects. I've merged them now so that things can be clearer. "All" my advice?! The only things I asked you to do was test on a different aircraft to make sure it wasn't something to do with a particular aircraft, and also to enable event and axis logging and show me the log. If YOU want to analyse the log instead of showing it to me, that's fine, I'll leave you to it. Look for "spoiler" commands. They'll be in English, like "Axis spoilers set" or "spoilers set" or something else with "spoiler" mentioned. Er ... if you are disconnecting and reconnecting joystick devices you may be generating lots of problems for yourself. Every time you do that Windows may assign different IDs, so the numbers used by FSUIPC (the 0, 1, 2, 3 in the Axis assignments, for instance) could change. If you are going to do things like that you will want to use the Joystick letters in FSUIPC instead of the numbers. Please see the Chapter in the User Guide about "keeping track of multiple control devices". It's listed in the Contents. Worse, each time FS sees a newly connected device it is likely to make automatic assignments, even if you've previously deleted them. That's why we first need the logging. We don't even know if it's a button control or an axis operation doing it yet!!! Regards Pete

Okay. That helps. Probabably if I parse the string "M.f" and step down through tables it will work. I'll try it and let you know. So if it doesn't know that "f" is in "M" how does it know to use the string "M.f" in the event function? No, it's my code. I'm calling a function called "getglobal" which takes the name and returns the function pointer for me to call. "M.f" is not a function name but a table name (M) and a function name "f". I think it's just that the getglobal call doesn't parse the name to separate table pointer and content. I'll need to do that in my code I think. Unless you put everything on one line, surely the line number is a BIG clue? I use "ultraedit32" as my editor and that provides line numbers. Regards Pete

Sorry, I don't understand. You seem to contradict yourself. You can see your plane and traffic (in what?) but yet you say there's no data? Plane and traffic positions are data. Please clarify. Perhaps you are talking about scenery data which Plan-G has to read directly from FS, nothing to do with FSUIPC or WideFS? Check its documentation -- you probably have to share some folders, or maybe run a program on the FS PC then copy files across. I don't know the program I'm afraid., but i know you have to do that with programs like FS commander. It doesn't really have any meaning. You should be using supported versions -- at the earliest those available on the Schiratti download site, but there are usually later versions in the Download Links forum here (much later at present as this year's updates haven't been finalised for the Schirati site yet). No. I've no idea why you have had a "great deal of trouble". The only trouble so far has been the firewall, which is a Networking problem not a WideFS one. You've not given any information about any other problems, yet. Pete

Hmm. I don't (yet) know how to do that. At present the procedure is obtained by using the C function "lua_getglobal". This references the globals index by LUA_GLOBALSINDEX. Evidently that doesn't contain all the names in modules even as a list named for the module, or if it does just using "getglobal" with the string name "m.fn" doesn't cut it. I've had another read through the relevant sections of the Lua books I have and I don't think I understand the internal data structures well enough to know how to implement it. Obviously the interpreter must know where "m.f" is but how do I call it from C code? The lua_pcall function needs the function pushed onto the stack. I get that using lua_getglobal. Do you know how to make that work with functions in a module? What happens if you define local names for the functions in the module, like myf = m.fn and then use "myf" as the function. Does that work? Maybe I have to parse the string to separate "m" from "fn". Then get "m" as a global, check that it's a table (lua_istable) and then, if it is, see if I can access the field in it named "fn" and check that's a function. I might experiment on those lines. Of course it could go further. "m.t.fn" there t is a table of functions in module m. Et cetera. I'd have to keep going whilst I found tables till i found a function. Hmmm. But that makes no sense. If you know "f" is a function in "M" then you can call it from a local function in the main program. What's the difference between doing that and making it a literal string in the event library call? Either way the main program has to know that function f is in module M. I assume you don't mean the FS modules folder? ;-) Regards Pete

No, they should be entirely independent. I'm not sure what's happening. I had a similar test setup and it worked exactly as it should. Something must have got changed more recently. I'll check it out in the morning at let you know. It is getting late here now and I'm tired! {IN THE MORNING] Okay. Found it. Stupid typo in an unrelated section of code, overwrote the ID and gave all Lua timers the same ID. Grrr! It'll be fixed in 4.662, later today. Regards Pete

Yes, that's good, but the ipcPARAM value might change whilst you are in the procedure, if another button is pressed, and then the event will trigger after you exit for the same value. Really you should use the parameter supplied -- that is why it is supplied, to make it easier in any case. i.e. function Test(param) if param == 1 then ipc.display("parameter 1") elseif param == 2 then ipc.display("parameter 2") end end event.param("Test") Rehards Pete

Do you mean "ERJ145.mcro"? If it is "...mcr" then that's the problem. It needs to be mcro. As I asked before, is the name listed in the [MacroFiles] section of the FSUIPC4 INI file? At present my only guess is a corruption in the INI file which is preventing the macro listings. But I can't see the file from here. Maybe you could just paste the complete thing in a message here so I can check it for you? As above, as in my previous reply. Regards Pete

Sounds like you are using the Windows joystick number IDs to identify the joysticks on which your buttons and so on are programmed, and then have disconnected or reconnected them, or connected some other USB device, and this has resulted in the ID numbers changing. I added facilities to handle such changes automatically for you -- there's a chapter on it in the User Guide. It involves using letters instead of the ID numbers, and then FSUIPC automatically matches things up by reference to the device names and "GUIDs" it records in your INI file. Sorry, I don't understand this bit. You are saying the macro files are in the FSX Modules folder, yet not listed in the dropdowns, at all? I really don't know how that could happen. Are the files listed in the [MacroFiles] section of the INI file? Maybe something in that area has got corrupted? Sorry, I've really no idea what's going on there. What sort of names are you using? There's a limit on the lengths of both macro filename and individual macro name. What version of FSUIPC are you using, by the way? You might want to try a later one just in case. Version 4.661 is available in the Download Links subforum. Regards Pete

Yes and yes. But I wouldn't expect any change. You'll need to do some logging. Also check on different aircraft -- the default 737 for instance. It might be something in the aircraft code. Please paste text into messages here instead of trying to attach or post links. You can use the code quotes ( <> above) to delineate them. Regards Pete

It can only be one of three things: 1. You are getting the wrong port number 2. The driver is no good. I had great difficulty getting decent drivers for those cheaper adapters, expecially 64-bit ones. You could check the FTDI site. Most adapters use their chips/. 3. The adapter itself is broken. I gave up on those adapter things. Even when you get one that weorks they start playing up after a while and become unreliable. I invested in a BrainBoxes PCI serial port card. Perfect. Good drivers, reliable operation. They cost around 10 times as much (50 UKP rather than 5-10 for an adapter), but it's been well worthwhile for me. Regards Pete

You have Joystick 0, Axis R assigned to the Spoiler. The ailerons are on joystick ID 3 axis X, so I doubt that there's be any cross-interference there, which only leaves assignments in FS9. Have you tried disabling the joystick rather than only unassigning? Enable axis and event logging in FSUIPC's Logging tab, see what controls are occurring. There's a much later version of FSUIPC available in the Download Links subforum too. Regards Pete

Your account seems to contradict itself. Which of these is true? 1. Your computer freezes as soon as you plug GoFlight USB modules in. Or 2. The computer crashes when you run FSX and enter the FSUIPC buttons and switches tab. "Freezing" is not "crashing". If the whole computer crashes or freezes and you have to power off and on again (reset) then there is most certainly a driver level problem. Try uninstalling the GoFlight software and downloading and installing the latest. For GoFlight kit FSUIPC uses the GoFlight driver called "GFDev.dll". Make sure that is installed and is correct for your equipment. There is a recent one of those provided in the Download Links subforum here. FSUIPC itself is not capable of bringing the complete computer to a freeze or crash. You might also want to try updating your FSUIPC4 to the latest version, 4.661, also available in the Download Links subforum. Regards Pete

Thanks! My favourite! Drinking it now! ;-) Pete

Well you most certainly have the same axis assigned someplace. Show me the [Axes..] sections of your FSUIPC INI file and I'll check. Have you only deleted assignments in FS and not actually disabled the controllers? It is easy to miss one, and FS also has a nasty habit of automatically reassigning things. BTW please always mention things like version of FS and version number of FSUIPC. Pete

What software are you trying to talk to? There's only one ATC-related PTT support provided in FSUIPC -- the one actually called PTT. The other is for "PVT" the private talk line.for SB3/4. There isof course a pair of controls for each -- one for on the other for off. With a PTT button you program the "press" to turn it on and the "release" to turn it off. If the mike appears to be held open you've not done the latter. The idea is that you hold the button down whilst speaking and release it when you are done. That's why it is called "Push To Talk" (or "Press To Talk" if you like). Pete

Okay. Thanks for letting me know. If they want any help from my end I suppose they'll be in touch with me? Regards Pete

Show me the FSUIPC4 log file from the FS Modules folder. There are separate keys for WideFS and FSUIPC. You need to enter both in the same install, by selecting 'both'. Why did you enter them "a few times"? Did you make sure to use the correct name and email, to go with the Keys? There is absolutely no difference in registration for Prepar3D from FSX or ESP. It hasn't changed. Pete

Yes,. You need not only the key but also the original name and email. These details are in text form in the FSUIPC Key file, in the FS Modules folder. Also you can always retrieve your key from your SimMarket account. You are posting in the wrong Sub-Forum, by the way. I'll be moving this thread to the support forum in a few hours. Regards Pete

You might not have noticed its date, but Version 4.60a came out long before Prepar3D so it could not possibly recognise it. The first installer and FSUIPC version which copes with Prepar3D is 4.638 which is available in the Download Links subforum here. Where did the Prepar3D support folks point you to? Surely not the current release version on the Schiratti site? I am slowly working through the documentation updates which will enable me to put together proper new full releases for the Schiratti site, but meanwhile there are always lots of interim updates posted in the subforums here, where I can control things myself rather than have to ask Enrico each time. Regards Pete

The router one shouldn't be interfering, but don't forget that XP, Vista and Win7 firewalls are active by default. If you can't figure it out, do let me see the LOG files I mentioned. And try ensuring the the Workgroup names match -- XP has a different default workgroup name to Vista and Win7. Regards Pete

Well the best way is to browse the user guide and see if it offers enough to be worth it to you. For FS9 I think the wind and pressure smoothing in FSUIPC does a good job for any external weather source, complementing the settings in ASE. But ASE is pretty good in its own right. I can't really comment on REX as a weather controller I'm afraid. For FSX the weather filters in FSUIPC4 aren't quite as effective -- FSUIPC4 has to work through SimConnect just like ASE, and in fact they are operating in parallel so the one cannot actually filter the other. In FS9 ASE is controlling through FSUIPC so the filters can work more effectively. Only that there are more of them -- more options to choose from, more precise calibration, and capabilities like having different assignments, different settings, for different aircraft. But if you are happy as you are I wouldn't try to force you. FSUIPC is a tool. If you need to use a tool, you use it. If you don't, you don't. I don't see any point in buying a tool just because it's available. You have to decide for yourself what you need. Need? I don't think anyone "needs" such things per se, it all depends what you want to do. Regards Pete

I just looked on SimMarket's website and on the FSUIPC4 purchase page there is most certainly still a big yellow box in red surround telling you about the bundle. How can you not see it? Regards Pete

I don't think they would be pressed at the same time, but in sequence. To send a sequence like that you'd have to either make a multi-lined macro, or edit the FSUIPC INI files to make multiple assignments to the same button. You can't do that in the Options tabs, unless for a sequence of 2 only you do the first character on the 'Press' and the second on the 'Release'. If you only need the two, that might work. However, there may be a much better way. Enable Event logging in FSUIPC, on the logging page, then press 5 and one of the views. Check the log, see what was sent. Then you might be able to assign the relevant controls directly. There are view selection controls.If you are talking about FSX there are direct controls for cameras 0 through 9 ("VIEW CAMERA SELECT 0" ... etc). In FS9 there are "VIEW AUX 0 ..." contorls, but I don't know if they do anything. Regards Pete

WideFS has two parts -- the Server and the Client. The Client is the same for all versions of FS, from FS98 through to FSX. That is currently 6.78 on the main release site, with a later one (6.841) available here in the Download Links subforum. The WideFS6 / WideFS7 difference is to distinguish the Server end, which is the part you purchase a license for. On FS9 and before, the Serving is performed by WideServer.DLL which is now up to version 6, whilst on FSX and ESP (and Prepar3D) the server functions are instead incorporated into FSUIPC4 and go by the version 7 label for purchasing purposes. FSX not only has to be installed but also running, with the WideServer registered and enabled. You didn't to read the advice about getting your workgroup names the same, then? If you do that you've really no need to edit any INI files. The connection should then be automatic provided your firewalls allow. If you do provide the ServerName or IPaddress details you must also specify the protocol (Protocol=TCP or Protocol=UDP). For automatic connection both 8002 and 9002 are used. On both PCs. Did you try disabling the firewall on both PCs just to check you had these "opened" correctly? I thought firewalls worked by stating which programs were allowed to breach them? (FSX.EXE and WideClient.exe in this case)? I've never used any firewalls outside the one on my router as they are always a real pain in a home network. For any further help I need to see the Log files: FSUIPC4.LOG and WideServer.LOG from the FSX Modules folder WideClient.log from the folder in which you placed and ran Wideclient. Just paste them all into a message here. Please make sure both FSX and WideClient are closed down first. Pete