Jump to content

[0.90] Magic Smoke Industries Infernal Robotics - 0.19.3

sirkut

By sirkut
in KSP1 Mod Releases

 Share

Recommended Posts

sirkut

sirkut

Posted
  • Author
Posted

Small update guys.

I have both rotating and sliding parts operating correctly in the VAB/SPH. I also have them loading correctly onto the launch pad EXCEPT for the piston and the gantry for some strange reason(adjustable rails work fine). I'm certain it's a model issue so I'll have that fixed and will be sending out a beta version of this new feature to a few people to test out. It's been the most requested feature since I picked up where Damned Robotics left off so to have this off the request list will be an awesome win for me.

Link to comment
Share on other sites
marce

marce

Posted
Posted
Small update guys.

I have both rotating and sliding parts operating correctly in the VAB/SPH. I also have them loading correctly onto the launch pad EXCEPT for the piston and the gantry for some strange reason(adjustable rails work fine). I'm certain it's a model issue so I'll have that fixed and will be sending out a beta version of this new feature to a few people to test out. It's been the most requested feature since I picked up where Damned Robotics left off so to have this off the request list will be an awesome win for me.

Oh and you surely will get a lot of kittens and maybe even a unicorn from every single person playing KSP (which should be anyone anyway) :D

Link to comment
Share on other sites
Nori

Nori

Posted
Posted
Small update guys.

I have both rotating and sliding parts operating correctly in the VAB/SPH. I also have them loading correctly onto the launch pad EXCEPT for the piston and the gantry for some strange reason(adjustable rails work fine). I'm certain it's a model issue so I'll have that fixed and will be sending out a beta version of this new feature to a few people to test out. It's been the most requested feature since I picked up where Damned Robotics left off so to have this off the request list will be an awesome win for me.

Nice! Thanks for your work on that. It is certainly a feature I'm looking forward too.

Link to comment
Share on other sites
steve_v

steve_v

Posted
Posted (edited)

And again, another vessel trashed, another save file corrupted. This time a fuel tank ~100m away from the rest of the craft and somehow still attached.

Hell, the displaced parts weren't even directly attached to any IR part.

Once again, nothing in the logs.

Only common thread: IR parts not in rest position when switching away from craft.

What gives man? This just isn't usable in this state.

Edited by steve_v
Link to comment
Share on other sites
steve_v

steve_v

Posted
Posted (edited)

And just found another. BYE BYE IR. guess I'll come back in another year, or whenever the dreaded lousing up part attachment bug is sorted.

Edited by steve_v
Link to comment
Share on other sites
marce

marce

Posted
Posted
And just found another. BYE BYE IR. guess I'll come back in another year, or whenever the dreaded lousing up part attachment bug is sorted.

Pro tip: grab the source, try to find bug, fix it, test it, submit pull request.

Link to comment
Share on other sites
sirkut

sirkut

Posted
  • Author
Posted
And just found another. BYE BYE IR. guess I'll come back in another year, or whenever the dreaded lousing up part attachment bug is sorted.

No one gives me any method of reproducing this bug. I have had over 12k downloads on one version alone and I don't hear a peep from all those people. Give me a method to reproduce it and I can see about fixing it otherwise that's it. Honestly I don't play KSP anymore so I'm not going to run across this bug because I find maintaining the mod more entertaining.

Link to comment
Share on other sites
steve_v

steve_v

Posted
Posted

Believe me, if I knew how to reproduce it I would let you know in a flash. As for debugging it myself, as much as I would like to I simply don't have the time to a: learn a new language, totaly useless in my day job & b: figure out someone elses code from scratch.

Unhelpfull as it is, all I can say for sure is that it only happens to vessels with IR parts & only happens when I'm not looking :(

I agree that many do appear to be using it without issue, however isolated cases have been appearing for a good long while now.

So be it I guess.

Link to comment
Share on other sites
Alewx

Alewx

Posted
Posted
Believe me, if I knew how to reproduce it I would let you know in a flash. As for debugging it myself, as much as I would like to I simply don't have the time to a: learn a new language, totaly useless in my day job & b: figure out someone elses code from scratch.

Unhelpfull as it is, all I can say for sure is that it only happens to vessels with IR parts & only happens when I'm not looking :(

I agree that many do appear to be using it without issue, however isolated cases have been appearing for a good long while now.

So be it I guess.

What mods else do you use?

Although I can not report any compatibility issues between IR and other mods myself.

Link to comment
Share on other sites
steve_v

steve_v

Posted
Posted

It varies, right now the list is pretty long:

MechJeb2

AGExt

TweakScale

ThrottleControlledAvionics

HabitatPack

R&SCapsuledyne

OpenResourceSystem

SelectRoot

FMRS

NearFuturePropulsion

EditorExtensions

NearFutureSolar

ShipManifest

PartAngleDisplay

AutoSave

SpaceplanePlus

ImprovedChaseCamera

FerramAerospaceResearch

StageRecovery

ProceduralWings

ProceduralFairings

RPM

