steve_v

I'd be surprised if someone hadn't, seems like an obvious solution to me. Of course one would have to roll your own ground-contact detection, suspension, friction, all the other stuff that comes with the existing wheel system... but I don't see why it couldn't be done. I can only speculate that it comes down to "no off-the-shelf solution available, too much work to implement in-house".

So why not multiple raycasts radially from the centre of the wheel? I don't know Unity, but I don't see any reason for raycasting only in the direction of gravity.

True, that is an exaggerated example. That said, I have had aircraft catapaulted into the air on hitting a slight change in gradient many times - cockpit parts have a sloped underside resulting in nosegear castor, wheel hits uphill slope and stops dead then springs back. Excessively energetic bouncy-bouncy when landing on rough terrain, same cause. Perpetual-motion bounce-o-matic aircraft? The runway jitterbug? You guessed it. Never had a wheel stop dead at the bottom of the slope driving down off the runway? I have. Tired of having to make sure your landing gear are perfectly perpendicular to the ground to avoid physics jank? I am. Probably true, though I have to wonder if all the time spent on band-aids for dodgy wheel colliders would have been better spent on fixing the fundamental issue. Wheels in 1.2 seem better, but going by various comments I have seen (along the lines of "suspension settings must be precisely tuned to each other" & "wheels must be perpendicular to the terrain" ) and the explode-o-matic rover ("That's not nominal!") I saw on one of the pre-release streams, it's just better band-aids on the same old guff. My own experiences with wheels in 1.2 are similar, and not much removed from 1.1.*, just somewhat less jumpy and much less fragile. Dare I say it, a better workaround - though I'll also say they're damn near indestructible now. It would appear the story is much the same with landing legs - landing legs that kerbals can now walk right through. AFAICT, this is the latest workaround for, wait for it... The single point collider reacting to an instant 'no kerbal under leg' -> 'kerbal under leg' transition, with explosive results. Down with the over-simplified not-wheel not-landing leg single point wheel colliders, and the many problems they cause. --- A very quick search turns up UWP, clearly it doesn't have everything KSP needs, but this kind of thing certainly can be done. Multiple raycasts or possibly sphere-casting would result in much better behaviour on rough terrain. A true 3D tyre would be even better, but one would have to watch the performance overhead.

Like I said, they're not-wheels. They have always been not-wheels and all the ongoing wheel related drama, since day-one, is due to this over-simplified single-point wheel simulation. Wheel is not a wheel -> re-invent wheel. Physics sim is not realistic enough -> fix physics sim. Reliance on unity builtins / third-party plugins limits functionality -> write better unity plugin.

If the prerelease is anything to go by... nope. They're still not-wheels.

They may be sleds, but they sure aren't round. I'll call wheels 'fixed' when they actually have round colliders rather than points, and work with >15° caster. As far as I am aware the "wheels" in 1.2 are still ⤓, not ⍜. Wheels should work when mounted sideways or upside-down too - wheels are supposed to be circular, and circles don't have an up and down. This goes nowhere, because those are not wheels. Wheels are round. Wheel: A circular object that revolves on an axle and is fixed below a vehicle or other object to enable it to move over the ground. --- It will quite happily slide around sideways under reaction wheel torque, however. Perhaps not so far off with the 'sled' bit.

Post logs, for a start. Probably best to open a new thread in the tech support section for that. Read this for log locations etc.

Of course. Furiously submitting more as I type this. It would appear the 'aim camera' bug is on the tracker too, surprise surprise. I was until recently, now I'm only playing for testing purposes. 1.0.5 is too slow, and 1.1.3 is too crashy. 1.2 is looking like a better prospect, time for more testing. Lets see if SQUAD actually fix the bugs we raise in the prerelease... this time.

It's only the LT-1 that does that, so there is hope that it's just something that got overlooked. (QA, cough cough.)

Seeing a little bit of "iffy" TBH.

11496

I took a copy of my clean 1.1.3 install, downloaded and ran the 1.1.3 -> 1.2-pre patch. I could only find a Windows binary, so I opened it in wine... Didn't work at all. Where's the patcher at SQUAD, you know, the one you were going to fix for the 1.2 pre-release? At this rate, I have my doubts. To elaborate, from the bugtracker: Seen zero progress on fixing it since then, it worked again for one release (untouched AFAICT) then promptly broken again. Yeah, right. This bug report is now closed. The patcher still does not work.

Hmm, maybe I'm just that good. Haven't played without FAR since 0.90-ish, threw something together that looked 'bout right (with no intention of going to space, just testing landing gear), pointed up a bit and made orbit with almost no pilot-input. Seems too easy.

Here's a quick (and possibly dumb) question: With this fancy new flow priority thing, how do I transfer fuel from one tank to annother? Ye olde mod-click on two tanks gives me no in/out pump buttons. Wait, no, nevermind. I'm just going crazy. Ed. ----- Have rapiers had a buff, or am I just used to FAR? SSTO spaceplanes seem ridiculously easy now...

