Lisias

The Near Future add'ons were revamped recently, and this screwed up the old (and also deprecated) patches on TweakScale for these add'ons. The solution, again, is to install another TweakScale Companion, this one the PKMC. You will also need Frameworks for supporting SystemHeat, CryoTanks et all - but this is currently work in progress, and I will have another beta release today by night I think. Problem: it's a beta release, so it should be considered unstable and you should avoid using it on valuable savegames, as things are expected to break.

Hi! You got duplicated patches on two BDB parts: [LOG 18:47:07.937] [TweakScale] ERROR: **FATAL** Part bluedog.CXA.APAS.A.L04F (**DEPRECATED** **do not use**) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 18:47:07.940] [TweakScale] ERROR: **FATAL** Part bluedog.CXA.APAS.P (**DEPRECATED** **do not use**) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 Looking for the patching process, I found: [LOG 18:32:51.473] Applying update Bluedog_DB/Compatibility/Tweakscale/tweakscale_APAS/@PART[bluedog_CXA_APAS_A_L04F]:NEEDS[TweakScale] to Bluedog_DB/OldParts/APAS/CXA_APAS_A_L04F.cfg/PART[bluedog_CXA_APAS_A_L04F] ... [LOG 18:33:20.558] Applying update CxAerospace/Station Parts/MM_configs/CXA_TweakScale/@PART[*]:HAS[#author[cxg2827]:HAS[!MODULE[ModuleCommand]]]:AFTER[CxAerospace] to Bluedog_DB/OldParts/APAS/CXA_APAS_A_L04F.cfg/PART[bluedog_CXA_APAS_A_L04F] And this is a very old problem happening again, and there's no hope for a proper fix from the Maintainer. What you can do, however, is to delete the file GameData/CxAerospace/Station Parts/MM_configs/CXA_TweakScale.cfg and install the TweakScale Companion for Living Style, where patches for CxA were reimplemented in a safer way. Link for download: https://github.com/net-lisias-ksp/TweakScaleCompanion_LivingStyle/releases/

Exactly. Without air to help to decelerate the water particles, the splashes will go everywhere including bearings (what probably would happen even with air inside, anyway), and then draining into the electrical stuff. Since it's pretty hard to keep airtight seals on moving shafts, it's usually easier to seal the whole machinery together the chamber, so probably the whole shebang would need to be water proof. And on pumping air out, that moisture would be pulled into the pumping mechanism, that so would need to be water proof too. None of this is a too difficult problem to solve, but adds cost to the system. The big question is if the costs with dealing with water would worth the eventual savings. I don't have a clue, to tell you the true… Yep, but this one is a prototype. It's smaller, way smaller and it's not intended to endure many launches - it will be used for some test and then dismantled/retired and that's it. The real deal will be way bigger, will launch way heavier payloads - so an assembly robust enough to allow this without balancing may not be feasible, or too costly. We are talking about a 100 M arm (weighting probably more than a ton only itself) rotating a 3.5 revolutions per second - this is really something. Additionally, the whole structure would be subjected to the vibration, not only the bearings - on the other hand, I think the structure should be able to contain a catastrophic failure of the system so this may not be an issue at all. Ingenius! Pretty out-of-the-box thinking, I like it. There's a problem on it, however - you can't accelerate the capsule faster than the gases you are getting on the burn, so a slow burn is not useful. If you want the capsule to reach 11KM/s at the end of the barrel, you will need something burning in a way that the resulting gases would reach that (and something more, to tell you the true). Another problem is that burning solid fuel creates a hell of heat, that need to be dissipated by the barrel otherwise it would melt - it's different from detonating explosives, where a significant fraction of the heat created is rapidly absorbed by the gases being expanded. On your solution, the heat would be constantly created during the whole launch. But so would happen too with a series of chambers detonating their charges sequentially, so your idea is as valid as mine . But the problem of slow burning still persists. You need something that creates really high speed gases inside the barrel. So I thought to myself… What about coating the barrel with the solid fuel? The barrel would be some inches wider than the projectile, and the gaps filled with solid fuel , with firewalls preventing the whole barrel to ignite at once, we want the ignition to be sequential - it's a derivative from my series of chambers idea. We ignite the first section, the projectile is propelled ahead exposing the next section that would so be ignited, adding impulse to the projectile that would expose the next section, and so it goes until the end of the barrel... The air will be already out of the way, the whole chamber will be in a vacuum, so this is not a problem. Neat! The problem would be enough capacitors to store this energy, not to mention the heat generated by such electricity transfer in so small timeframe you would get - I think you would need some superconductors here. There's also the machinery to recover the counterweight from the deepness of the coil well (it must be somewhat deep, no?). But if the energy you get from the stunt is enough, you would get some energy back to inject back to the system on the next launch or perhaps on the pre-launch procedures! Neat²!

Since the quotes on the "cheating". Also, from the same post you quoted:

You would need two release mechanisms, that should be triggered in the exact nanosecond. The construction should also be slightly wider to accommodate the extra thick arm, that would be also slightly heavier. On the other hand, having two collectors able to withhold half the energy instead of just a big one is something to be considered, perhaps the total size (and cost) would be smaller. I'm not exactly inclined to this approach due the extra complexity (but having two smaller collectors for the weight may compensate it!), since I had calculated that there's time to spare for the weight to clear the arm's path - but it's a good idea nevertheless. I didn't considered it myself. For the sake of completude, I wondered if we could not use a liquid as counterweight - splashing water in a wider area would be easier to cope. But then I realised that the whole mass of water would be released at once and will hit the same spot the same, and then all the energy would make the water to ricochet and splash the whole chamber, that so would need to be cleaned before the next launch. So, terribly idea. In time, I just found a picture of the whole building: And I'm not seeing a place that would allow a "collector" to catch the counterweigh on release (that entry turned to the bottom looks like where they insert the projectile). So now I'm really curious about how they are rebalancing the arm after launch!

I think this is somewhat convoluted, and way "cheating" - unless the parts in question are unbalanced, and then we are going into add'on authoring, i.e., how to take a set of parts and rework them to create a new add'on, what's better served on the Add'On Development SubForums. It's still a valid option, but I don't see how TweakScale would help on it. Well, I ended up missing what you was willing to do. A solution for you will depends from what you intend to accomplish: are you playing a Modded Carrer? Or Role Playing on SandBox? How much are you willing to stick with Real Life™ ? Are you allowing youself to go Full Kerbal™ or you want some degree of plausibility? Perhapsyou are shooting a Video? In any case, I can think now on the following options: Option 1: If you are going to shoot a Video and are interested only on the visuals, there's a (pretty hacky) way to to tell TweakScale to ignore scalings at all : edit the ScaleExponents and ScaleExponents_Extended changing all the exponents to 1, as the example below: TWEAKSCALEEXPONENTS { name = Part breakingForce = 1 breakingTorque = 1 buoyancy = 1 explosionPotential = 1 mass = 1 .... This will essentially short-circuit all the heavy work it was be done (boohooo… ) by TweakScale current and previous authors, turning TweakScale into a glorified mesh and nodes Scaler - essentially what @ColdJ is telling you to do by brute force, but with a very convenient User Interface (and without the need to reboot KSP). Advantages You can make things fit the way you want without penalties No mass loss or gain no weight/thrust ratio worries no nothing, everything will behave as it was never scaled at all. Disadvantages You are throwing all plausibility and game balancing through the window. Keep in mind that by changing the Scales, all the current savegames on the KSP you are using will be hopelessly mangled beyound salvage, there's no way to do such stunt for only a savegame, it's the entire installment or nothing - what really is not a problem, just make a new copy of the KSP and fool around on the copy - just remember to do not start anything "serious" on it. Option 2: You are doing Career or a RPG on Sandbox, and want to be the less unplausible as possible. Assuming that all the parts you are using are satisfactorily balanced, well… You will need to scale down the probe (and work around the dV deficit you get), or you will need to scale up the Shuttle (and work around the problems the gain of mass and atmospheric drag you will get). Solving these kind os problems is what KSP is about, and since TweakScale just don't "scale things up the same", it's a challenge by itself to scale up the Shuttle and keep it flying the same - usually you will need to rework the fuel tanks due the change of the CoM, as the cockpit and the engines will not scale the same as them. Advantages You keep the game challenging You get the visuals you want You keep some plausability Disadvantages You lose a bit of plausibility, as we don't just scale up the Launch Vehicle at will on RL. Obviously, you can choose to scale down the probe and work around the problems you get, what it's what we would do on RL™, and so this doesn't apply. Option 3: You think the parts you are using are unbalanced, and want them to fit a Stock game. This is where @ColdJ hints will be useful to you, as you will reworking the add'on itself to meet what you think they should be. On this option, looking on the Add'On Development SubForum is the best line of action, as you will find a vast source of information from people that did exactly that in the past! Advantages You keep the game challenging You get the visuals you want You keep plausability, as intended by the add'on authors and now you would be one of them! Disadvantages It's a hell of a heavy work! Cheers!

Nope. Scaling down things will scale down the characteristics of each component differently, not equaly. So it's not just dividing everything by a number. You scale down a fuel tank, you are scaling volume down, so the thing gets exponentially down. For example, a 3 m high, 2 meter wide tube have a volume of 9424777.96 cm**3. Half the height and diameter, you have 1.5H, 1W = 1178097.25 cm**3. More or less 9 times less volume, or 2**3. But some parts like engines don't scale the same. Engines lose or gain mass at scaling at an exponent of 2.5 and not 3 as the volume of the fuel tank. A half sized engine will scale 2**2.5 down in weight but 2**3 in thrust, ~5.65 and 9 - so smaller engines have a worse thrust/weight ratio. Crewed parts have lots of empty spaces, so the factor for the mass is 2 (squared, not cubic). And so on. The dV is calculated with the current mass and the currently available engine's thrust and fuel. With fuel tanks, engine and cockpits losing or gaining weight at different exponents, you will have different dVs on scaling things up or down. right. But TS doesn't scales everything the same.

I was wandering about something similar. But the closest to the center of the arm the weight is, the longest it will travel until it hits the collector, and in the mean time the arm will rotate and perhaps hit him. The weight must clear the arm's path in less than half a revolution, otherwise we will have a collision. Damn. Time for some math. It was stated that the arm will have about 100 meters long (let's settle with 100, it will make calcs easier), and the speed at launch will be ~5.000 MPH, or 8046.72 KM/H or 2.235.2 M/s. So how many revolutions per second an 100 meters long arm will need to rotate in order to its tip reach 2.200 M/s (another rounding, please.. )? r = 100m v = 2200m/s v = rad/s * r rad/s = v / r rad/s = 2200 / 100 rad/s = 22 So the arm will be rotating at 22 radians per second, or 1260.51 degrees/sec or 3.5 revolutions per second! 0.28571429 seconds per revolution. Since the weight needs to clear the arm's path in half of a revolution, it have ~0.14285715 secs to do it. Or 100m/0.14285715s = ~700 m/s. In order to reach 700 m/s, the weight must be be at rads/s = 22 v = 700m/s v = rad/s * r r = v / rad/s r = 700 / 22 r == 31,81818182 But by then you need less time to clear the arm's path, as you have "only" ~70 meters to go - obviously, assuming that my math is working at this time of the night. So, yeah, I think your idea can fly.

