jeancallisti

According to the forums' descriptions, I don't think you should have moved it. It's about neither directly KSP 1 nor directly KSP 2. It's more about a fantasy KSP clone. What could have been done of the KSP1 code base when the development of KSP 2 started.

I am in no way saying that this is the only way to make a better KSP or an actual KSP 2; this is just what *I* would do if I had the time, budget and expertise. Please take in consideration that I know how to program professionally; this is not coming out of nowhere. Finally, this is a technical post, this is not at all about the game mechanics. It will be nerdy and boring. IMPORTANT: the model below would not leave enough computing power for a "pretty" game. All the power goes to computing physics. The game would look ugly. 1) I would not start with implementing space, instead I would start with TIME. I would implement the ability to have more than one timeline, and branching between those timelines. Or at least, I would lay clear concepts to divide that paradigm into smaller problems. Think "git" but applied to a KSP game: just like git has branches, commits, merge, rebase, squash, etc... Here we would have timelines, snapshots, etc. Each parallel timeline would be a succession of "snapshots" of the player's universe. You think it's weird and impossible? Well, this exists more or less already in KSP 1 as part of the so-called "multiplayer" plugin. Vanilla KSP lets you fast forward time, but on top of it the plugin lets you do more: you can create alternate timelines and it lets you "resync" them. Implicitly, it means a primitive form of "rewind" by reverting to snapshots. 2) I would think about how to SAVE those snapshots Those timelines are a succession of snapshots. Unfortunately, the player spends most of their time playing "real time" in KSP. It would be too resource-intensive to save the entire flow of events. The only way is a) to restrict the moments in time when the engine can take a snapshot, and b) to make it possible to reconstruct/interpolate what comes after until the next snapshot. It's a matter of making decisions (i.e. RULES), and sticking to it. Consider KSP 1: it already forbids you from saving when you accelerate, or are in the atmosphere, etc. (I can't remember exactly if those restrictions have been worked around, but my point is that there are rules). It means that the INITIAL CONDITIONS after a savinga snapshot are UNAMBIGUOUS; with a bit of effort, the engine could more it less reconstruct what happens to a craft until the next snapshot To give you an idea (among many real-life examples), you can imagine how a video codec works: it can compute the next few seconds of video by using (a) an initial state (a full screen image) and (b) a little bit of computation/incremental data (the minimum amount of changes between each video frame) I did not detail here the tricks I would use to work around complicated situations, such as a craft under acceleration, or a craft entering/exciting a sphere of influence, etc. That will come after . 3) I would start with applying this discretization of time to CELESTIAL BODIES it would be absolutely crucial to be able to find the position of every celestial body relatively quickly, as far in the future as we want. If you ask an astronomy geek, they will tell you that it's impossible, because computations on multiple bodies creates a chaotic system (in the physics sense), i.e. incredibly heavy (nearly impossible) calculations But again, for a videogame it's a matter of setting rules, to simplify and calculate only what's needed (while swiping the difficult bits under the rug). Illusion! In the case of orbits I would stick to simple systems: a) the sun is central and immutable, b) the planets don't interact with one another, c) satellites don't interact with one another. If you need a two-bodies system (i.e. Neptune so heavy that it deviates the sun) then hard-code it. The position of each satellite is an offset to add to the position of its parent body. No complicated conics, maybe a simplification relying on segments of hyperboles or a handful of carefully chosen Bézier curves. But remember that the whole engine is snapshots-oriented. You can't save every point (in time and space) of every orbit of orbits. Therefore, even the "simplified" orbits would eventually be broken down to a set of points with a LINEAR resolution between each point. between point A and point B, we decide that the celestial body travels at constant speed, in a straight line. We can smooth out the change in speed between each point (again: linearly). Here I don't explain how to save the points' positions with enough precision; I will explain further. Side note 1: A good idea would be to snapshot the positions of the Lagrange points, additionally to the positions of the celestial bodies. Side note 2: there's still the case of random asteroids, like in KSP 1. I would make them pop in and out of existence randomly, but following a system of seeds (i.e. you can predict where and when it appears). then the engine can compute the asteroid's position based on that initial position and speed, but only IF it needs to, i.e. IF the player decides to interact with it. 4) Discretization of space Like the original Dev of KSP wrote in an old blog post, one of the challenges of such a game is that the engine needs to manage a 3D space at a scale a of a few centimetres (does your kerbal's foot touch the ladder?) all the way up to astronomical distances. This is resolved (on paper and in some way in KSP 1) by managing space at TWO different scales: the "SMALL-ISH" scale, i.e. everything that's close enough to the craft to be managed natively by the physics engine with sufficient precision. And the "LARGE" scale, which is more or less doubling or quadrupling the precision of floating point numbers by adding an extra 32, 64, etc. bits. Possibly in a separate variable that rarely changes. In other words, the 3D space is a kind of VOXEL. The "secondary" number where you store the "large" position of a craft is the equivalent of the CHUNKS in Minecraft, and rarely changes. But I would push the concept further, by developing a kind of space discretization more suitable for orbital mechanics. Let's call it SPHERICAL VOXEL. For as long as a craft is within a sphere of influence, you could define its location above the surface by using its latitude chunk and longitude chunk. And then of course within each chunk, use a regular floating point position. The interesting part would be the altitude: you could define vertical chunks that are NOT divided linearly, but instead exponentially, to reflect the rapid decrease of gravity as you go up. However, still following our concern for snapshots and requirement for minimal storage needs, the gravity change would be resolved linearly within each vertical chunk (with a linear smoothing as we transition from one chunk to the next) Going back to discretization of space: when the craft is NOT within a sphere of influence, we save its position in a regular cubic voxel, with its initial position, direction and speed at the edge of the voxel, and since we know what forces are applied to it (both because of our simplistic model for celestial bodies positions and because we have strict rules for snapshots) we can calculate its position as simply as possible at any point in time until the next snapshot. It's trivial to determine when an object leaves the cubical voxel to enter the spherical voxel, as it's directly related to its distance to the celestial body. 5) collisions The double voxel system described previously (both the cubical voxel and the spherical voxel) lets us determine quickly when two objects are far enough apart from one another to NEVER collide. That is, when they are in two different chunks. Any object going at extreme speeds might require extra care (the problem arises when it's going so fast that it skips several chunks between each game tick) but that's still resolved reasonably easily by following standard algorithms -- similar to netcode algorithms (simulating continuous movements from discrete data, like when counterstrike's net code determines if a projectile hit you). As a fallback you can decide that if a craft goes that fast then it should disintegrate! Or that you "lost connection" to it. Or create an entirely new model for crafts going at extreme speeds. Anyways, once you've asserted that a craft can only go from one chunk to its neighbour chunk then you can compute what craft might collide with what other object within one chunk, both in time and space. Once again we rely on our extensive use of linear resolution of trajectories (or, at worst, polynomial) to cast "rays" (in the 3D graphics sense) and determine if the relatively tiny objects that are crafts (in the immensity of space) do collide within the large chunk. Let the physics engine do the rest, as the crafts are in fact rigid bodies. 6) rigid bodies This paragraph is secondary to the whole system, but here's an idea: each craft part (tank, engine, antenna...) should in fact be designed from the beginning as a set of attachment points and struts/metal beams. Not literal struts or literal metal beams, of course (we don't need to see what's inside the craft's part!). But the physics engine should be fed the rough structure of the part, to know where it should bend and where it should break. For example, a tank should not secretly be just two attachment points connected by one single vertice (with a pretty cylinder mesh slapped onto it as a skin). Instead it should be a handful of vertices arranged in cylinder shape, representing its inner metal beams. The physics engine would work with those so-called beams and calculate the constraints on them, like in the video game Polybridge. Pretty standard stuff. KSP 1 already did an embryo of that when it introduced actual struts as well as autostrut. But while that "physical mesh" should remain hidden to the player during a flight, its existence should be made explicit (for example, through a new overlay in the VAB). The actual mesh of the part (the one visible to the player) would only be cosmetic. That mesh could even distort, following the "physical" mesh's distortions, by using a simple displacement shader. Only if the physical mesh gets "too distorted" then the part gets ripped off the rest of the craft, or explodes. The rigid body that is the part doesn't need to have MANY physical points (that would require too much GPU). In fact, it needs very few points, the same way a collision is very often just a cube. Just enough to make it interesting. This way ships could break in other places than just the attachment points between parts. And they could bend in unpredictable ways. no, I'm not advocating for KSP2's floppy rockets. Quite the opposite. 7) weather use the standard way of generating weather and volumetric clouds in a game (seed-based pseudo-random noise) and keep it as deterministic as possible to shoehorn it into the snapshots and voxel systems. To put it shortly: 3D Perlin noise creates shapes in small cubes, that you can interpolate linearly. Just like our voxel. They fit together. 8) aerodynamics The "Ferram aerospace" plugin lays the path for proper aerodynamics. It uses voxel, but it has nothing to do with our voxel system. The main goal would not be to have "accurate" aerodynamics (that comes as a bonus) but instead to pre-bake as much aerodynamics-related data, in order to alleviate the GPU 's work as much as possible when resolving/predicting the trajectory of a craft. In other words: from the pre-baked model, try to extract some discrete aerodynamics behaviours (craft angled 0°, craft angled 10°, etc.) and make heavy use of those simplifications while maintaining a reasonable level of detail in the flight behaviour. 10) resync'ing of timelines I've come full circle from time to "orbit-scale" space to "craft-scale" space. It is now obvious that some aspects of the game can be resolved on-demand by the engine (snapshot, rewind, fast-forward, etc.), such as the position of celestial bodies and the position of crafts that are in orbit, while some aspects are still out of reach (such as the position of a craft submitted to aerodynamic forces). The time has come to explain how I would resolve that. Imagine you're flying a craft in the atmosphere and it separates into two crafts, each with a guidance system. 1. Both crafts' flights still need to be managed by the game engine. None of them becomes a falling brick. The engine needs to be robust enough to handle as many crafts as are present in the current voxel chunk, even if it means a drop in frame rate (no skipping allowed for the physics engine!!!) 2. When one of the crafts gets "far enough" from the craft currently being flown, the engine applies a simplified flight trajectory to it just to show it on screen, but that trajectory means nothing. The engine marks that "fake flight" as "unresolved". The player can no longer switch to it. 3. In order to "resolve" what became of that craft, the player needs to (a) finish flying the current craft until it becomes possible to create a new snapshot of this timeline, then (b) tell the game that he/she now wants to "resolve" the flight of that other craft. Then (c) the game obeys by reverting to the snapshot taken when that craft went too far from the original craft, and (d) lets you fly it until it becomes possible to create a new snapshot for that craft. Those two crafts now have different timelines, and both are resolved as far as the player flew those crafts. But what if the player flies the second craft close enough to the first craft again? That's the interesting part. The two timelines become reunited temporarily. If the crafts don't collide then the timelines separate again, possibly without changing the snapshot created previously (i.e., created AFTER flying the first craft to completion). But if the crafts collide, then the two timelines get reunited permanently (and any subsequent snapshots they might have had get deleted). After the collision, if they get separated again, then Both crafts' flights need to be resolved again, separately, just like before. Please note that an "unresolved" flight can remain unresolved indefinitely. The incentive for the player to resolve a flight is that if they don't, then the craft never lands or never crashes, and the player can never recover the parts. unresolved flights could be displayed in the tracking station, just like any other craft. 11) resync'ing of timelines in the distant future Everything I'm about to describe was already a paradigm in the multiplayer plugin of KSP 1, and we know from Dev interviews that the KSP 2 team had similar ideas as what I'm about to present. Imagine this scenario: 1. you take 10 days to fly a craft to, let's say, the Mun, and you lend it there. That craft is named "MISSION A". 2. The game engine can assert that could repeat that flight as many times as you want, given the same resources and the same time to travel. Therefore, if the player requests it, the game can create a "commercial route". It can even assume that the same amount of fuel that was left in your craft when you landed will be present on any subsequent "automated" craft landing on the moon. It does not need to simulate each and every craft . That's the trivial part. now for the fun part: 3. Imagine you revert to the timeline snapshot just before MISSION A departed. Now you decide to launch a new MISSION B. 4. that second fight takes only 4 days to fly to Mun, because this time you flew better. It lands in the exact same spot where MISSION A will land 6 days from now. 5. We can let the player play with MISSION B as long as he/she wants. If that craft leaves the surface in less than 6 days, then nothing special happens. BUT.... Here comes the catch! If MISSION B stays 6 days then we know that it occupies the same surface chunk as MISSION A. the two timelines need to be resolved! The player is notified of it and needs to keep playing one of those crafts for as long as they're within potential collision distance, otherwise the flight is marked as "unresolved" as we explained before. 12) actual cooperative or competitive multiplayer? By the way, this mechanics allows for real multiplayer in KSP. However, not real time. It would be fun to imagine game modes where there's a game master who can decide who can rewind time, and how far back. Or each player can rewind time only a limited amount of times. Etc. 13) landmarks [A somewhat dumb and out-of-place] addition to this long post.] I find it strange that KSP 2's engine was not immediately able to handle the KSC properly (from a rendering perspective). Each large landmark at the surface of a planet (whether be building, arch, cave, solar flare, etc ) should be modelled at several levels of detail. Low-poly version for everyone as soon as you get away from it! The collisions work with the low poly version at high speed/large distance, or with the full details at short range/low speed.

