pellinor

I'd like to discuss how auto scaling works, or is supposed to behave in the future, with respect to parts from different scaletypes. Here is my view on the subject (might be limited because I don't really use the function yet). Auto-scaling for stack parts seems clear and well-defined to me: stack parts those have an interface with a diameter and a corresponding stack node. If I auto-scale a new part such that its node matches a target node, I will always get a smooth stack. For other parts however, the node sizes are quite arbitrary. So I'm not sure if the above rule is any help. For example, the TrussGirderXL has 1.25m-nodes. So if I attach it to the top of a MK1 pod, it is auto-scaled to 50%. Does not make much sense to me. If both parts are identical, it makes sense again to autoscale them to the same size. Maybe the solution here is to make the autoscaling ability a property of a scaletype, and only work within that scaletype. Then we can set it true for 'stack', false for 'free'. And if someone has a set of parts that should be compatible with each other (like the IR hinges), he can define a custom scaletype with autoscale=true. Then IR hinges would autoscale with other IR-compatible parts but not jump to strange scales when connected to a stock stack part. At the moment autoscale only works via stack nodes, not for radially attached parts. I don't see wyh (or how) this should change.

Yes, I did not change any of the included configs for other mods.

Would you join me in the development thread to discuss this? It is not completely clear to me how auto and chain scaling is supposed to work. And if that logic can be easily ported to parts outside of the standard stack sizes. Thank you for your clear invitation for someone else to take the lead. Since you know the mod best, feel free to tell me when I do stuff that does not make sense or write ugly code.

The promised thread is up: http://forum.kerbalspaceprogram.com/threads/110899-WIP-TweakScale-Freescale-Everything I didn't knowingly fix any bug, so it probably still is there. Free scaling is a property of a scaletype. The old TweakScale only knows one %-based free scaletype, my version also makes the 'stack' scaletype free. There are no changes necessary for the individual part.

See also the release thread! TweakScale was originally developed by Goodspeed and Biotronic. [original release thread] This work started as a fork to make a feature I wanted for a long time, comfortable free scaling for everything. Since Biotronic has no more time to support the mod, this has also grown into a maintainence thread for TweakScale. Source: Github License: WTFPL Download Latest dev version (WIP) Stable Version Change Log ToDo / Ideas see the issues on GitHub Sort out interference with tweakable everything Support for D12Aerospace subassembly-scaling, a config file for setting of hotkeys

This really needs a separate thread (will come later today). For now, let me state that my fork is not a simple fix but rather a new experimental feature, and might break more things than it fixes! Please treat it as a WIP and don't consider it a stable version of TweakScale yet. This is also why I don't consider it a good idea to put this version on kerbalstuff. PS: thanks for the zip. I remembered some 'download as zip' on the github page, obviously not the commit page that I linked...

New version is up! https://github.com/pellinor0/TweakScale/commit/2cac39a64307eacc28519d435055db6e3787aba3 Autoscaling of free scaletypes works now. If you ever wanted to build that 1.5m rocket that splits into multiple 0.75m stacks you can do that now. The 1:2 / 2:1 adapter types (stock 2/3/4way adapters) are also set to free scaling and seem to work fine. Scaling is propagated along (stack) attachment nodes, and the new part is scaled to make its node match the node it is connected to. In the process, the concept of 'node families' vanished, so any two stack nodes are considered compatible. Will this hurt anyone / any other mod? I'm always thankful for feedback on mods or workflows that I don't use myself, so I don't accidentally break stuff. In this update chain scaling might be broken, since I had to comment out an if statement there. This might make it get active too often. If there is any problem, it should go away when disabling chain scaling.

I'm pretty suspicious it only vanished because I broke something else (didn't even know about this bug). Setting the stack scaletype to free scaling means that we are running through different parts of the code now whenever treating a stack part. Probably also broke auto/chain scaling by taking out too much from the stack scaletype. I'll look into that today.

I think an old career should be fine, and old ships should load fine. Only thing is there are UI informations dumped in the craft files, so the tweakables might not work right on old crafts in the editor.

Hello everyone, I'd like to discuss a change to fix the wonky increments for free scaling, and allow free scaling of stack parts. Github (includes the recompiled dll): EDIT: see separate development thread For stack scaling, the arrow buttons of the tweakable still lead to the standard stack sizes, but now the bar between them can be tweaked for intermediate sizes. So far, I tested scaling and node sizes in the VAB with some basic stock parts. It also works for adapters containing nodes of different sizes (to check, you need to change their scaleType first). Open questions: * More testing. This is where you come in. * Does this interfere with anything? (Like tech restrictions, or other mods changing default scaleTypes) * Is the surface scaletype still necessary? In the past, I liked it only for its better usability. * Are the adapter scaletypes still necessary? (were they made for the "a-to-b" names or to solve problems with node scaling?) * Code quality (I'm not familiar with c#). * Biotronic, do you still take pull requests? The Changes in detail: * Increments depend only on maxSize, instead of (max-min). (because this is how the tweakable in KSPApiExtension works) So now we can get nice round numbers in free scaling. * 8 large Increments (hardcoded for now) If maxSize is changed, this will result in wonky increment borders. It might be better to make largeIncrement a config value. * 2 small increments per large increment Mainly to have an easy access to 0.625m scale. * 25 slider positions per small increment Because repeatable values seem more valuable to me than infinitesimal steps. The slider increments are 1% for free and 2.5cm for stack. * proportional node sizing (size0 counting as 0.5, rounding down) * Change the 'stack' scaletype to free scaling. So the scaleFactors/Names and ATTACHNODES list are no longer used.

RCS build aid has a slider for this. I prefer custom control to auto-scaling because for large SSTOs I first want big indicators for overview, and then I tweak then very small for finetuning of dry/wet CoM. +1 for scaling of the indicators.

