surge

Anyone else noticed the "merge" button no longer works in the new version? Or am I being a dumbarse somehow. Assuming I'm not the only one, it's not a big problem because the workaround is just to go back to using temporary subassemblies like we used to. Just requires a bit more faffing around.

Don't forget, the ideal optimal is of course 0, so bearing in mind the highest lattitude launch site, you still want it as close to 0 as possible. I presume that's at least one reason why the ISS isnt polar. Then again, the closer you are to the pole, the less 0 inclination becomes optimal, or even matters at all, right? Since the launch site isnt travelling east as fast. Hmm... Theres probably some complicated maths involved there.

Ive been working on this myself recently (and on and off for several years). A trick Ive noted is to tilt the whole ship so that its in it's various flight configurations (i.e. hover, forward motion, etc.) and look at the vectors. It becomes fairly easy to see how it will react when you actually fly it. Obviously, dumping all the fuel out of it and repeating is worth doing as well. Be sure to post if you figure out how to get the KAL-1000 to behave with rotating engines... I am having immense trouble trying to get 2 of them to do yaw AND forward/backward at the same time.

It goes in <KSProot>/saves/<name-of-your-savegame>/Ships/VAB Optionally .../Ships/SPH if its a plane. (It doesnt matter, it will just load facing a weird direction if you get it wrong; you can just rotate it)

Not really the problem is it? They clearly are. More importantly, it lags the hell out of the game because it's spamming stuff about the UI.Navball to the log file. Has anyone else seen this, is it a bug, or is my memory going bad (it's not ECC, so I don't get reports on it failing)? I reloaded that game recently, but it seems to have dissapeared, so I can not report the log error anymore... hmm.

I'd hardly call 4 months 'old'. And it's worth pointing out that this only applies to the right-angle triangle parts. The isosceles? (non-right angle) parts work properly.

What's this? https://imgur.com/a/fbWqWX5

Ive seen this a lot too, so much so that my stupid launch ladder vehicle (so that kerbals can deliver science data to a rocket before launch to an orbital lab) with a hinge on top of a 30m high pile of structural parts now has the hinged part sitting about 5m away from where it is meant to be. It looks ridiculous and is completely useless now. https://imgur.com/a/KQzX0oY I'm pretty sure it's not specifically gravity, its the physics loading that causes the parts to jump around slightly, which over time causes big problems. I used to use the Infernal Robotics addon heavily, and since Squad has clearly nicked the code from that, it inherits the same problem. The heavier the stress between the parts, the more they jump each time, so while autostrutting helps a little bit, the problem will never really go away. BTW, I find Rigid Attachment works a bit better - I built a new version of that ridiculous contraption above with that on between the hinge parts, and even after several 100 launches, its only moved about 1m.

