Skip to main content
Code Golf

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

8
  • \$\begingroup\$ If I remember correctly, you could get the classes via Wild.classes, since it's a static field... So you wouldn't have to update you wolf everytime a new wolf is posted here ;) \$\endgroup\$ Commented Apr 10, 2014 at 14:37
  • \$\begingroup\$ That's true. But I've done it this way now, probably going to leave it. May also remove some of the lesser-winning wolves from this multiwolf. The Wion seems to become extinct every time in my runs, I'm considering cutting it out from MultiWolf as I wonder if that's reducing the quality of the actions. \$\endgroup\$ Commented Apr 10, 2014 at 14:59
  • \$\begingroup\$ I believe that the rule "You may neither read from nor modify files created by another Wolf class" was intended to include the other wolf class files themselves. So I think that this entry, while an awesome idea, is against the rules. \$\endgroup\$ Commented Apr 10, 2014 at 15:05
  • 1
    \$\begingroup\$ @Runer112 I did wonder, but I've also learnt a bit from this about loading classes by name, and that there's no simple way to find all the classes in a package. Just a bit of fun \$\endgroup\$ Commented Apr 10, 2014 at 15:31
  • 3
    \$\begingroup\$ Instantiating another Wolf doesn't constitute reading or modifying files created by another Wolf, so this submission is legitimate. The rule was intended to protect data from submissions written in languages that don't have things like static variables and need to write to a file instead. \$\endgroup\$ Commented Apr 11, 2014 at 3:49