 |
Forums |
Admin  Start New Thread
By: sox box
 RE: patch: big refactoring [ reply ]
2005-12-16 23:56
|
|
You are right. I shoud have looked into that a bit more. It seems to me it would be better to change it. Other than LinearShooter and SniperDuck, the only other bots to use this were mine, which used it incorrectly.
|
By: sox box
RE: patch: big refactoring [ reply ]
2005-12-16 04:12
|
I think I found a bug in the new code. The event['got_hit'] returns the robots remaining energy instead of the damage caused by the bullet. I think this is inconsistant with previous versions, and doesn't make a lot of sense. I think this was a simple oversight.
Just relized you now have this code in the main rrobots. The above code is still useful to keep the robots backwards compatable.
|
By: sox box
RE: patch: big refactoring [ reply ]
2005-12-15 23:38
|
The initialize thing only cost me an hour or so trying to figure out why it wasn't taking my newest bot. For anyone that is interested, this is what I did in DuckBill05 to make it compatable with both the regular rrobots, and the tourney versions.
def initialize *bf
if bf.size != 0
super(bf[0])
@tourney = false
else
super
@tourney = true
end
<<rest of init code>>
end
To do the victory dance at the end ( only in the tourny version) I do the following
@mode = victoryDance if @tourney and game_over
This prevents a check of the undefined game_over when run under regular rrobots.
I can't complain to much about the extra work to get my bot to work, because the abstraction from the battle feild is a step in the right direction. I would like to see this adopted in the mainline code.
|
By: Simon Kröger
RE: patch: big refactoring [ reply ]
2005-12-15 23:22
|
Well, i realy hope we didn't screwed this release up. All your changes are in the 0.4.0 release (rather untouched).
This breaks some robots, but only those that had a initialize method with parameter. This should be easy to fix.
Would you post your robots to the tracker (and link them in the forum) for reference?
Thanks again!
|
By: Ilmari Heikkinen
patch: big refactoring [ reply ]
2005-12-11 00:03
|
http://rubyforge.org/tracker/index.php?func=detail&aid=2995&group_id=1109&atid=4361
I basically tried to split the functionality into parts that would make future additions painless. There's a big changelog on the patch page.
Some stupidities seeped in though: the battlefield should call srand on the first tick, then put the robots to the middle of the bf, and use robot.teleport to send them to random positions. Also, the draw_robot/explosions/bullets-methods of TkArena could be further split into make_robot + configure_robot, etc. The #state-methods may not return all the state you'd need to create replay files (dunno).
Anyhow, thoughts? Too big and invasive for one change? Design mistakes? Overengineering :?
|
|
|
