pellinor

Are you aware that this method will break as soon as two modules use it? Suppose I add 1t to a part and you add 1t, then both modules will report a moduleMass of 2t. So it only works if each module remembers how much it added and only reports this as its moduleMass. For TweakScale I'll give the "remember what you added" solution a try. I really fail to see what this IPartMassModifier is good for, its purpose seems to collect an information that is already there (the part mass) in a more complicated way.

You can look at how Roverdude fixed the USI Kontainers. He made separate parts with hardcoded scale (not using the rescaleFactor value because that will trigger the same bug).

I think this is more a question of game design rather than realism. The 1t/kerbal setting leads to a valid and interesting game. Raising the value adds new ways of playing, while breaking some of the old ones. It is really a question what sort of game you choose to play. In my own game I treat high range and mass limits as an abstraction. So I give orders and get the result, without simulating all the details in between. Just like crew transfer, which I consider interesting the first few times but boring once it becomes routine work.

The current exponent comes from a rough comparison of the stock cargo bays. I'd consider anything between 2 and 3 as somewhat reasonable and would just test which exponent feels balanced for the sizes you are using. This editor is a piece of unused and outdated code, you can safely throw the dll out. I just haven't touched it yet because there were never any problems.

For the larger asteroids the CoM-centered camera makes it difficult to interact with the tiny attached vessel. Is there a mod to solve this? Centering the camera on the 'control from here' part would help for example.

Stuff inside KIS inventories does not exist as a physical part. KIS will only create that part when it is taken out of the inventory. Inaccessible resources are a consequence of this design.

I have all of these mods and everything works. Maybe a missing ModuleManager?

The code in my post above is a module manager patch. Just put these lines into a file with ending ".cfg" anywhere in the GameData folder. It is good practice to keep custom patches like this outside of the KIS folder so you don't accidentally lose them when updating the mod. Edit: the file with the original value is Gamedata/KIS/settings.cfg

As a workaround you can give the kerbal more reach so you don't have to climb: @KISConfig[KISConfig] { @EvaPickup { @maxDistance = 100 } }

Did you also give the part a new name? Part names must be unique, else bad things may happen. And the new part should not be scaleable until you explicitely add a TweakScale module.

The 1.25m mass driver seems a bit strong for its weight. Powered by batteries it makes a decent engine for a rocket SSTO :-) RCS is just a different control scheme for engines, so it would be good if both are roughly balanced against each other. Also, how come the larger mass driver uses less electricity in RCS mode than in engine mode?

I think you used file names instead of part names (following squad's example, people often don't name their stuff consistently). For example there is a file corridor_2end_adapter.cfg but the part inside has name=KKAOSS_gangway_2_adapter. The last one is what MM needs to identify the part.

Just had a look at the ART Github repo. The "Revamp for 0.7.0" commit brought lots of files from firespitter (including props, sounds and the parts guide pdf). It looks like an accident to me, the changelog does not sound like the new version would use all these things.

Thanks! Fixed in the dev version.

Extending the panels was esinohio's work. I rebuilt the ladders by hand, only using the original mesh as a guide.

My usual way to view the forum was a list of all threads that changed since my last visit. This last can be configured as an activity stream, but my screen now shows about a quarter of the information it showed before. Is there a better way to stay up to date? A bonus would be to restrict the search to a subset of the forums. Still, I'd already be happy to get the old information density back.

Do we really need so many significant digits on a conversion factor? Capping the display to 1/100th credit would also solve the issue.

Great ideas. I'll definitely try this.

[quote name='Tatonf']You can't change your orbit without changing the kinetic energy of the ship[/QUOTE] Actually you can. Radial and normal burns do exactly that. Maneuver nodes have 3 dimensions, energy only has one. So there must be two dimensions of orbital change that keep the orbital energy constant.

[quote name='EladDv']since energy is a scalar and gravity can only transfer energy from kinetic to potential energy and in the reverse when you get out of an SOI in KSP (which is a sphere and since that the potential energy is the same) gravity assists DON'T change your energy at all BUT you momentum does change since it is a vector it's direction is changed by the constant force towards the planet that is perpendicular to the vessel's velocity, still since the energy dosnt change your speed dosnt too. The perceived net energy gain is from the energy you'd need to expend in order to change your vector into the one you get at the end of assist (i am not a professional physicist but still a uni student in physics)[/QUOTE] Within the reference frame/SOI of the body you are right. There is a static gravity field and conservation of energy holds, so the gravity assist can only change the direction but not the magnitude of your speed. In the reference frame of the parent, things look different. As an example, model the gravity of Mun in the reference Frame of Kerbin. You can do this either with a time-dependent gravity field (the Mun moves), or with a rotating reference frame (coordinates rotate so that the Mun stays fixed). Both of these models break energy conservation. Example: Say a vessel stands still at the height of the Mun orbit (zero kinetic energy). (Say it spends a short time there so that falling towards kerbin is not significant) The Mun approaches, when the SOI catches the vessel, it has a speed "v" relative to Mun which is conserved. It passes Mun's SOI on a hyperbolic trajectory, exiting in a different direction with the same relative speed. Now back in Kerbin's SOI the vessel has a speed (up to 2v), and therefore gained considerable kinetic energy.

[quote name='Tatonf']Thanks for all the replies, but I still don't understand why I gain more "kinetic energy" from burning in LKO rather than in Sun's orbit. You say that I can't compare my velocity from LKO and the velocity from my Sun orbit, but what does matter at the end ? My velocity relatively to the Sun ? That would mean that, if I go orbiting the Sun at an altitude where my velocity is greater than 9284.5 + 3431.0 = 12 715.5 m/s, the Oberth effect I'll get from the Sun will be better than the one I get from LKO ?[/QUOTE] Maybe it helps to think in terms of gravity potential, which does not depend on the reference frame. The Oberth effect means that pro/retrograde burns are most effective when you are low in a gravity well. Now the sun generates a large gravity well spanning the whole system, and Kerbin causes a local dip in this potential (the SOI model in KSP is a close-enough approximation of this). So when you want to do a burn somewhere around Kerbin, you'd look for the local potential minimum, which is "as close to the planet as you can get away with". Edit (overtaken by other posts): I agree that the Oberth effect does not need gravity wells, however they can avoid confusion about reference frames because you can formulate your kinetic energy in a handy way. [quote name='GoSlash27']exponential relationship between velocity and energy[/QUOTE] quadratic (just nitpicking, of course that does not invalidate your point)

Small dev update: * Don't force early setup when getModuleCost is called. This should fix a crash with TweakScale and MFT/realFuels.

Small dev update: * support for NF-Construction

I changed nothing, and can still scale everything continuously. The intermediate sizes are allowed by the "freeScale=true" property. This is set to "true" in all configs that come with TweakScale. Maybe you miss some .cfg file in the GameData/TweakScale folder?

TweakScale recently got an update (Oct-30). Among other things, I fixed a similar bug with the stock drills (the impact range value of ModuleResourceHarvester was not scaled). It might be worth to check if the issue also occurs with the version before: TweakScale v2.2.1.