Difference between revisions of "User talk:Jdev"

From Robowiki
Jump to navigation Jump to search
(Nobody can help me?)
(reply)
Line 129: Line 129:
 
Just update --[[User:Jdev|Jdev]] 16:49, 17 June 2010 (UTC)
 
Just update --[[User:Jdev|Jdev]] 16:49, 17 June 2010 (UTC)
 
----
 
----
 +
 +
Hm, sorry I didn't look at this close enough before but I think I see the problem. Robocode is behaving correctly, however one must realize that Rules.RADAR_TURN_RATE_RADIANS is the maxiumum radar turning rate ''relative'' to the gun turret, and the max gun turret rotation is relative to the body rotation. Even if you use setAdjustGunForRobotTurn(true) and setAdjustRadarForGunTurn(true), the maximum turn still depends on how much the gun and body are moving. One quick note, is to my knowledge very few bots take advantage of this. One of the few being my melee bot [[Glacier]], which uses gun turning when not firing in order to boost how wide a radar arc it can make. --[[User:Rednaxela|Rednaxela]] 19:30, 17 June 2010 (UTC)

Revision as of 20:30, 17 June 2010

Welcome!

Hello, Jdev, and welcome to RoboWiki! This place contain a wealth information about Robocode, from basic to more advanced. I hope you enjoy creating robots and being a robocoder!

If you are posting a comment on this wiki, please sign your messages using four tildes (--~~~~); this will automatically insert your username and the date stamp. If you are not familiar with MediaWiki, these links might help you out:

If you need help, check out the frequently asked questions or ask it on this page. Again, welcome!

—— Nat 12:37, 22 July 2009 (UTC)


Probably the funniest user page ever! It took me a while before I understand 'well come' as 'welcome'. --Nat Pavasant 06:25, 24 October 2009 (UTC)

Thank you) i'll fix "welcome") --Jdev 10:40, 24 October 2009 (UTC)

It isn't usualy form of communication for me, which used here. Anybody, please, say me which rules there're, where and what i can find here, where i can write, etc. I don't want irritate anybody) --Jdev 15:21, 24 October 2009 (UTC)

The only rule is 'Pretty please be polite'. It can be found on Readme page. You can do anything you want. I think all of us agree that 'common senses' is the second rule. If you do something wrong, then we'll fix it for you. I admit I have done a lot of wrong things on this before. Just learn from mistakes. --Nat Pavasant 15:30, 24 October 2009 (UTC)

Thank you) --Jdev 15:33, 24 October 2009 (UTC)

Welcome from me too, cool user page! :) --Positive 21:14, 24 October 2009 (UTC)

Thank you too) I glad, that robocode community is so newbie-frendly)--Jdev 21:18, 24 October 2009 (UTC)

Well, everybody started out as a newbie, some better than others. Without newbies, the community would slowly vanish. So, welcome, and I hope you turn out to become a veteran. ;-) --GrubbmGait 11:22, 25 October 2009 (UTC)

In the fact i'm already veteran - i robocoder from 2005) just only this summer i leave my computer and go search happy online) --Jdev 17:00, 25 October 2009 (UTC)

May be there're mean to do code review for published listings? i think, that public code review (code review done by community) is the best way to make code perfect. --Jdev 09:33, 28 October 2009 (UTC)

I don't think there is a need of the a 'published listing' if you mean to create new one. Normally I (and I think several other too) randomly read robot's code, and if we spot any bugs, we are kind enough to report them, not to humiliate the author =) In case that you mean to review the existing listing, I think I have enough work already... --Nat Pavasant 13:28, 28 October 2009 (UTC)

Just i read today this code PluggableRobot/Source and, IMHO, there're some not good decision. Also i'm Warrior of Perfect code and try to fight for it evrywhere) But i understand main idea - make it by yourself, but be polite) --Jdev 13:36, 28 October 2009 (UTC)

I agree that PluggableRobot's source isn't very good -- and if I am correct it won't run under Robocode 1.6.1.4 which is use in RoboRumble (key line: _g = bot.getGraphics();) My (developing) robot is currently based on almost the same feature as PluggableRobot framework but with less and much (IMO) cleaner code. Another that may come into effect, is that someone can't read other people's code at all. --Nat Pavasant 13:59, 28 October 2009 (UTC)

