m4ti140

Are you going to add spin-up engines and yoyo despin system for Star48B in future? I know they are useless since we've got SAS for stabilization, but it's the most kerbal stabilization system ever made IRL IMO: 1. We want a cheap interplanetary stage - let's strap it of control systems! 2. Oops, it doesn't want to point into burn vector long enough - let's spin it up to ridicoulus rotation rate and use teh physics! 3. It must be cheaper - let's make it an SRB! 4. Oops, the probe is falling appart due to spinning and we've got nothing to stop it... Hmmm... Let's throw away 2 counter masses on ridicoulusly long rope and use dah physics. Though I think the letter would require some plugin work...

Dude, with so many mods installed my game wouldn't even start... I have seperate install for each space program... But I have 32 bit OS.

Is there any chance for g-force tolerance to be adjustable for each part seperately by cfg editing? Bc current limit is sometimes either to low or to high for specific parts.

^This - the starfield dimness when looking on Kerbol is alredy simulated, so if you just lowered the brightness until stars disappear completely when looking towards Kerbol, it would be OK. Of course for all of this to work properly, KSP would need to recognize planets as light sources as well, but it still would be better then stock + engine sounds should be removed too if you are planning to simulate silence of space. IRL these aren't heard in space, neither in cockpit - AFAIK, no, it doesn't go through the spacecraft's body bc the engine sound doesn't exist in space, it requires air around nozzle, resisting the escape of exhaust gases, for the sound to be produced - nor outside.

Yep, that's what I do as well. I have a separate install with Soviet pack and functionality mods (MJ, DR, FAR) only, with even some stock parts removed. Same with Constellation. And the limit of RAM for 32-bit apps is not 3.8GB. Actually 3.25 GB is an upper limit of whole RAM used on a 32-bit OS. The actual limit for 32-bit application is 2GB. This can be increased if an application has IMAGE_FILE_LARGE_ADDRESS_AWARE flag in image header. I don't know if KSP.exe has this but it probably doesn't. There was once an application that force set this flag on binary level, I used it with Unreal Engine 3 based games (e.g. Mass Effect 2) and in Battlefield 2, but it should work on any 32-bit .exe AFAIK. Unfortunately I don't remember its name. MS Visual Studio also has an universal tool for this AFAIK.

Well, that's interesting, bc there is a whole page in this thread about this issue...

1. It does affect your a/c - if you make a standard-configuration plane (main wing and rear stabilizers), if you leave pitch at ailerons, they will counter elevator's input - if you pitch up they will act like spoilers, pushing you back down, and if you pitch down, they will act like flaps, lifting you up. Also if you leave roll on rudder, it may overdo its input, leading to unnecessary yaw + IRL it's pilot's job to take care of rudder and apply correct yaw to prevent side-drift. Leaving pitch on rudder and yaw on elevators/ailerons shouldn't do any harm since they don't work in those axis anyway but only if your wings/horizontal stabilizers are perfectly horziontal, and vertical stabilizers are perfectly vertical, otherwise they will make unnecessary input in axis they are not meant to work in. Also leaving roll on elevators is only a good idea if you build a fighter and use winglets for elevators. 2. I guess some study on aerospace engineering XD. I'm starting my studies in October, so I guess I will find out . But wikipedia should be enough. @Ferram - I think I also hit the node drag problem, I was reentering with soyuz descend module from bobcat - since it has both, top and bottom node, free at reentry, the torque from drag they made them cancelled out (though it should've been applied on top node only, since it isn't aerodynamical, forcing proper orientation) which togeather with intentionally offset CoM allowed me to stay in correct orientation. However, the drag of whole pod was so ridiulously high, that while normally I would probably overshoot the target with FAR (since it lowers drag), I landed almost 300 km short of target. I had like 5G on flattest possible reentry trajectory and didn't even see reentry plasma. It worked almost like a parachute. Maybe you could allow to disable additional drag at specific node with a part.cfg parameter/module (name = FARNodeDrag; disableDrag = [node name])?

Thanks for info! That's good to know. I have a question about wing parameters: How to handle a part that is an actual wing, not a canard or such, that has built in control surfaces? Should I add both FARControllableSurface and FARWingAerodynamicModel or just FARControllableSurface?

Ferram, are you planning to add heatshield aerodynamics (like lift at non-retrograde position of pod)?

