Linux Support

[S4ndstorm]

Hi!

Edit:

Using the steam version on CachyOS, the splash screen is appearing whenever i open the map or interacting with it. It happens with the native or proton version
If launch it in gamescope (

Code: Select all

gamescope -W 2560 -H 1440 -b -r 144 --force-grab-cursor -- %command% -skipintro

), it works perfectly

I have had the same problem. (my previous comments in the same thread)

If it matches, you should be getting the splash screen on map and menus open/close only when on foot and not when sitting in a ship's seat.

The problem seems related to KWin+Wayland. If your problem is occurring with X11, then it is a different problem.

Workaround that I use:
KDE System Settings -> Window Management -> Window Rules:
- Create a Window Rule for the X4 window and add the following Rules
- Ignore Requested Geometry - Force - Yes
- Size - Force - 1919 x 1080 [do it according to your screen size, so 2559 x 1440]
- Keep this Window Rules setting disabled and enable it after starting the game. Disable it every time after closing the game window and reenable after starting it again.

In my case, the monitor screen resolution is 1920x1080, so I just reduced 1 pixel length and made it 1919x1080. You can also do 1920x1079 or reduce it by more than 1 pixel lengths. Either one works.

Alternatively, if you have 2 GPUs, then you can set plasma to use the GPU that X4 is not using and that might fix this problem (it did for me until the other GPU stopped working (maybe it was just old, maybe something else)).

Just wanted to say thanks for this. I had been busy for a day to try and get it to work. This (including the disable enable for start) worked for me.
on Fedora KDE Plasma, AMD Graphics and multiple screens (1gpu) i would love to see this added to the firstpost

[Rastuasi]

Just wanted to say thanks for this. I had been busy for a day to try and get it to work. This (including the disable enable for start) worked for me.
on Fedora KDE Plasma, AMD Graphics and multiple screens (1gpu) i would love to see this added to the firstpost

Just a small tease, none of this should be needed on 9.0. They corrected a bunch of the wayland issues and I was able to turn off all the launch options.

[beko]

Just a small tease, none of this should be needed on 9.0. They corrected a bunch of the wayland issues and I was able to turn off all the launch options.

Hell yes!

… and you can tease me all day

[Rastuasi]

Just a small tease, none of this should be needed on 9.0. They corrected a bunch of the wayland issues and I was able to turn off all the launch options.

Hell yes!

… and you can tease me all day

9.0 is out! So please let us know what options you still require. Each system is different, so I may be special in that I could remove all those extra commands. Definitely be good to note what ones and what hardware differences there are.

[TacticalTree]

9.0 has fixed the splash screen issue for me. However, I have an issue with dialogue audio now, there's no voices, be it comm or "ship" voices (like Autopilot activated, station/ship name etc.)
Other sounds like ship engines or weapons are fine.
The biggest issue is this also locks me out of saving, during Boron questline Boso Ta contacts me when I arrive at certain spot, however the comm video and subtitles just stay up as he says nothing. Can't save, quest doesn't progress.

Disabled all mods (All two of them, Sector Satellites and Learning all the things), deleted them even, started a new game as well, problem persists.

@edit
Reinstall with all config removal has helped.

[steve_v]

What in the holy three-dimensionality is going on with GNU/Linux native performance?

