Hi Everybody,

Is X-Plane 12 allowed to have more than one entry in its shortcut? For instance I run reshade so I have my XP12 shortcut setup as shown below. Renaming Xplane 12.exe to FlightSimulatior.exe has removed all issues with reshade, no more crashes. I now have both exe files in this folder so any updates to XP12 will work as normal.

"C:\X-Plane 12\FlightSimulator.exe" --allow_reshade

I would like to add the following for my AMD 7950x3D CPU

--num_workers=7

I haven't tried this, is this possible?

"C:\X-Plane 12\FlightSimulator.exe" --allow_reshade --num_workers=7

Wait, what? You renamed the exec and it doesn't crash? How about when you switch airplanes or change to a different airport? That is what plagues me anytime I do certain things. That and some plugin windows can't be closed without a crash - I can open but not close them. I've learned which plugins work with Reshade and which don't.

So regarding stacking the command line entries - I think you can. Try reversing their order and if Reshade comes up both ways, you can probably assume the workers will too.

What is the purpose of the workers again? I had that some time ago but it didn't make any difference that I remember.

EDIT: I tried renaming the exec and it still CTDs when I change aircraft. No joy.

Edited April 12, 20242 yr by dolph98

1 hour ago, dolph98 said:

Wait, what? You renamed the exec and it doesn't crash? How about when you switch airplanes or change to a different airport? That is what plagues me anytime I do certain things. That and some plugin windows can't be closed without a crash - I can open but not close them. I've learned which plugins work with Reshade and which don't.

So regarding stacking the command line entries - I think you can. Try reversing their order and if Reshade comes up both ways, you can probably assume the workers will too.

What is the purpose of the workers again? I had that some time ago but it didn't make any difference that I remember.

EDIT: I tried renaming the exec and it still CTDs when I change aircraft. No joy.

I don't have any issues changing airports and I only use the Zibo mod 737. Another plus of changing the name to flightsim, you get additional reshade filters available via nvidia experience, although I use reshade. For the workers, I want to specify how many workers simultaneously send data to RAM.

Good idea swapping the entries, going to give that a try.

Edited April 13, 20242 yr by Mike_CFII_MEL

1 hour ago, Mike_CFII_MEL said:

specify how many workers simultaneously send data to RAM

It doesn't make a huge difference in terms of number of threads spawned. Do you see much difference in performance?

17 hours ago, blingthinger said:

It doesn't make a huge difference in terms of number of threads spawned. Do you see much difference in performance?

I'll be checking today to see if there is any difference that's noticeable. 

On 4/13/2024 at 11:47 AM, Mike_CFII_MEL said:

if there is any difference

Anything?

I was curious in linux land too. If anything I lost a couple FPS. I don't think most of those threads are doing much yapping at RAM most of the time.

8 hours ago, blingthinger said:

Anything?

I was curious in linux land too. If anything I lost a couple FPS. I don't think most of those threads are doing much yapping at RAM most of the time.

I noticed additional stutters, will be removing the entry.

Doesn't "num_workers" only specify the maximum number of threads for scenery loading?

That would make sense if it was the case (and/or documented somewhere).

Can confirm. Seems to be a scenery load thing. Very useful if you've got either a highly overclocked CPU that pushes temps when fully loaded, or if scenery is stored on a spinning rust hard drive given that they tend to not really like massively parallel read/writes very much.

Edited April 16, 20242 yr by blingthinger

I goggled it and I can only find anything having to do with Python. Doesn't seem to be a Windows trick. Could it have to do with AutoOrtho?

 

Edited April 16, 20242 yr by dolph98

It's independent of OS. I jumped down the rabbit hole and rebooted to windows a bunch of times. I timed sim startup into default KPDX with ortho and default acft:

 

Reboot before each sim load:

workers = default, load time = 2:20

workers = 4, load time = 2:34

workers = 3 (2 didn't seem to work for some reason), load time = 2:40

 

No reboot:

workers = default, load time = 0:43

workers = 4, load time = 1:00

workers = 2, load time = 1:20

 

There's very clearly a difference on my system but it isn't drastic. I actually like this flag (aside from the lack of documentation). All this is running on a HDD. Reducing HDD thrash is a good thing in my opinion. Fewer threads banging on the drive means less wear. I'll gladly sweat out that extra 20 sec.

I don't run autoortho so can't attest to that behavior and imagine there would still be a difference given that the threads look to also be processing the data, not merely doing the drive read work. So maybe it doesn't matter if it's AO loading cached files or network download, there might still be a visible difference??

Also, I imagine this would be less obvious on a SSD.

Edited April 16, 20242 yr by blingthinger

I think that initial load times aren't that good of an indicator. Testing complex ground scenery like X-America/Europe with default mesh while loading a tile in-flight should be much more indicative as too little scenery workers mean longer DSF load times and thus framerate drops and some stuttering.

Can't think of a use case for limiting scenery workers either. File read sequencing is managed by the HDD/SDD controller, while clock speed and thus thermal management is completely up to the CPU. If anything, one would exchange maybe slightly higher framerates (due to less communication between processes) for less smoothness (longer scenery loads and thus the aforementioned stutters).

And as far as I know Autoortho has its own tile downloader workers. At least there should (still) be a config entry to manage their amount.

Edited April 16, 20242 yr by Bjoern

A dsf is a dsf. Initial load in is worst case scenario because it's doing everything, not merely the next batch in the flight path.

HDD/SDD are not in the same category. I'm not questioning the controller capabilities or limitations. I'm looking to reduce the HDD armature movement over time. No need to thrash the drive unnecessarily.

I'll run with this for a while and monitor jitter during a session. I imagine with spinning rust it will be about the same.