pellinor

Thanks, I couldn't explain it better! Good to see that the issue already has some attention.

If TweakScale breaks something I'd be grateful if you bring it to the Tweakscale thread. However I can not reproduce your situation. I have TweakScale, stock fuel switch and Orion installed and everything looks fine to me. Stock tanks can be switched and scaled consistently, and the "Orion pulse unit magazine" has buttons saying "previous/next texture" which change the tank content.

You're right, this is just the sort of contribution I'd like the node tool to handle for me. When assembling the node from small incremental steps (like the stock gizmo does) or integrating over a continuous burn following the normal marker (like an engine burn) the contribution in pro/retrograde builds up naturally. When taking large steps (like pressing +100m/s in preciseNode) things get imprecise. And I already have ideas how to correct for this.

I already mentioned our idea in the other thread and it seems not welcome there. Which is okay because we propose a change in the stock gizmo and the other thread is about an extra tool that needs to be consistent with stock. When I find the time I'll try to code a prototype of the "target orbit" coordinate system into preciseNode. Then we will see how it handles.

I'd like to raise the question what coordinate system the maneuver node gizmo should use (see this post in another thread). Short version, I'd suggest to use the coordinate system of the target orbit (instead of the current one before the node). For example pulling the normal+ handle would incrementally add dV in the new normal+ direction (which changes in the process), effectively changing the inclination of the target orbit without affecting anything else. Likewise, prograde would raise the velocity after the maneuver without changing the direction.

I think this is not about actual engine burns but about the behavior of the maneuver node gizmo: should the handles refer to the orbit before or after the burn? The current behaviour is "before", so pulling the handles does not change their orientation. Pulling the prograde handle means "add a small prograde burn before the current node". Simple and stable, but not always ideal. For example, pulling the normal handle messes up AP/PE and needs lots of fiddling to get a pure inclination change. This is a common use case so the UI should allow an efficient way to do it. "After" seems more logical to me. Let's say I plot a complex maneuver node and look at the resulting orbit. The direction is fine but I need to go faster. In this case the vector I want to add is the "prograde" of the new orbit. Instead the gizmo gives me the prograde direction of the old orbit, which tends to mess things up if those directions are not the same. With the "after" behavior, the above inclination change would also be plotted by just pulling the normal handle. I'd strongly prefer this behavior. First I wanted to propose a switch for this, but actually I can not think of any situation where I'd prefer to make corrections based on the "before" coordinate system. Of course the final node is an object in the "before" coordinate system. What I propose is that a UI for the input of incremental changes is more intuitive if it operates in the "after" coordinate system. EDIT: another try to formulate this in a simple way: 1) it is EASY to say what a small prograde burn AFTER a complex node will do 2) it is HARD to say what a small prograde burn BEFORE a complex node will do In KSP we plan our maneuvers by adding up small incremental changes. Why are we doing it the hard way?

This just makes me think of Maxmaps and the 50% default throttle. If the game insists on putting it there, it must be a reasonable setting, no? Would it work to have specialized crafts? A few stock crafts which are good designs for some use case, and their descriptions clearly state what they are good at. But an average player can still do better because most of his use cases ask for something different.

The link goes to the Angel's DSEV repository, pathfinder is here: https://github.com/Angel-125/Pathfinder/releases But it does not list a 0.8.1 release yet.

Feel free to experiment with blanket patches, just keep in mind your personal patches whenever you encounter problems (some people tend to mess up their install with custom patches and don't remember them when reporting bugs). Generally, unused TweakScale modules should not do any harm. I just prefer more explicit patches in the official download because I consider it safer and less intrusive towards other mods. Edit: see here (in the middle of the huge post there's a blanket patch with some criticism).

Questions about particle effects: currently TweakScale seems not to scale engine exhaust (at least the particles seem to spawn in the right spot). What would I need to do for a believable scaling? So far I tried some random methods in with part.particleSystem / part.particleEmitter but that was pure guesswork that didn't lead anywhere. For a simple solution I would probably need something like * scale particle size * scale particle speed by the same factor

