Jump to content


  • Posts

  • Joined

  • Last visited


457 Excellent


Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Correct. Correct. Correct. I believe we're in agreement. Axial tilt refers to the polar axis position which defines the poles and implicitly sets the polar caps location. Why would they be? Polar ice caps are at the poles, and for good reason (because the poles are coldest). Duna has zero axial tilt. Were you expecting the polar caps to be ... somewhere other than the poles, for some reason? No, I was under the impression there was a texture placement error in the game for Duna. I got confused by something I forgot about.
  2. That sounds like fun.. and not only NPCs, but also other teams craft in multiplayer.
  3. while (!landed) { while (ASL < AGL) keep flying; if (ASL > AGL) land; } The rest are details that can be implemented in the script. But it would be even easier if the scripting language was integrated with journey planner, maneuver nodes and a landing trajectories calculator. You keep using one of the most complicated example you can come up with (transforming propeller plane drone) without understanding that the control code would also have to be relatively complicated and it would need integration with the other systems in the game. Let me make it more clear: I want a difficulty option that creates incentives to program probes. Call it signal delay or "program input only". If you don't like it, play without it. .. also, unmanned craft are supposed to be expendable and experimental with a fast iteration loop. If you fail you improve your designs and test more - it's what Kerbal's all about.
  4. The poles are where the polar axis intersects the surface of the body. Axial tilt means the tilt of the polar axis. If there is axial tilt, it means the poles are tilted. The polar ice caps are at the poles (according to axial tilt) but they change shape depending on orientation relative to the sun (thus we have seasons). I was under the impression that Duna's polar ice caps were tilted, but after doing some research it seems not. I hope they will be in KSP2 and we'll have seasons on Duna.
  5. I think we'll be able to build some big projects in multiplayer, but not civilization-wide mega-structures. Personally I would love to build a Oort cloud - asteroid hopping network that links two stars (for constant low-tech transport missions).
  6. Hey @Bej Kermanwhat do you think about this?
  7. I agree it's important to also focus on this - with tutorials and a simple Kerbal - Mun - Minmus system. Beyond that, the space race is on! By the time you worry about interstellar missions, you should have sunk your teeth in axial tilt. If you think about it, the progression is there: Kerbal -> equatorial orbit -> Mun encounter (only pro-grade burn) -> Minmus encounter (needs matching orbital inclination) -> Eve / Duna encounter (learning interplanetary transfers) -> then Duna should definitely have axial tilt, which is more important for manned mission takeoff than just landing, and considering no one is really taking off Eve before learning the game.. yes Duna should have axial tilt - aren't the Polar Ice Caps at an angle anyway?
  8. Ok, I agree with some of your comments. My basic idea was to move unmanned craft towards pre-programmed control and leave manned craft in the area of real-time control. This is because I believe probes are OP, you can play all of KSP 1 without the need to launch a single Kerbal in space. I believe we need more incentives to use manned craft. Adding visual scripting is the most important point. Indeed KSP1 and CommNet abstracts signal delay away because it's not fun gameplay, but also because there is no tool to pre-program unmanned craft. So let's think about what incentives there could / will be in KSP2 to use manned craft with real-time control: planting flags piloting craft when there is no communication signal craft construction and modification (one or more kerbals) craft repairs science labs special science experiments (like the deployable ones) colony construction and expansion (more important in KSP2) resource extraction and processing bonus What incentives we have to use unmanned craft: you can control craft in real-time like you can with manned craft you don't have to worry about kerbal loss of life, life support or radiation protection you can discover any place manned craft can discover (with relays and good comm signal) in KSP1 you can do basic orbital / landed construction using robots and dockable sub-assemblies you can do most of the useful science experiments So if we add visual programming you would have all the benefits of KSP1 unmanned craft and also: be able to pre-program control of probes with no communication signal So basically what we're doing is adding programming and by doing this we are making OP unmanned craft even more powerful, without adding incentives for manned missions. This is why it's important to talk about separating unmanned and manned gameplay, adding extra incentives for manned craft and/or taking away some of the advantages of unmanned craft. It's a balance issue, it can be solved in multiple ways. This is the reason integrated visual programming and signal delay is still one of the possible solutions and a good idea - depending on implementation.
  9. Yes to water / under water crafts. No to flags ON water, but yes to flags on the sea bed (first to plant flag in the Kariana trench for example).
  10. There's a big difference between HAVING ANY and having THE BEST. You're arguing with your straw man.
  11. Ok, after reading through the previous discussion I realize there's one thing that I mentioned in the OP that needs more explanation: integration of the visual scripting language with the Journey Planner (maneuver nodes), the onboard equipment, the control deck, the manned command center. Simple ideas (comms signal needed): 1. You create all the necessary action groups and the KAL recordings for the unnamed craft. 2. You set the destination in the Journey Planner and create all the necessary maneuver nodes BEFORE launching the mission. 3. You export the plan (1) with all the intermediary key-frame maneuvers as a basic script frame for the Kizzy editor. This way it's like you have access to high level MechJeb functionality, but you can work with it in the script. 4. In your script you also have access to all the action groups and KAL recordings and telemetry / sensors / other equipment. 5. You finish the script, upload it to the unmanned craft, send it. 6. If later you find a bug you can reupload the improved program (if signals are good). 7. You interact with the unnamed craft indirectly through a Unmanned Craft Control Deck, with UI elements integrated. You see the onboard cameras and all equipment data. 8. You are able to send direct commands only if you have a command center close enough so the delay is below a certain threshold. In this case you can control the unmanned craft in real-time. 9. You do your best, learn from your mistakes, improve the maneuver nodes and the script, upgrade equipment, send manned missions closer to the destination to have real-time control. I think this would be fun and it would expand gameplay. If not, it could be a very nice spinoff game or DLC. PS: Don't tell me it's too complicated. Have you played Paradox games? Also don't tell me you don't want to learn visual scripting. Have you played SR2? Programming craft is a great fun functionality even as an optional feature. Having comms delay is actually an emergent feature, it is a difficulty settings unlocked by what is made possible by an integrated scripting system.
  12. I know this. In all aspects I trust the creative and technical decisions of the dev team and we're probably going to get the best game possible. I know that they have thought about all this already and made choices. But the problem of KSP2 is actually the opposite - hype is too low, promises very few. I want us to think about what this game COULD be until we find out what it actually is. Don't be worried about being disappointing - imagining the future is the most important thing. Someday there will also be KSP 3. Maybe all of these ideas could be implemented then. VR too.
  13. It's another controversial topic, but I know everyone is open to discussions, ideas and suggestions. So let's just assume that KSP2 will have a simple visual programming language like Vizzy in SR2 that also plays well with the Journey Planner. I think this would allow adding a feature (stock or as a dificulty setting) that would make the game even more interesting: (manned craft or ground support = command stations <-> unmanned craft) communication delayed by the light-speed limit of causality. Let's have an open mind and think about it. Manned craft would be controlled in real-time as usual, but it would take some time for scientific results to be transmitted to the network of colonies. This has a small impact on tech progression if experiments would also take time to run as implemented in Kerbalism. Besides, we can always time warp to get the science points. Manned craft would be even more important because they could allow the control of probes in proximity: this is motivation to create space stations, colonies closer to unmanned mission destinations. Unmanned craft would be pre-programmed, re-programmable and remotely controlled with distance-proportional-delay and using limited information (using data from hull cameras, telemetry, sensors, science and other instruments). This could also mean implementing a Probe Control Center, like an instruments deck similar to IVA view. Previous point means also that early in the tech tree only manned craft would be able to see a direct close-up real-time interactive detailed view of celestial bodies. So there would be a bigger motivation to send actual exploration crew and would ensure gradual discovery of celestial bodies. Unmanned craft would be useful but limited, dispensable, even launch-and-forget - not as important as manned missions. This means a faster rhythm of craft iteration and discovery. It really ties in nicely with reusable craft, logistics automation, and delivery routes system. I think the game would have a lot to gain from giving the player learning experiences: "I hope I did a good job and everything works, because it's out of my real-time control now - I just get the instruments info and watch the show" "I messed up the programming, but I will learn from the mistake and do better next launch" (just read how hard it was to send successful missions to Mars) "I learned basic programming" "I found a mistake during the mission, I can't control the probe in real-time, but I can update the software" "I need to send crew to be able to control in-proximity probes in real-time" "99% of the work is in design and testing - after launch we hope for the best" And I'm sure there would be a lot of interesting variation and emergent gameplay from this. Long live RemoteTech! Unleash it with visual programming!
  • Create New...