User talk:Chase-san

Just to confirmed, you come from USA, right? But why your rumble flag is Japan? » Nat | Talk » 10:51, 12 April 2009 (UTC)

If you read the country flags page on the old wiki, you'll find

I be changing of my mind on my flag, and at the same time, uploaded
a new GIF. I would perfer the Japanese flag, as they need someone defending
them in the top 100. The old one looks like a badly squished bright red
dot, where as the japanese one is a little darker. So this  flag for the
'chase' package please. --Chase-san

So Chase-san is going under the japanese flag just because he wants to essentially. --Rednaxela 14:50, 12 April 2009 (UTC)

• Thanks, now I understand. » Nat | Talk » 14:53, 12 April 2009 (UTC)
  • Other people have done this aswell in robocode. In the end the flags are jsut there for looks, you could ahve a fake flag if you wanted (I suppose). --Chase 23:21, 22 April 2009 (UTC)

---

Hey Chase, where can I find your EvilDrone? I'd like to see it, not in action, but the code. And can you tell me which version of robocode that you are allowed to do that thing? » Nat | Talk » 05:13, 23 April 2009 (UTC)

Well that would be a bit hard, you would need a very old version of robocode to even view it. I will search around but I think the code is long since gone. Basically all it did was something like robocode.battle.bullets.add(new robocode.bulletpeer()), assigned it to itself and placed it projected off enemy location (gained from reading the enemy location from the internal class) at an PI/50 intervals (ergo PI*2/100). and set the velocity to fly towards the enemy. If you wanna see something like ti disable the security manager and use the new method of peer management that Robocode uses. You should be able to do something like that with that system. Just don't try making your robot teleport, robocode didn't like it then I doubt it likes it now. --Chase 06:23, 23 April 2009 (UTC)

ACtually I found some really old versions of two of my hackbots, they are on my server. www.csdgn.org/robo This EvilDrone isn't the really amazing one I describe, but it still always wins. --Chase 06:28, 23 April 2009 (UTC)

Thanks! Ahhh. It's 1.2.1 Beta (from your JAR) which is un-downloadable :-( » Nat | Talk » 07:37, 23 April 2009 (UTC)

Redirects

It's pretty funny to watch the recent changes page while we make all these redirects. --AaronR 20:19, 12 November 2007 (UTC)

Hehe, yah, it was, it was like a Redirect war. --Chase-san 20:21, 12 November 2007 (UTC)

Okay, maybe not

Maybe I canot jump right back into robocode again. I have been working on a great deal of 3D stuff lately I am not sure if I can think in 2D anymore. I actually created a linear targeting gun that works in 3 Dimensions, and the like. But only as experiments. I will look into getting back into things now that class is lettting out for the summer. But I know I probably was not the nicest person back then, but I hope I will be welcomed back if that day comes. --Chase 09:54, 13 May 2009 (UTC)

You will be welcomed if you come back. Robocode community is very quiet lately. » Nat | Talk » 11:21, 13 May 2009 (UTC)

I didn't know you then, so I have no reason to not welcome you ;-). --zyx 13:08, 13 May 2009 (UTC)

When were you not nice? Welcome back. And if two dimensions isn't enough for you, you can use as many as you want if you go back to the DC and Kd-Tree work. =) --Voidious 14:27, 13 May 2009 (UTC)

I did have a Bucket KD-Tree with a working range search to speed up my Pytko (which I never installed). I think I was working to get a honest working tree search in, but the bucket method of the tree pretty much made up for almost any added precision that would otherwise be gained by searching back along the path. --Chase-san

Robofight

Well, Robocode did implement a lot of thing, why don't you build it on top of Robocode? Or as a plug-in for Robocode? You know, there is an incomplete Battleview3D plug-in in Robocode's SCM trunk, you might want to examine it. Your physics looks good, btw. » Nat | Talk » 14:39, 18 July 2009 (UTC)

Well this is a bit beyond the scope of what Robocode can really hope to do I think.

I have been writing mostly C/C++ since July, and I have done some opengl. If I can use a OpenGL wrapper in java I might be able to use that for this. However despite this still somewhat being on my eventual 'todo' list I have other more pressing things right now I need to work on. (Like College work! :P)

But to me, one of the really neat thing about this is the possibility for custom models. Of course there would be option to scale them to a certain 'area' if to large and would probably be in the format of an average obj file. I have worked with those before, they are very simple.

Which would make the battles very interesting to watch. Initially it will probably only use wireframe models, to avoid having to texture map. (and it looks cool)

But until I actually do something this is all just speculation.

--Chase 10:02, 6 November 2009 (UTC)

Okay, since I have done opengl before I decided to try out JOGL, and amazingly its almost identical to the honest to go C opengl in the way of commands. So that makes this easy enough I can make this nice 3D demo for everyone. I didn't do any texture mapping (making a texture takes to long, imho), but the rest of it is there. I have two ships flying orbits around the center. This is just GL trickery right now and not example of actually programmed robots, but I wanted to show I could do it now. Because before I had absolutely no clue on the 3D.

