Pete Dowson

Sorry, I'm confused. 1. I have no idea if your "mode change" (whastever that is) is even detectable. Certainly unplug/replug is detectable. what is this "mode change"? 2. What is the HID part if not part of the Lua script? By "stops working" what do you mean -- no hang, no crash, only zero returns or something? Maybe the mode change makes it report differently? Maybe it somehow closes and reopens the link, so you have to too? Pete

Not at present. In fact I can't offhand think of an easy way to do such a thing except via Lua. Well, not really. If I implemented such a thing (which isn't easy) it would probably be just as messy, with interlocks on offsets and so on. Pete

Yes, that's quite possible. I never designed any of it for hot plugging/unplugging I'm afraid. I'd have to add more code for that. What would you expect to happen, just zero returns to all the calls? Pete

If I provided a way in Lua for you to relate joystick names, GUIDs, VIDs or PIDs to the FSUIPC joystick number, would you be able to move to using the joystick interface instead? The names and GUIDs are actually available in the FSUIPC INI file of course, but it would be easy for me to return these given the unit number (0-15). Alternatively I could get the VID and PID hexadecimal numbers instead. The problem of course is then multiple POVs and more than 64 buttons. To extend that for FSUIPC general assignment would be a nightmare, but it might be possible to do it for Lua access. I'd have to check. It might actually be best to implement a new "joy" Lua library -- so not an immediate project, just one I could think about adding. Hmmm. Pete

I agree, because the discard figures show as much. If it was catching up with a backlog I'd expect those to be much higher. I guess something much lower down in the heirarchy is discarding stuff before FSUIPC if there's only 1-2 discards for a 500 mSec delay! Sorry, I'll keep thinking and looking but I can't hold out much hope. Regards Pete

Ah, shame. Did you see my amendments, about separate threads? I've been looking at the code for ReadLast, and there are no delays or sleeps. It doesn't actually do the "reads" itself, all serial port reads are done in separate read threads, one for each device, which simply loop reading when there's data. Those are high priority threads, and work well for all comms devices not just HID. So I don't think there's any inefficiencies in my code. I think this seems to be confirmed also by the low number of discards you reported. If the devices are sending frames at 10 mSec intervals, the worst case of 2 discards should only mean a max delay of 30 mSecs. I will try digging a little deeper, but I think this is looking to be a Windows thing. This method of handling devices just isn't so good when they are jittering. The regular joystick drivers are working at a lower level and presumably bypass where the bottleneck is occurring. Regards Pete

I just realised (and re-reading my own OpenHid documentation) that the default Report ID is actually 1, and there's a comment in the "hiddemo.lua" saying "I *think* all joystick types use Input Report 0", so it would be worth your while trying CurrentData, n = com.readreport(jdev, 0) Or more generally CurrentData, n = com.readreport(jdev, Report) because, at least in the version of the Lua I supplied, "Report" is set to the correct Report number at the top of the program. I'm just trying it here ... The other way of speeding things up might be to have separate Lua threads for each device. The problem with only having the one trying to handle several devices is that whilst the thread is running it won't receive more timing events, and lost ones are lost. I don't queue events. If you wanted a central control, to determine connected devices etc, you could have the one Lua running the others (by RunLua) but you'd need to have each with a unique name as FSUIPC only allows uniquely named plug-ins to run together. Maybe there's a requirement for a plug-in to be able to spawn separately threaded copies of itself. There are some threading facilities in Lua, but I doubt they work in FSUIPC's environment (not tried them), and in any case that wouldn't deal with the event reception issue as it would only look like one to FSUIPC. Regards Pete

