JoWie

Have you tried getting a better internet connection?

would have been fun if asss was AGPL

you shouldnt really be using threads directly, you should be using the timer stuff, which just spawns a worker thread just use the standard interfaces i havnt had any issues with them at all I am not talking about spawning threads or using working threads. If you write a non trivial module, you will have to think about how asss uses it threads (usually so you know when to lock). There are callbacks that can come from a thread that is not the main. Threads are involved in the crashes of hscore. I am not saying threads are bad, I am saying how they are used in ASSS is unnecessarily complex. Also, I remember you pming me for help with issues that ended up being related to threading a few times.

The most time consuming and biggest source of mistakes are when dealing with threads in ASSS. I think it needs a different approach to threading if it should get more adoption. I also suspect there might be a few bugs in the core asss code related to threads, but I am not sure about this.

If set up corretly, you can use all the bots that are used on subgame

I have his contact info but only if you say please.

Have you tried using inverse multiplexing for the WebSocket network communication?. Could help with incidental packetloss. The big issue with TCP is the buffering after packetloss/bit error/etc occurs (one segment gets dropped/damaged, subsequent segments are delayed until the bad segment is resolved). Those may have been the big latency spikes in the video. If you implement a system where you: + use multiple WebSockets + track the arrival of the messages you send (other party replies with an acknowledgment message) + when sending, use the socket with the least in-flight/unacknowledged messages. This works especially well for redundant data (like the position of a player). I tested this a while back, and as long as you have enough sockets and the cause of packetloss is incidental (like bit error) and not caused by congestion, the latency is comparable to UDP. Of course this assumes your engine is able to deal with messages arriving in the wrong order. Oh, and this piece of javascript code may be interesting (works for me with firefox + java): http://pastebin.com/6tYG8rqK . Uses LiveConnect to open an UDP connection without user interaction. Downside is that it does not work on localhost, only works with domains if you set up a reverse dns.

http://www.youtube.com/watch?v=f1NXF0TYmNM&hd=1

i liek trains

The end goal is to kind of make it a game platform. But the while the first versions ensure that there are no constraints in things like the network protocol, a lot of stuff will not be very generic yet. Oh, Aphelion has 367567200 rotation points at the moment. The idea is that you can define the rounding in the zone setting, for example if you configure this setting to be 367567200 / 40, you get the same amount of rotation points as continuum.

You could just have specific days or times in which private freqs are allowed.

It will not be compatible with continuum, so it would probably be done in a different way

At the moment I am only doing the networking and physics. Jabjabjab is doing the rest

My idea was not to run a XMPP server per zone. Only one for the entire game (or perhaps one per zone network, like ssca, sscu, etc). That way you avoid placing too much trust in zones, I do not want to have players worry about the zones they enter. I have written an IRC server and a few bots, IRC has a lot of annoying limitations (if you want to support existing IRC clients of course).

Yes, that was not intended for chat local to the server (pub chat, etc). Not involving the game server with remote chat is also easier to secure (against evil game servers). As for commands, it is very likely everything is going to become a command (like firing your weapon). You would then be able to map any command to a keyboard button.

yea one of the ideas was to have separate chat servers. But probably not IRC because it has a lot of limitations, especially with nicknames. I had to use a lot of workarounds in that asss irc server script. XMPP (jabber) looks nice. It is a decentralized protocol and extensible. Every in game player could have a nickname@subspace.net handle. And someone with google talk, pidgin, etc could communicate with you.

Current idea is to allow the server to send ecmascript/javascript files which are run in the JVM (Java 6 has Mozilla Rhino), these would be sandboxed by using a SecurityManager.

I seem to recall from a couple of years ago (so I am not sure about this) that the area of effect of a repel is square and not round. So perhaps instead of using distance sqaured / pythagorean, it calculates the speed difference for x and y separately.

I think he is talking about:

There is always something that is centralized. Just have to make sure that it is possible to replace it.

This might be a relevant read: http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

Client-side and network-level game-rule cheating is preventable (as far as i know, twister was mostly this kind of hack). Fully preventing this comes might come at a cost though (network/input latency, complexity). A lot of first person shooters protect against this. This leaves client-side augmentation (aimbots), server-side hacking and social cheating (players colluding, multiple clients, et cetera).

i'm on some waiting list. I want to use it to simulate bad networks. I'm getting sick of using 3 laptops. I also looked at CuBox which has 4 times the ram, but it also has a long waiting list.

Yea seems like the jquery animations are causing some slow downs (try "jQuery.fx.off = true" in the console) Have you tried using bla(); function bla() { try { // ... } finally { setTimeout(bla, 25); } } instead of setInterval? Canvas would probably speed things up too

although, there's a huge shortage of computer programmers over here haha.