ModdedBot/Chat

Feel free to ask any questions you'd like.

Shouldn't it extend TeamRobot? -- Kawigi

If your mod requires team functionality, then it should extend TeamRobot; in that case you can just change it to make it extend it. If your mod doesn't require team functionality though, you don't need to extend AdvancedRobot; course it's probably a good idea to change it that way anyway, since you don't lose anything by going AdvancedRobot... Ah well. -- Vuen

Vuen did you receive my email about the problems with this code ? (handling events). Check the new RobocodeDeathMatch for a solution. Unfortunatly, the solutions found is not a solution for Coop (since you need to use RobotPeer? peer). The basic idea is to directly act on the EventManager? and it work. -- Synnalagma

What's the problem? I've noticed a minor problem that ScannedRobotEvent etc. don't have a constructor for making one based on another event, so you have to separate all the bits first. -- Tango

Oh, crap... I see what you mean... See I never found this to be an issue before, because none of my bots ever use any blocking calls in the events. I wonder if someone here can help me resolve this issue. Here's a copy of Synnalagma's email:

Hi,
There's  a problem in your code and I don't know how to handle it correctly. 
You have an infinite recursivity if the bot is calling execute() in any 
onXXX(event) (for exemple in on ScannedRobot()). This is not important since 
you your bot will do it fine (you are calling execute). But after a while 
you will have a StackOverflowError this mean the recursivity is getting too 
long.  Why ?
Here is the schema :
I call execute() //we never return from this method
           dump()
               in onSannedRobot (wich is called from dump()) I call 
execute()
                   execute()
                      dump()
                          .......
Hope you understood. After a while the stack containing the recursivity is 
too large wich cause a StackOverflowError.

This won't appear all the time since the round  could end before this appear 
but it appear many time on my computer. Try it by having a bot that just 
call execute() in onScannedRobot and dont fire and a bot that just move 
around.

The good news is that it work fine to be informed about any event but not to 
modify or dispatch them.

Synnalagma

Anybody have any clue how to fix this?

-- Vuen

Could this be as a result of the pariorities of other events. If the event you defined has a higher pariority than others probably it will not run the other events, so it always calls the same event which may cause the recursivenes. Just a guess. --SSO

No, this has nothing to do with priority. The problem is that the overriden execute tells it to call onScannedRobot again, so it gets stuck between the event and the call to execute. I just also realized however that setInterruptible() is also broken. The thing I just don't get is, this same recursivity should occur with regular bots, but it doesn't; suppose you have a bot that calls setTurnRadarRight(Double.POSITIVE_INFINITY) in run, then in onScanned robot calls setInterruptible(true), setTurnRadarLeft(getRadarTurnRemaining?), and scan(). In theory it should crash the same way with AdvancedRobot, but it doesn't. That means Robocode does something funky to drop down the stack before recalling onScannedRobot. I'll run a few tests with setInterruptible, and then I'll crack open RobotPeer? to see how Robocode does it. However I don't have time to do this now, and I really wanted to get Fractal's new gun working soon. It may take me a week or two before I get around this; in the meantime, see if you can advise people not to use execute(), scan(), and doNothing() in events, and to replace fire and fireBullet with the equivalent set methods. The rest of the blocking calls should probably not return enough to overflow the stack. I'm very close to an update with Fractal, so let me just get an update out and then I'll see what I can do with this recursivity problem. -- Vuen

I've just had a look at RobotPeer? and EventManager? and can't see how to fix your bug, however i have found out why FireAssist? works on AdvancedRobots?. My java isn't great, but i think if classA extends classB which extends classC then classA is an instance of classC, yes? EventManager? has the statement "getRobot() instance of Robot", when it should probably have "!(getRobot() instance of AdvancedRobot)". Does that sound right? -- Tango

Yup, that's right. -- Vuen

---

Okay guys, ModdedBot 1.1 released. The infinite recursivity bug is now fixed. This means that my patented state-of-the-art StackOverflowBot? now runs properly with version 1.1:

package sample;
import robocode.*;

public class StackOverflowBot extends mod.ModdedBot {
    
    public void run() {
        setTurnRadarRight(Double.POSITIVE_INFINITY);
    }
    
    public void onScannedRobot(ScannedRobotEvent e) {
        setInterruptible(true);
        setFire(0.1);
        turnRadarLeft(getRadarTurnRemaining());
    }
    
}

This no longer produces a stack overflow. Furthermore, all prioritization functions now work properly. In version 1.0, all events could simply interrupt all other events. With 1.1, prioritization and event interruption is handled the same way as Robocode, now making pretty much all robots compatible with ModdedBot. Robots that depend on event interruption now function properly. It also makes the event dumping code a lot harder to understand; it was difficult to build, and I'm quite sick of trying to be the JVM. It looks a lot like what you would find in robocode's EventManager?, except it's commented, so you can understand what's going on. If you have created a mod with ModdedBot, please update it to this version of ModdedBot to allow prioritization-dependant robots to use your mod. And if something goes horribly wrong and it doesn't work, please let me know!

-- Vuen