komodo

Yes, this. It saves some sanity if one is adjusting their heating model, as well. Hermes is "out of place", due to its external origin, although I disagree with this description, as it blends very well with Etoh and Muo, as well as the new members of the family. Personally, as pods scale up, I typically stick a tweak scaled 1.25 m service bay between the pod and heatshield for stuff and things. (Although with USI.LS of late, the "stuff" doesn't go very far I wish they had standalone recyclers... Ah, I digress.) When pinching spesos, every bit of recovery helps. Especially dem science dealios, for sure.

Hit up the app launcher button for settings? Or, failing that, see a few posts above yours for details.

Landertrons are probably temporarily toast, but I don't think beyond that there are many/any plugin dependencies? With a big caveat, I don't see why it wouldn't work. But, we'll have to wait and see, as with everything!

You probably want to set sensitivity to 1. It explains that it is the value to scale back to when the time gets ahead of the target. For doing a straight insertion, yeah, I imagine it's just a little confused. (The time! It does nothing but go up!! *flail*)

"One of us, one of us!..." Nice patch, I'll give it a go next time I can get some Ksp time. Pros/cons of resize vs rescale? Something is clicking in my head regarding spherical volume going as the radius cubed goofing something somewhere, but it's late and my geometric instincts can go astray at times. (But yeah; with MM indexing and variables in hand, some serious tweaking can begin!)

The damn forum is goofing up a bit I think... Anyway, RT configs for the new probes. Hurray!

Someone or another on a pogo stick... That's a lot of tiny probes! Whelp! Time to go full Kessler! Imgur uploads may have to wait til the weekend, its already past my bedtime as it is! Looking good, though!

Fun is what it's all about, I just was disavowing myself of any lawsuits your Kerbals might level I loaded up some small MM tweaks on my Fork thread, as I mentioned above... (three days after the fact...)

Good/Bad/I don't know News! Thanks to the power of gnu/linux, this kinda thing is really stupid easy to do... All parts in Tantares containing isFairing: I don't know if we were hoping to find any 'false' ones?... Anyway, time to go blow up a new NLV beta!

@MrMeeb I have absolutely no idea what ROMini combined with realfuels stockalike pack would do. It seems that it would double rescale the masses/densities to something unpredictable. It would be interesting to see none the less... And SMURFF as well? You may want to check the configs to see if they are all active: it may be that some are detecting the others and disabling themselves, but I'd have to check. If they are all going, you shouldn't have any problem getting to orbit, haha! On gravity turn autopilot, yeah, it doesn't quite understand about atmospheric heating. I've had good luck with it with a start angle of 5-9 degrees, initial time of 70-90 seconds, final time 40 sec, and sensitivity around 0.4-0.5. Altitude should be pretty high for a "low" orbit, ~500 km or so. Mechjeb ive not tried in a while to see how it might act.

Woohoo! I made a happy! Seriously, I'm super glad to hear someone likes it ^^ two things I ought to note after rereading my post... I need a known issues section: one, is if you have to add a missing node patch, make sure not to add an additional entry for an existing one, or it'll happily square it vs a nice multiplication. The other is regarding procedural fairings; I had to explicitly exclude them from scaling, as the code that handles their resizing totally freaks out when subjected to these modifications. They work correctly, but they show the man behind the curtain when their numerical size doesn't match their visual. Consequently, you may want to change/patch their size limits to match the rescale. 2,3,4m, etc. I'm still looking into that one, but I'm far from a C++ guru, so their source is a little fuzzy to me. I suspect there is a simple way to tell them that they should start at 2m and step in 10cm increments, as they somehow know to start at 1.25 and go in multiples of that... but, it's probably right in front of my face where I'll never find it i also have no idea what procedural parts will do. Also go nuts, I suspect. *puts it on the "to check" list * oh, and SRBs: this carries over from the original, but they have ***wayyyyyy*** too much oomph as it stands. You'll want to probably set them down to 10-20% limit for most applications. (When I asked, NathanKell said he thought it was for escape rockets and the like, but he wasn't sure either.) You may want to play with that one: it's right at the top of the file, conveniently.

If you're being insanely 1000% exact, Celsius to kelvin is +273.15, not 272.15, although I don't know if the engine will ever be precise enough for us to tell. Someday, we can hope! i will also put this on my ever elongating list of "cool stuff to try"!

As they're almost impossible to make root parts, you could just slap in rescaleFactor = 0.5 or something suitable.

Regarding career mode in rescaled systems, I'll try to post some additional tweaks I've made, which are more to taste. some are from 64x as far as shuffling parts in the front of the tree, another which I haven't seen elsewhere is using custombarnkit to adjust the pad mass and dimension limits per building level. (I'm imaginative and multiplied the mass and (up; call it y) by 1.6. The x and z I left alone, as i mainly blow up rockets, less so spaceplanes. The same adjustment could be made there as well, though. Im also one of those KCT and remotech loonies, so my experience may not be the norm. I would reccomend testing career with different funding modifiers for sure, as that is something I haven't nailed down a balanced number for yet. 110% is close, I think. Science is more subjective as well, although Minmus biome hoppers are very unlikely to be possible here. Rescaling parts, that's why I liked the script I wrote: it's fairly transparent as far as gameplay goes. KER is a must as always to build sane rockets, just with the goal of 8-9000 m/s dV for lainch. SMURFF would work more or less the same, more "build rockets", less "research how real rockets are built".

The magic of github... https://github.com/KSatNet/RATPack/releases. Just needed to click through a bit!

@MrMeeb @thunder175, ROMini.cfg from RO is another option. I just posted some modifications I made as well, that compliment it. I only stick my head in here as your guys' posts inspired me to get off my *** and finally upload the tweaks i've been meaning to for the last while.

@NathanKell: I'm sure you just got pinged repeatedly, but my funday-Sunday-day-off managed to get the modifications I made cleaned up and a thread posted in AddonDev: Link. @LostOblivion, if you find ROMini to your liking, I would look at the modification I linked above. It remixes the script a bit for some quality of life improvements.

Hello all! I've been working on this project off and on for quite some time now. (tl;dr, magically rescale parts, follow instructions at bottom of post to install.) Backstory! I like to play on rescaled systems, 6.4x to be exact. But, this brings with it challenges as anyone who has tried it knows. Launch and Reentry are particularly trying. Several solutions exist for this problem, the two main ones that leap to mind are Realism Overhaul and SMURFF, both fantastic works that put mine to shame as far as sophistication goes. Realism Overhaul brings out the big guns as far as making the changes for a rescaled system go. SMURFF has a very comprehensive system while remaining lightweight. I admit I haven't tried it out in a while, but it's on my to-do list. Major props to @Kerbas_ad_astra for inspiration and some gleamed MM tricks. The solution presented here expands upon ROMini.cfg, from RO. It's not prominent, but available on their github page. It works by applying a similar methodology as RO does, to rescale parts more to a realistic scale size wise, along with some mass adjustments, such that density comes into line more or less naturally. A blanket scalar is applied, which was conveniently set at 1.6x times original size, so 1.25m becomes 2m, and so on. I instantly found it a blast to play with, as it kept things interesting without being too complicated to maintain. Major props to @NathanKell for this one, for originating the script/numerous other reasons. So, why is this post here? In 1.0.5, there exists a rather annoying bug in that rescaled root parts (specifically, those scaled by rescaleFactor) do not persist through load events. So, on vessel load or quickload, a rescaled part would revert to its original, smaller size. I never was able to ascertain if it was visual or if FAR was affected to. There exists a alternate method to scale parts in KSP, the model Scale variable. This one works correctly for loading, but doesn't rescale attach nodes to match. Boo! Module Manager (Props to @sarbian!) can do the appropriate scaling math on attach nodes perfectly well, but it has no means to do wildcard matching on them as far as I can tell. The MM patch looks funny, but works well to fix nodes. The problem is that a separate patch needs to exist for each kind of attach node that a part uses. This lead to a lot of copy and pasting to get a proof of concept working. So, I wrote some code. Specifically a python script to parse every cfg file in GameData, extract the node_* names, and write me the MM patch out. That's why we're here: The zip file below contains three components: A modified copy of ROMini.cfg with scaling code adjusted; a python script to generate a MM patch for said script, and a pre-generated patch file based off my install. (It's fairly large, but certainly it doesn't include every mod. It ought to cover the most common cases though, I would think.) Install! Install is easy: The config files can go anywhere in GameData. I would stick them in a directory named zzzzzzROMini, but I don't think it's strictly necessary. (We want it to run at the end of the MM passes, without using :FINAL.) The generateNodes.py ought to go in the base KSP directory (The one that GameData sits in) This also isn't strictly necessary, but it saves a step when running it, if you need to. If a node didn't scale right, and you don't wish to/aren't able to easily run the script, one or two nodes aren't too painful to edit in to the MM config: Find the part in question, and look for its "node_(whatever)" entries. Copy a block of patch and paste it to the end of the file, and adjust the text in the template. Requirements! KSP 1.0.5 Some sort of rescale, unless crazy OP is your goal semi-Optional: Python, minimum 2.7. (3 should work as far as I know.) Platform independent! Also as far as I know, this should work on Windows/OS X/Linux just fine. Optional: Having fun playing with your newly rescaled parts! Download!: Here Let me know if you have any trouble with it, i'd love to get feedback, as this is really the first 'addon' i've posted here. Good/Bad News! This will only be relevant/required for a few more weeks/couple months, as the aforementioned rescaleFactor bug has been fixed for 1.1, by, @NathanKell. (More props! And some jets, for that matter!) Still, if it is useful in the meantime, great! Also, it might serve as utility to someone who wants to write a similar helper script and/or learn python. (Which I kinda did to do this.) Snippets! These are just some extra tweaks I use, that you might all find handy. CustomBarnKit Config: This ups the mass and size limit on the level 1 and 2 launchpads to make it a little saner to blast off. Procedural Fairings: These are borrowed straight from RP-0, so all the credit goes over to them. They adjust the size limits and tech tree nodes at which the fairings unlock. It's only the front of it, just as an example, as I think this is something that might be a matter of taste as far as tech tree balance. In MM code, @ edits a value, % edits or ADDS a value if it is missing, ! deletes a value. The node names are fairly straight forward. If you're curious further, just drop a post here and lets see what we can work out. (Adjusting when the parts themselves unlock may be a worthwhile venture, as well.) Starting Launch Clamps: This one is from the 64x pack. It adjusts the launch clamps in the tree such that you start with them in the 'Start' node, as they may be of some significant utility for oversized craft. ... I swear there was another one. Blah Known Issues: If a Node needs to be added to the list manually, double check that it's the correct one; a duplicate entry will quite happily end up scaling twice (that is, squaring the scale). Procedural Fairings are still WIP: They certainly work, but they play a little bit of 'man behind the curtain', as the numbers displayed don't jive with the visuals presented elsewhere in the game. I'm still seeing what can be done about this, so its WIP. Not an "Issue" Issue, but be aware that SRBs are scaled to a VERY high TWR out of the box: This is so launch escape systems and the like can work properly. For regular "SRB-ing", you'll likely find that they're a little much. (Your Kerbalnaut may find that they're a little bit 'chunky guacamole', in other words.) Aim for 10-25% on the thrust limiters. This is easily adjustable, at the top of ROMini.cfg, in the first config block, look for @maxThrust, and tweak the multiplier to taste. Changelog: License:

Tiny Bug Is Tiny! When Explorer 1 got renamed, the RT patch slipped through the crack; I would post the patch, but it's a literal single string replacement from explorerprobe to Bluedog_Explorer1. Everything else has been golden thus far!

First, thank you for making this pack: I have a blast playing it in 64x career mode. I would say either 2 or 3 would be good choices; in anything, intentionally building hate and contempt seems daft, especially so here in a recreational activity of all places. The pack as it exists will still continue to if someone is neck deep in a career, but I don't see why progress shouldn't be made, with special note that I think you should do what gives you the best feeling: It's your pack after all, we're just lucky enough to tag along for the ride! Timewise, again, the existing pack would continue to exist, so if an overhaul, major or minor, took some time, I'd be fine with that. In light of 1.1 as well, it might be the perfect time to ponder art assets, as a funny feeling tells me kopernicus won't be ready on launch day. (Not to be cynical, but i'd be floored if KSP was ready launch day, such an update as it is.)

The quote gizmo broke on mobile, but I rather like the result honestly... Anyway! regarding save breakage, as with all things Ksp, and especially all things add on, it's your show after all; if something needs to break for arts sake,well, I'll demand a full refund That is to say, if something needs to break, it's on us more than you, I think. Besides all that, foodphonelaptop priority sounds like the place to focus as well. Oh, and those "class" things... Yeah, them... >_>

I dig the names! They're always very pesky, although I like the feel of these. A word to go with a part does tend to help sort them out. I would argue slightly for the 'immersion' of the alphanumeric 'technobabble', but I can understand both sides. The numbering system used for your parts is mighty handy for getting an idea of the relative fuel capacities. I .. feel a bit foolish at wondering after the Etoh name, though. It wasn't meaning anything to me, thus a quick google... DUH... It's the perfect name for a boozerocket. However, me and my chemistry degree are going to hide in the corner and pretend like that didn't just happen My in game names always tend to come out somewhat pragmatically; my current series of satellites are named NextGen, as they're made up of a Ranger Core Bus, with a USI DERP module underneath (don't judge me... ). The new (and prerenamed) Fenris-Darkah booster conspires to get them about 14k dV off the pad. Quite the improvement over the previous Etoh-(Able?) booster series. The Administration hopes that this will be enough to edge the probe into escape velocity, haha.

@VenomousRequiem: Real computers were meant to run in, nay, atop cardboard boxes! /o Glad you're back with us! As for the other jazz, I think a massive thumbs up should do the trick. This stuff looks awesome.

These look insanely awesome. I had a quick question though: I see clearly that the career mode costs and unlocks are whacked. The question would be is it the unlock 'cost' that is considered whacked, or the tree node placement? Also, is the progression intended to be temporal wise, payload wise, or technology wise? The shuttle-y things seem to pop up sooner in the tree if I recall correctly. I only ask because it has been on my list to nudge the parts around in the tree for personal taste as far as what unlocks when, along with some look at the speso cost, but I didn't know if there was a general idea as to which direction the balance should go. (Up, down, left, right, red fish, blue fish, etc.) I understand that these are big*** boosters, but I rarely get that deep in the tech tree in my careers, and i'd love to play with them more readily Any thoughts would be great, i'd love to give something back to the project, but only if it would be useful to others!

I like it: The basic features are fairly accessible, and appropriate to their node. It is good to have features that unlock as they may be needed. Some other mods fall into the trap of unlocking the (whatever) far past when it would be useful to have. (RT in particular locks away the built in low range omni antenna so deep in the tree without ever stating it anywhere such that it becomes very frustrating to contend with. (Although if frustration is to be avoided, RT probably isn't the mod to run! )) The tech tree as stock leaves a lot to be desired, unfortunately, as previously noted, but I think this is entirely reasonable as far as a progression goes.