MaHuJa

I saw this issue in ksp 22 with kas 0.4.4 (I think) - I'm kinda of suspecting the culprit is remotetech - do you have it as well, and if so could you remove it and try again? (I wiped my gamedata folder for .23) As a workaround, if you use the... "holders" for the containers, you can put them back into place rather than let them float off. (If the containers are correctly mounted, you can even release them on command rather than having to pick them up in EVA.)

I'm so quoting you on that. At least for a while. -- For rounding, you have round() as dio said, floor() which always rounds down (to nearest whole), and I don't remember if kOS provides a ceiling() or ceil() function that always rounds up (again to the nearest whole).

Coming back and seeing the code again with fresh eyes; That code was never correct in the first place. It's not that it broke ("I`ve noticed a change") but that you couldn't see what was was wrong with it before. Probably better explained by this page: Programming by coincidence (It's aimed at professional programmers, for the average kOS user its advice is partially overkill. Heck, we're in the business of killing kerbals with our mistakes, right? ) OTOH you have two problems: 1) you are assuming realtime and gametime are in sync, which is in my experience rarely the case. 2) wait 1. does NOT wait 1 second, it's 1 second plus however long it takes before it starts the next frame update after that. To do it correctly*, i suggest you code for a wait random(0.5) . (if random existed) - which is really about prohibiting any form of set x to x-1. (for a time-related value) in favor of something along the lines of set x to floor(time:seconds - st). Match that with a wait 0.1. and all will be well. Usually one would do the opposite. There's no point in drawing the same frame twice (the situation would not have changed), but multiple physics ticks between frames can smooth out problems that occur from big physics steps. For simulations that don't solve the big physics steps by putting things on rails, that can be a pretty big deal.

