ZRM

Well, it's not me, and I don't think it's helldiver either. That's just a link to an album helldiver posted in this thread a while back shortly after I sent him what I thought was a working copy of the KSO (notice how the MFDs aren't working in his copy). Either helldiver's reposting under another name or someone thought they'd just post that album.

Yeah, well somehow I think it might be quite difficult (I'm not saying impossible - we've all learned not to say that) to get interstellar distances working. Implementing such scales on the current system directly would not end well due to floating point precision. If a modder was ever to attempt having multiple planetary systems light years apart it may be best to treat interstellar travel as unloading the system you're leaving and loading the destination system as necessary, dealing with all the setting up and tearing down along the way. There would also need to be a new super-map view for visualising space at the per-system level. The tricky part is making sure that unloading/loading systems cleanly deals with the persistence of the state of things on and orbiting bodies in those systems, and figuring out how to deal with vessels in interstellar space in the best way. The feasibility of all of this hinges on how much of the internals the API exposes. The more feasible alternative is to just have multiple systems that the user can pick between per save file. Squad would probably take a different route to implementing interstellar travel given that they actually have control over how the core code works directly. They would probably make a new "super" scaled space environment which each system's scaled space resides in. That would end up being a lot more seamless.

Well, that's a surprise, hiding away in Mission Reports. I'll still work on my approach though when I get the time, and I plan to make it much more open - for example, as soon as I get it so that you can add a custom planet via a config file I'll make a release. Then anyone can make their own planetary systems, not limited by the imagination of the mod author. Judging from those screenshots, though this is just an educated guess, it looks like Krag's mod is making planets by duplicating and modifying existing ones (for example those screenshots show a blue gas giant still possessing a green atmosphere tint like that of Jool, and the new rocky bodies look very similar in certain respects to some existing ones). I can already do that to an extent (see my previous post with the screenshot), but I would much prefer being able to generate bodies completely from scratch, which I have reason to believe is very doable, and would lead to a much greater range of possibilities. I also might have a solution for the multiple star illumination problem. Damn, I really wish I had the time to work on this, if only just to get it out my head.

Ah, I had heard that they had done something to improve PQS for 0.21, but I did not have specifics of what exactly that was. Thanks (also, link?). The changes in 0.21 are also apparently what made Kragrathea give up on her planet mod. Luckily I started the project with 0.21, so I hopefully won't have to deal with major changes to the system.

If you're not near a body's surface (near being defined as quite a bit closer than 100Km in most cases - the exact distance varies depending on the body) so that the terrain system is not active, the body is rendered as a simple 3D model. This practically guarantees that only one body has its terrain system and objects on the terrain active at any one time. You're then only limited by the CPU cost of updating orbits for extra bodies (which is not much - it's the same as the cost for all the debris you have in orbit, and think how much of that you can have) and the rendering cost of all the "distant" models. I don't think there's much in the way of a LOD or culling system for these distant models (aka ScaledSpace models), not even for the ones that take up less than the size of a pixel (which is the case for nearly everything), but I think it's possible to implement such a system on top of what's already available to keep performance at a suitable level even with maybe 1000s of bodies (e.g. with upwards of 50 moons per gas giant and a moderate asteroid belt). In theory you could make it so that only a subset of the whole system is actually presented to KSP's systems at any one time, e.g. so that you can cull asteroids. In short, I think performance is probably not necessarily a permanent problem, if indeed it is one at all. We'll see, once I find the time to work on creating custom planets (probably December at the earliest). Also, my investigations have indicated that it should be possible to create things like planetary rings, comets, and maybe even wacky things like cube-shaped planets, all as first-class members of the solar system (i.e. without hacking things much). I would also be curious to see what Squad said about number of planets vs performance, if you have a link.

Yes, multiple copies are possible. That was in 0.21, but I don't think anything has changed regarding planets and how they work in 0.22, so it should still work just as well. That Eeloo2 is every bit as good (or bad, depending on your opinion) a planet as Eeloo. I just shifted its orbit around so they wouldn't interfere, but other than that I haven't done much on this since. The same could be done for Jool, but you would have to take care to copy all of its moons as well. You can also delete planets/moons if you like as well. When I can find the time I am going to try to make a full planet generator that builds planets from scratch from custom resources and a config file, because I think I've figured out how to do it. Of course my first target would be our solar system, which would be handy for this mod. Edit: I didn't mean to imply that copying the planet Jool requires you to copy its moons - I was thinking of the case of copying the Jool system. Jool is also easily resizable and retexturable, so you should be able to have Saturn, Uranus and Neptune analogues. You can even change the atmosphere tint to match. Jool is the easiest planet to manipulate because it doesn't have a surface (well, not a surface in the sense that the other planets have). It also doesn't have any static objects on it to take care of.