What do you mean by "Squad hasn't released a patcher"? I used the patcher I had in my download of 0.20 to update to 0.20.1 (which failed) and than to 0.20.2, which seems to have worked - my version number changed to 0.20.2 and there were no errors. Does it mean it didn't actually update and I should redownload the game? It seems to work correctly so far.

No problem with non-transparent LER, it's KSP after all. LER wasn't even transparent in 'Moonbase Alpha'. EDIT: Kvant and other Mir modules are not exactly to scale. It can be fixed by setting rescaleFactor on Kvant-1 to 1.1268 and on TKS based modules to 0.9122 - this makes the diameter of docking compartment on TKS based modules the same as the diameter of Kvant-1, which is ~1.048 of Core module diameter, just as IRL.

Doesn't Mechjeb 2 allow exactly the same functionality (Attitude Adjustment pad)? omg, almost every equation on that page contains an integral...

here: http://forum.kerbalspaceprogram.com/showthread.php/24724-0-20-X-BobCat-ind-Historical-spacecraft-thread?p=423695#post423695 page 73 The surfaceDist value may require additional tweaking, with a use of original model (it seems to be the distance beetween 0;0;0 point of the part and KAS attachment node) - I found 0.08 by trial and error

I made a fix for Mir Core top solar panel, it's few pages back in this thread. I haven't yet changed the Kvant panels, gonna take a look into those.

THIS IS A GENIOUS MOD! Thanks.

Which version of MJ are you using, daver? 1.9.8 or 2.0.8 ?

@Shrrom and Daver: Well, that's only one thing, after you update KAS you also need to change module entries in part.cfg's of parts that use KAS module, bc they are a bit different in current KAS version, otherwise they won't work. E.g. for Mir Core Top Solar Panel you need to replace this: MODULE { name = KASModuleEvaGrab grabKey = g grabMaxDistance = 2 grabBreakForce = 3 grabbedPartPos = (0.0, 0.10, -0.25) grabbedPartRot = (180.0, 90.0, 0.0) attachKey = h attachMaxDistance = 2 attachOnPart = True attachOnEva = True attachOnStatic = False } with this: MODULE { name = KASModuleGrab grabKey = g maxDistance = 2 breakForce = 3 evaPartPos = (0.0, 0.10, -0.25) evaPartRot = (180.0, 90.0, 0.0) addPartMass = true grabSndPath = KAS/Sounds/grab } MODULE { name = KASModuleAttach attachKey = h rotateLeftKey = b rotateRightKey = n surfaceDist = 0.08 maxDistance = 2 allowPart = True allowEva = True allowStatic = False sendMsgOnly = False pointerUseModel = True partRot = (0.0, 0.0, 0.0) } This will allow to place solar panels on surface in space, using eva. You need to do pretty much the same on Kvant-1 solar panels. Figuring out the correct surfaceDist value requires some trial and error.

If you mean version 1.8.5, that variant doesn't work. After I did a few modifications to part.cfg's it started to work. Anyway, am I allowed to upload those modified cfg's for other users, or am I prohibited? íтþ, чтþ õÑÂÑ‚ÑŒ ò òÑÂÑ€ÑÂøø 1.8.5 ýõ рþñþтðõт úðú ýðôþ. Úþóôð Ñ ÑÂôõûðû ýõñþûьшøõ ø÷üõýõýøѠò ÿðрт.цфó рðñþтðõт úðú ò рõðûьýþÑÂтø. Ãœþóу ûø Ѡ÷ðóру÷øть üþôøфøцøрþòðýýыõ ÿðрт.цфó ôûѠôруóøх? ï ø÷òøýøтõ ÷ð üþù ÃʄĄÂÑÂúøù, Ѡø÷ ßþûьшø

Again, what do you mean? Could you write it down in Russian as well, please?

OK, as I've said I made some cfg editing to recreate OGB SAS behaviour and I succeeded. All I had to do was to add nodes to Soyuz Orbital Module and top shroud (they're now meant to connect to each other (yes, I did maths, nodes are in correct positions) - that's not exactly how it worked IRL, but it at least looks more realisticly now) and added/removed some decouplers on top and bottom shrouds. Now shrouds behave correctly both on abort and separation. The only thing I couldn't figure out yet was how to make airbrakes open via hotkey - they neither open with action group (I added all stuff that happens on OGB SAS separation and escape into "Abort" action group) nor with 'gear' button (it is present in "Gear" action group), they need to be opened with gear icon. Now, BobCat, can I upload somewhere and/or send you in Private Message the modified part.cfg's for Soyuz TMA Orbital Module and shrouds?

