Difference between revisions of "User talk:Skotty"

From Robowiki
Jump to navigation Jump to search
(Thoughts on exploits)
Line 48: Line 48:
 
*Specially [[Diamond]] is nice with its feature to turn on/off gun and movement graphics separately during battle (radar graphics does not show anything I think). That's something I definitely want to do too, because enabeling the graphics in the .ini file is just too much trouble. [[Tigger]] would be the first tank to have graphics, as stefw was the one who developed the possibility. --[[User:GrubbmGait|GrubbmGait]] 00:05, 11 June 2011 (UTC)
 
*Specially [[Diamond]] is nice with its feature to turn on/off gun and movement graphics separately during battle (radar graphics does not show anything I think). That's something I definitely want to do too, because enabeling the graphics in the .ini file is just too much trouble. [[Tigger]] would be the first tank to have graphics, as stefw was the one who developed the possibility. --[[User:GrubbmGait|GrubbmGait]] 00:05, 11 June 2011 (UTC)
 
** Radar (unless I broke it) shows last known location of each bot. In 1v1 this isn't very visible, but in Melee you can see the squares. And thanks. =) [[User:KID|KID]]'s [[User:KID/DrawMenu|menu system]] sounds a lot sleeker though! --[[User:Voidious|Voidious]] 00:21, 11 June 2011 (UTC)
 
** Radar (unless I broke it) shows last known location of each bot. In 1v1 this isn't very visible, but in Melee you can see the squares. And thanks. =) [[User:KID|KID]]'s [[User:KID/DrawMenu|menu system]] sounds a lot sleeker though! --[[User:Voidious|Voidious]] 00:21, 11 June 2011 (UTC)
 +
 +
== Bug Exploits -- What's Fair, What's Not? ==
 +
 +
Thought I would share my thoughts on bug exploits, and see if anyone else cares to share their thoughts as well.
 +
 +
In my opinion, anything that attempts to exploit bugs or vulnerabilities in the Robocode engine itself is unfair, as it is '''not''' in line with the intent of Robocode.  However, anything that attempts to exploit vulnerabilties in other robots is fair, and very much in line with the intent of Robocode.
 +
 +
The one case I see as debatable is whether or not it is fair to exploit bugs in other robots.  I would categorize this in two flavors -- generic exploits, and targeted exploits.  ''General'' being an across-the-board attempt to exploit a common bug, and ''targeted'' being based on recognizing individual robot names.  I think both are fair and acceptable practice, as opponents are always welcome to update their robots to correct them.
 +
 +
Does anyone disagree with this assessment?  What are your thoughts?

Revision as of 18:09, 27 June 2011

I Hate Wall Avoidance

I hate it with a passion. I'm still trying to come up with an elegant solution. Since one of my main drive strategies is "orbital", I'm now toying with the idea of moving my orbit target to avoid hitting the wall, rather than trying to adjust orbit path separately. Though I'd prefer a solution that works regardless of drive strategy.

I still have a lot of work to get my drives working well in general. However, I may have to stop playing Robocode again soon. Too many other things I need to get done...

Have you tried Wall_Smoothing ? If you are not wave surfing, you will probably also want to have some explicit Dive_Protection . If you are having trouble implementing those elegantly I would suggest you take a look at the Wave_Surfing_Tutorial) --AW 21:37, 31 May 2011 (UTC)

Packaging Source Files

At the moment, my robot XanderCat is not packaged with source. This is fine, since the Xander framework is not entirely complete yet. Though when I am ready to package with source, I'm not sure how I will do it. I use Eclipse for development. I can add the bin directory under the developer options to run my robot while it is under development. But when I go to package it in Robocode, I'm not sure there is any way to tell it where the src folder is. I could also just check to see what all Robocode is putting into the jar files, and write my own Ant built script. Or I might just provide the source as a seperate download from the wiki page. Thoughts?

I'd also like to point out that not packaging your source doesn't necessarily keep people from checking out your code. Class files can be decompiled. Just a thought...

I too use Eclipse for development, and have never had trouble with packaging the source code. I have options -> preferences : development options set to my ...\workspace\robots\ directory which contains my ...\src\ and ...\bin\ directories, then I can package my robots in robot -> package robot for upload; this dialogue contains an "include source" check box (enabled by default). --AW 23:21, 27 May 2011 (UTC)

The preference dialogue on development options, it says that "If you are using Eclipse, you can enter the root dir of robot project inside robot workspace as well (recommend)". Robocode is able to parse Eclipse's project file to get /src and /bin dir (multiple source dir is also supported I think). That way the source code will be packed. --Nat Pavasant 02:43, 28 May 2011 (UTC) PS. I am the one who requested this feature. Before that, I have to either put the source in the jar myself (via WinRAR) or set output directory to /src