I thought I had dealt with that issue in a previous bugfix. You're definitely using the latest version? Regardless, I am not in a position to work on this project right now so bug fixing will have to wait for the time being. Did you follow the installation instructions in the README to the letter? I haven't tested it in 0.22 yet (or even played 0.22 for that matter), but it should work in 0.21.

Thanks for that shadowsutekh! This thread was in danger of spiralling out of control. However, just for fun, it looks like could be misread as Isn't the ambiguity of English grammar great? Thanks again, though.

Dude, I am not trying to get an ETA, havent been asking for it either. I replied to this because I saw one of the devs talking about this thing and so I came to take a look. Only to find a fight in progress which was at that point only being carried on by people with reactions like "stop asking". Mind you, people stopped asking a dozen of posts before when the first flame was thrown. Sorry for trying to get things to settle down and shed things in a different light for some people here. Too bad you accuse me of not accepting things while you are the one not listening to what I actually tried explaining Put that in the OP then, all im saying is people ask because they do not feel like spitting trough 1000+ posts, last 3 pages being a fight, to maybe find something usefull. Put it in and you guys really have a reason to show the door to people who keep asking, unlike now. But fine, take the high road and lock it up, why am I even caring about this?! Bye! Yep, I also think modifying the OP would be a good idea, but this is helldiver's thread. Also, to be clear, there is NO ETA as of this moment, however I can return to working on the project by 6th December at the earliest. I guess I was hoping too much that would-be posters would see my notice explicitly asking to let the thread cool down and just leave the thread alone, thus leaving my notice near the end of the thread where everyone would see it. That's a fault on my part. Just to be clear, I'm not going to jeopardise my degree for this project, and helldiver does not see the point in releasing the current version as it is. Please remember that he has literally no experience with KSP/Unity modding, only 3D content generation, so asking him to "fix" something or make a tweak to make things suitable for an interim release is not a simple matter, especially considering that a portion of the project is plugin powered, and not just by my plugins, so appropriate permission requests and repackaging are required for release. I don't even have the project set up correctly here at university in order to work on it to deal with the few remaining issues. I just don't have the time. As an idea of what is left to do, here's the current TO-DO list of things definitely required for the first release: Figure out what's missing from the distribution or what else could be causing the cockpit to be borked on non-dev machines (probably just a DLL missing or a plugin version incompatibility - I haven't had time to analyse it to figure out what). The final graphics assets for the ENG (engine) panel and the HUD. Fuel/resource setup needs to be balanced. Make it so that the DirectX specific parts of the MFD rendering only happen under DirectX (otherwise the displays will blur slightly under OpenGL) - this should only need a simple check of the render system name. There are a few other very minor issues on my actual list I have neglected to mention here, as they're mostly just either aesthetic tweaks or other non-essential issues that should not take much time at all. Also, I have no experience of whatever this new attachment joint instability introduced by 0.22 is that helldiver has mentioned, so I will also have to have a look at that. If it is what I suspect it might be, it shouldn't prove much of a problem. If not there's always Ferram's new KJR mod.

Yeah, sorry for the confusion. All of the files I am working with use internal names like ksoCockpit etc., due to the convention that started when helldiver first sent me the models, so it's stuck in my head as KSO. /offtopic

It's the Kerbin Mini Shuttle (or Kerbin Shuttle Orbiter) I'm working on with helldiver. Currently that thread is filling up with "Is it ready yet" posts because work has stalled since I returned to university, so I would steer clear for the time being. All claims of feature creep and poor management are baseless. It's very close to being ready for release, just needs a few issues sorting out.

That may not be a permanent situation. You just wait until December and I finish off then release the KSO mod, then I'll be able to work on my so far unused results of my investigations into how best to add more bodies to the game and how to make PQS setups from scratch. I'm not promising anything yet, just don't continue the project on the assumption that the bodies you have are the only ones you'll ever have. If memory usage becomes an issue with more planets and a plethora of moons we can always make an alternative Linux only (and therefore 64 bit) version. Also, have you tried my suggestion about abusing rotationPeriod to allow custom rotation? Does it work out alright?

Reading about this fantastic mod is dragging me away from my studies, but after a very small bit of testing and analysis I think I can see how to do custom rotation to allow proper axial tilt for every CelestialBody (or other changes in the angular motion of a body, for example if you want to implement astronomical models of the future/past motion/rotation of the Earth) without hacking or breaking anything. If you get stuck I might be able to find the time to explain the details. If a larger amount of free time comes along I would work on the KSO mod instead, so I won't be able to actually work on this mod myself. Edit: Also, which thread should be used for discussing the planet rescale mod? People seem to be discussing it in both threads.

