swjr-swis

I think it's way past putting that one back into the bottle...

There really shouldn't be much to study about it - it follows your build, so it's mainly your own techniques. The main exception is that I used 2x 3-way symmetry all throughout the lifter, which seemed like the natural way to achieve your stated behaviour. With using symmetry comes the structural side benefit of auto-struts linking in symmetry as well, which allows minimizing the use of external struts. Almost everything else is a copy from your craft. I left all fuel flow priorities exactly as default, making the fuel ducts the only parts responsible for the desired asparagus flow. It works exactly as one would expect and how it always used to before they made the fuel flow changes - the ducts bypass the crossfeed separations allowing multiple sets of engines to feed off the tanks that will stage off first, so the craft always has full tanks left after every staging event. And since they do this with one-way flow only, the engines cut off automatically when the stage tanks are empty, which serves as a cue to stage. The comms set is a fudge and a bit of an afterthought. I wanted to add comms and relay capability (motherships generally need both) but without significant changes to the rest of the craft to accommodate it, and the result isn't exactly pretty. 4x RA-2 + 2x 88-88 pointing outwards from inside a 2.5m service bay, placed between the bottom center docking port and the orange tank, would have been a better solution.

Drilling for oil may have unexpected results though. (Picturing the planet suddenly shooting away and flying in random patterns across the solar system as it slowly deflates )

The entire upper crust of Kerbin consists of highly compacted kerbal and craft remains dropped from the skies, after aeons of constantly trying to get to orbit. Iow: Kerbin is quite literally made out of compacted Kerbal droppings... (just one theory)

A few separate points that didn't seem to get answered: The part you used to fit the clusters of LV-N engines below the X200-16 tanks. The game assigns a lot more drag to them than one would expect - if your ship/PC can take the part count, it's almost always better for drag to avoid them altogether, and place engine clusters through the use of radially attached nose cones. In your craft though, you also picked the 1.25m-to-4 adapter (TVR-2160C), which means there is a node mismatch between the tank and the quad-coupler - adding even more drag. In the rebuild I posted, I replaced the quad-coupler by the TVR-400L, so at least the nodes are matched. I tested with the radiators disabled: I did a continuous full throttle burn of the LV-N stage and burned through the entire fuel without a single heat warning anywhere. Heat does not seem to be an issue anymore, so you may be able to do without them (or replace them with the smallest ones). The only thing I could think of that I did not test is how it fares when burning much closer to the sun. The way symmetry is forced by the stock game, it won't let you override an already existing symmetry in a stack other than placing things from a certain point individually. In the case of this craft, I think it works best building the entire lifter with a 2x3-way symmetry, and then place the payload individually - ensuring balance/symmetry manually. Which I think is very doable. If you still plan on adding ion drives as well as nukes (which I don't think would be very efficient, mind you, but don't let that hold you back), I would suggest using fuel cell arrays instead of a large number of solar panels. You are lobbing a huge unused capacity of LFO (the nukes do not need the Ox!) tankage into space, and fuel cells could use a fraction of that to cover all your EC needs, including powering the ion drives. Note that even though the Gigantors can theoretically provide more EC per part than the fuel cell arrays, typically you won't be able to get all solar panels to generate optimally, and the farther from the sun you get, the better the fuel cells will do in comparison. Consider configuring the fairings to 'clam shell' mode, with a bit more than the default force, lower the segments to 2, and rotate the fairing such that the parting line is diagonal across the lifter lattice - the two shell halves should then part to the 'sides' of the corner and never touch any other part of the craft. Actually, you can. I can think of two methods: More parts and less 'cheaty' for those who have strict no-clipping policies: cubic octagonal struts let fuel flow through - so simply attach one of those to the side of the decoupler below the engine, then run one fuel line from the lower tank to the strut, and one fuel line from the strut to the top tank. You may need to gizmo translate the strut a bit to make them connect well, then translate back after they are connected. Less parts, less drag: with the translate gizmo, first shift the engine a good bit aside. Place a single fuel line from the top side edge of the lower tank to the lower side edge of the higher tank. Now with the translate gizmo again, hit space to reset the engine back in it's default place. The fuel line may visually clip a bit, but for the game's purposes it is connected properly between the tanks. You can even hide the fuel duct entirely if you so wish with the translate gizmo, even moving it to where it literally passes through the center of the decoupler and engine - it will still work. Just remember it's there, and if you ever reconnect the stack, you may need to redo the fuel ducts.

