Bit Fiddler

while the ALCORE is indeed my go to lander. I still NEEEED the internals in all my cockpits. lol I try to play KSP in full IVA mode. and thus want these nice RPM/ASET internals in every part I use.... I know, big wish, but hey.

could the lights on the Mk1 crew cabin be moved a bit... there is a mod out there that adds a crew hatch to the top of the Mk1 cabin. however this puts the LED right on top of the hatch window. if the LEDs could be move to the sides, above the windows for instance this would be great. also not sure why this is happening but... my Mk1 pod has 2 small LEDs floating off to the left side of the part. I can post screen shots for both of these issues if you want.

for the glide slope value I would not make it a set number. let the user define the wanted slope based on a per use basis. just set a value on some UI control and it will use it. EDIT: oh I think I misread the post. you do not mean set it to 3 degrees, you mean just the units to display it in, no matter what the actual value is? in this case I would make it click to change so it can be cycled between degrees, ratio, percent (3°,1:20, 0.05) thus no matter what the user likes to see it is there.

my point is to use real world numbers of knots and nautical miles and feet etc.you need your craft to display these numbers, and it does not. so even If you have your WP displayed in nautical miles. your air speed is not in kts. and your VSI is not in f/s etc. so you will need to have a mod change all this to match the nautical miles of the WP manager mod. and all these mods would have to agree is it based on kerbin's geometry, or just a simple conversion of m/s to kts based on earth geometry etc. not saying one is better than the other. just saying if players change their frame of reference to Kerbin rather than Earth and realize the underlying math it all works out better. as trying to get all modders out there to agree on converting the metric values already used in KSP to another unit of measure will mean they all must either go with kerbin geometry or earth geometry. as if they ALL do not do it the same way all the math is ruined. this would be a cat herding exercise. so better to educate the players on how to do things with the tools at hand, rather than try to get all modders to agree to use Kerbin geometry for their kts and mach numbers.

well not to side track this topic but.. kerbin is not the same size as earth and thus kts, and NM are not the same here. you would have to get all the mods out there that use these "units" to convert them from the actual earth values to kerbin values, or the math will not work out. as one mod may display your speed in kts, but this is kts earth relative, not kerbin relative etc. but yes, I have worked with mission planning type of things for about 30 years now so I know what you are talking about with this. and have had this complaint that people making mods that use other units of measure like kts, mach etc. are just doing a conversion based on earth physics not making actual calculations based on kerbin. and since all the craft in KSP use the metrics you do not have this problem of tables to convert metrics to kts. since you are in metrics to begin with just go with it. otherwise you need a mod to convert your speed to kts, a mod to convert the way point distance to nm, and a mod to convert your VSI to fps. basically what you are asking is the exact opposite of the problem in china. you want a craft that is set up in metrics to convert all the data to kts, feet, etc. my point is rather than make all these changes, relearn the math in metrics and just use it, as that is what your craft is setup for and using here. The underlying math you need is just a ratio.. your runway is 10km away and you are at 3000m altitude. your ratio is 10/3 or 3.3 what you want to maintain is this ratio. so if your approach speed is 100m/s you get 10km/100m = or 100 seconds to landing, and you get a VSI of 3000m/100s or 30m/s. 100/30 = 3.3 thus the ratio is maintained. so now just fiddle throttle and pitch to maintain 100m/s airspeed and 30m/s VSI. so the math is all the same you just need to change your frame of reference.

on the topic of the missing crew portraits for parts with no "internals" there was a mod out there that looked at every part that has crew capacity, and if it did not have an internal would just use a generic "black square" for the backdrop, yet still show your kerbals in the list of crew on the bottom of the screen. I forget what it was called... but it was very handy for this. as for growth. rather than treating them as weeds, what about making your growth depend not on the total number of kerbals but rather create a new "stat" for your female kerbals "pregnant" and anytime they are in a crew that contains male kerbals well.... there is a chance this will become activated and then the growth happens. but keep this tied to the Kerbal not the craft so the Kerbal in question may move to a new craft, or even a new planet, and still have this counter ticking. basically, yes, just model reproduction as it exists in organic life forms. there are at least 2 mods out there... if I recall one was called "Kerbal stats" that were designed as a framework for this exact sort of thing. so mods had a central "skill or stats" data base to pull new things like this from.

another contract I am skeptical on taking. I am supposed to send a team to the island airfield and leave them there. if I have TAC installed they will all end up dead... what happens if I have them "near" the spots but in some sort of base type craft with life support?

is this not the same as speed in M/S and distance in meters? it is just different units of measure, but the math is all the same.

