KerikBalm

Link to the mod, what does it do?

I would rather have mass drivers and beamed power propulsion. Gotta love massive laser arrays that with a little tweaking turn Mun into the death star....

A photon drive would be either: 1) Antimatter powered: likely going to be in game 2) A solar sail: would be cool 3) A light sail, and some laser installation: ie beamed power propulsion, I would love this (and beamed power need not be limited to light sails) 4) Massively inefficient if powered by anything other than antimatter or solar: (if using a fusion reactor, throw the reactant mass back at high speed for more thrust per unit fuel) Regarding the light/solar sails: Using solar panels instead would be massively inefficient, and would be massively heavy for the miniscule thrust. Photovoltaics would be far less efficient than just reflecting the photon, they would be far heavier, and they would not be able to take nearly the same light intensity... very very very low TWR as a result. magnets do not contain photons

Better have a kerbal on it, and a probe that grants SAS, no? Besides, I want to be able to control probes without a connection (should just be required for data)... real probes can do things on their own without a connection, just as an astronaut can. A probe core should be able to analyze its surroundings, take measurements, and plot a course on its own. Real probes can. Of course, I don't want autopilot, I want to pilot the craft as if I am the probe's AI. Bah, I just set up a simple relay network if that is the case. Avoiding communication blackouts back to Kerbin is easy. I'll want those anyway for science transmission. yea, scientists and engineers are all I really need... and really just scientists, but engineers are nice to speed things up, and the craft modification does make things interesting now.

To be clear, the game seperates thrust and lift, and what you are discussing is lift. Well, real helos do this by cyclic, and we now have cyclic, but I think the blade disk needs to actually tilt. I think that just relies on flexing in the blades. I think KSP 1 already could model this if they had an appropriate control algorithm But real tandom rotors do change the amount of "thrust" on different sides. That is how realistic heli dynamics would work. I think KSP just doesn't know to apply left roll cyclic to the front rotor and rear roll cyclic to the rear rotor. I get around this by using quad copters, or hinged rotors.

I doubt that we will see anything other than 1 "real" terrain surface. That doesn't mean that you can't have cave "objects", as we saw to a limited extent in the Tylo cave, and sort of with the Mun arches (I believe you can find some colonies hanging from those in Youtube videos). The Arma series also has terrain with just a single heightmap (thus one "real" terrain surface), but there are small caves in the official maps that are composed of walkable objects such as boulders. (similarly, it also supports bridge objects that can be driven over, and the Ai can osrt of handle it). Then there a number of user made maps where they just assign a very low elevation to a place (ie, make a pit), and fill it with a 3D cave/bunker object. If KSP1 had the Tylo cave, I expect KSP2 to have some sort of Cave object - but I expect them to be limited in size and number, and sort of be easter eggs.

It seems that there's at least one prediction that was pretty accurate...

I don't disagree with any of that, I am just saying, it seems strange to express concern that this LANTR engine makes getting to orbit too easy, given what has already been shown... In particular the mmH engine, as it has none of the radiation drawbacks (aside from the torch ship drive and the Orion drives, it seems likely other interstellar drives will be put on craft that must be built in space - and the Orion must have some other engine for the initial liftoff, or you destroy the colony)

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