small dev update: * Fix scaling of resource lists. This should fix alternators and the power consumption of drills and reaction wheels.

looks like a variant of the editor mass display bug. It looks like only the stock display is wrong. In my tests MechJeb/KER show the right value and when the ship is launched again the stock display in map view also shows the right mass.

From the TweakScale side a definite no. I don't think touching the scale of parts mid-flight is safe to do at all, especially if they are part of a vessel.

This is probably more a complaint about stock wings than about tweakscale? As a qick test of the scaling I built a simple plane with a control surface as main wing and measured the takeoff speed. Then I did the same with 4x the same part at 50% scale and came to roughly the same result. So from the TweakScale side the scaling of control surface lift looks fine to me. Lift should go with scale^2, so the lift currently scales with surface area and ignores the change in thickness. Again, to test the TweakScale side of the problem you need to compare different scalings of the same part. Otherwise there is interference from the balance of stock parts, which should be tested separately (like comparing 1xFAT against 4xElevon1). - - - Updated - - - I still don't see it. Now testing with techRequired = start, improvedNuclearPropulsion, start, start, start and all looks well. The 50% factor is not available, so the first slider goes from 10%-100%, and all right click menus work fine. What exactly are you doing? Could you reproduce the bug in stock+CTT+TweakScale? Did the bug vanish for you when you put it as the final tech?

small Dev update: * support for a few missing stock parts (thanks jojoa1997) * fix typo (thanks Wercho) * stock radiator support: scaling maxEnergyTransfer in ModuleActiveRadiator with scale^2. It looks like there is nothing to scale for the passive radiators. Please test, I am not sure how these parts are supposed to behave. One panel at 200% size should now do the work of four panels at original size. * Scale ImpactRange for stock drill modules. This is what determines if the drill has ground contact or not. ImpactRange fixed (see above). The placement of the effect seems roughly ok to me, the problem is particle effects generally are not scaled. I opened a github issue for this bug. No idea yet how to solve it. Is anyone familiar with particle effects? Is it intended behavior that they do not scale with the transform of a part? Is it advisable to postpone this issue until KSP1.1 is available?

Scaled parachutes look fine to me. I tested the following: * stayputnik core * kickback SRB tweaked to about 500 fuel * 2x MK2-R(100%) vs 8x MK2-R(50%) * activate everything in the first stage and compare max speed and speed at touchdown Both vessels had roughly the same speeds (80m/s max and 7.5m/s at touchdown).

I see the problem, but can't think of a good and simple way to solve it. Also be aware that each scaleFactor of each part can have its own techRequired, so you would have each part appear 6-9x in the tech tree, which is just too much. - - - Updated - - - I can not reproduce this, my dev install is fine with scaling engines of any sort. So it looks like a broken install or mod conflict. - - - Updated - - - I can't reproduce this. In a fresh career save with CTT installed, I added the following line to the stock 4-way RCS thruster techRequired = start, start, start, start, improvedNuclearPropulsion After researching the thruster, everything looks normal and I can click through the first four scalefactors (until 200%). The 400% factor is locked as expected.

