a__gun

Noooo active vessel targeting DEFINATELY has a place

I understand both points of view on the seismic/impactor sensor. I think it would be good to maintain the original part, but add in the impactor functionality as an unlockable upgrade. This was you get the original stock science early on and still get to use the awesome impactor idea. Thoughts?

I would guess that there is a connection that is dependant on the active vessel somewhere. Ensure that your Mun satellites have an uplink even when they are not active (Each of them need a dish pointing at Kerbin and each of your Kerbin sats need a dish at the Mun)

I have done that already. Keeping the maxTemp constant is the only way to accurately test the effect of the reflective stat really

Done more testing and found my earlier conclusions were wrong...woops. The Animation2Value modules are working - I can scale the maxTemp value according to the animation absolutely fine. It does not, however, seem to work with on the reflective value. I have tried setting reflective to change ridiculously based on open state (0.9 when closed and 0 when open) whilst maintaining the same maxTemp in both states to emphasise any effect, but the result is that there isn't one; the part accumulates heat at the same rate in both states, and explodes at the same point. I'm about to try the same test with the stock shielded port and will let you know my findings. EDIT: Yup same with the stock 1.25m shielded clamp-o-tron. Same rate of heating regardless of shield position. Would seem rate of reflection isn't something that can be updated on the fly

I think Ratzap meant while the Fusebox is minimised, not the toolbar itself. Could be totally wrong though...

I recently found I was getting exceptions and errors from a variety of mods (Many of the ones on your list), turned out it was none of them, just a corrupted .craft file

Cool cool well if that turns out to be the case I'll have to bug him/her lol. Cheers

Thanks but I know that's not survivable. I'm just putting myself into a descent where I know I will hit the max temp, so that I can compare at which point I burn up when the shield is open and closed. There should be a difference but it doesn;t seem to be behaving as it should.

Is the shielded docking port meant to be any more/less aerodynamic when it is opened/closed? My testing suggests not.... How does it not work with KW? Seems fine to me.

On a hunch just tried a very similar test but with the stock 1.25m shielded docking port and the results were the same: shield closed it burns up at approximately 1450C and shield closed it burns up only slightly below this. I'm either doing something very wrong or this is working as it should. EDIT: Scratch that, when the stock port is open it gets to 1400C then imediately shoots up to ~1700C and burns

Tried it, done some pretty thorough testing and...can't make it work. I have a simple craft in a 500x20km orbit around Kerbin with the shield at one end and MechJeb keeping the shield in the right place. I have logged the shield temperature at various heights whilst it is open and closed and the results are virtually identical. When closed, the shield detonates at ~1450C (Which is the lower value in the MM cfg) but when open the shield detonates at <1450C (There is no maxtemp lower than this specified anywhere). I have tried inverting the key values as you suggested but that doesn't seem to make a difference. I also noticed in the part cfg for the shield that the animationName = deployShield rather than dockingring, and changed the field in the ModuleAnimation2Value accordingly, but this also seemed to make no difference. I am beginning to think there must be something strange about the setup of the part animation that doesn't conform to the standards DR assumes (On a side note I am having similar troubles trying to integrate TweakableEverything functionality) Any more ideas..? EDIT: Oh and the MM patch is definately being applied becuase the shield says it has a heatshield module in the editor.

I'm having trouble adding tweakable functionality to a custom docking port. I've downloaded the shielded senior docking port found here and want to make it so I can start with it open or closed, as you have done with the stock port. I have created a ModuleManager config based on the one provided with this mod but it doesn't seem to be doing the trick. This is what I've got: node_stack_tdn = 0.0, 0.1160832, 0.0, 0.0, 1, 0.0, 2 @MODULE[ModuleTweakableDockingNode] { TDNnodeName = tdn deployAnimationControllerName = deployShield } I have checked the config file for the port and the animation is called deployShield, hence that change. The port is getting the other tweakable changes (this is handled by your MM config) but cannot be opened in the config. It is also having another node attached to the top (While closed) but it is unusable. Any help would be much appreciated

Thanks guys I'll try this tomorrow. It was the two different ModuleAnimation2Value's that was confusing me mainly, but I'm starting to think I'm just tired lol

Looking to add a DR heatshield to the shielded docking port on this page. Tried looking at the ModuleManager changes to the stock shielded port but couldn't figure out what was going on. Help..?

Loving the parts great work A request though, in the fully recoverable rocket video in the OP, the second piece of the rocket to drop uses the shielded docking port for reentry then flips around and uses its recessed engines to land. I think it would be awesome to have a part similar to the shielded docking port, but without the port, so that you could essentially have a set of doors covering the engine. That way, the stage reenters with the closed doors acting as a heatshield and then the doors open allowing the engine to fire. EDIT: Also, any chance of configuring it so the heatshield actually works with Deadly Reentry..?

OMG this looks so awesome!! Handy guide for licensing here

No problem I'm all for improving your own skills. That's why I wanted to do it myself as its been quite a while since I looked at coding.

I decided to have a look at your code to disable Jeb's suggestion and ended up doing a bit more. It should be totally possible for users to define any number of modules per item, and I have written some pseudocode to explain the way I would do it. Instead of having two seperate 'drawListItems' methods to handle items with either one or two modules, this one method can handle items with any number of modules. onWindow{ if file exists{ for (int i=0; i<items.length; i++){ //For every item in the list drawListItems(i); //Draw the Item and wether its true or not inc windowHeight; } } } drawListItems(i){ bool hasModule = false; int noMods = 1; //The number of modules linked to this item int nextItem = i+1; do{ bool longer = false; if (items(nextItem)==""){ //if the next item is blank it means more modules //are linked longer = true; noMods++; nextItem++; } }while (longer==true); if root selected{ foreach(part in ship){ for (int x = 0; x<noMods; x++){ //Check this part for every module if(part.module.contains(modules[i+x])){ hasModule = true; } } } } print(items[i], hasModule); } If you need any explanation of the code or help implementing it feel free to ask. Love the idea of this mod, keep up the good work **edit** I have made the changes to the source to implement this but I am nowhere near a compiler so it is untested. Anyone wanting to try it can find it here

I now have an extra item on my list...'MOAR BOOSTERS!!!' Whilst I appreciate the joke, how can I disable it?

Awesome 10-char

Any chance of folder icons, resizing and reordering to tide me over in the meantime?

Well thank you for the reply anyway and I hope you find the time and effort to continue at some point

There is one more feature i think would be good to implement in this, then I'd consider it complete. Currently the plugin checks the deployment altitude of all attached parachutes and slows time a certain height before each of these (Which is great). The only issue I have, which really is a very minor thing, is timing. With the current implementation of the plugin the delay between time slowing and parachute deployment grows as the vessel moves slower and slower, as it takes longer to fall from the safety height to the deployment height. I think it would be awesome (and quite simple) to calculate the margin based on the speed of the vessel, such that the delay was constant. Anyway even without that, great plugin, good work

Looks like you've made something new to me I'm sure you get loads of requests, but would you be able to make some models for the TAC Life Support mod? I like the mod but don't really like the models that come with it :/ If nothing else, could you make a set of your tapered boxes labelled with the life support resources (Food, water etc). Love your work and hope you continue