Tallinu

April 16, 2014

Thanks for the tip regarding the config setting, I'm still figuring out some of the specifics of how MFT works. Realism is great, generally speaking. But unfortunately, despite being based on real orbital mechanics and such (to the extent possible in a simple simulation like this), a lot of KSP is notably unrealistic for gameplay reasons. Engine masses are often very high and ISPs low, planets unusually dense or the opposite, and with the stock drag model the atmosphere is like pea soup... I prefer to edge in realism's direction without getting too far from stock values, myself. So for now I'll try making that settings change, and see what the resulting masses are.

I wasn't suggesting that the band be removed, of course - I understand the need for having it there, believe me! Being able to use one (or more) of those hemispheres as the base for a lander is nice, especially when using radial engines. Keeps a lot of the weight low toward the surface for a more stable lander. Cutting it in half would be perfect.

And while I understand what you meant about the tank sizes, I must point out that 3.75m is not double 2.5 or 1.25... Increments of 1.25m would seem a more appropriate description, which would indeed mean that two sizes are missing (5m and 6.25m) between 3.75m and 7.5m... So, I hope you will consider adding both of those for V4 so that we can have a greater flexibility in choosing the right size tank for our building needs. The same goes for the toroid sizes - the current sizes seem pretty good for lower-capacity versions, at least below the biggest one (that might qualify as medium-capacity tank of its diameter). Having one or two more capacities available would be really great.

(Have you ever thought about procedurally defined tanks, like some of the Goodspeed parts or the StretchySRB stuff? Being able to define inner and outer diameter for toroidals and pick different end cap sizes for your choice of sphere sizes would be awesome too.)

Anyway, now I have even more reason to look forward to V4.

April 16, 2014

This is very cool. As I'm sure you found already, there is no collider associated with the struts to cause issues with the method you're using here. Making it so the struts themselves would "decouple" would require a model rework, but I think I have some ideas on how it could work. Something to look into when I go for V4.
Yeah, that weird fuel flow has been an issue from the beginning. I honestly have no idea what the cause is, but I'm pretty sure it has to do with the strange way I built the attachments between the toroids and the hubs. What confuses me is that I expected them to drain in the same order as regular stack tanks (top to bottom, etc), and for the life of me can't figure out why they drain evenly all the time.

The attachment pipes aren't really an issue, and honestly, it looks better with them coming away with the tanks (even if they do phase through the rocket in the process), unless there was a way to truncate them just outside the rim of the hub. And that wouldn't be easy, with the variable hub sizes and all.

The fuel flow is probably because the toroidal tanks are effectively leaf nodes off of the main stack, as if you'd put in the 6-way adapters and stuck rotated fuel tanks on the side attachment nodes. I'm not sure why it drains them all simultaneously instead of top to bottom, though. Maybe it counts from the 'ends' and works back toward the engine (as in, the most distant part is zero and closer parts are 1, 2, 3, etc, but all the leaf parts are also dead ends and therefore 'zero', and it drains whatever parts have the lowest number(s) first...?)

The only way I can think of to solve that problem is to have an intermediate part with crossflow disabled (I tried setting the toroidal tanks themselves to have no crossflow, but that apparently only affects parts *beyond* the one flagged as such). Disabling it on the hubs would most likely prevent fuel flow from the rest of the stack, not just the toroidal tank. Maybe the struts could be that part, but I can't think of a good way to attach the tank to the struts without making it flop around the way surface attachment would or ending up with an off-center CoM...

The best thing I could think of would be some way to make the center attachment node of the hub disallow crossfeed, without affecting the flow between top and bottom nodes. It might take a plugin to make that possible, or it might not be possible at all, and it would certainly confuse things like MechJeb if they didn't understand it.

Another topic: I think you may have mentioned plans regarding this before, but the dry masses on the toroidal tanks seem very high for the amounts of fuel they store. It would be awesome if those were reduced closer to stock tank ratios, even if they were still a few percent heavier in comparison.