Hi everyone, I am back from summer vacations and other hobbies and slowly catching up. Thanks to everyone who answered questions and provided support! Instead of the name it would be better to filter for parts that do not have the IR part module. If anyone has translated this into a working MM patch, please share. It seems like some more people are looking for a patch like this. - - - Updated - - - This sounds more like RealFuels, which does its own TweakScale support. I know mft/realFuels has its own code for tank scaling (and TweakScale does not touch resource nodes if such a module is present). There is currently no such ignore rule for engines. - - - Updated - - - The current setting is an exponent of 2.5 for both mass and thrust of engine parts (this is done with the "#@TWEAKSCALEBEHAVIOR[Engine]" statements). I started with an exponent of 2 like you suggest, but found that the resulting downscaled engines were often too heavy/strong to be useful. Or in other words the perfect engine for a tiny craft was too small to visually fit. Anyway, if there are engines where scaling does not preserve TWR I'd consider it a bug in the TweakScale config. - - - Updated - - - Thanks I'll merge it. - - - Updated - - - * The UI might make more sense if you use type=free and no defaultScale. So the parts start at "100%", which always makes sense. Your config makes them start at "2.5m", which is strange for non-stack parts and misleading for non-2.5m stack parts. * Please be aware that blanket patches might have unintended side effects. In principle a Tweakscale module on stuff like asteroids or kerbal EVA suits should not do anything, but I would not bet on it. * I would do it at the time FINAL, because other mods might apply patches later than AFTER[TweakScale]. * Be aware that scaleable parts are not stackable for KIS. In my install I occasionally remove tweakScale modules when I consider stacking more important than scaling. - - - Updated - - - Best is to post it in one thread and put a link to the post in the other. Is is this one? http://forum.kerbalspaceprogram.com/threads/65365-WIP-MSI-s-Infernal-Robotics-Model-Rework-%2828-04-2015%29-On-Hiatus?p=2185932&viewfull=1#post2185932 - - - Updated - - - I'll happily accept a working config if you find one. So far I haven't found a fairing config that visually works (there might be some hardcoded component that would need scaling). Haven't used a single radiator yet, but I have hope that these will be easy to scale (ETA: before 1.1 hits). - - - Updated - - - Already done with the "techRequired" config value. Some mods use it, but the standard tweakScale configs do not (mainly because nobody has included it in the configs). In my own game I actually don't scale that much and prefer to use common sense as a restriction. The problem with the way techRequired works today is that I'd consider it a lot of error-prone work to include in all the patches (maybe even separately for stock and CTT), and a huge mess to maintain. - - - Updated - - - My house rule is more like "use something that is close to the scale you need". So downscaling is fine, but if I need 10kN of thrust I don't start with a 3.75m engine. - - - Updated - - - There is a switch in scaleExponents.cfg to make them scaleable (which can be changed directly or via MM patch). Since this has confused quite a few people so far, I'm considering to change the default back to allow crew pod scaling by default. So the people who don't like it have to flip the switch. It would also be more stable since accidentally reverting the switch to 'forbidden' can break crafts. Any thoughts on this? - - - Updated - - - Any idea how those effects are placed/scaled? Usually TweakScale scales the local transform of the part, and this affects all the visual stuff and colliders. So there might be part modules with config values to scale. Or the hotRockets code might need to do something when a rescale happens.

This can be solved with a single MM patch, see here: http://forum.kerbalspaceprogram.com/threads/112693-1-0-4-TweakScale-v2-2-1%28Jun-26%29-Drag-cube-scaling?p=2214327&viewfull=1#post2214327 - - - Updated - - - You can just copy from other configs in the TweakScale/patches folder. A simple patch has the form @PART[insertNameHere] { %MODULE[TweakScale] { type = free } }

Small addition: on shapeways the model costs about 19 euros (+tax +shipping) in the "frosted extreme detail" material I used, and 13 euros in "frosted ultra detail" which should print just as well. So it was not even that expensive for its size and level of detail. I just hesitate to put it up for sale because I printed a different file (a sprue, together with other parts). If anyone is interested in the blender file just contact me.

No more tabletop players or scale modellers here? Finally I built and primed the model, to allow some photos that actually show something. The priming was done in two steps: first black, then a light dusting with white spray paint mainly from one side, to make the structures more visible and give a rough idea of the lighting. The solar panels have a shaft of 1mm thickness, and I ventured to draw a 0.4mm hole in it for inserting a reinforcement wire. And it worked! I can't stress enough how awesomely detailed this material is. The background has a 1cm-grid, and the model is about 7cm long.