Thanks!

So I built that perfectly standard medium-small jet plane and wanted to see how fast it could go. It has Panther engines. I was extremely surprised to discover that if I add a pair of mk12-r parachutes on it (the smaller, orange ones), it caps around at 380m/s, whereas as soon as I remove the parachutes it almost goes up to 700m/s. I did several tests; with and without. With and without. I even deleted and re-added the parachutes to be sure that there was no glitch. The parachutes are definitely the culprits. This tiny pair of unopened parachutes almost halves the top speed of the plane. Anyone has an explanation for that???

A warning to future readers : This kind of missions might be broken. I did this : - Built my "outpost" in the VAB - Sent it to Mun, as per contract - Landed there => All the ticks became green EXCEPT for that first main tick that gives a general description of the contract (and contains the "The outpost must be fully assembled when launched" sentence). I have no idea what the game didn't like in my build, and this thread is only moderately enlightening, as most contributors are mostly guessing. EDIT: The mission got completed the second I jettisoned the two small engines that were attached to the outpost (required to land it smoothly). It means that the mission description implies that an OUTPOST cannot have ENGINES.

Good suggestion, I'll try that!

Bump. Why does reloading a saved game temper with the mesh/object/collider and how do I prevent that?

Consider this pull request to the Kerbal-VR mod : https://github.com/Vivero/Kerbal-VR/pull/88 The changes to KerbalVR_Manipulator.cs adds a setting _overrideFingertipScale , as you can see here : https://github.com/Vivero/Kerbal-VR/pull/88/commits/19272b41219181e97dde7eb72f00f26daf92b415 This operates an on-the-fly modification to the fingertip's collider, to shrink it. fingertipCollider.transform.localScale = _overrideFingertipScale * fingertipCollider.transform.localScale; It works well. However an issue appears later: As soon as you reload a saved game, somehow the size is reset? The whole VR glove is somehow reloaded, but without the fingertip modification. I'm not familiar enough with Unity (that's not my mod) and I don't understand the lifecycle of objects, mehses and colliders so I don't know where to put the missing resizing. Does anyone have a suggestion?

