Tiberion

Its a texture loading bug in the game. Exit out to the space center, hit Alt+F12, go to Database tab and hit reload (then hit alt+F12 to close the window again) - it should look right now. If you use ModuleManager its Alt+F11 (I think?) Also, Merry Christmas (or whatever else) to everyone and thanks for all of your support. More good things to come in the future, I hope

No problem. The referencenode is used to signal which node is "linked" to the docking transform, so that it can be "undocked" the 1st time from whatever it was stacked with in the VAB without the need for a decoupler. You can do a dockingnode without a stack node assigned (example: the shielded Clamp-O-Tron stock docking port)

Here's whats going on onboard the ISS today: http://time.com/meet-the-twins-unlocking-the-secrets-of-space/?pcd=hp-magmod So yeah, manned spaceflight is a thing. Really no use arguing about it anymore.

Try explicitly adding the "nodeTransformName = dockingNode" to your ModuleDockingNode, using your transform's name of course. It can be left out if your transform is named the default/expected name (which I assume is dockingNode, but I don't remember) but it's acting like the transform isn't being located.

I wasn't the one that brought up PR value, I was just saying that EFT-1 had the most PR "heat" - it wasn't just celeb endorsements - they trucked that orion mockup or the inflatables around the country to airshows and all sorts of events and people turned out. Its pretty clear that manned spaceflight will enjoy more public support, for all that matters. It doesn't affect the quality of the missions, though it could affect how easily congress would cut funding or cancel something, though not much I think. And I totally agree about not putting all our eggs in one basket. I wasn't the one arguing against manned missions and suggesting we limit ourselves to robotic exploration either. Which is like putting humanities eggs in a basket and then just sort of studying them with a camera. There are so many challenges ahead for Humans in space, it's going to take a diverse set of missions to guve us the capability to move among the stars. We have to explore and understand our solar system, which robots are quite suited for. We have to refine how we move and live in space, better propulsion and life support, shielding, and all of the technological hurdles. And we have to learn how humans will adapt, how we must train and how we'll change as we live in space for longer and longer periods. They are all important, and we can't just abandon part of it because the others are cheaper and easier to do. If budgets and political nonsense are the way, we have to fight it. I think most of us reading this are from a free society where democracy in action can in theory be used to change things. Just look at how the Planetary Society has pushed back against the eroding planetary sciences budget over the last year. NASA isn't perfect and maybe the Venus plan is too crazy to happen anytime soon. Maybe stupidity will reign once more and the SLS/Orion projects don't lead us down the path to Mars. We still have to try, to take those risks. I am conservative about a lot of things, but this isn't a place we can afford to be. Let's go back to talking about Venus, eh?

The biggest scientific ROI is the ISS, though if you roll all of the NASA Mars rovers as well as the orbiters together as one project its probably close. As for PR, I'd say Orion EFT-1 and the #ImOnboard campaign probably wins that pretty easily, and it was only an unmanned test flight for some future manned mission. There was just an insane anount of celebs and people involved all the way through 2014. I can't imagine how much it will expand when they actually launch people out of Earth orbit again There is no waiting for manned missions to be more favorable. You either press on through budgetary issues and do them, or you don't and you don't progress human spaceflight, and we remain chained to Earth.

You guys can't just gloss over the "human" part of human space flight. The exploration of space by humans leads to us being Earth-independent, which at some point in the future that none of us (and hopefully not even our great-great grandchildren) will see will allow the human race to survive should it become impossible on Earth. Or even just as a means of expanding out into the universe even if Earth remains perfectly fine. Learning about whats in the rocks on Mars, or what is under the ice of a moon, or anything that robotic missions can do are very good things to know, but by far our biggest hurdle is learning how to live in space, or in other places. Long duration human spaceflight, and the science we gather from it is key to this. It's pretty much been the focus of the Russian space program (outside of other political considerations) and its been a huge part of NASA as well, not just in the early days of Mercury, Gemini, and Apollo, but with a lot of the shuttle missions as well. And its certainly the primary mission of the ISS. Someday the ISS will retire, and we might reach the limit of what we can learn from a station in orbit. The next step is almost surely Mars, and before that they'll prepare via orbital missions around the Moon and just maybe to some asteroid orbiting it (who knows, it could still happen) Certainly a Venusian airship sounds more exotic, but again the benefit of sending people would be learning more about surviving in different environments. You can predict how a person living in a Venusian airship will react, but until it happens, its just a prediction. We aren't playing KSP here, where we're trying to get as many science points as possible in the smallest number of missions. There is no "one" way to explore space