I also would like opinions on the size of the ship to the size of the field there. In retrospect I should of just added an additional unmoving ship in the center so its easier to peek at the model. But if any of you have any 3D modeling programs you can poke the model I have in the zip. Mine is about 20 minutes with some cheap smoothing done on it.

I will add a version of the physics engine here soon, and a basic programming interface for testing some things. But needless to say, debugging graphics on this would look awesome (and maybe also really hard to see).

Download 3D Demo

Uhm, oh the file is a bit big (1.7 mb), because I tried to pack the dynamic libraries for all the relevant systems (Windows, Linux, Mac OS X).

--Chase 15:30, 7 November 2009 (UTC)

You make my head spin with that. But I think Robot only driving on the ground, unless you make an aeroplane robot, which should be really hard to write (and control from the API) --Nat Pavasant 15:49, 7 November 2009 (UTC)

Wow! Cool! I personally think the field should be bigger, especially if the bots are going to be able to move at the speed they do in your simulation. Similar to robocode, I think it should take at least 100 ticks to fly from corner to the other, and half that for bullets to travel from one side to the other. Another thought: since this is in 3D, we need to give the bullets some thickness or they won't be able to intercept. They can't just be modelled by a straight line anymore. --Skilgannon 21:34, 7 November 2009 (UTC)

Well I can completely change their speed, size, and the like. The field currently is 'technically' only 2x2x2 (-1 to 1) in size, and those models are very small, but to the actual robot it could be anything from 2x2x2 to 1000x1000x1000, dynamically resizing the robots as needed. But okay. --Chase 04:41, 8 November 2009 (UTC)

Obviously this has not received my full attention! However I would like to pose a question to all of you.

http://www.csdgn.org/files/images/three_axes.gif

I was wondering what the relative limits on the axis should be. Since the hit box on a ship will be non static, meaning you have a smaller profile when your side is facing then your top, I was considering restricting the ability to turn on the yaw the most and give the roll the most freedom, putting pitch somewhere in between. Considering the majority of your thrust will be along the x axis (forward and back, but with limited thrusting ability along the z and y). I was wondering if this seemed fair (since a high yaw would allow you to have a low hit box and be able to turn quickly when circling your enemy surfer style) --Chase 03:23, 22 April 2010 (UTC)

I think prioritizing limits that way makes sense personally. On second thought though, I wonder if making pitch and yaw the same for symmetry would make sense? One thing to consider is that one could always bank to the side as to allow pitch and yaw to be combined. --Rednaxela 15:21, 23 April 2010 (UTC)

If it is a plane, then I think pitch is easier to do than yaw. For pitch, you just pull the controller. For yaw, well, hard to control I believe =) --Nat Pavasant 15:30, 23 April 2010 (UTC)

Oh, and in other news on this, aside from the few of the local to global coordinate and thrust translations I need to do yet, I can internal code mapping to display code. Roll, yaw, pitch all work. Velocity works, I have to apply the rotation to the thrust still (since thrust is local) and then apply it to the velocity. Once I get the fluid dynamics reapplied, it should be ready for some basic programming in the flight department. --Chase 04:13, 22 April 2010 (UTC)

On that note, I have a core test for you. Basically this bot is a somewhat inefficient 3D version of walls. This is not 3D trickery, this is the actual core doing its job. Physics (if you can call a simple drag physics), rotation, thrust, etc. They all work. It uses a system similar to the current robocode for setting it's turn, or at least the last version of it I looked at. The field it is on is HUGE, 2000x2000x2000, it is bound the the display so that is the reason if it looks like it is going insanely fast and turning on a dime (I will fix this at some point by giving the engine its own thread). Core Test 0 To be honest I am a bit annoyed with myself, since the last time I worked on this I found it hard, now I don't, not really. --Chase 06:55, 22 April 2010 (UTC)

http://www.csdgn.org/files/images/roboflight.png

Alright, now I have something really done. Alright, I rewrote the graphics and engine. Two really simple bots with really simple behavior. Loopy does loops, WallyX is like the previous walls, except he will change which set of walls he flies on randomly when at the midpoint, meaning he will cover all 6 (eventually).

