Troberg

Sounds like it will be a long process anyway. I suspect I'll just add a ****load of fins and rcs instead, as I have plenty of delta V to spare. They should be able to keep it on track.

Are the fairings purely cosmetic, or do they affect the aerodynamics? My problem: I've made a huge permanent Eve base. It has its center of gravity spot on, yet the launch rocket slowly tips over, due to the drag being a bit off, making it un-launchable. I could fix it by trial and error and adding stuff until drag balance out, but that would take forever, especially since the entire vessel is so complex that it'll take at least two hours for each trial launch (yeah, I know, it's a bit much, but it's such a cool base that it'll be worth it...). So, if I put fairings covering the payload, would it solve the offset drag problems?

Oh, another thing: * When you move a vehicle from the SPH to the VAB (I often build payloads in the SPH, then move them to the VAB and add a lifter), symmetry gets messed up. Say, for example that I set it to 6x symmetry and place an RCS block on the side of the tank, instead of getting six RCS blocks placed evenly around the tank, I get a circle of six RCS blocks on the side of the tank that's facing me. This is probably just a minor oversight, missing to adjust the orientation of something in the transition.

Well, my suggestion was not so much about fairings as it was about a way to increase performance by replacing many parts with a single part. Fairings were just a way to hide the switch. Yes, it would probably freeze the game for a while while the parts loaded, but, frankly, I prefer a 20 second freeze to a 60 minute slide show... Sorry, I didn't see that in the list, must have missed it. What's the mod, and does it increase performance as I suspect it will? A practical example: I was working on a largish base today. I was zooming/translating around all over the place using shift and arrows. Then, when I started trying to just rotate with the left and right arrows, it got strange, probably because I had moved past the point it used to rotate around. The problem is there with all crafts, but with small, uncomplicated crafts, you'll probably not notice it. Yep, I know. That's why I said it was probably a biggie. I just wanted to throw it out there, and maybe, somewhere down the line, in some future version, it'll happen. Maybe just some workaround (hmm, perhaps it can be done using docking ports...). Yep. I know. I just see it as an unnecessary newbie hurdle that could be easily fixed. I'm not saying that the devs should do the work of the modders, just that they should "let the information flow". For example, the new directory structure in 0.20 could have been announced a week or two in advance. Likewise, I'm not saying that ani modding interfaces should be etched in stone, just that one should weigh in "will this change break mods and is it worth it at this point" as one factor in the decision process. I'm a developer, and I know how frustrating it can be to develop for a "moving target". I've done that, a lot. It helps a lot if one gets some insight into the thought process of the devs who make the target, as well as some information like "this bit is pretty much done as it is, it's not likely to change for a good while", "we are rewriting this bit, be prepared that you will have to handle data like this instead" and "this is mostly just a test stub, don't rely on anything to be stable or unchanged". I'm not telling them, I'm just suggesting. There is talent out there, and they got an excellent opportunity to see the quality of their work. Hiring is hard, and any indication of the competence of a candidate is worth a lot of good money. Then again, a company, especially a software developing company, needs to grow organically and at a pace where new developers can be assimilated into the team in a good way, so one should not hire so much that one dilutes the core competence. I've worked at a small company for a long time, and have seen both how it should be done and how it shouldn't be done. Either way, my suggestion was more about pointing out a possible resource than a command to hire.

Some humble suggestions, all based on my own, personal, opinion: * The main focus of development at the moment needs to be performance. I have a decent computer, and as soon as I try to make something a little bit more complicated (say, 500-1000 parts), the performance drops to levels where I use MechJeb, simply because a launch to orbit can take an hour or more. Suggestions for improved performance: ** Don't treat all parts as structural. For example, I want to add lights, antennas, navlights and other mostly aesthetic stuff, but, as they increase the part count, perfomance drops to a slow slideshow. So, my suggestion is to treat those "decorative" parts as just decorations, and not include them in the physics calculations for structural failure et cetera. That would reduce the number of performance sucking components a lot. ** Add something like Procedural Fairings, but, when the payload is hidden under the fairings, it's replaced by a "dead mass", with the same center of gravity, angular momentum and so on, but it's one single part. That way, even a complex payload (like my current 600 part permanent Eve base) would run smooth as grease. It would also encourage the use of fairings, which means nicer looking, more realistic rockets, instead of the usual bird's nests. ** Allow some parts to make a permanent bond, in effect making them a single part for the physics engine. Example: Tanks. If you use a stack of two orange tanks or four half size grey tanks shouldn't matter. Either way, they should, for the physics engine, become one big tank, totally rigid. Less parts, better performance. Would also reduce the wobble problem a lot, as well as making "realism sense" (for a real rocket, they would make one tank as large as needed, not stack a bunch of small tanks). Other positive side effects are less need for struts (once again, fewer parts) and less different parts needed (why need several lengths of tanks if you can just stack smaller tanks). * Larger VAB and SPH. I frequently build craft that don't fit well in them, especially the height of the VAB is a problem. * Landing pad. Precision landings are fun, but the launch pad is usually cluttered by launch supports, and has some nasty slopes. So, just a circular concrete pad with some markings to land on would be nice. * Autoexec action group. I'd like to be able to set up an "autoexec action group", where I could add actions that should be performed automatically even before the craft is put on the launch pad. Typical examples: lower gear (for testing landers and stuff, it's often useful to start in the "landed" position), disabling gimbaling, disable fuel cross-feed, activate lights/nav lights and so on. Basically, a way to put the vessel on the launchpad, ready for start without fiddling around. * View controls in the SPH. For larger craft, they quickly become very awkward and pressing the correct key almost becomes guesswork. I'd like some more intuitive, first-person-shooter-like controls. Move with the arrows, look with the mouse. * Trusses. I often put stuff on other places than the ends of the trusses, and it's fiddly, very fiddly. I'd like some more attachment points, such as on each side, half a truss width from the end (for nice 90 degrees joints) and halfway along the length on each side. * Realism. I know there are a lot of people who wants hardcore realism, but I'd want a mode left that's something like what we have today. Frankly, I have no interest in the next to impossible logistics of realistic manned interplanetary flight. Too much realism would also create a too high threshold for new players. * VAB and SPH, aligning parts. A common situation is that I've, finally, after fiddling around with pixel precision mouse movements, manage to get the part where I want it. Problem is, it's not pointing perfectly in the direction I prefer. So, I'll have to click the part and try to align it properly without it popping lose and me having to start over. My suggestion is some modifier key, say, Ctrl, which, when pressed when clicking a part, leaves the part connected in its current position, but still allows me to rotate it. * Building "rings". As far as I can see, with the exception of struts, no components can be connected so that a loop is formed. or, in other words, they will only connect on one node when you place them. Example: Take four four-way connectors and four habitat modules (or tanks). Try to make a square using those parts. When you try to put the last part in, it will only connect to one node, making the construction wobbly. Sure, I can use some mod, such as quantum struts, to stiffen it, but then I get more parts and require a mod. I suspect this is a biggie to fix, as it probably would require changing the internal data structure as well as the VAB/SPH logic, but it would be very nice if it could be fixed, as it would allow some very sturdy constructions. * Stronger parts. Seriously, vessels over a certain weight is next to impossible, as tanks start to collapse simply because of the weight of the stuff stacked on top of them. * Clearer part descriptions. The main thing I miss is clear information about if a part is 1.25m, 2.5m et cetera. Shouldn't be too complicated. * Mod compatibility. I know it's under development, and one can't do a lot of work to not break mods. That said, try to avoid unnecessary changes that will break mods, and try to announce in advance what mod makers will need to do to keep their stuff working, to minimize their downtime. Face it, KSP is, for many players, a very mod driven game, and breaking mods slows adaptation of new versions and causes unnecessary annoyance. I'm not saying that you should go out of your way to preserve mod compatibility in all cases, but keep it on the agenda. * Modders. Seriously, there are some really, really good modders and mods out there. I know you've hired one modder. If economy permits, consider hiring more, or negotiate with some of the modders to give some mods an "official" status as part of the base game. Now, it may look like I'm just whining, but the truth is that I really love this game (I wouldn't do a two hour slide-show speed launch with choppy sound if I didn't really, really love the game). That's why I bothered to write this long post with suggestions about some details that bothers me. I hope some of them will be found useful. Either way, excellent work, keep it up!