EDIT: wrong thread

Thanks. I'm currently trying to tweak the VR mod to reduce the size of the collision box at the fingertip.

EDIT : All the DLLs were actually provided separately - https://wiki.kerbalspaceprogram.com/wiki/Setting_up_Visual_Studio

I know that the development has stopped, but does anyone have an idea of the size of the collision boxes of the small rectangular buttons around the screens? In this mod I've noticed two sizes of screens : The larger ones (that most IVAs have only once or twice, for special stuff like landing mode), and the smaller ones (that most IVAs cram everywhere possible in the cockpit). I've noticed that in VR it's much harder to click on the rectangular buttons around the smaller model of screens, even though those buttons meshes have ore or less the same size as the buttons of the larger model of screen. With the smaller screens you always end up clicking three buttons simultaneously. I'm wondering why. I'm suspecting the size of some sort of collision box for each button. Would that make sense? Has anyone ever had a look into the buttons meshes used by this mod? Note: I'm working almost exclusively with the RasterPropMonitors that are in the ALCOR landing can, if that's of any use.

Great explanations. Thanks so much.

I mean : does it add actual stock struts in important places automatically, or does it alter the parts' physical properties to make them less elastic?

Side-tracking discussion (3 questions) : Nowadays, what's the use for autostruts on a reasonably small rocket (100 parts, most of them small thingies like lamps, etc.) ? It seems fairly rigid to me, so would autostruts really be of any benefit? if I were to want autostruts, what's the mod that lets me add them with the least installation hassle? How do autostruts work under the hood? I want to play with DMP multiplayer and I don't want autostruts to mess with the ship's integrity in multiplayer, or had a gazillion "hidden" parts that would make the whole system lag.

