maxdreamland

[quote name='Av3ry'] My question : What can't I install with RSS? Or would I be better to downgrade to KSP 1.0.4 and run all the suggested mods and essential ones... Or stick with 1.0.5 and just isolate the ones which aren't updated yet. (And does anyone have recommendations as to which are which?) THANK YOU[/QUOTE] Do yourself a big favour and start using CKAN ([url]http://forum.kerbalspaceprogram.com/threads/100067-The-Comprehensive-Kerbal-Archive-Network-(CKAN)-Package-Manager)[/url] ... not just for RSS/RO but in general. It makes life so much easier to be aware and follow all the inter-mod-dependencies. CKAN does all that work for you. seriously, take a look at it, you won't regret it.

Hi, I'd like to report a bug concerning one of the modifications done by RO to one of the FASA parts. I noticed this when i tried to build and fly the "Explorer 1" craft from the FASA package. When you build the Explorer 1 you start with the "Explorer 1 probe" part and then attach the "Baby Sergant Solid Kick Motor" and below that the "Baby Sergant 3x Cluster Decoupler". That last part, the decoupler, is the one that has the bug. If you try to attach it, it will "click" to the part above but the "decoupler icon" in the staging display (bottom right corner) will not be shown as included into the staging. it will show like a part that was "put aside" and is not connected to the rest of the craft. It will also not show/create the little conical fairing that is supposed to be created dynamically after attaching the decoupler. you have to flip the part upside down for it to correctly attach and both show the conical fairing and be integrated into the staging display in the bottom right corner. But if you do it this way there is another problem. when you launch the craft and finally come to stage the decoupler, the dynamically created, small conical fairing will still show, even after the decoupler has been decoupled. It will be part of the final Explorer probe, which looks weird and wrong. I had a look at this myself already, and i believe i found the source of the problem (but Im not an expert, so i might be wrong). It looks like somebody did this on purpose so I'm not sure if it is really a bug or maybe i use the decoupler wrong. if you have a look at this config file: GameData\RealismOverhaul\RO_SuggestedMods\FASA\RO_FASA_Explorer.cfg You will find this section: @PART[FASAExplorerSgt3Dec]:FOR[RealismOverhaul] { %RSSROConfig = True @MODEL { scale = 1.494, 1.212, 1.494 } @scale = 1.212 // fix node orientations (FASA has them screwy) // @node_stack_top = 0.0, 0.01, 0.0, 0.0, 1.0, 0.0, 0 // @node_stack_bottom = 0.0, -0.01, 0.0, 0.0, -1.0, 0.0, 0 @title = Baby Sergeant 3x Cluster Decoupler @description = A small decoupler for your 3x Baby Sargent engine cluster. @mass = 0.008 @MODULE[ModuleDecouple] { @explosiveNodeID = top // @isOmniDecoupler = false @ejectionForce = 1 } } The three commented out lines (nodes_stack & isOmniDecoupler) are my fix for the problem. With these lines commented out the decoupler behaves like i believe it should. you don't have to flip it upside down anymore before attaching it. And the conical fairing vanishes after staging the decoupler. if this is not a bug I would be glad to learn how to use the decoupler in the right/intended way. regards Max

Thanks for the feedback. I'll have a look at the log, thats actually a good idea that i could have had myself :-)

Hi, I have a performance issue with RSS and RO. And the fact that I don't read about this significant drop of performance anywhere else lets me assume that this is not a general problem with the addon but something locally on my system or install. But to be sure, and before i invest a lot of time investigating the problem I wanted to quickly hear what you guys have to say about it. I started using RSS and RO a couple of weeks ago (installed via CKAN) and initially I enjoyed it very much. That was until I hit crafts with a part count around 75-80 parts. then the framerate dropped dramatically and an in-game second now takes several realtime seconds to simulate. An 8-9 minute flight to orbit easily takes 25-30 realtime minutes now. And as you can guess, it's not fun anymore :-) Partly because of this performance issue I upgraded my system last weekend to a brand new Core i7 6700K overclocked to run at 4.7Ghz with a Geforce GTX 680 (i kept the graphics card from the previous PC for now). this helped with the problem but the difference between "stock KSP" and "KSP with RSS/RO" is still night and day. Without RSS/RO I can easily launch crafts with 75-80 parts with no problem (even larger craft with 100+ parts are no problem). It's 60 fps all the way to orbit. but with RSS/RO installed the 75-80 parts craft is down to around 30fps and the time indicator on the top left corner is going yellow. so now i'm wondering if this performance drop is just something that comes with the increased complexity of RO and needs to be accepted (and has been accepted and is therefore not discussed on the forums, therefore i couldn't find any information about it?) or is there something fishy with my install? Is it unusual to experience this significant performance drop off and is it therefore worth my time investigating this? thanks in advance! best regards Max

Hi, i recently tried streaming my KSP gameplay to a friend with the Geforce Experience streaming feature (the one with the Chrome Extension needed to work on the client side). I didn't get it to work with KSP, because each time I press ALT+Z to pop up the streaming overlay (where you can activate the streaming and generate the URL for the client to connect to), KSP is minimized to the taskbar and the streaming feature says for it to be working a game must run in fullscreen mode. I made sure that KSP has the fullscreen option enabled in the settings, and i even tried switching it on the fly with ALT+ENTER, but to no avail. The streaming feature always assumes that there is currently no game running in fullscreen. I tried other games (namely the Witcher 3) and they worked fine. When i press ALT+Z in the Witcher 3, the streaming overlay will popup over the game instead of minimizing the game to the taskbar. It feels just like for example the steam overlay. and i can activate the streaming in witcher 3 no problem. I was wondering if somebody maybe has the same problem and maybe has a solution for it? thanks in advance! best regards Max UPDATE: someone on reddit pointed me to this thread that had the solution: http://forum.kerbalspaceprogram.com/threads/114935-KSP-1-0-x-0-90-windows-true-exclusive-fullscreen-shadowplay-and-gsync-solution

yes, the effect seems to be related to using HE and MJ in conjunction. when i use either one of them alone the effect does not appear. when i use them together, tough, it's easy to reproduce and it completely "breaks" MechJeb. i also observed several times now (not always, though) that when i first use the MJ maneuver planner window after i changed an orbit with HyperEdit, the maneuver node created shows "NaN" (Not a Number) as "delta V remaining". so it seems that HE does "something" to the orbits that MechJeb doesn't "like". I understand that you won't be able to say much about that. I'm a software developer, too and i can make an educated guess how hard this would be to debug. so i guess for now i'll just stop using the two addons together. HE is a cheat anyway, right!? :-) just kidding :-) regards Max

i tried the beta DLL and i can still observe this behaviour. one guy in my other thread mentioned that he uses HyperEdit a lot but does NOT use mechJeb and he never observed this effect. so maybe it is some sideeffect between HE and MJ. i guess i'll try to uninstall MJ, startup a fresh steam-download from the game and try to get to Duna, do some maneuvering there without any mods, then install HE (beta) and change some orbits and do some more maneuvering and finally install mechjeb and see when the effect starts to show up. i'll get back to you on that.

Hi, recently i came across a problem with wandering maneuver nodes and created a forum thread to find out about the root cause of this effect. you can find this thread here (the thread describes it in detail and there is also a video of the problem): http://forum.kerbalspaceprogram.com/threads/110757-why-do-maneuver-nodes-wander-around following post #17 in the mentioned thread it became apparent that the underlying cause of this seems to be HyperEdit. I was able to confirm that by deinstalling HyperEdit the effect will vanish. so i'd like to bring this to your attention in case you're not already aware of it. thanks in advance! regards Max

i have now flown a simple mission to Duna (with unlimited fuel cheat enabled) where i uninstalled the HyperEdit addon and @eddiew was right, the problem is gone. i've updated the reported bug and marked it fo rejection. maybe i can get in touch with the author of HyperEdit and make him aware of this effect. thanks again to @eddiew for giving the key hint! regards Max EDIT: i've now posted the problem in the HyperEdit Addon-Thread, maybe it will get some traction there: http://forum.kerbalspaceprogram.com/threads/37756-0-90-HyperEdit-NEW-VERSION-Teleporter-Orbit-Planet-Editor-More?p=1739780&viewfull=1#post1739780

thats very interesting! thank you for your feedback! i'll try this right away. but i have a feeling you might be right, because it would make sense why i never came across this effect before, when i played in the Kerbin system. because i never used Hyperedit there. And like you said, i started using Hyperedit t when i worked on my Duna Lander Module, to be able to quickly test landing/ascent/docking scenarios. before i read your comment i already created a bug report for this: http://bugs.kerbalspaceprogram.com/issues/4090 i'll just leave this here for now. if it is in fact a side effect of HyperEdit i'll close that ticket after i was able to verify it. thanks again! regards Max

i investigated this effect a little bit more. i tried to vary different variables to see if they have any effect. first i varied the mass of the craft itself. i tried crafts with 0.2t, 4.6t and 590t. they each suffered from the effect exactly the same. so craft mass doesn't seem to be a factor. next i varied TWR. i tried TWR's of 0.26, 4.80 and 56.00. again no effect, they all suffered the same. then i started to check out different planets and moons. from the ones i checked Moho, Eve, Eeloo, Ike, Jool and even the Mun all suffered from this effect. i was especially surprised to see that i could recreate the effect at the Mun, because i played quite a lot in the Kerbin system before and it never caught my eye before. i did find a couple of places where the effect was not present, or to be more precise it was less pronounced. less to a factor that mechjeb was able to complete it's maneuver nodes. those places were Gilly, Bop, Pol and Minmus ... all relative small (light) moons. so gravity seems to be a factor here. i don't know what to do next. to be honest this impairs my fun with the game significantly because i like to use mechJeb, especially for things like rendesvous and docking. and given that the effect seems to be present in so many places/cases/scenarios i'm surprised this hasn't been a bigger issue before in the community. i mean even if you don't like to use mechJeb and do everything manually, this is still quite annoying. or am i just especially sensitive? :-) does somebody know how we could get the attention of Squad for this? is there an official way to report bugs? regards Max - - - Updated - - - nevermind, i think i found it myself: http://bugs.kerbalspaceprogram.com/ i think i might report this and see what comes of it

OK, i managed to throw together a video that showcases the effect i'm talking about: https://www.youtube.com/watch?v=QaU51V4QzBY you can clearly see that the behaviour around Duna is vastly different than around Kerbin and i don't believe it is merely a "rounding error" thing. let me know what you think when you watched it. i annotated the video, but it basically shows the build of the simple spacecraft and then the same maneuver twice. once around Duna and once around Kerbin. in Kerbin orbit mechJeb has no problem to execute this simple maneuver. in Duna orbit mechJeb will be caught in an "infinite loop" and burns all your fuel, and then some :-) i believe what most of you guys tried to describe/explain to me with the "residual error" and "floating point imprecisions" can be seen in the video at the very end of the Kerbin variant of the maneuver. there is a tiny amount of jitter visible for the maneuver node display on the navball. but it in no way interferes with mechJebs ability to complete the node. The behaviour around Duna ist vastly different and "breaks" mechJeb. just to be clear, this is not a mechJeb introduced problem. the same thing happens without mechJeb and manual controls. oh by the way, i decided to use mechJeb for the video because that makes it easy for everbody to reproduce this effect without any "manual control effects" introduced on top.

i'm glad i'm not the only one...i started to question my sanity :-) still, would be interesting to find the root cause for this...