There's another solution: the arm being perfectly balanced without the payload, and the balancing weight being ejected at the same time the payload. This will solve the timings and the shock (it will be zero). Of course, now you need something to colect and absorb the impact of the huge Kinect power of the weight (that would go to space itself if not collected), but this is way easier than the alternative. But it will demand more time between launches, as one will need to rebuilt the weight collector before the next launch - it will probably be destroyed and, so, you will need to remove the debris, clean all the system from any pulverized debris from the Impact, and put a new collector (and a refurbished weight) on the machine.

Wire is not a good choice. The slingshot effect of a 2KM cable will be pretty devastating for the machinery. Remember the 3rd of Newton: for each action, there's a reaction with the same intensity and opposite direction. With the sudden relief of the 'action' (the payload), the 'reaction' is free to go wild. On a wire, this is pretty nasty.

Yep, when I saw this one i became in doubt if I should post it here or in the 'Real Life Kerbalims' thread! and yep, as always on engineering, we don't really solve problems, we shift them to a place where they stop to be a problem for us at this moment. This stunt solved the problem of the energy releasing- but it created another one that may hinder the applicability of the thing. You have two problems: impact absorbing on the payload, and shock absorbing on the arm (as stated by @magnemoe). On the payload, the shock from the acceleration will be minimal, the thing will accelerate slowly and gradually. The problem will be on launch, when suddenly a lot of G force will suddenly vanish and any, absolutely any compressebility of any material will cause a slighshot effect on the opposite direction of where the G forces were happening. Both the capsule as the payload should be able to withhold that - au contraíre of the staged gun, this will happen instantaneously. Another problem is the arm itself. The rebalancing mechanism needs to be triggered in such way that the arm should be rebalanced after the launch BEFORE the resulting impact from spinning with that energy in an unbalanced state hits the ball-bearings - otherwise you will witness a hell of a R.U.D. (Rapid Unplanned Dissembly). Problem: the balancing weight needs to travel from the 'with payload' position to the 'without payload' position, and the thing will need to travel uphill against the centrifugal force. So your payload will be severely limited by the balancing mechanism- it needs to be fast, it needs to overcome inertia, it needs to withhold the Impact the balancing mass will produce (and dumper it to preventing screwing up the ball-bearings itself!). THIS is the most challenging (and limiting) factor of this solution. And the reason I think it may not be cost/effective as a launching vehicle from Moon to Earth - you would need a lot of small launches instead of a probably more cost effective big one for the payloads I expect it will needed for.

