HoneyFox

perhaps you need to swap x & y axes (or perhaps x & z or y & z axes, I don't remember that clearly) for the rotation because the coordinate system used by orbit is different from the one used by vessel.GetWorldPosition() IIRC.

AFAIK a liquid fuel tank is never really full. There will be some ullage there for fuel to boil (especially for those cryogenic fuels) and/or to avoid exceeded pressure inside the tank. But yes when the fuel tank is relatively full, the fuel flow will be less likely to be unstable. I don't know if there is any liquid-fueled engine specialized to be running with fast spin in RL. In normal cases this should be avoided or fuel will be sticking on the side of the fuel tank instead of the bottom of it. And you talked about the instability inside the combustion chamber, I wonder what would happen to it because IIRC there're some engines that has spiral pipes along the chamber wall and injects propellant into the chamber in some sort of vortex pattern.

That might be the problem. If the launch clamp is not directly attached to the engine, it has a range limit for igniting engines by checking the engine part's center position (yeah so if the engine is very big it might be too far away even if it doesn't seem to be). You can always change the engine to be surface-attach-able IMO. Or you can open the Ignitor_Stock.cfg and adjust the launch-clamp's ignitor range to a bigger value (unit is meter).

I remember that i added the Lat/Lon input in the latest version so that you can use that to place your object roughly at the position you want and then play around with { Vector3 {X,Y,Z}, Alt } directly to fine-tune the position. The {X,Y,Z} is a vector representing the direction from the main body's center to object's position. This vector will be normalized and then multiplied with (body radius + Alt) to get the final coordinate of your object (related to the center of the main body). The Y axis is the north/south pole axis. hence if you still want to tweak the object's position by directly changing X,Y,Z values, you should first tweak X & Z values to setup the longitude of your object, after that tweak Y value to adjust the latitude. By following this order, the longitude will remain unchanged when you tweak Y.

This will be useful for long ion engine burn (with close-to-reality thrust of course)... mmm...

I've been using SteamGauges for quite a few months. it is quite useful but when I use it with this KFI, two HUDs clutter the screen quite much and it's not so easy to keep track both the pitch ladder angle and the KFI's symbols at the same time.

damn how can modders keep finding things that should be STOCK but are not.

Awesome, I've been wanting real projecting-to-infinite HUD for quite a long time. EDIT: BTW will you consider adding pitch ladder?

Oh then we have some complex interaction between them. TS will update the mass by scale^3 as well, which i think should be corresponding to the origMass in MEC right? And if possible, I hope that the Isp can reduce a little bit when an engine is up-scaled... Perhaps... just perhaps, here is my opinion of this: what if we reverse it, what if MEC actively tries to (because it might fail) acquire TS module and its scale information and do the tweaking of thrust, mass, Isp, etc by itself? All the TS does is: provides a scale, do scaling of the engine's size. EDIT: I was even thinking if some sort of IRescaleable interface (with OnRescale(...) function inside of course) can be implemented and shared by multiple plugins...

That sounds great. though I would still prefer a way to do this by simply changing a variable's value other than calling a certain function... maybe by provide some sort of thrust multiplier? though I remember there's already something with similar name in your code.

Can you add support to ModuleEngineConfigs? which has configureMin/MaxThrust to set when rescaling engines, just like what you did to ModuleEngines & ModuleEnginesFX. I made a forked version for my own personal use, but the implementation is rather bad and it's based on a quite old version. so...

I cannot recall anything more that we talked about ... log10 done, color/alpha on the todo list.

ha, remember that i asked you about RF ModuleEngineConfigs's configMaxThrust got set in OnLoad()? at that moment i was trying to fork this project and add support for MEC configured engines when rescaling them.

Ah... and one problem is I cannot ensure that TP's OnStart() is executed after MEC's OnStart()... guess I need to use StartCoroutine() with an IEnumerator with yield return null to let it execute after one frame delay. Same with OnLoad() of course.

