Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. I've managed to get a similar crash, but it took a while, ad it seems to happen more if Lua logging is enabled. I've tracked it down very very deep into the Lua interpreter logic. It looks like there's a number of places in the original Lua code where things are used without checks. with threads coming and going I find a lot more checks are needed. Anyway, I've added checks in three places which I think are relevant, and in version 4.858, which i'll release later today or maybe tomorrow, I can't get it to crash at all. BTW I tested with the idea I had in my last message, where you are using the difference in the parameter values as an increment / decrement, and I think you need to do a few things slightly differently: 1. If, like my test axis (not a wheel), you need to reverse the trim action to match wheel-for-wheel, you need to change trim = trim + val - prev[/CODE] [size=4][font=arial,helvetica,sans-serif]to[/font][/size] [size=4][font=arial,helvetica,sans-serif] [CODE]trim = trim + prev - val[/CODE] 2. You might want to reduce the effect somewhat. if so, just divide the difference byt some factor, e.g.[/font][/size] [CODE]trim = trim + ((prev - val) / 2)[/CODE] [size=4][font=arial,helvetica,sans-serif]3. With a Delta of 1 your trim is subject to any jitter on the wheel axis. Set it instead to the minimum change you can see in the axis inputs x 2.[/font][/size] [size=4][font=arial,helvetica,sans-serif]4. You'll probably want a button you can push to centre the trim, for initial use or after loading a flight with the trim non-centred. Assign the button to [b]Axis elev trim set[/b] with parameter 0.[/font][/size] [size=4][font=arial,helvetica,sans-serif]Pete[/font][/size]
  2. Hmm. Shouldn't occur in any case, sleeps or no. I'll see if I can reproduce it here. Thanks for the error log data, that'll be useful. These are normal trim increment and trim decrement controls. It's such a shame you can't simply assign it as an axis, as intended. I think you said that was because you like to use what would be the electric trim adjustment on your yoke, right? And the trim wheel position then wouldn't match? Strange, that. Each one should move it a tad -- same as a single tap on the 1 or 7 numpad keys. No. The event system only calls the function when the Lua thread is idle (i.e. after the previous call has exited). The whole function is executed every time the event occurs. BUT there is no event queue -- all the PARAM changes which occur whilst the previous change is being dealt with will be collapsed into just the one change. So a Delta of 1 mught have the same effect as a delta of 32 or 64 or whatever, depending on lots of factors including how fast the wheel is turned. You would probably get more movement from slow turning than fast turning. That's the FS "control acceleration" operating. It does that for things like radio frequencies, headings, altitudes, all types of adjustments -- but only on the keyboard. Theoretically a pair of identical TrimUps and Trimdowns, with no other control between them, should do the same. In that respect it is self-defeating inserting sleeps. Controls don't work like that. They are neither "held" nor "released", they are simply events. There is another alternative, but I don't know if it will work with the aircraft you are using. That is doing the increment / decrement yourself, instead of relying on the inc/dec controls. This is actually one of the detailed examples in the User Guide -- search for "Offset Increment/Decrement Controls". You can do the same thing it is describing in the Lua program -- read the offset by trim = ipc.readSW(0x0BC0) [/CODE] Then adjust it, possibly by the difference in your previous and current PARAM value. For example: [CODE] trim = trim + val - prev if trim < -16384 then trim = -16384 elseif trim > 16383 then trim = 16383 end ipc.writeSW(0x0BC0, trim) [/CODE] You don't need to check if the value is going up or down this way. Another way if to use some fixed amount, arrived at experimentally. But I think the above is most flexible. Regards Pete
  3. That is the FSUIPC4.LOG file. It's filename is FSUIPC4.LOG. You have Windows set to hide filenames from you! Bad idea! The FSUIPC dcumentation tells you about this and what to do (see "Finding and Editing Files ..." on about page 10 of the User Guide). That's what I asked you to do. Don't bother Zipping and attaching files unless they are really big. The log shows FSUIPC4 is running fine. If even trapped and prevented a G3D.DLL crash, as shown here: 75770 *** G3D bad pointer trapped and crash prevented *** Being so early in the session it seems that you have something bad (scenery or aircraft files) loading up as part of your default Flight file, i.e. the default (X:\FSX\FLIGHTS\OTHER\FLTSIM.FLT). I suspect therefore that your FSX installation is corrupt and that this is the main reason for all these problems. Please next time close down FSX before getting the Log file. There is valuable information provided at the end of the Log. As I said, in this case FSUIPC4 loaded fine and was working well, but you certainly have FSX problems in any case if the default flight is crashing in G3D.DLL (which it certainly would have done if FSUIPC hadn't stopped it). Regards Pete
  4. Sorry, i'm a bit confused by what you say. The only problem with a normal keyboard is that when a key is held down it repeatedly sends the KEYDOWN code over and over until you release it, when it sends a KEYUP. Is this what your "hacked" keyboard is doing? In FSUIPC you can check the option "no repeats" to tell it to disregard the repeats of "KEYDOWN". Is that what you are lloking for. It's described in the User Guide in the key assignment chapter. The only the initial KEYDOWN and the eventual KEYUP is used, as you wish. Where do "buttons" come into it? You can read the documentation without purchasing anything. Pete
  5. Sorry, then. I'm just as baffled about what they are doing as you. Is there any support for this aircraft? I think you need them to sort this mess out. I find it very strange indeed that any add-on maker would mess about so much with the radio setting system implemented in FS by default, as it works perfectly well. Regards Pete
  6. 4.827 is very much out of date and long unsupported in any case. The current main release is 4.853. Version 4.857 is now available too, with this problem fixed. I have changed the code for FSUIPC3 too, but this won't be released until something more major needs a change. Regards Pete
  7. Why all the "sleeps" between controls? That in itself means you need more controls, because each change to the parameter (axis value) is taking nearly a whole second to process in the Lua before the next value can be seen. When you get to the end of the axis the parameter won't change anymore, so the Lua won't be executing. Well, that's the first thing that is wrong. 4.843 is out of date. 4.853 is the minimum supported version, and the current version is 4.857. Please ALWAYS make sure you are using the latest version before submitting a question or report. You'll need to re-test with the current version, please. Even the error details you took a picture of cannot be applied to the currently supported version. Yes, but most of the trim wheel axis changes will be missed because it is only using one change every second or thereabouts (all the sleeps added up). The way to get more response is to reduce the Delta value in the axis assignment - I see you've left it at its default of 256, so all changes of less than 256 will be ignored. Try 1 to catch every change, and only have one control in your Lua not many. See how that works, then adjust the Delta till the ranges match up. If you still get a crash at all, I will need the crash details again (but it is more efficient to get them from the Windows error log. You can copy and paste them from there into a message rather than taking a picture). Regards Pete
  8. It is a standard facility in WideFS and used a lot, especialy with PM modules. Check the "KeySend" facilities, described in the WideFS documentation. I'm surprised you've not used these before! You don't send the keystroke from the Server to the Client, but simply an assigned KeySend number (1-255). In the client INI file you instruct WideClient what to do with that KeySend. It might be starting or closing a program, or changing Fous, or, as you wish, sending a program a keystroke. There are several ways to direct the keystrokes too, described in the manual. Regards Pete
  9. FSUIPC itself does not have any Wilco-specific offsets. I don't have a list relevant to their Airbus. Offset 5648 is part of the area assigned to Project Magenta's "PMSystems" program. 5648 in particular is its FireStatus and Firebell control. If you are not running pmSystems when these offsets should be zero. So that is quite correct.. I think you need some other program to provide data from Wilco's Airbus. If you have a "list", who provided it? What is its title? Pete
  10. Wow! So it IS deliberately trying to delete it! What an unfriendly thing to do! That's the sort of thing invading virus software tries to do (but with more critical parts of course)! Pete
  11. That program is evidently not setting the weather stations. Which is odd. Unfortunately you did not send a proper log, only a "continuation log" (WHY did you press the "New Log" button? Please don't! It causes all the initialisation stuff to be chopped off in the other, previous log!(. It can't be scrolling that fast -- a few lines per second, that's all, as I can see in the log. Just lengthen the Window. For now, to test this, don't run your weather program, leave normal FS weather enabled. Only make one small change at a time. Pete
  12. It only patches around one specific G3D.DLL error, the one which seems to occur the most frequently -- but there are lots of others. And you do nothing to enable this action but install an up-to-date version of FSUIPC4. Pete
  13. Ouch! I must just be lucky in avoiding them all the time then? Regards Pete
  14. Yes, FSUIPC doesn't scan any joystick numbers which don't have any actual assignments. I suppose it should really look at all of the conditionals to set the list to scan too, but it never has done so, and this has never been a problem. I'm not sure I want to change that -- certainly not in FSUIPC3 in any case. Maybe in FSUIPC4 if it is easy to do. Which are you using, you don't say? Meanwhile, it is best to just assign a button to some dummy action which does nothing. Maybe I should add that note to the manual. No, I'm not messing further with the complexity already there. The "this or this or this" system has ALWAYS ben by havng multiple lines as you've found. It is much simpler that way, and surely easier to understand. Even if I derived some horrible new format for ands and ors in one line, the format internally would still involve separating them out into multiple entries for separate testing. Seems much more sensible to keep the parameters in line with the way they are processed. If you really want to get into very complex logic with things, try using Lua plug-ins, please. The reason I implemented Lua was to avoid making the existing code for such things so horrendously over complex and with more and more arcane syntax for the parameters. Regards Pete
  15. Seems odd that you encounter them so much. I've never run into one at all. You surely have to actually park at them and set your brakes and turn the ignition off? Why are you doing this if you don't want the auto-refuelling? Just park away from them. Can't be so difficult, surely? I was assuming it was just a pain on a couple of airports, spoiling your favourite parking spots? Regards Pete
  16. I don't think that's been possible programmatically since FS2000 or 2002. Best thing to do if you want them turned off permanently is probably to edit the AFD BGL file with something like ADE (www.scruffyduck.org.uk/ade/) and remove them. You might find more help in a scenery design forum. There's one on AVSIM I think. Regards Pete
  17. Assuming that on these occasions FSUIPC is not actually being loaded (see if there is a Log file produced), then this is a rare problem which is caused by a timing bug in SimConnect. Please see the "FSX fails to run after FSUIPC4 first installed" thread in the FAQ subforum. You could try using the FSUIPC loader, as described in the Installation and Registration document included in the main installer ZIP package. Be aware that using it does stop a couple of other things working, but these may not matter to you. On the other hand, if a Log file is being prodcued, it may be a different problem -- possibly interaction with something else you've installed. Show me the log file (FSUIPC4.LOG) from the Modules folder. Regards Pete
  18. So every time you run this VAFS5 program it deletes the MakeRunways executable from the FS folder? I wonder why? It surely cannot be accidental!? What happens if you make it read-only -- i.e. afford it some protection? Pete
  19. Ah, I see. No, sorry, nothing in the default ATC mechanism is accessible through FSUIPC or SimConnect. I don't know of anyone who has decoded the ATC modules in FS. Regards Pete
  20. No idea why you thought this was a "User contribution2 and posted it in that subforum. I assume it is a support question, so moved iit to the Support forum. No picture was evident, so i've no idea what you mean by "next ATC radio frequency". Perhaps you can explain if you can't provide a picture? Pete
  21. Reverse thrust controlled by throttle is simply a negative throttle value. With turboprops reverse is set by a negative prop setting though. 0B00 is a fixed value per aircraft whch gives the lower throttle limit -- 0 for aircraft without reverse thrust (on throttle) and a -ve value for those that have. it canot tell you when reverse is engaged. 088C is the throttle value for engine 1, but it will be >0 for forward thrust and < 0 for negative thrust, idle at 0. I don't know how you deal with that in pmSounds. Tried PM support? Pete
  22. Did you not view the results in real time in the FSUIPC console log, as I advised? Otherwise I am dependent upon you to identify which of the logged changes were done by which method. Actually only one type of control was used in any case, the direct setting ones, no INCs nor DECs. I think you need to observe what happens as you do these things, as I can't see what you are doing when. Not that it is relevant, but I'm not sure why you are getting so many failures to read the weather -- what weather are you using? Pete
  23. I've also never heard of such an odd thing occurring. It doesn't make any sense. Anyway, it's easy enough to correct -- just put it back. The latest version is always available here in the Download Links subforum. Pete
  24. I can't search by first names. Give me the order number and I can check here. The order number is needed. You might be getting the registration key correct, but are you also getting the email address and name exactly as shown in SimMarket? Use cut-and-paste to avoid making an error! There's been no change whatsoever in the way the Registration is checked, not since Registrations were first started in 2003. The code to do it has simply been moved into the Installer, because that has more privileges and with changes to security in Windows this step was made necessary. Every time this problem has occurred it has been a mistake in the details entered. [LATER] I searched all orders on 04-April-2006. Luckily only about 10 for FSUIPC3. Your order number was 240619, but unfortunately, at that time, the database I can access did not store the Key. I now have your name, as in the order, and email, as in the order. fI you send all the details (all three parts) you are trying to use, to me at petedowson@btconnect.com I will cross-check them here. Do not post such details here. However, please find the FSUIPC.LOG file (in the FS Modules folder) and paste the whole of that here, in a reply, or, if you prefer, ZIP it and attach it to your email. Regards Pete
  25. You can't do it with FS, but it is one of the main uses of FSUIPC. You assign aircraft to Profiles, and each Profile retains assignments and calibrations for all axes, buttons and keypresses. FSUIPC automatically loads the correct profile when you change aircraft. It sounds like you haven't yet become an FSUIPC user. You know you can install it and study the supplied documentation before purchase? You'd need to purchase a registration to do what you want, though. If you just want to read documentation without installing it, you'll find it downloadable in the Documentation thread in the Download Links subforum. I think the version there might be a little out of date, but not a lot will have changed in the area of your interest. Regards Pete
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.