i actually used the SAS "point at node" feature. i agree with you that the node is "supposed" to move "a little" towards the end of the burn because of this effect. and i'm used to this while playing in the kerbin system. and it never effected the gameplay adversly. more to the point, it never rendered mechJeb useless. so the behaviour around Duna is definitely something different or far more pronounced. I'll make you a video later on, i think that will clear tings up...i understand it's hard for you guys to comment on it without experiencing it. i probably should have done the video from the start. sorry for that. it tends to wander to the "north pole" (of the blue hemisphere) of the navball.

@brdavis: yes, i think i understand the concept. but if you get close to node completion for a simple maneuver like raising your apoapsis where you basically just burn prograde, the "residual error" what you call it, shouldn't suddenly make the maneuver node jump 90 degrees upwards. thats a direction you would never burn to, no matter how large the residual error becomes to complete the burn. wouldn't you agree? i think it will really help if i try to post a video of the effect, later when i'm at home.

@henshaw: no, i don't think thats it. i'm familiar with the effect you describe, but it's usually only a factor with very long burns and the node deviation/wandering is small. in the scenario i described above we talk about a 19m/s delta V burn that is may 1-2 seconds long at full thrust. that is quasi instantaneous. and the node wanders around like crazy (90+ degree deviations) and you can try to chase it forever. when i'm at home i can try to make a video of it...this is something different than you describe, i'm pretty sure.

