Tron 3.11 seems broken in current Robocode/Java versions?

Jump to navigation Jump to search

Tron 3.11 seems broken in current Robocode/Java versions?

I'm unsure why, but I'm noticing that Tron 3.11 is currently broken under Robocode and OpenJDK 11. It seems to always start up in "Reference" or "Challenge" mode, never in "Normal" mode. This is the reason for Tron's recent underperformance against updated/new rumble entrants. Need to figure out the cause of this. There's a good chance this could point to a regression in Robocode.

UPDATE: Confirmed that Tron is working fine in and, but not in Robocode This is unfortunate and I doubt Tron is truly the only bot affected.

Rednaxela (talk)04:47, 19 June 2021

Looks like there's some incompatible change in the logic of robot name in, and anything depend on that is broken to some degree. This frequently happens to bots with Team capacity.

Xor (talk)09:23, 19 June 2021
Edited by author.
Last edit: 09:57, 19 June 2021

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:Talk:Tron/Tron 3.11 seems broken in current Robocode/Java versions?/reply (2).

I've ran some tests and confirmed that Tron's change in behaviour seems to be a rather troublesome side-effect of the change in what getName() returns.

To confirm this, I repackaged Tron with " (1)" added to it's version field, and it misbehaved in even in, in the same manner the regular version misbehaves in

It's rather strange that " (1)" appended to the end of getName() causes problems for Tron, because neither "*" appended nor " (1)*" appended does.

Considering this further, I believe the most likely thing is that ABC was using the result of getName() specifically to detect the special case of multiple instances of Tron versus itself, to behave in a special way for development purposes in that scenario.

Most team bots used the suffix to determine a "leader"? Curious. Most teams I spent time looking at either did not have an explicit leader, or were using a different bot class for that.

In any case, this change in what getName() returns really breaks too many things in my opinion.

Rednaxela (talk)09:48, 19 June 2021

I am using the bot name suffix to determine the position of current bot in the team, as well as switching colors. Not remembering where did I see someone using similar tricks. Anyway anything like this now breaks.

Xor (talk)09:54, 19 June 2021

I'm very strongly of the opinion the change to what getName() returns should be reversed. Even if the new numbering is used for display or internals, it just breaks too much to return to bots in getName(). It seems there are too many historic bots that are broken even in 1v1, that are more or less infeasible to update, and we may never really be certain if we've found all of them that may be affected. It's very possible some changes in bot behavior may not be immediately obvious.

Rednaxela (talk)10:03, 19 June 2021

I agree. Having looked at the code in ScalarR, when determining colors, it assumed no suffix for 1v1, and corresponding suffix in teams. The change in bot name breaks its color but nothing else, but no one can be sure some bots are changing other behaviors depending on the name suffix. It's not feasible to monitor which bot is partially broken.

Xor (talk)10:07, 19 June 2021