Ah...okay. I did not follow that it would automatically check for /src and /bin folders. Skotty 21:32, 31 May 2011 (UTC)

Rant on Lost Form Submissions

Bitten by poor web application design again. After having to pause one of my edits to take care of another matter, I returned a bit later, finished my edit, and submitted it. However, my session had timed out. Much to my surprise, MediaWiki did not preserve my edit. I thought MediaWiki was classier than that.

It is a newbie web developer mistake to have a web application lose someones edit due to a session timeout. The proper action is to save the edited data, give the user a chance to log back in, and then apply the edit or return them to the edit page without losing the edit. I'm often surprised at how many web applications exhibit this glaring flaw...so many, that I almost consider it my own mistake for not copying the text to notepad before submitting. But it is not my own mistake. It's the web application's mistake. A mistake that I am really growing tired of seeing again and again and again...


Eh? I have never had session timeout with MediaWiki. Are you sure it is really session timeout? I know for the fact that MediaWiki use token cookie for authentication. BTW, I know Chrome preserve form data on 'Back' button. I don't know about other browsers, but I think they do too.

On completely unrelated note, I found that FanFiction.net authentication system more frustrating: if I checked "Remember me for one day", it remember exactly one day i.e. if I start edit on 23.58 and finish on 24.01 hours after my login, my edit will be gone :( --Nat Pavasant 12:51, 27 May 2011 (UTC)

Robocode Bug

I like to print out some stats after each round, but I've been running into a problem. I may be limited to printing to the console. If I win, I get an Win event and a RoundEnded event. But if I lose, it appears as though I get no events. However, it may just be that the console dies before all events are fired/processed. Is that the case? It would be a pain to have to write results to a file every time. I'm running Robocode 1.7.2.2.

In my test, I do a System.out.println in each of the event methods on my main robot class (onWin, onRoundEnded, onDeath), but I only see them when I win. Thoughts? Skotty 21:39, 8 June 2011 (UTC)

I just figured it out. It happens when the main window is minimized. The events are always fired, but they can only print to the console if the main window is not minimized. Annoying, but I can live with it. Skotty 22:01, 8 June 2011 (UTC)
Certainly sounds like a bug - you should always get them, and I'm pretty sure it worked in the past, even when minimized. I have onWin and onDeath both calling a common method (maybe onRoundEnded didn't exist at some point). --Voidious 23:03, 8 June 2011 (UTC)

Painting on the Battlefield

I have been using the painting ability in Robocode to a large degree lately. It's great for debugging, and it's just plain cool. I have quite a few painting features built into XanderCat and the Xander framework now. I left them enabled in XanderCat 3.4, and I have even more cool stuff that can be turned on for XanderCat 3.5 (mostly gun stuff).

Who else out there is using the painting ability of Robocode? Are there any interesting robots to check out? Do you use it for your own bots? Skotty 15:20, 10 June 2011 (UTC)

Off the top of my head: Diamond (gun gfx need an udpate though), Phoenix (one of my favs, and one of the first to make really nice graphics), Shadow, Glacier (other Rednaxela bots?), DrussGT, GresSuffurd. Well, that should get you started. There are lots more though. Maybe Google: graphics site:robowiki.net would yield a more exhaustive list. =) --Voidious 16:24, 10 June 2011 (UTC)

  • Specially Diamond is nice with its feature to turn on/off gun and movement graphics separately during battle (radar graphics does not show anything I think). That's something I definitely want to do too, because enabeling the graphics in the .ini file is just too much trouble. Tigger would be the first tank to have graphics, as stefw was the one who developed the possibility. --GrubbmGait 00:05, 11 June 2011 (UTC)
    • Radar (unless I broke it) shows last known location of each bot. In 1v1 this isn't very visible, but in Melee you can see the squares. And thanks. =) KID's menu system sounds a lot sleeker though! --Voidious 00:21, 11 June 2011 (UTC)

Bug Exploits -- What's Fair, What's Not?

Thought I would share my thoughts on bug exploits, and see if anyone else cares to share their thoughts as well.

In my opinion, anything that attempts to exploit bugs or vulnerabilities in the Robocode engine itself is unfair, as it is not in line with the intent of Robocode. However, anything that attempts to exploit vulnerabilties in other robots is fair, and very much in line with the intent of Robocode.

The one case I see as debatable is whether or not it is fair to exploit bugs in other robots. I would categorize this in two flavors -- generic exploits, and targeted exploits. General being an across-the-board attempt to exploit a common bug, and targeted being based on recognizing individual robot names. I think both are fair and acceptable practice, as opponents are always welcome to update their robots to correct them.

Does anyone disagree with this assessment? What are your thoughts?