swjr-swis

Bill: <reads suggestions, does some numbers> Bill: <notices more suggestions, with other numbers, recalculates> Bill: <notices even more suggestions, with yet other numbers, recalculates again> Jeb, Val and Bob in unison: "Oh heck, just fill 'er up and let's go!"

Fixed that for you.

"The Kerbal Space Program community has been abuzz today (...)" Exqueeze me? What buzz? Where? I see no indication of any buzz whatsoever in our forum. . . . . . Oh wait... he means reddit.

Like I said, I recognise this. It's always easy to spout ideas when one is not the one to do the work. So never mind, it seems to be just me anyway daydreaming about the potential of this model. If I ever decide to use it, I can clone and modify a vector to suit, slap six over the main engine nozzles, disable the main engine, maybe clip one or two ore tanks in to shift the CoM, and make the thing do exactly what I envision. More part heavy and losing some of the aesthetics and efficiency, but it'll work for me.

If you want to confine the lander to that single use case only, sure, go ahead. How much use is it going to see in that capacity? I really like the model of the lander, it's obvious a lot of effort went into it and it looks great... feels like an awful waste to not give it a bit more flexibility of use. But hey, that's me.

DLC would work. DLC can only be from Squad, after all, or it would be a mod. Stock+ could be interpreted in all kinds of ways that do not necessarily equate with 'only parts from Squad'.

From your picture it would seem you have staged, you do have control, and you have EC and LF, and I see no mods... so if it's not simply that you forgot the throttle: check whether you have a stuck/sticky CTRL or X key - maybe your keyboard is killing the throttle intermittently. What may help as a quick workaround: rapidly hit the key multiple times. But you may need to dismantle and clean under the key if it keeps sticking.

I like your enthusiasm and initiative about this, but I think you're forgetting option nr 3: Wait until the the darned thing is actually released and reviewable, see what kind of files it produces and what handholds it offers to work with, and then design and build something based on hard facts. Right now speculate is ALL we can do. They have given us nothing tangible to work with, other than telling us what it's NOT going to be: supposedly, it's going to be nothing like contracts. Which leaves us still knowing... nothing. Heck, even their own user interface is still in mock up. What exactly is the worst that will happen if there is no 'mission-sharing' option on KerbalX from the absolute day 1? People will use dropbox or equivalents and place links in forum posts. Which a lot of people will do anyway even IF KerbalX had something ready and 100% functional from day 1, and a group of people will keep doing it that way anyway. You (calmly!) work on it and announce your new feature when ready, and in no time at all KerbalX is the default site for mission-sharing and no one even remembers it ever being different. Instead, by trying to avoid the above 'doomsday' scenario, you're going to be stressing yourself out over way too little workable information and then almost 99% guaranteed prepare something that will still not work right, if at all, from day 1, then stress even more for the next week while idiots complain how it doesn't work, even though it'll likely take weeks before anyone even gets familiar enough with the mission builder to put out stuff they'd be willing to share in the first place! <deep breath> Sounds like setting yourself up for failure and bad feelings all around. It's not my call of course, but I say wait until you have the facts in hand, and don't stress over not having something from day 1, or even for a while after release. It's not even important whether you're the first with it. We all remember what happened with craft-sharing 'competitors' that were going to do it all grander and better and faster... oh that's right: they've silently gone nowhere, I don't even remember the site names anymore. Save your creative muscles for when you have a base to unleash them on. With your track record of service-minded practical work ethic, I have no doubt you'll deliver, it'll do what it needs to do, and KerbalX will become the de-facto mission-sharing site, just like it has for craft files. And all we users will need to do is have a little patience for a time, time that will probably pass unnoticed while we get to grips with the released mission builder. Peace, man.

A known issue that sometimes randomly crops up while editing craft; symmetry gets confused somehow, is saved to the craft, and from that point on they act weird. It happens more often when control surfaces are near the CoM, the point where the engine flips around how the surfaces deploy - flaps are usually right about at that point. Two solutions: In the editor, deploy them, then with the offset tool move each of them a notch back and forth (so they end up again where they were). Most times, this is all it takes to make them both deploy to the same side again. Sometimes that doesn't help though, and all you can do is remove them entirely and replace them with new ones (not even just detaching and then placing them again - for some reason, sometimes they remember this weird deployment symmetry even when detached).

