Starwaster

Two words. Drop.Box. http://www.dropbox.com

When you look at the size of the tank parts and apply some math to determine volume, it's pretty apparent that it can't be liters. To really make the tank volumes and resource densities metric requires increasing tank volume and decreasing resource density. (assuming liquid resources such as LOX, LH2 or RP1. forget how this affects compressed gaseous products) This is currently done with the Real Fuels mod which does indeed assume liters. RF is based on Modular Fuel Tanks, earlier incarnations assumed a base of 6.25 liters, which would make 1 volume unit 6.25 m3 or 6.25 kl.

another fix is to add and set CoMOffset in the part's cfg file which for best results requires knowing how much it's off by.

Yes and yes. Except that I think you can specify the resource. There is a radiator part with RF that works, I think.... it looks bland and textureless so I used its config as the basis for the radiator that zzz made for the interstellar mod. If you download that part, you can use this config for it: The sensor code is redundant if you have Deadly Re-entry. I stuck it in there to debug how well the part was dissipating heat. Note that resource is configurable.... even optional IIRC @PART[radiator1]:Final { @mass = 0.025 MODULE { name = ModuleHeatPump heatTransfer = 50 heatDissipation = 5000 RESOURCE { name = ElectricCharge rate = 0.01666667 } } MODULE { name = ModuleEnviroSensor sensorType = TEMP } }

Resource consumption is all resources/propellants listed in the parts engine module and is the amount required to produce the amount of thrust specified based on the engines Isp (AtmosphereCurve) This is pretty much how it works in real life with one important exception. In real life thrust is variable according to atmospheric pressure as determined by Isp while consumption stays constant. In this game however thrust stays constant and fuel consumption is increased at sea level to compensate. This last point is likely responsible for any discrepancy you've noticed. The mod Real Fuels provides a more realistic experience where thrust is reduced at sea level increasing as you get closer to vacuum.

