swjr-swis

Main argument is that standards/conventions are good in community efforts. KSP modding is a very lively environment, with thousands of mods by now, and almost anyone can go ahead and create a mod. We need to cherish any standards we can manage to agree on... as the workings and compatibility of all our mods can and will sooner or later depend on them. Note that I'm not criticizing the decision to relocate HyperEdit's data files - I think it's a good idea. My remark is just about the chosen location. The general convention for mods, for a while now, is to use the GameData/Mod/PluginData directory for mod data files. This has slowly been replacing the older convention of simply placing data files in the mod's main directory or an arbitrarily named subdir of it. Using GameData/Mod/PluginData, all the mod's files and data can be found in the mod's subdir, which makes it easier to archive a mod and later reinstall it with all it's data/settings intact (just zip/unzip "GameData/Mod", and you're done). Removing a mod, since it affects only its own directory in GameData, should never affect any other mods (barring any hard dependencies of course). The use of the GameData/Mod/PluginData directory I think was initially prompted as a way to exclude certain mod-specific *.cfg files from being incorrectly processed by Module Manager as MM patches. In other words: placing files there is akin to publicly stating "enter at your own risk - these files are only intended for this one mod alone". One standard named subdir to skip is easier to code for. I don't know of other mods than MM that scour the entire Gamedata tree for files to process (maybe texture optimizers/replacers?), but if one mod had reason to others may follow, so it's worth keeping in mind. On the other hand, using the root PluginData, while seemingly even easier to code (literally just one directory), actually makes things more complicated: that directory would be shared by all mods (there's only one PluginData at the KSP root after all), so extra rules would need to be agreed on -and consistently followed- to ensure mods leave each other's data alone. The very real risks of filename conflicts and overwriting each others' data have to be considered. A very simplistic example: 'readme.txt' or 'settings.cfg' are commonly used filenames - in a mod's own subtree, this is very clear for authors and users and never an issue; but in the shared root PluginData, the last installed/saving mod would overwrite all others that use those same filenames, leading to all sorts of potentially hard to diagnose problems. Also, removing/archiving a single mod would need one to look in two places for all its files, and again the risk of affecting other mods lurks - users would need to be very mindful of which files from that one shared directory to remove. More support issues may ensue, and more detailed add/remove instructions would be required for mods. Aside from the above, up to now the root PluginData directory has been empty and unused for many versions, like several other directories the game (re)creates in the root - an historical coding remnant that KSP has long ago moved away from. You're basically necro'ing a long-dead directory, and as we all know, mods frown upon necros (). Seriously though, I think I'm not the only one that keeps hoping Squad will finally remove those vestigial root dirs permanently, for everyone's sake.

At the risk of being a lonely (and rather irrelevant, as a current stock player) voice: is there any way to reverse this decision? We had accepted those root directories being nothing more than vestigial remains that can be safely assumed empty and useless; any actual plugin data being contained in the plugin directories themselves is as close to a standard as we have seem to come with KSP modding. Why break convention? Why force players to now have to consider that mods may choose other places to store their data - potentially causing file overwrite conflicts if more than one mod decides to place a similar named data file in that one root dir?

Which one? There's the very obvious 'Crater Rim' that lies mostly submerged in the ocean, only touching the continent on one side. But there's also a much older impact 'wound' of bigger diameter that is entirely inland on the continent at the opposite side of the planet.

That quote mark may be the issue. Can you paste the entire text that is the 'Target' field, just so we don't have to solve this one character at a time? The options should be outside the quotes. The quotes are only needed in case the path to the exe uses special characters (or a space), but the options need to not be quoted.

There should be no space between force and d3d11.

I try to standardize, because I use action groups a lot, but the stock 10 is just slightly too limited to be able to stick to a consistent standard. I keep hoping they'll add Mod-number to the action group definitions, so we can have an extra 10 actions in stock. It also slowly evolves over time, depending on what type of craft or missions I find myself doing a lot, and on game features appearing in updates - like the new 'Control from here' option we have now, which can come in very handy for stock VTOL craft control or spaceplane reentry attitude control, so it's likely going to be displacing one of the existing groups in the near future. My current standard seems to be the following: General set for spaceplanes: toggle flaps / toggle engine mode toggle engine mode / toggle engine group 1 toggle engine on/off / toggle engine group 2 payload action 1 / toggle science instrument readout and covers payload action 2 / take science readings and crew reports payload action 3 / delete science readings and crew reports payload action 4 / collect all science data toggle antennae, solar panels, radiators toggle cargo/service bay doors toggle ladders General set for rockets: toggle lower stage engines toggle higher stage engines toggle OMS engines payload action 1 / toggle science instrument readout and covers payload action 2 / take science readings and crew reports payload action 3 / delete science readings and crew reports payload action 4 / collect all science data utility 1 / toggle antennae, solar panels, radiators utility 2 / toggle cargo/service bay doors utility 3 I also edit the default groups - I like my craft window illumination to be on at all times, so I always remove those from the lights group; I often add paired control surface deployment to brakes to serve as airbrakes; on atmospheric-only craft I sometimes use the RCS group for flaps if I'm short a group for engine actions. Did I mention my hope for an extra 10 action groups in stock, by allowing Mod-number as assigned keys? I know there's a mod to add hundreds, but I can count on one hand the times I've had true need for more than 20 action groups, yet I am constantly short 1-3 groups to really do all I want with a craft. Having just one extra set, by using the mod key, would solve the issue for almost all situations for me.

The official ES translation of the game itself uses those characters extensively, so the characters do exist in the game fonts. I did notice that if I ask to edit the file, github gives me the following warning: I don't know which encoding is the correct one, if any, nor do I see any option to select or change the encoding. So I'm not sure any PR will have the desired effect if github decides by some uncontrolled means to change the encoding again.

I checked the github... the es-es.cfg file uses the correct characters. Whatever is changing those characters must be happening in the compilation step.

Agreed that help requests should be in a separate thread (which I think was already done). But: The OP does rather specifically declare this thread immortal - not sure necro applies in this case.

La consola deja ver el log en vivo, y el GUI de datos termales muestra detalles de temperatura, insolación, etc. Ambos se pueden encontrar en la pantalla debug (Alt-F12).

Hola Novak. No estoy seguro qué ayuda puedo ofrecer, ya que por ahora juego sin mods. Además, las capturas que has subido son de bastante mala calidad - no reconozco casi ninguna pieza, y el texto no se puede leer. ¿Donde se encuentra la nave? ¿Y tiene alguna pieza integrada que genere calor? Lo único que veo, en la lista de mods, es que incluye Kopernicus, lo que me dice que posiblemente tengas los parámetros del sistema solar modeados - quizás una estrella o planetas diferentes. Si es así, eso sería el primer lugar donde yo buscaría la causa - por ejemplo si la estrella ha sido adaptada para radiar más fuerte que Kerbol, podría ser la causa del recalentamiento. En el log, ¿te dice qué pieza es la primera en explotar? Eso puede ofrecer una pista.

Just install the paid version in another folder. KSP does not care about multiple installs, you can keep them (and use them) independently as long as you want. And it would be safer, as this would leave the old demo saves and craft files intact for you to return to in case of incompatibilities. When you're happy with the new install, and are sure you have all your save/craft files, you can remove the demos without it affecting the paid install. EDIT: as soon as I posted this, I noticed you specifically ask about updating the 'free version', whatever that means. I don't know of any free installs other than the demo, so I can't help with that.

In a game as versatile and open and moddable as KSP, 'cheating' can be defined by so many different things and circumstances and opinions that it's an almost meaningless word. Just take a stroll in the challenge section of the forum to see this in action - challenge descriptions often need a page of 'by-laws' to more accurately define the context and so avoid what the OP personally considers to be cheating, and even then there are regularly submissions that force the OP to amend/expand the ruleset. What is cheating really, in a simulated environment that intentionally and unintentionally bends the laws of physics? Where 'reality' can literally be reshaped at whim, by the choice of mods to install (or files to edit). It's all incredibly relative. Intentionally deviating from the listed parameters of a challenge is about the only thing I truly consider cheating, so I avoid that. In career saves, everything is self-imposed anyway. I do try to limit editing - debug menu or directly - to either the very start of a new career (setting that career's defining parameters, if you will), or when some game bug causes damage that would be too much trouble to fix by normal play. It's all fair play as far as I'm concerned. I play this game for enjoyment and education, not for punishment or tedium. There are limits to how much time I'm willing to invest in a game (yes, despite having sunk over 10k hours into this one already), so if something happens that would feel like a waste of time, or somehow ruin my enjoyment of the game, I will fix it by any means to my disposal. Ultimately, I would be 'cheating' myself doing otherwise.

Technically, the OP states it ended yesterday, so any further entries may not get on the score board. But I don't think anyone is going to complain if you show us what you got.

Check if you have your R&D center upgraded to level 2 or higher. If R&D is level 1, it will not allow resource transfers.

Type the '@' then a forum name - the forum will show a drop down list of possible matches as soon as you type the first characters. Then you click the one that you want. That's on a desktop browser. No idea if it works in a mobile one.

Can I ask what flight profile you used to get your record distance? The cabin of my FleaC'er is basically a lighter less draggy version of your craft, and even exchanging the fins with your winglets (which are a bit worse than 2x3 basic fins), the max distance I got in several attempts with a vertical launch is 301km. Theoretically it should perform better, so obviously the problem must be my flying - which tells me that if I knew how you flew yours, I could maybe improve the distance I got for the FleaC'er too. So, I'm curious. (It's fine if you wish to keep it a trade secret, but I figured it doesn't hurt to ask)

Feels good, dunnit? Nothing quite like coming up with a fitting solution to a problem posed. When things start to just click, and stuff works the way you want it. You're hooked now! One question: is it possible you posted the wrong craft? The Peregrine is a different type of plane than the Aquila Ursa in the thread OP - unless the design goals changed mid-thread and I missed it. This one is missing the ramp and the rover, and gained a passenger cabin... looks more like an SSTO crew lifter now than a long-distance atmospheric transport. I downloaded the Peregrine and tested it - there's plenty of power alright, it went right to LKO on the first try, with plenty of fuel for higher orbits. A few improvements I could think of: The control surfaces could use some tuning - it's over-controlled at the moment, which explains the wild behaviour. Limit the control authority, and dedicate control surfaces to a single axis. I'd say that's the main improvement you can make to this. The bi-coupler at the end throws off the balance if filled with fuel. It's perfectly ok to use tanks empty purely for their structural value. An extra X200-8 tank in the cargo bay (under the docking port) would balance the rear Mk3 adapter tank so the CoM stays put when burning LFO (if the bi-coupler is left empty, that is). If you also move the wings and engine pods forward it would also balance the LF fuel - the CoM would end up almost dead-center in the cabin, just shifting a bit up-down as fuel burns. I need to thank you for creating this thread, btw: it has reacquainted me with the Mk3 parts, which I've left neglected for a good while now. Mk3 joints were notoriously weak at one point, which made me give up using them - but playing around with the parts due to your questions made me realize they're much better now, and I need to use them more. Hmm, maybe time to pick up my old shuttle projects again...

Indeed. @purpleivan ?

Seeing as everyone else did a vertical take off (*), I wondered if it'd be possible to be competitive with a horizontal one. So I present the FleaC'er Ic: Full imgur album here. There's a few additional pics of the flight in there. Craft file shared on KerbalX: FleaC'er Ic (*: I missed @purpleivan's rail rocket entry. Is a 45 degree take off still vertical? )

Made me giggle. Also, I suddenly feel an urge to give Jeb a middle name: Jeb "Junkyard" Kerman.

You make no mention at all about crossfeed settings. Decouplers default to crossfeed disabled, which means that they form a barrier between every disposable tank and the rest of the craft. Have you checked if all the decouplers in that train are set to enable crossfeed? Otherwise no matter how you set the flow priority, they will never get used. It's very hard to tell what engines you are using with that low video quality, but there are engines that do not use oxidizer at all. Or, due again to the crossfeed setting not leaving it any other option, it may be using oxidizer from any other tanks that are accessible... like the orange tanks of the Duna lander.

Bienvenido a KSP y al foro. Aquí estamos para consejos, ayuda, etc.

This happens sometimes intermittently if you have the wing base clipped into cargo bays, service bays, or fairings. With bays it is easily tested: when this happens, just open the bay, and if you suddenly have your lift back, that's the problem. The underlying cause is that KSP was changed to consider anything shielded in a bay to not be 'functional', and this includes wings not generating lift. So it's not specifically a problem of this mod or that particular wing part. (Annoyingly, the game is not very consistent or intuitive about when something should be shielded - having just a very small part of the wing in the bay is sometimes enough to cause this. And then sometimes it works at first, but during the flight, as the flight stress bends the frame, suddenly it stops the wings from lifting, or worse, just one of them. This may be what has happened to you, and why it couldn't be reproduced later.)

I agree. I always do this as well, for a slightly different reason: I feel like a proper space program needs to always have a backup team. Contingencies, people! A single extra pilot does not make a backup team, you need a scientist and engineer as well. And since the 'first' team is all boys, it feels fitting to have an all girls team as well. I regularly find myself swapping between them for alternate launches, so if I start with the boys for the first launch, girls get the second, and so on, even for test launches or craft iteration tests. Additionally, in my mind anyway, there's a bit of an ongoing competition/challenge between those two first teams, giving the game another little fun dimension. When either one of them get back from a success, I picture them strutting by the 'other team' in the break room with a large grin and taunting each other amicably, and the 'losers' have to buy the snacks or drinks that day. I never seem to give it importance after filling out the second team - any further teams just get filled with whatever the rescue contracts or roster offer. But the two first teams... yes, always need the all-girl team to start the competition. So I'm all for making it default, two more orange suit female kerbals to complete the second team. As for names: I like the suggestions of Sally and Mae.