Menu
▾
▴
#166 bots referencing robocode.robocodeGL broken
Many bots in the RoboRumble that always worked in the past no longer run in 1.7.0.2
They reference old robocodeGL things however don't require them to run, but Robocode now complains about the unused references. See errors like this:
vuen.Fractal: Got an error with this class: java.lang.ClassNotFoundException: robocode.robocodeGL.system.GLRenderer
Robots are not allowed to reference robocode engine in robocode.control or net.sf.robocode packages
No, robocodeGL is NOT old. Those bots (I think you refer to ClassisClay) bundled the GL into it. On standard robocode, it will not be activated. But, in older version of robocode it doesn't check the existent of classes but this version do. So, it isn't a bug but the right behavior.
One more thing, you SHOULD use 1.6.1.4 as a roborumble client as it is proven stable.
-- Nat
I think you're a little confused, bbeause RobocodeGL (http://davidalves.net/robocode/gl/) IS old, hasn't been maintained for years, and is furthermore made obselete by standard Robocode's drawing functionalities. As far as being a bug or not: This IS a bug, because checking those inactive classes plain isn't necessary and this change in behavior breaks a sizable number old bots.
Also Nat, I ALREADY know very well what versions are proven stable as a roborumble client; I have upload disabled in 1.7.0.2, and am simply testing so that we can actually have future versions work correctly. If nobody runs new versions to test with the rumble, we'll never have a properly working version of Robocode.
-- Rednaxela
I'm sorry, I think that you are some newbie to robocode playing around and just report a bug for fun! So that...
But I DON'T think RobocodeGL IS old because I'm sometimes using it. (sometimes do a thing with GL is simpler that SG) I think it is good to check for existent of classes. It provide more security. (although it sometimes confused me that a classes in same project but difference eclipse's source folder shown as non-exists)
Yeah, I'm very much not a newbie.
Actually, it really doesn't provide more security, checking as-needed is just as secure with how things are architectured. Thus I'd consider it a bug because it's a needless change of considerable incompatability.
P.S. Also, hm, insteresting that someone still uses robocodegl. As I understand, a large number number people that used to use it in their bots converted to the built-in drawing in robocode when that existed. Some things aren't as simple for some things yes, but as I understand most people found it more convient to make a little extra drawing framework than to keep multiple versions of robocode around, and actually, this change also makes it even more inconvient for those few who still use robocodegl like you.
I not use it as much as internal robocode graphics. I like to try thing so I try it. Many of thing on robowiki still use GL (like AGravEngineGL or HowToMakeNiceAimingGraphics). I'd once try RobocodeSG to understand what the checkbox labled 'Robocode SG' work :)
I don't think it should be called incompatability. On the GL page it say clearly that RobocodeGL is not compatible with robocode and need to remove in order to rum with robocode.
PS. I now know you aren't a newbie because you are Rednexela. But before, you are unknown qal21 to me!
Those old things on the robowiki that use GL were pretty much ALL made prior to robocode HAVING internal graphics capability I believe.
It worked with old versions of robocode, and it was widely used in that way, there's no true need to check the classes before they're called upon, thus it's an unnecessary incompatibility. It's one I'd consider a big deal too as it will break rumble rankings notably considering a fair number of high-profile high-ranking bots are among those that carry robocodeGL references, and some of which can't simply be re-packaged easily by anyone due to not all of them having source code included.
This is caused by better following all referenced libraries when loading robot into classloader. We can easily return back to shallow loading, but
1) robot packaging is dependent on list of referenced classes
2) potentially invalid robot would failed during battle, instead of during repository reload.
3) it was rather lack of security check than feature, I think
So guys, are the robots which are failing really that valuable. If yes, could we get them recompiled ?
Thanks
Pavel
Many of them are really I'd say. CassiusClay for instance is still 10th in the rumble and at once point was at the top, and a fair number of others are of ranking and/or historical significant I believe. I'll have to take another look at the list, but I think while most do have source avaliable to recompile from, some may not. I'll get back after I take a look at that.
Maybe you could even send email to authors and politely ask them to recompile or open sources.
I just tested pez.rumble.CassiusClay_1.9.9.70GL.jar, it is not running on Robocode 1.5.4. or any newer. So I think recompile of the robots is best solution to this "bug".
Anyway, what was expected fix ?
Shalow loading ? It would not help, because during battle it will be loaded and will cause security exception anyway. So, how it was working in old versions of robocode ?
I probably missed something.
pez.rumble.CassiusClay_2rho.01b.jar is what works in 1.6.1.4 and below. The version you're looking at is old. See:
http://www.dijitari.com/void/robocode/pez.rumble.CassiusClay_2rho.01b.jar
Thanks!
I fixed it for Robocode 1.7.1.
https://robocode.svn.sourceforge.net/svnroot/robocode/robocode/branches/repository-workspace/
It will no longer folow any referenced classes from robocode packages, so robocode.robocodeGL is skipped as well. It would not cause any security harm, because if the class is really resolved during run, it will throw then.
Shout to my email if you can't live with bug till 1.7.1 ;-)
Thanks for getting to it so promptly!
No immediate need, but just curious: what's the current status/timeline for 1.7.1?
The bugfix for this issue is available with the Robocode 1.7.1 Beta release.
Please verify that this issue has been properly solved.
Yep! Fixed in 1.7.1 Beta. Thanks.