-
Posts
2,419 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by lo-fi
-
That's reassuring, as it's exactly where I thought I'd start looking. Yep, the anchor position needs to be where the contact point game object sits at fully extended suspension travel, so a calculated offset from the parts rigidybody to here. The anchor point is indeed defined in local coordinates of the game object of the rigidbody its applied to. I think all the funkyness is happening somewhere in here. I'll keep to confirm, but I think the root GO of the part has Part applied, as well as rigidbody. . . Which in my testing case shouldn't be the problem, as it's in the same orientation as the "wheel" GO where the wheel collider component is applied and references position from. Ultimately, I'll have to do some scalar products to determine the wheel orientation against the part and set the joint axis correctly, but for now I just have to figure out why it's all back to front when they're in the same orientation! The anchor object gets positioned correctly in Start(), but the moment the joints are connected to them, it all goes berserk and they get forced into the wrong place.
-
@TARDISES beat me to it, but have another one for good measure.. @V8jester, that's awesome as ever. IR rework being put to good use, I see I'm not really sure how much help anyone can be, unless they've got some magic bits of knowledge about the inner workings of KSP, and why vectors don't work like they do in plain old Unity...
-
Ah ha, I finally managed to make some progress. The script gets added to the gameObject where the wheel collider is: Super hacky, but this is what I'm using. using System; using System.Collections.Generic; using System.Collections; using System.Linq; using System.Text; using UnityEngine; namespace KerbalFoundries { public class WCReplacer : PartModule { public override void OnStart(PartModule.StartState state) { base.OnStart(state); if (HighLogic.LoadedSceneIsFlight) { StartCoroutine(WaitForFixed()); } } IEnumerator WaitForFixed() { print("WCR waiting for fixedupdate1"); yield return new WaitForFixedUpdate(); print("WCR waiting for fixedupdate2"); yield return new WaitForFixedUpdate(); print("WCR waiting for fixedupdate1"); yield return new WaitForFixedUpdate(); print("WCR waiting for fixedupdate2"); yield return new WaitForFixedUpdate(); print("WCR waiting for fixedupdate1"); yield return new WaitForFixedUpdate(); print("WCR waiting for fixedupdate2"); yield return new WaitForFixedUpdate(); print("WCR Fixing colliders"); foreach (WheelCollider WC in this.part.GetComponentsInChildren<WheelCollider>()) { print("WCR Found collider"); print(WC.gameObject.name); SLWheelCollider SLW = WC.gameObject.AddComponent<SLWheelCollider>(); Destroy(WC); } yield return null; } } }
-
Right.... overuse of debug messages to the log reveals that the anchors are created successfully in the correct position, though they are not visible... I can't figure out why. Presumably something to do with shaders, though I've run out of energy to fight with KSP to figure out how to apply a KSP shader - bla, bla, bla. The rotation of the anchors is set the same as the wheel object every frame, and in any case, the angular drives are set to free, meaning the cannot impart any torque back to the connected object. I'm bored, frustrated with something that clearly doesn't want to be for a game I don't play any more, and about to give up.
-
Interesting and frustrating in equal measures I wonder whether it's to do with the way KSP moves the coordinates around as part of KrakensBane, and it's disturbing the position of the joint contact points. I'll need to set up some serious logging and debug stuff, but that's my chief theory for the moment.
-
We do have a very different system now built entirely from scratch, which shouldn't suffer those issues. Or, at least, I can't see why it would, but that doesn't mean there isn't something weird going on. The tracks do indeed work exactly that way, though I've only been testing the new colliders with simple wheels so far in game. I'll get stuck back in on my return from Norway, and hope there's a simple explanation.
-
Sorry, I ran out of time before I left! Basically, I made a part module that searches the part for wheel colliders, removes them then adds in ours to the relevant game objects. I'd modified KFModuleWheel to look for SLWheelCollider and utilize it the very slightly different way in needs, mostly to do with the hit info. At the moment, it goes bonkers, so I was looking at stripping a load of stuff out of the plugin and enabling some debugging info and debug lines in to see what the hell is going on. We're talking explodes the runway, makes the wheel parts go odd shapes and phantom forces the craft into orbit kind of crazy.
-
Thank you - and I'm sure I speak for shadowmage too - it is appreciated. If it weren't for all the brilliant, crazy people who have stuck with us over the years, we wouldn't be here doing what we do. It's certainly been an interesting journey, and I hope the knowledge, discussion and open forum will benefit other projects in the future, and not just for KSP. You'd be amazed how often I bump into my own posts when researching - it's cool, but rather frustrating. I'm currently stripping a model and the plug in right back to basics to work up from there, which will hopefully let me see what's going on. Stay tuned Oooo, Ackerman. The proportional steering in the stock stuff didn't actually work properly when I tried it. I had to wonder if our work had an influence, though! I might revisit the Ackerman thing.