New lobby communication implementation

[coryrc]

I've created a setup, in Python, that creates two "retarded"(1) trees and, essentially, syncs them between the client and server for the lobby. The host can change all settings via a tree-layout (just to get everything there right away). However, I made an error with the layout (see 1) that requires changes to pretty much everything I wrote. Since people really wanted it done in C++, I'll probably do a rewrite to that right now. So, please critique my plan:

First, I'll be keeping the synced trees plan. Every node has a name and a value, along with possible children. Every node name is a string and any string can have 0-9, a-Z, and _. The layout sent over TCP/IP is:
Set a value (create node if it doesn't exist): {root/child:value}
Misc command (delete node, send auth or user, etc): [delete:root/child][user:coryrc][pass:mypassword]

Other choice would be something with xmlrpc, if anyone has used that and liked it please let me know of your experiences.


(1): Wasn't originally thinking to make a tree and thus a thing can either have an option or children, which is rather limiting.

[Ace07]

It seems good to me! I am getting close to done with the lobby myself.

The netcode doesn't have to be extremely complex...but it doesn't hurt to have a good plan beforehand anyways.

[Tim Blokdijk]

Souds very technical
Will it allow me to play with two buddy's on a lan and one connecting via the internet?
Usning a NAT router on his and my end?

[coryrc]

Souds very technical
Will it allow me to play with two buddy's on a lan and one connecting via the internet?
Usning a NAT router on his and my end?

You should already, just change the script generated by the current client to match the internal IP. Please check the relevant thread for info on this.

[Ace07]

Cory, I don't think that writing it in C++ will be necessary unless you want to do both C++ and python. People seem to like python since it happens to work pretty well. (and the binary dependencies are only 15 mb)

I need to get working on adding more functionality to some of the dialogs...so...have fun with the netcode. =)

[Fnordia]

A problem with not doing the lobby in C++ is that you will have to reimplement a lot of functionality from the spring codebase. The current lobby accesses this through a few helper DLL's, but using the code directly would be a lot nicer. And if you are going for a pure python implementation you'd have to write the map handling, archive handling and unit parsing from scratch, and then there would be two codebases to maintain that does the same thing which seems quite wasteful (and bugprone) to me.

Anyway, I'd be happy to help out with writing a C++ lobby if you want.. We need to add stuff to the lobby to support mod switching for example also, but doing it in the current one seems a bit of a waste since it will probably get replaced.

[Ace07]

A problem with not doing the lobby in C++ is that you will have to reimplement a lot of functionality from the spring codebase. The current lobby accesses this through a few helper DLL's, but using the code directly would be a lot nicer. And if you are going for a pure python implementation you'd have to write the map handling, archive handling and unit parsing from scratch, and then there would be two codebases to maintain that does the same thing which seems quite wasteful (and bugprone) to me.

Anyway, I'd be happy to help out with writing a C++ lobby if you want.. We need to add stuff to the lobby to support mod switching for example also, but doing it in the current one seems a bit of a waste since it will probably get replaced.

I am fairly sure that python can load DLL's. wxWidgets offers a cross platform way to do it also.

Cory has already ported the required DLL's also. If we can't get the DLL's to load (which I don't see why we wouldn't be able to), then we can simply use another API that interfaces python and C++ code.

Also, I am not trying to make it so that people can't code a c++ version. The code-base for the C++ version is here. I am hoping that someone will pick that up some day and add the functionality that is needed to make it work. Currently, all the hard stuff in that codebase is done (the GUI and stuff). You only need to add a few lines here and there to make it all load up properly (assuming you have the wxWidgets api). We chose wxWidgets because of the many directions you can take with it. It is very easily portable, because that has been its goal for the 8 years its been in development.

Our decision to use python stems from the fact that we needed a Lobby as quickly as possible. Python code is very easy to write and debug, which is almost the opposite of C++ code.

[coryrc]

A problem with not doing the lobby in C++ is that you will have to reimplement a lot of functionality from the spring codebase.

Like Ace07 said, we can call C++ functions in Python almost as easily as in C++.

Anyway, I'd be happy to help out with writing a C++ lobby if you want.. We need to add stuff to the lobby to support mod switching for example also, but doing it in the current one seems a bit of a waste since it will probably get replaced.

Okay, but either way, what do you think of my plan?

[Ace07]

My question is whether or not it will work with both the Spring server, and the PW server. Or will it be its own protocol?

