Jump to content

Bartybum

Members
  • Posts

    275
  • Joined

  • Last visited

Posts posted by Bartybum

  1. On 1/6/2020 at 11:17 PM, ChrisF0001 said:

    Might I ask if there's been a change to how Rover Stability Control works in the last few versions?  While driving forward it seems okay, if a little weak, but if a rover is stopped with Stability Control on it seems to dramatically flip out (for lack of a better description).  I suspect that if the velocity is 'backwards' for any reason (reversing, rolling backwards down a slope, rounding error...) it's trying to pull the nose around to comply with the velocity vector by hook or by crook, even if this involves grinding the nose into the ground or scraping off all the solar panels.

    It seems much more pronounced on the Mun rather than just outside KSC...

    I'm having this same issue. It's making AFK rover voyages impossible. I'd like to be able to stop at every waypoint and quicksave, but as soon as i pass below 3m/s, the rover starts spazzing out. The stability assist should reduce to 0 below a configurable speed.

  2. @KSK but how would making comm range, aero heating, plasma blackout, G-limits, etc. optional more difficult for balancing? Whenever they're disabled they're disabled because the player wants an easier game to begin with. Bar life support, I honestly can't think of any features that players would want to be optional that would impact balancing in any meaningful way.

  3. Just now, XLjedi said:

    I believe you didn't think they would have engines anywhere near the speed of light either, correct?

    Assuming you're talking about all the near/mid-future engine types we're gonna get, they've very obviously been added to address the time issues with launching otherwise multi-decade missions while trying to develop a space agency back at home.

    It's a very different situation than multiplayer. I agree with OP, MP is likely gonna be small local servers. MMO just wouldn't work for KSP.

  4. 9 hours ago, mcwaffles2003 said:

    Softly, this still doesn't answer the

    What happens to A's docking situation if B, instead, on Day 3, rams the station, completely destroying it? What, in that case, did A dock to on Day 5, after the station was destroyed?

    Mmm, no it defs doesn't, does it? :/

    I suppose multiplayer could be based off the assumption that both players work cooperatively (i.e. you wouldn't play KSP with someone you don't like), and then it leaves it up to the players to decide whose version of the station will persist. This way, if B destroyed the station, and then synced with A, the game could prompt both to decide whose instance is correct.

    11 hours ago, mcwaffles2003 said:

    If it does come back what if the station is just moved on day 3? Do 2 stations appear now after the merge or has A been magically transported?

    The same would apply here. Both users must work together to decide whose station instance to keep.

    That being said, this whole scenario seems like one based of a neutral/hostile relationship between players. It can be avoided if they just coordinate.

    11 hours ago, mcwaffles2003 said:

    What if A and B are unsynced and each researches a different tech? do they get both techs when they sync? Are the science points in the future used by people in the past? Does money function the same way?

    Perhaps again, the tech that's unlocked will be determined by whose instance is considered correct. That way if you used a ship to fulfill a contract/unlock tech and that ship gets wiped, then so would the tech/money. Tbh I hadn't thought much about money and stuff though - I've mainly been focused on sandbox gameplay. For a co-op career, I do think forced timewarp would be quite cool, but I wouldn't wanna play that with more than 3-4 players (which is plenty), because of transfer windows.

    11 hours ago, mcwaffles2003 said:

    I just dont see *snip* happening

    I do, people can learn things pretty quickly. To interact with a player, you'd simply have to be synced to them. In any case, I would also see the option of locking timewarp to prevent desync being implemented when players wanna interact, or even globally so that there's no desync at all.

  5. 6 hours ago, mcwaffles2003 said:

    Umm... chill? I wasn't dictating how people play multiplayer, but I was pointing out the absurdity of playing in a multiplayer server in the fashion of everyone playing a separate single player campaign in a single server and saying that I don't understand that point of view...

     Also, we're discussing how multiplayer timewarping is going to work. Since you have a different opinion should I get mad and accuse you of dictating how I should play? No, because that's unproductive...

    My apologies if that came off as not chill, not my intent. That being said, I do find your attitude towards the gameplay style I described earlier to sound a bit like gatekeeping.

    Personally I don't think it's absurd to play how I'd like to play. After all, it's the same general play style as in any other multiplayer sandbox game. People go off and do their own things free of restrictions, but can interact together if they wish.

     

    6 hours ago, mcwaffles2003 said:

    Agreed, hence my:

    If everyone's locked in the same time and you're on a 5 year long mission while others are on hours long missions why not come back to your mission and do something else in the meantime?

    I answered that:

    11 hours ago, Bartybum said:

    Because I don’t want to wait days or even weeks in the real world before I have a chance to continue what I was doing. What if I don’t have time to play KSP every day? What happens if my connection drops out when it’s my turn? Does the whole server pause, or do I suddenly have to wait another few weeks in real life before I have another chance to do my thing?

    If I have to wait months in real life to do even basic interplanetary stuff (not even mentioning interstellar voyages) then what’s the point?

    I have preferences on what I'd like to do, and I don't want to have to be constantly waiting to do them. Do I have to keep sending missions out? I don't want to have to wait months in real life to finish them because others keep having more urgent missions to do. At some point I'd like to finish my missions.

     

    6 hours ago, mcwaffles2003 said:

    Thank you for clearing that up. But you do recognize the issue razzark brings up with that, correct?

    There is a station in orbit.

    A launches a ship into orbit. B also launches a ship into orbit.

    A timewarps ahead, and is now on Day 5, while B is on Day 1.

    A now docks to the space station.

    Can B also dock to the station on Day 1? What happens if B does not undock before Day 5 to allow A to dock? What happens to A's docking situation if B, instead, on Day 3, rams the station, completely destroying it? What, in that case, did A dock to on Day 5, after the station was destroyed?

    If B docks to the station on day 1, then the paradox only occurs when B tries to sync with A after B has docked.

    One solution could be to prompt B that to sync forwards with A would require B's station to be replaced by A's, effectively undoing B's work.

    Admittedly, this would require some measure of player coordination to avoid losing ships due to the game trying to avoid paradoxes. I imagine the scenario to look like this:

    • A and B each launch a ship into orbit (assuming the station has more than one docking port)
      Both craft are at time T=0
    • A timewarps forward 5 days
      A is at T=5, B is at T=0
    • A informs B that they will be docking to the station; B cooperates and agrees to wait until A's save is ready to be synced with (only logical; you want to make sure you set out at the correct time)
    • A docks (assume it takes one day to dock)
      A is at T=6, B is at T=0 (but can be anywhere between the two)
    • B syncs with A, and then A goes and does something else. The station in B's save now has A's ship docked to it
      A is at T=6, B is at T=6
    • B docks
      A is at T=6+x (x is whatever arbitrary time has passed while A has been doing other stuff), B is at T=7 (assuming it also takes B one day to dock)
    • If B warps ahead of A, then A can sync to B to update the station and A's save. Otherwise, A is prompted by B to update A's version of the station (sort of a reverse sync) to reflect what the new station should be (with both ships attached), as well as where it should be. Both players' saves now have the station with both ships docked, both in the correct position in each player's respective timeline

    If that's programmable, then personally I don't think it'd be too difficult to get the hang of, especially if taught properly in a tutorial with examples. I think it follows a fairly logical train of thought.

     

    6 hours ago, mcwaffles2003 said:

    What queue? We are obviously not on the same wavelength. Personally, I figure timewarp should go as fast as the slowest persons timewarp and in a server hopefully everyone can be respectful with that, if not, kick'em. But as for connections dropping and what happens when they do? Well that depends on if you're running the server I suppose. If you are, everyone loses connection and has to rejoin at the last save when it reboots. If you're not the host, the game will go on without you until you return, sorry, crap happens. If you can find another way for this to work please do tell.

    The timewarp queue is the priority list that I was talking about earlier, the one that would evolve out of transfer windows:

    11 hours ago, Bartybum said:

    Picture this textbook problem:

    • A wants to drive a rover from point A to point B which is an hour away.
    • B wants to do a mission to Duna, but his transfer window's in a week.
    • C is already en-route to a Munar orbit, arriving in two days.

    Alright, in that case we let C go first, because their mission won't take long, and they're coming up first. Then comes B, because theirs won't take too long either. Last but not least comes A, whose mission will take an hour. Assuming nothing went wrong, A only had to wait about 10-15 minutes to do their task. Now B and C both have to wait an hour before they can do anything, and after that, one of them will have to wait for the other too.

    Suddenly we have to prioritise who can do what and when, and the whole game slows to a 1x crawl. The waiting is only compounded by however many failed attempts and reloads have to happen. Furthermore, once you have even primitive life support systems in the game, you need to plan way ahead and pack loads of food, otherwise your Kerbals could be waiting in orbit for years before they can do anything.

     

    6 hours ago, mcwaffles2003 said:

    Just curious, when you are imagining multiplayer in this game, how many players do you envision being on a sever simultaneously at max?

    At max I'd imagine no more than six to eight players.

  6. 4 hours ago, mcwaffles2003 said:

    We'll when you imagine the scenario are you playing with people or are you playing around people? In the situation of with I assume theres a common goal so if theres a long mission the collective group would like it completed, in the latter version I don't know why you're on a multiplayer server.

    Why is it up to you how others play multiplayer? Both play styles are equally valid. One person does a mission here, one does a mission elsewhere. Space agencies can have multiple missions at once.

    I’m on a multiplayer server because I wanna build stuff that others can then later interact with. And likewise, I wanna interact with their stuff.

    4 hours ago, mcwaffles2003 said:

    I dont see how any multiplayer mechanic changes a connection drop, nor how it's relevant to the topic at hand.

    It’s absolutely relevant, because if my connection drops at the wrong moment I’ve lost my position in the queue and have to go do something else until my next transfer window/whatever, which could take god knows how much time if I have to wait for other players because they’re doing stuff in that window. That’s not fun.

  7. 12 minutes ago, mcwaffles2003 said:

    If everyone's locked in the same time and you're on a 5 year long mission while others are on hours long missions why not come back to your mission and do something else in the meantime? 

    Because I don’t want to wait days or even weeks in the real world before I have a chance to continue what I was doing. What if I don’t have time to play KSP every day? What happens if my connection drops out when it’s my turn? Does the whole server pause, or do I suddenly have to wait another few weeks in real life before I have another chance to do my thing?

    If I have to wait months in real life to do even basic interplanetary stuff (not even mentioning interstellar voyages) then what’s the point?

  8. 42 minutes ago, Dale Christopher said:

    And yet you do have people routinely (probably every 10mins consecutively for hours at a time) easily coordinating timewarps almost without a thought about it. In Minecraft the assembly buildings aren’t even instanced, everyone constantly works on their projects in real-time with frequent timewarps. So..... what the problamo?

    Problamo is that in Minecraft it doesn't matter what the time of day is. You can do almost anything at any time in that game. That's why people can coordinate time changes so easily in Minecraft.

    KSP doesn't have that same luxury, because you have to deal with live physics, transfer windows, waiting for maneuver nodes, rover voyages and more. Forced timewarp (voting is still forced on those who don't want it) severely bogs down progression in the game.

    Picture this textbook problem:

    • A wants to drive a rover from point A to point B which is an hour away.
    • B wants to do a mission to Duna, but his transfer window's in a week.
    • C is already en-route to a Munar orbit, arriving in two days.

    Alright, in that case we let C go first, because their mission won't take long, and they're coming up first. Then comes B, because theirs won't take too long either. Last but not least comes A, whose mission will take an hour. Assuming nothing went wrong, A only had to wait about 10-15 minutes to do their task. Now B and C both have to wait an hour before they can do anything, and after that, one of them will have to wait for the other too.

    Suddenly we have to prioritise who can do what and when, and the whole game slows to a 1x crawl. The waiting is only compounded by however many failed attempts and reloads have to happen. Furthermore, once you have even primitive life support systems in the game, you need to plan way ahead and pack loads of food, otherwise your Kerbals could be waiting in orbit for years before they can do anything.

    While it may still be tolerable on a server with only three players, once you start adding more and more, the list of prioritised tasks grows and grows, as does the waiting time. I don't wanna have to wait for hours on end for the other players to finish what they were doing, because that's not fun for me in any way. They don't wanna have to wait for me, because that's no fun for them either.

  9. 14 hours ago, Dale Christopher said:

    I havent read the whole thread but it might be worth mentioning that Minecraft already has a solution for timewarps in a multiplayer game. Their solution is to require all parties in the server to agree to it. It seems to work fine O_O. 

    Minecraft is not KSP. You don't have people doing stuff that heavily relies on time progression.

    1 hour ago, razark said:

    That I want multiplayer KSP without paradox.  I could have sworn I mentioned that repeatedly.

    Then just hit the sync button? And don't play with people who refuse to hit the sync button? It's as easy as not playing with griefers.

  10. 1 hour ago, Brikoleur said:

    If you don't have those extra systems for abstracting out supply lines (and, implicitly, production, consumption, and acquisition of resources -- i.e., a simulated economy), then that means you have to make those supply runs manually every time. That would be rote, repetitive, and tedious. 

    Fair point. I would love for automation; it'd help with the whole running a space agency shtick.

  11. 3 hours ago, Brikoleur said:

    Emergent gameplay is when  systems cause players to come up with stuff to do on their own. Constellations are emergent gameplay, because they don’t need anything beyond the properties of CommNet to emerge, supply lines and farming are not because they would require systems of their own in the game.

    What extra system would be required for me to restock my space station with supplies? Supply lines can merely be a gameplay strategy to get around the costs of having to constantly send expensive ships from Kerbin.

  12. I'm in favour of an optional approach like atmospheric heating, etc., but by default it should be off for easy difficulty, but on for normal and hard. Like many others, I think the best way to do it is like Snacks!, where you have few resources that are easy to manage, as well as waste recycling capabilities. Throw in some production facilities and we're golden. Life Support is a pillar of manned spaceflight, and the game should be able to reflect that.

    On 2/23/2020 at 7:42 AM, Brikoleur said:

    It should be experienced as a challenge, and it should lead to emergent gameplay just like CommNet does.

    Resupply missions? Food production? If that's not emergent gameplay then I dunno what is. Just like relay constellations emerged from CommNet, supply lines can emerge from life support. If you make it in the player's interest to set up these lines, particularly in early-midgame when you don't yet have colonies, then the corresponding gameplay will emerge.

    I'm not really a fan of air management, but I do think we should have to make sure our Kerbals stay fed.

  13. On 9/29/2019 at 6:52 AM, rmaine said:

    Er, in what way do you think axial tilt has any effect on getting into orbit? None that I know of, at least around Kerbin. It affects getting into interplanetary orbits, but nothing before that. Are you perhaps thinking that zero-inclination orbits would end up effectively being inclined by the amount of tilt? Not so. Orbit inclination is with respect to the planet's axis of rotation, regardless of how much tilt that might involve.

    It really depends on how it'd be implemented.

    They could:

    1. Tilt Kerbin, but leave the orbits of the Mun and Minmus the same relative to Kerbin's ecliptic plane, or
    2. they could also rotate the Mun's and Minmus' planes to keep them the same relative to Kerbin.

    I was more thinking about the first one, but you're right in that the second option would only affect interplanetary transfers. In either case, I think the way Kerbin's set up now is good, and makes the game accessible enough from a learning standpoint.

  14. 8 hours ago, mattinoz said:

    There is a lot a space in space to handle such things. So why does paradox need to be prevented?

    Seems to me letting Paradox build up then tasking players to drop in to the timeline to correct it could be an awful lot of fun in its own right.

    It provides a lot of freedom and doesn't end up bogging down the game. User-activated syncing is the way to go in my opinion.

×
×
  • Create New...