Thanks! Happy happy me.

Dumb me ! I didn't even know this was a native feature of the game. After years of playing it, it's the first time I need to "cheat" instead of manually de-orbiting an object. Lol!

I'm looking for a quick way of deleting a vessel that's already in flight. I know I could go to the Vessels folder and delete the subfolders, but I'm looking for a more error-safe way (I want to avoid human mistakes with the many Vessels that have the same name, for example). Not to mention that there are asteroids there, annoyingly bloating the list of Vessels guids. I'd rather have a mod that lets me delete the flights in the in-game Tracking Station, for example, in a WYSIWYG kind of way. Is there such a mod or tool?

Someone told me in the Spectra thread that yes. I don#t know if they can be believed.

Bump

So here are my thoughts so far, with KSP 1.7.2 (and most likely 1.7.3) : VR : playing inside the cockpit (IVA) Works (with mod "Vivero") Minor issue : the pod's cameras and some other displays (displayed on the in-game RasterPropMonitor) don't work if you enable them in VR. You have to come out of VR, click the RasterPropMonitor's button in regular IVA with your mouse, and only then does it work. You can go back into VR and the monitor is still working. Other minor issue : the buttons around RasterPropMonitor are hard to click because the VR's virtual glove has a fat finger and is pushing three buttons simultaneously (the one you're aiming at and its two neighbours). It usually takes several attempts. I wonder if it's an issue with the smaller monitor's mesh rather than the VR because it doesn't happen with the other model of RasterPropMonitor (the larger one, with the Descent options, that's usually on the side of the cockpit). VR : Controlling the rocket in the cockpit with a joystick Works natively. The mod " Advanced Fly-By-Wire" (AFBW) helps a lot setting up the controls. First-person (not VR) : space-walk outside of rocket (EVA) Works (with mod "through the eyes") First-person (not VR) : Controlling the Kerbal in space walk (EVA) Still with "through the eyes" : With keyboard : works natively With joystick/joypad : natively, there's weird issue - the kerbal does not behave the same way as with the keyboard - it's almost impossible to make him stop spinning (no subtle stability assist that terminates the spinning, as with the keyboard) => I tried installing the mod " Advanced Fly-By-Wire" (AFBW) but it didn't help much. The issue seems to lie with the absence of stability assist rather than the controls. I ended up using external program "antimicro" to map the gamepad to the keyboard. That works well but it's not analogic control, it's keyboard control (key is on/off). There are probably programs equivalent to antimicro to do the same, but with a joystick instead of a joypad. Reminder : The "through the eyes", the keys are WASD + IJKL + HN VR: space walk outside of the rocket (EVA) Does not work for me : The camera is properly attached to the neck of the Kerbal and i can look around, but as soon as the kerbal starts moving there are issues (e.g. the rotation of the kerbal's body mesh does not induce a rotation of the VR camera's origin -- i.e. the Kerbal spins but you don't) This would probably work with a bit of fixing from the author of Vivero but he's not too active (see the issue I posted on Vivero's github)

Either. There are other outdated dependencies: Astronomer Visual Pack, etc. Also the thread of PlanetShine does not make it clear that it works in 1.7.3. Until you told me, I wasn't sure. Spectra requires a lot of manual installation, it's silly. But if you're telling me that it's by design, then fine. I just wanted to be sure.

Thanks, but.... This mod seems to be dead since 1.3

Can someone explain how this mod is labelled "1.7.x compatible" when several of its dependencies are not (e.g. Planetshine) ?