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;

I've mostly been reading http://wiki.kerbalspaceprogram.com/wiki/Community_API_Documentation, which is linked from the wiki's main page. Other than that, I've been looking at the source code for other plugins. It's just plain difficult to find any good information.

I've been thinking about how to control the driver, and I think I like the idea of changing the amount of power discharged the best. I would display in some info fields a few parameters: * Resistance of the rails (something that would be different for higher-tech mass drivers and at different temperatures) * Efficiency of the driver (correlated with resistance, affects the amount of force put into the payload) * Temperature of the rails (lower would reduce resistance, near absolute-zero they would be superconductive -- you would achieve this by attaching the liquid helium tanks from the interstellar mod) * m/s^2 acceleration that will be applied to the payload * estimated m/s delta-v that the payload will experience and a button to increase and a button to decrease the amount of power the driver will consume. Perhaps a set of four, with which you can increase by +/- 1 Megajoule and +/1 100 Kilojoules (1000 and 100 electric charge units respectively) What do you think? Anything you would change?

"this.part.vessel" gives you access to the active craft. Specifically, it gives you access to the vessel that the part is attached to, where "the part" is the part that your module code is attached to.

I think that rescaling would be convenient, but we actually need different part models for each different size, because the docking ports look different for the different sizes. The docking port module requires a size specification, and will only allow docking ports of that size to dock together. So, if you are using a driver that's sized for 1.25m parts, then you won't be able to dock a .625m docking port to it, nor a 2.5m docking port. Using a common base model, rescaling it, and slapping a different docking port on it would be fine. Also, would you mind trimming down the large base? Now that I've changed it to consume ElectricCharge, I think it will make sense to use the driver rails as a part that attaches to the end of a stack of batteries. I think the base would should be about 1/3 or 1/4 its current height. Imagine a stack of ten round 2.5m batteries with the mass driver rail attached to the end. Something like this: https://drive.google.com/file/d/0B0a7PNLYAdzQbGRYT0FxNU5qLVU/edit?usp=sharing Thanks again so much for your help with the modeling!

If you're calling GameObject.Find(...), then you're calling a static method, and that method doesn't know anything about the part you're looking at. For a method to have "scope" in the sense that you're using the term, then you need to call a method that's on that object, or call a method that takes the object you're looking at as a parameter. Perhaps you mean to be working with this.part? That's the part that the module you're writing is attached to at runtime.

That's how I intend it to work -- can only reattach parts using docking ports. It's more realistic (typically mass driver payloads are loaded into a special container which completes the circuit between the rails) and it's much simpler. lo-fi, on that topic, can we include the existing docking port models and textures in the mass driver rail model, to make it obvious that they are meant to connect? Ultimately, I would like to have a version of the rails for each version of the stock docking ports.

I've updated the plugin, here are a few changes: * Consumes ElectricCharge (10,000 units currently) or Megajoules (when present), so this no longer requires the Interstellar plugin to work, but will play nicely with it. * Applies a recoil force to vessels which are not landed -- when flying or in space, the mass driver will apply half of its force to the payload, and half of its force to the mass driver itself. Now you can use it as a propulsion system! However, note that it very well may just completely destroy your ship. Attach it to a strong part, and use it only on very large vessels!

Ah interesting, yeah, I hadn't looked at the near future pack yet, but it looks like exactly what we're looking for. I'm planning at the moment to change the resources consumed from megajoules to electric charge, and to opportunistically consume megajoules when they're available. Then, if you really wanted to, you could actually set up 10,000 units of electric charge instead of 10 megajoules and be able to use the mass driver without the interstellar pack. Activating the driver would consume megajoules if they were present, but would fall back to electric charge for whatever megajoules didn't supply. I've updated the code to apply a recoil force when the ship is not landed. Specifically, I calculate the total amount of force that will be applied by the mass driver, then * if the vessel is landed, apply all of the force to the part connected to the mass driver, or * if the vessel is not landed, apply half of the force to the part connected to the mass driver, and half of the force in the opposite direction to the mass driver part itself. lo-fi, I'm getting a warning when the mass driver part is loaded, "[Warning]: [Docking Node Module]: WARNING - No node transform found with name dockingNode". Does that indicate that there is an element missing in the part model that would indicate where the docking port node should be? I think this is preventing docking ports from attaching to the mass driver.

Ah, I see what you mean now. Yes, I've been writing code in C# to control the properties and actions of the parts, applying forces et al. I thought you meant some kind of animation scripting. Absolutely, can you point me to where you're working on the wheels? Is there a different forum thread for that?

Hey Frizzank, those look great! I'm really excited, and glad that it looks like lo-fi is taking a crack at incorporating some of your models.