The network handling code has been re-written from the ground up on the client side and it seems to have eliminated all performance issues I also eliminated some memory leaks that were present before and I’m happy to say, The state of project Cartographer is STABLE!.
So what’s next on the agenda?
Let’s take a look at what’s currently done.
During my previous fix I changed things around so much that I actually introduced major performance issues the processing time of each packet went up and part of which seemed to also have introduced some sort of memory leak.
Over all the current state of project cartographer is unplayable and unstable with that said we still need people to test once in awhile and lately it’s been hard finding anyone around (in Teamspeak) enough to do so we have 1 or 2 dedicated people willing to test through the agony of lag, crashes, and random other events with us.
Right now what needs to happen is a complete re-write of all packet handling systems there’s tons of inefficient and poorly done things which I’m just now re-thinking and re-structuring.
What I’m constantly seeing from people though is the misunderstanding that this project is currently in a state where we’re even looking for bug reports, or that you can even use it.
If you download this to test with us please do not report things like,
“I crash”,”It doesn’t work”, “It’s laggy”,”Help me”.
These things do not help us improve the code for you and the rest of the community these things only begin to frustrate me and misdirect my attention to issues other then what’s important which is creating a playable stable solution for everyone to play their games with.
Hopefully I have more news soon for the community and here’s to it being good news once I complete this re-write of the whole user handling system, another late night in coming.
So originally you were unable to run 2 clients or 1 client and a server on the same network or same machine,
Now I’ve come up with some what of a fix and it’s pretty messy but it works!
Basically the way I was handling things previously you couldn’t run multiple clients on the same network or same PC even due to the fact that everything was binding to the same port and there were tons of comparisons and identification systems which would identify people based on their WAN IP address instead of some other unique identifier.
Now that I’ve changed the code to identify people differently and added a “server” option to the INI which you’re expected to set in one client/server on the network it will re-bind ports differently.
To explain if I want to run a server on my network I’ll leave it as “server = 0”, I know it’s kind of backwards…
This will cause my server to bind to standard ports 1000,1001,1005,1006.
Now when I launch my client and I set “server = 1”,
My client will bind to 1100,1101,1105,1106 and the rest of the network code in every other client and server will handle this appropriately based on data of where they receive the connection from, what this may break however is the ability to make a lobby due to the fact naturally when trying to connect to lobbies clients will attempt to use the standard ports.
So essentially you can only have 1 host per network at the moment, though this needs to be looked into in a less messy/sloppy manner so that we can run multiple instances of a dedicated server on a single system.
The only idea that I have to brain storm on with this is sending the port with the broadcast packets and having each client read/understand this,
The problem is at this point this is becoming less Universal and more geared towards Halo 2 which isn’t necessarily a horrible thing, just requires a lot of re-coding of the base.
And may mean that in the future I will have two separate versions one specifically geared towards Halo 2 and another which is universal for all XLive games.
For those who understand python read on…
There were also minor modifications I’ve had to make to the master server list which changed how users were stored,
Originally I stored users when they initially made a halo 2 specific “broadcast-search” packet.
In general this is the way LAN configurations in games should work…
Client->Broadcast to 255.255.255.255 (Entire Local Network) -> Server gets packet and sends reply with information.
Right now the way the code works on this end is simply replacing 255.255.255.255 with the “broadcast server” or “master server list”.
The way I stored the users was based on their remote IP without their port, now we just store the self.client_address tuple into the dict and use that.
Basically since each user would be now using a different port we combine the two to uniquely identify them, the way I was doing things previously would overwrite their user in the dict causing them not to be able to see the server… just a lesson to myself in bad programming practices attempting to identify people by IP addresses which I did a lot starting out with this project.
The current state of Project Cartographer is quite buggy to say the least,
It works you’re able to join games there’s no tunnels/vpns(Hamachi,Tungle,etc) or extra stuff besides our single DLL required.
How it works?
It replaces GFWL(Games for Windows Live) libraries and executes network code to simulate a LAN connection over the internet ( Yes this means we use the LAN browser ).
The limitations of this are,
- Custom Map downloading currently does not work.
- You can not view another player’s latency
- There’s no way to customize how you view servers, or to bookmark them or etc.
- Things are still quite buggy 😉 just remember it’s pre-alpha software at the moment.
Even with limitations there are pros to be had,
- Because we package things by injecting data into normal halo2 packets instead of making server requests during joins, this should eliminate Join Lag.
- You’re able to join games faster as well due to the above point.
- The game’s performance over all has been improved by the removal of this.
- The 30ms ping limitation does not exist.
- We will be re-implementing all of the removed functions (bookmarking servers, sorting, map downloading, and player latency viewing).
What can it currently do?
Currently the most you’ll get out of this is playing some quick matches with friends, but in the future there are plans to integrate tons of things.
- Re-integrate a new H2V friends list or a “XLiveless” friends list across all GFWL games.
- Add custom Game Types/Variants to H2V (Zombies with automated team switching and etc, Cat & Mouse where people are automatically spawned in the vehicle etc).
- Real matchmaking systems.
- TeamSpeak API to integrate VOIP since H2V is missing any voice chat capabilities.
- And more.
Let me start by first telling you what The Project Cartographer is,
The Project Cartographer is an attempt at reviving Halo 2 Vista which started with the multiplayer services going down for it and no one hearing any information about it’s return.
Now while this is the initial goal,
Due to the method being used to perform such a feat I’ve also began focusing on other GFWL(Games for Windows Live) games which have had their multiplayer servers also discontinued, but we’ll get more into that later.
For now looking at Project Cartographer you’ll see it is a replacement for XLive and all multiplayer services in Halo 2 Vista,
It is in a functional alpha state currently and was not planned for public release there are people currently testing and we’re always open to additional people granted you’re able to use TeamSpeak and communicate actively with us on issues as well as not expecting a bug free release as this is still a pre-alpha release.
As far as getting the actual files and helping us test please check out the Halo2Vista forums,