User talk:Chase-san/Archive2014
Contents
Rumble Flag
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)
Evil Drone
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)
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)
- 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)
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)
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 RougeDC Pris GeomancyBS
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)
This thing has the wierdest looking LRP I have ever seen =) I've thought about doing something like this, but to only crash against my own bots, thus boosting their scores. Of course, I didn't really think that would be fair =) Another idea would be in melee, having your own bots not fire against each other if they are in the same battle, boosting their scores in general =) --Skilgannon 17:22, 6 July 2010 (UTC)
- I thought the LRP was interesting looking as well. If I had a high ranking bit would be on the list though. — Chase-san 23:46, 6 July 2010 (UTC)
Kitsune
Hey Chase, what's up with this bot? It's only getting battles on the test server, and not the real rumble? That seems like not so good an idea, since the point of the test rumble is to emulate the real rumble and compare ratings, not as a replacement rumble for bots incompatible with 1.6. --Voidious 17:35, 15 August 2010 (UTC)
- I am actually removing it soon. I was testing a few things. I spoken to Rednaxela about it already (before I did it). I don't actually have any plans to release that bot for another month or two. There is no easier way to test robots in a rumble environment, then to test them in a rumble environment. I don't have quite the CPU time to run battles for all the robots for my own private one. — Chase-san 21:00, 15 August 2010 (UTC)
- Regarding "I don't have quite the CPU time", you kind of do. Because you had it set up so only your client would be running Kitsune, you would have had the CPU time to get equivalent results I think with RoboResearch. --Rednaxela 22:50, 15 August 2010 (UTC)
A bit off topic, but is Kitsune a fox (by mean きつね)? --Nat Pavasant 13:49, 16 August 2010 (UTC) PS. I am just learning a bit of Japanese now and then, mostly for travelling ;)
- 狐 (きつね) is the Japanese word for fox, however in Japanese folklore they are depicted as intelligent beings and as possessing magical abilities. Generally considered tricksters and so forth. There is a lot more it then that, but there are full wikipages for that. Kitsune — Chase-san 15:10, 16 August 2010 (UTC)
Irrelevent Voodoo
private static HashSet<String> methodSet = new HashSet<String>();
private static HashMap<String,Method> methodMap = new HashMap<String,Method>();
/**
* Just a little witchcraft!
*/
private void dispatch(Object ... obj) {
//Secondary overhead
String methodName = Thread.currentThread().getStackTrace()[2].getMethodName();
if(methodSet.contains(methodName)) {
for(EventHandler e : handles) {
String name = e.getClass().getName()+"."+methodName;
Method m = methodMap.get(name);
if(m != null) {
try {
//This is actually the main overhead
m.invoke(e, obj);
} catch(Exception ex) {
ex.printStackTrace();
}
}
}
return;
}
setupDispatch(methodName,obj);
}
/**
* Lots of reflection voodoo to set things up (should only be called once per method per battle)
*/
private void setupDispatch(String methodName, Object[] obj) {
for(EventHandler e : handles) {
try {
Class<?> cls = e.getClass();
Method method = null;
for(Method m : cls.getDeclaredMethods()) {
if(m.getName().equals(methodName)) {
method = m;
break;
}
}
if(method != null) {
String name = cls.getName()+"."+methodName;
methodMap.put(name, method);
method.invoke(e, obj);
}
} catch(Exception ex) {
ex.printStackTrace();
}
}
methodSet.add(methodName);
}
//Example usage (simple, no?)
public void onScannedRobot(ScannedRobotEvent event) {
dispatch(event);
}I just thought up this little piece of voodoo code. I was a bit proud of myself, unfortunately I know better then to actually use it in a robot for the event dispatcher, because reflection is slow and events happen a lot, even if it is somewhat optimized now.
Basically the extension (radar, gun, movement) classes are just extended versions of the EventHandler, and if the child class overrides the give method then call it, otherwise, don't.
But my question is, anyone else often have things like this, that are really awesome, but you know you can't actually use them.
— Chase-san 07:08, 13 July 2011 (UTC)
Lessons Learned?
Your more recent robots have jumped considerably in the ranks. I've been stuck in the high 40's for months with XanderCat, close to Seraphim's rank. Did you happen to learn any lessons that might give me some ideas on how to improve? -- Skotty 15:42, 15 August 2011 (UTC)
- Well let me think here. Well First, debug the hell out of things. If your getting hit, figure out where and why your getting hit, then do something about it. Second of all, start of round performance was important. Third ask peoples help, they might know something you don't. — Chase-san 15:46, 15 August 2011 (UTC)
- Also as a side note, don't feel to bad for being stuck for months. I have been stuck for YEARS. About 5 to be exact. :) — Chase-san 01:19, 16 August 2011 (UTC)
- it's ok about my 5 cents? If you look at Tomcat/Version_History, then you can see, that bug fix with zero lateral velocity give me 6 places and adding sorting of data (in fact - bug with using old data) give me 8 places. So i completly agree with Chase, that debugging it is main task, if you has good algorithms
- Another lesson - it is how to test releases. I have set of ~80 different bots (from Top 10 to Bottom 100) and execute 4 battles against each. It take about hour for me now, but Tomcat's version history says, that this test gives true results --Jdev 03:27, 16 August 2011 (UTC)
- I was giving Chase some tips during the recent Nene experiments, and... I'd say the key things to remember about surfing are:
- That systematic distortion is always bad and avoiding that is much more important than any learning algorithms you might try
- Systematic distortion can come from either bugs or conceptual issues, and it's important to be vigilant about both. An example of the latter, is when one's notions of where a wave's danger "comes from" are inaccurate. Fixing the former is debugging your code. The latter is debugging one's notions ;)
- If you're not getting extremely close to 100% against head-on-targeting, then there is probably systematic distortion of one sort or another to sort out.
- (and to be clear, what I mean by "systematic distortion" is when something systematically distorts the robot's notions of what choices are safe/unsafe. This is as opposed to something like the lack of precision caused by not using precise intersection, which while a disadvantage, is generally not a big problem in practice, as the many surfers without it demonstrate) --Rednaxela 03:57, 16 August 2011 (UTC)
Diamond error log
Hi Chase - Could you check if Diamond wrote an error.log on your RoboRumble client (/robots/.data/voidious/Diamond.data/)? I'm hoping -28.9 vs MoxieBot exposed my bug: [1]. That bot's scores do seem pretty erratic, though - 0.04 vs SittingDuck and 16.59 vs Ascendant...
- Strange, I found nothing in the data folder for Diamond. (doesn't it save data as well?) — Chase-san 14:25, 23 August 2011 (UTC)
- Ok, thanks for checking. I don't know MoxieBot well enough to say for sure that wasn't a real result, so I guess it was. And no, Diamond doesn't save any data (besides caught RuntimeExceptions as of 1.6.3). --Voidious 14:29, 23 August 2011 (UTC)
- Oops - I think it would be in
/robots/.robotcache/voidious.Diamond_1.6.3.jar_/voidious/Diamond.data, actually. Though I'm pretty sure I've got this figured out already. --Voidious 19:00, 27 August 2011 (UTC)
- Er... ".robotcache" is only for robocode versions below 1.7 I believe --Rednaxela 19:16, 27 August 2011 (UTC)
- Weird - that's what I thought, and indeed my RoboRumble 1.7.3.2 dir only has .data. But with RoboResearch + 1.7.3.2, it's definitely filling out .robotcache and data saving bots (like Phoenix) are writing to their data dir there. It still uses .data if I launch from robocode_install manually. I did re-install to robocode_install and clear out all my other robocode_install_xxxx to be doubly sure I don't have multiple versions under roboresearch. Kinda insane... (Worth noting that I use the command line, I think most of you use the GUI.) --Voidious 19:34, 27 August 2011 (UTC)
- Er, what is lib/robocode.jar under RoboResearch? I can't just replace robocode_install and have a new version?! Removed robocode_install/libs and it still runs, remove lib/robocode.jar and it doesn't. Gah! My whole world just fell apart... :-P Calls into question all my RoboResearch based tests of different Robocode versions, doesn't it? --Voidious 19:40, 27 August 2011 (UTC)
- Wow, I'm a very sad panda... RoboResearch comes packaged with a specific version of robocode.jar which it uses to run battles. [2] --Voidious 19:47, 27 August 2011 (UTC)
Wave Banding
Wave Banding is treating all waves that would hit within a time given margin (usually 1 to 5) as a single wave. Often weighted by strength and time difference.
Originally designed to remove the need for more complex or deeper multiple wave surfing to deal with bullets that arrive at similar times, simplifying design, and speeding simulation.
I figure within a given time margin, surfing the other waves is about equivalent to surfing the initial wave. These 'bands' would unfortunately however need to be recalculated every time a wave is added or removed (e.g. often).