I have detached the engine from the screen rendering, the engine is fixed at 20 fps for the moment, but the display is much higher. I added the ability to rotate the display manually (with momentum) and shift it up and down and even zoom in on it (mouse wheel). The yellow line shows thier direction of movement (since it is not always along thier x axis during turns). Still would like to hear your opinion on the turn radius of the robots. Oh and here is the demo so you can try it yourself, I decided to split the libraries into their own archive (so I don't ahve to upload them again). JOGL Libraries Roboflight Core Test 2

--Chase 21:55, 22 April 2010 (UTC)

As a side note I have in the past already determined a way to do linear non-iterative targeting in 3D. It was done by calculating the point at which the two objects would meet. It looks a little something like this. --Chase 00:45, 23 April 2010 (UTC)

/** Returns a vector that you should aim at, give both objects travel at a constant rate, in a linear direction */
Vector3d Intercept(Vector3d cPos, Vector3d tPos, double cVel, Vector3d tVel) {
	Vector3d rPos = new Vector3d(tPos);
	Vector3d tVel2 = new Vector3d(tVel);
	rPos.sub(tPos);
	double b = rPos.dot(tVel);
	double a = cVel*cVel - tVel.dot(tVel);
	tVel2.scale(b + Math.sqrt(b*b + a * (rPos.dot(rPos))) / a);
	rPos = new Vector3d(tPos);
	rPos.add(tVel2);
	return rPos;
}

Neat. Now I can't help but ponder non-iterative circular targeting in 3d... that gets trickier I'd say... hm --Rednaxela 15:21, 23 April 2010 (UTC)

Cool! If the robot is a plane (thus 'flight'), I believe pitch should be a bit lower (base on source code in code 2 anyway). Your control is a bit interesting -- I wonder how can I thrust from the z axis. If so, I think your should limit the thrust on y and z axis to be s lot lover than the x axis. But the probably on your todos list already. --Nat Pavasant 15:30, 23 April 2010 (UTC)

Yes, actualy, I plan to limit the thrust on the X and Y axis to be at most 0.1 or 0.2, where as the x axis can go all the way to 1.0. Depending on how I decide to do the movement dynamics, the inverse of x might be at most -0.2 or all the way to -1.0. Depending on if I want a game like robocode, where backwards can be the same magnitude as forward. I will also limit the total maximum magnitude of the thrust to 1.0, if over 1.0, so 1.0 on x and 0.2 on Y would give it a total magnitude of sqrt(1.0*1.0 + 0.2*0.2), or a bit over 1, so I would normalize it to 1. Meaning both thrust vectors would be reduced, but if under this, no normalization will occur.

As for the pitch and yaw. I wanted to give pitch a greater turn radius so that robots will expose a greater hitbox to the enemy to make use of this better turning ability, if they are orbiting the enemy in standard robocode fashion. If i was really evil, I would get rid of Yaw altogether. (thus requiring robots to roll and pitch to make a turn) --Chase 17:34, 23 April 2010 (UTC)

For bullet collision, and bullet missile collision, I will probably still use a line, but use a shortest distance between two line segments algorithm to determine if they had collided. Might have to do it in substeps, and only if the two bullets line paths distances are less than a certain amount (to avoid unneeded computationally expensive checks for bullets nowhere near each other). Robot/Missile or Robot/Bullet collision will probably make use of a line and plane intersection algorithm, this would require a check of all 6 surfaces (most likely), since unlike usual robocode, the hit box changes orientation and is of non-square dimensions. --Chase 17:49, 23 April 2010 (UTC)

Wow 2 Years...

Looking at the timestamp of the last bot I released (Pytko), it has been over 2 years since I released anything. I have been doing other things since then, but the robocode fever really did burn itself out I guess... It is no longer "I can stop any time I like!", but "I not sure if I can restart.". The thing is, it has been so long since I have worked on a robot, I would have to cover the basics again... While I consider this a great chance for a fresh beginning in the community, there is little room left for innovation, and I doubt I would be the one to make any such breakthrough (unless I try to make an ART based bot and it works). --Chase 03:37, 3 March 2010 (UTC)

Well, I feel that melee has greater room for innovation than 1v1 still, and that the Team an Twin formats are still relatively unexplored and likely have many breakthroughs to be made still. --Rednaxela 03:55, 3 March 2010 (UTC)

Just two years.... Remember Phoenix took David three years =) --Nat Pavasant 15:13, 3 March 2010 (UTC)

I kind of know the feeling. I started working on Diamond last April after ~16 months of non-Robocoding. You look at 1v1 and you're like, "do I really want to even start climbing this mountain?" =) But I'd barely touched Melee before then, so it was a very refreshing and enjoyable experience to explore new territory. And, of course, eventually the 1v1 bug bit me again, too. Anyway, welcome back and good luck. =) --Voidious 15:35, 3 March 2010 (UTC)

• I am often working on Hubris in the background, but every innovation falls flat. I'm sure I could get much farther playing with movement, but I'm really just not that interested in that aspect. I just keep building the foundation of the robot and changing my statistical gun around. Meh. Then I get irritated and slip back into the shadows for a while. --Martin 16:23, 3 March 2010 (UTC)

You removed orbit and wristwatch. Both those bots have been giving me trouble for years you know. Just because your bots aren't top 10 doesn't mean they aren't contributing to the fun that is robocode. I've spent quite a bit of time trying to time out their movements for maximum effect :) BTW, welcome back! --Miked0801 16:11, 3 March 2010 (UTC)

