Added fighters seem to appear late

Bug #58678 reported by Jonathan Lange
2
Affects Status Importance Assigned to Milestone
Joybot
Fix Committed
Medium
Unassigned

Bug Description

The final "!next" should say *** giant *** (next up bear)

[23:23] joybot jml: SEG 3 *** iratsu *** (next up metagnome)
[23:23] jml !add bear dex=15 spd=3
[23:23] joybot jml: bear enters combat
[23:24] jml !next
[23:24] joybot jml: SEG 4 *** metagnome *** (next up giant)
[23:26] jml !next
[23:26] joybot jml: SEG 4 *** giant *** (next up RAOF)

Jonathan Lange (jml)
Changed in joybot:
importance: Untriaged → Medium
status: Unconfirmed → Confirmed
Revision history for this message
Chris Halse Rogers (raof) wrote :

Fixed in branch add-latecomer-58678

Changed in joybot:
status: Confirmed → Fix Committed
Revision history for this message
Jonathan Lange (jml) wrote :

Belated review!

_actorsInSegment looks like it's going in the right direction, however there are a few points.

As always, details first:
* If _actors() is only going to be called by getActors(), then it should just become getActors().
* The clearest way to convert an iterable to a list is list(i). In quite a few tests you do [a for a in i], which is less clear.
* It's not clear why _actors() is changed to order actors by DEX. It's as good an ordering as any other, I guess.
* test__actorOrdering should be renamed test_actorOrdering.

Some more significant things:
* "actors in segment" and "actors in phase" are synonymous concepts in HERO. That we have two methods _actorsInSegment and _actorsInPhases bodes ill.
* + for dex in xrange(self._calcMaxDEX(segment), 0, -1):
  + for actor in self._actorsAtPhaseAndDEX(segment, dex):
  This seems to be a cumbersome way of saying "for actor in self._actorsInPhase(segment)". I understand that we want to be getting a fresh list of actors at each DEX. I can't help but think there should be a nicer way. Regardless, this should be explained in a comment.

Things to think about, not actually related to the code under review:
* Combat should probably be an actual iterator.
* Perhaps our thinking about Combat is backwards (or something). Maybe Combat should have event generators instead of actors. Each event source would have a DEX at which it should be polled for events. Then, for each phase, Combat would loop through the list of registered DEXs, and for each DEX, randomly loop through the event generators for that DEX, telling it the segment. Not entirely dissimilar to what's going on in this branch, but I think it would look simpler.

Probably we should talk :)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.