Sorry for going off topic, but where did you find the "cockpit" for that crane? I've seen others use it, but haven't found it yet.

Use one of the mods that give stronger struts, and strut a lot.

Is it possible to use MechJebb for a non-optimal planetary transfer window? My problem: I have a multi-ship mission going to Eve (several large base parts, rovers, airships and stuff). Now, if I launch them all into orbit and use MechJeb for the transfer, they will all be scheduled at about the same time. Since they won't run if it's not the currently active flight, all but one of them will miss their launch window. Now, the first kerbonauts will not like having to wait until the last ship arrives two years later with all their toys (rovers, airships and stuff) because they'll have to wait for the next optimum window... If I could tell MechJeb to advance or retard the launch a number of orbits, it would be much easier. For example, on a three ship launch, first launch one ship a Kerbin orbit before optimum, the second on the optimum and the last one orbit after optimum.

Ah, I see. Then I misread the instrumentation. My bad, sorry.

When you get it working, please make it in various lengths. Some applications of this will need very long lengths, probably 10m or longer...

Then we are seeing different results. When I burn one engine, it looks like only the one tank it's attached to drains, but as soon as all engines start to burn, it's equalized. A bit like with ordinary asparagus staging, where it looks like it drains the inner tanks as well, but as soon as the outer tanks are dropped, the inner snaps to full immediately. My suspicion is that the display is a bit off, but internally, it's keeping correct count, and some events (such as killing all engines and then starting them again, or dropping a tank) forces the display to update. Btw, I run 0.20.2, if that makes any difference.