Sorry I didn't see this before. I've used RSS a lot and I didn't experience the behavior that Newbinator did any more than I did in stock. If it wasn't the control point issue and it was the previously discussed bug AND he was using something older than 158 (I think that's where Sarbian said he fixed it?) then IMO it was something intermittent. Removing Alternis and 'Landing AP working' is likely coincidence. Any time it hit me before I'd just F9 and try again.

When a craft other than the one that I set RCS on and send SmartASS commands to starts responding by firing RCS thrusters, doesn't that point towards MJ? PID values also all set to (-)Infinity. The only other time I've seen that is if RCS is missing from the craft. (which seems odd in itself given that it still has more than enough torque from its flywheels.... were you aware of that one) Just to make sure, you did see this, didn't you? This doesn't help? https://www.dropbox.com/sh/9pxl3a3fz3tetcc/rxV0aqOzPz It's got logs, screenshots and a save file. No craft file but the craft were all stock. As to instructions, nothing special needs to be done, if you try initiating auto-land (at target) enough it will happen. Happened to me on my second try. Edit: Nope I take that back. Craft file was included. It's the whole save folder and the craft is in the VAB. I think I used Hyperedit, so not 100% stock but that was just so I didn't have to waste time getting the thing into orbit first. The save file has multiple craft around several planets so I could test as to whether one planet did this more than another.

Haven't you ever seen photos of the actual Project Rover tests? (Kiwi, Phoebus) It's visible. Here. This was the first one. Kinda weak but it was just a ground testing prototype

Uhm the carbon fiber is on the truss and its still ther. The The tank is the same texture just a little darker and some different rim lighting and secularity.

Tonight I successfully re-docked the drop tank after jettisoning it. This was ma possible because both the long saddle truss and the drop tank itself contain docking ports. They will only dock with each other, nothing else. It was fairly difficult because the tank itself is unpowered, uncontrolled and will spin if you smack it. The docking was performed by MechJeb2. So, Copernicus has gained some re-use capability now. A tank could be sent up, preferably with a tug attached, which would make it much easier than the way I did it.

It's not a FAR issue. Either he's controlling from a pod/port that's off-axis or he's run afoul of a long standing bug where the re-entry controller will (usually after an initially successful de-orbit burn) start doing 'course corrections' that take it off course. And it continues to perform the burn until it runs out of fuel. (even to the point where it reaches escape trajectory. I once turned on fuel cheats during such an event just so I could see when it stopped and I tired of the exercise long before MJ2 did) Sooo, Newbinator, make sure that you're controlling from a forward facing command pod, probe core or docking port and try again. It's either that or the bug I described and if it's the bug, it usually stops after you reload. Or try exiting to spaceport and try again if it persists, but it's never hit me more than once. YMMV.

Ok, revisiting the NTR generator issue, I updated my files here: (Squad / KSPX only) Did two things. Bumped up nuclearFuel/nuclearWaste consumption/production a bit because I'm still seeing some power issues. Removed the ElectricCharge resource because it seems like it's actually interfering with the ModuleGenerator somehow. Not sure how really though there's another post elsewhere I found where electric producing engines were interfering with solar panels located elsewhere on craft. Doesn't seem like it got a lot of attention but it seems like it was an issue with several engines.

Ok, took another look at this taking into account what MOARdV said and it's definitely not a case of not having a control reference set. When it happens, setting 'control from here' doesn't fix it. Two craft of identical mass were docked and when I undocked them one would consistently set its Tf to 1.0 even though it was a 2 ton craft. (typically before docking they would set Tf to 0.04 which IMO is too low but that's what they would set it to BEFORE docking & undocking) Also while (re)testing this I also noticed then when I undocked craft 1 and craft 2, sometimes while setting SmartASS commands for Craft 1, Craft 2's RCS thrusters would sometimes start firing. Typically this would be KILL ROT and Craft 2 would just start firing/counterfiring repeatedly. Keep in mind this is while setting commands for Craft 1 Now... even while submitting this report/feedback and also keep in mind that I do feel docking/RCS in general do need a good bit more work, I want to take this opportunity to showcase a (IMO) nearly impossible task that I set MJ2 to perform. For those who don't know, I've been working on a set of parts to re-create in KSP the Copernicus MTV (Mars Transfer Vehicle). And possibly the Terra Nova from Race to Mars if you've ever seen that. One thing that I wanted to make possible is the re-docking of the drop tank so that the craft could be re-usable, even though the NASA proposal calls for the thing to be dumped in heliocentric orbit. (what... really NASA?) I did not think MJ2 could perform this task given its tendency to approach the target at something like a 45 degree angle and I meant to try tweaking this before attempting this task but somehow forgot to actually apply the fix that I wanted to try. (dunno why, it's not like it was mindbogglingly hard but I just forgot). So, anyway... here it is. Tonight, it did it. It bumped the tank a few times and nearly threw me into cardiac arrest but it somehow did it. And, even when it lines up successfully and moves forward, there's no guarantee that it can dock the thing because the truss is not a convex shape so it can't actually contain the tank! Even so.... MJ2 DID THIS (Edit: So, when someone comes in here and complains about how crappy the docking AP is and how it smashed their station to bits, just direct them to this post. RCS on this thing was a bit off balance because of the mass of fuel in the back, the engines and the fact that it didn't fully line up with the truss so the RCS thrusters were a few degrees out of alignment)

Wow really? That sucks if that's what it is. I wonder what programmatic solutions are possible.... i.e. assigning one in the code if the attitude controller could detect that such a condition exists. But then there would be the question of where to control from? The most obvious choice would be the docking port that was previously docked. Or the root part if it's eligible. (usually is but you can't take that for granted)

A couple of bugs to report in the latest dev (build 167) version. Or they might have started in an earlier version but I've been busy with Copernicus modeling so I haven't really noticed until I needed to dock these big ass parts. After undocking (or possibly undocking then switching between the two craft with []) one or more of the two become uncontrollable by MJ2 (SmartASS, maneuver nodes or docking AP or anything where it needs to adjust attitude) There's no errors in the output_log.txt during that time other than the ones informing me that there is 'no icon for X' (in a rather accusatory tone I might add, yes, I KNOW MJ2! I have to download them) However in the attitude control panel I see -Infinity for the PID settings (Kp, Kd, Ki) and Tf setting autotunes to a value that is abnormal compared to what it usually sets for that particular craft. For instance, a very large craft (several hundred mt) might have a Tf assigned of 0.4 or a small craft might have one assigned of 1. Sometimes toggling RCS balancing a couple of times clears it but generally I have to exit to Space Port so that both craft unload. I don't see this happen except for craft that I have recently undocked.

Oh in case they get hungry during the trip over to the Discovery they can pop open a panel behind that sign, take out a jar of honey, pop open their helmet real quick and squirt some in their mouth?

After reading something like that, of course I have to go and try to find out more (like I need another time sink in my day, yeah, way to go Nathan. Hope you're proud of yourself) and I didn't learn what I set out to learn but I did find out that the LM ascent engine (made by Bell like the Agena engine) was rated for 35 restarts, nearly twice as many. Why so many? Just for redundancy? Or maybe higher thrust hypergolic engines damage the chamber/valves? I dunno. I also learned (or rather was reminded) that there sure were a lot of old geezer engineers at NASA, Bell and the aerospace industry in general back then.... and it saddened me to think that so many of them are gone now.... It's known btw that there's only a few of the original NTR guys still alive and kicking. Makes me think that if we're going to restart the NTR program we're having to start over almost from scratch. We should be so much further ahead than we are now So sad.

I thought IRL hypergolic engines had infinite amount of ignitions since the fuel is self igniting... is that wrong???

New drop tank mesh and tweaked the texture a bit but I don't like it. Looks less like foil insulation now. Maybe if I darken the base color but increase specular and falloff (which will be more gold)?

I wonder what that says off to his right... I bet it's Russian for.... 'Don't look down'. (yeah I know, that's not really what it says....)

You sure about that? I've never seen a dot product out of that range before. Maybe it's because I'm used to normalizing everything though but that sounds odd

Sarbian, I was looking at the docking AP code to see about tweaking how the rate at which the AP approaches the docking axis. Really to change the ratio between lateralVelocityNeeded and zVelocityNeeded. Doesn't seem that hard to do but something else caught my eye which was zSep and lateralSep.magnitude. You're comparing the two in places in the code even though they're dissimilar things. The code still works (until you get very VERY close to the dock) because reducing lateral separation brings zSep within the range that it expects in order to be able to advance forward. But the earlier comparison is to check if zSep is less than lateralSep even though zSep actually has to be high (being the dot product between two vectors) in order to be considered close to the docking axis. That's why it tends to follow a diagonal course to the dock and why on a few occasions it gets hung up very close to the dock but offset by a few tenths of meters. (it probably could let go at that point and magnetic attraction take over but it's still stuck in approach mode) Edit: There's a few places in there where it seems like it's expecting that zSep is the distance to the dock (along the axis) but because it's a dot product its range will always be -1 to 1. (though for our purposes, when in front of the dock it's really going to be 0 to 1)

The textures on the tanks is meant to look like the 'gold foil'-like insulation that NASA uses in space. It's called multilayer insulation or MLI for short. It looks a lot like gold and is very reflective. It is still being tweaked. I can't say for sure when I'll make it available for download. I still have to do a proper drop tank mesh. What you see is just a standin. The truss was the main hurdle in modeling and that's behind me. To do: Finish testing to make sure there aren't weird collision body issues or intersection issues that make the whole thing want to come apart. Last night, towards that end, I uninstalled KJR to make sure it stays stable. There's still some odd phantom forces that killed all my Kerbals. I left it orbiting Kerbin last night and when I came back the Mk1-2 CM that had been docked had broken loose and I had a message that the crews had all died from 18g of acceleration. Something had set it spinning violently enough to register 18g? That doesn't happen unless my SDHI crew vehicle is docked. So that put a damper on things. So what I'm saying is I need to make sure the assembled craft stays stable and also the one I've shown you guys is really big for stock so there needs to be a stock sized version available at release time too. (Not for stability, just because not everyone uses RF or RSS.

uhm I dont get it. Do you WANT someone to 'sing that' so you can have something to argue about? Otherwise I dont get what the big deal is. Play, don't play. RSS, don't RSS. Noodles, don't noodles....

Oh, I'm sure that it's not even begun to reach its maximum potential to disappoint us in new and strangely exciting ways.