Hah thanks. Maybe I will try for some melee. 1 on 1 is just really hard. Maybe my Kohonen surfing might work better if I make it Min-Risk and shove it into melee (never know). --Chase 20:16, 3 March 2010 (UTC)

Prototype gives some pretty strong bots a tough time (Diamond among them until just recently). On a semi-related note, you might like to read Gaff/Targeting for some NN-bot inspiration. =) Pris (Gaff's sister) uses NN for both gun and surfing. --Voidious 20:38, 3 March 2010 (UTC)

Well in that case

Prototype had a ton of work put into it, reading over its code now, it makes me wonder what exactly my plan was for it. I however very much enjoyed working on Pytko, so I think I might work on that bot some more. Even though it is a classical pattern matcher, it doesn't have a movement to call it's own, so I figure I should resolve that. Even though I doubt I will quickly come up with a better one then Raiko's. --Chase 06:44, 4 March 2010 (UTC)

HFSPM?

Forgive me, but I'm curious... what does HFS in HFSPM stand for? :) --Rednaxela 01:31, 28 June 2010 (UTC)

Nothing to special, it's Heavily Folded Symbolic Pattern Matcher. I have no idea if its anything more special than a normal one, except it uses my own symbol maker. Unfortunately, even I cannot seem to replicate those results anymore (at least against RaikoMX). Which makes me very sad. By the way, do you have some other means of contact? — Chase-san 01:43, 28 June 2010 (UTC)

Actually Nevermind! I found the problem (somehow I removed the AdjustYForXTurn stuff). — Chase-san 01:59, 28 June 2010 (UTC)

About ProblemBot

The list of bots it suppose to be the ProblemBot for, is as follows.

DrussGT
Diamond
WaveSerpent
Dookious
Phoenix
Hydra
Ascendant
Wintermute
YersiniaPestis
GresSuffurd
Garm
SilverSurfer
SandboxDT

Just you know it is slightly gimped so that no one got overly mad at me (and it wouldn't effect scores as much). Usually the bot I based it on Beats SandboxDT, but ProblemBot doesn't (not even close). I say this just in case someone thinks I didn't do it right, or well enough. It was on purpose (jokes go only so far). :) — Chase-san 10:33, 6 July 2010 (UTC)

But on that note, if you want me to do it right, please wait for Seraphim 2 to be finished. :) — Chase-san 10:37, 6 July 2010 (UTC)

Hi mate,

Links pointing to http://file.csdgn.org are broken. I fixed one of yours in 1on1 to point to http://robocode-archive.strangeautomata.com/robots/ but I presume that you would rather host your bot yourself.

Thanks, it was due to an errant htaccess whitelist rule. I forgot to place the subdomain in it, so it got blocked.

Thank you for dealing with the recent spam attack.

Most of the discussion about this attack is happening at Thread:User talk:Skilgannon/Spam bot invasion, including a list of users who need to be nuked and some suggestions about what to do next. If you haven't read that thread yet, you should.

Already saw that page and i'm working on what I can. I don't have system access, just admin, so I can't change any logic or lock the wiki to clean up or anything, just going to begin a super ban wave.

Abdul
Abhi2828
Abhishek.upadhyay11
Adamsmith
Ahmad1234
Ahmadd123
Ajaykapadia2
Akki
Alex
Alexa
Alexdogge1
Alexyokei
Alhaji
Amit8923
Andoralifs
Andrusmith1
Anisingh
Anjilajolia
Anjilajoliaa
ANNU17
Anshu01
Araja
Asdasd
Ashish12345
Ashish786786
Astrologerbaba16
Avisupport
Baba786
Bisafepa

Have been blocked and their pages deleted. I'll keep you updated but this is a huge list and I have work tomorrow. :(

Bitcoinsssupport
Blizzardbluee
Bookentry
Bradyswan
Brandi84
Bujelizala
Caira
Caleb
Cbkjvjvkd
Chorsupport
Chunnu7294383gulabo
Cooljass1
Cuwerokume
Cybertechnisdhhdh
Dabbu
Dante
Dasfgs
Dear
Depih12
Dev123
Dexter6789
Dfasffasf
Dfgvfgvfsd5
Dfjhfgj
Dfsdf
Dgdfhfgjhfgh
Dhanraj99
Dinni999
Dk923478
Dolka01
Dpkapadia1
Dsgdfhg
Dsgsdhjfe
Dykywipy
Ellis S Skinner
Emma000001
Emmawatson
Emmie2680
Engineer123
Ergugfdguf
Eswt
Faer
Fairsearches.pradeep
Faisal
Faulkner
Fdbhdf525
Fibarip
Frankgel
Fransis99
Fullsupport
Gakllerjohn
Gattu
Ghfdhfg
Ghufgt567121
Gibson
Ginjuilinhj
Gk707027
Gofyozilto
Gopalamj
Gtrtgum
Guwogepome
Hajsfdjorkgpgk12
Harryji
Hemantvar
Herry9
Ginjuilinhj

Have been blocked and their pages deleted. This is only a 3rd of the "new list" so far and i'm already pooped. We need a better solution.

List updated.

I made a new pass through Special:ActiveUsers (when a user is nuked, it will drop out of this list), checked each one to make sure that it is indeed a spam account, and used a script to filter out the ones that you already removed.

There seems to be a flood of new users, I can only guess that these are not people interested in robocode, but rather some kind of spam bot (or spam bots). We need some way to captcha user creation I think.

While we are at it, remove some of those "new users" without any edits.

I wonder why create spam bots when you can create Robocode bots. :P

Speaking of user removal. How many active admins do we have?

Well a few, for example I don't have access to actual site stuff (so I can't add a captcha).