Well, that works too. By completely removing the TweakScale folder, you also removed the file GameData/TweakScale/Plugins/PluginData/config.xml where this option is persisted. What I don't understand is how you could activated it if CTRL-L is not responsive on your rig. Anyway, removing the file mentioned above would do the same result if something like this happens again.

You have the deprecated TweakscaleMakingHistoryConfigs installed: [LOG 16:33:20.500] Config(@PART[ServiceModule18]) TweakscaleMakingHistoryConfigs/Payload/@PART[ServiceModule18] It's some years since TweakscaleMakingHistoryConfigs was available for downloading - it was internalised and updated on TweakScale since them. Remove the directory GameData/TweakscaleMakingHistoryConfigs and you will be fine. Cheers!

Me too!! But @sevenperforcewas right too - my argument was valid in spirit, but wrong on the form, and he spotted the mistake - but I think he didn't understood exactly why my argument were flawed, and I think this ended up leading me to more confusion, as I was not linking the points and both of us ended up arguing in circles. In a nutshell, I was using "Shock" and "Impact as they were synonymous, and they are not. "Shock" is the appliance of an acceleration over a mass. "Impact" is what happens by a Shock OR by a Force being applied to the mass. Use Impact on my arguing instead of Shock, and things will make more sense.

I could not reproduce this problem on a vanilla 1.12.2 instalment. So it's something on your rig for sure. I will need the craft file in which this happens, your KSP.log, the MM Patch log and the MM Cache. KSP.log is on the same place the executable for the KSP is. The MM Patch Log is on the directory Logs. The MM Cache is on the GameData directory. It seems that something is screwing up the default scale of this gear. What you describes happens when the prefab default value differs from what was used to create the craft. So it's surely something that you have installed since, or perhaps deinstalled (i.e., you created the craft with a broken installment, and now it's loading the crippled craft on a sane instalment). — — POST EDIT — — Check if Auto-Scale is not active (CTRL-L). The Auto Scale tries to match the scaling of the current part using the parent part's size automatically!! Hit CTRL-L and see if it solves the issue!

Not if the whole structure is the mass in movement. There's a difference between (going back to the wristwatch) letting a 160g device hit a 5.000Kg something at 5000 gees, and letting something with 5000KG hiting it at 5000 gees. Also, please note that if you stack these two computers one over the over, and then shove 1000 gees on the butt of the bottom one, this one will suffer stress from the source of the impact and also from the computer over it due tis inertia. So if 1.000 gees if the exact amount of shock it can withhold without leaking it into the internal components (and assuming the compression and the tension resistance is the same!!!), this one will fail for sure due the extra stress caused by the compression of the computer on top due its inertia, that by the 3rd Law of Newton will also be 1.000 gees. The top one will survive, tough. Yes, it does. The casing is withholding twice the shock, from both sides. — — POST EDIT — — However… Assuming that such casing can withhold the Forces from both sides (up and bottom), i.e., 1KG * 1.000G = 9800N, times 2 = 19600N, indeed the impact from the bottom will be nullified by the impact from the top as the acceleration from the top will be the inverse of the one from the bottom (it's still the 3rd Law). So the net acceleration is zero for whatever is inside the casing. So, yeah. I'm seeing your point now.