Hmm, that is weird. Click the "center" button on the Unity Ui to swap it to Pivot, and check where the pivot of the collider object is. It needs to be within the mesh itself. In fact, another thing to try, drag the collider and thrustTransform object in the hierarchy so that they are parented to the "model" object - since I assume your part exporter script is on Gameobject, it is ignored in the hierarchy and that just leaves 3 separate top level objects which might be preventing KSP from recognizing the collider.

Making a landing leg with suspension is a huge pain. Maybe even worse than a wheel. Here's some images of the landing leg from my Odin pod. took me forever to get them working even halfway right. whellCollider is at the bottom of the piston travel, its origin closely matching where the origin of lowerPiston (the leg's transform and also the silver inner piston model) will be when extended. and the end of the wheelCollider's "line" reaching to the Foot when extended. Note that since lowerPiston is the transform in the config, the module moves it and any children along the suspension length. The pistonCollider is the one that will actually touch the ground and travel with the suspension. The Foot itself should not have a collider. ANY Mesh collider that interacts with the wheel collider will probably cause it to fail and let the leg collapse. That is why I have the simple box collider "objCollider" to provide collision for the upper part of the whole thing. My animation is imported from Blender as "Deploy" with frames 0 to 99 using the Legacy rig, its contained on the Odinleg2 parent object as an Animation widget. Maybe all of that will let you figure out what to do with yours. Its mostly trial and error and trying not to punch things.

Well, you CAN have multiple gimbal objects, but they will all rotate from their origins according to the flight inputs, and if they are offset from the centerline (say + and - X) then the + side will rotate one way and the - side the other way when yawing. Whereas all objects that are the childen of a gimbal object (and not sharing the gimbal transform name) will just move with it - so depending on what looks better, you can have the arms static, or move with the gimbal. If you keep the gimbal range low (like <5%) then the amount of visual "travel" is limited and it might look okay without detailed inspection. Also, the position of the origin matters a lot, so if you move it up level with the top of the arm brackets, it might look like the whole thing is swinging from the frame mount.

Yeah given that your engine is fully modeled, there would be a pivot point that the chamber, pump assembly and nozzle all rotate around, between them and the brackets that mount it to the tank. In a lot of KSP engines they sort of fudge it and have the nozzle and throat separate from the pump and chamber section, and just gimbal that part; it's even less ovvious if most of it is hidden behind tankbutt and the like.

Yeah smokePoint or whatever should be +Z down. Or rather, its more correct to say that your FX outpoint to be towards that objects local +Z, so you point that where you want your the FX to go. The same applies to thrustTransform as well. You could have the thrustTransform pointed straight down (global +Z) and have your engine's nozzle/bell and the smokePoint pointing 45 degrees off if you wanted and it would still work. Most of the time they'll be aligned though (and previous to the fairly recent engine module update, it was hardcoded that they were aligned.) Also, yes you must reload for any cfg changes as well. The reload button basically reloads all the assets in GameData Do note that it can get in a weird state sometimes, so if you seem something odd and you can't seem to fix it, be sure to restart KSP entirely before you start tearing things apart.

Hmm, it all looks okay, the only thing I can possibly see is the name of your export container "BE-4 Export 2" - I've never tried having spaces in the hierarcy of names, so that could be breaking the path that the engine module is using to find the thrustTransform (while the asset loader is fine with it, it loads pretty much anything. Try naming that BE4_Export_2 and exporting again. Also, the purpose of that "smokePoint" object is to let you set the spawn point of your flames and smoke in a different place than the thrustTransform, I typically find I have to offset the smokePoint 'down' a bit to get the flame to hit the engine right. The separate objects are also useful for multi-engine or nozzle parts and other useful things. Also, I assume the thrustTransform is oriented with +Z (blue arrow) pointing down?

