Jump to content
The simFlight Network Forums

Alexey

Members
  • Posts

    12
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    EU

Alexey's Achievements

Newbie

Newbie (1/14)

  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare
  • Week One Done Rare
  • One Month Later Rare

Recent Badges

0

Reputation

  1. Yes, agree. This is legacy stuff I blindly moved from P3D (it was needed specifically for A2A aircrafts). Set DirectAxesToCalibs back to No, but the behavior is the same - sim yoke movements not linear. With the obvious difference that I now don't see the axes in FSUIPC calibration dialog - but I don't need anyways. Can't say, because this SU10 is when I first tried. Maybe I can try with SU11 beta. Attached please find FSUIPC7.ini and log file (I removed name & email). Log shows values coming from WideFS (2nd pc), but that I hope irrelevant to the issue. Log contents left me puzzled: what I see in values, looks fairly linear: 59625 25784 Monitor IPC:0BB6 (S16) = 0 59640 25784 SimRead: 0BB6="AILERON POSITION" FLT64: 0 60984 25784 Monitor IPC:0BB6 (S16) = 8216 61000 25784 SimRead: 0BB6="AILERON POSITION" FLT64: 0.501464961099 62328 25784 Monitor IPC:0BB6 (S16) = 15957 62344 25784 SimRead: 0BB6="AILERON POSITION" FLT64: 0.973938106511 But look at the screenshot (also attached). The title bar shows current 0x0BB6 value ˜8000, so my expectation for yoke rotation angle to be about 45 deg, but in MSFS it just started moving from straight position. Same behavior for three airplanes I tested. So no idea.. Maybe it's just visualization issue. FSUIPC7.ini FSUIPC7.log.zip
  2. Hi! I have a custom FFB yoke and try to setup MSFS with FSUIPC7 in the same way I had in P3D with FSUIPC5/6. * I don't have joystick device for my yoke. Instead, I directly set axis values through offsets 0x0BB2, 0x0BB6. * For P3D it works with DirectAxesToCalibs=All set in .ini file * I don't need any calibration/nonlinearity (the yoke has full range already). In MSFS this approach generally works, but comparing virtual yoke and real yoke motion I see that virtual MSFS yoke doesn't move linearly comparing to real one. There is a sensitivity curve introduced somewhere which makes it more sensitive at center. It works same way with and without FSUIPC calibration enabled (with FSUIPC calibration set to linear). I can compensate it via FSUIPC at the expense of movement accuracy (inverse curve), but that's undesirable scenario. Note: I cannot set or see calibration curves for ailerons and elevator in MSFS because I don't have joystick device for my hardware. Is there a way to have linear motion in this case? Am I missing something in FSUIPC or MSFS configuration? Thanks! Version: FSUIPC 7.3.1.1 Environment: MSFS 1.27.21.0, Win10
  3. Hi Pete! Thanks for quick response! Good or bad, this is typical setup for control loading applications. They itself load 1-2 cores for calculations and communications, so I don't want to stress main rendering PC even more. The lag is under 5-10ms (with UDP), which 100% enough for yoke movements. What is bad here? Obviously it's because something wrong with WideClient... It should not increase its memory footprint continuously, because the number of variables is constant (I think under 10-15 offsets, or event less if I setup only yoke app). Also, why it stops sending joystick buttons after reconnect? Again doesn't sound like correct behaviour. It's not excessive, it works very good until WideClient reach 100% load of its core. I believe that under any constant loading and working network stack WideClient should not uncontrollably grow its memory footprint and CPU load. Do you agree with this statement?
  4. Hi! I'm using WideFS with P3D 4.4: the client is installed on a second machine, and there are three programs that using it: force feedback yoke, motorised trim wheel, and a shaker controller (all from bffsimulation.com). Also yoke joystick buttons are connected via WideFS. When WideFS client connects to the server, its cpu usage is ~3-5% (from 4 cores) and it takes ~10Mb RAM. Then it starts to increase slowly, but noticeably. After about 15 mins, CPU load rises to 25% (full single core) and RAM is ~60Mb. I can see yoke movements becoming "coarse" and laggy (they are written to FSUIPC offsets via WideFS). Same for joystick buttons - when I start simulation, P3D reacts almost instant, but after time, it takes couple of seconds to react. Most probably it's the result of 100% CPU core loading on the second machine. I set WideFS to auto reconnect each minute, and it helps. After reconnection CPU load and RAM back to normal and start increasing again. But there is annoying side effect - after reconnect joystick buttons stops transmitting to server. I don't see reaction to pressing those buttons in FSUIPC settings. This looks like another issue (shutdown and restart of WideFS fixes this till next reconnect). And reconnection unfortunately introduces visible momentary jump in yoke movement, that's not great on final approach, etc. Does it look look like anything known? Tech specs and notes: FSUIPC 5.150b and WideFS 7.151 (latest to date), P3D 4.4, Windows 10 x64, Core i5 6600k 16Gb RAM (second PC with WideFS). Local gigabit ethernet. Tried various WideFS client and server settings, no positive effect to this issue (TCP and UDP, different ApplicationDelay, run as admin, etc.). Logs don't show any errors and look generally normal. Adding Log=Yes shows tons of offsets being written and that's all. Interesting that WideFS usually stay in processes when I close all clients and close it's window. Takes zero CPU, but memory still allocated. Has to kill it manually. My case maybe a little bit specific because WideFS client constantly writes FSUIPC offsets multiple times per second. Behaviour is the same if I only leave a single client application (any). Process Explorer shows several threads inside WideFS process and only one thread takes all the core. Others are less that 1%. With increase of ApplicationDelay parameter RAM and CPU load increases slowly. P3D frames locked at 30 FPS all the time. Attached config and some short last session logs (with reconnect enabled, so actually not showing the problem). I'll post logs with disabled reconnect within 1-2 days. FSUIPC5.ini WideClient.ini WideClient0.log WideServer0.log
  5. Hi Pete! Just noticed that brake axes calibration is not saved into .ini file. * I set DirectAxesToCalibs=All * open FSUIPC calibration tab, go to Left/Right brake * press "Set", do some changes * close the dialog * then open again => no calibration for brakes axes (nothing in .ini files). Can you pls check on your side?
  6. Hi Pete! Downloaded 5.150a and tested - working as expected! Thanks! P.S. "DirectAxesToCalibs=All" sounds good to me.
  7. Thanks for an explanation! But why are brakes axes so different? From here it looks like same questions are valid for other axes, including elevator and aileron. How that axis vs offset conflict is solved for them? I'd expect same behaviour for brakes, no matter which one. BTW, there is x310A offset to disconnect joystick from main controls, maybe something like this for brakes would resolve the issue? Personally I'd agree with any simplest workaround allowing me to calibrate that axis
  8. Just to be 100% clear, here is the screenshot from what I'm getting: Left part (prop, mixture) is a an example of what happening when I press "Set" button there. Right part is what happens when I press "Set" on Left/Right brakes. I.e. nothing is happening (looks like it immediately returning to the original state). If I change DirectAxesToCalibs to No, brakes start working just as all other axes.
  9. Hi Pete! I can reproduce the issue with default .ini with a single changed line (i.e. DirectAxesToCalibs) . Pls find that .ini attached and logs also. Yes, here they are: 0x0BB2 - elevator 0x0BB6 - aileron However, to reproduce the problem, I don't need to start the app that uses those offsets (normally it starts on another PC via WideFS). Yes, I have a rudder/brakes and throttles. This is the reason I want to calibrate brakes axes (rudder is calibrated perfectly). But I have this issue reproducible without any joystick devices connected (tried). I mean that I can enable calibration for any group box in "Calibration" tab, except for brakes. And this situation does not depend on particular axis assignments. E.g. I can assign right brake to my joystick axis, or I can skip this assignment - still "Set" button in Calibration->Brakes doesn't change anything. FSUIPC5.ini FSUIPC5.log
  10. Hi! I need DirectAxesToCalibs=Yes option to be able controlling A2A airplanes with my FFB Yoke (it uses FSUIPC offsets to control yoke position and this approach doesn't work with A2A without DirectAxesToCalibs). I found that when this option is enabled, left/right brake calibration doesn't work. When I press "Set" for brakes in Calibration tab, simply nothing happens. Other axes work fine. Version: FSUIPC 5.15 Environment: P3D 4.4 (same behaviour with P3D 4.3 and previous FSUIPC version), Win10 Repro steps: (optional) reset fpuipc.ini (delete, restart p3d, close p3d) set DirectAxesToCalibs=Yes in fsuipc.ini start P3D go to Axis Calibration -> Left (or Right) Brake press Set Expected: usual calibration controls will be shown, button text changes to "Reset" Actual: nothing is changed, still only "Set" button is visible in the Brake groupbox Notes: obviously with DirectAxesToCalibs=No (default value) calibration is working other axes still calibrated fine if calibrate the axis with DirectAxesToCalibs=No, save to .ini file and then start P3D with DirectAxesToCalibs=Yes, calibration values deleted from .ini file (only for brakes!) in my case seems the behaviour doesn't depend on aircraft (though I'm testing mostly with A2A Comanche) same result whether axis is assigned or not. Similar report: https://forum.simflight.com/topic/78135-ch-pedals-calibrate-brake-axis/
×
×
  • 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.