FireStormOOO

I'm not sure if the vessel class works inside of the VAB/SPH, but that has a property called rootPart which might be what you need?

*Everything* related to the function of the part is in the part.cfg to my knowledge. Some of the effects have to be set up in unity, but not the resource system. What you described should work. I'd go test it myself, but I FUBARed my KSP install. Post up the full cfg inside a code tag? EDIT: You know, on second thought, I give 90% odds that you didn't change the 'name' field of your new part, which makes it so the game can't tell the two apart when loading a saved ship. In your case, you MP engine would revert to a LFO engine on the launchpad. I've had it happen to me before with part rescales. That name field always has to be unique across the entire install.

There's breakingForce and breakingTorque that everyone seems to know about. There may also be a way to set the dampening and spring constants from the cfgs or definitely via plugin(I'm working on one such now).

Maybe you could modify the resource transfer type for that part only to isolate it from the rest of the ship fuel wise and then drain the fuel out however you please. As long as it's empty and fuel can't get back in, all is well. I looked and it seems really easy to add a resource to a part, but nye impossible to get rid of them. It seems clear that you aren't supposed to be able to remove them at flight-time, though if there's a will there's a way. EDIT: Part.SetResource(ConfigNode node) looks promising; if I understand how that system works, you should be able to change at flight-time anything that can be set via a cfg file?

Looking awesome and definitely worth waiting for. IRL takes precedence, and besides, there's *always* something when you're coding Anyways, if you're having trouble cramming all the functionality onto the part at one time, you could make it so that there is one partModule that makes the tank "Convertable" and have that be the only thing added in the part.cfg. You could then make any other changes to the part at convert time, such as removing the ability to carry fuel and oxidizer, changing crew capacity, etc. For example, maybe the "Convertable" part module could add a "MidConversion" partModule then remove itself, so you no longer had the option to start the conversion, but now had the conversion underway text.

Very nice, this should take care of everything plus some. Also makes me wonder about adding emissive textures to parts programmaticly in conjunction with deadly reentry... but one thing at a time. TY.

Oh I'm going to love this. Don't get me wrong, that existing throttle steering plugin has been a godsend, but this... *drools slightly*

You have to make the DM resource have non-zero density, otherwise any amount of the resource still has no mass, and can't work in a reaction engine.