¿Te has fijado si estás usando la simetría de modo 'espejo' (el círculo grande al fondo izquierda)? Tiene que estar dividido en dos con dos cuadrados. En PC, si no lo has cambiado, 'R' alterna el modo de simetría entre radial y espejo, y 'X' los grados de simetría - en caso de espejo, solo 1 o 2. Aparte de eso, intenta colocar las ruedas en el centro del lado, y después las puedes desplazar al lugar correcto con la herramienta 'Move/Mover' (o pulsa '2', como dijo Noobton). El editor trata algunas piezas rectangulares como si fueran curvadas, y si intentas colocar piezas alejado del 'centro' (*), introduce un ángulo. (*: Centro entre comillas, porque hay piezas donde el lugar desde donde calcula los ángulos está fuera del centro aparente de la pieza. No hay mucha lógica en el asunto, así que no hay más remedio que experimentar y aprender).

La garra necesita un poco de maña. Lo que no se dice en ningún sitio es que 1) requiere que la superficie a la que quieres enganchar esté casi perpendicular a la garra, permite un poco de ángulo pero no mucho, y 2) requiere pegar un buén choquecito, intenta acercarte a unos 2-3m/s.

Nothing to do with precession (*) - the slight difference between solar and sidereal day is due to the planet moving a slight bit ahead in its own orbit around its sun while it makes one full rotation, which causes the sun's angle to the surface to 'fall behind' slightly, which means the planet has to rotate just a tiny bit more than an exact 360 degrees for the sun to be at the exact same location in the sky. Hence the solar day (measured by the position of the sun in the sky) is always (#) a slightly bit longer than the sidereal day (measured by the 'fixed' position of the distant stars, which in KSP is effectively fixed). (*) - precession on the other hand is the shifting of the rotation axis of the planet, which does not exist at all in KSP, and in our familiar case of Earth is a very slow mostly circular movement noticeable by the stellar background shifting in the sky over the course of ~26000 years, give or take a dynasty. (#) in the most common case of a prograde rotation. If the planet's rotation is counter to its orbital direction, then it would be the other way around.

An alternative to this, if you are already considering using the Alt-F12 option: 'Set Orbit'. Fill in the parameters as required and place it in the correct orbit. The contract should get completed when you focus on the sat, and as a bonus, you also get to have the sat where it was intended to be.

A small suggestion, if it is still in time to be considered: the lander problem I think is that the main engines are integrated, and thus have a single thrust vector, on or off is all the choice we have. We can tweak the body CoM and/or CoT as is to fly well without cargo, OR we can tweak it to fly well with cargo... but not both, because adding any significant cargo at all means the CoM will shift significantly down, and either one way or the other it moves it out of whack and causes uncontrollable torque in some flight situations. A single set of CoT/CoM settings for the body is not going to solve this issue for all flight profiles. Now, if the main engines were to be separate (think three separate sets of engines/nozzles), allowing us to activate/toggle them through action groups for example, we could adapt the CoT on-the-fly to a good degree to the shifting CoM (disengage the 'lower' pair of engines when flying empty, engage them when flying with cargo). That and a certain allowance of gimbal should make it flexible enough to adapt to most reasonable flight conditions. Just a suggestion of course, I'm well aware that it means more work than a one-time parameter change on the existing cfg/model.