I recently started to leave the Kerbin system and started to exlore different planets, like Duna for example. while doing so i discovered a behaviour that i never came across while navigating within the Kerbin environment (Kerbin, Mun, Minmus). i would be curious to learn if i'm doing something wrong or if this is a quirk/bug of the game. for the sake of simplicity take the following scenario. slap together the simplest of all spacecraft. a command module, a fuel tank and a liquid engine. then use HyperEdit to place the craft in a 52km Duna orbit. create a maneuver node to lift your apoapsis to, let's say, 85km. when you start to execute that maneuver node keep an eye on the node in the navball. when you're close to completing the node, throttle down so you can observe the effect more clearly. every time i'm close to completing the node, that means when i aproach less than 1 m/s delta V left on the node, the node starts wandering on the navball. usually 90 degrees up. And no matter how long you follow the node, you will never be able to "complete" it, because you will never get down to 0 m/s delta V left. i started noticing this behaviour when i tried to use mechJeb to rendezvous or dock with other craft while orbiting Duna. It's impossible, because mechJeb can't complete a single maneuver because of this effect. at first i thought my install was messed up. but since then i tried fresh 0.90 steam installs without any mods (except HyperEdit) on two different machines and the behaviour is the same. i tried the same scenario around Kerbin (little different altitudes of course) and it works fine there. i assume thats why i never noticed it before in my game. is this something the community is familiar with? do i have to live with it? can i do something about it? any input would be appreciated. thanks in advance! regards Max EDIT: after some discussion it became obvious that a video of the effect would be helpful for everybody to know what we're talking about, so i provided this one: https://www.youtube.com/watch?v=QaU51V4QzBY

