#415 Loading pre-loaded data 1.9.4.2

[Rednaxela]

Noticed a big problem that was introduced between 1.9.4.1 and 1.9.4.2. Having robots read data that was pre-loaded in their JAR file no longer works correctly, at least in some cases.

I noticed this with Tron, because it depends on checking robots/.data/abc/tron3/Tron.data/Tron.properties
for configuration of what mode it's in, and it's always running in the wrong mode by default now.

Tron is closed source so can't easily debug it, but pretty sure this is what's happening. I'll see if I can get a simple test case made to add to this ticket soon. This is a pretty severe issue as it is tainting some rumble results, and I'm sure not just for Tron.

[Rednaxela]

So I made a quick little simple test bot (ags.bugs.ShouldBeGreen 1.0), to see if it reproduced what was going wrong for Tron, by bundling a properties file in the robot data directory, and reading it. If it works right, the test bot is green, but if it fails the bot will be red. Turns out green however even in 1.9.4.2, so whatever is going wrong with Tron is a little bit different somehow.

I wonder if maybe Tron was using it's own name in some fashion, but if it was it was already stripping the version off so it's not entirely clear how (1) would break it. Something thing is definitely going wrong with Tron though, causing it to not behave in accordance with it's packaged properties file.

(As an aside, it seems to me like the "Include data files" checkbox in the robot packager might not be working these days? It didn't seem to when I tried so I had to manually patch it into the JAR file)

[Rednaxela]

Tron's change in behaviour seems to be a consequence of the change in what getName() returns. As a test I repackaged Tron with (1) added to it's version field, and it exhibited the same behaviour in 1.9.4.2, when in 1.9.4.1. See the attached abc.tron3.Tron_3.11_T.jar for a repackaged copy of Tron that misbehaves even in 1.9.4.1.

[Rednaxela]

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

I was hearing from Xor on a wiki thread that there are also some teams out there that look for (1) to assign one bot to be leader. Most teams I looked at in the past didn't do this (either no leader or used a different class), but apparently some did.

In my opinion, the change to what getName() returns really breaks far too many things.

[Flemming N. Larsen]

Hi Rednaxela, and thank you for your effort in analyzing this issue. 👍

If 1.9.4.2 causes a problem for the rumble, the rumble should stick to 1.9.4.1 for the time being.

Fixing getName() is not easy. It was changed in 1.9.4.2 to fix an issue that other competitions using team robots (not the rumble). And getName() has been fixed many times before, e.g. with the hide-names feature the way the robot DB/cache works. So it will be very hard to figure out a solution that will work for all without breaking something else.

It is also really hard to improve Robocode (e.g. upgrade to new Java versions), and at the same time keep compatible with bots that are never updated, and using getName() in a way that it was not meant for. Even harder, when the robot sources are not available.

In this case, it is not clear to me what needs to be fixed to solve the problem. Rolling back the last bugfix for getName() gives other problems that need to be fixed, which is not easy to handle in a good way either.

[Rednaxela]

Unfortunately, sticking to 1.9.4.1 isn't an option for the rumble either, at least for Teamrumble/Twinduel, because as of 1.9.4.1 getTeammates/isTeammate are very broken, and are relied upon heavily. It could be modified of course but I don't think the current version of literumble supports setting different required versions for the different leagues either, so short-term options are likely either:
- stick to 1.9.4.2 for now until there's a fix, temporarily removing bots it's known to affect (which may not be comprehensive, it could be hard to discern more subtle impacts) from the participants list for the time being
- or go to 1.9.4.1 for the time being and don't run Teamrumble/Twinduel for the time being.

It's rather unfortunate that some bots relied on getName() in a way that was not meant to be relied upon, but at the same time bot authors had their reasons for wanting to detect some configurations of multiple of their own bot in a battle and that was definitely the path of least resistance to accomplish that, such that some historic bots came to rely upon it. I don't imagine it was ever thought at the time that (n) numbering would ever be for any purpose besides avoiding duplicate names, and for accomplishing that goal alone the way it was certainly was the most intuitive way for it to be.

Yeah, it certainly seems that the best way to get compatible getName() behavior is not going to be so simple as rolling back the last bugfix. An appropriate solution will probably need some careful consideration as well as unit tests that ensure no regressions. I might see about looking into the internals myself some time soon.

[Rednaxela]

Posted a possible fix for compatible getName() behaviour while also avoiding risk of bugs akin to in the past:
https://github.com/robo-code/robocode/pull/58