Arry

I'll second that. Just want to bring a little positive encouragement to this panicfest.

'bout time I'm threw my three cents in here (yes, I have three, where many of you mortals only have two cents ) First off.... let's break down the ammo system into game atoms. (aka game elements). The ammo system is actually three new game elements from a player's perspective. 1) Firstly game atom is resource management (i.e. making sure you don't run out). And by multiplayer extension becomes a game of sucker. As in... whoever runs out of ammo in the middle of a dogfight becomes the sucker. Mastering this game atom is as simple as remembering to press a macro every life and mastering the reloading game atom (we'll talk about that in a minute). Neither of these are particularly challenging, and therefore it's only rewarding (read fun) when someone else runs out and you catch the 'sucker' with their proverbial pants down. 2) Second game atom added is the reloading challenge. That is, getting to a reloading zone without losing (much) of your bounty. This game atom is simply a mastery of completing a set of manuevers (button pressing) in the least amount of time possible. And frankly, I think the only people complaining about this are the people who fail at it miserably. This game atom is immediately rewarding to those who master it (ie they get to keep btying and making tons of cash). 3) Third game atom is an extension of the ship building system. You're trying to make the best ship you can and this now includes exploring the ammo usage of guns, both in money cost and how often you refill. (How well you've mastered game atom #2 above will determine how important time between refills will be). In geek terms this is exploring possibility spaces searching for local maxima. This is the fundamental game atom of any RPG and I find this extension to be a good addition. There may be some other hidden game atoms here like the challenge of building a macro or the challenge of managing the "pants down" situation (ie, effectively running away or beating your opponent even when your ammo does run out), but the three I mentioned were the main ones. I think the key things here that developers need to be aware of is that A- they forcing players to play game atoms 1 and 2 and B- players will quickly master game atoms 1 and even 2, and after a while, they could get bored of being forced to play those games (er... game atoms). They will want to byp!@#$%^&* these now "boring" games in order to play the ones that are still challenging. (byp!@#$%^&*ing could be anything from relegating it to a simple keystroke with a macro, to an autobuyer/autoreloader, to higher capacity which means forcing the player to play that game atom less) The third game atom added is not being forced on players so it's not prone to the same boredom/drudgery factor (ie a player can maximize their possibility spaces any time they want to as long as they have money)

Cut and paste of what cerium said he added: Cerium> ok, changes I've made Cerium> Added support for clickable URLs, and modified the behavior of the scrollbar to not auto-scroll when it's not at the bottom. Cerium> Added support for ?ignore as well as a list of ignored players in chatnut.conf which follows the same format as the private messages stuff. Cerium> Also: Brain, I hate your message chaining system. It's clumsy as !@#$%^&*. Cerium> Fixed a bug that prevented zones.txt from being loaded. Cerium> Improved how zones.txt is found and loaded.

Yeah, if I was just trying to throttle I could use something like that. But I'm also trying to prioritize the Queued messages (spammers last). I'm going to make one that just throttles too, but I think it's unfair that one person could use several multiline output messages and everyone else has to wait till the Queue is cleared. Rather, I want people who haven't recieved many private messages (IE the ones who are sending commands with multiline responses) to be the able to skip ahead of people who are bogging up the queue with their many messages.

I'm making progress on this, but I think I'm going to run into a problem using PriorityQueue.... when a player has multiple messages in the queue, those messages need to be maintained in the order they were originally trying to be sent. I'm thinking that PriorityQueue will not garuntee order among equal items (in this case that's messages queued to the same player), and there's nothing internal to the message string that tells me the order it arrived. I'm going to have to verify this, but I think I'm going to need to compensate for this somehow.

Wouldn't I have to have a separate thread that would continually check the queue to see if it had messages and if it was safe to send then send any messages that are waiting?

Imma repost this here because it's applicable: I don't like the terms "Subspace is dying" or "Saving SubSpace". It seems to induce some sort of panic and really puts a negative spin on things. Nobody wants to be on a sinking ship, and if you start shouting that the ship is sinking it's only going to make more people jump off. Well, I for one am not jumping ship because the population in certain zones seems to be dwindling. I've been to play other games but I keep coming back to subspace. It's a relatively tight nit group of players who also have complete control of the developement reins. It's a highly adaptable 2d environment, and it's totally free. Sure, there's a lot of 2d games out there people can play for free, but I don't think you could ever replace the intagibles we have in subspace. Subspace is one of the only online games where you hear people come in and say "Wow I used to love this game six years ago" and then start playing it again AND ENJOYING IT. Subspace is not dying and we're not saving subspace, we're evolving it.