Hi, recently i had an idea for a plugin and i considered trying to implement it myself. But since i have never done anything in C# before i figured i throw the idea "out there" and see if somebody more experienced is interested in picking it up...and undoubtetly come up with something far better than i would be able to :-) i claim no ownership or any rights of any kind to the idea, so if you like the idea feel free to jump on it. I was thinking about a small window that displays the science you are missing in context to where you are right now. So, for example if you were on Kerbin, it would show you that you are currently in the biome "XYZ" and that you never did a crew report and an EVA report from here. Or you maybe on a low orbit around Minmus and the plugin would tell you that you never measured the temperature here. There is a nice table of all the different places you can do science, here: http://wiki.kerbalspaceprogram.com/wiki/Science And the game itself keeps track of what science you already did (and where) in the science archive. so in theorie the plugin should be able to figure out what science you are missing for any given place you are right now. I think that would be quite helpful, since the possible combinations are so many that you almost can't keep track of it manually. regards Max

Found it, thank you!

i've never done this myself, so take this with a grain of salt... but you should check out the addModule.cfg file in the GameData/KAS directory. Open it up in an editor and have a look around. you'll see lots of GRAB {} sections that seem to modify stock parts and make them "grabable". they look like this: GRAB { stockPartName = linearRcs evaPartPos = (0.0, 0.00, -0.21) evaPartDir = (0,0,-1) dropAtGroundPos = false dropPartPos = (0.0, -0.1, -0.65) dropPartRot = (0.0, 90.0, 0.0) addPartMass = true storable = true storedSize = 4 attachOnPart = True attachOnEva = False attachOnStatic = False attachSendMsgOnly = False } i would start and copy one of those entries, change the stockPartName to one of your modded parts and see what happens. regards Max

you really shouldn't talk about women like that :-)

Hmm...one more question...i'm wondering how i can change the thread-prefix from "unanswered" into "answered". I tried "Edit Post" but that didn't work.

Somebody already recommended "Infernal Robotics" and there is a great video about a compact satelite that fits inside a fairing and "unfolds" once in orbit. You should check this out for inspiration:

Great feedback, thank you both! Of course, you're right, i have to take the SMA and not the orbit height...totally missed that, thank you! As for the factor of 2, i "kinda" had it in there...and...still got it wrong :-) I used Exel to quickly compute the width of the cone for a given angle (including the fator of 2) and then fiddled with the angle until i got the right cone width. But then i forgot that this value for the angle represents only half the angle. Yesterday i tried this out in a sandbox game (by cheating and "teleporting" a test satelite into Moho orbit, using HyperEdit) and it turns out your recommendations do in fact work. I used a Communotron 88-88 and it has sufficient range and viewing angle. So i can start to implement this in my career savegame. Thanks again for your feedback! regards Max

Well, thinking about a bit more, i noticed a fault in my thinking. I should actually check if the cone is wide enough at the closest distance between the planets, too. Otherwise not all the satelites orbiting Kerbin (or Moho) will be visible to the targeting satelites. The closest distance between Kerbin and Moho should be the difference between Kerbins Periapsis (= Kerbins Apoapsis) and Mohos Apoapsis. Which will be 7.284.074.276m. And that would equate to an angle of roughly 0.02275°, which is considerably larger than the 0.00825° I computed before. So this larger angle should actually be my target value. Any more thoughts? regards Max