We could just go through and manually delete them all, but there is no bulk method way to do that (that I know of).

List of those with mediawiki "administrator" access:
AW‏‎, Chase-san‏‎, Darkcanuck‏, David Alves‏‎, GrubbmGait‏‎, Jdev‏‎, MN‏‎, PEZ‏‎, Rednaxela‏‎, Sheldor‏‎, Skilgannon, Skotty‏‎, Voidious, Wompi

List of those with server shell access:
David Alves‏‎, Rednaxela‏‎, Skilgannon, Voidious

The one whose name the server name is under:
David Alves‏‎

The one whose name the domain name is under:
PEZ

The last several times the server needed config maintnance I've dealt with that. I know Skilgannon is also checking in wiki sometimes. Voidious less often recently to my knowledge.

For future reference, you can see who's a wiki administrator or bureaucrat by using the "Group:" filter on the user list page.

Hate to break it to you Chase, but we already have a captcha on user creation. In fact, we have *TWO* captchas (reCaptcha, plus a simple math question presented as an image) required for user creation, and the bots involved in these user creations seem to crack crack both. I tend to wonder if they're using a "mechanical turk" type of system to outsource bulk captcha breaking to humans.

Only reason they very rarely succeed at actually posting content these days, is because of a custom Mediawiki extension I added, which blocks any edits which add new external URL links if the user account was created within X hours of the attempt. (Note, it does not block external URLs that are not formatted as Mediawiki links, such as the participants page of course)

Perhaps I should augment this extension to remove users whose only attempted edits during a 1 week period were blocked in this fashion?

My experience with captcha locked registration, is that at some point someone, most likely a human, provides an answer to at least one question. After this bots will register like crazy. On my site I had non googlable question, which holds bots for a month or two, but sooner or letter they will come.

The only way to deal with it, is to remove old questions and generate new ones.

"Perhaps I should augment this extension to remove users whose only attempted edits during a 1 week period were blocked in this fashion?"

That policy sounds pretty reasonable, as long as it is clearly written somewhere new users would see.

Make it 3 days and that'll do it for me. We should also nuke users without any posts that registered more then 3 days ago as well (and were not added by an admin), or something.

I think there are some features enabled for registered users. Something with cookies but I cannot recall what are they. So, quiet registered users have a right to exist.

But quite folks do not contribute, so it is probably fine to sweep them away as the bot candidates.

There are not a major amount of benefits to being registered aside from posting. I think it keeps your layout and settings and such. But most active people (even readers) have at least one edit under their belt. Since this is about robocode, you usually make a robot and enter it into the rumble.

Actually, now that I think about it. I think Voidious used Asirra to prevent issues on the berrybots wiki. Now asirra is closing down this year, so we can't use that. But there should be some other image based captcha's around.

As we all know, classification is a very difficult AI problem, but is almost trivial for us humans. :)

Usually, it is sufficient to ask what is "2+2", may be in the form "two plus two" so it is not that obvious for a parser. Since, we are fighting attacks not designed against this particular wiki, it will be sufficient. Once, a traitor give the answer to this question to a bot net, we will ask what is 2+3, and so on.

We could just randomize it so it's 17 + 21, and then just tweak the way it is said so it becomes thing likes "one before eighteen plus one past twenty"

Wow, I would not pass such captcha on a first try :). It sounds like the french way to call numbers, which I believe, is not very common.

I decided to try the registration process. We do have a math question and a number image recognition images. But these bots are advanced. They clearly can parse/recognize numbers and do simple math with them.

I think we need at least one captcha which deals with something but numbers and we need it asap. My rss feed is spammed by new registration announcements way more often than I wish to know.

Or, as Rednaxela noted above, they could just be outsourcing it to humans. Though if they are advanced bots, we could try something like Asirra, which makes users select only photos which have a certain type of animal in them, though it seems Asirra itself won't be around for much longer. (Voidious, since you use Asirra for the BerryBots wiki, you may also want to look into a new captcha system.)