1) all of the Mk2 stuff you can find. Porkjet, Quiztech, Mk2 expansion etc. they all have very good parts for making VTOL. also the USI packs have some very good VTOL parts. if I recall, the exact packs are exploration, and the Freight transport packs. OPT Space plane pack has good parts for larger craft. 2) also, I use a lot of wings and such from the B9 procedural wing pack. as you can fine tune the wing and control surfaces to your exact needs. 3) and finally, firespitter, KAX, SXT, Airplanes plus, etc. these all have good general aircraft parts even a few specific to VTOL. basically any pack I can find that is "aircraft specific" I will install as they all have little gems in them you may otherwise miss. I just accidentally wiped my career game and lost all my VTOL example craft but I can rebuild some of them to show off some of the more interesting parts I have used.

can use a PID idea. as your angle to the target decreases you want to decrease the rate of change. can simply adjust the torque of the gyros for this. in very simple terms set your torque% to the angle between you and your target. so at 90deg. off, your torque will be at 90%, but when you reach 1degree off target, torque will be 1%. obviously this will not work as stated and I guess you probably know what a PID is, just including this brief description in case anybody did not know what I was talking about.

hmm must be some odd mod conflict or what ever. as I tested again and when thrust limit is set to less than 100%, the engine is still burning fuel at the same rate. will have to start from a clean install and see if I can figure out what is causing this.

you must have a processor installed like the "wide field" for instance. then point your telescope at a planet or moon, NOT THE SUN, and then take a picture. If you are zoomed in close enough it will return a science reward. if you watch the video linked in my previous post it shows this process, however no science is returned as I had taken this picture before. however, on a new picture it will indeed return science points.

ok so again... does limiting the thrust burn less fuel or just waste it? If ISP remains constant, and thrust is reduced, it would seem to be that fuel burn is also reduced. but unless I am misreading the data my engine seems to just waste the fuel when it is under thrust limit. as in it burns the same amount of fuel per second but the thrust is cut, so the fuel is wasted. this seems like a bad game mechanic, but so far it seems this is true.

ok making a "shuttle" launch system based on the Real World Shuttle. I assume T-SAS will balance all the liquid engines to keep the COT in line with the COM. but I have a few questions. what does limiting my liquid engines output do to my fuel efficiency? does the ISP remain the same and I just burn less fuel as I am making less thrust? secondly if the only engine active is the main engine under the external fuel tank, will T-SAS balance the thrust of this engine to provide stable flight with the control surfaces on the shuttle? as in limit the thrust to a value that the control surfaces can counteract. and lastly there is a typo/grammar error in the "AutoStage" tool tip 'falmouted" should be "has flamed out"

well as long as we are on the topic of GAP. I also had issues with the drop a Buoy. for some reason it would never recognize the "thing" I made as a valid buoy. basically all it needs is a barometer yes? well and the obvious, power etc. as for the glider I just made one with a cockpit and shoved a command chair on it just to complete the mission.

yes but "take command" is not updated to 1.2.1 and "walkabout" does not work for me either, it crashes every time I try to use it. and on top of this it is easier to spawn a rover, as walking the Kerbal all the way out to the runway end is even more painful. best solution is to remove the need for the seat. and then add a conditional that will add it back in if "Take Command" is installed. then when it is fixed the contract will require the seat.

a request... can you remove the requirement for the "first glider" contract to have a "command seat" it is too much of a pain in the ass to spawn a Kerbal in a rover and drive him off the runway. then make a glider that now needs a probe core because it cant launch "unmanned". then walk the Kerbal over and mount the command seat and begin the flight. after doing all this there is no reason to actually put a Kerbal in the seat. just fly the thing with the probe core. it is just too much hassle to do this contract as expected.

this may also explain my problem where no contract update after photo of the mun. as I run kopenicus and some planet packs. thus, if you do not handle that, the contract may not realize I have a photo of the mun...

on the topic of CO2... a green house will use O2 to produce CO2 (in the dark) and use CO2 to produce O2 (in the light). the ratio of this is on the positive side for O2. thus the net result is a greenhouse will produce more O2 than it consumes. so however you chose to model this if you can assume at least equal light dark cycle you will gain O2. so it all comes down to if you wish to realistically model the light dark cycle of the green house based on the orbit. or if you just fudge it and say it produces some O2 and call it quits. I guess it depends on how hardcore you want to mod to be. and while I like TAC as it makes KSP "Hard Kore" and it is one of my must have mods. I also think that there comes a point when trying to micromanage a greenhouse just detracts from the game. I would much rather have a closed system I can enable and then put it on rails and forget about it. basically if I must come back and be sure to turn parts off and on depending on the light conditions the fun is gone. this goes for all the parts that interact with TAC; fuel cells, Sabatier, purifiers, etc. I would rather if be fudged on the side of playability than try to make it 100% realistic. I want to be able to make a closed system that will support X kerbals for Y days. and not have to micromanage all the individual processors. all I care about is if I must "burn" water then how long will my water supply last. all the individual interactions from all the parts can just be tedious and get in the way. I would not expect a true closed loop however. I would always expect some "input" is needed. in most cases this would be water. food can be grown in a green house, and the greenhouse will make O2, while it will consume water. other parts will fit in this cycle, but the basic model here is I supply water to the craft and it will provide the kerbals with Food and Oxygen. the other bits to recycle waste water back to clean water can give you the "nutrients" for your hydroponics and extend the life of your water reservoir, or convert water to Hydrogen and oxygen for breathing and for fuel etc. but the net result is water = life, as there will always be a diminishing return on the complete cycle that will mean an over all loss of water. oh and obviously EC so "H2O + EC = Life" EDIT: oh and I can send you the spreadsheet I started to make for the TAC support. it is not a big deal and you would need to still add a lot of stuff to it, but if you wanted it as a starting point ill send it.

