surge

So, not ideal in every situation, but I replaced the rover/wheels with a dummy load for rocket testing. The changes were incorporated back into the real system and it has been launched on it's way. Whether or not this will give me troubles in the future remains unclear, although now that it's launched, there's no way to 'revert' anymore, and this bug has no chance to appear, so fingers crossed...

What is the backward-compatibility policy of this mod? I've discovered that SHIP:STATUS no longer says "PRELAUNCH" (it says "LANDED") when on the launchpad. From testing I've narrowed it down to an API change made in 1.0.5, and the related changes made in kOS v0.18.2 (or thereabouts). I still use 1.0.4 due to bugs in 1.0.5, so I was wondering if it can/would be fixed? Or not worth it? If not, you might want to update the version checker stuff so it warns if you're using an incompatible version.

This post also mentions the problem that if you put Model S2 wheels inside a Service Bay, the game will crash if you try to revert. Not O/S specific, nothing to do with memory leaks, and probably not related to addons. I've been wringing my brains for a workaround with no success and alot of restarts. They are unlikely to fix it until 1.1 comes out, so any ideas? Since it's specific to that particular wheel I might have a look at the part file and see if that holds any secrets, but I'm not real familiar with the format.

In real life, most high orbit launches (russian ones at least) use a very low thrust (lower than yours obviously - the Briz-M generates about 20kN, but the numbers don't translate into KSP well) final stage to do somewhere between 3-8 burns each orbit to get the satellite both into the orbital altitude they want and to circularise it. I think the french/europeans (Ariane) and americans (Delta) do this too. Real space flight is unbelievably slow and boring! As mentioned, I tested this before on a set of circularisation burns for Jool's moon Laythe with a 2kN ion engine, that could only get enough electric power each time around for about 15ms-1 dV, and it seemed to work pretty well, so there are 2 other uses for this. Probably only the 1st is realism related, real space agencies seem to use aerobraking to help circularise an outer world orbit with an atmosphere, but with the funny atmosphere density on bodies other than Kerbin in KSP, we have to do it the hard way (at least in 1.0.4 - I've heard they tried to fix that in 1.0.5). Transfers are actually a really bad use for this, because of what you've discovered... it takes longer and longer to come around to the next orbit each time, and there's no easy way to tell the maneuvre system that you want to have a final ejection at *this* time, and on *this* orbit. It's not a fault of this mod, it's a fault of the basic system. It's much simpler to build an overpowered rocket and just do it all in one go. On the other hand, if you're doing a several million km transfer, the timing doesn't matter much, what matters most is the final velocity, so it's not entirely useless - as Lale said, you should just need a little correction burn after you've exited the original SOI. Lastly, inclination changes are more efficient if you do them in one go... by ALOT, so don't use that as a yardstick. Sometimes you have to do them over multiple burns because of TWR/crashing into the planet, but just live with it, or build a bigger rocket. If you're not doing it already, do them as far away from the body as you can when your speed is the slowest (like just after you achieve initial orbit). You'll be surprised how little it costs. Then do the circularisation burn(s).

At that point, youre just being unnecessarily kerbal. If one of the nodes is in the past, DISABLE the undo button. Punkt! You must make it idiot proof, after all. These are kerbals were dealing with! If you want to get fancy, maybe the button could turn into "delete all the nodes my mod has created" There was mention about it supposing to leave future nodes alone after all (I've not tested this, when it gave me what i didnt like and the undo button produced garbage, i just used mechjeb to "delete all nodes").

Great mod. Seems to work mostly as advertised too, which is a big plus. Suggestions on UI: -Most use cases for this will be to split a large dV change into smaller ones, as you've said. It is logical then, that the UI should have a mode when you simply type in the max dV you can support in one burst (Vy), and it splits the node (Vt) into Vt/Vy nodes, each of Vy (and possibly a remainder) Obviously this should work with other units as well, particularly time. I tested this on an solar powered ion probe which had a perigee mostly on the dark side of a moon, and i had only a few minutes of sunlight to burn each pass. -When you press + to add another split, it should copy the text from the split above it - saves alot of typing when you have to split 500m/s into 15m/s burns! Also a not-really-a-bug-because-its-undefined but if i split a node and execute a couple of them, and then press undo, it reverts to semi-garbage. If there is a way to detect if a node has been executed, you might want to disable the undo button.

uh. your silliest answer wont work at all. the mun is moving. Very fast. if you change that to be 'when the mun is on the horizon', it might. easiest = silliest

Might this be fixed before 1.1? Frankly, it's a pretty huge bug, it seems ridiculous this got past QA.

You'll probably find that all of them do go into an orbit at first, it's just not circular, or low. Because the upper stages had so little thrust (and so much fuel/mass), they would do several burns at perigee to raise the apogee before finally launching for the moon. If this level of realism is what you want, you'll want to launch several hours - possibly even a day before Munrise, and get into some orbit (doesn't really matter if you're eyeballing it), then do 2-5 more short burns each time around at perigee to exploit oberth effect, and hopefully by the time you're ready for the final shot, your perigee will be at Munrise.

[QUOTE]reentry[/QUOTE]... so you've been in eve's atmosphere, possibly started from it's ground and returned?

[quote name='parameciumkid']And surge, could you elaborate on the "sluggishness?" Last I heard the Unity upgrade is expected to produce massive performance [I]improvements[/I]. Did you hear otherwise somewhere?[/QUOTE] Sluggishness: synonym for slow. The unity upgrade may well produce massive (or more likely, very slight) performance increases for HIGH END SYSTEMS. For poor old Veeltch above there, it may well make it unplayable completely. And it won't be because of the number of cores. It will be because of some ....... new GL shading system nvidia or intel demands, and Squad just slightly aren't quite that bright enough to avoid ignoring, cooing at, fawning over, and adding code and effects for, like they did with the aero heat last time. I'm sure that knocked out about 10% of their old users. Back in the '90s I used to use a 3d system called 'crystalspace'... Only the new tech then was 'huge' (bigger than 256x256) textures (among other things), and it consequently died in the arse, because people weren't facinated by shiny new things back then, and couldn't afford the $1500 3dlabs Oxygen semi-sgi boards that could use that feature. The point is, 'new' doesn't always mean faster for everyone. In fact it means 'disabled', for many in the world of graphics. I recently bought a new system, so I'm unlikely to be affected, but I am not rich, and saved up for that for nearly a decade, and I know how it feels to be ostracised. I am already feeling sad for Veeltch.

Absolutely.

Whatever was there has been destroyed so long I can't remember. Was it a helium tank? A bunker? I don't know. I don't even remember it happening, but my best guess was a small SRB fell back on the launchpad and destroyed just this one bit of it: [IMG]https://lh3.googleusercontent.com/-SHo5uSL5aD4/VkudbObEduI/AAAAAAAAAbc/BUURvdK3uzw/s1280-Ic42/screenshot0.png[/IMG] Always point your rockets 2-5 degrees immediately on launch, kids!

I'm quite concerned about the sluggishness the next unity upgrade will cause. KSP is already horrible to play on slower computers and there really isn't a good reason for that. If it manages to improve performance PURELY because they split up the physics processing into more threads, fine. More processors, the better. But I doubt that will actually happen. More likely is more sluggish performance on older systems, less compatibility with older hardware due to use of more recent GL shaders, which frankly aren't needed, and all round general slowdown. This will all be the fault of unity undoubtedly, because they don't make the engine [I]just[/I] for KSP. Sometimes I wonder if Squad should just spend a year or 2 making their own engine and be done with unity. It clearly causes alot of problems. Of course, they can't afford that, and may not have the expertise, but if there's some nutjob who wants to donate a few million dollars, let it be for that.

The fastest hairdryer the Kerbin Records Keeping Society has ever seen. Or at least that's what Romy thought at first when she feared her hairdryer had escaped the cockpit. It turned out to be a KIS powerdriver, no less surprising. [IMG]https://lh3.googleusercontent.com/-5EiKH4gi2xU/VkuNfjeUGwI/AAAAAAAAAaU/M3pW-IYm_GQ/s512-Ic42/fastest_E-SD80screwdriver.png[/IMG]

[QUOTE]I dont like to donate, I want to Invest[/QUOTE] Thats what you did when you bought the pre-release. Your argument is invalid. If it wasn't for people doing this, they may never have produced 1.0 in the first place. An investment usually involves getting your money back, and then some. For me at least, I find that has happened, since the game has become more valued since I bought it, yet I haven't had to pay any more. Nevertheless, if Squad does need money they can charge more, and they very well might upon the 1.1 release. But because they didn't blow their entire budget on advertising, like typical AAA console games, they will likely get a steady stream of new customers for a good few years, as people hear about it slowly from word of mouth.

[B]I seem to religiously install KAS, yet never use it.[/B] Not once have I used any of the parts that I often put in rockets on a real mission. I've only ever played around with the mod on the runway at KSC. [B]I'm afraid of timewarping to the next significant event.[/B] It's becoming a serious problem to the point of stagnation, but I can't stand the thought of missing any fun or easy contracts even though I have millions of spacebucks and the KSC is fully upgraded.

You're welcome, thanks for the game Is there a way to get the -popupwindow thing to work on the 2nd monitor yet? Then it could be an effective workaround for me at least, but my 1st monitor is just too small.

Nope, i've deleted settings.cfg several times, and never set it out of game. - - - Updated - - - Looks like a case of barking up the wrong tree, unfortunately. Here's a log with no weird resolutions (I think) after `rm -rf ~/.config/unity3d/Squad settings.cfg`: http://pastebin.com/vaasp0hX All I did was set the fullscreen mode in game and go to the tracking station. Still has the error.

Argh, I should stop doing that. See (edited) post above. They are wierd resolutions - they're not even in the modes the X11 driver detects: [ 82055.301] (II) NVIDIA(0): Validated MetaModes: [ 82055.301] (II) NVIDIA(0): [ 82055.301] (II) NVIDIA(0): "HDMI-0:1920x1080+1024+0,DVI-I-0:nvidia-auto-sel ect+0+312" [ 82055.301] (II) NVIDIA(0): "HDMI-0:1280x1024+0+0" [ 82055.301] (II) NVIDIA(0): "HDMI-0:1280x720+0+0" [ 82055.301] (II) NVIDIA(0): "HDMI-0:1024x768+1024+0,DVI-I-0:1024x768+0+0" [ 82055.301] (II) NVIDIA(0): "HDMI-0:800x600+800+0,DVI-I-0:800x600+0+0" [ 82055.301] (II) NVIDIA(0): "HDMI-0:640x480+640+0,DVI-I-0:640x480+0+0"

Update: just upgraded to nVidia driver 352.55 and still have the same problem. I guess it's not the driver at fault. Here's the log. (After the upgrade), prefs has this: <pref name="Screenmanager Resolution Height" type="int">720</pref> <pref name="Screenmanager Resolution Width" type="int">1280</pref> The wierd resolution(s) were probably me mucking around with the settings, trying different ones (as mentioned).

I accidentally posted a new thread for this, so for coherency, details are linked there. I also just noted that if I use the 1920x1080 fullscreen mode (same as what the 2nd monitor is running in), the bug doesn't rear it's head, so I guess it's nothing to do with twinview. The driver version is noted in included Player.log (346.35).

My bad, I just noticed one of them. Somehow missed it before posting. FYI: The 1st link is for MacOSX, the 2nd one is not the same bug.

nVidia GTX 760 in twinview mode with 2 heterogenous monitors KSP.x86_64 1.0.5 buildID: 01028 New bug for 1.0.5 (worked fine on previous versions back to at least 0.90): To repeat: Ensure fullscreen mode is active. Start game and go to tracking station. Only occurs in fullscreen mode and only in the tracking station. Other scenes with sidebars (like the VAB editor) are ok. I've tried several different resolutions, both fullscreen and windowed. The fullscreen ones are corrupt, the window ones work normally. Player.log http://pastebin.com/i1gkzxPG I suspect the heterogenous monitors/twinview confuse KSP. When in fullscreen mode it only fullscreens on 1 monitor, but because twinview reports desktop size as both monitors, it seems to be misjudging where the left sidebar is. Although, I couldn't test it on the 1st monitor, because KSP fails to draw properly on anything less than about 1024x768 (cant see/access the 'accept' buttons in settings).

This occurs for (cockpit) lights and gears too.