Pete Dowson

Seems you are missing that DLL. The start of the Lua program says: poKeys = luacom.CreateObject("PoKeysDevice_DLL.PoKeysDevice") if poKeys == nil then ipc.log("Error: Unable to create PoKeysDevice_DLL object") ipc.exit() end [/CODE] so you need the module called PoKeysDevice_DLL. Pete

In that case I am not surprised!!! I am sorry, but I cannot possibly support such an old version! Where on Earth did you "just ... downloaded about a week or so ago!"? It is over 4 years and 50 versions old, and certainly should not be available anywhere! I'd like to know where you got it so I can make sure it isn't supplied there any more! I suggest you update and try again. The earliest supported version is 4.853 which is available on both the places which legitimately supply my programs. There is also a n update to 4.859d in the Download Links subforumn here. Your FSUIPC registration is actually not valid either with that old version as the registration system was changed a couple of years ago! I wouldn't be surprised if it was causing you all sorts of problems! BTW, also, you pressed the "New Log" button. Please do NOT do this! It means initialisation data is missing from the log. Only do as suggested, do not press things at random. Pete

:razz: :razz: :razz: :razz: ! Mine's a black and tan, thank you kindly! Pete

It won't hurt to try smaller values. There'll come a point where the graphics redraw on the target will limit it, or you'll notice some impact on the FS PC -- though the latter is actually less likely, as it is all happening in separate threads. Pete

That's the one parched by FSUIPC4. If they all at that location you are in luck! Yes, as it says: it is offset 0x000ba79f in module C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\g3d.dll. Pete