After reading through this thread and seeing the above, I felt I couldn't let this be the end of the long illustrious career of the Aquila lifter. Especially because I agree with your statement here: even though fuel flow did change in significant ways since 1.0.5, the good ole traditional asparagus staging should still work exactly as one expects it to. So, with that in mind, I did a rebuild from scratch of the lifter in 1.3.1, using your shared file as example. Then I copied the rover payload from yours as a subassembly and placed it on the lifter (with a few minor tweaks - antennae added and wheels/fairings slightly redone to prevent the wheels from blowing when the fairings are staged). My resulting craft file is on the dropbox link below. https://www.dropbox.com/s/ja08gr8cy28aheq/Beach Head B 131.craft?dl=0 I couldn't get your original craft to work quite right simply by editing it - I suspect a combination of broken symmetry and some save error sneaking in during your previous edits. I decided it would be faster to rebuild it from scratch instead of trying to debug the issue. It's not identical... I did do a few things differently, without -I think- affecting its overall concept and personality. The in-game description text should list all differences. But if I understand you correctly, I think it now works the way you wanted it to, with the 'traditional' asparagus type of fuel flow, automatic engine cut-off, and staging. You'll have to let me know if it proves a worthy continuation of the dynasty. Long live Aquila VIII.

You could try the procedure described in the link below, which allows changing the 'friendly name' of each device (the name shown in the control panel/device manager). But this will only work if KSP also refers to the joysticks by that name... I don't know if that is the case. Warning: note that it requires using regedit, so take precautions to ensure you can undo what you change, just in case (save the registry keys you're going to edit, make backups, take notes, etc) https://www.avoiderrors.net/rename-devices-device-manager/

Hi there, welcome to KSP and its forum. I understand most of your points - from the point of view of a new player, there are definitely some less than intuitive things about this game. Squad has done a lot in recent versions to improve on that, adding better descriptions, more tooltips, a KSPedia, tweaked/improved tutorials, and more/better UI controls. But you're right, there is still room for improvement. A few tips that may help you enjoy the game in its current form (without in any way diminishing your observations): First: visit this forum, it's an amazing resource of all kinds of information that would otherwise not be obvious if tackling the game by oneself. You'll find that despite a bit of grumbling every now and then, this community is pretty amazing and very helpful to new players. Feel free to ask questions - you'll find that most if not all of the things you might run into have been encountered by others as well, and you'll get quick solutions or workarounds offered in no time. About your 'most annoying thing': there is a little-advertised way of adding a permanent waypoint for the KSC in the stock game, through the debug console. From the Tracking Station (or while controlling a craft), call up the debug menu (mod-F12, where 'mod' is Alt on PC), and on the console command line enter the command '/ksc'. From that moment on, you'll have a waypoint in your game centered on the space center area, which will help to navigate. By default it only shows on the map/tracking station, but when you rightclick on the waypoint marker it allows to 'activate navigation', which will also show an indicator on your navball (four blue arrows pointing inwards). I add a few screenshots to clarify in the spoiler below. You also mention having an issue with the darkness on the map and inflight. This can be changed in-game to your preference, by using the three 'Ambient Light Boost' sliders in the settings (one for inflight, one for the map, and one for the editor). In-game you can find them under the Esc menu, Settings (scroll a bit down). See the screenshot below. For locating the runway from a plane, I do what @adsii1970 suggested, with a little addition: instead of just one flag, I plant two of them, one at each end of the runway. With two flags, besides simply finding the runway, you can also use the markers as visual aids in aligning with the runway direction - just keep them overlapping as you approach and you are pretty much perfectly aligned for landing. Just remember to place the flags a bit beyond the outer edges of the runway (which includes the slope down to the flat KSC terrain) - otherwise the game will keep complaining that there is a 'craft' already on the runway. Keep playing, and keep posting your observations.

Why does this setting even exist? Genuine question.

Logs and pics would help to diagnose this, no argument. A few possible causes to consider perhaps: Zoom level (mouse scrollwheel) - seems very unlikely, but easy and quick to test FoV level (Mod + mouse scrollwheel) - not many people fiddle with this. A bit more likely, also easy and quick to test. Different widths of (virtual) screens might have slightly different effect on this The 'FEMALE_EYE_OFFSET_' variables in the settings.cfg of KSP. If those were tweaked manually -or through some other mod-, they may be causing the eyes to show in front of the camera plane

