Starwaster

The problem was seen before it happened Edit: concerns were raised about O seal integrity being compromised after a brutally cold night. Engineers were overruled by managers. This is hardly a new problem either. The same thing happened over 20 years before when Apollo 1 astronauts complained about flammable space suits, hard to open hatches and other fire hazards that they asked to be fixed and never were, until after the fact of their deaths. Columbia too was avoidable. Concerns had been raised about a possible debris strike during launch. Again, those in authority decided that there was no way to deal with related problems while in orbit so the matter wasnt pursued further.

sorry I ate all the snacks. Nobody told me we were having newbies over!

Ahhh I only saw agises' example

Just because the real life space shuttle had no such system is no reason That we have to constrain ourselves. (interestingly enough, the crew compartment of the Challenger survived the explosion of its EFT intact. Given the nature of its construction, it's not outside the bounds of possibility to have given the entire crew compartment a means of separating from the rest of the shuttle to act as an escape pod withs its own parachutes and braking rockets)

Ok so after months of not using this (more time doing some modeling and some light coding for some mods) I've picked up the latest version of this and it looks like the scrubber bug is still around? Is that really the case? How many people still use this? I'll take a look to working on some of the bugs if anyone's interested and If I can get some people to summarize what the biggest bugs are.

The problem is not with the nuclear engine. Respectfully, the problem is with your understanding of rocket science. DeltaV computations are based largely in part on mass and hydrogen is the least dense of all the elements. Put another way. Hydrogen has the greatest ISP per kilogram of any other propellant. Per kilogram. It is ~70kg per kiloliter. So what you need to do is use larger fuel tanks. Possibly as much as 11 times more by volume.

If he or anyone is duplicating a part, the name on the duplicate part had better change. Either because it explicitly gets changed by the duplication config or because ModuleManager gets coded to automagically change the name. The consequences of not doing so are having two duplicate parts in the VAB/SPH and then actually taking that part into the world and having it revert to the first part that KSP encounters with that name. i.e. you have two parts with the same name. The first one just a static part, the second has modules and/or resources. In the VAB you will see them as two separate parts and the changes that differentiate them are apparent. However, in the 'real world' only the static part is ever loaded because that was the first one that had that name when KSP went to look up that part.

It's probably a problem with the hatch collider being too low to the science pod mesh. It can make it difficult to click on sometimes, from certain angles.

That could be done as a rescale easy enough, or maybe incorporating support for other mods that resize parts (to avoid part bloat) but I was also thinking of similar parts to these but with the top and bottom nodes scaled up to twice the diameter of the side ports. So two 2.5m top / bottom and the six side connections stay at 1.25. That would change the overall geometry quite a bit...

no problem! glad you got it sorted

White hole sun, won't you come....

model000.mbm is its texture file You should be finding it under the structural tab. No idea why you are not. Try looking for it again in case you missed it; if you don't find it, post your output_log.txt file from KSP_Data folder. Or if you're on Linux/Mac, post player.log Do not under any circumstances post ksp.log or you will be laughed at. use dropbox or pastebin to post the log.

Looks nice but I don't like the idea of slapping things on top of the wings that might confuse FAR.

I suggested that a long, long time ago. It occurs to me that there's a way to hack it in with some creative Module Manager editing of the MODEL node, an invisible mesh to put the flag on and a DecalFlag module with the name of the mesh plugged into it. The only thing lacking is knowledge of mesh coordinates so that it sits on the wing properly.

Plus, someone from NASA might play the game. Can't have them going inside a Fustek module and saying, "Hey! They got that wrong!"

Oh please, I was checking this thread for updates on inflatable habs before it became fashionable to check this thread for inflatable habs! Ahhh this brings back memories.... or flashbacks rather, to launches gone bad and me trying to sneak the camera into the fairing to click on something that was causing the launch to go bad so I could stop it from causing the launch to go bad. Fun times.... fun times.

Should be, but of course bugs happen. The whole point of the recent flurry of updates is to make old save games more stable when their modules get munged by new mods. MM is also backing up your saves so if something does go wrong, you should have something to fall back to. @Sarbian: Do we have a changelog of what was fixed in 2.1.4? Edit: Also, do we have regexp on general matching now, or just for mangling strings? For instance, if I wanted to match on a non-zero number, can I do that now?

Wait... you're telling people to add to the wiki who you're referring to the wiki because they need information about FAR's aerodynamics and how it's giving them and their planes the shaft. Question: How are they supposed to add to FAR's wiki if they can't figure out FAR in the first place?

I plan on doing some minor model reworking of some parts. The trusses will have their struts thickened a little, but not a lot. (if you look at any of the NASA /GRC concept art, they're not that thick to begin with being made of advanced composites). Some art reworking and the plugin for node resizing will be updated to remove debugging messages. I'm not sure beyond that what more I'll do as I don't see a lot of feedback except from a few people. and one of those on someone else's thread :\ Oh and some updated craft filez to take advantage of the new Procedural Fairings update, including the procedural thrust plate.

Well there's not really a whole lot to teach. They're stack nodes by virtue of not being attach nodes, of which you can have only one. (i.e. node_attach, not to be confused with the generalized term 'attach node') They always begin with 'node_stack_' and whatever name you chose for them, except that I think the game has special cases for nodes named top/bottom, so you should probably respect that and name your top and bottom nodes node_stack_top / node_stack_bottom. So, let's start with node_stack_side1 node_stack_side1 = 0.475, 0, 0.8227, 0.500011, 0.0, 0.866019, 1 First three three numbers are the coordinates for the node and are where a part will physically end up when attached. node_stack_side1 = 0.475, 0, 0.8227, 0.500011, 0.0, 0.866019, 1 Second set of three numbers can be treated as a surface normal, except that they indicate which direction the part you are attaching to this node will face. For attach nodes that are situated exactly along the X, Y and Z axes, it's easy to figure out the normal. In the case of node_stack_side0, this node points away along the X node_stack_side0 = -0.9325, 0, 0, 1, 0, 0, 1 However, node_stack_side1 is different. It points at a diagonal on two axes. Treat the first three digits as a vector and normalize it. If you're not sure how to normalize a vector, visit www.wolframalpha.com and input the first three numbers (the coordinates of the node, which we take to be a vector pointing away from 0, 0, 0) and Wolfram will spit out some information about those numbers, including treating it as a vector to be normalized. Here, I've input the coordinates for node_stack_side1: http://www.wolframalpha.com/input/?i=0.475%2C+0%2C+0.8227 Scroll down the page a short ways and you will find the normalized vector of: 0.500011, 0., 0.866019 which is what we'll use for the next three digits as indicated above. The seventh digit is the size of the node and controls how easy it is to snap to that node. If something you're attaching has one of its nodes inside the first part's attachment node it will snap. Large nodes make it hard to snap when you have numerous very small nodes to choose from on the part to be attached. However, large nodes also control connection strength and the greater the size (up to size three) the more additional connection joints are created. (these are invisible and reduce wobbling in 0.23.5+) node_stack_side1 = 0.475, 0, 0.8227, 0.500011, 0.0, 0.866019, 1 node_stack_side0 = -0.9325, 0, 0, 1, 0, 0, 1 node_stack_side1 = 0.475, 0, 0.8227, 0.500011, 0.0, 0.866019, 1 node_stack_side2 = 0.475, 0, -0.8227, 0.500011, 0.0, -0.866019, 1

But of course they do! I'm not even sure attachment nodes have a limit as to quantity. Practical limitations perhaps but as far as I know you can have as many as you want. (at least up to maxint....) And they can have any orientation you want too just as long as you define the normal correctly. The only hard part, if such there was, was that the five port hub unexpectedly flipped 180 degrees on its Y axis. Actually, for all I know, so have the other models I've done. Except that they were symmetrical so escaped my notice. I had to reverse the position of the nodes on that one. I have no idea why it did that unless it's a side effect of me using XSI / Softimage / Mod Tool / whatever-the-hell-they-call-it-these-days.

Right above the album! It uh... was there all along and you just didn't see it. I totally did not forget the download and totally did not hurriedly edit the post to fix it....

Change Log 1.0.0 - Release! 1.0.1 - TweakScale configs added (unreleased version) 1.0.2 - Connected Living Space configs added. 1.1.0 - GingerCorp added as contract dispensing agency.

Here's a couple of stock-alike station hubs. These are stylistically derived from the stock six port station hub. However, these two have three and six side ports instead of four. Good for building alien themed stations. Now with GingerCorp as a contract dispensing entity! Download: https://github.com/Starwaster/Stockalike-Station-Hubs/releases/ If you find this mod helpful and want to throw some money away, feel free to click the donate button below! Demonstration Screenshots GingerCorp Stock-Alike by Starwaster is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

The frozen Kerbal thing is a known issue. You need to update KSP. (same version; newer build number)