KSP 2 Multiplayer Discussion Thread

[Doc]

6 minutes ago, Lu K. said:

My prediction for mp is space agencies who compete or co-operate with each other, maybe a space race or working together on massive projects.

That would probably be 'easiest' - just treat everyone elses ships like they are 'on rails' - that'd even solve the time-warp issue. But I wouldn't really call it multiplayer...

[Bartybum]

23 hours ago, GoldForest said:

5) This is also a bad idea. No in VAB/SPH team building should be allowed. Too much room for abuse. Besides, you can build a space ship in orbit by docking modules together.

No room for abuse if you make it request-approved only.

 

[GoldForest]

2 minutes ago, Bartybum said:

No room for abuse if you make it request-approved only.

 

Still room for abuse. 
"Hey can I join you?"
"I don't know." 
"I only want to see what you're working on."
"Okay."
[Ninjamaster_123 has joined the build process]
*Ninjamaster_123 proceeds to randomly and quickly add and delete parts before they can be kicked.*
"Hahahahhahahahaha" - Ninjamaster_123

[Bartybum]

6 minutes ago, GoldForest said:

Still room for abuse. 
"Hey can I join you?"
"I don't know." 
"I only want to see what you're working on."
"Okay."
[Ninjamaster_123 has joined the build process]
*Ninjamaster_123 proceeds to randomly and quickly add and delete parts before they can be kicked.*
"Hahahahhahahahaha" - Ninjamaster_123

(Prompt): "Allow [player] shared VAB/SPH access? Your craft will be autosaved before you accept (Y/N)"

Problem solved. No room for abuse.

Edited August 23, 2019 by Bartybum

[Kerbart]

3 minutes ago, GoldForest said:

Still room for abuse. 

One solution: players becoming experienced in not doing that.

Another solution: user accounts that are hard to change and have some kind of rep system

Third solution: restrictions on what joiners can do. “Ninja_123 has joined. Please select actions for Ninja_123: [ ] view only [ ] steer & throttle only. [ ] stage” etc. Mayb3 joiners can be restricted to only controlling a speicif craft.

 

I agree that griefing will be a problem, the most likely solution is us learning to deal with it. And the ability to revert.

[Kerenatus]

9 minutes ago, GoldForest said:

Still room for abuse. 
"Hey can I join you?"
"I don't know." 
"I only want to see what you're working on."
"Okay."
[Ninjamaster_123 has joined the build process]
*Ninjamaster_123 proceeds to randomly and quickly add and delete parts before they can be kicked.*
"Hahahahhahahahaha" - Ninjamaster_123

LOL This makes me laugh

[GoldForest]

7 minutes ago, Bartybum said:

(Prompt): "Allow [player] shared VAB/SPH access? Your craft will be autosaved before you accept (Y/N)"

Problem solved. No room for abuse.

 

1 minute ago, Kerbart said:

One solution: players becoming experienced in not doing that.

Another solution: user accounts that are hard to change and have some kind of rep system

Third solution: restrictions on what joiners can do. “Ninja_123 has joined. Please select actions for Ninja_123: [ ] view only [ ] steer & throttle only. [ ] stage” etc. Mayb3 joiners can be restricted to only controlling a speicif craft.

 

I agree that griefing will be a problem, the most likely solution is us learning to deal with it. And the ability to revert.

Okay, I guess you could find ways to limit it, but it would still be a hassle, and that's not preventing abuse, that's just a solution to revert the abuse. 

[Bartybum]

1 minute ago, Kerbart said:

I agree that griefing will be a problem, the most likely solution is us learning to deal with it. And the ability to revert.

This ^^^ and my suggestion combined would be great - forcing a save prior to accepting, and then having the ability to revert guests' changes

1 minute ago, GoldForest said:

Okay, I guess you could find ways to limit it, but it would still be a hassle, and that's not preventing abuse, that's just a solution to revert the abuse. 

In that case your request is incorrect. It's impossible to prevent people from acting like dicks; the best you can do is revert the effects.

[Kerenatus]

1 minute ago, Bartybum said:

