Ceiu

Happy new year to you as well, my asian "friend".

That's exactly what class we were referring to.

I'm surprised no one questioned the idea of a 13 year old having a 13 year old child.

Using another thread would allow you to guarantee that the messages will go out eventually. If you don't use another thread, you run the risk of leaving messages in the queue until the send method is called again.

What you could do is use a PriorityQueue object with a custom Comparator (or whatever it's called). Basically, the queue will sort items based on where the Comparator says they should go. Then, just make the Comparator keep track of how many messages the users are receiving. As a user receives more messages, their priority goes down. From there, you'd make an object that implements the MessageHandler interface and insert it to the outbound chain of the CNConnection you want to throttle. What it would have to do is keep track of how many outbound messages have gone out, then queue messages as it reaches it's limit. Read the details on the MessageHandler interface and the postMessage and sendMessage functions in CNConnection for details on how to piece it all together.

I see. You may want to give JCreator a try. It's a much nicer IDE in my opinion, it's significantly faster than eclipse and it's just as free. It doesn't have a billion and one plugins though, but I'm guessing you aren't using any anyway.

Few things I noticed: - Java will automatically use the current directory if you don't give it an absolute path to a file. The only time you need to do what you're doing is if the user is going to be running it from random directories (via shortcuts, or something), where you need to explicitly specify the install path. - You've missed a curly bracket in a odd spot. I say odd because in most cases you'll get a compiler error, but in this very rare case it actually compiles (and probably works too). Unfortunately, it won't give you the result you want (See below for details). 1 //Main Code goes here 2 while(!objConnection.isClosed()){ 3 if(objConnection.connect("67.19.122.82", 5000)) 4 { 5 objConnection.login(botName, botP!@#$%^&*); 6 while(objConnection.isConnected()) 7 //While the bot's connected, this thread just sleeps 8 //All the work is done in the CNConnection object 9 Thread.sleep(5000); 10 } 11 if(!objConnection.isClosed()){ 12 System.out.println("Disconnected. Waiting 30 seconds to reconnect."); 13 Thread.sleep(30000); 14 System.out.println("Attempting to reconnect..."); 15 } 16 else 17 { 18 if(!objConnection.isClosed()){ 19 System.out.println("Unable to connect. Waiting 60 seconds to avoid biller login ban."); 20 Thread.sleep(60000); 21 } 22 } 23 } Judging from how it's indented, it appears that line 6 is missing it's left bracket after the while-statement. This is causing the if-statement on line 3 to end at line 10 rather than line 22. The else-statement on line 16 becomes part of the if-statement on line 11 because of this as well (making it useless, as both cases are the same). If I'm right about your intentions, you're also missing the right curly bracket before the else-statement on line 16. This may explain why you were having some issues with the reconnection code. - If a connection to the server can't be made, you won't be making any login attempts which means the biller won't be banning you. Though, it's good that you're conscious of it. None of these are real major (save for the syntax issue), but are things you should look at. Nice work, nevertheless.

Ok, since you two are !@#$%^&*bent on the whole run-winning thing.... 1) Getting someone to camp tw to stop a run-winner isn't an easy task. There's even more difficulty in getting someone who has antimatter or space mines. Further, if you're the only one chasing them, a good run-winner will make you follow them through a safe zone to make you null your mines before using it. 2) ID is slow when compared to TW. Also, it uses the new system as well, so your argument there is void. 3) Run-winning is something that's not exactly supported by those in charge; they've been trying to prevent it and/or fix it for some time. If you're lobbying against something, saying it "makes run-winning harder" is definitely not a good argument. Also, you suck at spaceships.

I can't help but point out that his only point is that the new tw makes run-winning harder. lulz?

Disconnect is fired when a connection simply disconnects from the server (for any reason). Close is fired when the connection not only disconnects but also closes, rendering it unusable for further communication. Regarding the other issue, note that CNConnection.isConnected() only returns the state of the connection; it does not check if it's actually in the zone or not.

The problem is you're still relying on code running on the user's machine to be "telling the truth" -- it'll never be secure. The only thing we can really do is make breaking the security so tedious that no one would bother doing it (at which point we run the risk of writing so much spaghetti code that it's a pain in the !@#$%^&* to manage). Meh. I say we just do a fair amount of server-level checks and physics.

I fully expect her to cause the first ss-related death. Give it up for negligence.

For the same reason she got pregnant: She's a drama !@#$%^&*. It's too bad myspace is already full of drama... we could be rid ourselves of these types. I hope she accidentally drinks some bleach in the next 8 months and ends that abomination to the gene pool before it's too late.

...says the fat kid who's never once posted his own photo. If you don't like me because I'm an !@#$%^&*, that's fine -- no one will argue that one. But to say imply I look ugly or nerdy is just foolish.

This idea is probably the best, save for one problem: If the user no longer has access to the email (dead domains, lost passwords, etc). Typically, this is the only reason to change the email in the first place and by the time people realize they need to change their email, it's already too late. Why not simply have a command which sets a flag for the name to have it resend the registration info (?resetemail, perhaps)? This way you can check the user's new IP, Mac ID and IDData for a match. If the info matches what we already know about the user, it's probably still them. The only downside I can see would be that you may need to re-register from the same machine for the changes to take effect (depending on how the check is performed).

It's a permissions thing (either that or his drive is full). He just needs to give/get write permissions in the folder.

Considering it's not my house... no.

...the !@#$%^&*? The only thing that even comes close to matching is our hair styles. I'd need to put on another 100 pounds and MAYBE I'd kinda almost half resemble him.

I'm a programmer, not a photographer. Yes. I plan on getting a better one next time I build a new computer.

Since you jerks don't know how to keep a thread on-topic... These are my current living conditions while I wait to move into my room at school... And, for the chickies out there... a much needed updated photo of myself:

No one said you did, sally.

Since this appears to be a botcore written in C#, anyone interested should get in touch with udp -- he's already written this exact thing.

Hrmm... I kind of browsed this thread because of a few people being intentionally ambiguous and a lot of people having the same ideas I had, so if I repeat anything... whatever. Basically, from what I can see, the only thing that's really important to players is their name and the ability to chat with people in other zones. A new biller network isn't going to take over for SSC without either a huge following or being able to maintain those two things. The way I see it you could go about this one of two ways: 1) Create a biller which connects to SSC biller as a zone and relays chat. This would mean you could maintain the chat connection, but names would need to be re-registered. The problems here are two fold: (a) some people would lose their names due to the !@#$%^&* baggary of various players; and ( with a new set of names and interconnected chat, you run the issue of name spoofing. (a) can be solved by simply having a policy in place which allows billing ops on the new network to give players their SSC names within a certain period of time. ( can be solved by prefixing the billing network to incoming and outgoing names. For instance: Players on SSC would see chat messages like "1:(SSx) Cerium> message" from players on external billers, but would still see unmodified messages from other players on SSC. Likewise, players on SSx would see "1:(SSC) Cerium> message" for players on SSC, but would see the standard message for other players on SSx. 2) Create a biller which connects to SSC and attempts to validate names and create names based entirely on the SSC db. This would mean you maintain the chat connection and name permanence. The problem here is you're basically mirroring SSC for the sole purpose of allowing others to control who has access to it (and maybe additional features). I suppose after a while this biller could "break away" from SSC and go solo -- if the biller had enough players/zones, it just might work. In fact, this is likely the only way a new biller is going to succeed against SSC. If there's some security or functionality issue I'm missing, by all means fill me in -- I don't know the biller protocol as well as I'd like to, so... yeah.

Can someone explain to me the point of __town? I've seen three of them now and have yet to understand the appeal or even see a steady population in the arena.

Take note kiddies: Hack one of those zones to get every subspace name EVAR!!!!!!!!!!11!! HACK TEH PLANET!!!!!!!!!!