steve_v

[sorting key][role][design#]-[revision]-[variant] Special craft sometimes get special names though.

I have been arguing for a complete overhaul (read in-house rewrite) of Unity's janky wheel system since KSP started using it. Squad has been "tweaking" it, rather ineffectually it would seem, with nearly every patch over the same period. A number of band-aid fixes have been applied (autostruts, disabling collisions, exposing spring variables etc.) and yet wheel physics is still thoroughly unrealistic, unpredictable, and frustrating for players. When is this going to be fixed properly @SQUAD? The old wheel system was at least reliable and usable, while the new one is anything but and brought precious little in the way of desirable features. Ackermann steering is not worthwhile upgrade if it comes with perpetual-motion machine springs and unpredictable physics failures. The Unity WheelCollider horse is glue, please throw it out and write something that works properly. The problem, if I am correctly interpreting it as the same one I have seen in several situations, is not the breakingforce of the wheels. The problem is the screwey suspension physics code that makes them go mental and generate ridiculous forces, in many case forces which are capable of destroying any wheel. It's the same problem that makes craft vibrate on the spot, and aircraft landing gear bounce up and down perpetually. It's Unity's crap wheel system. FWIW, It's also massively exacerbated if you let the suspension bottom-out.

Excellent. I don't see NearFutureFissionGenerator.cs anywhere in https://github.com/JPLRepo/REPOSoftTechKSPUtils/tree/master/ though, despite it being referenced in BackgroundResources.csproj. Slightly confused. I am looking at the correct repo, right?

I can confirm this, I was getting the same and worse with the two installed.

In a halfhearted kind of way, updates are finally coming, apparently:

The behaviour of stock wheels has been at odds with rational physics since 1.1 and there's little one can do about it. There are spring and damper settings available when advanced tweakables are enabled if you want to fiddle with them, you might find something that works.

The patch is source code. It's a patch. A plain old unified diff to be precise, no compiled code anywhere. I specifically refrained from posting compiled code out of respect for you and a desire to avoid causing you support problems. My link is hosted on a machine with a self-signed certificate, as the error presented should have informed you. Self-signed certs don't actually bite, and your definition of "unsafe" clearly differs from mine. It's a text file. If you don't want it, suit yourself. If you insist, the licence might as well inherit from the code it's a patch against - in this case CC BY-NC-SA 4.0. I'd prefer WTFPL, but whatever. Source code is self-evident. Had you actually looked at my changes, you might have noted that it's somewhere around 10 minutes work. 10 minutes work for me that is, one who doesn't really know what they're doing. If you need a vote to decide whether or not that would be a worthwhile use of time so be it. This has been asked for both here and over in the NF thread in the past. Wow. Just wow. Remind me not to be remotely helpful or share any solutions in future.

No need to apologise, I did say I had no idea what I was doing. If you were to delineate those rules though, I might be able to do better next time.

Perhaps so, but it still frustrates the hell out of me because it doesn't have to be so. The laziness of the many simply overwhelms the effort of the few. Many people, small individual changes, problem defused. Easy, right? Then the old proverb regarding horses and water crops up.

It's astonishing, and somewhat disturbing, how willing people are to give up control of their stuff for a little convenience. All those games you guys own on steam, valve can disappear them whenever they want and there's nothing you can do to stop it. The online communities you build through steam, valve can demolish at will. Centralisation leads to concentration of power, and that truly sucks. Bring back self-hosted online gaming I say.

That's why I pretty much only buy games on GOG. I have zero tolerance for DRM, and Steam is garbage.

This will date me, but back in highschool we had old 486 machines for typing class (which everyone found deadly boring), so we hacked DooM's serial multiplayer to run over the LAN using the network driver from an old file-transfer program whose name I forget Fastlynx for DOS? It was about all those machines could handle, but it was fun. More fun than typing anyway. There was also TankWars, we all kept a disk with that on it for a quick match.

The most disruptive thing I did was to install StarCraft on every machine in the school remotely, with a modified network worm. Unfortunately it included a minor oversight (not deleting temporary files properly) that caused it to consume all the disk space on the main fileserver, for students and teachers alike. People were displeased. Other than that, we were pretty careful not to draw attention to ourselves.

I remember running rings around school IT as being a rather entertaining passtime myself. By the end of the whole school thing myself and a small group of like-minded individuals had the keys to the kingdom, so to speak. Admin passwords, backdoor into the fileservers and routers, the lot.

Unless there's been a revolution since my school days (and schools have now got better filtering than large corporations), I seriously doubt they're undefeatable.

Of course I like it. It works well, and it does it with a nice clean C interface that makes proper use of the input subsystem. What's not to like. How Unity can make such a hash of input handling really does baffle me. Even with SDL middleware in the mix they still manage to screw it up.

Dunno TBH. If it was mine I would, it's rather good. I didn't have any problems building or setting it up, but annoying questions are inevitable if you make a thread... I guess it comes down whether or not you can be bothered dealing with users.

Unlikely to be a problem, I've been compiling other peoples code for a long time. Sometimes I even compile my own, but that's strictly for slow days. Thanks for it not being a VS project with a bunch of batch files and postbuild events I have to eviscerate, those are a pain in the ass. I'll be sure to have fun with it. I think I still have a namespace-magic wrapper around here somewhere, it should do for hiding those device nodes. Unity's input handling on GNU/Linux is a disaster and has been for a long time. Frankly, the new one looks to be a step backwards.

Err, I'm runinng GNU/Linux, can I convince you to share?

In my case, it's a factor of both. CPU's don't do a whole lot without a mainboard to plug into. Your typical is not my typical. I have 30TB of storage on this desk. If you like your cheap mobo causing yo grief, that's cool. I don't. Case in point, last week had to sort out a machine that randomly resets 3-4 times a week. Can you guess which component was at fault? Do you think it was a high-end board or bargain-basement?

Primarily, bandwidth between the CPU and other components, like the main memory and the GPU(s). Really? I had 2 GPUs until very recently, and this box has 4 SSDS, 2HDDs, and 8 memory DIMMS in it. Quad-channel bandwidth bonus for the RAM because I have a nice board. I prefer not having them to begin with, see comment on Gigabyte boards. Do a real throughput test with many connections, and have a look at CPU load and retransmit rates. Compare to non-trash NIC. Realtek chips are what you find on bargain-basement no-name NICs, and there's a reason for that. Intel chips are what you find on server NICs, and there's a reason for that too. This I do agree with. There's no reason you can't have decent quality without the silly lights though.

Crossposting in case anyone else wants TACLS working with NF reactors:

The motherboard does most certainly matter. Quality of components, number of power rails and regulator phases, heatsinking, chipsets used, I/O bandwidth and expansion capacity, BIOS bugs, it all matters. Personally, I wouldn't touch a Gigabyte board with a very long stick. I don't know what their quality is like these days, but I've had rather unpleasant experiences with them in the past. And avoid anything with Realtek network chips, they're garbage.

@JPLRepo Can we please have support for the Near Future FissionGenerator module in BackgroundResources? Pretty please? I'm probably going to give it a prod myself at some point (once I set up a dev environment that actually works), but to be honest I don't know C# from a porcupine. I'll try anything, but it's going to be rough. It looks easy enough to do, from a casual peruse of the source... I bet it'd be a lot less pain for someone who knows what they're doing though. ed. So I have a thing, and it seems to work... or at least my nuke powered ships don't kill crew in the background any more. Since I have neither a github account nor the motivation to learn to use it, here's an oldschool patch against master. CC BY-NC-SA 4.0, 'cause it needs it apparently. Credit to JPLRepo, again, 'cause whatever. It's probably wrong in some way as it's based entirely on "this code looks like it does foo, but I don't know the language", but it works for me .

[snip] The one in the github master tree, which contains the commit I linked. CKAN, right... Several mod authors say "CKAN: no support" for good reason. In this case it's not there because CKAN pulls from the release zips not the master tree. If you want the fix you'll have to go download it. Your loss. Getting a single file from github (or fixing it yourself for that matter) isn't all that hard, but if you want to keep experiencing this bug knock yourself out.