Also, have you considered making toroidal tanks with thicker tank sections? I keep looking at them and wishing I could get one with a just over 2.5m inner radius but a larger outer radius so it could hold more fuel, instead of the only option being to increase both and not gain nearly as much fuel space.

There seems to be a noticeable gap in the choices of spherical tank sizes, big enough that a couple more sizes could easily fit with room to rattle around between them. The only spherical tank with a 3.75m end cap is absolutely mammoth in comparison to the next lower size, and I keep looking at the 2.5/3.75m tank and wishing for a 2.5/5m and 3.75/5m, and one somewhere between that and the largest as well.

And on the topic of spherical tanks, the hemispheres seem to have a bit of extra cylinder tacked on - putting two of them together, for example to get different size end caps on each end, doesn't make a perfect sphere. It's like the middle band from the full spheres was kept in its entirety, and only the part of the sphere sticking out below it was cut away. Even if the stats didn't change at all, it would be nice if we could (perhaps optionally, for those already using and/or liking the current models) have hemisphere models that could be mated without the result looking misshapen.

April 16, 2014

One bit of cautionary advice: fuel crossfeed in KSP is some dark arcanery. In general, this should prevent fuel from passing through a part when it's set to disabled. But fuel flow follows a lot of weird rules about attach nodes and orientation and who knows what else, so it will not cause fuel to flow across a part that would not normally conduct fuel in its stock behavior.

I have a pretty decent idea of how it works - I just wanted to be able to toggle crossfeed between certain sections of a stack without having to insert docking ports in the middle of something that isn't intended to be detachable, and this should do the job just fine. Thanks again!

April 12, 2014

Hmm, if you mean the 3.75m I and L parts (the final 2.0 in my last post), I hadn't really thought about the fact that it made them lighter than the 2.5m 6-way part. Still, I don't think there's anything necessarily wrong with that. It could probably be explained by a couple things: the fact that 3.75m parts are only 50% larger than 2.5m parts, and the last post's reasoning regarding the internal structural members being the majority of the part mass. The internal crew tunnels don't need to get any wider either, so that's yet another factor that would scale linearly.

Still, if the given mass reductions for the less-than-6-way parts seem too great, those amounts *were* pretty much off the top of my head. I was looking for relatively easy numbers that made at least *some* sense. The results of that ended up implying that 3/4 of the part mass was in the internal and external structures of the connection faces, which may be a bit on the high side. But 50 / 6 doesn't result in easy to work with numbers. Maybe 60% would be more reasonable. That would give the following masses:

Connections:  6w     X     T      I & L
(1.25m)       1.0    0.8   0.7    0.6
(2.5m)        2.5    2.0   1.75   1.5
(3.75m)       4.0    3.2   2.8    2.4

That would result in a much less noticeable difference between the 3.75m I & L parts and the 2.5m 6-way part. Now that I've put some thought into that, I think I prefer this set of numbers.

April 12, 2014

From the changelog for the structural parts: "- Moved T hub center of mass to be more realistic"

This would imply that some mass has been removed from the part of it where the 4th connection would otherwise have been. Now unless that mass was added back in elsewhere in the structure, that implies that removing a connecting surface reduces the mass of the part. So, even if the small 6-way node is the same mass as the stock node (which I think is heavier than it has any right to be, comparing it to other structural components), I'd suggest giving the 4-way, 3-way, and 2-way parts progressively reduced mass.

If the 6-way node is 1.5 tons, the 4-way could be 1.25, the T 1.125, and the L and I nodes, 1 ton. Personally I would use no more than 1 ton for the small 6-way node, and the others could be .75, .625, and .5 respectively. I mean, really, how thick does the paneling on top of the internal structural supports have to be?

For the 2.5m and 3.75m versions, I'd stick with simply multiplying the mass by 2 and 3. Someone might make an argument about mass being related to volume which is the cube of the part diameter/length, and that's true for solids. But if these parts are traversable by kerbals, they are by definition hollow, meaning it's at most the square of the size (surface area). Further, the main structural strength isn't going to come from the outside paneling but instead, the beams of metal (or whatever material their internal frame is built from), the mass of which would scale linearly with part size. So the truth would be somewhere between linear and square, probably closer to linear (maybe size ^ 1.25). But most importantly, playability: 9 tons (3 squared) for a 3.75m part that does absolutely nothing other than serve to connect other large parts together would simply not be very usable. That's something you can technically do with a .125 ton girder segment and a couple of struts, after all.

