[1.0.x] [V1.9f] Kerbal Foundries wheels, anti-grav repulsors and tracks

[Haifi]

That hitch looks very impressive already mate!

Ive tried to create things like that with Infernal Robotic parts, but the uncontrolled hinges are exactly that... uncontrolled, so you cant really set them up to work only in a certain angle. Looking forward to test them!

Please no complaining about bend or broken hitches

Cheers

[Gaalidas]

I never did try to make a free-moving hitch with those parts. I always theorized that it would be possible to get all angles of movement available by using multiple IR hinges in different orientations, but I worried that my hitch would be way too long to be practical. At least now I won't make the mistake of trying it on my own.

[riocrokite]

... 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!

This might be totally wrong direction of research but maybe some kind of flat surface docking ports with docking port functionality could have helped in aligning and docking precisely with correct angle? (if there isn't a solution for aligning vectors)

However in its current state this hitch of yours looks awesome and will bring much good to KSP lego game since you cannot do similar thing using IR elements.

[ratchet freak]

Indeed! Though this kind of vector maths is really, really hard

Find the angle between two vectors in one plane: Sounds easy, doesn't it.

in the plane of the vectors or a arbitrary plane?

the first is acos(dot(vec1, vec2) / sqrt(vec1.lengthSq()*vec2.lengthSq()))

the second is the same after projecting the vectors on the plane, that you can do by doing vec - planeNormal.normalized() * dot(vec, planeNormal.normalized())

[sharpspoonful]

I never did try to make a free-moving hitch with those parts. I always theorized that it would be possible to get all angles of movement available by using multiple IR hinges in different orientations, but I worried that my hitch would be way too long to be practical. At least now I won't make the mistake of trying it on my own.

Pretty much exactly what you said. It's not practical, and makes for some long and difficult to use hitches.

[lo-fi]

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!!

Edited January 30, 2015 by lo-fi

[ZodiusInfuser]

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 presume you're converting to degrees for your internal representation of angle?

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.

Woot! I realise that my explanations sometimes aren't the best, but at least it was of some value

[ratchet freak]

FYI

Mathf.Sqrt(Mathf.Pow( _hitchObject.transform.right.magnitude, 2) * Mathf.Pow(_couplingObject.transform.right.magnitude, 2)))== _hitchObject.transform.right.magnitude * _couplingObject.transform.right.magnitude

I just put it in as an optimization if for if you grab the squared magnitude directly (only 1 square root needed then instead of 2 if they were grabbed separately)

and yes that is indeed just the angle between them.

and projection should actually be vec - (planeNormal.normalized() * dot(vec, planeNormal.normalized())) I assumed you would have applied normal operator priority...

[lo-fi]

FYI

Mathf.Sqrt(Mathf.Pow( _hitchObject.transform.right.magnitude, 2) * Mathf.Pow(_couplingObject.transform.right.magnitude, 2)))== _hitchObject.transform.right.magnitude * _couplingObject.transform.right.magnitude

I just put it in as an optimization if for if you grab the squared magnitude directly (only 1 square root needed then instead of 2 if they were grabbed separately)

and yes that is indeed just the angle between them.

and projection should actually be vec - (planeNormal.normalized() * dot(vec, planeNormal.normalized())) I assumed you would have applied normal operator priority...

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.

I presume you're converting to degrees for your internal representation of angle?

Woot! I realise that my explanations sometimes aren't the best, but at least it was of some value

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...

Edited January 30, 2015 by lo-fi

[ZodiusInfuser]

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.

IIRC you also need to do the cross product to be able to get the full 360 degree range, since it can be used to get the sin of the angle (in a similar same way how you get the cosine from the dot product). Then you can use Atan2 to get your full 0 to 360 degree angle. Have a look at this link as it seems what's being asked is exactly what you're wanting too: http://www.gamedev.net/topic/88968-finding-angle-between-two-vectors-over-360-degrees/

[ratchet freak]

though if you want the oriented angle it's possible to transform both vectors so that 1 is the X-axis, the normal for the positive rotation is the Z axis. and then plugging the x and y of the other values in atan2

[lo-fi]

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...

Edited January 31, 2015 by lo-fi

[Gaalidas]

I just saw the updated video on YouTube while browsing crazy kerbal videos. Looks like the hitch is coming along nicely.

[ZodiusInfuser]

I just saw the updated video on YouTube while browsing crazy kerbal videos. Looks like the hitch is coming along nicely.

I concur, it appeared right in my sub box

[lo-fi]

*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.

[chrisl]

When you're in the VAB/SPH and setting up tracks, you've got some sliders for Spring Strength & Spring Damp. Is there a way to make those sliders active for vehicles that are already deployed? I've got some tracked units on Duna that I want to try adjusting those settings to see if that will help reduce the frequency of them falling over every time I start and stop.

[lo-fi]

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.

[chrisl]

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.

Ok. I'll give that a try.

[lo-fi]

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.

[J.Random]

I'm thinking the hitch needs an external camera and alignment indicator for use in IVA.

Why not simply use the Romfarer's LazorCam/DockingCam? If your hitch is a docking port, it will work as is (and I'm not sure, but it may work with RPM).

[Gaalidas]