Fact remains you are playing a modded game, not stock, and without giving the list of mods you are using, or really any detail of your game, it is impossible for anyone to even start diagnosing this issue. You are already reaching for conclusions without giving any context at all to base it on. This is not to dismiss your report or anything, but understand that you are giving too little useful information. Start with: Version of the game Mod list KSP.log (and if available, output.log) of a game session in which it happened A savefile or a craft file where it happens Steps to reproduce (you more or less already described this) (Don't paste the files as text in here, upload them to a filesharing service (dropbox is free) and link them here.) I say to put that all here so knowledgeable forum users can take a look at it and perhaps quickly point out if it's a known problem, and if it really seems like a game issue, then a report can be filed in the bug tracker so the devs are alerted to it. If it turns out to be some type of regression, that can be added to the report. But let's first start with the basic details.

It's the KSP logo on the top right of your profile page - it links to the KSP forum profile.

I have actually wondered why there is no monolith orbiting Jool. There really should be one. To start with anyway. It would be the perfect intro to KSP Two. All these worlds...

This might give a clue: there are no stock 'cryogenic-specialized' parts. You're playing with mods. May help if you list the mods used.

..that are riding on the backseats of the scooters?

It cannot be ignored, since the dependency, which was not there before, was introduced explicitly and solely because of the fuel lines - see the dev notes quote. With the fuel lines being unavailable until the very moment the dependency is 'lifted', the change completely misses its intended purpose.

Points for the gimble gamble. Thanks for the chuckle.

I made some electroprops for my Kerman Flyer that are absolutely 99.99% reliable (the sole exception being not to switch focus to a craft, or debris, more than 2km away... the game's automatic unloading will dislodge the bearings when you focus back). It uses two bearings to stabilize the rotor and will happily run for hours without a hitch through all kinds of acrobatic flying. The design is pretty straightforward I think, all parts are placed using the stock snap positions, it needs no freeform fiddling, just a bit of extra offset allowance (settings.cfg, VAB_FINE_OFFSET_THRESHOLD, works for SPH too; I have it set to 10). If there is any interest in it I can record a video of how I assemble them. Feel free to reuse them, in this case the root part is the cubic octagonal strut which allows them to be radially attached with a lot of freedom. Speaking of which: @NorthAmericanAviation, would a replica of the Wright Flyer fit as a submission for this thread? After all, it is the quintessential experimental/prototype/tech demo aircraft. You'll find all you need to make an article on the Kerman Flyer craft page (craft file, lots of pics, several videos).

La hay: Pasa el ratón por encima de los kerbals (sea en el complejo de astronautas, en los retratos cuando ya están en vuelo, o en en el VAB/SPH cuando estás decidiendo con quién tripular tu nave), y verás un recuadro con los detalles pertinentes de los kerbals. Más o menos a la mitad del texto que sale verás un 'Log' (o Registro, en la version 1.2.9 ES) que muestra una lista de todos los cuerpos celestes visitados, y la cosa de más XP que han hecho en cada uno de ellos (porque siempre solo cuenta la de más puntuaje).

The RESOURCE_DEFINITION module in ResourcesGeneric.cfg has a 'unitCost' parameter that is used to calculate the cost of adding (or as is the case in stock, the savings of emptying) fuel from the tanks, for instance 0.8 for LF and 0.18 for Ox.

Please revert the change from 1.2 to radial decouplers (TT-38K, TT-70, Hydraulic Detachment Manifold) that prevents the 'toggle crossfeed' from showing/working on radial decouplers until one has researched the Fuel Systems node. I actually thought this was a bug because it used to work before, and all other decouplers/separators/docking ports have the 'toggle crossfeed' option at all times, including the TR18-A stack decoupler which is available even before the TT-38K. Only after searching the forum I discovered this was introduced on purpose during the 1.2 update - the rationale we got for adding this weird exception was as follows: I do not understand why adding this strange exception was considered necessary in the first place: fuel lines have their own use cases that do not depend on decouplers being able to crossfeed or not (for example, 'proper' asparagus staging requires the one-way fuel lines if you want radial stack engines to cut off when they've expended their 'own' fuel, instead of continuing to feed off the other stacks due to crossfeed across decouplers being bidirectional). But disregarding any possible explanation that I can't think of, the way it's implemented now it completely fails to achieve the intended goal, since the FTX-2 fuel ducts whose 'relevancy' is supposed to be protected by this exception are not unlocked until that exact same R&D node! In other words: the fuel lines do not even become available at all to be or stay 'relevant' in any way... until the exact moment when the 'toggle crossfeed' option on radial decouplers is unlocked; which according to the logic used to introduce this change, makes them immediately 'irrelevant' as soon as they are available. So, hereby a heartfelt plea to please undo this weird exception that obviously does not actually do what it was intended to do (while adding limitations to the possible uses of the early radial decouplers). Alternatively, if reverting this change is absolutely out of the question... at least move the FTX-2 fuel ducts to a much earlier node (I suggest the same node as the radial decouplers, since them not allowing crossfeed yet would be the main use case for the ducts), so they actually have a chance at 'being relevant' during some time until the radial decouplers are deemed worthy of 'toggle crossfeed'.