Sorry for the late response, but your user page is awesome. =) And welcome to the wiki. About the code review, I don't think many Robocoders are so formal about publishing/reviewing code. (You are certainly welcome to try to organize formal code reviews, but most of us are probably too hooked on our own bots to participate much. =)) I imagine Robert would welcome any feedback you have, though, so you could certainly post it on the talk page. He hasn't been around for a bit, but I don't think he's gone forever. And of course, if you want, you could base a new framework on PluggableRobot, since it's licensed under RWLPCL. --Voidious 19:29, 28 October 2009 (UTC)

It's okey and thank you) and thank you one more time) Ok, i think that soon i will publish my own framework, as alternative) --Jdev 05:59, 29 October 2009 (UTC)

I really wanted to ask, what is that ')' you wrote? If you are using smiley, it should be either :-) or :) or =) etc.

One the point about the robot framework, I have looked into many different robots and I can't find any robot use any of existing frameworks (PluggableRobot and Module). Some ideas are borrowed, though... This is why I decided not to release my framework. (but I admit I really want to see your compare to mine) --Nat Pavasant 11:57, 29 October 2009 (UTC)

1) why "it sgould be"? it's just shortest form of smile) as you can see, i use it very often, so it's not bad optimization of my typig 2) hm... ok, then i will publish it's special for you) but it will be not very soon - now there're active phase of developing and i didn't refactor and code review yet --Jdev 12:10, 29 October 2009 (UTC)

Okay, I understand your point. But, maybe just me, when I see 'blah blah) blahblah) blah)' I would look before to find '('. But wonder, the '=' key is just two keys on the left of ')'.... Okay, I should s**t up about this. About the framework, if you want to see mine, just email me. (email on my use page) --Nat Pavasant 12:20, 29 October 2009 (UTC)

Okay, I understand your point=) yes, it's interesting for me. but i think, that it will be honestly, if i also show you my framework some time. may be i will not publish my code, but just email it's for you=) --Jdev 12:28, 29 October 2009 (UTC)

Last year i implement and discard 15 different guns (simple guns, genetics programming guns, random guns, PM guns, statistical guns, log based guns) and today start implement new one. Who implement more guns?:) it's so hard to "build the best, destroy the rest"...:) --Jdev 07:06, 17 March 2010 (UTC)

Hmm... well, in my early times Robocoding I implemented, 1) Head-on targeting, 2) Linear targeting, 3) Circular Targeting, 4) A crude pattern matcher, 5) a 'single-tick' pattern matcher as it's often termed, and 6) A rough attempt at using a hopfield neural net for a pattern matcher. None of those are in use anymore. More recently I've done, 7) RougeDC's DC-GF gun, 8) RougeDC's auxiliary PM targeting, 9) Some brief 'cluster tree' experiment that was never fit for real use, 10) A sort of targeting system in Polylunar to detect situations where a certain angle of fire is guaranteed to hit (falling back to I think linear when that gave no guarantee), 11) Antialiased/Interpolated VCS GF gun (aka SaphireEdge), and 12) Glacier's DC-PIF targeting. I think that's a full history of the targeting systems I've done over the years, the first half mostly being simple ones that I never kept. --Rednaxela 15:40, 17 March 2010 (UTC)


Also I have an idea about select gun for shot from guns array. But it was failed in my implementation and maybe anybody else will be more successive. Idea: you know, that gun has 10% hit rate, it's about one hit per ten shots. so, if gun wasn't hit in more than 10 shots, each miss will increment probability of hit with next shot, so you should select the gun, which have lowest hit rate in last time. i try to implement it, but i get little decrement of performance, while in theory it looks very good. --Jdev 20:44, 17 March 2010 (UTC)

I have thought about ways to account for the fluctuating nature of hit rates, but I think your idea is flawed. It sounds like Gambler's fallacy. I agree that VGs probably switch away from the better gun because of fluctuating hit rates all too often, but trying to adjust for that is not an easy task... --Voidious 21:12, 17 March 2010 (UTC)