We might want to consider locking registration until we can come up with a solution. The wiki isn't particularly active at the moment and there has been 166 registrations since they started on September 23 (and 1 which is questionable). None of them have posted a single thing. That averages about to around 10-11 new users a day.

I guess that would be fine for a few days, but if someone's willing to go to that trouble, why not just implement one of the solutions that have already been proposed, such as deleting accounts that only post with external links in their first few days, or your suggestion to have a hidden textbox that must be left blank?

Now that I had some time to think on the problem. I do remember using one really simple and really effective tool to prevent bots from registering.

It's called a reverse captcha. Basically you use in combination with normal captcha, but you are suppose to leave it blank. Give it a id and name like "captcha" and bots will almost always fill it in with something. You then either hide it via css (most bots don't read css, and even if they do, it often falls into the machine vision problem), or write next to it that you are not suppose to fill it in.

Also prevent registration from non-local referrers should also reduce the amount of bot registrations.

There is also the twobox captcha. Where you have one set of instructions for two text boxes, that have a value already set. You tell the user to change the value of one, but not the other (usually something simple). This requires usually a custom bot to attack the site, since such a captcha is beyond the normal (which generally only attack standard captcha implementations, such as recaptcha).

Hey guys can I get enough permissions not to have to go through all the captcha to link externally, etc. I think you are fairly certain by now I am not going to spam the wiki to death right?

I mean I am probably not the smartest robocoder by any stretch of imagination, and I often end up with my foot in my mouth. But I generally mean well.

Done. And while I was at it, I added a few more as well, people who have proved they can make meaningful contributions and delete spam when they see it. If I've forgotten anybody just yell!

Skilgannon, add me also, please.

Thanks too:)

Thanks!

Thanks!

Sorry, I didn't realize life was so littered with captchas for the non-admins. =) Maybe we can lighten the settings a bit for registered users? Seems like we get a steady amount of wiki spam that we just have to delete/block. All that captcha suffering may be for naught.

Not sure of a good way to go about fixing the problem. We could always switch to using KittenAuth. Asirra is a slightly newer MS based variant of the same type of captcha.

Hi,

I realize that I am making a bold request considering I have only been a member for a little over a month, but I would greatly appreciate having my status upgraded to administrator.

In addition to the external link issue, it seems there has been a flood of spam recently and I would like to help.

Thanks.

Hey all. It's a bit late, but I've taken some measures to both lighten the settings for registered users, and also reduce the amount of spam.

1. Adding external URLs to a page no longer triggers the captcha (registering an account still triggers the captcha)
2. Adding an external URL to a page is outright disallowed until 24 hours after the account's first edit.

Hopefully that helps.

I have been mulling around ways to approximate ELO for awhile. Since originally it was used for ranking (2000 club, etc), however the rankings have drifted considerably and with the advent of APS there is no real need for it. However the number is still nice, even if the methods for calculating it have problems.

So I figured we could get our nice number without a lot of number crunching with way of a simple equation. At least that was the original theory. However APS doesn't map very well to ELO, which is not at all linear, and the data set required for calculating such an equation is incomplete.

However here are my token efforts at doing just that. The dataset I used was the 2009 Glinko-2 and APS, as it was likely the most similar to the old ELO rankings. I would ahve used those, but they lacked an APS column, and the common bots between them don't exactly line up very well (plus that decimates my data set even more).

public static final double calculateElo(double x) {
	double a = 169.1;
	double b = 0.02369;
	double c = 334.2;
	return a*Math.cosh(b*x)+c*Math.log(x);
}
public static final double calculateEloFast(double x) {
	double a = 0.7082e-03;
	double b = -0.3340e-05;
	double c = 0.3992e-02;
	return 1.0/(a+b*x+c/x);
}

The first is a bit more accurate. 0 is negative infinity, and 100 is around 2450 (it should be positive infinity, but I did what I could). However with a logarithm and a cosh, it is a bit heavy to be called 700+ times every a page loads (I think at least). The second is a slightly less accurate system, 0 is 0 and 100 is about 2415. With mostly simple math it is much easier to execute.

So thoughts, concerns, scorn?

For a precise ELO calculation you would need the full pairwise matrix. But for an approximation based on an APS column, it looks good.

Another way to deal with rating drift (without the full pairwise matrix) is calculating the average of all ELO ratings, then calculate the difference from the average to 1600, then add/subtract the difference to all drifted ratings. So you have ratings centered around 1600. Works with both ELO and Glicko-2 ratings columns.

Does it currently do that? The Glinko-2 has drifted up, the 2000 club now consists of only the top 16 bots.

Which is why I was considering trying to make a Approximate version. However, with mine instead of drifting down I think I see higher bots drifting up, and lower bots drifting even more down. I think this is because as new lower bots are added the APS for higher robots go up, and robots that did worse against it go down.

So it faces an entirely different kind of drift, but at least the center seems stable.

ELO/Glicko-2 work with differences between ratings.

