DancZer

These exhausts vfx is mutch better! Looking forward to see it in action! Are you planning to overhaul the reentry vfx to in line with reality? We got spectacular footage from SpaceX (I have seen you made notes there on X )

https://forum.kerbalspaceprogram.com/topic/218512-developer-insights-21-rockets-red-glare/

This was very informative! Thank you for sharing it with us!

If this would be done, it will be no KSP2 for many many years. Yeah, not 1-2 but 10+. You underestimate the effort. This would break the community and the franchise for sure.

Yes you are right. One solution for that to have an AI which is trained by reinforced learning, so it learn the essence of gameplay a can detect a kraken. Otherwise you can't.

Will the reentry effects work the same as the rocket exhausts? In low pressure environment it will be like in the dev chat, but on higher pressure the trail end would move inward? I wonder what parameters are available for the engine beside the length, direction and color.

How do you split resources regarding bugfix vs feature development? It looks like that you shifted toward the feature development and less effort in bug fixing.

I have a good news, I manage to setup the Joystick! Steps to configure it: Go to the settings and setup the pitch, yaw, roll for your Joystick Save your settings Navigate to c:\Users\<Username>\AppData\LocalLow\Intercept Games\Kerbal Space Program 2\Global\ Edit InputBindings.json Find every processors and add clamp(min=-1,max=0) and clamp(min=0,max=1) for each axes. Make sure you add the highlighted text between \" Save the file Load the game Navigate to the Settings and click on Input Do not modify any settings, otherwise the InputBindings.json will be overwritten and you have to start from 5. Load you campaign and enjoy the flight Background info: The reason it was not working, because when you configure your Joystick axes for the flight they add your axis two times (eg.: pitch up, pitch down like W, S). You can test it if you remove one of your Flight/Pitch the path value. Let's say we keep the Flight/Pitch up binding. If you load the game the same way as I described you will notice that no matter that you move your Joystick forward or backward the pitch will always go up. Joystick axes value moves in range -1 ... 1, but KSP2 internally transform this to absolute value. That's why no matter if you move it to -1 or 1 the end result will be always 1 and the pitch goes up. To solve the issue you can add clamp. This will remove the lower and upper part of your Joystick value range and it will not let the bindings go down in Pitch Up binding and up in Pitch Down binding. I hope it makes sense for you. KSP 2 uses the Input System package for Unity to handle input: https://docs.unity3d.com/Packages/[email protected]/manual/Processors.html#clamp Example: "{\"bindings\":[{\"action\":\"Flight/Pitch\",\"id\":\"27397e14-6a24-4bbf-8830-e3cc4ad3db69\",\"path\":\"<Joystick>/stick/y\",\"interactions\":\"\",\"processors\":\"clamp(min=0,max=1)\"},{\"action\":\"Flight/Pitch\",\"id\":\"1eff4572-25e9-4520-bd55-07a5f4415db3\",\"path\":\"<Joystick>/stick/y\",\"interactions\":\"\",\"processors\":\"clamp(min=-1,max=0)\"},{\"action\":\"Flight/Roll\",\"id\":\"d273a7bf-6efa-4915-acaa-dab56c2719a8\",\"path\":\"<Joystick>/stick/x\",\"interactions\":\"\",\"processors\":\"clamp(min=-1,max=0)\"},{\"action\":\"Flight/Roll\",\"id\":\"3627ecee-69c2-45ca-8f78-c0dad13257ef\",\"path\":\"<Joystick>/stick/x\",\"interactions\":\"\",\"processors\":\"clamp(min=0,max=1)\"},{\"action\":\"Flight/Yaw\",\"id\":\"fe5396d2-4c1d-4bf9-915b-1bdfd3d5cc39\",\"path\":\"<HID::Thrustmaster T.16000M>/rz\",\"interactions\":\"\",\"processors\":\"clamp(min=-1,max=0)\"},{\"action\":\"Flight/Yaw\",\"id\":\"ce110cb9-c1f9-43cd-a91a-0a02bfdae364\",\"path\":\"<HID::Thrustmaster T.16000M>/rz\",\"interactions\":\"\",\"processors\":\"clamp(min=0,max=1)\"}]}" I wish you the best!

I think the the only time based science which makes sense is that to things on the dark side (so when the star does not shine the area of science for longer period (cool down). When the cool down is done, you would be able do run your experiment, if you have enough resource to do that (eg power).

I would add complexity by kerbals for example or dependencies for science,so we would require build and deliver more and like what we really do (build + flight). Eg.: some science would require more kerbals to gather by dependency I mean we should find rocks: first a small dark one, then a gray bigger one and so on. In this case the "mini game" would be riding the rover. Bringing a heavy duty drill to dig deeper. Provide enough power, scientist and engineer to operate it. Edit: Limited time based science, you have to do science on the dark side (so when the star does not shine the place of science for longer period (so the instrument must cool down too and/or have to stay cool (termal management)). When the cool down is done, you would be able do run your experiment, if you have enough resource to do that (eg power).

Re-watching the video I noticed something. The object or more like the air in front of the object should be bright? Only the trail? Basically there is nothing bright in the front where the compression and the plasma is created. This plasma then goes around the body and shows as a trail, but I think there should be in the front too, isn't it?

Interesting idea and has a great potential.

I made a video where I added sonic boom under KSP2 footage. I tried to do the doppler effect too, but it was hard (probably because of the already high pitch engine (it is much lower in real world)). Turbine itself is high pitch (when no throttle applied), but the flame is a flame, so the sound should be similar to rocket flame. or this, but unfortunately non of these amateuer fotages records the deep sounds, only the high frequencies:

I think this is because of the planned multiplayer. That's why every object in the game is handled in the game the same way. Currently the game they act like a client server (as it is a multiplayer game), even if you play it as a single player. At least this is my experience with developing multiplayer games. You have to design everything in mind of being multiplayer ready. It is not something you can add later easy. Probably this one one of the main reasons to start KSP 2 from scratch. It also correlates why it is fast to switch between tracking station/vessels/space station. I'm not sure what they want/can do regarding optimization, before the multiplayer comes online. Because then "distant" would be relative. Some simplification would definitely needed but it will have many parameters for a feature complete KSP2.

I was able to reproduce it too. I also noticed that when you pause the game during loading it does not load the game as it is show in the video. When you unpause (1x) then pause again, the game loads the craft and it looks that the terrain is loaded later, because I get this fancy water splash. The second craft in the background was my earlier craft. It has the same splash effect. I think this causes the disintegration.

I would like to request a feature for the Sound engine, which would simulate the doppler effect and the sonic boom as a two major phenomenon. If you don't know what is it: Sonic boom implementation in other games: Doppler effect in other games: If an object is big enough, the double sonic boom what is mentioned in the TED video is clearly audible. And what is big and goes fast?! Rockets!!! I hope you like it and the devs sees a nice addition in such a feature.

I think what he mean is he does not want a KSP1 style career mode, where you get random missions, but this time for Science. I'm also a bit afraid that this is the case. For Science I would like to: Scan somehow the celestial bodies E.g.: Kerbin Observatory, Space telescopes, Space Probes on orbit around the body Scan result would give some science + potential further science missions which I can chose from. When the scan is complete the similar UI what we have for the Science Archive in KSP1 would show me what I already did and what Is available. I would keep some Science for the easter Eggs too -> these could add some kind of decoration around the Kerbal Space Center as a reward (an image on the wall in the mission control or so) Edit: I would like to have missions for science only. I don't like the "Perform test at altitude xy". And I'm totally happy with random Kerbals without any RPG style character development (Eg.: xp). They are all professional afterall.

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Pro 64bit | CPU: Intel i7-12700KF | GPU: RTX 3080 12GB | RAM: 32 GB Part remain highlighted even if it is not hovered in the Parts Manager. Steps to reproduce You can reproduce it by rapid movement from one part to the another. It does not occurs if the mouse is moved slowly. I think the event of leaving the UI element is not triggered. Expected behaviour Only one part should be highlighted visually with the green border. Included Attachments: Desktop2023_09_01-12_36_08_01.mp4

I would like to suggest few things for the Part Manager: Decrease the font size, it is too big. I recommend to use the Breadcrumb font size (see the attached images). This should be the size for the default UI scale (100%) If a tree node is empty, do not show the arrow. These nodes should not be clickable nor openable. Windows should scale by the UI scale game options Pinning parts in the Parts Manager should be handy during flight. A pin button on the right side of the part would look nice. If player pin a certain part it will remain open and moves on the top of the Parts Manager (could be a new group (eg.: Pinned/Favorites)) Let the windows width resize more and add multiple columns if the width of the window is wide. Instead of this we could have this size. This image shows the columns as well.

I really like the approach for each KSP2 simulation model that the time warp or switching to tracking station will not be a solution to avoid certain situations. I hope they improve the angular velocity consistency during the time warp too. If you speed up the time the rotation stops.

I like your idea and I would extend it with mine. Players should have direct control over the joins (the lines on your drawing, by selecting the parts) with a weight penalty and we should forget that struct ever existed. I don't like it personally, because it was introduced because of the wobbling rockets. If the player increases the strength of the join it should slightly increase the dry mass of that part. Simple, transparent the player has control over it and visually satisfying too. Edit: So I think Option B is better, because it does not introduce an invisible join. But I would achieve the same strengthening without struts.

Generally rockets are pressured gas tanks. Tanks has pressure and wall thickness. Since object does not bend in KSP, technically the wobbling is the only way to add a "bending" of object to the game. Pressure could wary based on the volume and amount of fuel (not necessary, because they usually fill the tank with another gas to keep the pressure on, but it could be a factor if you wish (probably it shouldn't be linear)). Thickness could be a parameter for structural parts + fuel tanks, as a tradeoff changing thickness should increase the mass Decuplers/docking should have strength, which would require more energy as a tradeoff By adding similar options fo the parts, I think the Struct would not needed at all. Benefits: Player has control over it, no tweaking needed form the development side (basically it would be a UX for the player to control what they internally try to achieve) It would be visible for the player, not like autostruct, which is a bit strange solution Struct on the vessels are not fancy at all. However: If the struct is the only way, and players intend to use as many of them as they need to have a rigid structure, they will basically makes the ship as one big rigid ship. So technically the wobbling is a matter of time and pain to get rid of by the players with a lot of struct. If that's what players have to do they basically wants rigidity, no matter how the rocket/ship looks like. They don't want simulation of rigidity in the game, no matter what.

I see lot of comments about why not and almost nothing as a suggestion how should. Here is my suggestion for the improved wobbling, I hope some devs will see it and they could react. Generally rockets are pressured gas tanks. Tanks has pressure and wall thickness. Since object does not bend in KSP, technically the wobbling is the only way to add a "bending" of object to the game. Pressure could wary based on the volume and amount of fuel (not necessary, because they usually fill the tank with another gas to keep the pressure on, but it could be a factor if you wish (probably it shouldn't be linear)). Thickness could be a parameter for structural parts + fuel tanks, as a tradeoff changing thickness should increase the mass Decuplers/docking should have strength, which would require more energy as a tradeoff By adding similar options fo the parts, I think the Struct would not needed at all. Benefits: Player has control over it, no tweaking needed form the development side (basically it would be a UX for the player to control what they internally try to achieve) It would be visible for the player, not like autostruct, which is a bit strange solution Struct on the vessels are not fancy at all

Issue 2 - Trajectories change when vehicles cross SOI boundaries ..... the introduction of axial tilt to KSP2 introduced some discrepancies.... Can somebody explain what is the axial tilt? What this makes different compared to KSP1? Issue 8 - Major post-liftoff frame rate lag immediately above launchpad (associated with engine exhaust lighting) Quick clarification: engines had previously each spawned a point light that cast shadows. While this was very pretty, it wasn’t great for performance (and this impact was increasingly pronounced at high engine counts). We have turned off shadow casting for those lights and are seeing an improvement in framerate near the launchpad. I don't know if there were a value in shadow or it was a miss configuration right from the beginning, but disabling features to have performance increase is not a good approach IMO. Can we have one light for engines if there are multiple there? I mean with some clustering logic you can spawn 1-x light sources based on the engine placements to cast shadows. X could vary based on graphics setting.

Those are probably mathematicians. Fixing bug is not easy in some cases. If it is done wrong you could introduce a new bug. That could be a quality gate to let only some people to fix a specify bugs.