Automated welding already exists with the physicsSignificance flag. They just need to fix the conservation of mass issue. This and putting the flag in the craft file instead of the part definition would satisfy most welding needs.

I'd like to enter a solar plane using electric propellers. Too slow to keep up with the sun on the equator, it can still fly indefinitely on highter latitudes. It features lots of unnecessary complexity, since flying a few extra kilometers gives more points for the time spent than starting all over in the SPH. I only turned all the solar panels to the left to get more sun. Which actually did more harm than good because on the way north the sun was to the right and poor Jeb had to fly the first part of the journey upside-down. Built for duna, it is quite twitchy, but after some fiddling with mechjeb's pid-settings it flies stable enough for 3x time warp, and did fly for hours on its own. http://imgur.com/Tg46nUq http://imgur.com/Az3B3Fh Technically I didn't succeed to fly it as far as I can, since this would take infinite time, hope it is still a valid entry... There are lots of mod parts, for the challenge only the electric USI-fans and mechjeb were used. Unfortunately, the flight log seems to reset on quickload, so I lost quite some way from yesterday evening. I'll take the displayed number because in this case the distance is arbitrary anyway. Score: 100 enter the challenge 1 kerbal 5000 km -46 too complex! -36 heavy! -47 too long! -81 too wide! -16 too tall! ------------- 4875 PS: by the way, the score is totally not a covered advertisement for the cute little rocket engine on the back of the plane...

No. Procedural is not the same as random. It probably includes some sort of pseudo-random number generation but the seed is always the same, so the terrain under your base will not change.

To see your equatorial AN/DN you can also target the mun.

You can do a small aerocapture into a highly eccentric orbit, then correct your inclination somewhere far out, and lower the AP afterwards. With asteroids I try to manouver/aerobrake into a trajectory that crosses the orbit of the mun and then wait for gravity assists to change the inclination.

Actually, in a radial coordinate system (see the north pole of the earth), those distances are supposed to get smaller een in a flat space. What the image shows is that they get smaller at a different rate than a 'flatlander' from the outside would expect. I'd like to point your attention to a different viewpoint: geodesics. On this surface, what happens if an ant starts in some direction and then walks 'straight on' (suppose gravity is negligible) ? Just like the latitude circles on the earth, the circles in the illustration are not geodesics. So if you start tangential to a circle and walk without turning, your radial coordinate increases. Far away from the center, curvature converges to zero and your path converges to a straight line. Since a geodesic is the analogue to a straight line in curved space, in general relativity light travels on geodesics. So, if we send a ray of light close to this curved region of space(time), it is bent towards the middle. If one source sends multiple rays into the middle region, they will cross again on the other side. For rays of light, this effect is called gravitational lensing. Feel free to give feedback if you can't follow, I am probably doing this too fast and should give more intermediate steps. Edit: a small comment to the above illustration in general: I think what it illustrates really well is geodesics. Its main weakness is that people think of gravity as an extra force on top of the geometry, pulling things 'down', which is just plain wrong. The model would work just as well if you turn the surface 90° into the vertical, like the mouth of a trumpet. In general relativity, light rays (and other trajectories) do not bend because there is some magic force pulls them away from a straight line, but just follow the concept of 'walking straight on without turning', which is the same as going on a 'locally shortest path'. General relativity does not know a gravitational force at all. Gravity is encoded in the curvature of spacetime, and trajectories just need to start with some initial condition and then 'walk straight on without turning left or right'.

If this was true, then that part of space would be flat. See, supposing radial symmetry, you can always put your coordinates in a way such that all radial lines are the same length. Now suppose the other lines were also the same length (within some region of the space). Then the coordinate grid defines a length-preserving mapping (i.e. an isometry) between a flat space and this region. Since an isometry preserves curvature, the above space with the 'yardstick' distance measure would be flat. All the circles would have the same length. Hence, the geometry you are describing is that of a straight cylinder. If this is what the picture wants to illustrate (which I doubt), then it would not be a good choice of illustration.

The are not. Far from the middle, the geometry gets more and more flat (i.e. like euclidean geometry). And in euclidean geometry concentric circles can not have the same circumference. The lines sketch a coordinate system. Just like longitude and latitude on earth, the grid lines do not have the same length. In fact, you can recognize a curved space by the property that it does not allow a coordinate system in which all grid lines have constant length.

I only find 'frictionless maglev' and that it consumes electric energy. A cool project, but no fundamentally new technology and no magical source of energy.

Exactly. And physics does not have any problems with a perpetuum mobile as long as it respects conservation of energy.

The Jool system can be tricky to navigate but I find it incredibly cheap because of all those gravity assists. I usually park in an eccentric orbit of one of the inner moons. Brake just enough to get captured, then the exit burn is also cheap (there are some restrictions on exit, as the exit burn should be near the periapsis). Use Tylo to get to the outer moons, also use Tylo to throw the ship back to Kerbin. Edit: for the exit burn, I actively look for a gravity assist. So I warp until shortly before the transfer window, then make an escape node from the parking moon (usually laythe), such that it crosses Tylo's orbit. Then I shift and fiddle with this node until it leads into a useful encounter. If it doesn't work out or Vall gets in the Way, improvise some way to stay near the inner moons and catch the next gravity assist. It's a quite spontaneous way of planning, but with a bit of practice it works out surprisingly often.

Beautiful! This is how a proper aircraft should look. How do you disable those limits? I haven't found an easy way around them yet.

I miss an option to disable the limits of the translation gizmo. Since part clipping clearly is cheating, the opposite must be a good thing to do...

TweakScale would be a start, you can change the maximum size of things with simple MM patches. Just note that models tend to get ugly if you enlarge them too much.