Pete Dowson

Hmmm. Not sure I understand those, but I'm glad you got it sorted out! Regards Pete

I think you need to solve that problem: "if i try to access my fsx machine form my laptop i can do that no problem.Not the other way round tho". I'm afraid WideFS does need a working network, and I am no Network expert. For me it is always a matter of trial and error. Maybe it is that way for you, too. But something is surely blocking things. Maybe the same TCP port (WideFS uses 8002 by default) is being used by something else? You could try changing it -- you'd need to change it for both Server and Client of course. Regards Pete

No. There is never any going back. If there's a problem it needs fixing! I fix problems as and when they arise, but there's no information in your message nor in your reference. Maybe I could help with more data? Regards Pete

Hmmm. Shouldn't be about Globalsign except on an original XP release (where MS forgot to include that root), or Windows 98/Me. And the FSUIPC installer should rectify that by automatically running the GlobalSign root installer.

What's "Global Root" problem? You've not confirmed you've trusted it yet, then. It would either be in the Untrusted or Trusted tab. It needs to be NOT untrusted. Else it doesn't matter. Regards Pete

Sounds good, then. ;-) Pete

Well, in the short (8 second) flight time you did for that log you averaged 46 fps which is better than I get even on my 4.6GHz i7-980X PC, and there are certainly no errors. But maybe your problems come later, after 8 seconds of flying? Pete

WideFS or GSPout? WideFS only talks to other PCs, ones running WideClient. How are you seeing the data being sent on COM4? This is the first I've even heard of a Garmin Aera. Just googled it -- looks like a nice piece of equipment! Not cheap! :) Assuming it does actually support Aviation format data on its serial connection (I assumed you checked that?) the only other thing you need to do is get the communication speed ("baud rate") correct. Whilst most NMEA-compatible devices standardise on 4800, some devices allow a selection of speeds, and the Aviation format data probably has a different default in any case. Regards Pete

When was everything working okay? What changed? Does Active Sky still function okay? ASX, ASA and ASE all use SimConnect over the Network, not WideFS, so if that is having problems it points to the same Networking problem as WideFS is having. What about the Client? It's a two-way connection. Maybe solving that would solve both? Regards Pete

You need WideClient connecting to the Server for it to work. It looks like the server is blocking the client. You need to disable your firewalls or allow FS and WideClient through. Is your Network actually working correctly for everything else? Can you access each from the other in Explorer? Regards Pete

Well there's unlikely to be any SimConnect issues in FSUIPC in any case as they would probably show up fairly quickly. Interesting that in those 8 seconds of running time he had a really good average FPS: Odd that it takes only the fairly common 60-70 seconds for FSX to do its initial loading, with 11 seconds for SimConnect to get its act together: But then it seems the user is in the initial selection menu for at least another minute before a FLT is actually selected: During that time nothing else is running in any case -- the selection menu is modal, like most of the menu dialogues. Then the flight, aircraft and local scenery takes a further 83 seconds to load: That's more time in which no much else is running -- most of that is disk access I should think. As you say, FSUIPC is only actually running for a few seconds, during which short time performance is excellent! ;-) Regards Pete

Yes, this is known and clearly documented. Did you not read that far? Here is what it says in the Offsets list: That's directly from the entry for 1400. Only by sending the right keystrokes. Look at the "Payload737.lua" example plug-in installed with FSUIPC in the example Lua programs. Regards Pete

Such jitter is usually a sign of a badly worn or dirty pot in the device, or of a poor power supply where the voltage is changing. Get them working in FS. Surely you aren't trying to use them via FSUIPC without checking them in FS first? What is wrong with the Saitek software? Does that play up? Assign in FS, Test. Calibrate in FSUIPC to get a more controllable "feel". There are no methods to remove bad jitter. The Filter option in FSUIPC's calibration may help, but not if it as bad as you say. You should probably check the warranty on your device. Regards Pete

I think you are confused. None of those things are anything to do with FSUIPC. The resizing of the FS screen is done in Windowed mode just like with any other windows program, by dragging the borders. Changing aircraft and so on is done in the FS menu, not in FSUIPC. That's normally hidden by default, you have to press the ALT key to show it, as always in FS. Again, nothing whatsoever to do with FSUIPC or anything else of mine. Pete

Assuming there are no errors being logged (did you check?), then it will most certainly not be FSUIPC itself doing this, but something using it, something not running the same way without it being there as with it. FSUIPC's overhead on the running of FS is barely measurable, especially when it isn't even registered and therefore not processing any user-set options. The only thing which can slow things down is if FSUIPC is repeatedly trying to re-initialise its connection with SimConnect. Such problems will be because of a SimConnect installation error and will be shown quite clearly in the Log file. Please check -- both Install and FSUIPC logs will be in the FSX Modules folder. Also check you are using a supported version of FSUIPC4 -- nothing earlier than 4.60. Regards Pete

Version 4.5 is very old now and hasn't been supported for a long time. The earliest supported version is 4.60, and there are later updates to that available in the Updates Announcement here in the Forum. Pete

Only through the menu settings. In fact I can't, programmatically, tell whether it's enabled or not. In FSX and ESP there's a control you can assign called MIXTURE SET BEST which apparently should set mixture levers to the current best power setting. I've never tried it though. If you simply wanted a partial level of auto-control you could use that. I don't think it exists before FSX though. Regards Pete

Maybe, but I think you are close. Just put that missing space back into the path for SerialFP2! Regards Pete

What "doc"? I only added the standard Lua sockets library to FSUIPC, I didn't document it. To be honest I know little about it -- I tested it using samples supplied by the folks who did the library, downloaded from the Lua sites. You don't need to imagine! ;-) Up to the last major releases (3.98 and 4.60) the changes are documented in the History document, installed in your FS Modules\FSUIPC Documents folder, and changes since then are listed along with the Updates in the Updates and other Goodies Announcement in this Forum. Regards Pete