In this particular (random, bunch of 'roids and a station in view, couple xenon fighters nearby, no major combat) scene, ~55FPS with noticeable stutter / frame-pacing issues is the best I can get. At ~65%GPU / ~11%CPU load.
The exact same scene, with the same settings and same save (i.e. copied all relevant files), the Windows build w/proton gets a butter smooth 75+FPS at ~70%GPU / ~20% CPU.
The same delta tracks in several other saves I have tested as well, regardless of what is going on - a consistent 20+FPS better perf with the windows build.
It's not graphics settings either apparently, flipping the GNU/Linux install to the "low" preset gives exactly zero performance improvement.

I bought this game specifically because it has a native port, but a this is ridiculous. What gives?

X4 9.0 release (GOG)
Intel I9 10900KF @ 5.0Ghz
64GB DDR4 @ 3200MT/s
AMD RX6700XT
Gentoo GNU/Linux
Kernel 6.18.33
KDE Plasma 6.6.5 / Wayland

Aside, native wayland reports adaptive vsync "not available on this hardware" in display settings, which it most certainly is. Under xwayland and proton, adaptive vsync is available and works as expected.

Ed. just fired up a real X11 session with IceWM (to eliminate wayland compositor/plasma etc.), and it makes no difference whatsoever.

[mobilex]

What in the holy three-dimensionality is going on with GNU/Linux native performance?

In this particular (random, bunch of 'roids and a station in view, couple xenon fighters nearby, no major combat) scene, ~55FPS with noticeable stutter / frame-pacing issues is the best I can get. At ~65%GPU / ~11%CPU load.
The exact same scene, with the same settings and same save (i.e. copied all relevant files), the Windows build w/proton gets a butter smooth 75+FPS at ~70%GPU / ~20% CPU.
The same delta tracks in several other saves I have tested as well, regardless of what is going on - a consistent 20+FPS better perf with the windows build.
It's not graphics settings either apparently, flipping the GNU/Linux install to the "low" preset gives exactly zero performance improvement.

I bought this game specifically because it has a native port, but a this is ridiculous. What gives?

X4 9.0 release (GOG)
Intel I9 10900KF @ 5.0Ghz
64GB DDR4 @ 3200MT/s
AMD RX6700XT
Gentoo GNU/Linux
Kernel 6.18.33
KDE Plasma 6.6.5 / Wayland

Aside, native wayland reports adaptive vsync "not available on this hardware" in display settings, which it most certainly is. Under xwayland and proton, adaptive vsync is available and works as expected.

Ed. just fired up a real X11 session with IceWM (to eliminate wayland compositor/plasma etc.), and it makes no difference whatsoever.

Well the Linux build is still kinda experimental. If I remember correctly it was made public in version 8.0 so it's still quite new. I also run linux and I would recommend you to use the Windows (WINE) version over native one for now. (I found Proton-GE to provide the best experience)

[Rastuasi]

What in the holy three-dimensionality is going on with GNU/Linux native performance?

In this particular (random, bunch of 'roids and a station in view, couple xenon fighters nearby, no major combat) scene, ~55FPS with noticeable stutter / frame-pacing issues is the best I can get. At ~65%GPU / ~11%CPU load.
The exact same scene, with the same settings and same save (i.e. copied all relevant files), the Windows build w/proton gets a butter smooth 75+FPS at ~70%GPU / ~20% CPU.
The same delta tracks in several other saves I have tested as well, regardless of what is going on - a consistent 20+FPS better perf with the windows build.
It's not graphics settings either apparently, flipping the GNU/Linux install to the "low" preset gives exactly zero performance improvement.

I bought this game specifically because it has a native port, but a this is ridiculous. What gives?

X4 9.0 release (GOG)
Intel I9 10900KF @ 5.0Ghz
64GB DDR4 @ 3200MT/s
AMD RX6700XT
Gentoo GNU/Linux
Kernel 6.18.33
KDE Plasma 6.6.5 / Wayland

Aside, native wayland reports adaptive vsync "not available on this hardware" in display settings, which it most certainly is. Under xwayland and proton, adaptive vsync is available and works as expected.

Ed. just fired up a real X11 session with IceWM (to eliminate wayland compositor/plasma etc.), and it makes no difference whatsoever.

Well the Linux build is still kinda experimental. If I remember correctly it was made public in version 8.0 so it's still quite new. I also run linux and I would recommend you to use the Windows (WINE) version over native one for now. (I found Proton-GE to provide the best experience)

What? No Linux build has been out public since 2019, almost the entire life of the game thus far. I have used standard native version and it's been perfect. I also had no perf issues in beta nor sound for 9.0

[mobilex]

What in the holy three-dimensionality is going on with GNU/Linux native performance?

In this particular (random, bunch of 'roids and a station in view, couple xenon fighters nearby, no major combat) scene, ~55FPS with noticeable stutter / frame-pacing issues is the best I can get. At ~65%GPU / ~11%CPU load.
The exact same scene, with the same settings and same save (i.e. copied all relevant files), the Windows build w/proton gets a butter smooth 75+FPS at ~70%GPU / ~20% CPU.
The same delta tracks in several other saves I have tested as well, regardless of what is going on - a consistent 20+FPS better perf with the windows build.
It's not graphics settings either apparently, flipping the GNU/Linux install to the "low" preset gives exactly zero performance improvement.

I bought this game specifically because it has a native port, but a this is ridiculous. What gives?

X4 9.0 release (GOG)
Intel I9 10900KF @ 5.0Ghz
64GB DDR4 @ 3200MT/s
AMD RX6700XT
Gentoo GNU/Linux
Kernel 6.18.33
KDE Plasma 6.6.5 / Wayland

Aside, native wayland reports adaptive vsync "not available on this hardware" in display settings, which it most certainly is. Under xwayland and proton, adaptive vsync is available and works as expected.

Ed. just fired up a real X11 session with IceWM (to eliminate wayland compositor/plasma etc.), and it makes no difference whatsoever.

Well the Linux build is still kinda experimental. If I remember correctly it was made public in version 8.0 so it's still quite new. I also run linux and I would recommend you to use the Windows (WINE) version over native one for now. (I found Proton-GE to provide the best experience)

What? No Linux build has been out public since like version 1.5. almost the entire life of the game this far. I have used standard native version and it's been perfect. I also had no perf issues in beta nor sound for 9.0

Really? Sorry about my statement then. I have the steam version and the native option become available like 2 months back for me but I might have never noticed it. Sorry.

Now that I think about it the thing that got introduced in 8.0 that was connected to linux was cross-platform progression on Steam. I probably confused these two.

[Rastuasi]

Well the Linux build is still kinda experimental. If I remember correctly it was made public in version 8.0 so it's still quite new. I also run linux and I would recommend you to use the Windows (WINE) version over native one for now. (I found Proton-GE to provide the best experience)

What? No Linux build has been out public since like version 1.5. almost the entire life of the game this far. I have used standard native version and it's been perfect. I also had no perf issues in beta nor sound for 9.0

Really? Sorry about my statement then. I have the steam version and the native option become available like 2 months back for me but I might have never noticed it. Sorry.

Now that I think about it the thing that got introduced in 8.0 that was connected to linux was cross-platform progression on Steam. I probably confused these two.

Ah yes that makes sense, cause before Linux saves had a diff save structure so you had to use WINE version of steam and x4 to play your windows based saves on Linux. However, purely Linux worked since 2019. It was recently that they did that big push to sync how saves are done in the steam client and cloud that allowed them to do the change so we can simply play without wine for windows saves. As I havent had windows since the 90s, that wasn't an issue here . I have over 3000 hours in X4 on Linux though, so I can definitely say it works. Mind you Wayland did cause issues for awhile, but when doesn't it? It has to be good at one thing at least, so they chose "causing issues" haha. Regardless 9.0 fixed a lot of that, but as per the he wiki, you may need a -prefer-wayland starting parameter. I personally don't.

[steve_v]

I have over 3000 hours in X4 on Linux though, so I can definitely say it works.

Works, yes. Works well... Not so much.
7.x (the last time I played prior to 9.0 release) had similar performance native vs. wine/proton, but many other variables have changed in that time so it's probably not particularly useful data at this point.

you may need a -prefer-wayland starting parameter.

Whether any of this really has any bearing on my question, or is just you two arguing as to the native build being a real supported thing (I can assure you it is), I am not sure...
In any case, I've tried forcing wayland on wayland, I've tried it forcing x11 on wayland (i.e. xwayland). I've tried gamescope, I've tried all manner of environment variables to override vsync/present mode, and I've even tried it in IceWM in a real X11 session - zero (and I do mean zero) difference in framerate.
The only thing that does make a real difference is renicing the X4 Main() process to RT priority - which gets me *displayed* framerates (ingame FPS display or mangohud) similar to wine/proton, but if anything makes the microstutter/frame-pacing problems worse.

[Rastuasi]

I have over 3000 hours in X4 on Linux though, so I can definitely say it works.

Works, yes. Works well... Not so much.
7.x (the last time I played prior to 9.0 release) had similar performance native vs. wine/proton, but many other variables have changed in that time so it's probably not particularly useful data at this point.

you may need a -prefer-wayland starting parameter.

Whether any of this really has any bearing on my question, or is just you two arguing as to the native build being a real supported thing (I can assure you it is), I am not sure...
In any case, I've tried forcing wayland on wayland, I've tried it forcing x11 on wayland (i.e. xwayland). I've tried gamescope, I've tried all manner of environment variables to override vsync/present mode, and I've even tried it in IceWM in a real X11 session - zero (and I do mean zero) difference in framerate.
The only thing that does make a real difference is renicing the X4 Main() process to RT priority - which gets me *displayed* framerates (ingame FPS display or mangohud) similar to wine/proton, but if anything makes the microstutter/frame-pacing problems worse.

There were a bunch of graphical updates in 8.0 IRC, so yes most of us had to turn down settings a bit. More I turned off volumetric fog, but I'm running at 100 FPS now late game with full megaplex and in system. So we will probably need more of the actual documents for your system to know what is up, since it would be system related at this point. The unfortunate thing with the Linux world is that every person's systems differ.

[steve_v]

There were a bunch of graphical updates in 8.0 IRC, so yes most of us had to turn down settings a bit. More I turned off volumetric fog, but I'm running at 100 FPS now late game with full megaplex and in system.

Graphics settings make no difference here - I get exactly the same framerate and garbage frame-pacing on low as I do on medium, the only thing that changes is GPU load... Which never exceeds ~75% in this scene anyway.
Ditto volumetric fog, turning it off completely makes no difference (and there's sod all fog in this sector anyway).
IOW, I can certainly tank performance by cranking up graphics settings, but I can't improve it *at all* by turning anything down. Vsync off, AA off, framerate limit off, textures low, every other graphics setting off... Still 55-59FPS with unplayable headache-inducing microstutter.

This kinda smells like a vsync / present chain related problem (or maybe a severe CPU/threading bottleneck, but I doubt it) to me, the behaviour is very strange.
With vsync off, I get ~1500FPS in the intro FMV, then ~140FPS at the main menu, then it drops to a consistent 55-59FPS as soon as I start loading a game, and it stays that way right through the loading spinner and into gameplay. If it were related to graphics settings I wouldn't expect the slowdown to hit until the save had fully loaded and it was rendering the game scene. Vsync settings in the windows build do what you'd expect, but the native build behaves like there's some kind of just-under-60 FPS limit in place no matter what it's set to.

Even in a brand-new game, in a pretty-much empty sector, I can't get over 60FPS no matter what I do. Vsync appears to be always-on regardless of what it's set to in the display settings... and 60 isn't even the right sync rate since my desktop and my monitor are running at 75 (also freesync, which apparently doesn't work in-game either, at least not when running wayland-native).
The windows build in proton syncs at 75Hz just fine if the sector isn't too busy, and freesync works perfectly.

we will probably need more of the actual documents for your system to know what is up, since it would be system related at this point.

You will probably need to be more specific as to what "actual documents" are required. My system does not have any paperwork, nor a passport...
OS: Gentoo Linux 2.18 (python 3.14.4-final-0, default/linux/amd64/23.0/desktop/plasma, gcc-15, glibc-2.43-r2, 6.18.33-p1-gentoo-dist x86_64)
KDE Version: 6.6.5
Kernel: 6.18.33-p1-gentoo-dist (64-bit)
Graphics Platform: Wayland
Processors: 20 × Intel® Core™ i9-10900KF
Memory: 64 GiB of RAM
GPU: AMD Radeon RX 6700 XT
Storage: Samsung EVO 980 NVME 1TB (x2, mdadm RCocaineD 1), ext4.
Mesa version: 26.0.7
System CFLAGS: -pipe -O2 -march=native -flto=auto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wa,-mbranches-within-32B-boundaries -fvect-cost-model=cheap
lspci
vulkaninfo

What else would you like to know?

[gmjs]

Hello all!

After this came up again, I took a look at the GOG build and... I managed to reproduce the issue!

The good news is that we will be fixing this in future builds, so it should no longer be an issue going forwards.
In the meantime we cannot suggest any better solution for existing versions of the game, other than just doing what you're doing and enabling the logfiles.

Thanks to allpurposemat for help with this one!

- PG

Many thanks Egosoft! No launch issues anymore with Linux+GOG release @version 9.00.

[mobilex]

I have over 3000 hours in X4 on Linux though, so I can definitely say it works.

Works, yes. Works well... Not so much.
7.x (the last time I played prior to 9.0 release) had similar performance native vs. wine/proton, but many other variables have changed in that time so it's probably not particularly useful data at this point.

you may need a -prefer-wayland starting parameter.

Whether any of this really has any bearing on my question, or is just you two arguing as to the native build being a real supported thing (I can assure you it is), I am not sure...
In any case, I've tried forcing wayland on wayland, I've tried it forcing x11 on wayland (i.e. xwayland). I've tried gamescope, I've tried all manner of environment variables to override vsync/present mode, and I've even tried it in IceWM in a real X11 session - zero (and I do mean zero) difference in framerate.
The only thing that does make a real difference is renicing the X4 Main() process to RT priority - which gets me *displayed* framerates (ingame FPS display or mangohud) similar to wine/proton, but if anything makes the microstutter/frame-pacing problems worse.

There were a bunch of graphical updates in 8.0 IRC, so yes most of us had to turn down settings a bit. More I turned off volumetric fog, but I'm running at 100 FPS now late game with full megaplex and in system. So we will probably need more of the actual documents for your system to know what is up, since it would be system related at this point. The unfortunate thing with the Linux world is that every person's systems differ.

Do you have frame limiter set? I noticed that when you set the frame limiter to the same valve as your vsync framerate it produces stutter (the framerate is always lower by one so instead of 60 it hits 59). So I set mine to little higher value and the stutters dissappeared. I don't know if this is the exact reason why it happens but it fixed the stuttering for me.

[Rastuasi]

Works, yes. Works well... Not so much.
7.x (the last time I played prior to 9.0 release) had similar performance native vs. wine/proton, but many other variables have changed in that time so it's probably not particularly useful data at this point.


Whether any of this really has any bearing on my question, or is just you two arguing as to the native build being a real supported thing (I can assure you it is), I am not sure...
In any case, I've tried forcing wayland on wayland, I've tried it forcing x11 on wayland (i.e. xwayland). I've tried gamescope, I've tried all manner of environment variables to override vsync/present mode, and I've even tried it in IceWM in a real X11 session - zero (and I do mean zero) difference in framerate.
The only thing that does make a real difference is renicing the X4 Main() process to RT priority - which gets me *displayed* framerates (ingame FPS display or mangohud) similar to wine/proton, but if anything makes the microstutter/frame-pacing problems worse.

There were a bunch of graphical updates in 8.0 IRC, so yes most of us had to turn down settings a bit. More I turned off volumetric fog, but I'm running at 100 FPS now late game with full megaplex and in system. So we will probably need more of the actual documents for your system to know what is up, since it would be system related at this point. The unfortunate thing with the Linux world is that every person's systems differ.

Do you have frame limiter set? I noticed that when you set the frame limiter to the same valve as your vsync framerate it produces stutter (the framerate is always lower by one so instead of 60 it hits 59). So I set mine to little higher value and the stutters dissappeared. I don't know if this is the exact reason why it happens but it fixed the stuttering for me.

I have never had stutters, did you mean to quote reply me?

[GBscientist]

My game fails to start when loading from Heroic game launcher, and crashes after the splash screen when opening directly from the executables. Basically, I would appreciate any direction as to whether this is an Egosoft issue, or caused by my distro.

Required data:
Version 9.00 English, GOG Linux native
Modded with crystalfinder, RareModpartsSold, and shiptraderssellpaintmods
Terran Cadet start
Crashes before getting to the Egosoft logo movie
Only change that I can think of is Fedora 44 removing X11.

Here is a link to my Google Drive folder containing the Fedora crash reports and vulkaninfo output: https://drive.google.com/drive/folders/ ... drive_link

OS: Fedora 44, Plasma 6.6.5
CPU: Ryzen 7 9800X3D
RAM: 32GiB
GPU: Radeon RX 9070

[Rastuasi]

My game fails to start when loading from Heroic game launcher, and crashes after the splash screen when opening directly from the executables. Basically, I would appreciate any direction as to whether this is an Egosoft issue, or caused by my distro.

Required data:
Version 9.00 English, GOG Linux native
Modded with crystalfinder, RareModpartsSold, and shiptraderssellpaintmods
Terran Cadet start
Crashes before getting to the Egosoft logo movie
Only change that I can think of is Fedora 44 removing X11.

Here is a link to my Google Drive folder containing the Fedora crash reports and vulkaninfo output: https://drive.google.com/drive/folders/ ... drive_link

OS: Fedora 44, Plasma 6.6.5
CPU: Ryzen 7 9800X3D
RAM: 32GiB
GPU: Radeon RX 9070

Mods aren't generally supported in 9.0, especially any using Kuertees API and UI tools. If it CTD at the splash, that's a key sign of Kuertees being installed. Wholly unrelated to Linux

[steve_v]

Well, since apparently, contrary to the name of the sub, there is no real technical support to be had here (i.e. from anyone with access to the source code or inside knowledge of the architecture), I guess I'll answer my own questions as usual.

The microstutter can be ignored, it was all down to janky vsync behaviour and the fact that the in-game options are (still!) incorrectly/misleadingly labelled. This is a Vulkan application, please use vulkan present-mode names rather than this anachronistic windows-centric "on/off/triple buffer/adaptive' nonsense.

On the massive performance delta between Windows and GNU/Linux build:

Observation: The GNU/Linux build performs almost identically to the Windows build under WINE/Proton when NTsync is disabled - i.e. when wine is mapping windows locking semantics to pthreads calls rather than translating to kernel futexes in a manner specifically designed to mimic Windows behaviour.

Observation: The GNU/Linux build uses libpthread directly.

Observation: perf analysis shows every X4 thread (and especially known hogs like MassTrafficUpdate) spending large amounts of time (and sometimes the majority of their time) in pthread_mutex_lock.

Observation: Assigning X4 (and all its threads) SCHED_FIFO improves performance drastically (up to 20% in my test save), despite a near-complete lack of competing processes on the system. This suggests that the gain is not from increased thread priority, but the fact that SCHED_FIFO disables normal timeslicing and preemption, which will mitigate lock-contention and context switching overhead.

Speculation: Recent optimisations have specifically targeted the Windows CPU scheduler and Windows thread synchronisation mechanisms, while the linux port is still using POSIX threads (and probably an internal wrapper/emulation for the Windows primitives pthreads has no equivalent to) - which were absolutely not designed for the kind of fast mutex handling an "optimised" multi-threaded windows game-engine is likely to want.
This would explain why wine+ntsync outperforms native, and why graphics settings have no effect here - it's all cpu bound due to the threading / locking architecture.

So, the next time y'all feel like dogpiling that guy who claims "game be unoptimised"... Bear in mind that if they are talking about the GNU/Linux build they are probably right.
This game was not optimised for GNU/Linux, if it was it'd be using modern mechanisms like futex_waitv directly rather than burning cycles thrashing pthreads and fighting the cpu scheduler.

... Unless of course somebody familiar with the engine internals wants to comment, in which case I'll gladly be corrected.
From what I can see that isn't a common thing here, so until it happens I'll keep (somewhat) educated-guessing, with a side of bitching about lazy ports and being treated like a second (or third, if Linux+GOG) class citizen.

[S3nt1n3l]

Unplug/plug the peddles into the USB

Mind telling me the line for the device as it is shown with 'lsusb'?

I don't have the pedals but I can fake some just to cross check if X4 trips on something based on the ids/descriptor.

OK so I thought I would try this again, especially in light of the up coming patch 9 (woot woot)
Initially when I started the game I still had the same issue, so I hit google and this time an article appeared which provided me with the solution and what appears to be a permissions issue in UDev for the peddles.

Here is the fix I followed just in case anyone else encounters the same issue.

• Open a bash/shell and type

  Code: Select all

  lsusb

  This will list all your USB devices.
  For me my peddles come out as

  Code: Select all

  06a3:0764 Saitek PLC Flight Pro Combat Rudder

  Note the xxxx:xxxx number as this is VendorID:productID
• We need to create a new UDev rule with

  Code: Select all

  sudo nano /etc/udev/rules.d/70-saitek-combat.rules

  In the nano editor type this on one line

  Code: Select all

  SUBSYSTEM=="input", ATTRS{idVendor}=="06a3", ATTRS{idProduct}=="0764", MODE="0666"

  Replace the VendorID and ProductID for the device you are creating a rule for.
  Save the file
• Final step run the following

  Code: Select all

  sudo udevadm control --reload-rules && sudo udevadm trigger

  This reloads the rules
• Fire up the game and check the device appears in the settings. For me this worked

The MODE=0666 translates to the following permissions, Read/write access for everyone on the system

Hope this helps