i managed to get it to work >:)
but it crashes alot >.>

im am now learning how to use this :P

Win32 builds available!

someonesomewhere: Sounds like a possible solution to the problem, even though there's still the minor problem of floodfilling the falling blocks, I suppose. By the way, I just got a reply from Ken Silverman, the man behind the VOXLAP engine: http://paste.pocoo.org/show/S9H5mKY011TWPaRNSA25/
As I mentioned earlier, we should actually be working on the VXL structure, since we can check the RLE-compressed Z-columns/spans efficiently. I'll try and whip something up soon :)

As noted in the other thread, I'd be tempted to store the entire map (well the solid nodes anyway - you can disregard the empty/internal ones I think) as a graph and then just look for disconnected vertices or disconnected groups/components of the graph. There are algorithms for this sort of thing already. Once you've found a disconnected component, remove it from the graph.

Not really thought about it much but "brute forcing" the paths to ground sounds a bit inefficient. Worst case scenario is I have a map filled with blocks apart from the bottom-most three layers with two columns, one at 0,0 and the other at 512,512. If I take out the column at 0,0, will it search through every single block in the map until it gets to 512,512? Gut says its a bit sucky :)

Triplefox: Interesting idea, it seems (even though I haven't fully grasped it yet). I should probably make load_c.cpp work on the VXL structure, and not the 'unpacked', gigantic array so we can use this method in the future (as far as I've understood, that's necessary). In any case, it would be great if you joined #AoS@QuakeNet so we could possibly implement the idea :-)

The RLE used in the VXL format suggests one possibility for improvement. We should start by caching the surface blocks along each Z column. That will allow us to start searching the top and bottom surfaces of a shape immediately, rather than expanding through the middle.

Subsequently, when we expand we should treat inner blocks differently. After thinking about the problem a long while, I'm pretty sure that inner blocks are only useful if they immediately expand to other surface blocks. i.e. we don't expand from an inner block to another inner block. And the only reason we need to use inner blocks at all, and can't simply stay along the surface, is because of corners; the pathological case is a diamond shape. We have to have the inner corner to know that the surfaces are connected.

Edit: I forgot to mention: the inner-to-surface trick only works if we use the Z cache to expand across the inside of the shape. Otherwise hermetically sealed caves will exhibit an "onion peeling" effect because they'll finish traversal without ever touching the ground.

Szuwar: I don't think you get the protocol completely :) Basically, the *client* sends the PositionData, not the server (the protocol is very client-sided, yeah). It wouldn't take that long to finish the client, but it's not a priority. You're free to contribute if you want to, though :)

What I need help with the most is the floating block code - the current algorithm is a bit slow in corner cases (eg. in BridgeWars when people destroy the fundament of the bridge). hompy has been excellent in providing help on this, but if anyone wants to contribute, please have a look (the relevant function is 'check_node'): http://code.google.com/p/pyspades/source/browse/pyspades/load_c.cpp#116

I actually thought about writing some kind of a zombie-bot. The movement seems to work pretty good but I can't retrieve any information about zombie position. There is probably lack of something in my code as it get information about player who's connected by standard aos client but nothing about zombie (only PlayerData, CreatePlayer and ChatMessage). Anyway good luck with your server as it brings us a lot of possibilities.

Szuwar: I don't like supporting old Python versions (it's not fun writing a compat.py), and if you've got control over your server, it shouldn't be a problem anyway. I just use the stdlib json module, by the way, which is probably simplejson.

The client is merely there for testing purposes. Unless a really good reason comes up for finishing it, it's not going to be hacked much on. It does support fetching the map from servers already and it can join the game - basically, the packet loaders/writers are there already, they just aren't used. I suppose it would be cool with an alternative client, but it'll be work ;)

want >:)

matpow2, there is a small problem if you're using python below version 2.6 (in my case 2.5.2). After installing json module (from Ubuntu 8.04 repository) it has no method called 'load'. Switching to simplejson seems to work.

Also are you going to develop a bit more your client?

I just added SSH, by the way.

:-)

matpow2 wow!!! very good!!!
* togglebuild - Toggles building/destroying blocks on the server
* togglekill - Toggles killing/shooting players on the server
* toggleteamkill - Toggles friendly fire