This ^^^ and my suggestion combined would be great - forcing a save prior to accepting, and then having the ability to revert guests' changes

If vessels still use a tree structure, it'd be quite hard to revert guest changes only while a vessel building is in process.

 

[Bartybum]

2 minutes ago, Kerenatus said:

If vessels still use a tree structure, it'd be quite hard to revert guest changes only while a vessel building is in process.

Not really. If they suddenly grief you, then you kick them, then revert their changes one by one until all their griefing is reversed.

If their griefing has been slow and not really visible over time, then a system that informs you when and what they've just placed would fix that issue too.

Edited August 23, 2019 by Bartybum

[Kensor]

5 minutes ago, Bartybum said:

This ^^^ and my suggestion combined would be great - forcing a save prior to accepting, and then having the ability to revert guests' changes

In that case your request is incorrect. It's impossible to prevent people from acting like dicks; the best you can do is revert the effects.

Backups getting created every 15 Minutes would be nice in this case, so there wouldn't be such a loss if you have to restore a Backup.

This would only be possible on dedicated servers though, know it from ARK:Survival Evolved and i loved the option to revert, after some thought it would be a good idea to rampage on my server.

[Kerenatus]

On 8/23/2019 at 5:36 AM, Bartybum said:

Not really. If they suddenly grief you, then you kick them, then revert their changes one by one until all their griefing is reversed.

If their griefing has been slow and not really visible over time, then a system that informs you when and what they've just placed would fix that issue too.

IMOH, allowing players to share VAB live doesn't really worth all the potential [~ snip ~]

Sharing crafts or semi-assemblies directly in-game is a decent and much more abuse-free option.

Edited March 1, 2020 by Starhawk
Redacted by moderator

[Bartybum]

On 8/23/2019 at 5:43 AM, Kerenatus said:

IMOH, allowing players to share VAB live doesn't really worth all the potential [~ snip ~].

What? I just suggested a very simple fix to the abuse - how is there any potential [~ snip ~]?

Saying "oh no I think it's best left untouched" in light of what I've suggested is a total cop-out.

Edited March 1, 2020 by Starhawk
Redacted by moderator

[Kerenatus]

On 8/23/2019 at 5:50 AM, Bartybum said:

What? I just suggested a very simple fix to the abuse - how is there any potential [~ snip ~]?

Saying "oh no I think it's best left untouched" in light of what I've suggested is a total cop-out.

In a technical vew, allowing building a vessel live between several players may well require the server to constantly saving temporary craft files for every online game and even more back-up files if reverting is allowed,which is highly inefficient. While doing it solo, the game needs only to save it locally and having the craft file online only when you decide to share certain crafts.

I don't expect them to arrange that much server resource for the MP feature of the mainly solo-focusing game.

It may look simple in human logic, but require a [~ snip ~] ton of unnecessary resource for the computers.

Edited March 1, 2020 by Starhawk
Redacted by moderator

[Bartybum]

On 8/23/2019 at 5:55 AM, Kerenatus said:

In a technical vew, allowing building a vessel live between several players may well require the server to constantly saving temporary craft files for every online game and even more back-up files if reverting is allowed,which is highly inefficient. While doing it solo, the game needs only to save it locally and having the craft file online only when you decide to share certain crafts.

I don't expect them to arrange that much server resource for the MP feature of the mainly solo-focusing game.

It may look simple in human logic, but require a [~ snip ~] ton of unnecessary resource for the computers.

Assuming the craft file is local to the VAB-host's client, you could just not give the guest access to the VAB-host's craft file repository. Furthermore, you could give the guest a "download craft file" button to let them save it to their own local repository (if the host checks a "share craft file" button). It's the same as sharing a cockpit in a flight simlator server, where the guest can push buttons (add/take off parts), but the host still holds the reins (saving, and what craft file is loaded).

Edited March 1, 2020 by Starhawk
Redacted by moderator

[Kerenatus]

11 minutes ago, Bartybum said:

Assuming the craft file is local to the VAB-host's client, you could just not give the guest access to the VAB-host's craft file repository. Furthermore, you could give the guest a "download craft file" button to let them save it to their own local repository (if the host checks a "share craft file" button). It's the same as sharing a cockpit in a flight simlator server, where the guest can push buttons (add/take off parts), but the host still holds the reins (saving, and what craft file is loaded).

seperate craft files => seperate editing, which is effectively just sharing craft files like what we have on steam right now, but in a relatively convenient way. You won't be able to edit the same thing simultaneously in the way you suggested, which makes sharing live VAB pointless since it's not live at all.

On a friendly note, might i suggest having some basic grasp of programming and network?

Edited August 23, 2019 by Kerenatus
a friendly note, and spelling

[Bartybum]

3 minutes ago, Kerenatus said:

seperate craft files => seperate editing, which is effectively just sharing craft files like what we have on steam right now, but in a relatively convenient way.

 

Maybe I phrased my idea wrong, so I'll go again.

I'm saying that while in a shared VAB session, let both builders save the craft at any point to their own clientside repositories, but only allow the host of the building session to control which craft file is being worked on at any given time. Picture a normal singleplayer VAB session, but now add a guest. The guest is just along for the ride, but can add/remove parts and save the craft to their own repository.

Again, it's the same concept as a shared cockpit in flight simulator. Both the pilot and copilot can steer the plane, but only the pilot can choose which plane is loaded.

12 minutes ago, Kerenatus said:

basic grasp

"On a friendly note, allow me to say something rather condescending"

Granted, I don't know how to program/network/whatever, but I'm assuming the devs do. This isn't that unreasonable, since after all they do intend to tackle multiplayer.

Since neither of us two are writing the game, I think it's a bit premature to think it can't be done.

[Kerbart]

You have to weigh benefits vs implementation cost. VAB sharing appears very complex to me to implement. Things go haywire enough in the office when two coworkers edit the same spreadsheet at the same time, and that is kindergarden compared to what goes on in the VAB. And for what? Is it that much of an experience that you don’t want to miss out on it?

[Guest]

Yeah VAB sharing is a nonstarter. The UI issues alone will get way too hairy. Moreover I doubt there are more than a handful of players who would even want it.

[Kerenatus]

25 minutes ago, Bartybum said:

I'm saying that while in a shared VAB session, let both builders save the craft at any point to their own clientside repositories, but only allow the host of the building session to control which craft file is being worked on at any given time. Picture a normal singleplayer VAB session, but now add a guest. The guest is just along for the ride, but can add/remove parts and save the craft to their own repository.

 

Since neither of us two are writing the game, I think it's a bit premature to think it can't be done.

I'm always talking about the issues related to the being-worked-on craft file my dude, you don't work something on nothing, you work on a file. But since you don't know the basics, i'd leave it here.

Also, i never said or implied in any prevous post that it "can't be done".  I'm talking about whether the gameplay experience that suggested feature might bring worth the resource that it could potentially cost. By resource, i mean both developing and maintenance resource, in terms of both human and monetary ones. Only technically possible is faaaaaaaar from enough for a feature to be implemented.

28 minutes ago, Kerbart said:

You have to weigh benefits vs implementation cost. VAB sharing appears very complex to me to implement. Things go haywire enough in the office when two coworkers edit the same spreadsheet at the same time, and that is kindergarden compared to what goes on in the VAB. And for what? Is it that much of an experience that you don’t want to miss out on it?

As this said.

Above all, it relies, of course, always on the actual developers to decide anything development related, but since this conversation occurs, i'd like to add my bits as well.

[Xd the great]

What about mods in multiplayer? I see 2 problems with it:

1. Someone hosts a server with so many mods it, lag happens.

2. Griefers and trolls blowing up everything with BDArmory.

[Kerenatus]

1 minute ago, Xd the great said:

What about mods in multiplayer? I see 2 problems with it:

1. Someone hosts a server with so many mods it, lag happens.

2. Griefers and trolls blowing up everything with BDArmory.

Mod list surely needs to be unified in MP games. Either to straightforwardly ban mods(the worst case), or to allow the "host" to make a mod list and using perhaps in-game data streamming to load it for all guests?