The more competitors the ranking has, the more the rating difference between first and last places will be. This is normal.

But ELO has another drifting problem due to deflation. All competitors ratings going down because most retired competitors have ratings above the average.

static final double DRIFTED_ELO_AVERAGE = -2397.92418506835;

static final double DRIFTED_GLICKO2_AVERAGE = 1468.99474237645;

static final double DESIRED_AVERAGE = 1600;

static double calculateElo(double driftedElo) {
    return driftedElo - DRIFTED_ELO_AVERAGE + DESIRED_AVERAGE;
}

static double calculateGlicko2(double driftedGlicko2) {
    return driftedGlicko2 - DRIFTED_GLICKO2_AVERAGE + DESIRED_AVERAGE;
}

I'd be fine with a new ELO formula to replace the currently useless one, but I can't see myself ever again caring about ELO or Glicko over straight APS for the main overall score rating. APS is clear, stable, accurate and meaningful, and ELO/Glicko just seem like attempts to solve a problem we don't have. As far as new permanent scoring methods, I'm much more interested in the Condorcet / Schulze / APW ideas brought up in the discussions on Talk:Offline batch ELO rating system, Talk:King maker, and Talk:Darkcanuck/RRServer/Ratings#Schulze_.26_Tideman_Condorcet. I also really like what Skilgannon did with ANPP in LiteRumble, where 0 is the worst score against a bot and 100 is the best score against a bot, scaling linearly.

The main advantage of ELO/Glicko-2 over other systems is they work well with incomplete pairings, and yes, we almost don´t have problems related to incomplete pairings.

But there are other smaller advantages, like higher accuracy with scores near 0% or 100% due to its S shaped (logistic distribution) function. Being able to "forget" the past also makes ELO/Glicko-2 adequate in meleerumble where historical contamination is an issue.

And I would really like to see a Ranked Pairs ranking. This would bring something new to the rumble. It is superior to the current PL (Copeland) system in almost every way, except maybe CPU/memory performance. I was thinking in building another RoboRumble server myself, designed specifically to calculate complex rankings like Ranked Pairs. But didn´t find the time to do it yet.

The thing about ranked pairs is that I haven't seen any which provide absolute scores per bot, rather than relative scores - I guess this is just part of the definition? Because of this there isn't any way to make partial improvements however, which makes it meaningless as a testing metric. Also, they are usually difficult to understand (conceptually), so understanding which pairing is causing a score loss is harder. That's why I like the Win% and Vote% as metrics for robustness, and APS for overall strength, because they are easy to understand, calculate and identify problem bots.

In Ranked Pairs, competitors causing problems are always above in the ranking, with the one causing most problems almost always directly above. Competitors below in the ranking never cause problems.

Unless you are competing for the bottom, when you reverse the logic. Competitors causing problems are always below, and competitors above never cause problems.

Although the calculation is complex, the resulting ranking follows a rather straighforward transitive logic. Winners staying above losers, with this always being true between adjacent competitors in the ranking.

This is due to 3 criteria being met at the same time, ISDA, LIIA and cloneproof.

But Ranked Pairs is not meant to replace APS or ELO, it is meant to replace PL (Copeland). APS and ELO give a rating which helps track improvement while Ranked Pairs and Copeland don´t.

I think if you add a d/(100-x) term it will improve the fit near the top. Perhaps use d*(100-x)^e for the slow/accurate version, although you can't use simple linear algebra to find the best e then, a genetic approach would probably be better.

I like the idea of this, just for historical reasons to have a decent mapping of APS to ELO, and would consider adding a column in the LiteRumble page for it. I would calculate this on the fly as the page loads, since for me with Python on App Engine the slow part of the code is the interpretation of the code, not the individual math operations the code calls =)Of course I'd have to test to make sure it doesn't slow it down too much, but it should be fine, the fast version if nothing else.

Ah good idea, how about this? It is a real mess at the moment. But it seems to work, and is a bit more accurate in my opinion in placing certain bots where they belong. It also has negative and positive infinity for 0 and 100.

public static final double calculateApproxElo(double x) {
	double a = 0.0007082;
	double b = -0.00000334;
	double c = 0.003992;
	double d = -124.3;
	double e = 647.4;
	double f = -72.5;
	return 1.0/(a+b*x+c/x) + d/x + e/(100-x) + f;
}

That is, Diamond and DrussGT are in the 2200 (only just), Phoenix up are in the 2100, Help and up are 2000. The 1900's start around Raiko/Lacrimas.

Here are some graphs.

If you want to enforce a specific rating for a specific competitor, you can also adjust the DESIRED_AVERAGE in the algorithm above so ratings match what you want.

The real challenge is making multiple bots line up, which is about what I managed here.

If you change the rating difference between competitors, you distort expected score estimation, PBI and specialization indexes. It is no longer ELO-like.

That´s why the code I put above shifts all competitors up or down equally.