Alright, I did some tests yesterday night and i found something interesting: it seems like ModuleEngineConfigs' initialization has been called more than once when starting a flight. And since my TweakableParam's tweaking the configMaxThrust happens in OnStart() only for once, the value it changed was then reverted. I then tried adding some delay before applying the tweak and it finally worked. I remember that you once told me that for some unknown reason, KSP would call OnLoad() or Load() or something similar twice when beginning a flight. I wonder if that is the cause.

No. what he means is a model with hollow collider in the mid of the interstage adapter so that the engine thrust will not be "absorbed" by it. i.e. if you decouple the lower stage with a decoupler and still have an interstage adapter attached to the bottom of the upper stage engine (in other words, two-plane separation), it won't stop the upper stage from accelerating to get away from the lower stage.

Hi, Nathan. I come to ask a ... huh... strange question: Is there anyway I can do to tweak some values in the RF (either public or non-public, I can use Reflection anyway ) during flight to change an engine's max thrust (Vac)? I haven't dug into your codes deeply enough so I just want a faster approach to the answer by asking you directly. EDIT: I just saw a "ChangeThrust" function whose comment says it's for StretchySRB. Wonder if this can be used during another PartModule's OnStart() to change normal liquid fuel engines' max thrust...

You didn't get my point... and I've checked the source-code at GitHub. ModuleEngineConfigs is a different module from the ModuleFuelTanks, it adjusts the engine's performance/propellants while the latter one give customizable-fuel-amount capability.

Engines!!!??? Oh-YEEESSSS!!! EDIT: Checked the source-codes. and: 1. Don't forget the ModuleEnginesFX 2. Can you add support for ModuleEngineConfigs from RealFuels/ModularFuelTanks? Currently TS modify the engine's max/minThrust directly in OnStart(), but that might be overridden by RF/MFT. Should work well for non-MEC engines though.

Do want... and perhaps a minThrust for it too. Some RCS thrusters cannot adjust their thrust arbitrarily. EDIT: This might result to RCS control oscillation though...

Wait a minute... what do you mean by "if KSP thinks it is a 2.5m part"? I don't think KSP even needs to think about it. And some mod parts might have non-uniform scale in its own model, that's the problem I was wondering about: the TweakScale plugin seems to adjust the model gameObject (or a child gameObject of it) 's transform.localScale, what if that localScale is not {1,1,1} initially? EDIT: alright it seems like TS is just scaling the localScale, that should be no problem then... One thing I feel strange is: although I haven't added any defaultScale definition in the .cfg so that all parts use 1 by default (according to the source-code), some of these 2.5m/3.75m/5.0m parts (some parts from AIES/NovaPunch2) seem to be working normally while almost all parts from KW (no matter if it's 1.25m or 2.5m or 3.75m) don't behave correctly.

So the problem is: how should I set defaultScale values for one part? Some parts have "scale = " or "rescaleFactor = " ... in part.cfg. Some parts uses "MODEL {... scale = ...}" as well as "scale = ", What value should I use for these? I don't think I can simply use 0 for 62.5cm parts and 1 for 1.25m parts, 2 for 2.5m parts, 3 for 3.75m parts, 4 for 5m parts ... based on *what size I think it is* or *what size it looks like*. P.S. some plugins like ProcFairings' interstage adapters and RealChutes utilize part scaling as well, and will be locked by the TweakScale so I guess I need to add some exceptions.

Some feedback of the TweakScale plugin: 1. Some mod parts (NP, KW, etc.) seem to be scaled by their own and using TweakScale will make their size rescaled and after that their attach nodes are misplaced. 2. When using this plugin, flight camera will sometimes suddenly shift to tens of metres away from the rockets and gradually shift back, a bit annoying. In rare cases, the rocket might disassemble itself due to "gee-force exceeded" according to the flight log when the camera shifts.

Great! Now let me add it to PART[*]... muhuhahaha...

What I want to test the TweakableScale with is that Cargo Transportation-Solutions (WIP)... damn I cannot access my home computer right now.