toric5

I completely missed the atmospheric TWR... Anyways, PR incoming.

Ok, I think an ISP buff should be all it needs to balance with LH2s lower density. However, I did notice that in closed cycle mode, Project Eeloo has a TWR of 5.5, the best solid core NTR save for the Scylla. Just checking to see if this is intentional. Also, the stubber says it is supposed to be a high thrust engine, and yet it barely outperforms the Posiden in TWR, (3.3 vs 3 in LH2 only, 8.4 vs 7.5 with oxidizer.) (comparing it to the Neptune isn't much better.) However, its TWR is 275 seconds lower than other solid cores. Again, just checking to see if it is intentional, as the only advantage I can see is landing leg length.

Manual patch it is. However, I am completely clueless when it comes to balancing. Ill probably compromise between what the dynamic patch would do and the HL2/Ox patch for the NF areo jets. @Streetwind, anything I should be aware of? I don't have much experience with balancing. as for the multi patch, that is completely my bad. I was testing removing the multi-mode restriction, and the comments in the config reference the dynamic patch in a couple of places. I should have tested on a clean install first.

Ill try. I could remove the multi-mode restriction, but I think there are some possible edge cases where it could affect non-nuke engines. (I think. It might be safe...) Also, when did the LV-N get the patch to become a liquid fuel-LH2 hybrid? that patch needs to be applied after the dynamic NTR patch, so something like :FOR[zzzKerbalAtomics]. Ill pull request when I have something.

You cant launch to an inclination that is less than your latitude. You have to do a plane change.

Need a patch for the project eloo engine from NF aeronautics. the dynamic patch doesn't cover multi-mode engines.

The copernicus and nalatius say they cant be retracted in the description, but you forgot retractable=false in the configs. the halo (the giant circular blanket) has the opposite problem.

added a bit of gimbal to the medusa with module manager.

Is it just me, or is the tiny areospike engine a bit overpowered compared to the spark. better in every way execpt vaccum thrust, where it is 2kn worse, and costs almost nothing. I would suggest a thrust and ISP nerf

Whats the difference (in function) between this and KER? Ive been a KER user for years, but was browsing around and saw this...

yup. causes phantom forces. I thought the lossless mode modified the stock phys warp...

docked a part that had no rcs thrusters of its own, only one docking port (the one I wanted to attach to the station) and couldnt use the grabbing arm. Had to dock it to a tug, put it on a course so it would dock, and then undock the tug and get it out of the way before a collision. I basicly docked something by throwing it at the docking port.

that would have been back in .17... I remember I made it to orbit fairly quickly, but I must have killed jeb hundreds of times trying to land on the mun. No pictures, Ive gone through 2 computers since then.

sounds good. the whole autoscaling thig seems to be a tad off, unless it scales to the max amount present in the universe, whitch leads to a lot of problems. Good to know that its somewhere on the todo list. the problem isnt so mutch probe manuverablity, its more that if it had a 'controll from here' option allows you to use your navball and 'point at target' sas option in order to get an accurate idea of the altitude of resource bands. (unless you mean that they are intended to be placed on a flat surface on top of the probe...) My point about the models being ambiguous about whitch protrusion is the camera lens still stands though. The spectrometer has the square opening facing alongside the craft, and the round opening facing outwards. The particle detector has the big round dome at the top, and the tiny round protrusion on the side that looks like it could be a camara lens. (dont get me wrong, the models are quite nice, just ambiguous.)

Does your code use resource abundance ranging from 1 to 0, or from 100 to 0? I have found that a value of .2 works well for antimatter, but for the other resources, the abundances vary so wildly that in order to make a resource even visible on a low abundance planet, the resource will, max out the graph and not really give you an idea of where it is most abundant, only telling you that its there, and there's more than trace amounts of it. Maybe a log scale would fix this? Or making the y scaling adjustable in game, similar to how the x, or distance range couple of side notes: The ALICE spectrometers model makes it non obvious what the direction it scans along is. I thought it was the square lens that points alongside the vessel for quite a while. (the z map particle detector has similar issues.) The current orientation of these transforms also makes craft design that can use these to pinpoint resources rather difficult, as you usually would want to scan in line with your direction of control, so you can use the navball to assist you, but with the current transforms, you would have to place these on a flat surface on top of your ship to do that (very limited real estate compared to radial mounts, and awkward placement for surface attachment). Maybe adding a control from here option would be the simplest way to fix this. Finally, I don't know if it is you or Freethinker that curates these set of resources in the CRP, but jool exo liquidhydrogen has a max altitude and min altitude both equal to .1, making them effectively nonexistent.

Just as a confirmation, I went in and found that the AM bug was extremly simple (somone forgot a .cfg in the filename), and even with the AM properly generating, the long range profiler shows zero across the board.

Tried both. By the time the ship is large enough that the rotation does not start immediatly, it is frail enough that only the smallest bombs avoid rapid detachment of the engine from the rest of the craft. Even then, the rotation still builds up over time, and the SAS typically is not strong enough to counteract it. Could one of the model transforms be off? This is tested on the medusa, BTW. the orion can be worked around, as it has gimbal.

Both the medusa and the orion seem to be producing a very large amount of torque. any ship that does not have ridiculous amounts of reaction wheels goes into an immediate spin. The orions gimbals can handle it, but the medusa does not have a gimball...

This isn't just antimatter, but hydrogen, He3, and Deuterium as well. Liquid hydrogen, at least, is generating correctly, and can be sensed at the location of the sensor, as well as gathered, but it does not show at range using the abundance with range graph tool. I also saw nothing with AM, and assumed it was generating but not showing. Didn't check the entire kerbin orbit, though.

I am having the last 2 problems as well, also on linux.

I should emphasize, the resources are there, but the scanners arent showing them at range.

Brand new save for 1.5.1

It seems that the antimatter detector and the imaging spectrometer always return zero when doing the ranged scan. I can even manually hunt for kerbins antimatter belt (through the resources here display), and take a profile, and it is zero at every range. Tried with both the release .dll and the dev one you provided to someone else.

Anyone had any problems with this on 1.5.1?

any idea if the mks merge will be save breaking? (will I be able to do a clean upgrade from the current constelation to the future mks)