Psycho_zs

Sadly, no realistic exhaust plumes... yet.

Considering support of thrusted timewarp, this would be a great scenario.

https://www.videogameschronicle.com/features/interviews/an-in-depth-conversation-with-the-creator-of-ksp2/ Well, they will have engines similar to the Epstein drive because of their torch-ship qualities But they mention Orion and ICF engines among those. So the similarity is rather stretchy.

In KSP 1 crafts are structured as trees, with every part having a single parent down to a root part. This is a limitation for the building process, which manifests itself in the way radial decouplers are used, inability to form structural loops, multiple pylons etc. There is a multidock capability (and Recoupler mod that uses it to simulate multipath constructs), but it is not trivial to utilize it. So I wonder, will there be any relevant changes in KSP 2?

This in stock would be awesome.

(Edit: whoops, wrong thread.) Anyway, they aren't putting Epstein drive in the game. But yes, metallic hydrogen is a bit too speculative for a non-magic tech.

Persistent thrust confirmed: https://www.videogameschronicle.com/features/interviews/an-in-depth-conversation-with-the-creator-of-ksp2/ We’ve had to overhaul the map view and map system to allow you to plan a continuous acceleration trajectory, and of course we’ve had to add a couple more levels of time zoom because many of these voyages take years and we don’t want you to have to literally sit at your computer for years.

LF/OX was referred to specifically as methalox. There will be metallic hydrogen as next step.

More generally and importantly, persistent thrust, propulsion during analytical timewarp - that would be a killer feature. And judging by burn-flip-burn kind of travel mentioned in one of the interviews, there is a good chance of it being implemented.

Scalable universe as a difficulty setting... We can dream, right?

The main hurdle in KSP is physics. In two parts: poor performance of Unity's physics engine (or the way it was used in KSP 1) and soft body model not being the most appropriate choice for simulating rockets. They might fix or smooth over the first problem (it's one of their stated goals), but we have no idea yet of what (if anything) they are going to do with the second. That german interview featured pre-alpha footage of some extremely floppy rocket, same undampened springy noodle motion, it seems.

First of all, YES! HELL YES! [snip] Second of all, what engine is it based on? Also, any word on Linux support?

Slick engine, performance, performance, Linux support, performance, everything from KSP with a facelift (which is already covered to spare and then some, judging by trailers), a potential for expanding it, stock procedural exhaust plumes. Oh, and also performance! Damn, what a great time we live in!

