[wesnoth-commits] [wesnoth/wesnoth] 783dc0: more modifiable attributes to lua units
GitHub
noreply at github.com
Sat Oct 27 15:48:29 UTC 2018
Branch: refs/heads/master
Home: https://github.com/wesnoth/wesnoth
Commit: 783dc0767b8072cde9666c85eb124f969e0e8d17
https://github.com/wesnoth/wesnoth/commit/783dc0767b8072cde9666c85eb124f969e0e8d17
Author: gfgtdf <daniel.gfgtdf at gmail.com>
Date: 2018-10-27 (Sat, 27 Oct 2018)
Changed paths:
M src/scripting/lua_unit.cpp
M src/units/unit.cpp
M src/units/unit.hpp
Log Message:
-----------
more modifiable attributes to lua units
Commit: cc5aac7009f68584e1c05e23674fc10097495e42
https://github.com/wesnoth/wesnoth/commit/cc5aac7009f68584e1c05e23674fc10097495e42
Author: gfgtdf <daniel.gfgtdf at gmail.com>
Date: 2018-10-27 (Sat, 27 Oct 2018)
Changed paths:
M src/units/unit.cpp
Log Message:
-----------
replace impossible check with assert.
since we refactored gamestate construction to initialize units last, it is no longer possible that resources::filter_con is a nullptr here.
Commit: e634198a5e9d509da148392b45d4d48d2e240d65
https://github.com/wesnoth/wesnoth/commit/e634198a5e9d509da148392b45d4d48d2e240d65
Author: gfgtdf <daniel.gfgtdf at gmail.com>
Date: 2018-10-27 (Sat, 27 Oct 2018)
Changed paths:
M src/units/filter.cpp
M src/units/filter.hpp
Log Message:
-----------
make unit filters a little more safe against nullptr access.
Commit: 71118875351ac903f1f5e6454c5d8cf12f1c2109
https://github.com/wesnoth/wesnoth/commit/71118875351ac903f1f5e6454c5d8cf12f1c2109
Author: gfgtdf <daniel.gfgtdf at gmail.com>
Date: 2018-10-27 (Sat, 27 Oct 2018)
Changed paths:
M src/units/unit.cpp
Log Message:
-----------
[unit] moves=-1 no longer removes attacks
there is no reason why it should, also this behaviour was not documented.
Commit: 6c696cd127619886959cdb7b4ee7d0084638244e
https://github.com/wesnoth/wesnoth/commit/6c696cd127619886959cdb7b4ee7d0084638244e
Author: gfgtdf <daniel.gfgtdf at gmail.com>
Date: 2018-10-27 (Sat, 27 Oct 2018)
Changed paths:
M src/units/unit.cpp
Log Message:
-----------
experience modifer no longer applies to [effect]
now experience_modifer only changes the unit types xp, it no
longer has an effect on [effect]s that change xp, in particular
it fixes #1796 where a apply_to,increase=max_experience,2 [effect]
added one or two max_experience to a unit dependend on how much
max_experience it had before. This was in particular a problem
because this effect would only behave like this during unit
construction, not when an object is added ([object]).
Compare: https://github.com/wesnoth/wesnoth/compare/d94069798704...6c696cd12761
**NOTE:** This service has been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/
Functionality will be removed from GitHub.com on January 31st, 2019.
More information about the Commits
mailing list