swjr-swis

Well, to start with, I think they made a mistake with the linearly decreasing torque curve: that's typical for DC motors, but not for the AC type motors used in battery powered vehicles, which tends to be max for a considerable portion of the operational RPM spread, and then only a slight drop. So that I think still needs readjusting, separate from the heat production considerations. Heat production, I agree it should be somehow directly linked to RPM/speed. I'm leaving out potential air cooling effects in atmospheres, including that may overcomplicate things. I can agree with that, but I dislike the whole 'space-bound engineers start with no clue about wheels' mechanic, so I don't like the repair requirement. Basic repair skills of the equipment should be an essential requirement of an engineer included on a space flight... not something they 'learn on the job' (or worse, after the fact as if a posthumous badge pinning suddenly makes them more capable of now averting a potentially mission/personnel killing technical mishap).

I actually think this has to be a bug, and that at some point someone at Squad will go 'wait a minute now...'; one would expect a probe that is clearly designed for rovers and to be placed in a specific orientation, would have the control/navball properly aligned for surface travel. The obvious workaround would be to add an additional small probe core, or probably easier a surface-attachable Jr docking port, with the correct orientation 'forward', and either re-root to that, or in flight right click and select 'control from here'.

It is indeed. If you're feeling up to it, would you be willing to do another try, but this time keep an 80 degree pitch on the way up? I'm curious to see if it holds for very different designs that a slightly angled path can get just a smidge more altitude out of the run than a pure vertical 90. You will end up way out in the middle of the ocean with a long way to make it to land, but a water landing likely destroys less parts than the landing you recorded with this one, so win win.

This is why Molniya orbits are usually populated by multiple satellites, at least triplets, so there's always at least one in the high/slow part of the orbit over the operational area. I don't think the stock contracts asking for these orbits do this though; at least, I've never seen it ask for more than one sat being placed in the same orbit. The sort of application they tend to be used for, ground signal relay and observation specifically for high latitudes, does not really exist at the moment in stock. Except maybe in a very convoluted self-created situation of placing probe controlled vehicles in a deep valley on one of the far away planets. I agree it needs some more/other types of instruments to really have some practical use - even in the sense of the game.