And by now that one is now obsolete too. DOE is under new Management:

Nope. PT-BR here. Had to learn some German, however, in order to understand how Germans speak english on my times working as contractor for Siemens Mobile. TL;DR: it screed up my English.

But the adequacy of the shock mount is directly affected by the mass. Also, from the context of the original discussion, we were talking exactly about this: how increasing mass would affect the shock resistance of the wristwatch. If by some reason you scale up a wristwatch from 160g to 25KG, you can bet your SAS this will affect the shock resistance if the wristwatch components - on a pretty lame physics exercise (assuming that the resistance of the materials scales linearly, what doesn't happen!), I interpolate the gee resistance from such scaled up wristwatch from 5000 gees to a mere 32 gees. Please note that this mental exercise was not meant to be a accurate treaty about scaling up wristwatches (the series of oversimplifications used on the exercise was stated on the post). It was meant to demonstrate that the mass of the projectile has direct and crucial influence on the gee forces it can withhold - more the mass, less the Net Force it can withhold (at least, without some mitigation measures - but these adds more mass to the equation, leading us to a vicious cycle of a self-feeding problem). The whole point of the argument is that, at least in principle, the less G force you manage to inject into the projectile in each "stage", the better - less material you will use to mitigate the Net Forces applies to it, and so you can increase the payload of the thing - more earnings + less cost = better cost/benefit ratio, that it's what's matter after all. So, and going back to my original proposition that tries to satisfy the OP's question: may a pretty long barrel on a cannon filled with many expansion chambers could be effective on launching a payload from the ground into some kind of orbital trajectory? It was already stablished that it's not possible to do such to achieve orbit from the launching celestial body. It's a physics impossibility, so we had to wave off such use case. There's also the atmosphere, the losses imposed by the mass of air on front of the projectile is far from being insignificant, so I reduced my proposal to launch thingies from Moon to Earth using such a staged cannon. You would not launch fine manufacturings from the Moon, I think - there's no point on building factories for such things there. But I think you may want to bring down Ore (as long its value worths the costs) and, perhaps, Kerbals Humans that ended up their shift and need to go home in a cost effective way. That leaded to the problem of the Net Force injected on each stage - it should be, ideally, near 6Gs as this is relatively easy to get the passenger trained for. So, we are nailing it into the Requirements of the stunt: How much G you can kick on the project on each stage Dual mode? One for Humans, other for Ore? How many stages you will need What would be the distance between each stage? And so, how long the barrel need to be? How such energy you will need to extract from each stage How much energy it's possible to generate on each stage without blowing up the barrel. And how in hell the projectile will land on Earth with its cargo in a useable state (alive and health, on the case of Humans), assuming we manage to kick it from the Moon at first place. Arguing about Resistance of Materials is, indeed, a necessary step of the process (otherwise we would incur on an error similar as creating a Launching Vehicle to be used on rainy places that can't withhold moisture, or using valves on the fuel injection system that are eroded by the fuel/oxidiser - resemblances with real life events are not a coincidence). But arguing about the accuracy of some mental exercises meant to grossly demonstrate problems in a easy and fast way (prototypes - we use prototypes in order to prevent wasting resources on ideas that have no chance of working) ends up disrupting the process. Models and abstractions are not meant to be an accurate representation of Reality - they are meant to simplify the most possible the Reality as long the resulting model/abstraction is still useful to the problem at hands. No considerations are taken for any other use case, as it would be only a waste of time and resources. On the light of this last consideration, any discussion about how shock resistance on wristwatches really behaves is, frankly, moot. It's enough to demonstrate, empirically if possible (in order to save some time), that the shock resistance of anything (including wristwatches) are directly related to the mass : more mass, less resistance (unless further cost is added to the equation attempting to mitigate the problem - but even that, only to a certain extent). — — POST EDIT — — The guy was right, I was wrong. My model was not exactly wrong, but the reasons I was claiming the model works were wrong - and being right by the wrong reasons is not enough, as you will not be able to apply your model correctly and this may lead to wrong results - and you will not be able to fix it. The root cause of my confusion is that I ended up unadrevtidly using "Shock" and "Impact" as synonymous - and they are not. Shock is an acceleration applied to a mass. Impact may be related to a Shock, but also be related to a Force. You can't use these two terms as they would be same, as I was using on my mental model.

