-
Posts
2,419 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by lo-fi
-
It does tend to jump around a bit, but I do have it fixed. License is GPL2, so no reason there not to redistribute, but a fork/pull request is probably more polite if we can get hold of pizzaoverlord. As for rolling a version into KF? There's a lot of stuff I don't fully understand, so maintaining it myself is going to be problematic. Oh, and I noticed the MM patch is still not right either.
-
I'm having a poke at it right now. use the .csproj from GitHub and the source from the .zip (GitHub seems to still be the 2.1 version for some reason). Though it seems that the target framework needs to be set to 3.5. I think I can see where it's all gone wrong, will update shortly. The spheres are there because you've been compiling it in debug mode, at which point the code in the #if DEBUG regions gets added. In this case, spheres to show positions.
-
Definitely be a lot of interest in that! Shout if you need any help
-
BTW, is anyone any good making RPM props and fancy a little project? I'm thinking the hitch needs an external camera and alignment indicator for use in IVA. I've got so much to do, I can't spare the time just now. I have to get the proper models done first, but worth asking about in case someone is available.
-
The spring and damper are annoying, they don't like being updated while the wheel colliders are active, so I disable th sliders in flight. What you can do is look through persistence for springRate and damperRate and change the values there so they get set at start of flight. It's something I want to revisit, but that's the best I can do for the moment I'm afraid.
-
Find Part of GameObject
lo-fi replied to lo-fi's topic in KSP1 C# Plugin Development Help and Support
Ah, thank you. That will recursively search up the hierarchy? -
*grin* Yes, I've almost got it nailed. Persistence is a little shaky at the moment, but might be best to hand it over to you guys for breaking and take it from there. I have one major thing to do before I do so, though: checking orientation being within limits before coupling. Otherwise the Kraken strikes! Thankfully I've got the tools to do that already in place Details aside, fundamentally this will work as a viable mechanic in KSP. Strut gun tie downs come next, they'll be easy in comparison.
-
Hi guys As the title says, I'm sure I remember seeing a method something like GOToPart(GameObject) that returned the instance of the part the passed GO is attached to. I can't seem to dig it out of the object browser and searches haven't turned up anything helpful, so I wonder if someone could point me in the right direction? Many thanks!
-
The poll in my KF thread suggests a lot people would like some more rover bodies, which might be a great place to start. If you're interested I can probably dig out a few of the suggestions for some inspiration. For example, I was thinking of doing a little rollcage type affair like the tracked bikes from Prometheus (though obviously minus the tracks so people can strap what they like to it), but haven't had time to get round to it. Someone told me, months ago when I started modding: "Do what you like and makes you happy". I can tell you now it's very sound advice, so I hope you find something that really fires your imagination
-
Thanks gentlemen! I'll do a little reading, then I think we've got this nailed. Next potential showstopper to deal with after that is persistence. Anything beyond that is incremental feature development. Man, I love creating something new! EDIT: The cheeky little cheat with the cross product sign against a normal works rather well. Yes, it needs refactoring and optimisation //this projects vectors onto chosen 2D planes. planes are defined by their normals, in this case _hitchObject.transform.forward. Vector3 hitchProjectX = _hitchObject.transform.right - (_hitchObject.transform.forward) * Vector3.Dot(_hitchObject.transform.right, _hitchObject.transform.forward); Vector3 attachProjectX = _couplingObject.transform.right - (_hitchObject.transform.forward) * Vector3.Dot(_couplingObject.transform.right, _hitchObject.transform.forward); Vector3 hitchProjectY = _hitchObject.transform.up - (_hitchObject.transform.right) * Vector3.Dot(_hitchObject.transform.up, _hitchObject.transform.right); Vector3 attachProjectY = _couplingObject.transform.up - (_hitchObject.transform.right) * Vector3.Dot(_couplingObject.transform.up, _hitchObject.transform.right); Vector3 hitchProjectZ = _hitchObject.transform.forward - (_hitchObject.transform.up) * Vector3.Dot(_hitchObject.transform.forward, _hitchObject.transform.up); Vector3 attachProjectZ = _couplingObject.transform.forward - (_hitchObject.transform.up) * Vector3.Dot(_couplingObject.transform.forward, _hitchObject.transform.up); float angleX = Mathf.Acos(Vector3.Dot(hitchProjectX, attachProjectX) / Mathf.Sqrt(Mathf.Pow(hitchProjectX.magnitude, 2) * Mathf.Pow(attachProjectX.magnitude, 2))) * Mathf.Rad2Deg; float angleY = Mathf.Acos(Vector3.Dot(hitchProjectY, attachProjectY) / Mathf.Sqrt(Mathf.Pow(hitchProjectY.magnitude, 2) * Mathf.Pow(attachProjectY.magnitude, 2))) * Mathf.Rad2Deg; float angleZ = Mathf.Acos(Vector3.Dot(hitchProjectZ, attachProjectZ) / Mathf.Sqrt(Mathf.Pow(hitchProjectZ.magnitude, 2) * Mathf.Pow(attachProjectZ.magnitude, 2))) * Mathf.Rad2Deg; Vector3 normalvectorX = Vector3.Cross(hitchProjectX, attachProjectX); if (normalvectorX[2] > 0.0f) angleX *= 1; //a bit redundant else angleX *= -1; Vector3 normalvectorY = Vector3.Cross(hitchProjectY, attachProjectY); if (normalvectorY[1] > 0.0f) angleY *= 1; else angleY *= -1; Vector3 normalvectorZ = Vector3.Cross(hitchProjectZ, attachProjectZ); if (normalvectorZ[0] > 0.0f) angleZ *= 1; else angleZ *= -1; EDIT2: had a facepalm moment when I realised I'd forgotten that only the X axis of a configurable joint can have asymmetric limits :/ This causes major problem in hitching because it means the limits are set relative to rotation between the tractor and trailer, not the hitch itself. Couple up with the tractor 20 relative to the trailer and the joint will over rotate to the right and under to the left. Currently looking at solutions, but there's nothing in the joint that allows me to set what the limits are relative to. It's all centred when you first create the joint, so it's going to take quite a creative solution to figure this one out! Luckily I don't believe in a no-win scenario...
-
Ah ha, that needs updating, then - completely passed me by. Thanks EDIT: Yep, that nailed it, works perfectly. Though as it returns the acute angle, I'll need to do a few extra checks to see which way the rotation is. Yes, no forward calculation needed, and that's what the joints use, so I converted to degrees. Indeed! Between you two, I finally got it straight in my head and converted into Unity-speak. EDIT 2: I see no reason why the joint can't be powered like IR. I've got the data and the axis all configured, so why not. Yes, I'm talking about a BV202 style steering linkage. Watch this space, I think we're on the verge of something completely new...
-
Thank you Ratchet Freak, that's most helpful! I'm looking to get the orientation of the trailer coupling, at the point you hitch up, relative to the hitch - so I think that means an arbitrary plane which we pick to be what we want to measure against. There are conveniently oriented game objects on either part that are used to grab the vectors from (_hitchObject and _couplingObject). So, for the plane between vectors: float angleX = Mathf.Acos(Vector3.Dot(_hitchObject.transform.right, _couplingObject.transform.right) / Mathf.Sqrt(Mathf.Pow( _hitchObject.transform.right.magnitude, 2) * Mathf.Pow(_couplingObject.transform.right.magnitude, 2))) * Rad2Deg; // translated to Unity C# and reading out as degrees. I think this is functionally the same as Vector3.Angle(Vec1, Vec2); And in the arbitrary plane. Could generate the plane normal using cross product, but as we know that right is the normal of forward and up (etc) (and a unity vector) we can use that? If so (and I'm making some giant leaps this is correct!!!): Vector3 hitchVecX = (_hitchObject.transform.right - _hitchObject.transform.forward) * Vector3.Dot(_hitchObject.transform.right, _hitchObject.transform.forward); Vector3 attachVecX = (_couplingObject.transform.right - _hitchObject.transform.forward) * Vector3.Dot(_couplingObject.transform.right, _hitchObject.transform.forward); float angleVecX = Mathf.Acos(Vector3.Dot(hitchVecX, attachVecX) / Mathf.Sqrt(Mathf.Pow(hitchVecX.magnitude, 2) * Mathf.Pow(attachVecX.magnitude, 2))) * Mathf.Rad2Deg; Both of which seem to work!! I'll do some more extensive testing and report back. Pretty much the same as Zodius was explaining earlier in the thread, but another explanation made it sort of click into place. EDIT: Yes, that seems to do the trick. Thanks guys! now I can use that data to set the joint limits up correctly, as well as prevent hitching beyond the limits. Awesome!!
-
Well, for us mortals who don't do this kind of thing in the day job Thanks, I'll have a nose through the links and see what I can figure out. I was surprised I could find so little (and damn the joint for not revealing the data to me when I know damn well it must have it), though I was possibly searching the wrong terms!
-
Ewwwww. Stats. Horrible. I'll get back to you on the configurability, still working through how to set it up. All axis of the joint can be independently controlled, though I'm currently dealing with issues related to the joint being created while the tractor and trailer are not perfectly aligned. The limits are relative to how things are when the joints are created, so some measuring and calculation is required to make it behave properly. But it is freakin cool!
-
Odd that it'd be the surface repulsor, though. Unless the progress indicator is lying and it's actually stuck crunching the rover body texture, which is massive and I still haven't got around to fixing. I think it's probably next in the loading order after RepulsorSurface, so that may be it. - - - Updated - - - Alright, I got this: Imposing limits on the coupling is easy, and I can even make it tweakable. Next up is to see what I can do about recreating the joint when the scene changes back to flight or physics kicks in. This will, no doubt, be harder, but after that I'll release it to dev so you guys can do what you do best and break stuff
-
Yes, that's the bit that worries me :/ Still, the only way to find out is to give it my best shot! It's possible there is some kind of intractable issue that the (extremely clever) KAS guys found, or it's possible they didn't feel it was worth it for the grapple. Thanks, I'll have a look at smart parts, not heard of that before.
-
Another cool thing to come out of this is I can now make little tie downs for rovers in transportation. Going to make them aim-able, so once configured, you fire them to create a solid joint between themselves and whatever they're aimed at within a configurable distance. So you can drive a rover onto a ramp of a cargo plane, fire up several tie-downs and fly the plane away with the rover solidly fixed in place, just like in RL. No messing with fiddly docking port alignment, everything stays as a separate vessel and the rover won't fall out. Lots of unknowns like vessel and scene switching, how the on rails part is handled and stuff like that to work through, but that's the plan. Lots to do with the hitch before I even release it to you guys, and still a lot of unknowns there. Switching between tractor and trailer is fine - the joint stays intact - but it will need rebuilding every time focus is swapped away out of physics range, which could be a problem. Needs rebuilding before and physics kicks in too, or things will go out of alignment before the joint is rebuilt. I think KAS and IR can probably point me the way. One cool thing about this method, is that as tractor and trailer are still separate vessels, they actually collide with each other rather than folding into themselves! I'm going to try and create some limits to swivel range of the hitch anyway, but this might be tricky dealing with the orientation not being perfect when hitching. I'd also like to give the option to activate the drive and brakes on the trailer, so maybe I'll have to look at Burn Together or similar. Maybe I can hack around with some of the auto pilot functions.. Oh, and I need to make some nice hitch and coupling models... I'm literally just typing stuff as it comes into my head now, maybe I should stop!!
-
You're very welcome, eldiabs I can't quite believe how well that works, Zodius! I've been code diving KAS and IR quite heavily (part of the reason the trailer hitch got a bit of time put in) and hope to have some grabby animation goodness going fairly soon. Now wondering, with my new level of knowledge of joints, whether a lightweight IR type plugin with very different controls might not be the way forward for those wheels... Interesting stuff.
-
I'm just going to put this here Yeah, you'll have to ignore the debug lines and the fact that there's no visible link, but the important thing is that this works and the dynamics are perfect. I used short, light demo rovers to demonstrate how the forces act on the towing vehicle under acceleration and braking. Very tricky getting the configurable joint to do its thing, but well worth it. Onwards! I now have a far better understanding of how joints are configured in KSP, as well as how to configure them myself. Hope you're all having fun!