With that said, i'm wondering how the loading of KSP2 would work.

Since we will have multiplayer, and in KSP1 we load everything before start, does it mean we have to choose single or multiplayer before open the game and load everything needed afterwards? Or will it be loading universal "stock" data then dynamically loading needed mods for an actual in-game save?

[Xavven]

How many of you have actually played KSP 1 multiplayer mods? My suspicion is that most of the opinions in this thread are not very informed.

KSP multiplayer is fun (and buggy because it's a mod, and MP really needs to be hard-coded in the game IMHO). You share each other's triumphs and cooperatively design different phases of missions to be inter-operable. I play Luna Multiplayer with 2 friends right now. Here are some fun things we do:

1. Person A designs and sends unmanned probe to Jool. Person B designs and sends an armada of communication relays to Jool as support. Person C designs and sends a fuel tanker for the probe to extend its mission. I would have liked to spectate during their flybys to get awesome views of their high-speed, low-altitude near collisions with Jool's moons, but there are bugs in Luna Multiplayer that prevented it. KSP 2 should solve that. Honestly, it's fun just to see what other people build, and increase their capabilities by flying some kind of support, or docking and refueling them and sending them on their way, and hearing their glee at how much delta-v they have thanks to you. Or flying someone else's satellite to Vall and announcing, "500 more science coming in thanks to your satellite!" over voice chat. It's basically virtual high-fives all night.
2. Person A designs a booster and payload inspired by SpaceX, launches it. Person B takes control of the booster after it separates from the upper stage, attempts to land it back at KSC. Person A flies the upper stage to orbit.
3. Same thing, as #1 except with a detachable spaceplane on a plane, just like Virgin Galactic.
4. Re-enactment of Apollo 11 (we did this last July to commemorate its 50th anniversary). Person A is Neil Kerman, Person B is Michael Kerman (Command Module Pilot). I designed the LEM while he designed the CSM and Saturn V.
5. Collaborative space station building. Person A delivers a habitat with mobile lab, Person B attaches a giant solar array and battery farm. Person C delivers personnel to the station.

Griefers: Some of you are worried about griefers. Honestly, I think KSP and KSP 2 are not games I would even attempt to play with random strangers. For those of us who have trustworthy IRL friends who play KSP, multiplayer in KSP 2 is highly anticipated.

Timewarp: In Luna Multiplayer, each player can timewarp forward independently of anyone else. When you do so, you basically get your own instance of the game. You can see others' orbits but you can't interact with their spacecraft unless you're in the same timeframe. There's a button that insta-time-warps you to another person's timeframe (but you can only go forward, not backwards in time), and that lets you do your interactive cooperative stuff, and then you go timewarp independently again when you go your separate ways.

Launchpads: There's a "bubble" 100m in radius around the launchpad (and runway) where you have your own instance of the game. You can't see or interact with any other vessels until you are outside this bubble. This is so that a person sitting on the launchpad doesn't get another player's rocket spawned on top of him. That said, you are advised to time your launches so you don't exit the safety bubble at exactly the same moment!

VAB: Luna Multiplayer doesn't let you both design a craft at the same time. Why would you, though? I don't see much value added here. You can send craft files to each-other using the mod in-game, though. This lets one person design a payload and send it to another player to design a launcher, for example. Or you just share craft and launch multiple instances of it with your friends (useful for relay satellite swarms).

On how MP could affect the community: We already bicker about game balance. Is MechJeb cheating? Is the Mobile Processing Lab overpowered? Is part clipping cheating? Is air intake spam (air hogging) cheating? --- not sure I believe MP is going to make it any worse. KSP isn't a PvP game with classes that have to be balanced against each other. Even if there is some kind of adversarial mode in KSP 2 MP, everyone will have the exact same parts available to them.

[Xurkitree]

damn, ya'll ready to play multiplayer meanwhile i'm going for single player lonely and alone

[KerbolExplorer]

10 minutes ago, Xurkitree said:

damn, ya'll ready to play multiplayer meanwhile i'm going for single player lonely and alone

Same.