You can just hit alt+F12 to open the debug menu, go to database and hit reload (while in the space center scene, not in the VAB or any flight scene) and it will reload the game database including any changed configs, models, or textures. So you don't need to relaunch KSP every time. Also a screenshot of the "Hierarchy" panel from unity might help.

dockingNode should be pointing +Z (the blue arrow, not the green one) - that's probably why it isn't snapping

You might find "Eyes turned Skyward" of interest - there was an ongoing KSP project working on replicating a lot of its "What if" designs, but its been inactive for a month or so. Check it out here: http://forum.kerbalspaceprogram.com/threads/81756-Eyes-Turned-Skywards-UPDATE-now-with-Signup-Sheet And the original thread on Alternate History: http://www.alternatehistory.com/discussion/showthread.php?t=208954 And the wiki with links to technical details about all the vehicles and such: http://wiki.alternatehistory.com/doku.php/timelines/eyes_turned_skywards

Booster probably isn't the best word, I just tweaked its flavor text for future releases.

Alright then, a job well done by ISRO there. A pretty handsome rocket coming off the pad to boot. 10/10

The next thing above your chute should probably be the blastguard from the Escape tower - that can be a decoupler and used to separate the tower after its been fired or is ready to be jettisoned. Then your parachute cap can just be a cap and be hidden via the parcachute module when activated.

Hmm, I just loaded it up here and the Freyja IVA is working properly. It's the only one with a custom IVA for now. Make sure you have it installed properly in GameData/Novapunch2/Spaces/FreyjaInternals I also noticed a small issue with the pre-made craft - they need to be loaded into the VAB before being sent to the launchpad, because their save format doesn't have the new "size" data that determines if the pad is big enough to launch it (in career mode) - but the check is being made for the data even in Sandbox mode where the size is unlimited. I'll have to resave them for next time, but you can do that too for any ships you made, then you'll be able to launch them directly from the pad without going through the VAB.

Okay I managed to get all of those little issues fixed, and NP 2.08 is available on kerbalstuff now. Uploading to the dropbox mirror, and when that is done I will update the 1st post.

I could see some issues, if the bigger parts make you pass the mass limit in the 1st tier, or the size limits. Though I tended to leave the longer, bigger pieces1 tier higher than the 1st parts of any size, so I may have accidentally made it work. If people can report playtesting results, that would be cool. It seems that only that one engine has the TGA issue, and if you reload the database from alt+F12 it loads right. However even have saving the icons with an alpha channel they still dark, so I'll have to investigate further, no release tonight. Luckily, no major issues outstanding.

Yeah looks like those 2 icons got saved without an alpha channel, which breaks them. The Bearcat tri-nozzle engine has a broken texture too, I think its a .tga issue. I'll convert the struts to be clones of the stock strut (again) then tune them up, should be an easy fix. Anything else anyone has noticed? Hopefully will drop a new version with the tweaks late tonight/early tomorrow.

Is that example a mockup, or a working pack? All the download links point to FAR v14.4 rather than individual mods Also, a "Mod List" would be a more accurate name for this feature, its a curated list of what to download, rather than a unified, single pack with compatibility tweaks meant to work together as a unit. Does it let you specify a specific version of a mod? Perhaps only an older version works with another mod, or perhaps there's a special version with compatibility built in.

Boy, replacing the AJ-26 with another Russian engine seems... unwise. It's going to seriously hamper their competitiveness for government contracts on Antares, and that's ignoring the threats of engine sales being halted in another Putin.... episode? They're currently bidding on a new NASA cargo contract right now, being awarded in April. Common sense would indicate they would be at a disadvantage there now. But I guess government aren''t really known for that, so we'll see.