Jump to content

Vl3d

Members
  • Posts

    739
  • Joined

  • Last visited

Everything posted by Vl3d

  1. This mod should really be stock. Very useful. Thank you!
  2. How is a black and white filter limiting the player's ability to see clearly? Implementation - is up to the devs to make sure it's not too distracting. You are against the idea without even considering how it changes the feel of the game regarding tech progression and gradual discovery of celestial bodies. It would incentivize the player to get better tech and send a more advanced mission with better instruments in order to get more information about the place.
  3. Nooo, that was a discussion just about weather visuals, like clouds, rain, snow etc. Nothing complex, just graphics. The discussion about wind as a gameplay feature is here. Most people want wind.
  4. So you don't expect probes to be feature-limited either, right? You think it's logical that a Stayputnik should see the whole detailed planet surface in color the same as a HECS2?
  5. Are you sure? Do you have proof? Has anything official been said on the subject? I've seen wind powered generators in the game. Why not sails?
  6. Yeah, but will kerbals be able to row (j/k but really what kind of hulls and propeller / jet propulsion)? Will we have wind powered vessels? Will we need anchors to cope with the waves? Will there be storms and giant waves?
  7. I know that having telescopes and gradually obtaining information about celestial bodies is already semi-confirmed by this comment. But what do you think about also having a some filters / overlays for unmanned craft 3rd person view that improve as technology gets better? Some combinations of.. black and white vintage / sepia noisy blurry VHS CRT fake colors instruments (infrared, ultraviolet) etc. best color version would be the same as the manned craft 3rd person view of course. This would differentiate between manned and unmanned craft and give a better gameplay experience for tech progression. It could be applied to first-time visits based on tech level, to limit information and incentivize discovery. After sending better probes or manned missions the image could be normal. Also we could also have: telescope (science instruments) that can zoom in when orbiting / passing by a planet so we could see things happening on the surface or more details ability to record videos
  8. After doing some more comparisons between RemoteTech and CommNet and also some play testing I tend to agree with @Master39 and other similar opinions and I forfeit the idea in the OP, but keep the idea of scripting: Signals delay can be abstracted away because of the concept of time zoom (warp), so real-time probe control is acceptable for a better gameplay experience. It slows down gameplay too much. It's hard enough to build and test a probe, it would be even more work to also have to program it. It would generate a lot of "I give up" moments. Also controlling more than one craft (for docking for example) would be impossible without very high level MechJeb functions (which kind of defeats the purpose of scripting). Players should not be forced to exclusively use a IVA / Probe Control Room point of view. Maybe a black and white / fuzzy / sepia overlay in 3rd person craft view is better. But PCR / probe IVA would still be a nice alternative. Having a visual programming / scripting language / editor I think is a must for a modern KSP. This VPL should be optional in stock and normal dificulty, but there should be some harder difficulty settings that could limit manual control to incentivize scripting or there could be more situations where manual control of probes is not possible so the craft goes into an automatic scripted state. The VPL should be closely integrated with the other planning / logistics / navigation / smart-parts / telemetry / science systems to allow template generation and also fine adjustments. VPL would be great to use in situations where we have to control more than one craft simultaneously (booster return-to-base and reuse, small craft swarms / movement mirroring, floating / flying carriers, mining / resource transport / other repetitive operations etc.) Useful in cases where manual control is not possible (lack of signal) so a short automated script can be run (like holding SAS during reentry or queuing a burn during occlusion) There should be a better balance and greater distinction between using: unmanned craft (exploration, safety, simplicity etc.) manned craft (dealing with life support but necessary for colonization, building .. and other uses are needed!) Some better alternatives to signal delay (merging these features): CommNet idea of signal strength and relays; The Kerbalism system of file storage and data transfer speed (which slows as signal is weaker because of redundancy and error correction); The RemoteTech idea of more control over the comm network (being able to point directional antennas and manually change the signal links graph). Omnidirectional antennas would still be in the game, but would be weaker than the directional ones. The RemoteTech idea of queuing scripts / commands in case of loss of manual control. Having a CPU / KAL portrait image instead of a Kerbal when controlling unmanned craft.
  9. 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.
  10. That sounds like fun.. and not only NPCs, but also other teams craft in multiplayer.
  11. 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.
  12. 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.
  13. 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).
  14. Hey @Bej Kermanwhat do you think about this?
  15. 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?
  16. 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.
  17. 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).
  18. There's a big difference between HAVING ANY and having THE BEST. You're arguing with your straw man.
  19. 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.
  20. 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.
  21. 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...