Just tried with a clean game, same. It seems the game does not report docking. 7:39:12 messages are from successful proper docking, with the first message here from stock game, I presume. Then just silence, despite a couple of dockings happened since. [LOG 07:39:12.491] Docking to vessel Docktest [LOG 07:39:12.493] [DR:d:13108] DockRotate.VesselMotionManager+StructureChangeInfo.isRepeated(): set Ids after [LOG 07:39:12.493] [DR:d:13108] ... .reset() BeforeChange after Ids [LOG 07:39:12.493] [DR:d:13108] ... .isRepeated(): set Ids after reset BeforeChange [LOG 07:39:12.494] [DR:d:13108] ... .reset() BeforeChange after Ids [LOG 07:39:12.494] [DR:d:13108] ... .isRepeated(): repeated JointUpdate after reset BeforeChange [LOG 07:39:12.494] [DR:d:13108] ... .isRepeated(): repeated JointUpdate after reset BeforeChange [LOG 07:39:12.497] [DR:d:13108] ... .isRepeated(): repeated Action after reset BeforeChange [LOG 07:39:12.499] [DR:d:13108] ... .isRepeated(): repeated Action after reset BeforeChange [LOG 07:39:12.511] [DR:d:13108] JointMotion.get(): created JM:-463244:dockingPort2:1929589575:None>dockingPort2:1321144049:None [LOG 07:39:12.511] [DR:d:13108] JM:-463244:dockingPort2:1929589575:None>dockingPort2:1321144049:None.updateOrgRot(): -0.04845664° [LOG 07:39:12.512] [DR:d:13108] MDR:dockingPort2:1321144049:Target.doSetup(): joint PJ:dockingPort2:1929589575:None>dockingPort2:1321144049:Target [LOG 07:39:12.512] [DR:d:13108] JM:-463244:dockingPort2:1929589575:None>dockingPort2:1321144049:Target.updateOrgRot(): -0.04845664° [LOG 07:39:12.512] [DR:d:13108] MDR:dockingPort2:1929589575:Host.doSetup(): joint PJ:dockingPort2:1929589575:Host>dockingPort2:1321144049:Target [LOG 07:39:12.512] [DR:d:13108] ... .autoSnapStep() = 30 from snapOffset [LOG 07:39:12.513] [DR:d:13108] ... .autoSnapStep() = 30 [LOG 07:39:12.513] [DR:d:13108] MDR:dockingPort2:1321144049:Target.autoSnapStep() = 30 from snapOffset [LOG 07:39:12.513] [DR:d:13108] ... .autoSnapStep() = 30 [LOG 07:39:12.513] [DR:d:13108] JM:-463244:dockingPort2:1929589575:Host>dockingPort2:1321144049:Target: autosnap at 30 [LOG 07:39:12.514] [DR:d:13108] MDR:dockingPort2:1929589575:Host.enqueueFrozenRotation(): (0, 0, 0) -> (0.05, 5.00, 0.00) [LOG 07:39:12.515] Camera Mode: AUTO [LOG 07:39:12.519] [DR:d:13108] JM:-463244:dockingPort2:1929589575:Host>dockingPort2:1321144049:None.updateOrgRot(): -0.04845664° [LOG 07:39:12.519] [DR:d:13108] MDR:dockingPort2:1321144049:Target.doSetup(): joint PJ:dockingPort2:1929589575:Host>dockingPort2:1321144049:Target [LOG 07:39:12.519] [DR:d:13108] JM:-463244:dockingPort2:1929589575:None>dockingPort2:1321144049:Target.updateOrgRot(): -0.04845664° [LOG 07:39:12.519] [DR:d:13108] MDR:dockingPort2:1929589575:Host.doSetup(): joint PJ:dockingPort2:1929589575:Host>dockingPort2:1321144049:Target [LOG 07:39:12.647] [DR:d:13109] V:1889886728:probeStackSmall.KJRNextCycleAllAutoStrut() [LOG 07:39:12.658] [DR:d:13109] JM:-463244:dockingPort2:1929589575:Host>dockingPort2:1321144049:Target: enqueueRotation((0.00, 1.00, 0.00), 0.0485°, 5°/s, 0°/s), added [LOG 07:39:12.658] [DR:d:13109] MDR:dockingPort2:1929589575:Host.updateFrozenRotation(CHECK): (0.0, 5.0, 0.0) -> (0.0, 0.0, 0.0) [LOG 07:39:12.660] [DR:d:13109] V:1889886728:probeStackSmall.KJRNextCycleAllAutoStrut() [LOG 07:39:12.919] [DR:d:13118] JM:-463244:dockingPort2:1929589575:Host>dockingPort2:1321144049:Target.updateOrgRot(): 0° [LOG 07:39:12.919] [DR:d:13118] P:dockingPort2:1929589575:Host: rotation stopped [1], 0.26 electricity [LOG 07:39:12.950] [DR:d:13119] JM:-463244:dockingPort2:1929589575:Host>dockingPort2:1321144049:Target: removing rotation (done) [LOG 07:39:12.950] [DR:d:13119] VMM:-437648:1889886728:probeStackSmall: securing autostruts [LOG 07:39:12.951] [DR:d:13119] V:1889886728:probeStackSmall.KJRNextCycleAllAutoStrut() [LOG 07:39:12.951] [DR:d:13119] ... .KJRNextCycleAllAutoStrut() [LOG 07:39:15.239] [AsteroidSpawner]: No new objects this time. (Odds are 1:2) [LOG 07:39:22.865] [DR:d:13435] DockRotate.VesselMotionManager+StructureChangeInfo.isRepeated(): set Part after reset BeforeChange [LOG 07:39:22.865] [DR:d:13435] ... .reset() BeforeChange after Part [LOG 07:39:22.934] [DR:d:13436] JM:-463244:null.OnDestroy() [LOG 07:39:29.570] [PlanetariumCamera]: Focus: Docktest

Timewarp does nothing. Upon loading a quicksave everything goes back to normal and angle correction happens.

I've tested with debug dll. Most of the time autosnap works fine, but sometimes something fails, angle is reported as NaN, and angle is not autocorrected. A couple of successful dockings, last one produced NaN. I was able to reproduce it only a couple of times, most attempts were successful.

Oh, that explains it. * me looking at numbers in CryoEnginesRestock patches two days ago:

Yes, full realism. Snapped ports autocorrect to the nearest snapOffset to simulate docking latches.

30, same as in realism config.

Some controls are still visible in PAW. Ports have: captureMinRollDot:NEEDS[DockRotate] = 0.99904822 snapRotation = true DockRotate.cfg has: autoSnap = true hideCommands = true What does autoSnap do exactly? In one attempt with autoSnap=true in config I've got 179 degrees, but in other attempts with debug version and both switching autoSnap back and forth, I always had round numbers.

Maybe a pre-release? Github allows tagging as such.

Cool! It's in current master I presume? I will try it within a day.

Hi! Any chance of finishing restricted mode? (no rotation controls for snapped docking ports, only auto correction)?

Optimizations in general and physics overhaul in particular. I'm hesitant to buy a computer with over the top last gen CPU just to play KSP. And my i7-6500U can barely cope with it.

@JPLRepo To clarify mechanical nuances, because phrases like "you seem to have mixed the two..." and "by setting ... to have no motor" being put together create a bit of ambiguity: Are hinges motorized or free-moving or switchable? Are hydraulic pistons complex parts (like struts/pipes)? What I'm trying to ask is, is motorizing a hinge consists of changing hinge's parameter, or adding a piston between hinged parts? ...or any which way?