URL:
<http://gna.org/bugs/?14832>
Summary: strange new preprocessor behaviour
Project: Battle for Wesnoth
Submitted by: anonymissimus
Submitted on: Dienstag 24.11.2009 um 01:23
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: WML
Status: None
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release: 1.7.8
Operating System: WinXP
_______________________________________________________
Details:
This is a macro that was working perfectly in 1.6:
#define DK_UNIT_RESET VARIABLE
{VARIABLE {VARIABLE}.hitpoints ${VARIABLE}.max_hitpoints}
{VARIABLE {VARIABLE}.status.poisoned no}
{VARIABLE {VARIABLE}.status.slowed no}
{VARIABLE {VARIABLE}.moves ${VARIABLE}.max_moves}
{VARIABLE {VARIABLE}.attacks_left ${VARIABLE}.max_attacks}
#enddef
...
[store_unit]
variable=u_Kalenz
[filter]
id=Kalenz
[/filter]
kill=yes
[/store_unit]
...
{DK_UNIT_RESET u_Kalenz}
...
This macro causes a missing closing sign in 1.7.8 - the third line of the 5
{VARIABLE ...s in the macro definition is enough. Substituting the {VARIABLE
... with [set_variable]...solves the preprocessor error. Substituting the
name of the macro argument VARIABLE (and according calls to it) with
VARIABLE_NAME solves the error, too.
I don't know whether I should call this report a feature request or a
complaint about a syntax change - if it is too much trouble to fix then I'd
be happy with renaming the macro argument. But a note about it should be
added to the wiki, "macro arguments overwrite macro definitions of the same
name (or vice versa)" - if that is what's happening here...
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?14832>
_______________________________________________
Nachricht geschickt von/durch Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
