JoWie

Becareful with floats in such a model. In a lot of cases, floating point math is not consistent across different systems. It might not even be consistent on your own system (like when your instructions are *suddenly* optimized by using CPU registers which may have more bits, ex 80bit float point in register, 64 bit floating point in ram). This can usually be fixed by a keyword (like "strictfp" in java, and "volatile" partly helps in C), compiler flag, or by not using floats for the networking/physics stuff. In Aphelion we use use integers (no temporary casts to float) for the networked server authoritative physics and floats for the graphics/view.

The issue is not that some people know how to cheat, the issue is someone releasing a tool so that anyone can do it without any knowledge. This is the same issue that DRM faces, and also why it keeps failing.

I have not bothered looking at the binaries of continuum, so I am just reposting: Someone suggested part of the reason the source was not released was because of legal reasons? It was even suggested there is not a whole lot of source to release, that continuum is mostly a bunch of assembly hacking upon the old subspace client.

done

short term todo: * finish test cases (and debug) the current physics/simulation stuff. (currently only movement & warping) * convert rest of aphelion code to use the new physics engine * networking for the above (server,multiple players,yay) * weapons http://i559.photobucket.com/albums/ss31/XDreamersMS/Continuum/SubspaceTitleSpin.gif

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.