Snrrrub

You many have already seen L.C.'s new post but I just wanted to re-iterate: we have set up auto.subdir.{net,org} to collect data from the other directory servers and from each other. That means you're going to get the largest set of zones in your zone list by using auto.subdir. The recommended use is the following: For Continuum Users: Your "Directory Server Address List" should be: auto.subdir.net auto.subdir.org For Subgame Zone Owners (server.ini): [Directory] IP=auto.subdir.net, auto.subdir.org, For ASSS Zone Owners (global.conf): [Directory] Server1 = auto.subdir.net Server2 = auto.subdir.org Server3 = -Snrrrub

This is not a bug, it is intended behaviour. If you were banned or /*killed you really don't want to exacerbate the situation by attempting more logins. This is not an IRC client. I am aware of this issue - it happens when there's enough packetloss that the server has to disconnect you but the disconnect packets don't make it to the client. As it stands, the above issue is the only known bug and will be fixed in subsequent releases. -Snrrrub

Having spoken with L.C., it seems that there's some poor interaction between some application(s) installed on his machine and GTK+. If anyone else is finding Starlight unstable, please let me know so that we can find out which application is causing the instability. If you happen to be running NOD32 and have no issues running Starlight, do let me know so that we can eliminate that possibility. -Snrrrub

Starlight 1.2 is now available for download on my site: Starlight 1.2 2008-07-26 Release 1.2 - fixed bug where application would become unresponsive if the internet connection was broken - added chat logging (saved to: data/logs/session.log) - added a notify list: when a message containing one of the notify strings is received, the icon changes color and the application flashes in the taskbar - the zone selection is now maintained after receiving updates from the directory server - added a dialog box to display Continuum-style custom login errors - added ?ignore command - use ?ignore add <name> and ?ignore remove <name> to add and remove players from the ignore list - icon changes color in taskbar and system tray when a private message is received and the window is not focused - expands %selfname, %tickname, and %squad - added option to not display timestamps - added enter/leave messages - added player kill messages - displays player's squad in player list and allows sorting by name or squad - added registration form for new users - the lack of registration form prevented the creation of new accounts on the SSC biller in previous versions (thanks to CRe> for pointing this out) - fixed CRe>'s email address in About dialog - upgrades to the underlying control protocol (much more efficient - especially on upgraded ASSS servers) -Snrrrub

I've bought the subdir.org domain and I've set up all of the DNS records as well. You can use dirX.subdir.org in addition to the .net version - they're equivalent. I've mirrored part of the site using wget but there are some issues with wget not parsing CSS files for image references. Let's figure out a good way to mirror - can you do rsync? -Snrrrub

I forgot to mention, I'm running a home-grown directory server so if there's any information you'd like me to publish from my server (e.g. uptime), let me know and we'll figure out the details on how you can obtain that information. -Snrrrub

Yes, there are two: "S" and "Z". The behaviour is do!@#$%^&*ented on my Continuum Encryption page. Actually, "S" only generates scrty which I haven't do!@#$%^&*ented on my site yet; I'll add that information soon. Enjoy! -Snrrrub

I would love to help out in any way possible. That's precisely why I set up yet another directory server - because I feel it poses the greatest risk and that risk can be managed with very little effort. Redundancy is key when it comes to the directory servers. I don't recommend *against* using subdir. In fact, I think it's fantastic that we have an easy-to-remember website to refer to. I'm just cautioning people against using subdir (or any other single domain) exclusively. Use it, by all means - but make sure you have at least 2 other domains too. Again, I'm not saying that the site will go down - but if it does, at least we're prepared and it costs nothing. I feel that it's important that everyone has a clear idea of how they can prevent potential failures. It's a very "Smokey Bear" approach but I think it's effective. L.C., if you've got any suggestions on how to improve the system, let me know and I'll do my best to make it happen. Again, good work on the website and DNS records. :-) -Snrrrub

Continuum does not have any command line arguments that could be useful to users. -Snrrrub

CNAME records are certainly the right approach here but they don't solve the single-point-of-failure issue I mentioned. Using a dirX.ssdir.net is fine as long as there are at least two other (different) non-ssdir servers in your list. Suppose the ssdir.net DNS server goes down, the domain doesn't get renewed, or the ownership of the domain gets transferred. If, as a zone owner, you only publish to ssdir, you're not going to be listed on any directory server anymore (and someone else could come in and steal your zone's name). As a player, you won't get any zone updates. At that point, each player/zone owner who is only referring to subdir will have to add other directory servers. We might as well avoid the problem now by not relying on a single DNS source for directory information. -Snrrrub

It's great to see a website that lists the directory servers and their status. However, using the dir#.subdir.net aliases exclusively defeats the purpose of having multiple directory servers: there's now a single-point-of-failure on the DNS of subdir.net. I think it's also important to mention that the IP address *must not* be used directly by zones/players. While it's good to list that information about the host, if their IP address changes and someone happens to be using it directly, there's no transparent way to recover. Having said that, I'm glad to see some useful services coming up - they'll help maintain a reliable and fault-tolerant network and relieve users from dealing with implementation details. Good work, LC.

I don't think it's safe to assume that every client will render text in the same way. More generally, the issue boils down to the server knowing the client's capabilities and falling back to a safe default in case the client does not support an extension. Expecting a client to send an identifier (e.g. ?starlight) on login is a good idea but has several drawbacks. 1) If a server does not need to distinguish between clients, there is no point in sending an extra packet (e.g. subgame, ASSS with no special modules like 'fuschia', etc.). 2) The client version isn't sent so it's hard to determine what the client is capable of. 3) Even if the version is sent in that chat message, it now becomes the server's responsibility to map a (client, version) pair to a capability set. If, for example, Starlight supports extended colors in version 1 but not in version 2 (maybe there was an application rewrite and extended colors are not supported yet), the server will have to encode that knowledge. Every time a new client is deployed, the server modules will have to be upgraded. It is unreasonable to expect such tight coupling between clients and servers given that there is so much independent development in this game. 4) If the capabilities of a client change at runtime, there is no way to notify the server because the capabilities are hard coded in the server based on client type and version. 5) The user can manually type the command (or every client has to filter out the identifier commands for every other client - e.g. Continuum, Discretion, subchat, etc. all have to prevent ?starlight from being sent). We don't want the user to be able to explicitly specify extensions because it could put the client into an inconsistent state, potentially causing poor interactions between the client and server. Instead, I propose the following protocol extensions: Direction: Server to Client Packet Name: Query Client Version Packet: 0x80 Direction: Client to Server Packet Name: Client Version Packet: 0x80 client: 0 - Reserved 1 - Starlight clientVersion: an application-specific version number. This number must increase with every public client release. displayName: a string that can be used by the server to display the client name. Example: "Starlight 1.0" Direction: Server to Client Packet Name: Query Client Capabilities Packet: 0x81 Direction: Client to Server Packet Name: Client Capabilities Packet: 0x81 [capFlags2 (1) [capFlags3 (1) ... ]] capFlags1: bit 0 - Extended Continuum Chat Types bit 1..7 - must be zero Note: this is a variable-length packet with a maximum of 256 capFlags bytes. The server must accept all packets smaller than 258 bytes and will interpret only the flags it understands. The following rules determine when the above packets can be sent: 1) The server may send "Query Client Version" or "Query Client Capabilities" at any time after a connection is established (i.e. after 0x00 0x02 packet) 2) The client must send "Client Version" only in response to a "Query Client Version" packet. 3) The client may only send "Client Capabilities" after receiving at least one "Query Client Capabilities" packet. 4) The client may send "Client Capabilities" at any time after receiving "Query Client Capabilities". If the server does not receive a single reply to "Query Client Capabilities", it should assume no capabilities. If the server receives at least one reply but no subsequent replies, it should assume the capabilities of the last reply. I should also address some practical issues in adopting protocol extensions. Since these packets are not part of the standard protocol, we should strive for interoperability. To make sure that developers don't use the same bits or identifiers for different purposes, I propose the following: 1) All new protocol extensions and changes to existing extensions must be specified as above and must go through a review process. 2) The client id (in the "Client Version" packet) must be !@#$%^&*igned serially (i.e. you cannot choose your id, you just get the next available one) and does not need to go through a review process. A request is made for a new client id with an application name and description and the next available id is !@#$%^&*igned. To make the peer review process easier, I have set up a Google Group for developers. It is open to everyone, serves as as a point of reference for developers, and publicly do!@#$%^&*ents the peer reviews. The group is called SubSpace Development. As always, I appreciate any feedback. -Snrrrub

Thanks for the suggestions! I like the first idea and I'll make sure that is the case in future releases. The color codes pose a slightly larger issue. Since Starlight is a native client, it has a different interface than the game interface. The colors that you've listed won't be exactly the same because they don't work quite as well on a light background. Moreover, the chat types don't seem to have any comprehensible mapping to color. Frankly, adding these color types opens up a can of worms (for all clients) and I think it needs more thought put into it. I'll think about how we can make this happen (since those colors *are* useful) and add my thoughts here for some discussion until we reach consensus. -Snrrrub

It should be retaining the settings you've stored. There might have been some issue in saving the file or maybe the zone's IP/port had changed. I know that there's a critical bug where the application goes unresponsive when the network stack returns a non-standard error which is the same problem that Lynx mentioned in the post above. If you have anything other than "network thread aborting" in your error.log file (in the Starlight directory), I'd appreciate it if you could post that here. Thanks! Snrrrub

L.C., can you post the entire error message? Lynx, thanks for reporting this problem. This looks related to Purge's antivirus issue - when the server unexpectedly becomes unavailable (or the network is down on your machine), the network thread in Starlight aborts, causing the interface to become unresponsive. Were you able to reproduce the bug with /*kill? I will fix this issue in the next release. -Snrrrub

ThunderJam: which GTK+ installer did you use? I've heard that there are other GTK+ redistributables for Windows which are broken in the way that you describe. Also, do you have other GTK+ applications installed on your machine (e.g. Gimp, XChat)? There seems to be a version mismatch between GTK+ and Glib DLLs on your machine. Purge, it's not recommended that anyone download DLLs individually since GTK+ consists of many DLLs, some of which are tightly versioned. Everything that Starlight depends on is included in the ZIP file. Having said that, the site is pretty useful if a single DLL is missing which is often the case with certain applications. The next release will likely be a single executable that installs GTK+ if it is not already installed - clearly the current deployment method isn't sufficient. -Snrrrub

Well, the two points you mentioned form the core of my argument. Frankly, I'm testing the waters to see whether making the Continuum encryption more accessible has a net positive effect on the game. If so, I'll be more comfortable with alternate distribution forms (and I assume SSC and PriitK would be too). On the other hand, if things get out of control, at least I have a way of undoing the damage I cause. The bottom line is that I really don't want to be the one to kill this game. Anyway, I have a bunch of other points that I wanted to mention w.r.t. your comments in the other thread but I'm heading off to Mexico in < 8 hours so it will have to wait until I return. I'll email you an amazingly simple way someone can cheat (and see what s/he is doing) when I return. I'll also describe publicly a way that we can deter such behaviour (although I admit it won't be "secure" in any cryptographic sense and might not be entirely practical given our current developer-base). -Snrrrub

I released Starlight 1.1 today - it's available on my site: Starlight 1.1 2008-06-06 Release 1.1 - new Windows installer that correctly sets up shortcuts and icons - changed application icon (thanks to CRe> for the artwork) - window flashes in taskbar when not focused and a private message received (previously only flashed when minimized) - added configuration item to change background color of chat and input areas - input text color now always matches public text color - chat area auto-scrolls when the scrollbar is completely scrolled - added :: functionality to send message to last user who sent a private message - added a "minimize to tray" feature -Snrrrub

Bak, in this part: if (distSq > maxDistSq) { s->loc.x = xpos * 10000; s->loc.y = ypos * 10000; } you don't want to use xpos and ypos - instead, you want: if (distSq > maxDistSq) { s->loc.x = newx; s->loc.y = newy; } I had released virtually identical code in 2002: http://daccel.cvs.sourceforge.net/daccel/S...amp;view=markup You should consider looking at the code I have already made available - it might prove useful. -Snrrrub

Cerium, you have raised some valid concerns regarding the Oracle service so let me address them one-by-one: Prior to the Oracle, no application other than Continuum could connect to a server unless the user logging in was granted special privileges. Despite this restriction, many useful applications have been developed. As it stands, you are still free to develop applications that do not make use of the Oracle. If the Oracle is unavailable for any reason, your application can fall back to the SubSpace protocol and continue operation as before. Alternatively, if you feel that building a fault-tolerant application is not worthwhile, you can rely solely on the SubSpace protocol. The choice is entirely yours. You are no worse off with the Oracle than you were without it. As per Kirk's suggestion, I will add a ping packet to help you determine the liveness of the Oracle so that your application can decide which protocol to use before attempting a connection. The stability of your program should not be affected in any way. If it's a transient problem and the Oracle cannot respond to a key expansion request, your application should re-initiate the connection request and ask for a new key. If there's a transient problem while you're connected, your application can try asking for a checksum response again. If the problem is persistent, you'll know that by pinging and getting an extremely delayed response. Keep in mind that after the login sequence, SubSpace is quite tolerant of transient delays. As for the protocol, I will retain backwards compatibility and extend it when necessary. As for the ip/port: you should be using DNS to resolve the IP address and the port will stay constant. If you're still nervous about this, I can register the Oracle as a subgame server in the public directory servers. I'm more than willing to make this addition if it's in high demand. The security checksums happen every 2 minutes. Even if 2000 users were connected simultaneously 24x7 (which is approx. 2 times the current daily peak), that's a mere 17 requests per second to the Oracle. At 12 bytes per request/response pair, we're dealing with 204 bytes per second. Even with 20,000 concurrent users, we're still only hitting 2KB/s. Even if all 2000 requested at the same time, that's still 32KB in one second. I think a DoS from too many players is out of the question. Here's why the Oracle is better than releasing the code: 1) The Oracle works with every language. If you've seen the Ctm .36 key expansion routine on my site, that's about 14,000 lines of !@#$%^&*embly converted to C. Ctm .40 is way worse. If I release the C, how is someone going to convert it to Java, or C#, or Perl, or Python or any other language out there? In some cases it may not even be possible since language features may prevent correct operation (e.g. lack of unsigned types, no unions, no pointers, potentially unsafe type casts, etc.) of the routines. 2) The Oracle works with every platform. There are things going on in the latest key expansion routines (e.g. Windows SEH) that make it virtually impossible to run on other platforms and architectures. With the code, you wouldn't be able to target, say, Mac OS X or mobile devices but you can with the Oracle. 3) The Oracle is resilient to key expansion / checksum changes. If the EXE checksum routine changes or the key expansion routine changes and you're linking against the code, you're going to have to re-deploy the application. Alternatively, I could update the Oracle and all applications would continue to work as if nothing happened. As Kirk and others have pointed out, releasing the code would make it trivial to write a cheat. Once it's out in the open, there's no taking it back. The only option we would have is to wait for PriitK to change the key expansion and checksum routines again. We would depend on him to "save us", which is what you're complaining about in the first place. I'm not interested in damaging the game in any way. I try to make as much information public as I can that would not result in cheats or hacks and my website is a testament to those values. I'm more than happy to have a mature debate, Cerium, but you will have a hard time winning me over with flames. -Snrrrub

Purge, looks like there's some sort of Winsock error. I'd like to work with you, if possible, to resolve the issue. Please email me your contact details and some times that work for you so we can tackle this one-on-one. ThunderJam, thanks for the suggestions. Some of the missing features were intentional due to time pressure but rest !@#$%^&*ured, I will be addressing them in future releases.

Maybe a screenshot would give some hints - mind putting one up here? Also, can you check your install directory for "error.log" - if there's anything in there, please post that too. Thanks, Snrrrub

Purge, can you explain what happens when it goes unresponsive? Can you tell me the steps to reproduce the bug (and the platform you're trying it on)? X`terrania, what did you mean by "doesn't really move at all"? The chat window doesn't scroll or some other issue? On a related note, I've just put a Linux version up on my site. It's for i686 and requires the GTK+ 2 libraries but I've only tried deploying it on a Ubuntu 8.04 machine. I would really appreciate it if those running Linux could try it and tell me if they were successful or not in running Starlight with their distribution. -Snrrrub

I've just released Starlight, a chat client for Continuum, on my website. It works with both ASSS and Subgame and doesn't need special privileges - you can use this without VIP. Download it here: Starlight 1.0 Download. -Snrrrub

Open up server.ini and in the '[billing]' section, change the IP from '127.0.0.1' to 'localhost' and restart subgame. -Snrrrub