another good autopilot mod that is superb at landing aircraft and space planes etc. is Kramax Autopilot Continued. currently maintained by @linuxgurugamer I have used it quite extensively in my latest campaign along side this one for my VTOL needs. it will fly your plane in a very stable flight and near flawless landings. usually if the flight or landing is less than perfect it turns out to be a design flaw on my part. sure this does not fulfill your desire to make a mod, but it will give you the auto land you desire right now.

personally I have never used the cryo fuels and cryo engines etc. I have always had the mods installed but I have never used the parts yet. However as a rule I usually prefer more realism, but it can be taken too far and be come more hassle than it is worth. so my answer would be to make it as realistic as possible without having to reinvent the wheel. as in if you can fudge it and make it "believable" that is probably better than more realistic but requiring hours of coding. also, tedious micromanagement on the part of the player is no good. if your solution requires constant input from the player do not use it. what this means if I am forced to go back and revisit the craft every few hours/days what ever to be sure I power off a system or turn it back on that is no good. I need to be able to let a craft ride the rails for as long as it needs to and not have to worry about it when I load it up again. so if the solution is to have an active system that must be powered on and off constantly to balance the system that is no good. in cases like this the entropy ruins the game. it needs to be stable for as long as is needed. it can still burn EC or what ever to run a pump or something, it can still provide cooling by circulating the fuel into other parts or something like this. but just be sure there is not a need to micro manage the system. when I revisit the ship 10 years later as it passes the outer rim of the solar system and all the "catchup" is done the system needs to have a steady state result where I can calculate this part will consume xEC/second and I produce x+yEC/second so I will be fine. I hope you understand what I am saying here but if you need more input, I can try for specific examples. just as a quick example.. there are parts for TAC life support that use EC to covert water to oxygen and hydrogen, and another that will purify waste water back to usable water etc. but they can't all just be turned on at the same time and left in a "closed system" as you are constantly needed to power on and off each individual part to maintain the balance. this makes it necessary to over compensate so your kerbals do not all die while the ship is out on rails as it does background processing on them. a simplified system that can just tell you upfront give me this much power and I will do my job is better even if it is not as realistic. it still make the user think about their designs, understand the basic concept of the system, and engineer a solution without making the game tedious.

all of this is true but the Gemini capsule was how high off the ground? (150 feet?) and how high of the ground is the capsule in this video? also the ejection seat on the Gemini fired "upward" not "outward". this is a limitation of the part in KSP that can't be accounted for with this mod. and as for bottom eject; this is also true... however it does not change the fact that positive VSI was needed for safe ejection. if you want I can link you some airforce training videos that talk about this in detail but it is all just simple physics. on top of this the bottom eject of the F-104 was later abandon in favor of the traditional upward eject as the loss of VSI was unacceptable. the reality is that 99% of all ejection system, no matter the direction of ejection, must have a fair amount of positive VSI for safe ejection below something like 100m. and those, like Gemini, that can do it are very rare and very specifically designed to do this. so what you need is not a revamp of the ejection mod, but rather a revamp of the Gemini capsule you are using to make the exit vector be upward. I have never made a crew pod mod for KSP so I do not know what is involved in defining the hatches, but there must be some sort of vector definition to tell the game where to place the Kerbal and what direction is "out" the problem I see with trying to artificially make Kerbals eject "up" is what happens when I design a craft that an absolute "up" will make them smash into part of the craft? what if I need the bottom or side eject? thus creating an artificial up component would make it fail. I think it is better to design the craft with the limitations of the parachutes in mind, as trying to make this mod account for all the variables that go into safe ejection is far to complicated.

I would not change a thing... in real life positive VSI is the most crucial part of your ejection profile. most aircraft will not allow a safe ejection from a plane sitting stationary on the ground or with a negative VSI while under a few hundred meters. of course there are exceptions to this to allow for low level and stationary ejection. but even so the ejection profile with a negative VSI will be from much higher altitudes.

will try again, thanks.

I do not see this .cfg file in my directory. I tried to reinstall form a fresh spacedock download but still no .cfg file.