Thanks, will test it out. There must be something wrong with that pod, s1 in BobCat's thread reported the same issue when using just Mechjeb (while for me it worked fine with MJ installed). EDIT: I confirm this fix works. There is no more frozen rocket issue. Thanks!

OK, I did as you said and it seemed that Deadly Reentry 1.3 was causing this (I was expecting it might not worked since it was flagged as a module for 0.19) so I removed it. It didn't solve the problem but this is what I got in place of NullRefs this time: loading part: Soyuz TMA Descent Module (Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54) Cannot load Module ModuleCommand because the associated module on the part doesn't match the saved module (Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54) Cannot load Module rbr_chatterer because the associated module on the part doesn't match the saved module (Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54) Cannot load Module MechJebCore because the associated module on the part doesn't match the saved module (Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54) Cannot load Module ModuleRemoteTechSPU because the associated module on the part doesn't match the saved module (Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54) Part Soyuz TMA Descent Module_4293608200 cannot load module #4. It only has 4 modules defined (Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54) Now, I have no idea what does this mean. I was launching a fresh spacecraft from launchpad. Removing rbr_chatterer from this part still fixes the freeze problem

I had exactly the same glitch but not with Mechjeb - it happened when I added Chatterer to it. I came to this game after Orbiter 2010, and I do know how real Soyuz worked. Including SAS [i don't mean the gyro, that's how Soyuz LES was named] and landing engines (which I personally miss, though you're right, it's pointless unless you lower descend module's impact tolerance to destroy on touch). And probably I'm not the only one. If someone downloads a replica of real life rocket, than he is not a typical user which didn't even read the manual, if there is so much cool, noob-friendly, Kerbal-style stuff around. Ignore the trolls as well as people who are a textbook definition of noob [why read manual if I can complain to creator that it's too difficult? That's not the way to go guys]. Don't let them limit your possibilities. It's an Indy game, adress your high quality work to high quality players. What do you mean? Again, I play this game for 2 weeks, counting off time spend with demo, and I still DO know how to use action groups. It's not that hard to learn, in fact this game is much easier in this matter than any other space flight sim (read: Orbiter, bc there aren't many more around - and in Orbiter everything like this is menaged with config files, which are not as user friendly as in KSP). E.g. I use action groups for more realistic stage 3 ignition and seperation [yes THIS is a correct sequence for soyuz]. And again, I'm probably not the only one here. I'm gonna do some cfg work on those nodes and see if I can recreate OGB SAS behaviour myself. Though I have absolutely no clue how node placement works in KSP [but I can learn, can't I]? Text in square brackets is adressed to people who, after finding themselves too dumb for this mod, stalked BobCat about it instead of reading the manual or changing game to easier. Hope you won't get discouraged by careless users BobCat, your stuff is awesome, keep up the good work

Well that would explain why I heard chatter - Progress obrital module has 2 spots for crew, though they don't contain crew. Maybe it should check how many kerbals are actually on board to define it? After all, a mannable spacecraft travelling empty, on autopilot, would not produce chatter either. As for Soyuz Descend Module, when I add chetterer to this part (it's a marked as CommandPod in part.cfg) right after entry about loading this particular part there are 4 entries of NullReferenceException. If I try to do something with the frozen part, it starts to spam this entry. adding chatterer to a different part than Descend Module solves the problem. Also there are no such issues with any other pods from BobCat's Soviet Pack. Note that I've also added Mechjeb 2 to this part (and each other command pod in the pack - there are no issues with them), and I have crew manifest, module menager, Romfarer's Lazor module and kerbal alarm clock installed.

I got a strange issue with this mod + BobCat's soyuz - when I added chatter module to Soyuz TMA Descent Module part.cfg, it broke - the ship was frozen over a single point on surface and the orbital speed gauge showed 0 m/s. Anyone knows what could cause such behaviour? Also how does this mod realize wheather a craft is a probe or manned ship? Bc when I added radio to Progress I heard regular chatter instead of beeps.