So I'd suggest a simple linear scaling of the masses, for example:

1.5, 1.25, 1.125, 1.0

3.0, 2.5, 2.25, 2.0

4.5, 3.75, 3.375, 3.0

or

1.0, .75, .625, .5

2.0, 1.5, 1.25, 1.0

3.0, 2.25, 1.875, 1.5

for the small, medium, and large 6, 4, 3, and 2-way parts respectively. Factoring in an exponent of 1.25, 2.0 and 3.0 become approximately 2.5 and 4.0, so for slightly greater realism the last two lines could instead be:

2.5, 1.875, 1.5625, 1.25

4.0, 3.0, 2.5, 2.0

I hope this is at least food for thought, if not helpful or useful.

April 12, 2014

I'm having a weird issue and I have no idea if it's new with the current version or not...

(Firstly: I have all tech nodes except for the final warp drive node researched. I'm not using beamed power. There is fuel for all engines. The same results apply when switching the thermal rocket to Liquid instead of LFO, save for the usual changes to its thrust and ISP figures. The reactor is in Deuterium/Tritium fuel mode.)

The 3.75m thermal rocket nozzle under my 3.75m Tokamak seems to be eating charged particles as well as thermal power. The direct-conversion generator attached above the reactor can produce up to 9.75 GW, and yet when throttle is at max with no thrust limiter on the thermal nozzle, MJ supply is only 2.32 GW. (Not even enough for one DT Vista, much less the two that are mounted on this ship.)

I've carefully examined the interactions between the reactor and thermal nozzle (with the vessel launch-clamped on the surface), and it seems that while at approx. 80% reactor activity (throttle about halfway between max and the 2/3 tick) it produces 1.1 GW_cp (the minimum it ever seems to produce) and 43 GW_th, with the rocket nozzle producing 1884 kN of thrust. If I set it higher, the thermal power output stays the same (as expected) but the charged particles go up, and the thrust from the rocket nozzle increases toward a maximum of 2298.4 kN (ISP of 1650.5 using LFO), although it varies slightly over time as the amount of stored TP approaches zero. At max throttle the reactor shows production of 9.0 GW_cp, out of 11.5 maximum.

The power management display shows a theoretical supply of 9.75 GW (which seems slightly off, since 11.5 * 0.85 = 9.775 actually) with a demand and current supply of 185 MW (for the cryostats and antimatter storage tanks on the vessel) for 1.896% utilization. If I shut down the thermal rocket and activate the vistas, this becomes 5.18 GW demand and 53.154% utilization, while the reactor shows 19% activity, 4.3GW_th and 6.1GW_cp. As soon as I activate the thermal rocket though, the generator shows a power output of only 2.32 GW, leaving net power at -2.86 and the supply of stored MJ quickly runs out.

At idle, the reactor runs at 10%, outputting 4.3GW_th and 1.1 GW_cp. If I use a thrust limiter setting on the thermal rocket, I can run it at up to 93.5% (2149 kN) without the charged particle supply decreasing (the reactor shows 99.987% activity) but any higher and I eventually lose power, causing one of the Vistas to shut down and send the ship into a tumble.

I'm almost as confused that the thermal rocket can use most of the reactor's CP supply but not all of it (as evidenced by the 9.0 out of 11.5 CP output at full thrust), but really, why it is using ANY of it at all? In D/T mode, 10% of this reactor's energy output is in a form that it shouldn't be able to use at all...

April 12, 2014

That's perfectly alright, I run with the texture resizer anyway (so many mods!) - I'm not concerned with uber-detailedness. If you're going to make official 3.75m versions I'll wait for that instead of doing my own so I dont' have to deal with part name changes.

April 12, 2014

Thanks Toadicus, that would be really awesome.

April 12, 2014

X and T components?! AWESOME!

Not available in 3.75m? Sadface...

April 12, 2014

As Cpt. Kipard hinted, we've developed a plugin to handle the universal docking ports so no one need settle for such a "poor man's" solution. The tweakable idea had occurred to me as well, though!
At present no; there's no functional granularity available below the module level. I'll look into the possibility of adding a config file to disable tweakables that you don't want, but I'm not going to break the functionality out into an entirely separate module.

Well, the reason I was asking is that I wanted to be able to add a module to other parts that would let me disable crossfeed... Would using the tweakable module for docking ports to do that cause problems, or work fine (except for cluttering up the menu with useless controls)?

Also, I assume the updated universal docking ports work fine with this one? I'll have to give that a try.

(PS. I am curious, though, why you're opposed to having the crossfeed control as a separate module.)

April 10, 2014

Is there a module aside from the one that contains all the other docking port functionality (I assume applying that module to something that wasn't a docking port wouldn't end well) which would allow fuel cross-feed to be toggled on a part, in the editor and in flight? If not, could that be offered at some point in the future?

April 10, 2014

And toroidal tank could be even better if we are able to "cut" the 3 struts joint allowing us to remove dead weight, the rocket passing "through" it, as long as it is big enough.

This... I love this idea. An optional decoupler module to cut them free of the hubs would be amazing.

I'm using a mod that adds VAB-tweakable toggles to remove (even stock) decouplers from staging, so I know it COULD be made optional even without creating new parts. And as long as the tanks' colliders didn't extend inward along the structural members (something I will need to test) there'd be no risk of collision even without modifying the models. They already count as stack-mounted so fuel flow wouldn't be a difficulty, although pipes might be required to get the rearmost toroid to drain first if more than one was used or they were placed behind other standard fuel tanks.

I suspect a Module Manager patch could even add such a decoupler without requiring any other changes... Hmm, time for some hacking!

Edit:

With TweakableEverything and the following in a MM .cfg you can have an optional decoupler in the toroidal tank hubs which will detach the tank. You can use it without TE if you prefer but you won't be able to disable the decoupler module in situations where you don't want it.

Another option would be to duplicate the four hub parts, adding something like 'Decoupling' to the part names, but that's more the author's purview.


@PART[TAL_Toroidal_Tank_Hub_*]:FINAL
{
	MODULE
	{
		name = ModuleDecouple
		ejectionForce = 0
		explosiveNodeID = center
	}
	MODULE
	{
		name = ModuleTweakableDecouple
		decouplerModuleName = ModuleDecouple
	}
}

Looks like it behaves rather oddly with fuel lines though. It seemed to be draining all of the toroids evenly, even though I had pipes hooking them up in series from bottom to top. Also, MechJeb apparently got VERY confused about the remaining fuel, and once I started decoupling toroidals it thought there was zero dV remaining and did some strange auto-staging on me. It might be better off to put the decouplers in the tanks after all, rather than the hubs.

Edit 2:

Fixed previous code, forgot to have FINAL on it.

Putting the decoupler modules on the tanks themselves fixes MechJeb's confusion, and it autostages properly. But fuel flow is still derped up despite the fuel lines. Probably a KSP thing. The only way I can think of to fix that is to be able to optionally disable fuel crossfeed on the tank parts via some tweakable. If you weren't using the decoupling option, you probably wouldn't want it disabled, and you might not even if you were, but this little test ship I launched really has it behaving strangely.

Here's the tank-decoupler config:


@PART[TAL.Toroidal.Tank.*.Fuel]:FINAL
{
	@fuelCrossFeed = False
	MODULE
	{
		name = ModuleDecouple
		ejectionForce = 0
		explosiveNodeID = center
	}
	MODULE
	{
		name = ModuleTweakableDecouple
		decouplerModuleName = ModuleDecouple
	}
}
@PART[TAL.Toroidal.Tank.*.Utility]:FINAL
{
	MODULE
	{
		name = ModuleDecouple
		ejectionForce = 0
		explosiveNodeID = center
	}
	MODULE
	{
		name = ModuleTweakableDecouple
		decouplerModuleName = ModuleDecouple
	}
}
@PART[TAL.XLarge.Toroidal.Tank.Fuel]:FINAL
{
	@fuelCrossFeed = False
	MODULE
	{
		name = ModuleDecouple
		ejectionForce = 0
		explosiveNodeID = center
	}
	MODULE
	{
		name = ModuleTweakableDecouple
		decouplerModuleName = ModuleDecouple
	}
}
@PART[TAL.XLarge.Toroidal.Tank.Utility]:FINAL
{
	MODULE
	{
		name = ModuleDecouple
		ejectionForce = 0
		explosiveNodeID = center
	}
	MODULE
	{
		name = ModuleTweakableDecouple
		decouplerModuleName = ModuleDecouple
	}
}

YetAnotherEdit:

Okay it's not the fuel lines' fault. Even without any of them, it drains fuel from the toroidal tanks, evenly, before draining any from regularly stacked tanks. Regardless of the relative position of the toroidals' hubs and the normal tanks in the stack. And even changing fuel cross-feed to false, like in the above config, doesn't stop it from draining fuel from them. I'm really confused now. Maybe crossfeed has to be disabled on the part that a tank is attached to? But that doesn't explain surface-attached fuel tanks not feeding fuel to the stack they're mounted on...

April 8, 2014

It was previously stated to be a limitation of KSP's config node loading behavior, I believe. I know I've seen plenty of people having problems with it even on 1.5.6 and prior.

From what I've read: Everything before an opening curly brace has to contain no inline whitespace or it gets truncated at that point. Module Manager doesn't even see the node names until after they're loaded and this has already happened. Pretty sure it's unavoidable.

April 7, 2014

Yeah, KSPI's assumption that LiquidFuel is hydrogen is a bad assumption, sadly. It would be nice if he'd add Hydrogen as a separate resource. Maybe some future version...

April 4, 2014

I see what you mean, that makes a lot more sense now.

Maybe eventually the author can find a way to instruct the fairing/fuselage parts to break those extra connections when the adapter itself has its decoupler triggered. But either way, the name "auto-struts" is indeed extremely misleading, and really should be changed. Maybe "Extra Joints" or something to that effect.

I had thought that option was simply *not working* correctly, since I never saw any actual struts appearing, and I didn't know that Kerbal Joint Reinforcement was the only reason it wasn't getting stuck together.

Thanks for the explanation!

April 4, 2014

That's odd, I haven't had any trouble decoupling the interstage from the stage above it with fairings still attached - I put them up in stage 1 so they wouldn't separate from the adapter. And I was using your hollow version too, if that makes any difference. But I was sure you had suggested using fuselage pieces in a previous reply to me - and wouldn't that result in this exact situation? Why would it work differently, and what would the struts have to do with it? If the adapter itself decouples, all the struts connecting the rocket to it or any fairings or fuselages attached to it should break, just like when you decouple anything else that's strutted, right?

March 31, 2014

For the problem where sometimes right clicking on the part your Kerbal is carrying gives you the context menu for the Kerbal instead of the list of KAS options for the carried part: I think I've fixed it before by switching to a nearby ship with the bracket keys [ ] or if that doesn't work returning to space center and using tracking station to get back. Otherwise, just press H to get into attach mode without using the menu.

And regarding the "Attach on EVA" flag, when the docs say "Allow part to be attached on kerbal eva" they mean "Allow part to be attached to a kerbal who has gone eva". I've tried it - the part becomes one with your Kerbal and can't be removed except by having him enter a command pod, causing it to disappear. Doesn't seem like a very useful option for anything I can think of.

March 25, 2014

Probably because stock only comes with parts up to 2.5m in size. Would be nice if it still added them anyway, though. KW Rocketry is pretty common, at least, with 3.75m parts, and I know there are other mods out there with 5m.

You can easily add tech nodes to the .cfg files, or even use a Module Manager .cfg to do it. For example,

@PART[KzProcFairingBaseRing3_75]:HAS[!TechRequired]
{
TechRequired = specializedConstruction
}
@PART[KzProcFairingBaseRing5]:HAS[!TechRequired]
{
TechRequired = specializedConstruction
}
@PART[KzProcFairingBase3_75]:HAS[!TechRequired]
{
TechRequired = specializedConstruction
}
@PART[KzProcFairingBase5]:HAS[!TechRequired]
{
TechRequired = specializedConstruction
}

Just put that in a text file with the .cfg extension in your GameData folder, assuming you already have Module Manager there. Lots of things come with it, or you can grab it at http://forum.kerbalspaceprogram.com/threads/55219-Module-Manager-1-5-6-(Jan-6) and next time you start KSP those should appear in the Specialized Construction node (that's where I chose to put them, you can edit that if you wish).

March 24, 2014

Land everything on your planet, in an ore field.

It helps to find an ore field that overlaps with a kethane field. I usually find at least one to three such locations on a planet. The kethane electric generator is wonderful for dealing with changing electrical requirements, especially at night. Otherwise you can always ship in kethane and/or fuel.

"Everything" is a drill, a smelter, a rocket workshop, and at least one container each for ore, metal, and rocket parts, and finally a launch pad or (my personal favorite) orbital assembly port.

Converting ore to metal is the biggest bottleneck I've found. Small drill, big smelter (if possible). If you're bringing along a workshop, you don't need any other parts that convert metal to RP, it will do the job for you.

I started my Ike base with Bahamuto's small drilll, a tiny smelter, the small kethane drill, the small kethane converter, and the kethane generator on one lander, and used another vessel to haul the metal to my orbiting command ship. Then I built and landed a workshop and launchpad, at which point I used them to construct a large smelter on the surface.

If you land them sepearately, though, you will need to dock them together on the ground (which frankly is harder than just giving up on the whole thing and resigning yourself to launching everything from Kerbin) or install Kerbal Attachment System and hook things together with pipes.

I've used both approaches in the same base. KAS is amazing for hooking up mobile units like rovers or surface-to-orbit freighters. But if you design each module with landing engines, it's not too hard to use those same engines to fine tune the height of docking ports and thrust with RCS to get them to attach more easily. I'll pastebin an example module - the large smeltery I added - which shows off a number of the techniques I've picked up. Vertical-snap for landing leg positioning, rover wheels for easy maneuvering and positioning of modules, vertical engines and horizontal RCS are the main items on the list. And I recommend a number of reaction wheels for heavy modules.

Example: http://pastebin.com/JJ9sH1QD

March 23, 2014

http://imgur.com/a/1wRdE#23 ? That's Kerbin, some peninsula that happened to be where a lander was returning. I don't remember exactly where. Maybe it's the edge of the big impact crater?

I'd honestly prefer the extra button-pushing to having it spawn automatically - what if I'd switched from the base to something else in the area while waiting for it to finish, and was in the middle of hovering some previously built heavy station module into position, and suddenly my computer (already getting only a couple FPS at that base shown in those pictures) freezes up to spawn the next thing, or the appearance of it causes the pad to shift and make the base jitter, or... who knows what could go wrong? The more control the user has, the better, in my opinion.

If you're not using progressive builds, of course, there'd be no need for an additional click - that first click on the "build" button, which I'm assuming can't be done during timewarp either, is the equivalent of everything that comes before "release". And you could always add a config option to use or not use the extra button. Yeah, I know, it's more work for what might not seem like much of an improvement. It's up to you, of course. But I, for one, would really appreciate that option.

I actually did get my whole base exploding once* tonight even though I'd slowed it down half a minute before the craft spawned, on one of my tiny little lander probes even. I think I may have clicked "release" too soon, though. And like I mentioned, my old Core 2 Duo is only giving me a scant few frames per second at that base. The transition when those landers launch and get past the 2.3km mark is startling - it feels like suddenly zipping to 10x timewarp. I've seriously overshot my intended AP at least twice because of that transition. XD

(* So far I've had two, maybe three base explosions, promptly quickloading, for some eleven successful builds there - mostly shooting off those science lander probes. Amazingly, I built the pictured 18+ ton smelter module on that pad with no problems.)

Best advice: Pause build, quicksave, resume. Do it before starting, do it near the end (around 2/3 to 80% depending on how long a build it is), then do it again with 2-5 rocket parts left to consume. Don't leave the scene with it running and expect it to be done when you return (if it is, it'll try to spawn instantly, while the scene is still unstable). Don't leave the area while anything is on the pad un-released (I've had it "lose" the unreleased craft and the pad stop responding several times while testing various things). If you have to leave the scene, pause build first. Try not to let TAC Fuel Balancer or Kethane processing or anything else cram resources into the "docked ship" before hitting release, the CoM shifts might throw things off. And don't forget the landing legs, etc.

Edit: Just thought of a really good reason to have that extra button. Hypothetical yet very plausible situation:

I've just completed a build and released it. Craft is sitting on the pad just fine. Before taking control of it I start a new build (I know I just said don't do that, but ideally this is something you'd want to be able to leave running in the background). Then I switch to it and take off. Before the next point at which the game can write the persistence file, KSP crashes. I get fed up and go to bed. The next day I come back and head to the VAB to design something new, entirely forgetting about the ship I'd queued up. I fly something around, quicksave, do whatever, land, quicksave, recover the craft or just go back to the space center, then decide to get back to what I'd been doing the previous night. I switch to the base with the launchpad, which has had time to complete construction of the queued up craft - but because everything that happened from the point where I'd removed the previous craft from the pad never got saved due to the crash, that craft is already sitting on the pad. We now have two craft occupying the same space, with no opportunity to prevent this.

"Wow! Very exploding! Such loud! Many disappointment! No insurances?" Or, "All your base are on the way to destruction! Ha ha ha!"

March 23, 2014

Taniwha, I have vessel explosion few second after production finished, even if if's already released, when production finished at time warp (and it turn back to x1 automatically). When I change time warp manually to x1 it always works well. State of launchpad is prelaunch or landed.

Honestly, just cancelling timewarp isn't enough... I'm really not surprised that things explode. Even without large structures docked together with KAS attachments or clamp-o-trons, things can twitch and shudder quite violently when coming out of timewarp - even more so if they're landed. This seems to increase exponentially the larger the structures get. The physics engine needs time to settle things down after unpacking, BEFORE something new gets spawned and docked onto it all.

Any time I let EL cancel timewarp, or do it myself just a little too late and it constructs the new craft while things are jerking about, I seem to have a good 50% chance of my whole damn base exploding as soon as I release the craft. But if I slow it down early and wait out the last 20 seconds at 1x, I have yet to have any issues. Except, paradoxically, with constructing very light items on an orbital dock, such as lone KAS containers full of goodies - they apparently count as slightly too close to the dock, and on release, they spontaneously combust.

Taniwha: With progressive builds enabled, would it be very difficult to add one more button click between completion and the actual construction of the craft? So, when the last .01 rocket part is consumed, it kills timewarp - but intead of instantly trying to assemble the project, the "pause build" button becomes a "Finish Assembly" button, which can only be clicked when at 1x time and the situation is stable (like, you can right click on solar panels and extend/retract them - which you can't do in the first few seconds after exiting timewarp). I believe this would significantly reduce the frequency and severity of problems.

I'd also like to comment on Rocket Parts as a resource. I think they should stay. You don't assemble a ship out of raw metal, after all - nor do you hand-craft every screw, washer, panel, and hose. Many common components and materials are mass-produced, and then processed further into specific part designs, and I think RP are a good representation of that intermediate stage. The way I see it, the Kerbals working in the workshop are turning the common, mass-produced components, sheet metal, plastic, wire, transistors (or perhaps vacuum tubes?!), and so on into the actual "parts" (in the KSP VAB sense) used in whatever is being built, and then, finally, assembling those parts into the complete ship out on the launchpad or construction dock (That's the step I suggested adding the new button for).

Everyone: One thing I've discovered is that it really helps to keep the bottom-most collidable component of whatever you're building separated from the launchpad or construction dock using pre-extended landing legs, ladders, even antennas, or rover wheels. All of the above shift the "bottom" of the craft down below the real "solid" parts of it, making sure (okay, 99%) that they don't clip into the dock/pad and explode when released.

Finally: Hooray for launching half a dozen small lander-probes from Ike and setting them down on Duna, each one leaving a tiny sub-probe in orbit, then raining them down for massive seismometer science points. Thanks, EL and KSPI!.

(Here's a shot of the lander I was using if anyone's interested: http://imgur.com/a/1wRdE#4 )

March 20, 2014

Taniwha: Thanks for the quick answer. I'm not familiar with the inner workings of kerbals' stats - are you saying that an empty stupidity bar (lowest possible value) is not stupidity = 0? That is, rather than represented as (for example) 0.0 to 1.0 it's more like -1.0 to +1.0?

So, if their stupidity bar is above 50% (or whatever point corresponds to zero), you want as low a courage as possible... but if it's less than that, you want a high courage? How low does it have to be for courage to start providing a bonus? And does that bonus get scaled with how low stupidity is just like the penalty gets scaled by how high it is?

Sigh, now my hiring decisions will be even more complicated... I feel like the astronaut complex should now list a kerbal's calculated productivity scalar by their stats so you don't have to "test" them all on the ground before deciding who to send on your one-way colonization mission to Jool.

March 20, 2014

I just did some testing on the runway, having various kerbals with different stats hop in and out of an otherwise-vacant workshop, and found something surprising. Higher courage results in lower productivity. Is this intentional, or a case of "oops it should've been the opposite of the calculation used for stupidity"?

I would expect higher stupidity to lower productivity (just as it can with science, or so I've heard) but I don't see how being brave would translate to shoddy workkerbalship. Machining processes dealing with often sharp, frequently heavy bits of metal alongside various mixes of pressurized gases and explosive compounds in an environment where a mistake could cause a hull breach, even if it doesn't kill you directly, is certainly not for the faint of heart!

March 20, 2014

Oh, I see what was going on then. I just had fairings on one of them, extended to cover the entire gap. I'm not entirely sure what the benefit of the two floating nodes attached to each other is, then. The floating node on any version of the interstage adapter seems to make engines skip their own auto-fairings regardless.

Also, KSP normally destroys struts between decoupled sections anyway. It doesn't require KJR for that - although I know there had been bugs with that in stock KSP, such as decoupler force being canceled out...

March 20, 2014

For anyone else who's tried to make the container bay storable, grabbable, and/or attachable...


@PART[KAS_ContainerBay1]:HAS[!MODULE[KASModuleGrab]
{
!mesh = containerBay1.mu
!scale = 1
!node_stack_bottom = = 0.0, -0.8050, 0.0, 0.0, 1.0, 0.0, 0

@rescaleFactor = 1
@node_stack_top = 0.0, -0.35625, 0.0, 0.0, 1.0, 0.0, 0
@node_attach = 0.0, -0.4025, 0.0, 0.0, -1.0, 0.0

MODEL
{
	model = KAS/Parts/containerBay1/containerBay1
	scale = 0.5, 0.5, 0.5
}

MODULE
{
	name = KASModuleGrab
	evaPartPos = (0.0, 0.10, -0.15)
	evaPartDir = (0,0,-1)
	storable = true
	storedSize = 8
	customGroundPos = True
	dropPartPos = (0.0, 0.2, -0.55)
	dropPartRot = (-10.0, 0.0, 0.0)
	attachOnPart = True
	attachOnEva = False
	attachOnStatic = True
	attachSendMsgOnly = False
}
}

This combines the config heralo came up with that fixes the model with some parameters I'd picked to position things better and make the racks storable.

According to a comment in the part.cfg for the container bay, there was some kind of bug with scaling that must have prevented the use of the model node. I tried to look it up, but there isn't any bug listed at the given URL (either open, closed, or anything else, as if it was deleted). However, everything *seems* to work just fine using this config.

Profiles

Forums

Developer Articles

KSP2 Release Notes

Posts posted by Tallinu