Archived talk:Tityus 20090519
- Tityus Sub-pages:
- Tityus - Version History - Archived Talk 20040104 - Archived Talk 20090519
|
- Applause* Ninth place! Damn that new movement is good. Beautifully simple, too. Well this definitely raises the bar for Raiko. ;-)
Thanks! Yeah, the movement is promising. It's actullay the same movement as 0.6.2 just differently tweaked. And the current version is far from perfectly tweaked. I'm applying alchemistry now to find the right formula. =) -- PEZ
Amazing!! You've taken number 3, and it looks stable! Your graph is incredibly funny. :-) Congratulations! I think this heralds a new era in Robocode. Multimode is back, and back with a vengance. - Jamougha
Eek, I hadn't looked at the minibot rankings. 40 points above Verti?? :-D - Jamougha
Hey, I thought Swiffer was the return or the MultiMode era. =) But you are right. It took a really brilliant idea (of Axe's) to really break the barrier. I think this shows that the ranking system is a bit funny. Yeah, a look at Tityus LRP graph really shows it. I might have a less funny looking graph if I do the trick Axe's way, instead of my home-brewed one where I sacrifice the first two rounds against bots that don't hesitate shooting full lead. This makes me lose valuable points against many good bots. I have 1851 points with 358 battles fought at the time of this writing. With a negative momentum, so it might be #5 or something for T this time. But next version should fight better for the #3 spot I hope. 40 points ahead of Verti? That probably will settle too. But I would like to have both #1 and #2 a while. Something to use for wall paper. =) -- PEZ
Quoting jim again: "Hey!!! I was quoted. This might be a first." (That makes 2 quotes for jim X 1 quote for me :). I am very proud that i can pay back all of the great ideas that u all gave to me. I think that this is the spirit: "No Fear From The Sharing"!! Congrats!!! U surelly deserves be fighting for the crown! Watch out Paul!! -- Axe
Excuses, watch out iiley too :)... -- Axe
I think that i have a good idea too for that decaying problem in MultiMode, i have a large experience with multi gun thing. The problem is the switch in the best time, that is: the decaying... I will be sharing it at Musashi's page shortley. -- Axe
What decaying problem? I must have missed something.
It seems T0.6.8 gets the same rating as did T0.6.7b. The graphs are pretty different. This is interesting. It seems my own implementation to tricking head-on guns was more accurate than Axe's. But it came with a heavy price tag of giving two rounds away to the stronger bots. Since Axe's function is so elegant and to-the-point and the end rating is the same I'll keep it. I don't like losing to the strong bots even if it makes me win bigger against the weak. -- PEZ
Tityus 0.8.1 which is a blend of T0.6.3 movement, T0.6.5 gun and the MusashiTrick, rates in at 1854. And as I suspected it was the small (I thought) gun changes in T0.6.6 that was letting me down. It was also why the graphs looked so funny. Now the graph iswellbalanced and neat, and you can see the head-on targeters pretty easily. =) I often give, and seldom follow, the advice to not work with targeting and movement at the same time. Now, that advice is really worth something! -- PEZ
I tried the shrinking tips Jamougha gave me on the VertiLeach page on this bot and it saved me 47 bytes. Maybe I should do something more to reach those 60-70 bytes? In any case, now I have 115 bytes free. Anyone has a suggestion on what I should do with them? -- PEZ
Mmmm, let's see, you still have Point2D wGunLocation = new Point2D.Double(); in your wave class, and you don't need to initialise wGunLocation here. If you bring your shoot() method back into onScannedRobot you can make lastEnemyAbsoluteBearing local. Unfortunately your nice code structure makes it hard to do much more shrinking. :-) At least you found something to use up the bytes, heh. - Jamougha
Thanks. It's funny this shrinking voodoo. I removed the redundant initialization of wGunLocation and it didn't save a byte. The Wave class was still 69 bytes. Then I tried to compile it on a Windows PC with the bundled jikes compiler. The main class then shrinks 12 bytes and the Wave class grows to 73. But on the PC the Wave class shrinks to 57 if i remove the initialization. Which means compiling on the PC saves me in total 24 bytes. Together with some other canges and removing the DynamicGuessFactors again I now have 166 bytes free for the next version of Tityus. I am figuring on if Ishould use them for movement or targeting. I think I will choose the movement path. The bad thing is I will have to do the compiling on the PC... -- PEZ
What happens if you mix and match the class compilation - compile some classes on pc - others on your normal system - and bring them back together when packaging. -- Paul
That should work. However, in this case both classes gets smaller on the PC. But I'll keep that in mind. I have seen that in same rare cases some classes get smaller on the Mac. Codesize limited coding is a pretty stupid thing to do anyway. I guess I must suit myself for getting bothers like this. =) -- PEZ
OK. so I got this cool movement idea from Kawigi that I just must try. I think it might cost some 100 bytes in the first try. Will take a while to tune though. I wish I could use my speedy PC for this. It would cut down my test cycles from 40 minutes to 5. ... -- PEZ
If you're talking about a CoolMovement idea, it shouldn't be worth much more than 30 or 40 bytes. Of course, I say that based on my experience with using in Flood bots which are already doing interesting things with enemy fire power. It does take some tweaking for it to work, though. -- Kawigi
Scchhhh! =) We'll see about codesize, my guess is this will cost me 100 bytes. I bet you, Dummy, iiley and other codesize experts could obfuscate it down to 30 bytes. =) -- PEZ
I don't remember how many assumptions I made about default settings either, though, for instance using .1 instead of getGunCoolingRate() and stuff. -- Kawigi
Well, I'm using the API call. That should be the only assumption you could do. The rest are fixed with this version of Robocode at least and doesn't have a corresponding API call anyway. -- PEZ
Well, so my first try with CoolMovement didn't make the bot stronger. In fact it got a bit weaker and I think it's only the MusashiTrick that keeps its nose above the water. I won't give up on the first try though. It is hardly tuned at all and I know it's profile on sub 300 range is horrible. Besides Shadow seems to have problems with this movement. That's a reason in itself to keep it. =) It does cost me 100+ bytes as I suspected. But it might prove worth it if I manage to master the tuning. -- PEZ
Nice scorpion. Did you make it? --David Alves
No, I ripped it off of the web somewhere. I wish I could do graphics! -- PEZ
Interesting update. :-) Found another bug in the gun. To get the correct guess factor it uses
Math.round(((((wave.wBearingDirection * Utils.normalRelativeAngle(
absoluteBearing(wave.wGunLocation, enemyLocation) - wave.wBearing)) /
maxEscapeAngle(wave.wBulletPower)) + 1) / 2) * wave.wAimFactors.length)))]++;
but converting a guess factor to an angle uses
((mostVisited + 0.5) / AIM_FACTORS) * 2 - 1
which are not reversible functions. Works out it gives the wrong guess factor by one about half the time. Try subtracting .5 inside the Math.round function. Doesn't make much difference, but it's worth a percent or so on your accuracy. - Jamougha
The add 0.5 trick doesn't work for negative numbers, switch to real rounding around that statement if you can. -- Kuuran
I agree with Kuuran that rounding is better than adding 0.5 (and agree with both of you that they aren't equivalent). The reason I started rounding was because I was truncating ("rounding toward zero") to find the guessfactor but then firing straight at the guessfactor. This means I was basically always firing half a guess factor closer to head-on than the middle (and supposeable median) of the guessfactor. Not something significant, but something that may be worth 1% in the TC against the harder-to-hit bots. Side note - While my intuition tells me rounding is better, stuff like this is generally worth a TC run against one robot (I typically use DT 1.91 in passive mode for 500-1000 rounds) to see which is better. With a good test against fairly "pure" random movement (none of this crazy adaptive or self-charting stuff, a buggy gun is probably better there), the better is probably also more correct. On that note, I believe if you are using custom events for waves, you should add one to the firing time when you create the wave or always subtract one from the current time while processing it. Or it could be the other way around, but 500 rounds against movement-only DT will tell you. -- Kawigi
Thanks all of you. Long ago I used a different calculation (I think Griffon still uses that one), but I felt these were easier to read. It was FnH and Kuuran assisting me when I asked the question on PEZ/Question. Now, do I understad things correctly if my best bet is to do round(mostVisited) instead of adding 0.5 like I do above? I so wish I could run those 500 rounds against movement-DT 1.91. But the stupid bug in my PC (WinXP or Java or hardware or whatever it is) prevents that effectively. And it's painfully slow on my old laptop... But I'll have to do it I guess. =)
I had actually hoped this T should go a bit higher. Raiko style segmentation really helped a lot, but I need to dig up some more points. The only mini beating T now is BlackDestroyer it seems. Since T beats both Raiko and BlackPearl pretty good this should probably tell me something. But I don't see what it is! =) Also Musashi seems to be tough for this T. Watch this space to see what I do to counter that. -- PEZ
I should have pointed out way back when on PEZ/Question that the 0.5 will create problems with negative numbers, but for some reason I didn't (maybe at the time I wasn't aware of this). Math.round() does actual rounding to the nearest, adding 0.5 does so for positive numbers, but adds 1 to negative numbers because, by default, java does truncation, which is always in the direction of 0. So 1.2 + 0.5 = 1.7 which truncates to 1, the proper rounding. If it were over 1.5 (1.6 for example) you'd have something like 1.6 + 0.5 = 2.1 which truncates to 2, the proper rounding. In negatives you get -1.2 + 0.5 = -0.7 which truncates to 0, so you can see the problem ;) Truncation is always towards 0, the addition in positives moves it away from 0 by the correct amount to round, but in negatives you're moving it even further towards 0 throwing your factors way off. Math.round() around the statement instead of the adding of 0.5 will solve that.
Err.. sorry it's late and I wasn't thinking, I initially posted that you want to round the whole mostVisited/AIM_FACTORS term, which is obviously wrong, that turns it into an on/off switch :p Something like ((double)mostVisited / AIM_FACTORS) * 2 - 1 gives you your exact guess factor from -1 to +1. You want to use that precise value to calculate the angle in this situation, there's no actual rounding required going this direction, is there? Aren't you just going to take this double value and multiply it by the full lead angle to get how far ahead/behind they're probable to be? -- Kuuran
I'm not sure the addition of 0.5 is a rounding thing. I think FnH meant to make the factor be offset half a factor. Something like what Kawigi is talking about a few lines up. This is totally confusing to me, my head doesn't cope well with things like this. So hit me hard with more discussion around it. I'm slow, but eventually I'll get it. =) -- PEZ
Hrm, I'm going to take a look at the full code because it seems like I've misunderstood what's supposed to be doing what, and clearly that's not helping me make sense. -- Kuuran
Thanks! I appreciate. -- PEZ
Wow, at the rate you're going you'll pass Shadow shortly. :-)
To see what I mean about the bug, try putting Tityus up against sitting duck. - Jamougha
(edit conflict)I looked it over and now I have a slightly different picture of what does what. As far as I can tell this isn't a bug, I think you're right. The gun shoots at guessFactor + 0.5 instead of directly at guessFactor on the principle that all the data in the guess factor is coming from values above the guess factor (ie: all the stuff in the third bin is coming from guess factors 3.0 to 3.9999...). This isn't true, however, because you're using Math.round() instead of a cast to int, so 3.7 or whatever else that rounds up will in fact be in bin 4. This makes each bin the median value of the guess factor, not the start value, and makes adding 0.5 to shoot at the median needless. Remove it entirely and run a few hundred rounds against DT or compare to a few of your existing TC percentages for that gun, bet you'll see a small aim improvement. -- Kuuran
Thanks! I never did like adding 0.5 without knowing why. =) -- PEZ
Apparently RR@H hates you. I just watched smart battles run 30 battles of nothing but 0.9.2 vs Gouldingi and DogManSPE, both of which have negative PBIs ;p -- Kuuran
It shouldn't make any difference, if everything is working correctly. It would only change the ranking if T did worse than it did last time it fought them. -- Tango
What is smart battles anyway? I have seen that happen too at time that two bots really get to hammer out on each other. Doesn't make sense. -- PEZ
Something tells me this update (0.9.3) was a huge mistake... -- PEZ
Of the 0.9.x line it seems 0.9.0 and 0.9.2 were the best, depending on wether you're looking at overall scores or scores in mini. -- Kuuran
I'd say it's 0.9.1 in overall (1897 points) and 0.9.2 in mini (1907 points). But 0.9.2's edge over 0.9.1 in mini could be that I packed a few more mini-bot data files in the latter. -- PEZ
I may've confused .0 and .1 there, sorry. The ones I was thinking of did have the best scores there, and yeah, in mini I remember it being very close, I guess we'll see a rollback to .1? Good luck with version 1.0.0 if that is what's next, hope to see some Raiko upsetting ;) -- Kuuran
I don't think we'll have a rollback of the code. I like how simple I got it now in 0.9.3. My hoping is that it was just me doing a bad tweak of it. 1.0.0 is where I'm heading yes. When it's able to bring home 1920 points in general roborumble I'll name it 1.0.0. Passing DT 2.41 with a mini would be so sweet! =) -- PEZ
Now, a rollback of the code might be what I should do. I'll do two or three tests with this new system and if they don't work out I go back.
What should I do about the mirroring bots? I know stupid me gave Axe the advice to outmove and outgun the mirrorers. I wasn't aware then that my problem bot list does not only contain pattern matchers but also mirrorers. I can't fit an AntiMirror gun. Someone has another idea for strategy? -- PEZ
What about stop moving and fire(3) at you opponent if it is a real and pure mirrorer. --deathcon
If the mirror also does fire(3) I'm not all that well off am I? But something along these lines might work. Problem is it eats up quite a few bytes to check if I'm mirrored. -- PEZ
Adding in a dedicated AM system is probably beyond the scope of a mini that wasn't designed with it in mind from the start. Best bet might be to tweak your gun segments so they're particularly strong against your movement, you know when and where your movement is liable to show weakness, adjust your gun to see those situations easily and you should be alright against anyone who wants to borrow it. Even just tweaking the granularity of segments to match how your movement changes would be a good idea. -- Kuuran
AntiMirror guns, although fairly simple in themselves, are very hard to implement into a bot, because the gun and the movement are usually separate. Maybe you could just make a new movement system that only kicks in when it detects mirroring, and just make it very predictable (by you, not the enemy) so you can work out where the enemy will be and shoot it. The difficulting is fitting an extra movement system into a minibot... good luck. -- Tango
Well, it doesn't fit in T I can tell ya! It already packs more features than most other minis. But I thank you all three for your suggestions. I think I can make something out of them. Kuuran's observation alerts the problem I create by using the same bot for graphing when tweaking it's movement. Of course I create the ultimate Dodge Tityus movement then. And of course I get into big problems with mirrorers. -- PEZ
Indeed, the prevelance of personal grapher bots is my theory on why mirrors are suddenly a huge thorn in everyone's side. If I ever do get into larger bots where movement is paramount I'll probably grab a gun out of some top level OpenSource bot to plug into my grapher. Going the other way around, tweaking your gun on your movement, is probably a safer bet, as you'll do well against all the mirrors out there; where if you tweak your gun against some other bot you'll only be tweaked for that one bot, instead of multiple mirror bots. Since your movement is using the same strong, smooth, flat ideas as most of the top movements, a gun that hits it well should hit most top bots well anyway. -- Kuuran
One solution is to add a segment based on how long you are going to continue in the same direction. This helps against all cannibals, e.g. Verti, and helps slightly against other bots if done right; I've been playing with the idea of using it. Of course you would need to change the implementation of your movement to do this. - Jamougha
A couple versions of VertiLeech ago, I tried a segmentation based on the clock direction I was trying to go vs. the clock direction my opponent was going (either same direction or opposing directions). It was enough to make that version of FloodMini beat VertiLeech (although it may not be enough anymore). You could try something like that. Of course, it may be no better against a true mirrorer than some acceleration segmentation. -- Kawigi
About your 0.9.5 version problem: R u still using MusashiTrick? If u are it seems not to be working properly, see your ratings against Barracuda and Wesco for example... -- Axe
No, I'm not using it. But I thought I had replaced it with something that should work as well. Appearantly not. =) Thanks for letting me know! -- PEZ
PEZ, could you explain formulas in the code below?
double reverseFactor = 0.1 - Math.pow(enemyDistance * (enemyFirePower + 1.1), 0.82) / 7750;
if (enemyFirePower <= 2.3) {
reverseFactor = 0.107 - Math.pow(enemyDistance * (enemyFirePower + 2.1), 0.83) / 8000;
}
--Ph
Nope! It's about flattening of course. Tityus is a RandomMovement type of bot which means it continously asks itself the same question. How probable should it be that I change orbiting direction this tick? The main two factors to consider is the distance we have to the enemy and the velocity by which its bullets are traveling against us. I wanted this porbability to fit a non-linear curve and then I used Excel to experiment with different formulas to achieve it. But then the curve isn't perfect of course. Because of walls mainly. So from there it was about experimenting with different coefficients. I actually breeded several hundred versions of T and let them fight a TestBed of bots to feel more comfortable that I had got it right. To look at a more scientific approach look at Raiko. It uses T's WallSmoothing technique and the same basic how-often-should-i-reverse question. But it's using a formula that surprisingly simple. And this with as good results as T gets. -- PEZ
