#114 RateControlRobot vs. TeamRobot

[Martin Pedersen]

At present you must choose between them. Can you do one of the following?

1. Make RateControlRobot extend TeamRobot instead of AdvancedRobot
2. Move all functionality from TeamRobot into AdvancedRobot, expanding the AdvancedRobot interface and leaving TeamRobot an empty subclass (for backwards compatibility)

[Alexander Schultz]

I can't remember where, but I saw this issue brought up before and the thought was that #1 was the solution, plus there were other deficiencies/oddities in RateControlRobot that needed fixing

[Nat Pavasant]

It's at http://robowiki.net/wiki/User:Positive/Optimal_Velocity

[Pavel Šavara]

User could always extend advanced robot and implement ITeamRobot and ITeamEvents. Should we make interfaces enabled by enabled by default now ?

[Alexander Schultz]

I'd like the interfaces to be enabled by default, they make much more logical sense to me to use than the inheritance (though I personally won't start using it in my bots until robocode versions not supporting the interfaces are fully phased out of rumble usage)

[Martin Pedersen]

Implementing interfaces does not provide access to TeamRobots methods:
String [] getTeammates() or
void sendMessage( String, Serializable )

.. unless I'm missing something ..

[Pavel Šavara]

see how they are implemented in TeamRobot and you will understand.

[Nat Pavasant]

I believe you have to use it via TeamRobotPeer, as all other functions too if you just implement interface and not the Robot/AdvancedRobot class

[Martin Pedersen]

Pavel, I do not see how TeamRobot's implementation through access to TeamRobotPeer is applicable to a tank developer extending RateControlRobot.

Do I have access to that peer? I have yet to find a means of accessing it.

[Martin Pedersen]

If Pavel was talking about altering the Robocode source code, rather than trying to work around the issue as a tank developer, then it makes more sense to me, my not being a developer on the Robocode project aside.

[Alexander Schultz]

The way to create a robot using interfaces as opposed to extending a robot class is by implementing the setPeer() method. http://robocode.sourceforge.net/docs/robocode/robocode/robotinterfaces/IBasicRobot.html#setPeer(robocode.robotinterfaces.peer.IBasicRobotPeer)

One stores the value received from the robocode engine calling setPeer(). Now... one just needs to remember that if you override setPeer() in an AdvancedRobot instead of a pure-interface, you also have to call super.setPeer() to pass the peer up the chain.

Anyway, using interfaces is something I think should be done, but I don't consider that the solution to this bug report, and that RateControlRobot does need to be fixed in various ways.

[Flemming N. Larsen]

I agree that we should let the RateControlRobot extend the TeamRobot so it will be able to participate in team battles as well as regular battles.

However, this has been reported as a bug. It is not a bug. It is a change request. So please put change requests into the feature request page next time. ;-)

[Pavel Šavara]

Martin, you are right that it is not possible to same time extend AdvancedRobot and ITeamRobot . Because setPeer is final and peer field is package internal.

It seems we didn't designed interfaces to be used together with base robots. Should we support such usage ?

[Alexander Schultz]

Personally, my view is that such usage isn't particularly important, since I'd imagine most times a bot would want to use such interfaces it would want to purely use interfaces. The big use-case for the interfaces I personally see, is making cleaner bot frameworks for non-codesize-restricted bots. I believe I'm not alone in a tendency to in large bots make a bot framework, that really makes much of what AdvancedRobot does redundant , and for such frameworks the interfaces make a much cleaner API. I honestly don't see why one would want to mix extending AdvancedRobot with implementing ITeamRobot, except as a hackish workaround for a "TeamRateControlRobot"

On the other hand, I personally don't see any real harm in making setPeer non-final so that people can get the peer when working when extending the existing classes.

[Flemming N. Larsen]

In the coming version 1.7.2.0, the RateControlRobot changed to inherite from the TeamRobot so it can participate in team battles.

[Flemming N. Larsen]

This feature has been implemented in version 1.7.2.0 Beta. Please verify that this feature works as expected.

[SourceForge Robot]

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).