Will the default Spring server protocol need to be modified?

Other than that, I like the tree idea. It keeps things organized better.

Maybe you could give an example of a tree that might be used during normal operation of the client or server. That might help me to understand how it works better.

[coryrc]

My question is whether or not it will work with both the Spring server, and the PW server. Or will it be its own protocol? [1]

Will the default Spring server protocol need to be modified?[2]

1. I will be creating its own server first, then integrating into PW. It will need its own code mostly.

2. Replaced, I anticipate.

[NMDANGE]

My question is whether or not it will work with both the Spring server, and the PW server. Or will it be its own protocol? [1]

Will the default Spring server protocol need to be modified?[2]

1. I will be creating its own server first, then integrating into PW. It will need its own code mostly.

2. Replaced, I anticipate.

That's fine with me, I don't care much for the current protocol, it's a pain to program for, although I did manage it.

[Fnordia]

Ah okay.. Well I guess there's no reason not to continue in Python then.

About using a synced tree for the communication, I think it sounds like a good idea. It's nice with something general that doesn't need a new packettype or something for every setting in the battleroom.

Speaking of that, you are talking about the battleroom communication and not the lobby now right? Not sure if the terms are clear, but what I mean with battleroom is the dialog where a player hosting a game exchanges settings and chats with the other players before launching. And the lobby is the client that connects to the master server and allows global chatting, and gives a way to find these battlerooms that players have hosted.

Anyway, it would be nice if the battleroom is designed to operate independently of the lobby, so that LAN games can be hosted just as easily as internet games. This is mostly the way the current lobby works even though it currently won't allow you to host a battle without connecting to the master server first. It sounds like you are doing it this way, so I'm just pointing it out to be sure. :)

Some thoughts on the tree stuff: First, just to make sure I'm not completely off, the idea is that the tree is shared between the host and all the clients right? And when the host or a client updates a node/value this change is replicated through the host to all the other clients.

One thing that might be useful if the client could each have a "private" part of the tree that is not replicated to the other clients, only to the host. This would be useful to sync units. The client can put all the required info such as unitname+md5 in their private tree, and the host can then take the info from all clients and update another part of the tree that tells each client which units to use. The private tree is not stricly needed though of course, since if all clients know every other client's unitset they can all build the correct restrictionlist. But it is more efficient if only the host does it, since it is quite a few kilobytes of data to send.

[Ace07]

Speaking of that, you are talking about the battleroom communication and not the lobby now right? Not sure if the terms are clear, but what I mean with battleroom is the dialog where a player hosting a game exchanges settings and chats with the other players before launching. And the lobby is the client that connects to the master server and allows global chatting, and gives a way to find these battlerooms that players have hosted.

The program is going to have tabs more or less. When the lobby starts up, a LAN tab will open, allowing you to create games over a local LAN really easily. You don't have to connect to the spring server to access this feature either.

I hope the whole tabbed interface works out.

(I love firefox.)

[coryrc]

Speaking of that, you are talking about the battleroom communication and not the lobby now right?

Yes.

Anyway, it would be nice if the battleroom is designed to operate independently of the lobby, so that LAN games can be hosted just as easily as internet games. This is mostly the way the current lobby works even though it currently won't allow you to host a battle without connecting to the master server first. It sounds like you are doing it this way, so I'm just pointing it out to be sure. :)

Of course!

Some thoughts on the tree stuff: First, just to make sure I'm not completely off, the idea is that the tree is shared between the host and all the clients right? And when the host or a client updates a node/value this change is replicated through the host to all the other clients.

Yes, and the clients can only make changes to parts of the tree they own.

One thing that might be useful if the client could each have a "private" part of the tree that is not replicated to the other clients, only to the host. This would be useful to sync units. The client can put all the required info such as unitname+md5 in their private tree, and the host can then take the info from all clients and update another part of the tree that tells each client which units to use. The private tree is not stricly needed though of course, since if all clients know every other client's unitset they can all build the correct restrictionlist. But it is more efficient if only the host does it, since it is quite a few kilobytes of data to send.

Yes, I had implemented it this way. I had not thought of doing this with the units and that is a very good idea.

[Torrasque]

Sorry to bugging you, but i'm really waiting for a cool battleroom like you are doing

Any news from the front?

[Ace07]