Okaythat seems to confirm that the problem is at the Server end. And the fact that it takes a while to bog down indicates either a memory leak, as suggested, or a hardware problem being caused by heat or something which gets worse with time like that. The only way I ever found was by a process of elimination. Stop every add-on on the same PC, only use default aircraft. If it then runs okay, add things back one at a time. If it doesn't, then it's probably to do with scenery. Fly somewhere else or eliminate add-on scenery (make a safe copy of your SCENERY.CFG file and remove all of the entries past the default stuff. If that fixes it, add half back. If it is still okay, half the rest, etc, else take half of what you added back offetc. Eventually you find the one entry causing the problem). The only time this process of elimination fails is when there's more than one thing causing it. Then you are in a bit of a mess, unfortunately. If the problem only started happening recently, work out what you've added, recently, and start with those additions. It might speed things up. Regards Pete

Things seem to work fine for most folks. You must NOT include the real COM port (COM8, if that is where SerialFP2 normally finds the device). The pair you make with VSPE are to UNUSED COM ports, not real ones. That's why they are called "VIRTUAL" (means "not real"). Is the name "Compair_56" meant to reflect the pair as being COM5 and COM6, then, not COM8 and COM5 as you just said? Again, if COM8 one of the pair as you stated originally, this is wrong. That looks wrong. Check the path. I think you have a space missing between Files and (x86). No it isn't. You MUST check things more carefully! Why? I never advised any such thing. It is certainly not necessary. Googling for it I see error 267 means "directory not found", which is undoubtedly correct because you have it wrong! That is simply not true! You are not checking things properly! Because, as error 267 tells you (if you'd simply Googled it as I just did), you have the path incorrect. :roll: Incidentally, all that line in [Programs] is doing is starting SerialFP2 for you after FS has loaded. You could have tried that manually (double-clicking it or having a short cut, as for any other program) to prove whether or not all the VSPE stuff was okay. The [Programs] facility is only an extra convenience, to make things automatic, not part of these VRInsight facilities. Pete

There aren't currently any specific examples for the sound functions, but as you have seen they are simple one-liners' following the format defined. The examples provided do, however, show ways opf putting together Lua plug-ins to do all sorts of things, including events based on FSUIPC offsets. That is not true. Lua is at least as simple, for most things, as Basic, if not simpler, and in the case of the plug-ins using FSUIPC it is mainly a matter of calling functions as documented in any case. Please, just peruse some of the examples which are actually supplied. I'm sure you won't really find it so terribly difficult! Regards Pete

As the documentation clearly tells you, you only have to name the file "ipcReady.lua" and place it in the FS Modules folder, and it will start when FS is ready to fly. How can an example show more than such a statement? Surely you can this out so easily yourself from what is documented? I am really astonished that you won't even make the slightest effort to help yourself! :-(. You need to look up the number of the sound device 'xy' in the FSUIPC.INI file, as stated in the documentation for the function "sound.device()". Then just sound.play("name of sound", devicenumber) If you were really ambitious, and know the correct name of the device, you could write a loop to check the name of each available device and thus get the number automatically, but that is an unlikely thing to want to do. Oh dear. Have you not bothered to look up anything at all? sound.playloop("name of sound", devicenumber) You really want an event-driven function, exactly as shown in several of the examples supplied with FSUIPC. Read about the event library functions. I think you want to not do anything at all yourself? Why not at least make some effort? I am not here to do things for everyone individually. I supply documentation and examples. For the Lua language itself I give references to where you can find the full details as well as how to buy the books needed to learn more. However, it is so easy to simply apply yourself from all the examples already supplied. If this is really too much effort for you to apply I suggest you find a programmer willing to do things on commission. If you, on the other hand, want to try things yourself, I can help correct or extend your own examples -- but I really do ask you to make the initial effort. That is the best way to longer term understanding and therefore self-support rather than having to be spoon fed. Regards Pete

That's normally caused by the joysticks being "asleep" until you start using them. Apart from the fact that it is good practice to move all the controls and check they operate the control surfaces correctly every time before any flight (as in real practice), which would solve that in any case, you could try turning off Windows' USB hub power management. I'm glad you look ok, I can't tell from here. But a tendency to turn one way or the other as you accelerate on the takeoff roll is quite normal. There are several factors which contribute: Wind, "P-factor" (the torque from the rotation of the engine and propeller), and the effect of the air being blown back on the tailplane from the prop -- one side normally more, or higher, than the other depending on prop direction. I can tell you from experience in real aircraft that it is not easy to steer a straight line on the takeoff roll -- it needs practice. You can reduce the effect of two of those factors by reducing some of the realism sliders in FS. The wind factor is up to you. Either don't take off in any crosswind more than a few knots, or practice. Turning the ailerons slightly into wind will help as it will keep some friction on the ground from both wheels rather than allowing one to lift. If using your pedals makes the aircraft veer too much then either you are pressing them too far or they are just too sensitive. Rudder effectiveness increases with airspeed, so as you accelerate you should use less rudder in any case. If you have a registered copy of FSUIPC you can change the slope of any of the controls to flatten (lessen) the response near the centre (or vice versa). This is done by calibrating correctly and applying a suitable "slope". Regards Pete

Like to play a sound called "xyz.wav" located in your FS sound folder: sound.play("xyz") That's about the smallest example I can think of. Please explain what the problem is you are having. Isn't the explanation of the sound library functions in the documentation sufficient? If not, why not? What exactly do you find difficult to understand? The document has the format of the commands on the left and the explanations on the right. Is that not a good format for you? Pete