Why not simply use the Romfarer's LazorCam/DockingCam? If your hitch is a docking port, it will work as is (and I'm not sure, but it may work with RPM).

Ugh, that mod is way over-engineered and rather heavy of a load on the system. It really doesn't integrate very well. However, RPM has its own camera helpers and selectors for use in a standard RPM monitor. I believe there's a special transform you can define in the model for use with the camera module. As for an alignment indicator, I am unsure of how that would be accomplished. The ASET connector has a togglable set of arrows that I believe is simply an animation that consists of a single frame of movement which makes the arrows appear, and the matching part has a similar set of arrows. If it's a true docking alignment guide you're after, you may have to somehow define a docking post and make use of the alignment indicator plugin. As for RPM page coding, that's a real mystery to me. For inspiration into the model of the hitch, you could take a look at the KSOS pack. I believe they have a little docking port that resembles a hitch of some sort. I never was able to make it work right though, and I think it was just a dock with a really weak connection which allowed for a certain degree of sway.

- - - Updated - - -

*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.

y'know what would be nice, speaking of strut guns and such, would be if you could place two parts on separate crafts that would share an ID of some sort so that, upon docking, the two parts would fire a strut of some sort between the parts of the same ID. This would allow for predefining which docking-strut connects to whichever opposing part before docking is even commenced... okay, so I'm already having doubts to the stability and usability of such a thing... I so hate it when my amazing ideas fall apart as I type them out. I need to think on this one.

By the way, I finally got around to testing my experimental modification of the CollisionFX plugin. It compiled fine, even loaded fine. Heck, my new parameters worked amazingly well... it's the effects themselves that totally failed. Instead of sparks, lights, and/or dust, I was greeted with white, gray, and red spheres of varying sizes that either persisted in one spot, or followed the craft around (such as when a pod ejected a fairing during reentry which promptly collided with the pod) and, oddly enough, were physical enough to have their own reentry effects. It was rather hilarious, but also a failure overall. Guess I'm not quite as awesome as I thought I was. I'm still awesome, don't get me wrong... just not in this area. Can't imagine what went wrong though... I only took about half of the code, rewrote half of that and refactored the other half. All it took was some duct tape and a prayer and a little shove to make it fit in the drawer. What could go wrong?

[AntiMatter001]

Hi, I'm running ActiveTextureManagement basic and it hangs at RepulsorSurface\RepulsorSurfaceDiffuse. As in, no log, the program freezes. Any ideas?

yep same problem. taking forever and using up most of my CPU :/ ... ok i love your mod but really are your new textures THAT bad/good? XD

this is the first time loading it up so if it takes this long (an hour... ya... an hour...) again... i'm considering uninstalling kerbal foundries :/

EDIT: nope it loaded quicker the second time around ok ATM is ^^^^ so meh sorry KF your an awesome mod again lol

Edited February 1, 2015 by AntiMatter001

[Gaalidas]

It's not the repulsor texture, that's just the last texture that was successfully loaded. The one it's most likely getting stuck on, and thus not outputting to the log for until processed, is the one on the rover body which is a staggering 4096x4096 texture, plus a same-sized normal map. Heck, the only other mod with that huge of a texture overload is KSOS, and that mod tends to share it's texture space with multiple parts.

[lo-fi]

Aye, my bad with that one! I'll cut it down and re-issue, I completely forgot I'd made it silly res while I was testing stuff with normal map detail and it's stayed like that ever since.

Sounds like the collisionFX recompile can't find some particle shaders or something like that?

[Gaalidas]

Sounds like the collisionFX recompile can't find some particle shaders or something like that?

That sounds reasonable. The rules call for sharing the source, but they don't specify that you need to provide all the dependencies required to recompile it. Most likely there's a packaged shader in the DLL that wasn't provided with the source. Either that, or it's having issues with my rendering hardware. I never did test to see if the standard stuff worked properly. Either way, that shader must be amazingly simple consider my recompile made the DLL file a whole kilobyte larger than the release DLL. I am not really sure that a shader is the real culprit, but that seems the most plausible. It's also possible that separating the functions for the two differing effects broke something in another function that might rely on data provided by the standard spark effect setup.

The real issue is that I can't just recompile and start passing a new DLL around. pizza-whats-his-name has been MIA for a little bit here... along with just about everyone else working on the major part mods since .90 was released.

What puzzles me though is that the spheres were spawning for the collisions in place of actual effects, but the dust was no where to be seen. No spherical placeholders, no actual dust, just... nothing. The other various colors could be evidence that the color-altering effects on the mod were functioning as intended for things like the light effects that accompany the sparks, but I got no trail of floating balls following my tracks around unless they were spawning under the surface of the planet.

EDIT: I had another look at the original DLL in ILSpy (a little DLL decompiler thingie) and noticed that the effects are referencing a texture of some sort. Now, I know that there isn't a path in the gamedata directory or locally for either squad OR CollisionFX which contains the path/object of "Effects/fx_smokeTrail_light" to be referenced. If it's a file in the stock assets, then I suppose that's where it's looking for its source imagery, but if Squad made a change to that path recently then that could be the culprit. I might be able to get things working again if I found those textures and redirected the reference to a local directory instead.

Edited February 1, 2015 by Gaalidas