PeterDolan

Read up on git branches -- what you described is a dev vs. stable branch: http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging You can create a branch and upload it to the existing git repo. We will both be able to see it and work with it, and when it's ready we can easily merge it into the main branch.

Now that things are generally working correctly, and we have a very nice super awesome model ( ), I'll make some posts around pleading for texturing help.

That looks great, lo-fi! Looking forward to trying it out!

Thanks SpiritPlumber! Do you have any experience working with the models directly? I'd be happy to add you to the github project so that you can collaborate with lo-fi. If yeah, just let me know what your github username is. lo-fi, I noticed that the docking port models all have an empty node in the model that's called "dockingNode", and I think that's necessary for the docking port module to correctly tie two docking ports together. I think this is a little silly, as it doesn't seem reasonable for the docking module to do deep inspection of the model elements themselves, but the game does that anyway when it looks for collision meshes and etc. I tried updating the model myself with blender, but when I try exporting it as a .mu file, I can't get the textures / materials to work right. When you get a chance, could you look into this for the existing model? Once we have that, and we have the geometry of the part finalized (chopping the base down to size), then we can start using the model in more persistent games and start doing game balance work on the amount of electric charge consumed, and the power of the ejection force. Thanks everyone for all your help testing and developing!

Good news: I fixed the docking port problem. I've updated the code and plugin in Github, go ahead and re-download it from there. I'll update the direct download link too soon. Here's what has changed: * Fixed the docking port problem. Now, if you decouple, and reconnect the part, the mass driver will be able to find and launch its payload. * Changed the discharge power setting to a tweakable, so that you can set its power to any % of its maximum power. I fixed the docking port issue by removing any dependency of the mass driver on the docking port. So, instead of using the docking port's attachment node, which doesn't seem to be properly populated by the docking module, I'm directly inspecting the mass driver's children and parent parts. When a ship is repacked after docking, the child and parent parts are properly populated. This is a little wonky though, as the way I'm figuring out which part is the mass driver's payload is by calculating the vector between the mass driver part and each of its children and its parent. Then, I compute the dot product of the mass driver's normalized direction vector, and the normalized direction vector to its parent and each of its children. Whichever dot product comes out very close to 1 is in the path of the mass driver, and is considered the driver's payload. One somewhat nice upside of this is that now the mass driver is now completely independent of any other modules. Anything that can attach to the mass driver (precisely where its top attachment node is) can be fired by the mass driver.

Good and bad news. Thanks to spiritplumber's report, I investigated the docking question more closely, and I think we've found a bug in the core game's docking node module. Try this: set up a ship with a pair of docking nodes connected to each-other in the middle. Undock the two docking nodes by right-clicking on node A and selecting Decouple. Re-dock the nodes. Then, right-click on node A, and notice that you can't actually undock from that part a second time. This is correlated with a message in the debug menu about a part joint being invalid. Ultimately, this means that docking port A is unaware of being connected to a part at its top node. I'll try to figure out a workaround for this, but it's a bit tricky, and I'm disappointed that the core docking node module won't work for us in this way.

Yes. All of that. Another thing to think about is plasma rails. There's a form of advanced mass drivers that do not have physical rails. Instead, they ionize the space where a rail would be and run sufficient current down that pathway to create a plasma "rail", which is an excellent conductor of electricity. This costs a lot more in power, but the plasma rails do not degrade over time. Metal or other physical rails are damaged each time they are fired, which limits the lifespan of real mass drivers. I think it would be totally rad if we could animate a virtual plasma rail that's generated during the countdown to firing. Then, we could create advanced plasma-based mass drivers that are later in the tech tree, and add a "wear" parameter to those that still use physical rails. I imagine that the driver would "wear out" by reducing its efficiency, and that a kerbal on EVA could repair it. This would make it more challenging to set up remote bases that have no kerbals present, unless you had reached a higher tech level. What do you think?

That's super helpful, thanks Spiritplumber. I think this is caused by the code not properly detecting parts that are connected to the docking attachment point, while they do detect those that are connected to the "top" attachment point. I'll try to sort this out soon. Thanks!

Oh yeah, it should definitely be in utility. Feel free to go crazy with updates to Github, make parts of different sizes, move them around, etc., anything you like! Just be sure to sync frequently so that we don't run into too many merge conflicts.

What do you think about following the TAC convention of "no power for more than two hours == kerbal death," with "no power for more than X hours == greenhouse death"? I imagine that the plants would die if they were left with insufficient light for more than a week, perhaps. This would not really come into play for manned vessels (the kerbals would die first), but it would be important for unmanned vessels, such as a forward operating base or somesuch.

In reading another thread, I found the solution to this: http://forum.kerbalspaceprogram.com/threads/79603-0-2-35-CELSS-Greenhouse-%28TAC-Life-Support-Add-On-Version-0-1-beta%29?p=1154288&viewfull=1#post1154288 Using module manager, you can add modules to existing parts. In that thread, look at the [spoiler: Config]

I think you may be able to look at wheel.forwardFriction, and looking at the WheelFrictionCurve to determine where on the curve the current friction lies. Then, you are effectively determining "is slipping", and could reduce torque on that wheel accordingly. I'm curious if it's possible to apply steering to align the vessel with the surface normal and direction of travel (align the vessel to be "flat" on the ground and pointing in the direction of travel). That would help a lot for those times when you do a jump off a ridge.

I think this is super cool. Would you be open to adding traction and stability control? I think it would be a lot of fun if each wheel could individually adjust its power to avoid slipping (launch control?), or at least have an anti-lock braking system If you're open to that, I'd be happy to write some of the code! I think it would make sense to allow the user to enable / disable these systems.

I've updated the plugin. New features: * Can adjust the power of the driver in increments of 1Mj * Rail temperature affects the conductivity, which affects the force applied to the payload. You'll do best to wait until you're in Kerbin's shadow. * Estimated payload acceleration and delta-V readouts in the part menu * Updated model to lo-fi's latest copy, now a 1.25m part. * Removed electric charge resource from the mass driver itself. Attach batteries yourself, please. * Now consumes electric charge primarily, and will consume megajoules from the interstellar pack when they're available. So, you can use it without interstellar, just attach a bunch of batteries and some solar panels.

Oh yeah, it's definitely not you! I figured out the KSPField annotations from the interstellar mod, and I'm still having some trouble with them... Hah! Looking again at your and interstellar's code, I figured out the problem: the fields which are annotated with [KSPField] MUST be public fields. This is so that the game can access and set them for you. So, where I have: [KSPField(isPersistant = false)] float Efficiency = 0.8f; it should actually be [KSPField(isPersistant = false)] public float Efficiency = 0.8f;