Looks pretty good. Any chance you could show that first graph overlayed with a scatter plot of the training samples you used?

The first one was generated (calcelofast). I used all samples from 2009 rumble archive aps and glinko-2.

From there it was hand tuned to be honest.

Wow, ok. It would only be a couple lines of Matlab/Scilab to do a proper regression though. Wouldn't that be better?

If you want to do one. You can just get the output from the algorithm and use those as the samples.

(I don't have MatLab actually).

Try this: elo(APS) = -300*ln(100/APS - 1) + 1600

It uses a reflected normal sigmoid so (I think) it's based off of the same theory that the ELO is. Here's a pretty graph =) It's properly centered at 1600 as well, unlike our glicko2 implementation which it seems has drifted - 50APS doesn't line up with 1600 like it used to (perhaps due to more strong bots re-submitted like MN was saying).

Hey that's not bad! It places some of the top 20 a bit high, and that bugs me a little, but every other bot fits a bit better.

My biggest worry is it places YersiniaPestis and up in the 2100's and Tomcat is very close to the 2200 (not really a problem), and the top 2 are over halfway to the 2300s (not a problem really, since they are in their own little universe anyway).

Traditionally the 2100's started around Phoenix (85.78), but Shadow (84.69) up would be perfectly fine.

-290*ln(100/APS - 1) + 1600

Might be a better compromise.

If you take a look here it seems that the APS has actually drifted as well.

The same version of Dookious, 1.573c had APS 85.65 on 2011/03/14, currently at 86.31. I can only conclude that lots of weaker bots must have been added to the rumble. I based that formula off of the old APS-->glicko2 relationship, and if the current APS has drifted due to weak bots being added I'm not sure if we should correct for that in our formula or not. It's a tough call.

While there is no simple way to take care that drift in the long run (that I can think of), I think we should correct it as much as we can at the moment. At least to a point where the current historical numbers have some meaning again (2000 club, etc). So at least people can claim their titles.

I would like to see a way to make the approximate elo a bit more drift tolerant, but I have no (good) suggestions on how to go about doing that.

We could just retire the clubs and make new APS ones. I'm as proud of 90 APS as any of my ELO club memberships. :-)

Yeah, considering that 80% lines up pretty well with what 2000 used to be I think this is a pretty good idea. Good luck with getting your power back, hope you didn't lose anything to Sandy =)

APS has no direct relationship to ELO. The APS can go up because, as you said, a lot of weak bots were added. For ELO not the pure result counts, but the result relative to the 'expected' result. If f.e. the expected result is 95-5, and the true result is too, ELO would not change, while APS will go up. For me, an ELO of 2000 for cf.proto.Shiva 2.2 would be acceptable, as it hoovered there in 2006-2008 (source: The 2000 Club). That means that -280 would be even a better pick in my opinion. Ofcourse that would not be ideal for every bot, but I think that setting the border for The 2000 Club as it used to be (long time ago) is a good compromise.

Aargh, forget what I said. This approximate ELO is direct related to APS. Still have the old ELO in my head. My remark about the border of The 2000 Club still stands though.

Personally, I don't consider changes to APS to be "drift", but just valid changes to overall score based on the rumble population. There is no such thing as an absolute rating, even with a (theoretical) perfectly designed ELO. To me, rating drift is a change in rating when the pair wise scores have not changed.

I haven't examined the data closely (4th day without power here!), but fwiw Dookious maxed at about 2130 on the old server and Komarious was almost exactly 2000.

You make a good argument, it isn't drift per say. I suppose we could go with this version of the AELO. Unlike APS its numbers are more `memorable`. Mostly because their larger, but also because of the logarithmic scaling at the extremes.

So instead of saying i'm ranked 90.2 vs 90. It is 2244 vs 2237. Besides, if you hit 100% you get to say you hit infinity.

There is a way to make an "absolute" rating in ELO, using an anchor competitor.

Choose one competitor, preferably a competitor which is never re-submitted, and define arbitrarily which rating it has. Then, modify rating updates so this anchor competitor rating never changes. All other competitors ratings will adjust in relation to the anchor competitor, instead of in relation to newer competitors added to the ranking.

I saw it been done in CGOS ranking.

But simply centering everyone around 1600 (ELO) or 50% (APS) is good enough for me.

I think that's a good idea, and is something David Alves had slated for roborumble.org =), but everyone else's ratings would still change as the population changes, just as APS does. I was just saying that is unavoidable, and not an anomalous side-effect of some weird scoring formula, like ELO rating drift.

Avoiding ratings drifts due to population increase is hard to workaround, and the anchor competitor is the only way I know.

But avoiding ratings drifts due to re-submits (everyone´s rating going down) can be avoided by centering everyone around a constant number, like 1600, or around a single anchor competitor.

If I had to pick an anchor, I would go with something like SandboxDT, RaikoMX or some other classic robot.