Serverless Multi

[SinbadEV]

Would it be possible to make a client/setting that would let you specify an IP and port in command line and automatically attempt to join a battleroom hosted on the hosts computer... that way you could basically use IM or IRC or even implement plugins for other matching services (or I was thinking GAIM) that would let you join a local area network game or internet game and build the map script instead of how you have to manually edit everything and share the settings to do serverless multi... I'm thinking future Xfire support acctually too... also, it would be nice if at the end of a match before everyone get's booted and everything has to be re-loaded we had the option for a rematch... also, having spectators join mid game and then become able to be players in a repeat match...just babbling here I know... but it would be nice to be easier to get a game going and all... then people could leave themselves hosting as spectators when they are away from the computer and people with routers and firewalls and all could keep joining posted games... something like that would be nice...

[AF]

Start a single player game on the host, by running spring.exe directly and saying yes. Then connect to the host using it's IP by saying no and typing it in. Then it should connect to the host and start loading. If you wanna change the settings edit script.txt and give it to spring.exe as the only command line parameter on the host.

[SinbadEV]

Alantai Firestar: You have responded to the first part of my first point by proving that the process is needlessly complicated. The fact that there is no lobby, or version checking or anything in the process you have descibed illustrates the problems my suggestion is trying to circumvent.

[AF]

Well people have to join when the game starts. It's how the network code works and thats the end of it without a compelte code rewrite according to SJ.
Rematches are for the lobby program, just make everyone check again and press start.

As for serveless multi, when you play a game it's settings are stored in script.txt so if you edited it and played with it you dont need to edit again.

Or you can just go through the simply menus SJ wrote for when you manually run spring.exe (put a shortcut on your desktop and just drag script.txt onto it or make a set of commonly used and just change the mapname then darg onto it.

If not a program that edited it for you would be just as good as a new lobby prog for serverless play

[SinbadEV]

The BattleClient and BattleHost objects of the current client software are all locally run components, all you would need to do... well from what I see anyways... would be to rip these components out and let them be run locally with command line options... same code, different grabby bits... or at least that's how I see it... You're right about the rematch thing being handled by the lobby, but it would be nice if new joiners could jump into the lobby and choose to be spectators right away...

[SinbadEV]

I had another Idea... perhaps a command line parameter for the Client that would auto-login to server and attempt to join a specified game... that way one could 1-click to the battle-room... again for example in an IM client...

[AF]

Or maybe just an autologin option in the lobby.

[Maelstrom]

Yes, an auto login would be good. And the auto-game joining. Would make it so much easier to add to on line game services. GameArena hosts many games, and is always open to suggestions for new games. as has been mentioned, simple things like this are neccesary if this is ever to go really big.

[AF]

We should keep the multiplayer system centralised. That way we get better support, more players etc... If we start splitting it up it'l cause problems. So really it shouldnt be done till phoenix worx are complaining they cant ahndle the bandwidth.

[SinbadEV]

Good Point... does anyone know if any of the client's properties (like list of games etc.) would be accessable to external code? like this COM thing I keep hearing about.

[AF]

The lobby is pretty much a script.txt writter that distributes the hosts IP and provides a chat service. All game settings are written to script.txt and then passed to the game that way.

[AF]

The lobby is pretty much a script.txt writter that distributes the hosts IP and provides a chat service. All game settings are written to script.txt and then passed to the game that way.

[SinbadEV]

the lobby also acts as an interface with the server and can tell what games are available, full, being played, passworded, who's in those games and who else is logged into the server... if you've ever seen a program called Xfire ( http://www.xfire.com , it's a cross between a matching service and a IM client )... if support were implimented and the stuff the lobby sees could be made available outside the software, then (in theory) you could come online and have Xfire open and then be able to see if any of your friends were logged in to the pheonix server...

[BeastmasteR]

EDIT:
I mangaged to get xfire to detect TAS but only as a game that is being played. I'm not sure if it shows viewers if I'm connected to the TAS server but it is now showing up as a game being played in my status bar of xfire along with my profile.

This is what you have to change to the xfire_games.ini

Code: Select all

[4563]
LongName=Total Annihilation Spring
ShortName=tas
LauncherDirKey=HKEY_USERS\S-1-5-21-1177238915-1935655697-839522115-500\Software\SJ\spring
LauncherExe=TASClient.exe
Launch=%UA_LAUNCHER_EXE_PATH% %UA_LAUNCHER_EXTRA_ARGS% %UA_LAUNCHER_NETWORK_ARGS%

__________________________________
Previous Post
After reading all of the above, I take it support for xfire has yet to be accomplished. I will post what xfire looks for in order to detect spring.

Code: Select all

[4563]
LongName=Total Annihilation
ShortName=ta
LauncherDirKey=HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectPlay\Applications\Total Annihilation\CurrentDirectory
LauncherExe=totala.exe
Launch=%UA_LAUNCHER_EXE_PATH% %UA_LAUNCHER_EXTRA_ARGS% %UA_LAUNCHER_NETWORK_ARGS%

As you can see unlike the other games Xfire does not have a installhint line, so assuming that spring points to a "totala.exe" and a registry key is added to match the LauncherDirKey, then xfire should only then detect spring. Wouldn't you say?