It looks interesting, definitely going to keep an eye on it. The earlier videos do seem to show similar gadgets and visualizations as KSP, but it's obvious in later videos that it has moved away into a more distinctive look and feel. Considering the early stages of development, it's not really that surprising seeing 'shortcuts' or 'mockups' used based on things seen in other games - why waste time working out very detailed controls when one is still figuring out how to make the basics work. As more and more of the basics are fleshed out, more attention can be given to more distinctive UI features (and more ideas come along about how to do it 'better'). It doesn't seem to me at all like anything nefarious is going on, especially as there is a clear evolution showing that makes it less and less like KSP as later videos are published. Similarities may be explainable as simple as the fact that both are being developed on the same game engine, and there really only being so many ways in which one can visualize certain things in a simple easy to use manner: how many ways can one represent a 'cursor', or a 'menu', or a 'pull-handle', or a force vector... before you go from functional into ridiculous. The plan seems rather ambitious: to include all kinds of engines, vehicles, and mechanics, land, sea, air and space. If they can achieve this, this could be a very interesting game. I do like the procedural parts and the engines-from-components design, which seems a logical continuation of the craft-from-components mechanic. Nicer graphics (in part, but then it's still early stages), and potentially nicer sound (a bit on the fence on some of the sounds and effects... I hope there's still some evolution to go there and that some of it is made optional). Weaponry stuff... meh. I like the attention to detail and mechanics of it, but it's not something I'd do much with. The one thing that caught my eye was the wind speed and direction indicator on the lower right of the screen. I couldn't tell from the videos if it had any real effect on the planes, but it is interesting that it is being considered/included. All in all it seems worth keeping an eye on. I don't see it displacing KSP, but I can see myself playing it alongside it. Just like I've played different FPS, RPG, RTS, simulators and sports games right alongside one another. The more the merrier.

I am pretty sure eclipses have been a regularly happening 'thing' in stock KSP for a long time now... (screenshots made in KSP 1.1.2)

En stock no se puede marcar como objetivo, porque no hay ningún objeto a marcar. Lo que yo hago es usar un avión que se controle bastante estable, volar hasta acercarme al area, y una vez a la altitud requerida y fuera de riesgo, cambiar a modo mapa y dirigir hacia el punto marcado. Me suelo facilitar el asunto escogiendo solo las misiones que piden volar debajo de cierta altitud... de esa manera casi cualquier avión/aparato vale y no importa mucho si no mantienes altitud antes de llegar a la marca. Se complica un poco si aceptas una misión que requiere volar por encima de cierta altitud, o peor, entre un mínimo y un máximo (muchas veces requiere un avión bastante bién diseñado y control), especialmente cuando la carrerra no está muy avanzada o si no se te da bién el pilotar un avión. Cuando queda cerca del CEK, a veces he diseñado un rover mini-VTOL - me coloco directamente debajo del punto marcado a ruedas, y entonces me elevo verticalmente hasta que se me completa el objetivo. Tiene su gracia, pero recomendaría hacerlo a modo avión. Me ha engañado el foro - no me dejó ver tu auto-respuesta hasta después de responder yo. Creo que no he entendido lo que preguntabas, porque no me suena para nada el efecto del botón derecho en este contexto...

@tigreton, te recomendaría que ANTES de este último paso, primero le des otro nombre al 'persistent.sfs' original, para guardarlo por si las moscas.

The new model/texture switching ability that is being added to the stock game in the next version might be a good method of doing this with just a single part.

I'm a bit disappointed: there's a distinct lack of hand-crafted white vest in that success banner.

Interesting. Could be a test for a new filter to stop (ab)use of the site for something other than its purpose - which would be fair, since KerbalX is for sharing craft files, not for a personal message/advertising board. Or it's an artifact of those non-craft uploads - the uploader may be manually editing a bogus version into the files, and kat's clever coding is just adding it to the filter list automatically. Either way, since there's an obvious repetitive pattern, I would say those pages are risking getting filtered out or even banned. Hopefully it won't need to come to that.

The functionality of this mod was added to stock a few versions ago, afaik. Menus do no longer move with the parts, and can even be pinned individually now.

Well, seeing as all stock command modules have that internal antenna, I figured why not, that way it's up to date. Credit on the release page is fine, all I meant is I assert no rights whatsoever (to appease the forum mods). I noticed I left my name in the comments of the cfg file; that was meant to be temporary while editing, to quickly find back what I changed in the editor. Please remove those before publishing it (I didn't really create those sections anyway, they are straight copies out of the other Squad part files). Hmm, I just noticed a message at game load saying it can't find a texture... without specifying what texture it is trying to find. The model loads properly, the lights toggle on and off (even with my icky glow texture)... which means it loads both the part texture and the emissive one I made. Anyone know why it complains, or how I can figure out what other texture it is trying to find? Never mind, I already found the error: Blender (read: me fumbling about in Blender) added a third but empty texture entry into the model - due to it being empty, it doesn't show it's there unless you happen to click in the empty space below the second texture. Once deleted and re-exported, KSP no longer complains.

