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)
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)