Until I see it. You posted this (twice) at 3:09 am my time. I was here checking at 08:30 am. Do you have a post with any other question in it? If so I must have already replied, or you posted in a different place by mistake, because the only two from you are these two identical ones (I've deleted the other) asking how long .... Also, you added this to someone else's thread instead of starting your own. That makes it far less noticeable because it won't move the thread to the head of the list. Pete

Unless the versions you downloaded were different from the ones you had installed, I can't see how reinstallation could have made any difference. FSUIPC certainly won't run if it is corrupted (it uses the Windows digital signature system to check that). Regards Pete

Yes, though "required" is too strong. That is only used to do an initial 2readreport" to provide initial settings for toggle switches and axis positions, if the device cares to provide such things. Possibly because the device doesn't support readreport -- it is optional. Shame. it would have been a quick answer if it had worked. I'll have to think more -- but it'll be next week. Regards Pete

It represents the size of the input report. It varies per device. I've seen as short as 2 and as long as 40. Of course not. You missed the definition of this in my earlier message? The "readreport" function doesn't use a length -- you get the fixed length it provides, and like it! The second parameter is a Report ID. It's a guess. I think most devices use 1. Some devices have multiple report types, for instance for calibration data stuff like that. Pete

What report ID are you using? Maybe it's not 0 but 1? Regards Pete

This is why I added the "readlast" function, which takes it out of slow scripting and puts it into a fast C loop. I'd like do be able to do it all in one read, but it seems the HID code in Windows doesn't like that so I have to loop reading the input report size instead. Still, it should be fast in C, and it's in its own thread. Maybe, conscious of affecting FS performance, I yield too much in the loop. I doubt it, but I'll check. My normal yields are by "sleeps" of 0 or 1 mSec. Which should be fine. Regards Pete

I've just noticed that I implemented a different way to read the HID data -- "ReadReport". data, len = com.readreport(devicehandle) for report ID 0, else data, len = com.readreport(devicehandle, id) for other report IDs. When testing here they didn't appear to work correctly (it calls the HidD_GetInputReport function in Windows). So i left it out of the documentation. But try it in place of "com.readlast" and see what you get. I won't have time to test it till the end of the week. Regards Pete

Well, let me see if I can sort out the HID method first. Sorry I can't get to it straight away. Yes, it's a registry thing, and different between XP and Vista/Win7. No, currently the buttons are only extended from 32-39 for the first Hat (POV). FSUIPC4 supports two POVs for axis assignment, but FSUIPC only has the one. This is because FSUIPC3 uses the old "joy" API whilst FSUIPC4 uses DirectInput 8. Only later DirectInput versions supported 3 or more Hats. We'll see if we can make it work better. Regards Pete

Not sure how it "chokes". It simply does normal serial port reads. Maybe yu need the "GetInputReport" method for such devices, but when I experimented with that it didn't work well at all for fast polling (i.e. for smooth axes). I don't know. I'll have to think about it. Sorry, though, no time this week. Can you prompt me again next week? No. The HID facilities are bypassing all Windows joystick interfaces, drivers, everything. They are reading the raw data on the wires. If all you want is buttons you'd be better off using the normal routes. The HID facilities in Lua were for taking advantage of features not otherwise supported -- like many more buttons, many more axes, and even control of displays if you can decode the specific protocols. Regards Pete

Check with support for the VATSIM program you are using (Squawkbox or FScopilot./FSInn?). The button or key programming and action in FSUIPC is no different for PTT than any other assignment -- the request will simply go directly to the program responsible. So it will be some consequent behaviour in that area. Regards Pete

Out of memory errors in FS are almost always due to faulty sceneries or other similar add-ons with memory leaks. I think there are one or two quite well known causes. Best to ask in the FSX forum. It won't be at all related to FSUIPC4. Regards Pete

No, and it is not necessary in any case. It is never used as an email address, but only as a way of uniquely identifying you -- names alone don't do that. Regards Pete

They are needed if the Broadcast's aren't getting through from the Server. This could be down to any of these reasons: 1. Something else is using port 9002 on one of the PCs. 2. The two PCs are not in the same workgroup 3, The operating system in the Client predates the broadcasting facility (earlier than XP SP1). Regards Pete

I still can't help without information. As I said, I need to see both WideServer and WideClient logs, for the failing part (not after to disable and reenable, which will lose the information in the log). And please close both FS and WideClient down first. The FSUIPC log may also be useful. I did mention all this in my last reply. Now another day goes by ... :mellow: Something evidently changed. If not by you then maybe you have a hardware failure. But really I cannot hazard a guess from here. Information may well help, do you see? Regards Pete

The facility is documented in the WideFS Techincal guide. Search for RunKey and CloseKey. Regards Pete

In that case it doesn't exist and cannot run, obviously. The logs show a good working FSUIPC4 installation, presumably from before you deleted it. Pete

Excuse me, but if you delete FSUIPC4.DLL it cannot possibly run, so such de-installation must "work"! There's no difference between "registered" and "unregistered" if you don't use it. If it isn't used it cannot improve or change anything, it just sits there waiting to be used! It's a tool not a wonder cure. In that case you most certainly have not deleted the DLL as instructed! Those sort of hangs are almost almost due to a corruption in the files being loaded -- you can tell which ones because it tells you in that progress bar. Also you might need to wait a while. I think mine stops at 83% for quite some time. I seem to recall that's when it is loading and sorting its Autogen, but it might be scenery objects. The last things are weather and traffic. Regards Pete

I see Ian answered well, but I'm surprised you looked in all those places yet not in the most obvious, i.e. the User Guide which has a section entitles "De-installation" within its first few pages and which it also lists in the contents on page 2! :-( Pete