Difference between revisions of "Talk:XanderFramework"
(→CircularGun section: new section) |
|||
(3 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
A ran a new test tonight on static data handling. Tonight it appears as though static variables are not shared -- as if each robot runs on it's own JVM. This is fascinating, as I sware I have had problems with this before, and I even ran a test not that long ago that seemed to confirm the issue. I will need to do more testing to fully understand what is going on. Maybe it was an issue for an older version of Robocode. Not sure. I will have to run more tests. [[User:Skotty|Skotty]] 05:10, 2 June 2011 (UTC) | A ran a new test tonight on static data handling. Tonight it appears as though static variables are not shared -- as if each robot runs on it's own JVM. This is fascinating, as I sware I have had problems with this before, and I even ran a test not that long ago that seemed to confirm the issue. I will need to do more testing to fully understand what is going on. Maybe it was an issue for an older version of Robocode. Not sure. I will have to run more tests. [[User:Skotty|Skotty]] 05:10, 2 June 2011 (UTC) | ||
+ | |||
+ | I suppose it's time to dig deeper into Java class loading. Not something I've ever had to dig too deep into in the past, but Robocode seems to be doing some strange things with it, presumably to isolate robots from each other. Again, I can sware I've seen static variable sharing problems before. The last version of Robocode I used before 1.7.x was 1.1.3 -- could that particular version have had some bugs related to this? (note: I tried version 1.0.7 and couldn't duplicate the issue; version 1.1.3 is not available for download, and I no longer have a copy of it on my system to try). If indeed Robocode manages to completely sandbox every robot, it would seem I have wasted a lot of time working on a problem that doesn't really exist. Robocode informational pages should state this upfront, as it is atypical behavior for a Java-based system. [[User:Skotty|Skotty]] 06:21, 2 June 2011 (UTC) | ||
+ | |||
+ | A little note on drives and guns in the Xander framework -- a CompoundDrive or a CompoundGun allow multiple drives or guns to be chosen between using a DriveSelector or GunSelector respectively. It should be noted that CompoundDrives or CompoundGuns can be nested. What this does is creates a decision tree, with CompoundDrives or CompoundGuns being the branches. This might look something like the following (and is the general plan for drives for XanderCat 3.2). (Although I don't show it in the example, a CompoundDrive or CompoundGun can have any number of drives or guns immediately below; it is not limited to only having two) | ||
+ | <pre> | ||
+ | __________________ | ||
+ | [ Compound Drive ] | ||
+ | [ ] | ||
+ | [ [Drive Selector] ] | ||
+ | [__________________] | ||
+ | ____________|____________ | ||
+ | ________|_________ ________|_________ | ||
+ | [ Ideal Position ] [ Compound Drive ] | ||
+ | [ Drive ] [ ] | ||
+ | [__________________] [ [Drive Selector] ] | ||
+ | [__________________] | ||
+ | ___________|____________ | ||
+ | ________|_________ ________|_________ | ||
+ | [ Anti-Mirror ] [ Stat Drive ] | ||
+ | [ Drive ] [ ] | ||
+ | [__________________] [__________________] | ||
+ | |||
+ | </pre> | ||
+ | |||
+ | == CircularGun section == | ||
+ | |||
+ | In reply to: | ||
+ | <blockquote> | ||
+ | ''One advantage this gun has over some other circular targeting implementations is that it works for circular paths that are centered anywhere, and is not limited to circular paths centered at the location bullet wave was fired from.'' | ||
+ | </blockquote> | ||
+ | |||
+ | I would say that is rather misleading, in that so far as I've seen over the years, I've never seen any targeting that claimed to be "circular targeting" that had the limitation you mention. I'm pretty sure "circular targeting" has always been defined in the Robocode community, very specifically, to be something that predicts a path where the enemy velocity and rate of turning remains constant. Anything besides that wouldn't be called "circular targeting" at all. | ||
+ | |||
+ | --[[User:Rednaxela|Rednaxela]] 23:30, 6 July 2011 (UTC) |
Latest revision as of 00:30, 7 July 2011
A ran a new test tonight on static data handling. Tonight it appears as though static variables are not shared -- as if each robot runs on it's own JVM. This is fascinating, as I sware I have had problems with this before, and I even ran a test not that long ago that seemed to confirm the issue. I will need to do more testing to fully understand what is going on. Maybe it was an issue for an older version of Robocode. Not sure. I will have to run more tests. Skotty 05:10, 2 June 2011 (UTC)
I suppose it's time to dig deeper into Java class loading. Not something I've ever had to dig too deep into in the past, but Robocode seems to be doing some strange things with it, presumably to isolate robots from each other. Again, I can sware I've seen static variable sharing problems before. The last version of Robocode I used before 1.7.x was 1.1.3 -- could that particular version have had some bugs related to this? (note: I tried version 1.0.7 and couldn't duplicate the issue; version 1.1.3 is not available for download, and I no longer have a copy of it on my system to try). If indeed Robocode manages to completely sandbox every robot, it would seem I have wasted a lot of time working on a problem that doesn't really exist. Robocode informational pages should state this upfront, as it is atypical behavior for a Java-based system. Skotty 06:21, 2 June 2011 (UTC)
A little note on drives and guns in the Xander framework -- a CompoundDrive or a CompoundGun allow multiple drives or guns to be chosen between using a DriveSelector or GunSelector respectively. It should be noted that CompoundDrives or CompoundGuns can be nested. What this does is creates a decision tree, with CompoundDrives or CompoundGuns being the branches. This might look something like the following (and is the general plan for drives for XanderCat 3.2). (Although I don't show it in the example, a CompoundDrive or CompoundGun can have any number of drives or guns immediately below; it is not limited to only having two)
__________________ [ Compound Drive ] [ ] [ [Drive Selector] ] [__________________] ____________|____________ ________|_________ ________|_________ [ Ideal Position ] [ Compound Drive ] [ Drive ] [ ] [__________________] [ [Drive Selector] ] [__________________] ___________|____________ ________|_________ ________|_________ [ Anti-Mirror ] [ Stat Drive ] [ Drive ] [ ] [__________________] [__________________]
CircularGun section
In reply to:
One advantage this gun has over some other circular targeting implementations is that it works for circular paths that are centered anywhere, and is not limited to circular paths centered at the location bullet wave was fired from.
I would say that is rather misleading, in that so far as I've seen over the years, I've never seen any targeting that claimed to be "circular targeting" that had the limitation you mention. I'm pretty sure "circular targeting" has always been defined in the Robocode community, very specifically, to be something that predicts a path where the enemy velocity and rate of turning remains constant. Anything besides that wouldn't be called "circular targeting" at all.
--Rednaxela 23:30, 6 July 2011 (UTC)