I got some additonal work done last night and this morning. I now have the crudely textured parts in unity. As a first project, my philosophy is something along the lines of "make something useful; it doesn't have to be perfect". With that in mind, the textures are very basic, the models just on par with the stock pieces, and I haven't done the animation for the cargo bay, but I want to get these parts in game sooner rather than later. Once I make the part configs, I'll do a alpha release, including the original models and textures as well as the KSP usable parts. Take a gander at the parts in unity with the KSP shaders applied: I should have stuff out later today, pending no further problems, workflow or IRL(#BlackForestFire is getting mighty close). Looking to release under one of the more permissive Creative Commons licenses.

Save for a distinct lack of a deceleration burn kinda ruining that video for me, it was cool. I'm definitely interested in this, and would love to see an XCom style drop-ship or Halo's Pelican in game. I'm not entirely clear what you're stuck on from your post, but I think I can help; it's a fairly straightforward problem before you add in pivoting engines and thrust vectoring. I think it just boils down to solving a system of (linear?) equations with a throttle value for each engine, multiplied along its thrust transform. I believe you describe a subset of this problem here, just for bigger engines: http://forum.kerbalspaceprogram.com/showthread.php/28044-WIP-Analytical-RCS-thrust-balancing

I think if you wanted an engine with "no propellants" though, you'd have to write your own non-reactive engine class.

Think about it this way: the engine class models reactive engines. Period. It takes an specific impulse value, and a thrust value, and asks "how much mass do I need to move to produce this thrust". Yours is not a reactive engine in the sense that it doesn't need reaction mass. It is an easy fix/workaround though. Just add a resource called dark matter that has a non-zero density, make your engine run purely on that, and add an alternator or generator that produces it. That provides your reaction mass, still without requiring fuel tanks.

I haven't given up on this, but it's tedious beyond words to reload KSP every time I make a tweak. I need to figure out how to add a debug GUI so I can tweak the joints without a reload. I also need to make it so this works on the whole ship rather than as a part module. Nothing new or complicated there. I'll update on progress sometime later; I'm modeling some simple parts at the same time, so it's slow going.

Hi, I'm trying to figure out how I'd animate the cargo doors on a part I'm making. I have 5 separate segments, the main part, and 2 door sections on mirrored on either side. The first section needs to slide into the second, and simultaneously the second section needs to slide into the main hull. I have sketchup, blender, and unity at my disposal. Can someone either link me a tutorial, or give a quick and dirty KSP tailored walk-through?

I'll make whatever people need/want for their space-planes. This stuff is really easy to mock up in Sketchup, then I can just export as Collada into blender to finish them up(or should be able to once I make heads or tails of blender). I'm planning on reusing the MK3 textures for these sections, so it'll just me a matter of figuring out the UV mappings part I think. I'll start keeping track of section requests in the OP. I'm currently planning for Mk5 to Mk3 compatibility, but I'll add stuff that people request. If I did a MK5 cockpit, what would you want the other end to be? Would you rather the tail section end in Mk2 or Mk1? Is there an interest in other types of cargo bays, such as a bomb bay style one, or front/rear cargo doors?

I've imported into blender, and that already went a long way towards making it look smoother. Unfortunately I have next to no clue what I'm doing in any proper 3D modeling program; I only get along with sketchup because I have some formal CAD training. I've figured out some stuff in blender, but I still can't for the life of me determine how to pan the camera

Here's a 3D-ifyed version of the slide in cargo section. Also connected to an adapter, with a Mk3 section in front: The adapter is already quite large compared to the vanilla adapters, but I'm afraid I may have to make it even longer for the segments to look streamlined. I'm fairly happy with how the cargo section looks so far... Especially as I've been using sketchup for all of 3 hours

You're right. Apparently puush is down. Give me a moment and I'll re-upload.

Need feedback and taking requests! Fuselage section to for space-planes carrying medium (2.5m) cargo to orbit. I'm modeling a parts pack that will allow space-planes to carry 2.5m sections + radial attach goodies into orbit, while being considerably more manageable in size that TT's Mk4 sections. I need to know what types of segments people want me to do, and need feedback on existing ideas. I have the core parts in a usable state, and am working on configs for them now. I'm making my modeling work available under a Creative Commons Share Alike license with download here. No part configs in that download, but it includes the work in .dae as well as KSP's .mu format. Current and planned sections: In white we have the Mk3 fusalage for size reference, Behind it in tan is the Mk3-5 long adapter, The dark grey section is the cargo bay, with the green parts beside it being bay doors; those doors will be able to retract into the lower cargo fuselage in order to allow cargo release; The blue section is a cargo bulkhead, which will contain the attach node for your cargo, as well as probably some batteries and/or a fuel cell. In the background you can see a flat cross section showing my two original concepts for the Mk5. I ended up going with the thinner doors shown on the right. The red circle is exactly 2.5m diameter, representing your cargo, and the outside width of the fuselage is just under 5m. Planned, need feedback on idea Command section of some sort; need to know just how big and bulky people want it, and what cross section they want the nose to terminate in. Also taking thoughts on balance. Shorter adapter, likely half the length of the tan one. Won't look as streamlined, but will also be more compact. Need to know what goodies people want crammed in the adapter sections. Tail section, terminating in either Mk2 or Mk1, and allowing a raised tail section above your engines' cone of death. Concepts Bomb bay doors, Front or rear cargo doors, Fuel and rocket fuel sections, taking suggestions! Post your two cents and let me know what you want to see pursued. Also if you'd rather see this balanced against stock parts, or TV Aerospace. -FireStorm

Any idea how one might do that? I don't think it's one of the parameters on the joint. What bothers me most is the oscillations when using an autopilot mod like mechjeb with a large rocket; gets nasty real quick, and 2/3 of the rocket ends up as space tape. I did find a dampening parameter that I can modify, and it did seem to help. There's still the issue where rockets aren't "stiff" enough, so what I'm trying to do is make it so that they can handle the same amount of load, but deform much less before breaking; it's proved to be very finicky.

Alright, I ripped the model of the FL-400 fuel tank out of the MU format and it appears the scale is 1 unit = 1.25 meters. That's still not enough to account for the problems I'm having. Forces are all in kN? And pressure is then 1 unit force / 1 square unit distance, or .640 kPa?

Oddly enough, I had a similar problem with crashing on scene changes in .19.1, but it's considerably improved in the current version; in fact, I haven't crashed yet. How much memory are you running on your system? One of my tricks to get more mods to run and get faster loads was just to remove any parts I didn't feel attached to, such as fairings, redundant parts, etc. Sounds like your problem is a bit worse than that though. I've currently gotten the following running flawlessly in 20.2: mechjeb 2, HOME, NovaPunch, ampYear, Crew Manifest, Ferram Aerospace research, Kerbal attachment system, KSPX, RLA electric engines, Part Search, subassembly loader w/ patch, tt modular wheels, TT mk3 expansion, crew cabin, assorted misc parts from my old install still in the parts folder Personally, I'd start looking very closely at the debug console as you load and trying to figure out what's throwing errors and exceptions. Take everything out and add stuff back one by one. It's likely only a couple plugins causing the issue.

I'm trying to write a plugin that modifies physics to make rockets less wobbly. I was able to successfully replace the default joint with one of my own creation, but the behavior is... off. I believe the issue is one of scale. I'm currently working under the assumption that: 1 unit of mass == 1 metric tonne 1 unit distance == 1 meter But that doesn't appear to be working. Is that incorrect, or do I have an issue elsewhere?

And never mind that, missed the other 40 pages of thread... I'd be willing to help if it's needed.

I've been playing KSP for a long time, and lurking about both on the forums and with mod development. I recently decided start working on my first releasable plugin, and the following question came to mind: How many people (if any) actually like Unity's (and by extension KSP's) message system and how many would prefer it stuck to Events and Delegates like a normal C# program? Personally, the message system drives me up a wall. Would people want the devs to expose Events for key occurrences such as OnFlightStart and OnPartDestroyed? Are some people unfamiliar with Events and more comfortable with messages?