Ruedii

As a note, I noticed that the launcher is running swiftshader for EGL and Vulkan function. This should be entirely unnecessary. Nearly all modern GPU drivers provide EGL and Vulkan support. This is possibly causing problems when launching, and likely reducing the performance and bloat of the launcher.

The latest version of the launcher shipped by Private division crashes on Linux Steam under proton. This is a BLOCKER for being listed as supporting Steam Deck for KSP2 and all Private Division Titles relying on Proton to run on Steam Deck. It also is a blocker for many other issues. Here is an upload of my crash logs so far. https://gist.github.com/Ruedii/84ffdc5e26ade36207ddac433c79b6e7

The Launcher frequently crashes, still. Many times when the launcher self-patches, it will crash on load every time you try to play the game. Usually the only workaround is to uninstall and reinstall the game. Typically, this happens when the launcher patches itself wrong. It has come to my attention that Windows users are experiencing similar issues as well, so it might not be entirely Proton related, so much as just a problematic launcher that keeps shipping bad patches to itself and getting itself stuck in an unusable state. Sometimes said patches only affect proton users, sometimes they affect some Windows users with certain configurations as well, sometimes they affect everyone. It really is problematic. If Private Division can't get the launcher in working order, I really think that Intercept Games needs to find some way to either skip the launcher altogether (Private Division might not like this) or set it to run in a silent mode by default to reduce bug exposure by executing fewer functions in the launcher. (This may be their only option.) They need to file a feature request to allow users to "not show launcher" and just have it log you into the Private Division account, if you have provided login data or your steam account is linked, and then just chain-load the game without showing anything. Ideally it should chain-load the game first in silent mode, then log you in while the game initially loads, before passing the login token to the game and self-quitting. Ideally it can leave a DLL loaded for functions used by the game once the game actually uses some of its functions for things like multiplayer.

KSP 1's early access release was closer to a proof of concept than anything else. Yes, especially the number of people refunding after trying early access, only to buy it again when the game is complete and optimized several years later. This is so common in early access games, it has spurred an acceleration to get that first demo out to counter it by bringing expectations for the "current state" in line with reality. Many early access games release their first demo BEFORE release for this reason. I don't mind paying for an incomplete game, but many others do.

I think you need to remember the difference in performance between early access launch and 1.2 release in KSP. The early access launch version would grind most computers to a halt.

Is it safe to assume that a Radeon 5500XT would be sufficient, as it's only slightly lower speed. (I got the high VRAM model, so VRAM capacity won't be the issue.) I would presume there would be some "undesirable" issues with it, like slower loading times. I also presume you are going steam deck certified at launch, even if you aren't releasing Linux native initially.

I've been a little busy, been testing two new Indie games for fun and personal experience, plus the new experimental on Satisfactory. I hope I can get back to it soon. I probably should find some time to get up the Github repo to index what needs to be done slowly.

I've updated my system, so I'm going to do a super clean test on a much more typical Kubuntu 22.04 install with no other mods but Module manager, and installing by zip. This will also isolate for CKAN nonsense. Worst case, I have to rewrite the script to be (much) simpler. You shouldn't have to use the current directory stuff, but instead should use the directory the script is in. I'll have to find the environmental variable that reads that. The entire script is doing a lot of stuff the hard way. Just CD the directory and work everything relative is how it should work. No over-(ab)use of environmental variables. It looks like the string filters need to be adjusted too. As a note, on Windows I recommend testing bash scripts in WSL2 these days instead Cygwin. You could also use MinGW. Cygwin is dreadfully out of date these days due to better options being available.

I'll see if this is a bug in my current release. I currently am do for a distro update, and have been waiting on doing it until I install my new SSD. I will probably go and do the distro update today or tomorrow.

Update: setting executible and running from command line as an executable fails. Anyhow, I'm stumped for now. I'll come back to this later. I've got other things to do today. First got to run errands (stupid store hours changed again, so no late night grocery run.) Then I need to work on the wheel files for Airplane Plus and Grounded. If that goes well I might pull over the work on some of your mods, including SXT. I've been working on reverse engineering those wheel module configs, and I think I've figured it out. I just need to verify some things. I'll make sure to document the heck out of them, and maybe post up a page on the KSP Wiki. If you can't get it working, I'll write a new script from scratch by reverse engineering your batch script. BTW, Microsoft does ship powershell for Linux which can run .bat files. However, I don't know if there are any syntax changes. There is also a derivative of the open source clone of DOSKEY available for Linux. I'll look into those two. Powershell is a Mono app, so it can be shipped as a module for CKAN. I don't know it's license.