this features allowed add more game modes and phases!!!!

There are log files, yeah. I'll also do SSH very soon.

I might make a new topic, now that the 'WIP protocol implementation' title is quite misleading - pyspades is a very stable server, and it uses a lot less CPU than the original implementation, and in combination with the open-source, extendable nature of it, it's way ahead of Ben's work. It already has a lot of configuration options and in-game administrator commands, so people should seriously start considering switching to pyspades IMHO.

Current commands include:
* login - Login as administrator
* pm - PM another user
* kick - Kick another user
* votekick - Extended votekick (with updates on progress)
* ban - Ban a user
* mute - Mute a user
* unmute - Unmute a user
* kill - Kill a user
* heal - Heal a user
* lock - Lock a team (so nobody can join it)
* unlock - Unlock a team
* setbalance - 0 for no balancing, 1 for 1 extra player on a team, 2 for 2 extra players, etc.
* rules - Sends the rules of the server
* togglebuild - Toggles building/destroying blocks on the server
* togglekill - Toggles killing/shooting players on the server
* toggleteamkill - Toggles friendly fire

Upcoming features include:
* SSH
* Map metadata (so map makers can make blocks indestructable, etc.)
* A binary build for win32 (for the people that don't want to get dependencies and compile)
* A lot of other stuff that I can't recall ;-)

pyspades has been tested on Linux, Win32/64, FreeBSD and OS X so far, but should work on any appropriate platform with Python, Twisted and a compiler available.

10se1ucgo So we now have remote control of the server?

Or you thinking RCON is ingame admin?

Keep up the good work!

he did. The command is /login. Lawl please read :P He didnt add logs though i beleive

Can you add rcon and log files?

bump

Just a heads-up: The server seems to be complete. I've added some admin features like login/kick/kill/say, and the server can be configured a lot more than the normal server can. I'll make a binary package for win32 once I've implemented compression (which is a minor issue at the moment - it just means more traffic).

In any case, make sure to check it out! I'll fill the wiki when the time seems appropriate.

I will do whatever I can to prevent cheating. The source *is* open-source and GPL, so if you have cheating troubles, you will be able to fix it yourself :) Of course, Ben isn't supposed to have pyspades in mind when developing on his project - I'll have to reverse-engineer new stuff he implements (unless he wants to tell me about it, which would be great, Ben!). Doing the custom implementation now is only a good idea - Ben will probably not do major changes to the protocol, so I'll only have to spot the small protocol changes he introduces.

Awesome this is great stuff.

I was wondering if/how you plan to do any server-side anti cheat type stuff and generally keep-pace with the development of the game? I really really like the idea of a "better" server but am concerned its going to get fragmented - afterall fragmentation is what killed infiniminer.

I've done a lot of progress on this. I've got nearly the whole network protocol reverse-engineered down (pretty much all server->client packets, missing some client->server packets still), and my custom client can retrieve maps from servers perfectly. I hope to have a 'demo' ready soon (that is, if I manage to progress so well further on) :-)

I did, and it's been a week or so (seeing as he released an update just today, he either doesn't check his mail often or he's ignoring me completely).

I'm tired of very closed developers (I've done a complete server implementation before of a game, pySndo, where the author didn't want to maintain the game anymore, and didn't want me to do it either), so if Ben would become social around the community, that would only help.

I'd suggest you to email Ben since I don't think he checks the "Off-Topic"-section very often.

Auto map reset and changing the map without disconnecting players is probably not possible (I don't think the client can do it), but the other features are definitely possible once the server has been implemented ;)

looking forward to this

native Linux support is very much needed

are these features possible?

- auto reconnect to master server
- in-game text output to console (chat, kills, captures, etc.)
- console say command
- auto map reset
- motd and rotational announcements
- basic rcon for in-game admin messages, kick/ban, etc.
- change map without disconnecting players

it sounds pretty cool, I love this python brogramming language. good job with the cross platforming

There's no EULA stating that I can't reverse-engineer it for interoperability, and I'm doing this for the whole community, so I can't see why it wouldn't be a very good idea. ;)

Ben has never disapproved work like this, so I'm not quite sure why you would think otherwise.