Yes, against typical random movement, this is exactly the "Gambler's fallacy" which is why it doesn't work. One note is that this is not technically the gambler's fallacy against bots with non-'perceptual' movement, but except but against active flatteners or surfers probably has no chance of helping. Against active flatteners and surfers, I suspect there that attack the issues against them more directly instead of just happening to switch guns when the surfer doesn't expect it. ----

I'm not complectly agree. For example you have HOT and Circular guns. One will hit enemy in corners, while another in else situations. so if you hit by one gun some times, it's time to switch gun. But may be there're too much trivial example. Any way, i think that it's better to share an idea) --Jdev 07:53, 18 March 2010 (UTC)

If you're talking about against random movers, that IS the gambler's fallacy. If you're talking about bots with varied but non-random (or poorly randomized) movement, then yes it could work out in some scenarios but not because of why you said. If you flip a coin, and by luck get 'heads' 5 times in a row, your chance of getting 'tails' next is still 50/50, no higher. --Rednaxela 12:19, 18 March 2010 (UTC)


ok, let's it will be so - i'm not sure in it so much, to disput about it) --Jdev 12:53, 18 March 2010 (UTC)



hi to all. i have a bug in my radar code and cannot fix it. Code:

            LXXPoint enemyPos = lastUpdated.getPosition();
            double radarTurnDirection = signum(Utils.normalRelativeAngle((angleTo(enemyPos) - getRadarHeadingRadians())));
            if (Utils.isNear(radarTurnDirection, 0)) {
                radarTurnDirection = 1;
            }
            System.out.println("===========================");
            System.out.println("[DEBUG]: radar turn direction = " + radarTurnDirection);
            System.out.println("[DEBUG]: Angle to enemyPos = " + toDegrees(angleTo(enemyPos)));
            System.out.println("[DEBUG]: radar heading = " + toDegrees(getRadarHeadingRadians()));
            double radarTurnAngle = Utils.normalRelativeAngle((angleTo(enemyPos) + (Rules.RADAR_TURN_RATE_RADIANS / 2) * radarTurnDirection) -
                    getRadarHeadingRadians());
            System.out.println("[DEBUG]: radarTurnAngle = " + toDegrees(radarTurnAngle));
            if (abs(radarTurnAngle) > Rules.RADAR_TURN_RATE_RADIANS) {
                radarTurnAngle = Rules.RADAR_TURN_RATE_RADIANS * radarTurnDirection * 0.99;
                System.out.println("[DEBUG]: radarTurnAngle = " + toDegrees(radarTurnAngle));
            }
            setTurnRadarRightRadians(radarTurnAngle);

            lastRadarTurnDirection = (int) radarTurnDirection;

log:


===========================
radar turn direction = -1.0
Angle to p = 237.94483339133959
radar heading = 260.4730460891953
angle = -45.02821269785571
angle = -44.550000000000004 - turn radar on 44 degrees
===========================
radar turn direction = 1.0
Angle to p = 237.95354219349272
radar heading = 235.44087274677435 - but in fact 260.47304608919535 -  235.44087274677435 = 25 degrees
angle = 25.012669446718338

it seems like bug in robocode, but i think, if it was so, then this bug was already fixed.

Most part of time, this code works fine, but in rare and unknown envorinment it's produce log like upper.

Any suggestions?:) --Jdev 15:55, 8 June 2010 (UTC)

Just update --Jdev 16:49, 17 June 2010 (UTC)


Hm, sorry I didn't look at this close enough before but I think I see the problem. Robocode is behaving correctly, however one must realize that Rules.RADAR_TURN_RATE_RADIANS is the maxiumum radar turning rate relative to the gun turret, and the max gun turret rotation is relative to the body rotation. Even if you use setAdjustGunForRobotTurn(true) and setAdjustRadarForGunTurn(true), the maximum turn still depends on how much the gun and body are moving. One quick note, is to my knowledge very few bots take advantage of this. One of the few being my melee bot Glacier, which uses gun turning when not firing in order to boost how wide a radar arc it can make. --Rednaxela 19:30, 17 June 2010 (UTC)