[Commits] [wesnoth/wesnoth] 4e79ae: use unsyced rng for animation&sound stuff

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/wesnoth/wesnoth
  Commit: 4e79aedb8de8b4739b174cd430489e3e6025376d
      https://github.com/wesnoth/wesnoth/commit/4e79aedb8de8b4739b174cd430489e3e6025376d
  Author: gfgtdf <daniel.gfgtdf at gmail.com>
  Date:   2017-10-29 (Sun, 29 Oct 2017)

  Changed paths:
    M src/display.cpp
    M src/play_controller.cpp
    M src/server/user_handler.cpp
    M src/sound.cpp
    M src/soundsource.cpp
    M src/units/animation.cpp
    M src/units/animation_component.cpp

  Log Message:
  -----------
  use unsyced rng for animation&sound stuff


  Commit: 3763f5a759abbda701e4604164b228113824f305
      https://github.com/wesnoth/wesnoth/commit/3763f5a759abbda701e4604164b228113824f305
  Author: gfgtdf <daniel.gfgtdf at gmail.com>
  Date:   2017-10-29 (Sun, 29 Oct 2017)

  Changed paths:
    M src/units/unit.cpp

  Log Message:
  -----------
  use unsynced rng for unit traits

this has 2 reasons:
1) In the 'unit::unit(const unit_type& u_type ..' ctor the facting is
usually overwritten after the unit is constructed (at least the normal
unit recruit code does that) so calling the synced rng there has no
other effect than blocking undoing (in case that the unit has no traits,
otherwise undoing would already be imposible because of trait
generation)

2) in the 'unit::unit(const config& cfg ...' ctor it might make sense to
use the synced rng, but since iirc the facing attribute is already
unsynced since it changed by the drawing code (which might be skipped if
animations are disabled) we also use the unsyced rng here to not block
undoing (in that rare case).


Compare: https://github.com/wesnoth/wesnoth/compare/07c0af34f6d2...3763f5a759ab