I was already on it, you can find my first (very messy) result on this dropbox link: https://www.dropbox.com/s/143dile5o305d9b/Mk1PrototypeCockpit.zip?dl=0 The texture can definitely be a lot better, but you mentioned you can do textures, so feel free to improve or redo it entirely. The zip also includes the Blender and Paint.NET source files, for what they are worth. Take, use, edit and share at will, I reserve zero rights whatsoever.

I found this on the cupola... it looks like this might work without requiring a compiled animation. I'll give it a try.

Disclaimer: I am talking from an almost zero experience position here. I have taken a stab at this in the 'stockiest' way I could think of - I imported the existing texture into paint.net, saved it with another name in paint's native format. I had to correct some artifacts from the lossy import (bunch of white pixels along edges), but could then relatively easily create a second layer to paint all black except for the parts that I want to glow. I then saved that new layer as a dds. I then fired up Blender (at this point you're thinking 'ok, he used Blender but not GIMP, what an idiot' but I prefer the dds results from paint.net - with a plugin - over those of GIMP) and used the Mu importer to open the model.mu of the cockpit. I also imported the current Mk1 standard cockpit so I could compare them and see what needed to be changed. The differences I've found: Editing the cfg is easy enough, I used the current standard Mk1 cockpit as a guide. The shader in the old cockpit is KSP/Diffuse. The current one uses KSP/Emissive/Specular. This can be edited in Blender. The shader has a bunch of color properties defined in the current one that sound related to the glow effect (eg. _EmissiveColor, etc). This too can be edited in Blender for the old cockpit. The current cockpit mu has an animation defined somewhere, which I presume is what causes the gradual transition from off to on and back when toggling the light. However, I have not found this in Blender yet. I don't know if that is because I'm not looking in the right place, or that it cannot be edited with Blender (seems unlikely), or maybe the import plugin doesn't import animations. I'm leaning towards me just not looking in the right place and hopefully someone can point me to it. If the cause is that the plugin doesn't do the animations, then I am stuck, because even if I could add such an animation with Blender itself, if the plugin cannot export it it won't be in the mu file. With the first steps done, and the mu exported, I loaded up the game, and it gave me an exception when trying to toggle the button (which only says 'Toggle') and no glow happened - obviously because the animation the button wants to trigger doesn't exist in the mu file. Long story short: I think it can be done 'stock' just by editing the cfg and editing the mu file in Blender, but someone would need to explain where/how to add the gradual glow animation. I get the feeling I am simply not looking in the right place to find it from the current cockpit, but it could also be that the Blender plugin simply does not 'do' animations, in which case it would require some other tool (Unity editor?).

A fuel station I made back in 1.1.2. The fuel storage core is 14x Kerbodyne S3-14400 tanks in a star configuration, topped by habitation modules (14x30=420 max kerbal capacity). Total fuel capacity, including the pods = 156k units of LF, 149k Ox. The hab modules could all be decoupled in the event of an emergency, capable of independently performing deorbit, reentry and powered landing back on Kerbin. The staging shown in the editor was later changed, as decoupling all pods simultaneously was a guaranteed explosive event that damaged several pods beyond recovery. Keeping a single pod out of the mass abort event (and decoupling it by itself a second later) was enough to avert explosions. Somehow it seemed appropriate to let the captain's pod eject last, so I considered it an acceptable solution. I also uploaded some screenshots of my attempts at getting this thing into orbit fully fueled and in one piece. Proper 4am Kerbal engineering which I termed the 'Cathedral Method'. Lesson learned: skipping sleep to finish building a complex craft can have... well, less than optimal results. Part count of the final version -with a lab ring, ore tanks, tug, and the lifter- was around 1600 (860 without the lifter), with abysmal performance, so I never shared it. But the station itself was very stable in orbit, I never saw any undue oscillations or random explosions, and I had 4 of them in LKO at one point, although one was sacrificed in a test of the mass evac procedure and pod recovery. My OFDs in later careers were a lot smaller and more sensibly shaped, but always based on the largest Kerbodyne S3 tanks - it helps keeping the part count down.

There's a forum thread detailing easter eggs: The one you mention is listed there too.

That is a function of the Steam overlay, or the screen recorder software. NVidia has it in Geforce Experience/ShadowPlay as well. Steam: Settings, In-Game, In-game FPS Counter (will let you select from four positions on the screen). NVidia: GeForce Experience panel, ShadowPlay, (enable ShadowPlay), Settings, Toggle FPS counter on/off.