After a bit more testing, I noticed the audio file is the same as the one used for the "Spark" engine, which also does not have distance attenuation. This must have been a long standing problem, but I guess no one noticed until now, partly because the "Spark" is meant for space operations, unlike the RV-1, which is the steering motor for the RD-107-110 (for the real R7/Soyuz) or for our RK-7s. Actually the only engine from the "orbital class" that works properly is the Thud. The other engines I tested, you even hear in map mode, which is ridiculous, and pretty annoying. They were: Puff, Twitch, Spark, Spider and Ant (but I've noticed just from playing a lot that all of the monoprop engines have this problem too) I don't have the time or energy to test the heavier engines, but I imagine more of them work properly, since, as I said, it's probably only during launch that one would notice these problems.

After finally being able to build Soyuz launchers with this expansion, I find the RV-1 "Cub" engines are WAY TOO LOUD. I guess the RK-7 "Kodiak"s are meant to be RD-107 engines (and not RD-170s as I've been hoping for), but they should not be drowned out by these tiny little steering motors. The problem has been reported here, but until it gets fixed properly, heres a patch you can apply for more believable sound levels: --- KSP_linux_1.8.1/GameData/SquadExpansion/MakingHistory/Parts/Engine/LiquidEngineRV-1.cfg 2019-12-26 05:09:46.013579997 +1030 +++ patches-1.8/GameData/SquadExpansion/MakingHistory/Parts/Engine/LiquidEngineRV-1.cfg 2019-12-26 05:35:48.298569219 +1030 @@ -42,7 +42,7 @@ channel = Ship clip = sound_rocket_mini volume = 0.0 0.0 - volume = 1.0 1.0 + volume = 1.0 0.1 pitch = 0.0 0.75 pitch = 1.0 0.95 loop = true (Apply with patch -b -p1 in your root KSP directory) As you can see, it looks like some sound engineer just fat-fingered an extra 0 in there (Dunberatu describes it as "2-3 times as loud", but volume is logarithmic in perception, so in reality, its 10x more). I have noticed that this part does not have distance attenuation either; if you zoom out really far in order to try to make it not so loud, it does nothing. Therefore the real fix must involve something deeper, but since that will probably never happen, this patch should hopefully stop blowing up your ears.

After a search for this, I found a billion old forum posts here and from many other sources, but they were all asking the same question: "Does it matter?". As an long-time player I know it does not, but on the same vein; I was looking through the astronaut complex recently for new hires and remembered something: Some kerbals in old versions used to scream their little heads off during the entire ascent of a rocket (particularly Bill), which I found very amusing. I've been keeping an eye out for the least couragous and smartest kerbals, which I suspect causes this. They seem to have nerfed the hell out of it since... I dunno, 1.1? Because even during missions where I'm supposed to make kerbals pass out, they are usually still rubbing goo off their hands or adjusting their helmets and smiling What causes the panicy screaming, is my question? And I suppose, what traits aside from "BADA55" (yeah, yeah, we know) tends to cause other behaviour... for those who try to look up this question in the future.

steubens option is the one that i chose, as awkward as it is. It was supposed to be a sort of 'suprise' gift. If he needs to create an account in advance, it kind of ruins the experience, doesnt it

I would put this in your bug tracker thing but it requires an unacceptable amount of javascript, and password lengths I will never remember. (10 chars? liquid off) NAVBALL_TOGGLE { primary = KeypadPeriod secondary = None group = 0 modeMask = -1 modeMaskSec = -1 } This has been a control config since at least 1.3.0. It no longer works. Obviously annoying since at critical moments like hoverslam/suicide landings, I need a single key to hide the navball that works all the time, every time.

With the new website design, I no longer know how to buy KSP for a friend. We do not want steam/console versions, just the standard DRM-free one from www.kerbalspaceprogram.com. I know my friends email address, and I am ready to pay for him. That should be enough, right? Any ideas?

[snip]

As a suggestion, is it possible for you to punch the information from the spreadsheet back into the original post in this forum? Perhaps this 'google docs' can export it in html or whatever format this forum uses (i think it's called BBcode)? Say, at least when a new KSP release comes out, or every few months if you have the time. I exercise my right NOT to complain, mainly because you've collected the URLs to the mods I want already, and I always check them for the latest builds, regardless of what this post says. This idea does seem to solve all the problems though, if it's possible - As a heavy mod user, I generally don't use the new KSP versions until the mods I want are updated and they fix the invariable linux/mac problems; usually at least 1/2 a year later. I'm still running 1.3.1, and only a few months ago updated from 1.3.0 for example. I don't think I'm alone in this.

So it was unintentional. A shame.

If you're left wondering how to turn these vectors into something tangable, this function converts body-relative vectors into the strange ship-relative triplets required by node(): FUNCTION nodeFromVector // from a reddit post somewhere (I've forgotten) { PARAMETER vec, n_time IS TIME:SECONDS. LOCAL s_pro IS VELOCITYAT(SHIP,n_time):ORBIT. // The following assumes you do not change sphere of influence // between now and n_time LOCAL s_pos IS POSITIONAT(SHIP,n_time) - BODY:POSITION. LOCAL s_nrm IS VCRS(s_pro,s_pos). LOCAL s_rad IS VCRS(s_nrm,s_pro). LOCAL pro IS VDOT(vec,s_pro:NORMALIZED). LOCAL nrm IS VDOT(vec,s_nrm:NORMALIZED). LOCAL rad IS VDOT(vec,s_rad:NORMALIZED). RETURN NODE(n_time, rad, nrm, pro). } As noted I don't take credit for this (nor do I really take credit for anything here, since it's all just regurgitated equations from other sources). I found it on reddit after the much worse version I invented didn't work properly (see the oneorbit() post). Anyway, you can now do things like: set V1 to lambertMinE(R1,R2) -velocityat(SHIP, burntime). set n to nodeFromVector(V1, TIME:seconds +burntime). add n. to add the calculated maneuvres into the map. Making them actually happen is a less advanced topic not for this thread.

And luke-lukem, Squad has always screwed up linux (and apple) majorly in the first few new versions, hopefully take-two won't do any worse. Although I wonder why you need a joystick to drive a rover I just write kOS code to do trivial crap like that

It's clearly not that because I've noticed that after assigning an axis, and returning to the settings screen, it still shows '<>' as if it hasn't been assigned, rather than saying something like <Joy2, axis3> or whatever that stupid SDL2 mucks it up to be. Admittedly, I havent checked the settings.cfg immediately after, but AFAIK, that is only saved on exit anyway. Or perhaps when you press "Apply".

While I'm at the soapbox, in the 1990s I wrote a bit of code for a project called "gamedev" that automatically calibrated polled joysticks. Several months later, I found something similar in the linux kernel, similar to: value > axis_max ? axis_max = value : value; value < axis_min ? axis_min = value : value; I think they missed the extra part that also centres the axes - they lost that when they started using /dev/input/jsX (evdev) instead of just /dev/jsX. I released my bit as public domain, so no matter who wrote it, it has been used in SDL right up until SDL1.2 and because of it, I've always been able to laugh at windos users with impunity because they seem to need to constantly calibrate their joysticks. Now this... nothing makes me angrier than morons "forgetting" good algorithms just to be more "windows-like", or lately, "console-like", or "ipad-like".

I haven't tested if it still works this way in versions later than 0.90 or so, but it does look a bit like they were intending to enable launches from Baikerbanur at some point - If you parked something on the launchpad there, and tried to launch a new vessel from KSC, it gave you a dialogue box that indicated the launch pad was occupied (possibly the "recover the vessel and continue/cancel launch" one), even if the launch pad at KSC was empty. Can someone confirm this still happens? I accidentally deleted my long standing save game recently that had stuff near Baikerbanur and had to start anew.

Yeah, my web browser has this "new" thing called "Search" - I just press '/' and type what I'm looking for. As I'm well aware, *maintaining* this list must be a real PITA, but for "users", forcing them to use an unnecessarily complicated spreadsheet is a bit ridiculous. Anyway, it's Gaarst's decision, I'm not going to complain.

In case we have to end up using this ridiculous system that basically maps the axes of my very expensive joystick to act like a pathetic console controller, heres one for the CH F-16 Combatstick (just the joystick, not the throttle controller): SDL_GAMECONTROLLERCONFIG="030000008e060000f400000000010000,CH PRODUCTS CH COMBATSTICK USB,platform:Linux,a:b0,b:b2,x:b1,y:b9,back:b3,rightstick:b8,dpup:b4,dpdown:b6,dpleft:b7,dpright:b5,-leftx:h0.8,+leftx:h0.2,-lefty:h0.1,+lefty:h0.4,rightx:a0,righty:a1,lefttrigger:a2~," Don't forget to `export SDL_GAMECONTROLLERCONFIG` Note that there are no new lines in these, the forum formatting will probably add more, so you need to remove them (I've forgotten how to do the codeblock thing) As luke-lukem and Badsector have noted, it doesn't actually work yet, because KSP immediately forgets the settings. While I have the extremely hard to find program (you basically have to recompile SDL2 completely) that generates these strings, heres one for a Logiteck MOMO Racing Wheel with pedals: SDL_GAMECONTROLLERCONFIG="030000006d04000003ca000000010000,Logitech Logitech MOMO Racing,platform:Linux,a:b3,b:b5,x:b2,y:b7,back:b4,guide:b6,leftshoulder:b0,rightshoulder:b1,rightx:a0,-righty:a1~,+righty:a2~," The really moronic thing about this system is that the GUIDs (that huge hex number at the beginning) are generated seemingly randomly by SDL2. Theres no way to find out what they are without writing code that asks libSDL2 itself; they aren't related to USB addresses or vendor/product IDs at all. Some "millenial" at SDL needs a good hard stabbing in the face.

A million bucks says you're overloading the clock for the DP (3 ports? pfft!) - disconnect all other ports, and then see what it does? This smells like a poor design/hardware problem. Before you complain, my nVidia (a 960 or 980 or something, not as fancy as yours) board has the same problem - there are 4 connectors on the back but it only has enough clocks to supply 3 of them. It's commerce/false advertising gone rampant.