It is notable that I did not set the executable bit and use ./CopyTexutures.sh This might change the way some of the code is interpreted. I will also try echoing it over to bash, to see if that fixes the interpretation. It is acting like it hasn't gone through the pre-processor. Going forward on my end, after I run some late night errands tonight, I will go and attempt other methods to run the script to see if it fixes pre-processor behavior. I'll first try setting the executable bit and running it as a standard script with "./CopyTextures.sh" If that doesn't work I will attempt two other methods using pipes: bash < CopyTextures.sh cat CopyTextures.sh | bash I will also look into bash's command prompt instructions, as well as try zsh and busybox instead. BTW, next time just say it looks like we need to coordinate the troubleshooting, and we should do so on the forum post. Clearly there is a bug in the script or the instructions, but we have to figure out which one.

Syntax errors from texture copy bash script. I was told to post this here (I have no clue why, syntax errors are a bug.) I'm getting a syntax error when running the bash script to copy textures. I am running it from a terminal prompt with command "bash CopyTextures.sh" I am using Bash version "5.1.4(1)-release (x86_64-pc-linux-gnu)" on Kubuntu Linux. I am getting the following error log: /n/nThis batch file will copy the missing textures from the inaccessable Squad/zDeprecated directory /n/n Press return to continue ./BashCopyTextures.sh: line 17: [: too many arguments ./BashCopyTextures.sh: line 18: cd: too many arguments cp: cannot stat '../../Squad/zDeprecated/Parts/FuelTank/fuelTankT800_v1/model000.dds': No such file or directory cp: cannot stat '../../Squad/zDeprecated/Parts/FuelTank/fuelTankT800_v1/model001.dds': No such file or directory cp: cannot stat '../../Squad/zDeprecated/Parts/FuelTank/fuelTankT400_v1/model000.dds': No such file or directory cp: cannot stat '../../Squad/zDeprecated/Parts/FuelTank/fuelTankJumbo-64/model000.dds': No such file or directory cp: cannot stat '../../Squad/zDeprecated/Parts/FuelTank/fuelTankJumbo-64/model001.dds': No such file or directory cp: cannot stat '../../Squad/zDeprecated/Parts/Structural/Size3Decoupler/decoupler_and_adaptor_cm.dds': No such file or directory cp: cannot stat '../../Squad/zDeprecated/Parts/FuelTank/fuelTankX200-32/model000.dds': No such file or directory cp: cannot stat '../../Squad/zDeprecated/Parts/FuelTank/fuelTankX200-32/model001.dds': No such file or directory cp: cannot stat '../../Squad/zDeprecated/Parts/Aero/protectiveRocketNoseMk7_v1/model000.dds': No such file or directory cp: cannot stat '../../Squad/zDeprecated/Parts/Command/probeStackSphere_v1/model000.dds': No such file or directory cp: cannot stat '../../Squad/zDeprecated/Parts/Engine/liquidEngine48-7S_v1/*.dds': No such file or directory cp: cannot stat '../../Squad/zDeprecated/Parts/Engine/liquidEngineSkipper_v1/*.dds': No such file or directory cp: cannot stat '../../Squad/zDeprecated/Parts/Utility/dockingPort_v1/*.dds': No such file or directory cp: cannot stat '../../Squad/zDeprecated/Parts/Utility/dockingPortSr_v1/*.dds': No such file or directory cp: cannot stat '../../Squad/zDeprecated/Parts/Utility/rcsBlockRV-105_v1/rcs.dds': No such file or directory /n/nThe files have been copied/n Press return to continue The errors that are notable are: "./BashCopyTextures.sh: line 17: [: too many arguments ./BashCopyTextures.sh: line 18: cd: too many arguments" As well as the fact that the "/n" marks are not being copied. I am wondering if this particular revision of the script ever worked, or if this is an issue with this particular version of bash not interpreting the script when run from the command line like this. It appears there are spaces and quotes where there shouldn't be in the script, as far as I can tell.

If I get around to it I'll start a Github page. I'm a little too tired tonight. If Blackheart wants to take back over, they can clone the archive or, I can give them shared authority if they want to share responsibility for it.

OK, checking out the config on the wheels. I'm comparing them to the "Rugged" TR2-L and standard rover "M1" wheel Missing all friction bias behavior values. Suspension range is WAY too low Suspension target is WAY too low, Spring ratio is WAY too low Steering curve is not using separate "steeringMaxAngleCurve" function Low End Torque is WAY to high. Max Brake torque is INSANELY too high. If you Blackheart wants I can go ahead and rewrite these entirely to start, then get on more sane weights for everything else. If they have a github page I can just upload the files once I get a working pattern.

The grounded wheels have always had INSANE torque. They also had high friction to compensate, but I think they are hitting the limit on friction. BTW: Progress on my investigation, I reduced the weight of the vehicle by removing all my extra stuff on my usual vehicle and it is indeed skidding all over the place. Even increasing the traction control to 5 doesn't help. I haven't tried switching to manual yet, though.

OK, I experimented with the regular rover wheels to see what is causing the weird behavior. It is clearly that too much torque is being applied to the wheels when too little weight is on them. I can replicate the behavior on brakes with the stock wheels using the Grounded partset for the body. The Grounded car bodies are simply just too light. I suspect increasing their weight will help, as trying to reduce the torque of the motor. (The fact I turn traction control up to maximum on my steering wheels, and I only have a single pair of wheels set to steer is likely why I haven't been experiencing issues while moving.) I will experiment more later by increasing their weight a tad in the configs.

You could do this with a script, but I think it might be more work to create the script.

Yes there is a patch to replace them, but it replaces the engines. It doesn't make a separate set of engines. Do you have mirror on?

It would be nice to get this fully integrated with one of the fuel switch mods for proper handling. (Possibly fork to do this, since this is so stable, and you don't want to fix what ain't broke.) The features I would like are outlined as follows: 1. Default addition to stock and major stockalike mods. 2. Panel to whitelist toggles of resource classes in each part or part group. (This panel should also be able to add fuelswitch to other part mods.) 3. Optional module manager integration to convert API from other major fuel switch mod info into it. 4. Tech level resource restrictions. (Best provided by hidden upgradable module that gets attached into all fuel parts with fuelswitch). This would limit part capacity of various items early on. For instance, not let you convert a fuel tank into a mega battery. Wishlist: 1. Panel to create custom tank combinations. 2. Said panel includes "LFO" which is a shortcut tank with default ratio liquid fuel and oxidizer. 3. Skin switching, and model switching with mod-optional decal switching tied to tank part, and efficiency/power switching for engines when you change their fuels.

As a note to anyone interested, I haven't run into any issues on KSP 1.12.3 It's not like a minor bugfix release of KSP is likely to cause problems. However, it is good to let everyone know.

For the most part, this works perfectly fine with the latest version of KSP 1.12.x The only issues I've had are two existing bugs being worse than before. 1. When the vehicle is at a complete stop, it slides around a little. 2. If you kick the vehicle with your Kerbal it will sometimes go flying surprisingly far. (I think the parts are too light.) My suspicion is that the parts are too lightweight and that is causing both of these issues.

Minor feature request: Could we get the LFO engine configurations for Near Future Spacecraft to make separate engines with LFO instead of replacing the Monoprop engines?

From what the mod developer has said, the primary blocker is that he doesn't consider the wheel physics to be satisfactory. They are usable, just not optimal. The other issue is that the prop curves got messed up due to physics changes in the more recent KSP versions. Additionally, the props aren't balanced against the stock props in Breaking Ground. Personally I find this a much bigger issue. His standards must be high, because those are very trivial issues. I'd say the pack is well beyond a usable state, and I'd recommend still using it. I'd give it a state similar to "Preview" level of quality. Still some bugs, still needs tuning. The biggest thing is if you design a plane with the part pack now, don't expect it to work 100% the same in future releases. There are about to be changes that will affect physics behavior.

Open Cockpit and Streamline are the best. Make sure to get their MiniAVC files updated.

I guess we have to go through one by one and find the problem ones, so they can be fixed. As of the slipping, the behavior of all wheels are different from earlier releases, but I find it an improvement. It might just be me and how I handle using the wheels. The big issue is how they slip when the brakes are locked is a bit different now. More realistic. As of prop curves, they needed adjustment since who knows when.