I have a few ideas but first let me say that I don't like the term "Saving SubSpace". It seems to induce some sort of panic and really puts a negative spin on things. Nobody wants to be on a sinking ship, and if you start shouting that the ship is sinking it's only going to make more people jump off. Well, I for one am not jumping ship because the population in certain zones seems to be dwindling. I've been to play other games but I keep coming back to subspace. It's a relatively tight nit group of players who also have complete control of the developement reins. It's a highly adaptable 2d environment, and it's totally free. Sure, there's a lot of 2d games out there people can play for free, but I don't think you could ever replace the intagibles we have in subspace. Subspace is one of the only online games where you hear people come in and say "Wow I used to love this game six years ago" and then start playing it again AND ENJOYING IT. Subspace is not dying and we're not saving subspace, we're evolving it.

Wouldn't you just be able to let the clients watching the old game do the physics on the ball? Isn't that how recorded weapons fire works too?

Well, I'm not worried about slowing down the bot as much as I'm worried about fitting in under the server's spam limitations (before getting silenced). The logjam is definitely going to be how much the server will let me send, not how fast my bot can process incoming requests

Due to the amount of multiline output my new bot is expected to generate, I want to throttle it's output, but I also want to build a responsible queuing system that allows those who have cause the least spam in the past x seconds priority in the queue over the people who have caused the bot to spam a lot. For example, let's say there's an item listing command that fits on 5 lines. If someone is checking their items multiple times in succession, they'll quickly be the cause of a backlog of messages. Instead of cutting that person off, I just want to give any new messages they generate a low priority so that they aren't slowing the bot down for others. I'm thinking that I'm going to need a collection to hold the queue of messages and another collection to hold the current priority order of players. When an output message is generated, responsibility is !@#$%^&*igned (most likely to the same person who's it's sending the private message to). It then checks to see if that player is !@#$%^&*igned a lower than normal priority and then loads the message into the queue accordingly. Does this sound like the best way to go about doing it or would their be a simpler approach that would achieve the same goal? And what types of java collections would be the best fit here? (there's so many to choose from)

Lol.... I seem to have left critical parts of speech out of my post. Glad you were able to make sense out of it. LOL @ probably because Thanks! That's what I get for rethinking what I was going to say and then not proof reading before clicking send

Whoa, nice catch on the syntax error. That must have fell out during a recent edit (I was moving the blocks of code around with cut and paste). Doesn't explain former problems though cause it just happened recently. I'm still surprised the compiler didn't catch it... probably because Thanks! The reason I built is because eclipse runs things out of a higher level dir than the bin or src files. I wanted to ouput the full path to the console so that I knew exactly where it was looking for my cfg file.

?forceneut good, ?letdrop bad I think a command like ?restrictdrop would be better than ?letdrop, ?restrictdrop would change the behavior for ANY flag carrier (on your team) to neut at timer end instead of drop. It would be a majority command. That way, unless ?restrictdrop is used, the game plays normally, dropping on timer end. That way you keep default functionality the same and only make players who want to use it learn it.

Topic says it all. Bot is based on jcnlib v 1.11 Version History: v1.11 Fixed logic bug in autoconnect code v1.10 Added some new features: Auto-reconnect Loading bot settings from a file !die command to kill the bot. v1.00 Released initial version

Due to the neglect by teh major zones of their scrabble bots/arenas I made a new bot and host it 24/7 in its own zone. It has the latest word list, blank tiles, customizable timer, etc. Join the chat ?scrabble in SSC to find someone to play with. That's all.

Yeah, capturing video data into some sort of other format (like server data from a gamerecord module) is just a waste of time cause you then have to convert it BACK into video data. You simply need software that takes a window as video source and broadcasts it as a virtual webcam. That software *should* exist. It may even be a feature of popular webcam software. Check with people who stream online. They undoubtably want to stream their games from time to time. Find out what software they use.

hey, I can't make priitk be politically correct in his award... take that up with him

Priitk hands out lots of cert's these days.... check out this award I got.... http://img510.imageshack.us/img510/7787/hungriestplayerawardln5.jpg

Agreed. Agreeing Agreed I concur

http://www.speedtest.net/result/226118261.png @ Work http://www.speedtest.net/result/226419698.png @ Home

Lol here's what I was thinking as soon as I read "Don't buy anything" http://danwho.net/mp/index.php?id=snl_dontbuystuff

Trying to troubleshoot why occasionally, my bot will not be in the zone, but still think its connected. I'm wondering if I need to handle the close events instead of just watching disconnects? Or maybe I need to add some code to process lag outs or lag coma?

Myself and others have noticed that when using chatnut, it locks up. In my experience, it locks up at seemingly random times. I could be on it for 2 seconds, or 2 hours hours and it will randomly lock up. Many times it happens within the first 5 minutes.