Jump to content

[0.90] Magic Smoke Industries Infernal Robotics - 0.19.3


sirkut

Recommended Posts

On a different note, I've recently been playing with IR to build mecanum wheels, and I'm surprised how buggy things are even though the codebase has had quite the time to mature. I'm getting a lot of what looks like quaternion errors to me (they're not being normalized, so the rotation matrix also performs some translation or scaling of coordinates). These quaternion errors could even be in Unity code, but renormalizing them should still be doable from the plugin.

Mecanum wheels would be fun! I won't pretend that I know half of what the code is doing since r4m0n did most of the work. Quaternions is alien to me so I'm still figuring out everything. I know the springiness of the pistons when a lot of weight is being loaded on it is really goofy and haven't figured out how to fix that issue. I read up on ConfigurableJoint and maybe locking would work but I haven't tested it.

Link to comment
Share on other sites

Mecanum wheels would be fun! I won't pretend that I know half of what the code is doing since r4m0n did most of the work. Quaternions is alien to me so I'm still figuring out everything. I know the springiness of the pistons when a lot of weight is being loaded on it is really goofy and haven't figured out how to fix that issue. I read up on ConfigurableJoint and maybe locking would work but I haven't tested it.

Mecanum wheels were indeed fun, but unfortunately KSP's wheel physics don't lend well to building them, and after a few minutes IR always bugs out, probably because I crank the speed way up on the rotatrons.

On the quaternion issue: quaternions are four-dimensional vectors, but rotation quaternions are normalized (their length is always 1). In game programming, quaternions can often deviate from that property because floating-point errors add up after successive operations. Regularly renormalizing them solves the problem, but it's additional computation time so it's rare that quaternions are automatically normalized. I'm not certain that's what's happening here, but there's definitely some kind of drift associated with high rotation speeds.

Link to comment
Share on other sites

Would the accumulation of those floating point errors be a possible explanation for why some peoples MSI creations spontaneously explode after a minute or so of continuous operation?

Edited by NoMrBond
Link to comment
Share on other sites

Would the accumulation of those floating point errors be a possible explanation for some peoples MSI creations spontaneously explode after a minute or so of continuous operation?

Absolutely. I only poked a little at the IR code (and it's not exactly comprehensible), so my hunch may be completely wrong, but whatever's causing joints to drift apart is likely responsible.

Link to comment
Share on other sites

Absolutely. I only poked a little at the IR code (and it's not exactly comprehensible), so my hunch may be completely wrong, but whatever's causing joints to drift apart is likely responsible.

You are correct. It's not exactly comprehensible. I'm still trying to wrap my head around the code myself. Funny thing is the configurable speed option wasn't originally part of Damned Robotics which may explain why it was never allowed to begin with due to the breaking. Just define it in the CFG and move on. The only thing I've added to the code that would probably cause these issues is the speed. If you eliminate the locking event and the sound it's essentially "stock"

Link to comment
Share on other sites

You are correct. It's not exactly comprehensible. I'm still trying to wrap my head around the code myself. Funny thing is the configurable speed option wasn't originally part of Damned Robotics which may explain why it was never allowed to begin with due to the breaking. Just define it in the CFG and move on. The only thing I've added to the code that would probably cause these issues is the speed. If you eliminate the locking event and the sound it's essentially "stock"

Don't get me wrong, I'm not blaming you for the original code, and I'm well aware of its history. I guess I was expecting you to have impatiently rewritten large chunks by now. :wink: It's very likely, in my opinion, that this bug has existed for quite a long time.

Link to comment
Share on other sites

Only pieces that will surface attach work with the fairings. I use the tiny structural column bit. The IR door hinge washers will stick to the fairings also. I think you can use the I-beam parts too.

I have tried everything mentioned, i cannot get them to attach to anything but the original base. do you have vid somewhere showing what your doing.

Link to comment
Share on other sites

I've been able to get them (The PF fairings, if shape locked) to stick to the tops of rotatrons, hinges and even telescopic pistons

Javascript is disabled. View full album

The attach point for the panels seem up from the physical base, so it's kind of random when it'll work, and only if you're bringing the panel directly down onto the attachment ball for the part

Link to comment
Share on other sites

My favorite part of the weekly for MrTinyPirate's videos was "custom mechanical parts.".

That was annoying, my video had a full description of the parts in it :/

TinyPirate are you using PF for your fairing on the robots? if you are how are you getting the nodes to attach. i cannot make them attach after creating and shaping the fairing

I create the fairing (in fact, I leave the fairing base stuck on to the top or side of my craft until I'm 100% happy with it so I can keep modifying it) and then I stick fairings on to a cubic strut. I often then pick the strut up and slap it on what I want, carefully adjusting as needed.

Link to comment
Share on other sites

Nodes on the fairing pieces are directed vertically. For best results, you need a special model with nodes in the right places, but they can and will attach to cubic struts if these are oriented vertically.

Link to comment
Share on other sites

Absolutely. I only poked a little at the IR code (and it's not exactly comprehensible), so my hunch may be completely wrong, but whatever's causing joints to drift apart is likely responsible.
You are correct. It's not exactly comprehensible. I'm still trying to wrap my head around the code myself. Funny thing is the configurable speed option wasn't originally part of Damned Robotics which may explain why it was never allowed to begin with due to the breaking. Just define it in the CFG and move on. The only thing I've added to the code that would probably cause these issues is the speed. If you eliminate the locking event and the sound it's essentially "stock"

Actually, I think that may not be the culprit, digging through documentation, I think I've found a possible candidate for the exploding parts issue. The issue may be that the joint between the (washer's) parts themselves is rather weak though KSP's joints seem to take most external torques/forces (hence it's appearance more often at high speeds). I'm gonna try to build a modified dll to test, if I manage to eliminate the issue, I'll send you my changes to the source.

Link to comment
Share on other sites

Thank you everyone, and thanks for the link Gristle. i tried everything again as suggested. still did not work. so i uninstalled and re installed PF and now its working like you guys say it should. Thank you for the feedback. i Appreciate your time

Link to comment
Share on other sites

Well, I have a slight improvement, methinks, after a rotatron has drifted off, it'll at least stay put, XD

Edit: Looks like I'm on the right track, at least. Next thing to try, increase that projection snapping thing

Edit 2: Err, is there a way to swap out the dll while KSP is running?

(Also, the motion stuff is in toggle.cs, right?)

Edited by Reddot99
Link to comment
Share on other sites

Ok, my plan was a flop, but I did discover, as spinning objects drift away, they're drifting as if regular physics were applying single frames during their turning process.

(I know *what* I would need to do to fix it, but not *how* to do it... essentially need to have the rotationjoints translate back to their 'homes')

Edited by Reddot99
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...