Kerbaltek

KerbalJointReinforcement

KAS

KSPStockTweaks

Firespitter

TACLS

RCSBuildAid

NearFutureElectrical

FShangarExtender

RealChute

KerbalIspDifficultyScaler

ProceduralFairings

KSPX

Achievements

CrossFeedEnabler

TweakableEverything

AntennaRange

AlignedCurrencyIndicator

CustomBiomes

NearFutureSpacecraft

KAX

NavInstruments

NearFutureConstruction

KAC

ScienceAlert

DeadlyReentry

KerbalEngineer

VesselView

B9_Aerospace (R5 prerelease & its deps)

KWRocketry

MKS/OKS

DockingPortAlignment

SH_mods

FinePrint

SCANsat

That said, IIRC I've been having this issue since ~0.20 and the list was a lot shorter then :)

Can't remember if the same was happening with Damned Robotics way back when or not.

Link to comment
Share on other sites
sirkut

sirkut

Posted
  • Author
Posted
Believe me, if I knew how to reproduce it I would let you know in a flash. As for debugging it myself, as much as I would like to I simply don't have the time to a: learn a new language, totaly useless in my day job & b: figure out someone elses code from scratch.

Unhelpfull as it is, all I can say for sure is that it only happens to vessels with IR parts & only happens when I'm not looking :(

I agree that many do appear to be using it without issue, however isolated cases have been appearing for a good long while now.

So be it I guess.

Sure there are isolated cases but until someone can give me a solid method of reproducing the issue there's absolutely nothing I can do. When I do play, which is sparingly, I never have this issue.

Link to comment
Share on other sites
sirkut

sirkut

Posted
  • Author
Posted

Maybe I could write a "debug" window that will allow you to move your parts beyond the standard range of motion to bring them back to where they belong? I just don't know what I can do.

Link to comment
Share on other sites
steve_v

steve_v

Posted
Posted (edited)

'tis not just that the IR parts move beyond the intended range, that I could deal with. Rather that _other_ parts end up in weird positions - the latest (and most extreme I have seen) example was a vessel consisting of: [transfer stage engine][transfer stage tank 1][transfer stage tank 2][octagonal strut][decoupler][folding plane with 2 rotatrons]

I make the mistake of opening the wings to expose solar panels, and...

After switching back for a mid course correction I find that the [transfer stage tank 2][octagonal strut] section is now ~100M away from the rest of the vessel, yet somehow still connected to it. Camera thinks COM is somewhere in the empty space between.

Get annoyed, hyperedit same craft into orbit, go fly a probe for a bit, return: wing joints look like the ziggurat :(

Don't stress, I'll live without it. Was kinda looking foward to flying that thing on Duna tho.

EDIT: a bit more than 100M actually: http://imgur.com/GIvd4jw

Edited by steve_v
Link to comment
Share on other sites
marce

marce

Posted
Posted
Believe me, if I knew how to reproduce it I would let you know in a flash. As for debugging it myself, as much as I would like to I simply don't have the time to a: learn a new language, totaly useless in my day job & b: figure out someone elses code from scratch.

Unhelpfull as it is, all I can say for sure is that it only happens to vessels with IR parts & only happens when I'm not looking

I agree that many do appear to be using it without issue, however isolated cases have been appearing for a good long while now.

So be it I guess.

I only felt your comment was a bit harsh, so I suggested that you try yourself before demanding anything from sirkut (and it sounded like a "fix that!" for me).

Having a bad day myself, sorry.

Maybe I could write a "debug" window that will allow you to move your parts beyond the standard range of motion to bring them back to where they belong? I just don't know what I can do.

It seems I had the problem as well some time ago. I even posted a picture here, although I didn't know IR caused this.

From now on I'll keep my eyes open and if it happens again I'll try to reproduce and tell you my findings.

MechJeb2

AGExt

TweakScale

ThrottleControlledAvionics

OpenResourceSystem

SelectRoot

EditorExtensions

PartAngleDisplay

FerramAerospaceResearch

ProceduralFairings

RPM

Kerbaltek

KerbalJointReinforcement

KAS

Firespitter

TACLS

RealChute

ProceduralFairings

TweakableEverything

KAX

ScienceAlert

DeadlyReentry

KWRocketry

FinePrint

SCANsat

Link to comment
Share on other sites
steve_v

steve_v

Posted
Posted (edited)

Yeah, I should'na yelled. Sorry.

It's not the same playing without IR but every time I install it, sooner or later something like this happens.

That pic of yours looks very much like what happened to one of my rovers recently.

Edited by steve_v
Link to comment
Share on other sites
Ringkeeper

Ringkeeper

Posted
Posted
They've been in IR for ages. Still none in the IR model rework.

i know. But working with the ones in IR is at them moment everything but easy. You never know if attach that point which part moves or if the whole ship moves.

Link to comment
Share on other sites
marce

marce

Posted
Posted
Yeah, I should'na yelled. Sorry.

It's not the same playing without IR but every time I install it, sooner or later something like this happens.

That pic of yours looks very much like what happened to one of my rovers recently.

So I tried to reproduce for about an hour now without success...

But I realized that I'm suffering from part clipping (=parts being placed on positions they can't actually be because there are no nodes) with PP & PF [and maybe TweakScale]:

Fhac8Iz.jpg?3

And what's the only thing PP, PF & IR have in common? KAE. My guessing therefore: like PP & PF parts, IR parts sometimes trigger such strange misplacement because of KAE - somehow :D

However, since you, steve, seem to have the problem more often, could you give some instructions to reproduce?

@sirkut: I noticed something different which is missing (or at least I'm not aware of). Would it be possible to make IR parts movement require EC and cease to function if not enough EC is available? I *think* it should be a not too difficult addition, but if you don't have enough time and would be willing to add it I could try to give it a shot myself and maybe send you a pull request or so. If it's there already - sorry I'm blind :wink:

Link to comment
Share on other sites
Master Tao

Master Tao

Posted
Posted
But I realized that I'm suffering from part clipping (=parts being placed on positions they can't actually be because there are no nodes) with PP & PF [and maybe TweakScale]:

That's a PP + TweakScale bug that only happens when you stack TweakScaled parts with PParts. From previous discussion in the TweakScale thread, at least one of the mods would have to specifically check for the presence of the other and adjust alignment accordingly. ATM, they both think that the other part's stack nodes are where they were before scaling. Definitely annoying, though I think there's a workaround: place a PPart that hasn't had a height change between the two scaled parts. It's been a while since I much used PParts though.

@sirkut: I noticed something different which is missing (or at least I'm not aware of). Would it be possible to make IR parts movement require EC and cease to function if not enough EC is available? I *think* it should be a not too difficult addition, but if you don't have enough time and would be willing to add it I could try to give it a shot myself and maybe send you a pull request or so. If it's there already - sorry I'm blind :wink:

EC usage hasn't been implemented. I think it's been "probably be in the next release" for at least four major versions. Somehow I get the feeling it's not a high priority for sirkut. :) With that and the Grabber, I'd need to start including RTGs in all my robotic crafts.

Link to comment
Share on other sites
Drew Kerman

Drew Kerman

Posted
Posted
EC usage hasn't been implemented. I think it's been "probably be in the next release" for at least four major versions. Somehow I get the feeling it's not a high priority for sirkut. :) With that and the Grabber, I'd need to start including RTGs in all my robotic crafts.

I have an idea, but I can't think of a module to do it. Use MM to add a module to the part that allows a toggle and draw of resources. Then you can include that toggle with the action group for moving the part, so that resources are drained when you toggle the part in motion and stop when you toggle it off. This would mean you can't use the IR interface if you always want consumption but with something like Action Groups Extended there's plenty of action groups for all your moving parts.

So, is there such a module we could co-opt for such a purpose?

Link to comment
Share on other sites
sirkut

sirkut

Posted
  • Author
Posted
So I tried to reproduce for about an hour now without success...

But I realized that I'm suffering from part clipping (=parts being placed on positions they can't actually be because there are no nodes) with PP & PF [and maybe TweakScale]:

And what's the only thing PP, PF & IR have in common? KAE. My guessing therefore: like PP & PF parts, IR parts sometimes trigger such strange misplacement because of KAE - somehow :D

However, since you, steve, seem to have the problem more often, could you give some instructions to reproduce?

@sirkut: I noticed something different which is missing (or at least I'm not aware of). Would it be possible to make IR parts movement require EC and cease to function if not enough EC is available? I *think* it should be a not too difficult addition, but if you don't have enough time and would be willing to add it I could try to give it a shot myself and maybe send you a pull request or so. If it's there already - sorry I'm blind :wink:

By all means give it a try. My main goal is to finish the VAB/SPH movement task. Everything right now is on hold until I get this done. I'll gladly take any pull request.

Link to comment
Share on other sites
AccidentalDisassembly

AccidentalDisassembly

Posted
Posted (edited)

I had a question about tweakscale - I was wondering why many parts contain individual tweakscaleexponents definitions for mass, maxtranslate, whatever. All of these relationships seem linear: doubling size doubles mass, or doubles maxTranslate or whatever, like in the right angle extendatron part:

TWEAKSCALEEXPONENTS

{

mass = 0.045, 0.09, 0.18

}

TWEAKSCALEEXPONENTS

{

name = MuMechToggle

translateMax = 0.45, 0.9, 1.8

keyTranslateSpeed = 0.05, 0.1, 0.2

}

Why not just define mass = 1 in TWEAKSCALEEXPONENTS as an actual exponent, which would then double the mass of the part when you double its size, of halve when you halve? This is how it's done normally for non-IR-related tweakscale, if I've understood things right. This would avoid the problem of having to edit every part in order to make new and ludicrously large tweakscaled robotic stuff, wouldn't it? Or is there something that doesn't work right if you apply an exponent rather than individual values per defined scale?

Edited by AccidentalDisassembly
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...