Bit Fiddler

so the author does not have a ":for[ ]", but his mod does have a "thingamajig.dll", I can't use ":after[thingamajig]"?

would it be possible to add "Connected living space" compatibility to this mod? what I mean is if I scale a stack part the tweak scale code can look at the diameter of the top and bottom nodes and if they are over the minimum, (1m?) then set that node as passible for CLS.

is it possible to make the procedural parts be "connected living space" compatible? I know you can just add a MM patch to say all the parts have the CLS module, but what I had in mind was do it dynamically in game based on the diameter of the part. so basically take the diameter of the part at the top node and set that node as passible if it is over say 1m or what ever. then do the same for the bottom node. and then use the average diameter of the part or some other more complex formula for surface passible etc.

yes needs FTT works as he has the :For[ ] ... I was just talking in general terms as I could not find one nested like that that did not have a .dll or some .cfg with a :for[ ] but thanks for the info on nested directories. saves me testing patch files.

I think we may both be asking the question... as in "does that work with subdirectories?" if that is the case sorry for the confusion. as I do not know the answer, I was hoping someone here did. I have never seen it used that way before, so that is why I posted the FTT as an example, as it fit the model of a parts only mod nested in a subdirectory. I guess the only real way to figure it out is to just write some test patches and see what happens. I will have to try this out when I have some time.

and this support complex directories like in the FTT example? because for instance I may have all the USI mods installed except FTT and in this case the "Umbraspaceindustries" folder will exist, but not the sub folder "ftt"

ah I see. I figured this pre-cooler part was indeed a real part used in real aircraft.

yes... thanks. iam using FAR so basically at launch it will be mostly the same, then as speeds go up and the air is hotter I loose thrust. so with this in mind have you, or can we, modify the "precooler" or other parts in some way to help with this?

@blowfish Did I miss something? in you previous post.. this implied to me that if I supply a folder name like so: :Needs[UmbraSpaceIndustries\FTT] that it would require that mod to be installed. if this is not what you meant by #2 in your list, what did you mean? right, exactly what I just said. and this brings me back to the original question. Where does this :For[ ] get defined. it would be in the original mod makers hands to do this yes? as it would need to be in the directory where the original parts etc. reside so MM knows "this directory belongs to a mod with some name"? And if I use :For[ ] in a patch I make later the patch will become "attached" to the original mod as far as the order of processing is concerned? so in a mod that is parts only,and there are no MM patches made by the author to include a :For [ ]. I cant then use the :Needs[ ], or :After[ ], etc. so in the case of a mod with no .dll and no MM patches created by the author, how do I tell MM that it needs to be installed after this mod? I assume with item 2 on your list.. a directory name. thus the question for FTT example that had a compound directory name, does it work?

I am sure I read somewhere that I can change a setting for CLS that will give me tweakables for every part in the SPH/VAB to let me decide at construction time what is passable and what Is not. Did I dream this, or am I just not able to find this again? I see the tweak buttons on some parts but not on others. Was this not supposed to be on "every" part? or does it still need some sort of a module on it before this works?

just a note about EC usage... if I have TAC life support installed it is already setup to require EC per Kerbal. then when this mod is installed that EC usage goes into over drive. you could make a Patch that detects if TAC is installed, and removes the EC per Kerbal, to avoid this double hit to the EC required for a kerbal's life support.

would this not be possible to do in the VAB or SPH so we can see what is going on at design time?

I understand this is a nebulous question but here it goes. Does this increase or decrease the performance of the engines? yes, I know, many factors are involved. I am just looking for an overall idea. as in, if I install this will all my aircraft suddenly stop working?

ok so the mod in question is FTT by RoverDude. it does not have a .dll as far as I can tell so the name must come from the directory or a :FOR[ ] ? so the directory would be :Needs[UmbraSpaceIndustries\FTT] ? or with option 3 where is this :for[ ] defined? I was under the impression that :For[ ] meant this mm patch should be run right after the mod... differentiated from :after[ ] which was any time after that mod is done, or :needs[ ] which may be done before or after just so long as the mod is installed. is this not true?