Which, if correct, means the entirety of vanilla ksp is fubar. The time command is sourced off of KSP's "Planetarium" class, which tracks ingame time. I don't know the KSP internals very well, but it's not a stretch to assume planet positions/rotations, orbits, maneuver nodes, you name it, it relies on it. More likely, that magic number bit you. In the first code sample, you're doing -st-5, and later you lock the throttle to ct/7. This seemed to me like a curious mismatch - You say you want 7 seconds, so is the former magic number (5) the source of your problem? (If so, it's easy to miss - and keep missing - as long as you're using magic numbers like that. Are you very low on storage space?) Wait, on the other hand, is real time. (UnityEngine's deltatime, which I believe is time since last frame was rendered. So the loop will stop dead for a full real second in each iteration.)

Skygunner85203 - the focus functionality broke with .23 so you want the hotfix I provided 2 posts over yours. Kiyonisis - I'm able to reproduce it; it only seems to happen in an if. As a workaround, set bol to status="landed". if bol { print "test". }. seems to work. Dunno what's causing that problem. You say this broke with .23? Or is this a script you haven't tested in a while, say a previous kOS version?

I just forked it and tried to compile it, but it doesn't even compile for this version of ksp. However, think I managed to stumble onto a hotfix - both sides of the lock/unlock now want an identifying string. I think I remember a mention in kerbal kon about the bug that was supposed to fix - kOS uses the ship editing "picked up a part" logic to capture game focus. Anyway, I'm about to load up ksp with my own build to test this fix. Edit1: works beautifully. Now to check the license then stick it in dropbox. Edit2: GPL makes it simple. Here you go for a working version. Source is the same except adding a string literal for the lock and unlock calls. https://www.dropbox.com/s/0gmwx6latfb9fth/kOS.dll Edit3: Pull request added, so whenever he comes back it's only a couple clicks; he won't even have to know what caused the problem.

And the same with module = LazorAimable if you have any of the color modules installed anywhere.

So between crew manifest and TAC Fuel balancer, I already have all it currently adds? The #1 extension to crew manifest I would like to see, is that the roster shows what ship each kerbal is aboard.

Experimental rocketry is a node that's way up in the "endgame". That's where you'll find EPL stuff. That's the level where individual techs cost 1000 points, on the branch that goes with improved rockets. (I suggest going for the science tools first, will help a lot in reaching it sooner rather than later even though it's a detour.)

Cheesy, you should probably read his post. (Tip: License.) Were it me I'd be liable to make asking for granted permissions revoke the permissions in question. Now, I'd just need a reason to switch back to this after targetron filled that void.

My solution to the pipe bombs problem was to not use pipes. My base is connected by winches only now. I think the pipes will still be useful for orbital "docking", and for simple connect-refuel-disconnect operations, but time will tell.

-I don't know of anything in particular that happened before I saved - I switched away from a moving vessel (out of power means I could not turn on the brakes) and saved - when I loaded that save, my mun base detonated. -The base in question only had pipes actually in use. However, it happened to all vessels in the area, even those not part of the base. -The only part I'm not sure was present is the struts. It's possible winches weren't there, and in any case wasn't in use at the time. - No relation, afaict. It's been happening a lot, though, even when not carrying any parts. It's even happened in space, such that I could not activate the rockets, and jeb just drifted away. - I did place most of the pipe ends on the ships by means of EVA, prior to this event. No obvious relation. When I load that game - quicksaved - the base is first rendered on top of the ground, but then it seems like the ground moves upwards (which may be the camera-locked object moving down along with everything else) as soon as the game "activates". I can send you the quicksave, but I have a great number of mods around, including some really old ones. No custom edits currently, though. Opening it in the editor is probably not going to be very useful, but still an option. -- For the rest of you - pipes are basically a hybrid of strut and winch. It has the homogeneous nature of the strut - both ends are the same piece - and the features of a docked winch cable. Struts cannot be used between separate ships, pipes can - and will then merge them in the same way docking does. The hook support is placed on any stack point (just like the stack winches); you can then mount a hook (magnet, presumably grapple and perhaps even anchor) onto it instead of a winch.

Bug report: When the rocketpart requirement is 7 digits (including . and two decimal places) or more, the text wraps and you can only see the lower half of each number. I don't know if it wants 6k or 8k parts. I do recognize it when it wants some 12k parts. Which brings me to my question: How exactly is the rocketparts requirement calculated? I've built several small utility vehicles without problems (other than getting them off the pad, my "robot" with canadarms has helped a lot with that) but the parts requirement scales to ridiculous. Is it exponential off the ships dry mass or something? Edit: Turns out to be SRBs that kill it. Are we paying 1 rocketpart per unit of solid fuel or something?

There's a conflict between the Extraplanetary Launchpads build window and the progcom window. On a ship that has both, it will offer to "close" the build menu if the computer window is open. On opening it, it'll be the progcom window but stretched. I've edited my savefile to remove the progcom component, and it worked again.

I think the stock game "part x damaged by y exhaust" will purely increase the temperature of x until it hits the max for that part.

I've had it happen again, twice. Including one where I think it happened to some other engine, I think maybe it was stock engines, and probably connected to using "x" to cut off engine power.

If you build the probe in the SPH, you can use the symmetry mode. The same goes for its landing gear. Then using subassembly loader to put the finished assembly on your rockets is pure win.

You have FAR installed. FAR lies to MJ saying that it has no air resistance whatsoever. Correct guess?

You can point a kerbin dish at "mun" and a mun dish at kerbin, and they'll talk. I'm not entirely clear about how the mechanics of that work to/from outside the kerbin SOI though. For probes going all over the system, I'd suggest having one pair of kerbin satellites per probe - possibly condensed into two massive "relay stations" - that will never be on the same side of kerbin. The satellite itself would only need a dish pointed at "Kerbin". My preferred orbit for such a relay station has a polar apoapsis just short of losing contact with the "inner" network or escaping kerbin, whichever is shorter, and a periapsis and eccentricity that will make sure it spends far more time out there. If you have two of those and you don't mess it up horribly, you will never lose contact from the kerbin side. These relay stations can then target/track each probe separately to always stay in contact as the probe moves between planets and spheres.

2) If you click the "duration" label, it'll turn from time to dV or m/s, which the node will show in various places. 1) If - the dishes are attached (as in, part of the ship), - powered, - there's a RT "core" unit (like the rc antenna or the 1m 2m remote control/command pieces), - there's nothing (planet/moon) between, and - they're aimed (that remotetech dialog lets you set where the dish is communicating with - it can be individual ships or more general regions) at each other, they should communicate. Did I miss anything?

(oops, I had written increased) Skyrender's post basically said that by designing for a lower TWR (less thrust), you can get lighter engines (less mass to drag around -> more dV) and/or more efficient engines (higher isp -> more dV). Thus you'll be spending less of the fuel you've just mined and refined to get the fuel where it'll do something useful. I am simply saying there's a point where reducing the thrust further to get less mass or higher ISP will actually increase the total fuel portion consumed in transit, and giving people some idea of how to discover when they followed his advice too far.

Note: MJ2's function of burning half before and half after a node doesn't take this setting into account, in my recent experience.

Mechjeb2 can certainly show this. It'll show what the current air input is and what the engines require - I think both at current throttle and max throttle. All measured in kg/s or so. So that's 3 such values you can put in a custom window.

Under FAR, the non-far drag calculations all return 0 - so mechjeb thinks there's no atmosphere to worry about, meaning terminal velocity is infinite, and landing trajectories will not include air resistance effects on landing site or max drag g estimates (roughly corresponding to DRE heating.) Last I heard, "they" are getting together to fix it. Not sure who "they" are though, if it includes Ferram. It's in the last few pages of the MJ2 thread, and will probably only apply to MJ2. Your english was fine - clear and unambiguous.There are two issues with FAR that keep me from using it. This is one of them.

And here's me chiming in on that "feasible" which requires so much emphasis the above is almost pointless to say. All the time you spend from starting your burn till getting the orbit* you're paying 1.63m/s for each additional second (Mun gravity is 1.63m/s2) you spend on this compared to what a more powerful twr ship does. To extrapolate, a ship with a twr of 1.01 is going to spend all that fuel basically just hovering. A more powerful engine (or more engines) could do that burn in less time, so you spend less time fighting gravity, and thus pay fewer 1.62m/s penalties. (Twice as efficient as 1.16 is 1.32, not 2.32. Each additional "unit" of twr is less worth the more you have but costs the same.) But then the added mass and/or decreased impulse would itself reduce the dV of the ship, so that's a balancing act, like everything else. This also doesn't account for how much maneuvering you need to do once you are in orbit, where low twr is usually less of a problem. TL;DR: If you plan the launch well so you don't need to do lots of maneuvering, more engines or stronger but less efficient engines, can be cheaper on the fuel. Up to a point. That depends on your piloting AND planning skills, however. (Did I say mathemathics is part of that planning?) * An orbit is a state where you get back as much dV as you lose in a period. If you'd get a sudden injection of dV from the ground pushing you up from your orbit path, they call it sub-orbital.