[Unknown Target]

Could this be done? We've got a big 200 person LAN coming up, and me and another guy were thinking about having an open FS2 server running through the whole thing, it'd be great if the game supported deathmatches (a la UT - midgame joining, etc), and multi that wasn't super laggy on the LAN connection.

Any progress/ideas?

[Shade]

You could try using one of taylor's 3.6.10 Xt builds, those are inherently less laggy in my experience so it may help the problem some. Probably won't make it go away though. The 10/28 build would probably be the best pick, as later builds (not sure how much later, still testing that) have a sound problem in MP, but I know for a fact this one doesn't.

3.6.10 will also let you show off normal maps, which might raise a few eyebrows for a game this old

[Unknown Target]

Well one of the major things that's needed is a more modern multiplayer environment, i.e. being able to join the game, view the scores by pressing a key, then leave the game and if you desire, rejoin it. I know mid-mission joining was being worked on, dunno if there's any progress on it though.

[n0s]

well, mid-mission joining would help online-gaming too, i'd say

[Bob-san]

As long as you set unlimited respawns for games, that'd work. I don't think many people would sit for 5+ minutes while teammates complete the mission without being able to play. They'd probably leave the game and may try another. That, and basic training missions are a must.

[chief1983]

Aren't midgame joining and dedicated server both currently options that builds recognize?  I've never tested them before, but it sounds like it couldn't hurt to try.  There is a lot of interesting multiplayer stuff in the works right now I think, you could see how well you fare with one of Taylor's Xt builds from this month (2/22 is the latest right now I think).

[CP5670]

Ingame joining is an option but it doesn't work at the moment, although people try to do it all the time and it creates some odd effects. If you are on a LAN though, you shouldn't get the random dropouts that occur online.

As long as you set unlimited respawns for games, that'd work. I don't think many people would sit for 5+ minutes while teammates complete the mission without being able to play. They'd probably leave the game and may try another. That, and basic training missions are a must.

Unlimited respawns are not needed. The new player can simply take an AI's spot and inherit whatever respawns it has left, although I guess he would be stuck with the AI's ship and weapons.

[Shade]

although I guess he would be stuck with the AI's ship and weapons.

Man, that would really suck on a mission like odd_m02 (robin hood) "Hi! Welcome to the game. You've got a boanerges with a circe and a full load of stilettos. Now go make yourself useful."

[Bob-san]

The problem I was having is the launcher refused to launch--it gave me a DirectX error because it was an old OS, so I couldn't flag it properly.

[feltoar]

As long as you set unlimited respawns for games, that'd work. I don't think many people would sit for 5+ minutes while teammates complete the mission without being able to play. They'd probably leave the game and may try another. That, and basic training missions are a must.

Im not so sure. On Xbox Live people are usually patient enough to wait. Especially in games with low participation.

[Bob-san]

How about this--mid-mission changes in ship and weapon? So, after half the mission is completed, your next death triggers an optional Ship & Weapon tab to change your ship and weapons on the quick. Obviously it won't be on a Gauntlet, but I see no problem with it on Team games (not Co-Op, since missions are usually 10-15 minutes long it seems).

[karajorma]

// --------------------------------------------------------------------------------------------------
// INGAME JOIN DESCRIPTION
//
// 1.) Joiner sends a JOIN packet to the server
// 2.) If the server accepts him, he receives an ACCEPT packet in return
// 3.) The client then moves into the INGAME_SYNC state to begin receiving data from the server
// 4.) The first thing he does on this screen is send his filesig packet to the server. At which
//     point the server will either let him in or deny him. There are no file transfers ingame.
// 5.) The server calls multi_handle_ingame_joiners() once per frame, through multi_do_frame()
// 6.) After verifiying or kicking the player because of his file signature, the server tells the
//     player to load the mission
// 7.) When the mission is loaded, the server, sends a netgame update to the client
// 8.) Without waiting, the server then begins sending data ship packets to the player
// 9.) Upon confirmation of receiving these packets, the server sends wing data packets
// 10.) Upon completion of this, the server sends respawn point packets
// 11.) Upon completion of this, the server sends a post briefing data block packet containing ship class and
//      weapon information
// 12.) After this, the server sends a player settings packet (to all players for good measure)
// 13.) At this point, the server sends a jump into mission packet
// 14.) Upon receipt of this packet, the client moves into the ingame ship select state
// 15.) The first thing the client does in this state is load the mission data (textures, etc)
// 16.) The player is presented with a list of ships he can choose from. He selects one and sends
//      an INGAME_SHIP_REQUEST to the server.
// 17.) The server checks to see if this request is acceptable and sends an INGAME_SHIP_REQUEST back
//      with the appropriate data.
// 18.) If the client received an affirmative, he selects the ship and jumps into the mission, otherwise
//      he removes it from the list and tries for another ship
// --------------------------------------------------------------------------------------------------

From the sound of it the player is allowed to pick his ship from whatever is left in the loadout. I've not actually tried it yet though.

[CP5670]

although I guess he would be stuck with the AI's ship and weapons.

Man, that would really suck on a mission like odd_m02 (robin hood) "Hi! Welcome to the game. You've got a boanerges with a circe and a full load of stilettos. Now go make yourself useful."

I was thinking about the exact same thing after I submitted that post. RH is the only one where we've had to resort to that though, so we can just fix that particular mission.

From the sound of it the player is allowed to pick his ship from whatever is left in the loadout. I've not actually tried it yet though.

So does the new player see the entire briefing/loadout screen first, before actually entering the game?

[karajorma]

Haven't looked at the code yet. That's an old comment on how the system was meant to work. For all I know it's out of date by now. I only actually noticed that comment this week cause I opened the wrong file and kept reading.

It might be possible to add other steps in-between to allow weapon selection if need be. It also appears that at the end of a game all the people who did join are kicked. That will probably need to change too.

[WMCoolmon]

Does change-ship-class work over multiplayer? If so, it might be possible to script a menu and then trigger that SEXP. You could even use persistent variables to set the ship name, so you could use script-eval-num and return 1 when the player selects something, and then use change-ship-class with a variable set by the script called by script-eval-num.

[karajorma]

Unfortunately it doesn't. The SEXP doesn't do any sort of multi callback (along with about 90% of the new SEXPs).

But we could simply add a hook to the change_ship function that the SEXP uses and call that instead perhaps.

First thing to check is whether the game does all this already anyway though.

[WMCoolmon]

It doesn't do any good to add a scripting hook to the change-ship SEXP, unless SEXP variables are persistent across network connections. You could do something reaaaaaaaaaaly hackish if they are by using a variable to set a player name, another to set the ship they're switching to, and another to set the number of clients that still need to retrieve that info (decremented each time each client receives a new request).

Unfortunately two requests in rapid succession could possibly screw that up, along with clients disconnecting in the middle of a ship change update.

[karajorma]

Ah. I see your point. In that case it's probably best to get it to work through the code rather than trying to fix it via Scripting. You can have variables pass information across the network but it's a one way flow from server to clients. It wouldn't be hard to fix it to allow two way flow though if scripting wants to use it.

[Kazan]

yes the ingame join gives them a ship seletion screen and the select.. works too... don't remember what weird effecst you get from in game joins

[Shade]

I'll try to test how well it works on recent builds this saturday. I haven't tried it for a while and lots of stuff may have been fixed since then.