Cheers!!! (hey, you got it!) It's @Just Jim I heard around the corner?

Yes, it is. F = m * a, so mass is a key component on this equation. The shock resistance of a device is the the shock resistance of it's weakest component. How you mitigate the shock propagation into this weakest component is what's related to the geometry and elasticity of the casing of the device. What's completely off-topic, how about discussing this Thread subject instead?

Magic numbers: https://en.wikipedia.org/wiki/Magic_number_(programming) it was stated that some shockproof wristwatch could withstand 5.000 gees. Converting that 5.000 gees into Newtons, I got into 7480N of Net-Force the wristwatch can withhold. About the building I'm live, it doesn't weights 160 grams, neither is going to be shoved on a huge cannon barrel to be launched into space.

What means that the terminal velocity of the project will never exceed the practical expansion speed of the gas used on the expansion chambers. Good catch. However, and we are going literally nuclear on the matter, there's not practical limit for accelerating a particle other than the speed of light, right? So we need to find something that could expand strongly and fast enough to kick the projectile fast enough to reach the desired speed. Googling about, I found this (see page 159): On a nuclear explosion (yeah, I know, way overkill but I'm talking about theoretical limits now), we have a pressure such that the expansion runs at more than 150 KM/sec at 10 meters of the epicentre. Dude, this is a lot. Of course we could not use nuclear explosions on the chamber, as we don't want o obliterate the projectile - we need their atoms to reach the end of barrel on their original configuration, not scattered in vapour… So I think that once the technical issues are overcome (assuming theiy can be overcome at all), the idea still stands. But you hinted about another issue that I was letting pass trough: each subsequent chamber will need to inject way more energy than the previous one in order to "catch up the projectile" and then add yet more Kinect energy to it.

He was living with us, he was under an interplanetary student exchange and we were hosting him. We jumped together: I broke my glasses, he broke the nose - he landed on my dull head.

A strong push, a jump into the Skies. Everything was blue for some moments. Then he turned down, in the direction of his falling, and realised he was too fast and the aerodynamic forces just ripped off his carefully handmade ram-air decelerator device (also known as parachute). Everything was beautifully green for some moments. He opened his arms and legs, trying to delay even that by just a bit the end of this journey, inexorably accelerating into him at 9.8 metres per second per second… And suddenly it was over. Everything was red for a blink of an eye, and then black. Deep black. Painfully black. "JEBEDIAH KERMAN, I TOLD YOU TO DO NOT JUMP FROM THE ROOF, DAMNED BOY" he managed to hear while still buried in pain and stupefaction. "Mom… I'm going to be an astronaut…" "You will not live enough to drive a kraken damned car by doing this, what to say a rocket? Get up, we are going to the emergency unit - I think you broke your nose." Disclaimer: