KerikBalm

Setting aside the debate as to what physics is and is not settled, and if KSP2 should include engines with no current theoretical basis behind them (even if there was a former basis, as would apply to Aether propellors), my comment was directed towards the Gameplay Concerns/Implications. @Fullmetal Analyst was concerned that the LANTR engine would make getting to orbit too easy. As mmH would outperform a solid core (as this seems to be) LANTR engine, any Gameplay Concerns about LANTR enginges should apply even more so to mmH engines. Furthermore, as it seems that KSP2 will make engine-radiation a factor in gameplay, and a mmH engine would not emit radiation, the Gameplay Concern that a LANTR "engine will make the game too easy" should really not be an issue in comparison to the Gameplay Concern that a mmH "engine will make the game too easy".

So, no fix of the robotic drift bug, and no reversion of docking ports to the form that didn't cause robotic drift? Well... autostrutting will help... I guess this essentially means that ships will wear out over time though, as the robotic drift bug makes them more and more deformed.

Unless you have turned off terrain scatters to improve performance or make finding surface features easier. Regarding the Dress meme, I would contest that meme status equates with a high rating. Many things are memes because they are widely considered to deserve a really bad rating. Off the top of my head, twilight (the "still a better love story than twilight" memes for instance), and the 8th season of game of thrones.

Yea, its Meh, but Dres overall is rated so low that people joke that it doesn't exist. With Dres being about as Meh to me as Mun, Bop, Eeloo, Pol, Gilly, an overall comunity rating so low as to pretend it doesn't exist makes me consider it very underated relative to the other bodies

Hmmmm..... most over-rated? I can see a good argument for laythe, but I wouldn't say "just to see something identical to Kerbin", instead I'd say its because its like 95% featureless ocean. The appeal used to be flying planes on another celestial body, but because of BG, that also applies to Duna and Eve (and Jool too, I guess). I think other contenders are Minmus (its not that interesting aside from being close and having low gravity), and Duna - it, moreso than many other bodies, seems to lack fine scale detail - what you see from low oribt is pretty much what you'll see on the ground. The thin atmosphere isn't that thin, and landing with chutes is rather easy, not even much of a challenge. Under-rated: Vall: meh the whole body is just procedural noise. I'd say Moho, because its a fast but hard trip, with very frequent launch windows, and a great view of the sun. It really seems otherworldy being on the sun bakes side of Moho. Dres: It does exist, that canyon is cool, and the asteroid rings are interesting too. Ceres is an underrated dwarf planet in real life (It was a planet and lost its status before Pluto did!), and I think Dres is underrated because its real life analogue is under rated. "Eve, the best stock ocean world in my opinion" - Its a world that has some oceans, but I don't think its an ocean-world, any more than my modded Duna is an ocean world: but ocean worlds (where the vast majority of the surface is ocean, not 1/2 to 3/4 like Earth and Kerbin) can be a bit boring IMO . Eve is just too darn purple to me... and no its not really a good titan analogue I can accept purple water and coasts... like a primitive purple earth: https://en.wikipedia.org/wiki/Purple_Earth_hypothesis But that sky.... give me blue skies, grey skies, or even dull red or yellow skies... but that dark purple just seems... I dunno, depressing, oppressive? ughh... If I had to change eve, I'd make the skies closer to grey or blue, and the land some kind of grey. Purple water could stay

https://en.wikipedia.org/wiki/Tsiolkovsky_rocket_equation Its just a definitional thing. Its good that you could derive a measure of Isp on your own.

You forgot g: 9.81 m/s

Do you have a link to the mod that adds these? I've been looking for things to add underwater, and to kerbin in general. All I ended up doing was adding BG surface features to kerbin: On another note, I revisited my reusable 2-stage Eve cargoplane, which got 18 tons to orbit in a medium cargobay and ramp. That darn cargobay combination has a mass of 7 tons (10 tons for the longer version). That bay is seriously restrictive anyway. I thought about it, and I wondered, why am I building these things anyway? My original impetus for building these was that I wanted to construct to mobile modular surface bases. My thoughts were: 1) I can use a fuel truck/depot module to expand fuel capacity of the shuttle, and use it as a fuel tanker in addition to the craft to bring modules down to the surface to construct the base. - But a dedicated tanker craft is more efficient (less tedious repeated tanker trips), and taking modules down 1 by 1 is tedious, particularly on atmospheric bodies. Now with engineers and 1 storage container, I can even remove and put away parachutes after landing to save part count. 2) I could lift all modules of a base back to orbit, and bring them down somewhere else. I have never used this capability. The most I've done is land an ISRU module at a spot that wasn't carefully selected, to fuel up the shuttle, and then go back to orbit to choose a spot for the base more carefully, or to carry the ISRU around to collect biome data. I don't need to go ot orbit for that. I can do fairings a a couple chutes on Eve. I don't need the down-mass capability. And what do I really need the up-mass capability for? lifting up fuel for something in low Eve orbit (would this eve be more convenient than taking fuel from Gilly?). Lifting a few kerbals up? So I ditched the idea of an Eve shuttle with a cargobay.. bye bye to this: To be replaced by 2 different orbiters. One would be the fuel tanker. In place of the 2.5-mk3 adapter, mk3 cargobay parts, and 1.875m side tanks was simply 2 in line orange tanks, with an engine plate at the back (now 3x wolfhounds instead of 2x skippers). 2.5m rxn wheels and batteries became 1.25m ones. 2x solare panels became 1x. 4x canard control surfaces went to 2x. Big-S wings became Swept structural wings. 4x elevons became 2x swept elevons. Mass went down, dV went up, TWR went up (all considering 1440LF/1760Ox as payload). Any even smaller crew carrying orbiter was easily made. Instead of swapping out modules in the cargobay, I'm swapping out orbiters for different functions. With my new orbiters, I got to work optimizing my 1st stage carrier: The orbiter joins with the carrier by just docking on the ground. Landing gear spring strength is adjusted in case of alignment problems. They join unfueled, and are fueled up by an ISRU base on the ground. EC was limiting the max altitude on props, so I tried a gigantor based solution, trying to fly below the speed they snap off... results are... not great so far. Anticipating that the gigantors would work, I ditched 24 2.5 meter batteries (keeping 2), and added some wings (trying to improve ceiling on props, and also keep flight speed down so as not to break the gigantors) Anticipating a higher ceiling on props, I also removed 2x Kerbodyne S3-14400 Tanks replaced 8 vectors with 2 mamoths, removed another 4 vectors (I had anticipated an orbiter using 2x vectors instead of 3x wolfhounds, and I may want to revist that, so I can use crossfeeding to use those vectors). I was able to reduce mass from just over 900 tons to just over 700, at the cost of only 200 m/s (anticipated to be made up for by lighting engines higher in Eve's atmosphere)... It seems like I'm close to a much more efficient and practical system, but I'm still having a problem with supplying the EC. I could try spamming Ox-stat XL panels, but that would eliminate by part count savings... I don't want performance to suffer too bad. I wonder if the Ox-stat panels would be even better for performance, since they have their "physics significance" set to zero in the config. I think I'm going to mod the Ox-Stat-XL to have the same physics significance = zero setting, since 1 of those is identical to 8 of the ox-stats, and I want to save part count

Indeed, one causes drift, the other doesn't, so clearly there is a functional difference between the two. Yet they both allow parts to rotate relative to one another (unlike cargo ramps for instance, which don't allow a separate part to move with the ramp). I think if I want to keep using 1.12, and if htey don't fix it, I may have to keep a file for each craft, and cut and paste the original file from time to time. I really don't understand why it can't keep data on the original position, and not change that data. Keep the original position data, and if you also need to keep data on how much a part is extended/rotated/displaced, just have an option on the robotics/craft to reurn all parts to original/default position. It can't be hard to store the original position, I can do it with a text file. If they can't find an option better than my text file copying and pasting, then its pretty sad. This really should have been fixed before release of breaking ground.

I wish squad would chime in on this. I don't understand how they can make the claw, which allows free pivoting/rotation, work just fine, yet they can do rotation of docking ports

Kopernicus then scatterer the only two I use at the moment (except for mods depending on Kopernicus)

My question would then be if we can take some 1.12 files and add them to a 1.11 install, and thus at least have 1.11 with the planet overhauls. Regarding fixing the bug... if you say so that it is extremely difficult to fix, but as far as I can tell, all that is needed is to have reference values for part positions that do not change. I could accept robotic drift in robotic parts, because of the cost:benefit ratio. The added benefit was so great, and I could mitigate the effects by only relying sparingly on robotic parts, and having them mostly get saved when in zero G/ low G situations, where the drift occurs really slowly - craft in saves that didn't take measures to mitigate drift (because they were launched before I knew it was a thing), when drift is too severe, I launch a new one, and then edit save files to swap it out with the old one. This is only a couple ships... The cost(negative effects) could be kept fairly low. Now... docking port rotation is another situation entirely. Unlike robotics, docking ports are on almost every craft I launch. I dock modules of modular surface bases together... no way of avoiding high gravity there. My massive reusable cargo planes and rockets require redocking on the ground... The cost is now enourmous. The benefit? not having to redock a ship to get a pretty alignment?! The cost:benefit ratio here sucks. If they can't fix robotic drift, then they should absolutely revert the docking port changes. This is terrible.

Does this occur even in craft with no robotics and no docking ports? Are you saying that parts with no docking port/robotics attached suffer drift now if there is a robotic part/docking port anywhere on the craft? are you saying that parts with suffer drift now even if there is no robotic part/docking port anywhere on the craft? This is a critical bug, and one that cannot be left unaddressed. They can't have the 2nd to last update of the game kill all long term saves, and leave it like that!

The problem is that this is not my area of expertise, and I am skeptical that your (most likely similarly non-expert) opinion of their methods is accurate. However, I have seen a lot of bad science and bad logic recently by prominent virologists wanting to shut down debate on the origin of a certain virus, so I am somewhat open to the idea of fields where dogma trumps good science/logic (I suspect this happens a lot in economics as well). That said, if the planet is warming, which it certainly seems to be, it seems logically sound that the total ice cover on land would decrease overall (there could be specific regions where it gets thicker), and sea level rise is thus expected. The effect of complete melting of ice sheets on land is fairly straightforward to calculate, and thus the risks of sea level rise a sa result of climate change are there, even if the dire effects of the sea level rise haven't yet manifested.

https://essd.copernicus.org/articles/10/1551/2018/ and similar articles https://link.springer.com/article/10.1007/s10712-011-9119-1 https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5834701/ etc...

*cough* metastable metallic hydrogen engines *cough*. This either won't be a problem, or won't be a problem specific to the LANTR engine. Go here, and try out Porkjet's LANTR engine mod for KSP, and tell me if you find it OP'd: Plus, radiation seems like it will be a concern in KSP2, thus this engine will be more limited than metastable metallic hydrogen engines. So as far as gameplay, this should be less of a concern than what has already been shown. Also, in terms of realism, its orders of magnitude more realistic. There's no reason to criticise the inclusion of a LANTR engine into KSP2, as far as I can tell, without criticizing something else much much more.

Yea, I often have problems typing in a password correctly, or trying to compose an email, etc. I've also had similar problems trying to solve simple math problems in dreams

Ughhhhh, they *need* to fix robotic drift, now that it applies to any craft with docking ports. This will kill most of my saves with time.

They are supposedly going to add a lock feature in the next patch. Iirc, locked robotic parts stop functioning as robotic parts... I think this means that locked docking ports and robotic parts won't cause drift. I will always have my ports locked in place. Since they essentially added a robotic part to vanilla KSP, it would be just great if they could fix the robotic drift bug in the last patch. It really can be crippling for long term career saves, if you decide to make a key craft use robotics

Do you mean inclination right after launch, during ascent? When your orbital velocity is very low, it doesn't take much to change inclination, right as you launch, you are essentially at apoapsis of a very elliptical orbit that intersects kerbin's surface, with a very low orbital velocity at that apoapsis

Hmm, in my "high altitude" pics above, between 10,200 and 10,900, and nearly 140 m/s, dynamic pressure was exceeding 26 kPa. Looks like I will need a lower wingloading, or to see how it handles at a higher AoA. (I think I can drop some fuel and an engine pair if I have the power to climb higher) Angle to the relative wind seems to matter too though, so I wonder how much AoA they can take before breaking

I tried that, starting extended, with the base inside a fairing, it gets drags and breaks. Starting retracted, it gets no drag, but gives a message that it can't deploy

I thought I used to be able to node-attach gigantors, but I'm trying it out now, and they all seem to be radial attachments... even when put on nose cones. Consistent breaking at 180 m/s... I even removed all rescale mods to see if that had anything to do with it

Well, extending them backwards is what I had in mind when I said "I was thinking that if I had them parallel to the direction of travel, they probably shouldn't break. " I didn't plan on using small nose cones, just surface attachment and the rotate and offset tools, since their base is fairly thick anyway. I am trying to keep partcount down though (the craft I want to use them on has a ridiculously high part count (>300) and I am looking to reduce it. To put on 8 gigantors that way makes the part count go to 16... which makes it similar to the part count for fuel cells arrays... Well, I had some time to test yesterday. I mounted some on my quad tilt rotor cargo craft, which is normally capable of about 320 m/s, and I think I got to about 160 m/s before they snapped off. I am surprised that yours didn't snap off in that pic above where your craft orientation deviated by several degrees from your velocity vector. I have a few hypotheses: 1) Even going backwards, they have non-zero drag, when drag exceeds a certain value, they snap. pointing them backwards reduces, but does not eliminate drag. Gigantors will have a speed limit for various atmospheric pressures. I think at higher altitudes, this wont be a problem 2) The exposed node in my setup creates more drag, which results in it snapping sooner than on your plane. 3) My craft's wings have some incidence (5 degrees), at high speeds, the velocity vector points above where the nose points, this results in negative AoA, and this non-zero AoA may be what breaks the solar panels. I think it may be workable to have gigantors deployed on Eve, and then retract them just before lighting the rockets. I'm also thinking of adding a free-floating hinge, with a starting 5 degree tilt (to match the 5 degree incidence ofthe wings), with solar panels and some wings attached to it with. I'll try giving the wings some ever so slightincidence (not the 5 degree snap rotation, but maybe 1 or 2 pixels of non-snap rotation). The point of the wings would be to lift the hinge ensure that the angle of attack of the hinge and the solar panels very close to zero. Before lighting rockets, retract the panels, then light rockets, go suborbital, and then I think I will power up the hinge, and lock it in place for the descent, it could help with stability on reentry too... I think further part count reductions can be made via replacing 8 vectors with 2 mammoths... I also note that nearing its previous max altitude (it was "max" because it started to run out of power), the rotors were not strong enough to maintain 460 RPM (that screenshot shows 346 RPM). I'm counting 12 sets of 8 turbine blades... that's 96 parts for prop blades alone. If I reduce them to sets of 6 instead of 8, I save 24 parts. Perhaps with more EC generation, I can get to a higher altitude, and I won't need as much fuel for the suborbital 1st stage, and I can get a virtuous cycle going. As you see here, despite tons of batteries, it is my power consumption that was limiting my altitude: Climb rate was still a decent 9.67 m/s... AoA was still quite modest, so maybe the free-floating hinge idea is not needed

The point is to have fun overcoming challenges that you set for yourself.