Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. It is actually closer -- the code is similar, but different, to the place in FSX which I patched. The function is different -- one parameter instead of two. So I'm not sure if i can patch that one or not. If it looks like it occurs a lot and DTG don't want to know, I might look at doing it. But I'd much rather not. DTG have already warned me that FSX-SE is going to change regularly, which will mean a lot of work for me each time unless I can sort things out with them. The problem will be rather complex. I doubt if it will be a user's choice whether his FSX-SE is updated -- it might be automatic, when Steam is connected. And then add-ons which hook internals, like FSUIPC, will crash, or at least not work. i am trying to sort out a method of dealing with this at present, and adding more hooks and patches seems counter-productive from that point of view. Pete
  2. You enabled the Lua friction file? that will explain differences in rolling resistance, for sure! You'd need to undo that, and also make sure that "PatchSIM1friction=No" is set in the [General] section of the FSUIPC4.INI file -- else default frictions will be changed automatically too. There'd be a line saying frictions were patched if "PatchSIM1friction=Yes". But it sounds like you are deliberately patching them using the more sophisticated Lua method anyway -- or even as well? Well, I think you've heard wrong. If your engines are running you won't have to even touch the levers for it to start rolling. If you are moving them then yes, it'll "rush" instead of gently accelerating. You need to keep the brakes on! However, if you prefer to have the ground friction preventing this, you now now what to do. Pete
  3. I'm afraid I still don't like P3D enough to move over. It doesn't look so good to me, and performance is worse on my system. I've never had an OOM problem. Maybe because I don't have any cockpit -- my cockpit is all hardware, so nothing on screen. And for my FSX-SE is quite significantly faster, so much so that I can shove more sliders up. However, I'm waiting on ASN because I'm not going anywhere without it's quality weather and WX Radar in Prosim737. Odd than in all these years I've never had any real errors in FSX which I couldn't track down to video drivers or bad scenery / texture files. And then only a couple of handfuls in all 8-9 years of FSX. Lucky I suppose, plus the fact that I only fly one aircraft -- a 737 based on the default -- and without it's graphics cockpit. I've got lots and lots of sceneries, especially airports, but again only in Europe and near-Europe Middle East and North Africa. Still not gotten around to flying to them all! ;-) Pete
  4. But the N1% reading from FS, the one shown on your cockpit, IS the thrust. There's no other. It doesn't matter how it gets to that value, whether by keyboard, throttle lever, writing the value directly in the appropriate memory location, that's it. I don't see how any control method can be involved in such a discrepancy -- unless it's the ground friction. Are you using the option in FSUIPC to change rolling ground friction values to what most folks say are "more realistic values". Have a look in the FSUIPC4.LOG file. BTW a real 737NG will definitely start rolling with idle thrust. you have to keep the brakes on to stop it. Maybe it's just that you aren't used to such realistic behaviour? Pete
  5. Sorry, there is no useful information in your report, not even the version of FSUIPC4. The only odd thing I see in your log is something frequently stopping FS and reloading WX.PLN into the GPS. Is that you? What are the symptoms of "FSUIPC crashed frequently". Since FSUIPC operates as part of FS, when it crashes so does FS. It cannot "crash" on its own, nor can it "crash frequently" during one flight. Perhaps you are using the wrong word, and "crash" isn't applicable? There's certainly no crash shown in the log. Also there's no termination shown. Did FS just hang, or did you forget to close it down? You said Is that because it disappears from the AddOn menu, or what? It would disappear is SimConnect stopped responding, which can happen sometimes on an overloaded system, but then it should usually recover, and these events are always logged. Pete
  6. There is nothing FSUIPC will do to control how much thrust it takes to move the aircraft. There must be other factors, like loading, wind, ground friction and so on. 26% N1 is 26% N1, 35% is 35%. What then happens is up to the simulation engine and environment. No. Pete
  7. Are you sure DTG's "own sim" is not ongoing development of FSX? That's what they appear to be saying, that there will be automatic updates via Steam to the FSX-SE they've released already. This is why they are interested in getting FSUIPC4 and FSX-SE more cooperative (see another thread near here), else each time they do an automatic update, FSUIPC will either crash or at best fail sedately. Pete
  8. I've looked at the code in Steam's G3D.DLL for both this place and the previous one, reported earlier in the thread (which was different). Neither are in any way related to the same bug I patched in FSX and P3D. These two appear to be just other examples or the many we had reported in FSX, none of which were patchable. Please just report all of them in the FSX-SE forum on Steam. Pete
  9. I think you must mean "Port", rather than channel, and you can change the ports used by parameters in the WideClient.INI and in the [WideServer] section if the FSUIPC4.INI file. Please refer to the WideFS Technical manual, look for the Port and Port2 parameters. Change both ends. Obviously they must be the same. I expect your XP version has similar options. Pete
  10. Yes. It means the code used in the CDU is not standard and cannot be called in the standard way used by Mouse Macros without crashing FS. The Mouse Macro-making facilities detect this and report it so you don't end up crashing FS. This will be a function of the way PMDG implemented things. I expect the button needs "unpushing" in order to allow it to be pushed again. I don't really know much about PMDG add-ons I'm afraid. Pete
  11. All that looks like is a timeout in waiting for a response. I expect your aircraft loading is taking a little while and the time out is a bit tight. However, whilst it is loading an aircraft (same as when loading a different flight), FSUIPC does signal that FS is busy or paused so programs using it should simply wait and retry at intervals. I'm afraid I don't recognise much else in what you posted. It looks like PS737 is using Paul Henty's DLL to access FSUIPC, so you could ask in his SubForum above. However, in the end I think Marty needs to look at executing some sort of retry recovery rather than flaking out. I also use ProSim8737 these days and so far have not seen a similar problem, but maybe my disks are faster and load aircraft and flights faster. I support you could try defragging your disks, see if that helps. Pete
  12. You could probably do it by using the FSUIPC offset controls. Offset word set, with Offset = xBC8, Parameter = 32768 to Set Parking Brake, Offset word set, with Offset = xBC8, Parameter = 0 to Release Parking Brake, Pete
  13. If you want to use the whole throttle lever range for forward thrust only, you simply need to select the "No Reverse Zone" option in the calibration tab, BEFORE calibrating. Alternatively you can calibrate with the central Idle zone in any position you like along the throttle lever movement. That's the whole point of FSUIPC's calibration facilities -- to let YOU control what you want these attachments to do! It sounds to me as if you've not actually yet gone through the process of calibration, else I'm sure you would have discovered these things. There are numbered steps in the User Guide. ;-) Pete
  14. Sorry, I really can't advise you about solving Win8 problems. FSUIPC doesn't know about or care about Windows versions. And it uses basically the same joystick methods in Windows as FSX itself. But you do not need to re-purchase FSUIPC. Just open your account in SimMarket and retrieve the details. Pete
  15. Sorry, I don't know FSC and can't possibly guess what the error means. Maybe simply that FS was not ready yet. You need to ask FSC support. Pete
  16. Pan view is ALWAYS listed as an Axis assignable control. You select the option to assign to FS controls, NOT direct to FSUIPC! It is an FS control, not an FSUIPC control. Pete
  17. I can't see your PC from here! I need information if you want me to help. Just saying "the same problem" is not enough. I need log files and descriptions! Pete
  18. "New" FSUIPC? What was your "Old" FSUIPC? Version numbers are useful!! The sorts of conflicts you are talking about are almost always due to dual assignments, probably having things assigned both in FSX and in FSUIPC. Go to FSX's assignments and disable controllers there. Then re-check. If that doesn't help, then maybe you tried re-using your FSUIPC4.INI file from your other PC and didn't take care to ensure that the controller attachments are recognised in the same way. For that we'd need to look at your FSUIPC4.INI file. You can always use FSUIPC4's event logging facilities too, to check what is actually happening yourself. If you (temporarily) run FSX in Windowed mode you can use the Console Log to the the results of your buttons in real time. Pete
  19. As Paul says, you need to set the FSX folder as the current folder. Is it? Personally I hate XML files. Too verbose and too prone to error, the syntax is so inflexible. I don't much like CSV either -- those were all Radar Contact needs. I prefer parameter based INI / CFG files myself, but it seems these days I'm alone. They used to be all the range! ;-) I don't have any plans, but virtually all of what MakeRunways does is a result of requests, not plans by me. If you really need something adding or changing just work it out and specify the result you want, and I'll probably fit it in when I've got an idle moment. Won't be very soon tthough, I'm afraid. But it'll go on a list. Pete
  20. Yes, sorry -- it was an error in 4.938a! I've just found it. FSX-SE took the place of ESP in my tables, so it got into 3308 as 9. I'll fix it and put 4.938b up iin the Download Links subforum later today. Pete
  21. Well, with some corrections, yes: function ShowSomething(offset, value) local newValue = value/10 ipc.writeSB(0x????, newValue) end event.offset(0x????, "SB", "ShowSomething") where the ???? parts are replaced by the correct hex values you want. With Lua development, don't be afraid to actually try things. Yes, of course ask if you get stuck, but you can rarely do any harm by simply experimenting. Pete
  22. Best NEVER assign in both FSX and FSUIPC. If you are assigning in FSUIPC, disable controllers completely in FSX, and anytime something seems amiss, like axis conflicts, check that it is still off. Pete
  23. One control axis is exactly the same as another to FSUIPC. And the card itself is unlikely to be able to cause a crash unless there's a problem with the USB connection and the driver in Windows. Have you tried different USB sockets on the PC? Is anything mentioned in the FSUIPC4.LOG file? Does it happen with all aircraft, or only one? If you don't calibrate in FSUIPC, how are you getting it assigned? The steering tiller facility in FSUIPC is only available "direct to FSUIPC calibration", and must be calibrated in FSUIPC, as well as the rudder, to ensure a correct trasfer of steering from one to the other. If you are instead using the FSX steering control, then it is more likley to be a bug in that, and should be reported to L-M. Pete
  24. There's no problem with the Prepar3Dv2 installation. It is working fine The failure is for the Prepar3D (version 1) installation! This is because the Registry points to your Prepar3Dv2 path for both Prepar3D and Prepar3Dv2, see: Maybe you deleted your Prepar3D installation rather than uninstalled it, or maybe the uninstaller doesn't work very well? Either way there is no harm except for the error message, which is irrelevant if you no longer have Prepar3D version 1. If you want to fix the Registry, just delete the Prepar3d entries, i.e. HKEY_LOCAL_MACHINE\SOFTWARE\LockheedMartin\Prepar3D Pete
  25. Something is not installed correctly. Have youbeen trying to use any migration tools? The first clue was that you posted a file called:: fsuipc4.fsx.log which would not normally exist -- the file should be just fsuipc4.log. The inserted "fsx" part implies that the EXE file is NOT what was expected, but a renamed EXE -- renamed FSX.EXE. Looking into that log it seems that FSUIPC4 thinks it is running inside Prepar3D: This mixup is very very weird. FSUIPC4 will certainly crash because it thinks it is running in P3Dv2 whereas it is running in FSX-SE. So, I examined the Install log. Look at this: So, it looks like the cause of the problem is that you have the Steam version's path registered for both FSX and FSX-SE. In fact, the Installer did not install anything into your FSX folder at all, despite you saying that was okay. I suspect that' was installed earlier. Reading further, you say: which cannot ever make any difference to the Installer. Ouch ouch big ouch! If this was done BEFORE the logs you show above, then what you have done is screw up the Registry data. If the FSX-SE installer thinks you don't already have FSX installed (and you've effectively told it that by deleting relevant folders), then it installs in such a way as to try to look like FSX normal. But your Registry also still points to FSX-SE as FSX-SE. So, I can see why my FSUIPC4 installer installs into FSX-SE twice, and not into FSX at all. But currently I'm not sure why then it things it is running in P3DV2. But it will be related. I'll look to see if I can work that one out, as soon as i've caught up with my holiday support backload, but meanwhile I think you need to sort something out -- that is if you want to retain your FSX installation which is no longer being recognised. [LATER] As far as I can see, the only way FSUIPC4 can make the decision that it must be a Prepar3D folder is that the FSX-SE FSX folder also contains a file called "Prepar3D.EXE". It deduces it must be Prepar3Dv2 because of the much higher version number. The fact that it is running inside an fSX.EXE leads it to deduce that, for migration purposes, you are running under a renamed version of Prepar3D.exe. So, can you check? Why would such an EXE be there? If it is, the fix for getting FSUIPC4 working in FSX-SE is simply to delete the unwanted Prepar3D.EXE file. 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.