@cantab: what you describe sounds more like a "MIN physics delta time per frame" to me. @EladDv: I agree about the term "physics delta", but why does the setting explicitely say "max physics delta"? Or are we talking about different settings?

It says MAX delta time, so this setting might only make a difference when the simulation is struggling to keep up (timer turns yellow). In my understanding, if it takes less than 0.03s to calculate a physics frame, there is no difference between your two settings. If it takes longer, KSP will either take larger time steps (up to the max delta time), or slow down (if max delta is 0.1s and each physics frame takes 0.2s the game runs at half speed). You might find differences in oscillation behavior. When building a plane with (too) much control authority and using SAS, I have often seen it flying stable at 1x, and heavily oscillating at 2x of higher physics warp (it sounds like a high delta time should be somehow similar to physics time warp).

I always wanted to make a kerbal model in tabletop miniature scale. The idea was to pack as much KSP as possible into a single compact model, and I ended up with a space station with a docked spaceplane. So I started by using the craft file import script to get the meshes into blender. Thanks to esinohio for help with some of the part meshes that I failed to import properly. This model is optimized for "frosted ultra/extreme detail" from Shapeways, trying to push the envelope of this material. The main steps to a printable model were: * either thickening or removing thin details like handrails * incorporating features from the normal maps and textures into the meshes * making sure that the connections between parts are solid enough (stock connections often have a slight 'disc of air' between them where the model would fall apart) * making the meshes manifold ("water-tight") * hollowing the model to make the print cheaper Link: Model on Shapeways The station is 1.25cm diameter which corresponds to 1:200 scale. Printed with a wall thickness of 0.3mm, the whole model uses about 2.2 cm^3 of material. At 0.3mm, the gigantor panels are quite flexible and arrived slightly bent. Convoluted surfaces like the tanks and science lab seem perfectly robust. For the handrails 0.2mm deep and wide was a good measure. The design relies on the 'print it anyway' option, so I can violate the design rules here and there. The plane had small convoluted escape holes, which was not the best idea because there was support material left clogging the service bay and intakes. I'd recommend to either leave generous holes so the stuff can get out easily, or only a tiny hole (like 0.1mm, seems necessary to mark the interior as hollow) so it stays inside. Since I had a self-imposed deadline for the print, it does not have all the details that were initially planned, but I am very happy with how it turned out. It is quite difficult to take decent photos of the transparent material (I'll post better ones when there is some paint on it). The details come out well, however some of the smooth surfaces have a slight grain to them (only noticeable for surfaces at right angles, and I already sanded the spaceplane wings). Spinning this idea further, it would be nice to have a construction kit like arc5555 did with his kerbal paper models. So the main manual work only needs to be done once for each part. I could imagine two ways of making this work: 1) Printable meshes that let you build in blender, so if you place them next to each other they will intersect in a way to ensure a printable connection. In principle it should also be possible to tweak the existing blender import script to use these meshes instead of the in-game ones. This would be my favorite for models in tabletop-scale. 2) Like above, but instead of intersecting add some plugging interface to the stack nodes, so you print individual parts and snap/glue them together yourself. The interface might be as simple as a centered hole for inserting a pin. This way might be more fun to physically play with but will lead to models with visible seams. This is probably better suited for larger scales, together with cheaper materials or a home 3D printer. For best results these meshes would be optimized for a specific scale and material (the most critical factor being wall thickness). Being a slow painter with lots of other unfinished projects, I probably won't make another KSP model anytime soon. So I won't drive this idea of a construction kit any further, but would be happy to help if someone else wants to do it. Are there others interested in modelling at this kind of scale?

My most fuel-efficient solution is to * aerocapture into an orbit that crosses the mun's * gravity-assist my way into the desired inclination (may take multiple encounters) * aerobrake to the desired height I once pulled this off using around 100-150m/s of deltaV, most of which was needed to lift the periapsis out of the atmosphere at the end. Saves lots of fuel but you pay in playing time instead, tinkering with manouver nodes.