Yes. Extra Large too, please. We are currently doomed to try make do with just the medium gear as steerable option for crafts of sizes/masses that require the large/extra large as main gears. Aside from the very visible and ridiculous size/height mismatch, it's also always quite a job to get the respective gear height adjusted to each other without having one almost floating under the craft by itself while the other simultaneously sticking out through the top somewhere. Combinations of XL/medium in particular are very hard to get to look and work right, the size difference is just too extreme. On top of that, and due to the height mismatch often causing such craft to have to lean heavily on the nose (or the tail with taildraggers), the medium size gear ends up overstressed and very prone to exploding during take off and landing. I've ended up way too many times just forfeiting a steering option completely because of this. There is nothing about the large gear model that would prevent it from realistically have steering. I imagine that the longer 3x2 assembly like the XL may be more problematic from an engineering point of view, but then at least provide a steerable 2x2 more matching to the XL size and with appropriately adapted weight tolerances (a simple resized copy of the large gear would do nicely... once it's been made steerable).

I don't have an exact answer, but I do know that the fairing segment radius works somewhat like a Bezier curve (but not quite!), in that when you make a sharp angle in a segment, the segment right before that will be flared a bit in (or out depending), apparently to try to 'smooth' out any sharp angles. I'm sure the amount of flaring is a neat mathematical formula of some kind, but I have not seen it mentioned anywhere. I just know it very annoyingly keeps preventing me from creating very exactly designed shapes.

The screenshots only show 240827m (or 240890.3m if we take KER's word for it, which is a bit fuzzy at the moment). A typo perhaps, or have you uploaded the wrong pics?

Except this does not do what @dognosh is asking, which is a save option that shows the filenames of already existing saves to easily know which one to overwrite: And the answer to that is: no, stock does not give us a quick and easy way of overwriting existing saves, not in Esc menu save nor in the named quicksave. You would need to first check the load / named quickload menu to pick a name, then esc out of that and call up the save / named quicksave menu and type the name manually (and make sure you don't typo). I don't know of a mod that adds this functionality either.

My apologies in advance for not being able to do this in each of your respective languages individually. Hopefully you will understand this enough to participate. In the KSP Weekly (formerly known as Dev Notes) of 2016-Oct-21, @SQUAD mentioned the following: Notice the last part I marked bold. There has not been much response to this in the thread itself, and I have not seen any formal/official inquiry from Squad anywhere in the forum. I don't want Squad to get the incorrect impression that there is no need for KSP to support other languages. So I decided to start a poll here in the International section of the forum. Let's use this to let Squad know about our localization needs and wants. The above does not specify if they mean a translation of the texts in KSP, support for other characters sets, or support for other keyboard layouts - localization normally means all of those, so let's talk about all of them.

Don't spend too much an effort in redoing spreadsheets or calculator thingies, you might end up having to doit all over again shortly:

Creo que valdrá la pena esperar un poco más a ver con qué salta Squad. En las últimas notas justamente han dado a conocer que una de las (pocas) cosas que últimamente han estado haciendo es un sistema de localización. No vayamos a meter un montón de esfuerzo en hacer algo que ya se está haciendo dentro del juego mismo...

Do you happen to have a KerbNet window open and auto-refreshing at the time this is happening? I think the first auto-refresh is 7 seconds by default, and it can cause a slightly noticeable hiccup every time for some people/configurations.

You have a bit to go. Back in 1.1.2, in a mod testing install: patchedNodeCount = 41372

@Thomas P. How does this relate to the localization effort mentioned by Squad in the last devnotes KSP Weekly: Whatever they are planning/doing, it appears to include the hooks needed to also allow localization of mods.

That's ok, my child, you are on the path to recovery by confessing your sin. Go download 1.2, explore the new options, then maybe browse through the 'challenges' section of the forum and try a few of them that appeal to you. You don't even need to do it to post a competitive entry, just to see what you can come up with. As a Matrix fan, I often set out to deliberately do a challenge with a whacky out of the ordinary design, just to see what I can make KSP do that defies what one expects from 'physics'. Watch the following video, and imagine for a moment that Morpheus is trying to teach you how to play KSP :

Yep, that is the whole trick right there. Just in case I did test this too, but even cheating in the full facility upgrades, it didn't unlock the autostruts. So it's really just that one tech node.

It's possible you didn't enable 'Advanced Tweakables' when you started the career save. This is saved in the game save file somehow. It can be re-enabled in the game settings while in the game. BUT: I found out while testing this with a new save, that apparently if you ever started the save without the advanced tweakables on, autostruts will NEVER show again in that save, even if you re-enable the advanced tweakables after the fact. Never mind me, I didn't go far enough into the test career save to notice this, @DD_bwest had it right: General Construction is the tech node that contains the regular EAS-4 Strut Connector. Apparently this is what the game uses to decide to show the Autostruts tweakable in the menus.

The priority numbers let you program which tanks will be emptied first. The higher the number/priority, the earlier they will be emptied. Note that when the numbers are negative, a higher priority is shown by a 'smaller' negative (closer to zero). The green wavy line at the moment does not change direction with how the fuel flow is programmed, so just take it as informational to show which tanks a particular engine can draw fuel from.

@rudi1291 Ok, after testing a bit further, I found the source of the error: the inclined apostrophe you use in 'you´re' in your description field is giving the conversion error. @katateochi, take note, apparently it's a character that needs special treatment.

I like the idea of antennae being vulnerable and there being circumstances that would destroy the delicate construction if deployed. Three things I do not like about the way it currently works though: The only antenna that is supposed to be resilient enough to open in atmospheric flight, the 16-S, is also the single one that has been arbitrarily deemed unworthy of stacking. Which means that there is not a single combination of antenna we can put on our atmospheric craft that are capable of long(er) distance communication while in flight, 500k is it. And remember, Kerbin isn't the only body that permits flying in its atmosphere. The current mechanic does not account for circumstances that would perfectly allow some antennae to open and function without getting destroyed. If I place a regular Communotron 16 on the aft side of a nook of my plane, pointing straight backwards, where it is always aerodynamically shielded from both air pressure or heat, it should be able to deploy and function without damage despite the plane being in flight. In fact, while the warning that the antennae may break is appreciated, it should still be my choice to deploy it if deemed necessary, even at the risk of it breaking. The whole mechanic is not optional.

@rudi1291, I tried the craft. I got an error when trying to upload it as downloaded, warning about a ASCII to UTF-8 conversion error of the character 0xC2. This made me suspect the description field - the description field is handled very weirdly by KSP and needs conversion before it can be read/uploaded correctly. I checked, you do have a very long description field on this one. I deleted it entirely, and it uploaded without a problem right away. My suggestion, copy the text of the description for now to some place, upload the craft with an empty description field, then edit it into the web page directly. When @katateochi checks this evening he can then see which specific character included in your description (or maybe it's the length) is causing the problem, and I'm sure he'll be able to fix or check for it in a patched version.

https://kerbalx.com/ is a pretty good site, and it just recently comes complete with a mod you can install that allows uploading/downloading/updating craft files right inside the game. Not much help on your actual question... still trying to figure that out for myself.

In today's KSP Weekly (devnotes):

I keep going back and forth on this. I chose to start my career with CommNet on for a bit more challenge, plasma blackout on, and occlusion a bit higher because the visible lines clipping into the surfaces bother me more than the slightly more realistic allowance of refraction/reflection. I do want line of sight to matter for transmissions, but not needing signal for control, because I feel probes should be either fully capable of performing pre-programmed maneuvers or fully independent AI anyway, neither of which are proper options in this implementation. The limited control feels too much like a forced game punishment mechanic to me, I'll never play with that on. On my sandbox game, I have it all off because the fun to bother ratio is not really favourable, and I find that it doesn't really feel like I'm missing anything. But going back to career, I am happily planning and setting up relays. I'm so glad it's optional.

I still want my 1.2.3 ...