Version numbers a more useful. I would assume that it is 4.853, then, unless you downloaded one of the updates since the main release? Version number? (If you did that logging and showed me the log I could see the version numbers of both FSUIPC and GFDev.DLL. Possiby, though it is GFDev.DLL's job to work that stuff out. It sounds like GFDev doesn't like it. If you look in the FSUIPC documents folder, in the FS Modules folder, you'll see a ZIP file containing a number of Lua plug-ins -- supplied as examples. Please copy the GFDisplay.lua file into the Modules folder, then go to Keys or Buttons tabs, press reload, and then assign a keypress or button to "Lua GFDdisplay". Then use that key or button to start that plug-in off. It will list all the devices and do a sort of display test, then sit and wait for buttons and switches. Try that, see what happens. Finally, check the Download Links subforum here, the thread about the Lua package. In there is a link to a program called "HidScanner". Run that and show me the Hidscanner log it produces. Pete

Do you mean the TPM/SECM module? I don't see a SECM on its own listed on their site. I've never seen one of these units. If they identify themselves differently to either a TPM or SECM, then that may be the problem. I could add support but I'd either need to ask GoFlight to send me a unit, or get you to run a series of tests with Lua plug-ins in order to determine what bits do what. I'll try my contact at GoFlight first, and let you know. FSUIPC does include support for the original SECM module -- up to two are supported. The switches should be arriving as joystick.202 for the first annd 203 for the second. Maybe your GFDev.dll is out of date? BTW you need to mention which version of FS and which of FSUIPC you are using, as it might make a difference too. Meanwhile, make sure FSUIPC is bang up to date (see Download Links subforum), and enable button logging in the Logging tab, then operate each switch in tirn and show me the FSUIPC log. Pete

did you look in the documents which are installed in your FSUIPC Documents folder? FSUIPC4 has code to patch out one specific reason for crashes in G3D.DLL. Check the History documents. No, that is not totally true. It patches the G3D.DLL code to avoid one very specific crash, only, not all possible crashes. The one it prevents is most certainly due to corruption of data in memory. How that occurs and what the data actually is, has not been determined. All I know is that it is related to scenery. For those who experienced that specific crash it seemed to be related both to specific scenery areas, with specific add-on sceneries, and maybe also to the length of time that they'd been flying. I only ever got this crash once and it was not reproducible. I don't recall having any of the others folks reported. That doesn't sound like the one FSUIPC patches, but I can't tell without more data. The location of the crash is important -- it is found in the Windows event logs. Regards Pete

The software is merely reading what it sees from the USB interface in Windows. Possibly the hub you were trying to use was not powered, or insufficiently powered. Or else faulty in some way. All software is dependent upon the hardware it is trying to use, of course. Pete

It sounds like you are writing the wrong sized value -- both of those are just one (1) byte not words or dwords or any other type. The byte immediately following those (341E) just happens to be the hydraulics switch. Take more care -- each value in the offsets has a size. Respect it! Also, you could figure these things out by yourself. Use the logging to work out what you've got wrong. Finally please always mention the version of FSUIPC you are using, and if not the latest update first. Also mention the aircraft -- test with default aircraft. Pete

You can put the WAVe file in a different folder, where Windows isn't getting in your way, and provide the complete path in the Play command, so, for example: sound.play("E:\\MySounds\\10000FTalert") Note that you must use \\ to represent one \ as \ is used as an escape to include special characters like \n for 2new line". Pete

I see you allowed FS to install in the Protect Files area of the Windows folders. That means your "sound" folder will be write-protected. In order to put your WAV file in the REAL folder (the one FSUIPC can access) you need to run Explorer "as administrator". I suspect your sound file isn't there. Your logging looks wrong too. With the Debug/Trace option se and the exact same Lua program except with the WAV file name changed I get these entries: 40592 LUA.0: beginning "E:\FSX\Modules\Alert10000.lua" 40592 LUA.0: E:\FSX\Modules\Alert10000.lua:1 40607 LUA.0: Global: ipcPARAM = 0 40607 LUA.0: E:\FSX\Modules\Alert10000.lua:2 40623 LUA.0: Global: prevalt = -1 40639 LUA.0: E:\FSX\Modules\Alert10000.lua:11 40639 LUA.0: Global: mark = 10000 40654 LUA.0: E:\FSX\Modules\Alert10000.lua:4 40670 LUA.0: E:\FSX\Modules\Alert10000.lua:13 40685 LUA.0: Waiting for an event in "E:\FSX\Modules\Alert10000.lua" and then this for every altitude change it registers: 103070 LUA.0: Offset Change event: calling "check10000" in "E:\FSX\Modules\Alert10000.lua" 103070 LUA.0: E:\FSX\Modules\Alert10000.lua:5 103086 LUA.0: Local: val = 352 103101 LUA.0: E:\FSX\Modules\Alert10000.lua:7 103101 LUA.0: E:\FSX\Modules\Alert10000.lua:10 103117 LUA.0: E:\FSX\Modules\Alert10000.lua:11 103133 LUA.0: Global: prevalt = 352 You can also log the Sound actions by adding these lines to the INI file [general] section before starting FS: Debug=Please LogExtras=x20 Here's the result then as I pass 10000 climbing: 195282 LUA.0: Offset Change event: calling "check10000" in "E:\FSX\Modules\Alert10000.lua" 195282 LUA.0: E:\FSX\Modules\Alert10000.lua:5 195298 LUA.0: Local: val = 9998 195298 LUA.0: E:\FSX\Modules\Alert10000.lua:7 195314 LUA.0: E:\FSX\Modules\Alert10000.lua:10 195329 LUA.0: E:\FSX\Modules\Alert10000.lua:11 195329 LUA.0: Global: prevalt = 9998 195345 LUA.0: Offset Change event: calling "check10000" in "E:\FSX\Modules\Alert10000.lua" 195345 LUA.0: E:\FSX\Modules\Alert10000.lua:5 195360 LUA.0: Local: val = 10000 195360 LUA.0: E:\FSX\Modules\Alert10000.lua:6 195376 Sound: Id 1, PlayNow("CabinAlert") 195376 Sound: Id 1, PlayTheSound("E:\FSX\Sound\CabinAlert.wav") 195407 LUA.0: E:\FSX\Modules\Alert10000.lua:10 195423 LUA.0: E:\FSX\Modules\Alert10000.lua:11 195423 LUA.0: Global: prevalt = 10000 So, you need to cross-check everything. Pete

BTW it works perfectly here, though I changed the wave file to "CabinAlert" as i don't have yours. So, I'm pretty sure that you are making a mistake. Pete

Use Lua logging to see what is happening. See the FSUIPC logging tab (Debug/Trace Lua option). What for? How can you expect me to read that minute fuzz? Please do NOT add screen pictures, they are almost always a complete waste of time as that one certainly is, more so that most. can YOU actually read anything there? Pete

No. See my last post. The original is for AMSL -- you wanted Altimeter, you said. And the filename of the Lua file must match of course, be it "alert10000.lua" or "alter10000". You could name it "typo.lua" if you want, but match the command to load it ... of course. Wouldn't it be rather quicker to try it rather than post all these queries on every point? I'm not going to test it for you. If it doesn't work THEN ask questions, or refer to the documentation. Pete

And what does the Log show? What is WideClient being used for at the time? If that drive intended to be hot-swappable? Is there something on it which might be relevant to whatever you are having WideClient do? If the Wideclient log shows nothing wrong, check the Windows event log. It will tell you the module which crashed -- probably something to do with the network or at least hardware level drivers. Maybe the Windows hardware plug-and-play scanner messes up the network connection module when it is forced into action. Pete

In that case you need to change things -- offset 0574 gives the true AMSL reading. The altimeter reading is in 0x3324 and is in feet (unless you have FS running in metric altitude mode). So it would be: prevalt = -1 mark = 10000 function check10000(off, val) if (val >= mark) and (prevalt < mark) then sound.play("10000FTalert") elseif (val <= mark) and (prevalt > mark) then sound.play("10000FTalert") end prevalt = val end event.offset(0x3324, "SD", "check10000")[/CODE] Like what? What for? No. ".wav" is assumed. you can include it if you really want to though. Pete

Sorry, I've no idea what you are talking about here. Can you explain what you mean by "i plug in and after use out a external HDD"? What does that mean, it makes no sense as it stands. What is running where and what is it doing? What is the "failure"? What do the logs show? Obviously if you remove or change something whilst it is use you are asking for trouble -- corrupted files included. Pete

Yes, easy enough with a small Lua plug-in program which reads the altitude and plays a wave when needed. Check out the Lua facilities documented n your FSUIPC Documents folder (in the FS Modules folder). Do you want true altitude AMSL, or the atimeter reading 10,000? I assume the former?: prevalt = -1 mark = 10000 / 3.28084 --10000 feet in metres function check10000(off, val) if (val >= mark) and (prevalt < mark) then sound.play("name of climb wave file") elseif (val <= mark) and (prevalt > mark) then sound.play("name of descend wave file") end prevalt = val end event.offset(0x0574, "SD", "check10000") [/CODE] Something like that anyway. You might want to tweak it a little to avoid it going off continuously when wobbling about near 10000. And you might want it to start a little below/above 10000 to allow for any small delay in activation. Also of course fill in the names of the wave files you want to play (which should be in your FS Sound folder). Save that as, say, "alert10000.lua" into your FS Modules folder and add this to your FSUIPC INI file [Auto] 1=Lua alter10000 Regards Pete

Yes, thanks for the explanation. Pete

That wouldn't clean out years of accumulated sticky dirt inside. I use Super Servisol switch cleaning lubricant spray. Penetrates and clean switches etc. Spray so that it penetrates into the components and operate them whilst wet. Leave to try before reconnecting. I had a CH one many many years ago. it gradually got worse and worse. I had it serviced once at a CH service agents over in Shrewsbury, and it lasted a couple more years before it was junked. I think they make them a lot better these days. I have Saitek here, which seems okay -- certainly better pots with higher resolution. But i don't like any of these. They don't feel anything like the real thing, so I was spoiled by doing real flight lessons. I use PFC yokes now (I do the FS drivers for PFC). I'll probably give my Saitek to my grandson when he gets to be 12 or so, along with the throttle quadrants and other bits. At present he's more into sports and playstation type stuff so i wouldn't waste them just yet. Regards Pete

Yes. In strings the \ character is an escape character, so that, for example, \n can be used for "new line". To get a true \ character you need to put \\ each time. Also, I'm not too sure about those 8-char DOS abbreviated names. They may not work in the normal C library API calls which the Lua interpreter is using. Pete

Why disconnecting? That makes FS re-assign. Take care doing things like that. I assume you mean "yoke"? (yolk is the centre of an egg! <G>). Aileron=-15992,512,5906,16016 Elevator=-14598,-4819,512,13376 Throttle=-16193,16192 Those values look better, with a wider dead centre zone though. Do you want it that wide? You might do better with a narrow dead centre zone and just use the slopes facility to flatten things a little around the centre. I am beginning to think your idea of "super sensitivity" may be more related to the aircraft you are trying. Without being able to reach both extremes of elevator and elevator, as designed for that aircraft, you do not really have the full control you should have. 8 years? Have you ever cleaned the pots inside (electrical cleaner spray)? If the IN (input) values aren't changing reasonably smoothly then you either have a bad connection, or bad (dirty) post), or even pots with broken wires (assuming they are wirewound -- most cheaper ones are resistive carbon tracks). Pete

You didn't do the sound logging i suggested. Of the INI file the only relevant part is: [Sounds] Path=H:\Prepare3d\Sound\ Device1=Primary Sound Driver[/CODE] I'm afraid I don't have a clue why the standard DirectSound facilities aren't working on your system, assuming the wave files are there and the Sound folder is correct and accessible. The logging might help show why, but it may also be a good idea to update your FSUIPC4.DLL to the same version as myself (not that anything should have changed in this area).[b] 4.859d [/b]is available in the Download Links subforum. On your return, of course. Regards Pete

As far as I am aware, persistence eventually wins. I'm afraid I've no other ideas than those presented there, but just in case it is due to something different, please see if there is an FSUIPC4.LOG file produced in the FS Modules folder. If so, paste it in a reply here. If there isn't one, you could try to get a SimConnect log -- there's a thread in the FAQ subfoum which explains how to do that. Regards Pete