Thanks! That list looks great, but B9 is noticeably absent. Is that just because you've yet to try Kearth-launched space planes (space planes, IMO, seem to be what B9 is geared towards)? Has anyone dared trying space planes with this yet? I know I will once I finally finish phase 1 of the Kerbin Mini Shuttle project. Also, just a thought - what does MFS do for RCS? Some RL spacecraft (e.g. STS) use the same fuel for RCS and orbital propulsion, such as MMH/NTO.

Hey, very nice job. I've been wanting more realistic scales ever since I first tried the KSP demo. Just never got round to looking at how to do it. I don't have the time to try this out at the moment (for at least a month), but when I do, I would be starting from a clean install, so which mods would anyone recommend to go with this? I haven't used many mods for quite a while since I got caught up in modding (I tend to stick to a clean install + the project I am working on to keep load times down), so I'm a bit out of touch. I guess MFS and FAR are almost a requirement for reaching orbit, along with Deadly Reentry for realsim, but what else is useful, and which particular version/patch/fork of each mod would you recommend?

I'm content to try imaging other planets in our own solar system first. Unfortunately, since I purchased my telescope I have yet to have the opportunity to view any planets other than Jupiter, Saturn and Venus (and the only one I have photographed is Jupiter). Where I live (in a town) light pollution is quite high, so the further planets are not easily visible, and irritatingly almost all of the other planets were hiding in the glare of the Sun the majority of the first half of this year. I'm currently in university term time, but in theory when I return home to my telescope in December I should be able to employ the same technique on Mars. Next stop would be to find/write a good implementation of motion blur deconvolution so that I can photograph Messier objects cheaply (i.e. without a motorised mount). This does seem to be possible with the right conditions (e.g. most features must have comparable brightness and the motion is simple) according to academic papers. I'm sceptical that a normal 12-inch would be able to resolve exoplanets with any processing technique - surely there's a reason that only large observatories and space telescopes detect them? If I get the time I might upload one or two of the raw frames I captured as well as the processed result sans-level-correction so that you can judge exactly how good this technique is. As a general idea, the best of my initial frames were a bit blurrier and noisier than vetrox's photo, though with practically no chromatic aberration due to the lack of lenses involved. The worst were funny shapes due to air currents and exhibiting motion blur due to my less than ideal mount. The great thing about AviStack is that it selectively chooses the best parts of each frame (and may well skip several frames) at the same time as figuring out how the frames relate to each other and finding the offset between them (which was quite large as Jupiter tracked across the sky and I kept having to adjust the view to keep it in the small field of view). The settings did require some tweaking on my part before I got good results.