I am currently waiting for Coryrc to finish the netcode so that we can get the rest of the coding done. Since the lobby is mostly a netapp, you really need the netcode before you can see true functionality.

[coryrc]

Sorry to bugging you, but i'm really waiting for a cool battleroom like you are doing

Any news from the front?

Okay, I have it planned out, but using that nasty portable-but-not-distributable number 2 coding language. Need to continue implementing. I'm taking my time to make sure that it is done correctly and never will need to be done-over again. I can use non-coding help in the form of writing descriptions for all the options in the start file in the form of:
[
("GAME/Gamemode", "1 means when commander dies something happens or doesn't"),
("GAME/Mapname", "Filename of the map include .sm2 extension")
]
Preferably more verbose than existing documentation.

Everyone, but particularly Ace07, as it is planned, it will update the tree automatically and send notifications to the GUI application like {coryrc/Team} for an updated value in the options tree or [commandname:value] for commands it doesn't understand or doesn't want to process. Check out the comments for the files at the location:
https://lolut.utbm.info/svn/taspring_li ... /syncTrees

[Ace07]

Okay, I have it planned out, but using that nasty portable-but-not-distributable number 2 coding language. Need to continue implementing. I'm taking my time to make sure that it is done correctly and never will need to be done-over again. I can use non-coding help in the form of writing descriptions for all the options in the start file in the form of:
[
("GAME/Gamemode", "1 means when commander dies something happens or doesn't"),
("GAME/Mapname", "Filename of the map include .sm2 extension")
]
Preferably more verbose than existing documentation.

We really need this actually. I can do most of it, but we really need someone to post a really verbose text file on what everything does. There are people here with more experience in that area than us.

This is the best I can do:

Code: Select all

//Send a file formated like this as the only command line argument to spring.exe
//All players must get the exact same file except MyPlayerNum (and possibly hostip)
[GAME]
{

        GameMode=x; // 0=commander continues (same as before), 1=commander ends (whole team dies when commander die)
	Mapname=xxx;		//with .sm2 extension
	StartMetal=xxx;		//Starting metal for this game (everyone starts with the same)
	StartEnergy=xxx;	//Starting energy for this game (everyone starts with the same)
	MaxUnits=xxx;	      //Starting energy for this game (everyone starts with the same)
	StartPosType=x;		//0 fixed,1 random,2 select in map


	hostip=xxx.xxx.xxx.xxx
	hostport=xxxx

	//some more stuff like this here

	MyPlayerNum=x;		//only variable that should vary between different players
	NumPlayers=x;		//the number of players the game should expect
	NumTeams=y;		//the number of teams that are controlled by more than one player (they share a commander)
	NumAllyTeams=z;		//the number of traditional alliances between commanders

	[PLAYER0]		//a player (player 0 is the host)
	{
		name=name;
		Spectator=0;       // is this player a spectator? 1 or 0
		team=number;       // team number, must have a corresponding entry after all of the players have been defined

	}

	//more players


	[TEAM0]		//players in this will share the same units (start with one commander etc)
	{
		TeamLeader=x;			// player number that is the "leader"
		AllyTeam=number;	     // Is this team allied with any other team?
		Color=number;	    // 0-9, there is a link at the bottom that shows what 0-9 is
		Side=Arm/Core;			//other sides possible with user mods i suppose
		Handicap=0-100;			//Percent bonus on all resources collected	
                AiDLL=file;                     //Creates an ai for the team using the dll file specified. The teamleader field is used to determine which players computer will run the AI.
	}

	//more teams



	[ALLYTEAM0]			//teams in ally team share los etc and cant break alliance, every team must be in exactly one ally team
	{
		int NumAllies;
		Ally0=(AllyTeam number);		//means that this team is allied with the other, not necesarily the reverse
		//..
	}

	//more ally teams

	//something for selecting which unit files to disable or restrict
	NumRestrictions=xx;

	[RESTRICT]
	{
		Unit0=armah
		Limit0=0		//use 0 for all units that should be completely disabled
		Unit1=corvp
		Limit1=50		//>0 can be used for limiting, like build restrictions in TA
		//...
	}
}

0-9 colors. That picture is basically what the colors in Spring currently are. It looks like we have 10 player colors actually.

[AF]

You forgot the AI entries there Ace, tho I dont knwo exactly what they are, SJ has pointed out that they do exist and will be present in the next major release.

[Ace07]

I added the new ones in there, so it should be up to date now.