OK, here's a simple test craft that works for me. Burn on one engine only for a while, then activate all engines and you'll see that the fuel levels are equal in all four tanks. http://rpglab.net/nobackup/Fuel%20loop%20test.craft

I'll try later today or tomorrow, as I didn't bother to save the test craft. I use a bunch of mods (MechJeb, Firespitter, NovaPunch, Damned Robotics, Subassembly saver and a few more), but none that explicitly has that effect.

Actually, loops can be quite useful. I use them on large rockets that are too heavy to keep going straight with only RCS, so I occasionally might need to turn off a radially mounted engine in order to get it pointing in the right direction again. The problem is that this drains the tanks at different speeds, which, of course, messes up staging when I'm going to drop them, as well as moving the center of gravity. So, by connecting fuel lines in a loop going all the way around the radial tanks, they all drain at the same speed regardless of which engines I use. Very useful. Try it out yourself. Make a small rocket with four small radial tanks and a weak engine on each. Draw fuel lines between the tanks clockwise (or, if you prefer, counter-clockwise, just stick to the same direction all the way around). The, put it on supports. Turn off all the engines but one, then start it, without releasing the supports. Watch the tanks all drain in perfect unison. Nifty.

Great! I'm building an epic permanent base, based on the Hooligan Labs airships. It's destined for Eve (but will work on Laythe and, with minor modifications, Duna as well), have the capacity to house over 100 kerbal, will carry over a dozen rovers and airship based rovers (all usable manned or by remote, all electric, so fuel won't be an issue), the main base will be able to fly as an airship, but it can also drop off a ground base which can house around 30 kerbals. Some parts needs to be moveable and unloadable, that's why I need the sliders. Now, to get 300 tons or so in one piece to Eve, that's the challenge...

Thanks, I just figured out on my own and was about to post a "Nevermind...". Sorry for the inconvenience. Any ETA on the slider (I really need to create a long extendable ladder, as well as a cargo unloading crane)?

Just to clarify, which InfernalRobotics.dll to use? Magic Smoke or DRobotics? I'm a bit unsure about how to interpret what you meant, English is not my first language, and I find your explanation possible to interpret both ways.

Now, if I want to use these and the parts from DRobotics at the same time, how do I do it and is it possible?

That's because on a 32 bit machine, the available address space is limited, as graphics memory and the PCI bus uses some, so even if you have 4 GB memory, you usually get below 3 GB usable. On a 64 bit machine, each process gets its own address space, and that problem disappears. All this, of course, assumes Windows. A Linux 32 bit machine handles up to 64 GB (iirc) without problem. It's an OS limitation in Windows, not a hardware limitation.

Nice probe legs! Now, Some really strong legs for big landers would be nice. My current Eve lander (with return capability) weighs in at 250 tons (it also carries three wheeled rovers and two airship rovers) and requires a ****load of legs. Also, it would be nice with a stronger 6-way hub than the default, and in all sizes.

In the MechJeb Wiki, I found this documentation for the MechJeb API: http://wiki.mechjeb.com/index.php?title=Autom8 Now, this is extremely cool, as it allows me to automate launches. Why would I want to do that? Well, once I've got a stable launch platform for, say, a refueling station or an interplanetary return stage, I could automate launches so that when I don't use the computer for anything else, I'll just let it launch a mission to, for example, put an interplanetary return stage in orbit around Eve. This would take some of the tedious boring missions out of the game, and let me focus on the glorious missions. Also, it would, with very little work, allow me to set up an extensive support network all over the Kerbol system. One mission every night, one mission when I go to work and so on. However, the last edits to the documentation is almost a year old, and the API does not seem to reflect the full capabilities of a modern MechJeb. So, at last, my question: Is the documentation up to date, or is it missing something? Is there any newer documentation?

Another suggestion: MechJeb is an excellent learning tool, and in some cases, for example ascent and landing, it's quite verbose in telling what it's doing. However, in some cases, it's not as informative. It would be very nice to have a status window, where MechJeb tells exactly what it's doing (or waiting for). That way, a newbie could easily pick up the basic principles just by watching. Also, it would provide a way to see if MechJeb has misunderstood something and is about to mess up (which, occasionally, happens) before it actually mess up.

A small feature suggestion for the landing assistant: An option to set a minimum distance from the wanted landing site. Why? Well, it's too darn accurate, that's why! It frequently lands within 0.1 m of the intended target. That's nice if you want to land close enough to dock with the target, but, if you, for example, want to build a Mün base, you don't want to stack the landers that carries the different parts. Likewise, if you target KSC, chances are that you will collide with the debris on the launch pad. A minimum distance would fix this, so that you land at the target, but not closer that the minimum distance you set. Also, for landing at KSC, perhaps it would make more sense to use the airfield as target instead of the launch pad.

Or, even better, put a docking port at the end of the robotic arm. Just reach out and connect, then pull it together.

Check that you've actually put the boosters on the decouplers and not on the central stack. Remember, when you place the boosters, you are aiming with the mouse, not the booster. So, point the mouse on the decoupler and click.