how can I find the proper "name" for :needs[ ] my understanding is that if a mod has a .dll the name of that .dll is used here. however I am also led to believe that if a mod does not have a .dll the mod author can somehow still give MM a "name" so others can use :For[ ] or :After[ ] etc. the question is how can I find this name? how and where is that defined?

all good things to try... However the whole idea for this was to test how accurate MJ could land my colony bits on the mun. I was hoping it would be accurate enough to get them to land within 10m or so from each other to avoid long overland treks to get them all to the wanted destination. may just have to go overboard on the Delta-v and for the final landing use TCA to hover them the last few Km or what ever is needed to get them all in the correct spot. but as it stands now i am looking at making a rover to move all the colony bits around any way for the assembly process... maybe just have to move them further than planned. on a side note... i did switch out the monopropellant engines for LFO and it landed fine. the lander had to be modified quite a bit to accommodate this change so not sure if the engine choice was to blame or not. however this brought up a new problem. not tied to MJ i do not think, as i have seen it while not using time warp from the landing process... but when time warp is engaged the system glitches, and i do not just compress time but the lander actually warps about 20 km, thus i am now far beyond my planned landing spot. but this happened even when i manually hit the time warp buttons, not just when MJ did the auto warp. so ya, new round of head scratching.

cant speak for the real reasons, but i assume this was the exact reason. i have made some solar powered hover craft like this before and thought it was a bit OP. so even if it was possible i stopped doing it, and make sure all my hovers use reactors, or some sort of fuel cell setup, for power any way. not sure what this nerf will mean for them however, as i have not tried them out recently

i had 1500 delta-v and it was manned so no com signal to worry about. at impact the throttle was only at half and the fuel tank still half full. i was assuming it was going to go full power for the last few hundred feet to slow down but it just coasted in on half power until impact. like i said however that craft is scrapped and designing a new lander so i will just look at this again later after the new one is built. my assumption is it was the engines i used. MJ probably did not know how to compute their thrust correctly or something along these lines. they are monopropellant engines if this makes any difference. does MJ assume they are RCS and will not use them as a main? any way no worried i will test again with the new lander some other day.

I have a similar problem on another part. I assume it is KJR any way. I have a mod installed "Lynx Rover" it has some "bendable" trailer hitch things to articulate longer rovers etc. and they do not bend. I am assuming this is due to KJR. Would it be possible to have a tweakable in the editor to tell KJR to ignore a part, so it would allow the bending parts? and make any future things like this be easier to deal with?

mun landing, TWR 2+. select point on map in a circular orbit at 100K. turn on auto pilot, all seems to be going well up until impact at over 100m/s I said 100km/s before but that was a typo. oh well I have deleted that craft now any way and have gone back to the drawing board in my design. so I will see what happens with the next one.

ah I see.. so maybe I am using a USI reactor it just has the NFE pach on it. any way I am not too worried about which plugin it is using. I will look into this more and see what I want to do? maybe use as is and do something like Kos to automate it if possible. or maybe switch all NFE reactors over to USI plugin or what ever. I will just have to look at it all and weigh the pros and cons for the 2 systems and see where I want to go. thanks for all the info.

I have USI installed, as well as Near future. is this problematic? do they not play well? the reactor in question on this craft I am currently using is one from Near Future, however I have not tried the USI reactor like this to see if it will auto throttle.

on the landing guidance window I see some text "Mode SafeDecentSpeedPolicy (False)" what is this telling me? is this the reason I keep "landing" at 100km/s?

oh yes this one... lol I guess I could have just posted it as well. but thanks.

is this intentional or is there a possibility of getting this added in? as it is I am constantly fiddling with my reactors as I orbit to ensure that I am not burning any more fuel than is needed. even if this was another part or an "upgrade" bit to the reactors to give them a "reactor control computer" that would be great. maybe have several levels of upgrade to give more or better types of reactor automation. but really just the ability to get them to throttle up and down to maintain stable power would be great.