Nope, I wish I could afford a scope like that. Mine is an off-the-shelf 150mm (5.9") Newtonian, with a focal length of 1200mm. My camera is a Canon 600D (aka Rebel T3i). I attached it straight to the scope with a T-adapter. I think an eyepiece projection adapter might allow me to get better shots of Jupiter and especially Saturn. The reason the image looks so good for such a small and inexpensive telescope is mainly due to the technique used. I recorded 2000 frames of video from the centre of the sensor. Each of these was reasonably blurry, and quite often distorted by air currents. I then fed all of these frames into AviStack, a free image processing program designed with astrophotography in mind, which used statistical techniques to compute the near final result which I then adjusted the levels of in Photoshop. Depending on his/her setup, vetrox may be able to get similar results using stacking software like AviStack. Also, I have realised that my picture looks better scaled down:

Thank you for reminding me of my only photo of Jupiter, which I took last December. A lot of things happened shortly after that made me forget about it entirely. For posterity, let me post it here: It's stitched from several individual frames, and the levels were adjusted in photoshop. Considering that it's not taken from space, I think it's alright compared to the other photos here. It makes it all the more real when you line the shot up with your own eyeball. Saturn, unfortunately, is just too small in the sky for me to get a decent photo of with my current equipment, though I can see Galileo's "ears".

Unfortunately I am in the middle of university term time right now, and I literally have no time to work on this project until the end of term, which will be around the 6th of December. I was so close to getting everything working just right (with the main issue being figuring out what I haven't sent helldiver to get the cockpit to work for him) before the start of term, so it shouldn't be much of a wait after the end of term. This post is mainly an effort to prevent this thread from potentially drowning in "is it ready yet"/"are you dead" posts. The project won't die. I've put too much work into it for that. You could even let this thread sink for a while instead of bumping it. Threads don't auto-lock on these forums. I would also like to reiterate that at no point has the project suffered from feature creep, and that I am not changing my mind about MFS - both stock fuel and MFS will be supported eventually, but MFS will be the first one to release. On a vaguely similar note, 0.22 support will be very basic in the first release. I haven't even had time to play 0.22 myself yet. And, of course, thank you all for the support (all several hundred posts of it).

I must have forgotten to include something in the download or you did not install something. The MFDs work fantastically on my end. You're on Windows, right? (The final thing should work on all platforms, I'm just asking this to narrow the cause of the problem down). Did you check the log? The connections seem fine to me. Not sure why it would be behaving differently for you. What do you have you maximum physics delta T set to? The lower it is the better the physics should be. Not sure why the thrust vectoring isn't working right for you. Have you looked at the instructions for TT's plugin? Those nozzles do start retracted. I think the version you have is just before I fixed that. The G key should work, but due to a bug in KSP you have to press G a few times before it works, since clearly they only ever tested their code with landing gear that starts deployed. The mass balancing is easy to fix, and will be done once all the fuel is set up. I think the fidgeting may be a problem with your physics settings. It works fine for me. Did you launch with KerbCom Avionics in combined control mode? You do have to fight the SAS a bit, but launching should be relatively straight forward. The one thing to take care of is thrust vectoring angle. After the LRBs detach the angle needs to be made quite steep. What do you mean by no RCS effects? They work for me. Also, did you try turning on the cockpit lights using the light switch?

The MFD designed for flying in atmosphere (the HDG mode) will be using imperial units. The mode for space manoeuvring is in metric. You can customise the displays as you see fit by modifying the config files, so no one is forcing you to use the units that come as default. All engines use TT's Thrust Vectoring plugin. With that plugin you can bind action groups to specific angles, and keys for increasing/decreasing the angle. Once you drop the EFT the main engines have no fuel source (they run on H2/O2), so you use the pair of OMS engines (they run on LF/O). These engines need to be tilted to point through the centre of mass, so you still need to aim off-centre. This mod is still in its first phase, and will not have explicit support for MechJeb. Launch manually and manoeuvre manually. It's not hard, especially with KerbCom Avionics and SAS. In the future I may make it so that the control reference frame rotates with the engines. Be aware that MechJeb doesn't like KerbCom Avionics either. When time allows I will probably come up with my own programmable autopilot system, based on the scripting functionality used to make the MFDs work. It is planned to make a stock fuel version after the first release. By the way, I sent helldiver a copy of the project yesterday, so assuming all goes well there will be some more screenshots soon. I don't have the time to make them myself. Since the last screenshots another MFD, the NAV mode, has been added, as well as some extra small functionality like being able to turn the cockpit lighting on and off and cover/uncover the underside RCS ports.

Uh, default KSP fuel is "LiquidFuel" and "Oxidizer". LOX/LH2 is what the LRBs and main engines would be using under Modular Fuel System. So are you saying use LF/O for the OMS?

Right, I'm back working on this. Real life did get in the way. I'm going to tidy up the plugins and the directory structure, tweak some of the IVA cameras (since you want to make screenshots) and sort out the functionality of the underside RCS covers (should be quite simple, I just haven't got round to it yet), then I'll pass it on to you so you can check everything. Be aware that most of the fuel/resource load is not set up yet. For example, the shuttle itself does not actually contain any fuel yet. I just test it once in orbit with infinite fuel and infinite RCS enabled. Part masses will need to be tweaked to compensate when fuel is added, so it should still behave the same as it does now on reentry and landing. We will also need to decide about electricity usage, for example making the MFDs and cockpit lighting require electricity to function. I will also be sending you the NAV mode prototype. ENG mode is in the works, and I'm adding useful things like remaining delta-V, ETA to MECO, etc. After doing a bit of research, I found that the real shuttle used the same fuel (MMH/NTO) for its OMS and its RCS. Do you want to do the same?

Have you put it in "Combined control" mode? What other mods do you have installed? What engine types are you using? Jet engines have considerable throttle lag that make them not very easy to balance well.

It's hard to tell without at least one screenshot showing the rocket in flight as well as the KCA settings window open. Does the KCA settings window show up? If not, did you install the mod correctly by following the README file? KCA used to only replace RCS modules when you switch to a flight, but that proved too problematic in the end since KSP does not like having modules added/removed (especially removed) dynamically. The stock ModuleRCS refused to die quietly when removed, causing all sorts of glitches, and quite often it would somehow persist anyway. Another problem with that approach is that the new RCS module would not be able to save any of its state, so an RCS block would never remember whether it was disabled/enabled the last time it was loaded. So now my plugin bypasses these issues by replacing ModuleRCS in all configs in memory as they are loaded during the KSP loading screen. This has proved much more reliable, but as you have found it can cause incompatibility with other mods that look for ModuleRCS on parts. As more mods do more improvements to core functionality in the game, more incompatibilities are going to arise. The ideal solution in this case would be for me to move my replacement RCS module code to another DLL, then have both KCA and RCS build aid reference that DLL. This would not change the functionality of RCS build aid in any way, and both mods would work at the same time. They would then both include the RCS DLL in their downloads. Unfortunately I do not have much time to spend on this project right now, but it's something I'll consider when I have the time.