I'd go further than that: A seperate install would be best. It's not even the final 1.2 release yet.

That would be most wise. Mods are not yet updated, the changes are non-trivial so many will be broken, and it may take a while before everything you use is ready. It's also a prerelease, so it's still a moving target.

Going for first 1.2 compatible mod? Actually a pretty usefull tool to have for testing the prerelease. Ta.

Well well, finally got me a copy and I must say: it looks rather shiny, so far anyway. No crashes yet either. Very nice.

Yup, the pre-release is here... and so is "KSP Server Migration!" apparently, half way through my download. Awesome.

Had issues after removing a mod (Quiztech Aero, FWIW) referenced in both completed and potential (but not active) part-test contracts. Log throws: Contract: Exception while OnLoad() or SetupID() on contract Test Part landed at Kerbin., exception System.NullReferenceException: Object reference not set to an instance of an object at Contracts.Parameters.PartTest.GetHashString () [0x00000] in <filename unknown>:0 at Contracts.ContractParameter.get_HashString () [0x00000] in <filename unknown>:0 at Contracts.Contract.SetupID () [0x00000] in <filename unknown>:0 at Contracts.Contract.Load (Contracts.Contract contract, .ConfigNode node) [0x00000] in <filename unknown>:0 Followed by: NullReferenceException: Object reference not set to an instance of an object at Contracts.Parameters.PartTest.OnSave (.ConfigNode node) [0x00000] in <filename unknown>:0 at Contracts.ContractParameter.Save (.ConfigNode node) [0x00000] in <filename unknown>:0 at Contracts.Contract.Save (.ConfigNode node) [0x00000] in <filename unknown>:0 at Contracts.ContractSystem.OnSave (.ConfigNode gameNode) [0x00000] in <filename unknown>:0 at ScenarioModule.Save (.ConfigNode node) [0x00000] in <filename unknown>:0 at ProtoScenarioModule..ctor (.ScenarioModule module) [0x00000] in <filename unknown>:0 at ScenarioRunner.GetUpdatedProtoModules () [0x00000] in <filename unknown>:0 at Game.Updated () [0x00000] in <filename unknown>:0 at GamePersistence.SaveGame (System.String saveFileName, System.String saveFolder, SaveMode saveMode) [0x00000] in <filename unknown>:0 at TrackingStationBuilding.OnClicked () [0x00000] in <filename unknown>:0 And I can not enter / exit buildings. Removing all mention of offending parts from save file has fixed it, just a FYI. Can probably repro w/save complete log etc. if needed.

New option to apply padding on startup causes my game to not start up... nothing interesting in the log, just never makes it to the initial loading splash. Not sure what else I can say, nothing is logged that I can see.

In most games, sure. Don't bother testing that part of the map because you can't get to it without cheating, etc. But KSP is essentially a sandbox, there are no real guidelines as to how one should play it, so to a certain extent there's no such thing as "things that people would more likely do". To wit: making hinges out of thermometers or bearings out of landing-gear. Who would have thought? And when you're still adding features, leaving edge-case bugs unfixed will likely bite you in the donkey later on...

Er, that's what QA testing is all about. To pull random internet quote I saw recently: QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv. — Bill Sempf (@sempf) If the bartender says: "We don't serve sfdeljknesv here", all is well. If the bartender vanishes and the player falls through the planet, not so much. Adding "Do not order sfdeljknesv at the bar." as a footnote in the game manual is not a good solution. WRT KSP: If you do something wacky in game, and the physics engine delivers a realistic result (within game definition of 'realistic') then that's cool. If it causes the universe to implode, violates the laws of motion / thermodynamics, accelerates parts to impossible velocities, or causes any critical physics parameters to become NaN, then it's a bug. What Danny2426 does could well be called edge case testing. If KSPs physics engine did not have bugs, we would not (and we should not, IMO) have kraken drives. As physics simulations go, KSP is a bit wacky - that's cool, if it's by design. But the universe going kablooey because the player does something unanticipated is a QA fail.

RL reactors are no less reliable than rocket engines, and kerbal rocket engines never spontaneously explode, so I dunno about this. Movie plots aside, actual reactors are very difficult to cause to explode, violently or otherwise. Much more difficult than say, a large tank of explosive fuel... Seems that despite using rubber bands to hold things together, kerbal engineers can churn out large numbers of 100% reliable engines, so why not reactors too? Entertaining perhaps, but not particularly realistic. Nuclear reactors ≠ nuclear weapons. By this logic, engines should have a random risk of exploding too, fuel tanks of leaking, command pods of catching fire, etc. etc. I'd quite like to see something like this, but applying it only to reactors seems a bit silly IMO.

Use the current incarnation of KSP wheels, sooner or later somthing screwey will happen. Land on some landing legs, watch craft slide uphill. Climb a ladder against an obstruction. There are more, see kraken drive.