Talk:ReferenceWMLDump

Kernigh wrote:

Since Wesnoth 1.1.5, all simple substitution was eliminated in favor of complex substitution, which is more versatile.

There is no source for this claim, and my tests contradict it: In wesnoth 1.2.5, the WML snippet

			{VARIABLE foo_bar 42}
			{VARIABLE b bar}
			[gold]
				side=1
				amount=$foo_$b
			[/gold]

does nothing, but

			{VARIABLE foo_bar 42}
			{VARIABLE b bar}
			{VARIABLE_OP temp format $foo_$b}
			[gold]
				side=1
				amount=$temp
			[/gold]

adds 42 gold to side 1. I have therefore reverted the edit. Please only change the content of this page if you are sure you are right.

Meriton 15:25, 15 July 2007 (CEST)

In the source file wesnoth-1.2.5/changelog, under the section for "Wesnoth 1.1.5", it states, "all [event] tags shall perform complex substitution".

Further, the following example passes wesnoth 1.2.5, and at least demonstrates that the [allow_recruit]type= key permits complex substitution:

			# works in 1.2.5
			[event]
				name=start
				{VARIABLE title "Sharpshooter"}
				{VARIABLE name title}
				[allow_recruit]
					type="Elvish $$name||"
					side=1
				[/allow_recruit]
			[/event]

When I made a copy of 2p - Blitz with this event, side 1 was able to recruit Elvish Sharpshooters.

To show why your test failed, I suggest that "$foo_$b" is not a valid complex suggestion. (I do not know why "$foo_$b" does not work; maybe there is a bug in 1.2.5, or I misunderstand how complex substitution works.)

But if this is not a valid expression, how can it be correctly interpreted by [set_variable]format=, which after all does complex substitution, too? Meriton 22:17, 15 July 2007 (CEST)

The wiki page claims that [message]message= allows complex substitution, so I extended your example to be:

			{VARIABLE foo_bar 42}
			{VARIABLE b bar}
			[gold]
				side=2
				amount=$foo_$b
				# broken in 1.2.5
			[/gold]

			[message]
				speaker=narrator
				message=$foo_$b
				# broken in 1.2.5
			[/message]

When I tested this, side 2 failed to gain 42 gold, and the message box can up with an empty message! --Kernigh 16:35, 15 July 2007 (CEST)

There is a bug with complex substitution in the stable branch; it the value starts with '$' as the very first character then it will (sometimes) switch back to simple substitution. This bug was fixed by eliminating simple substitution in the development branch. As a workaround, you can put a space as the first charatcer in the message, like this: message=" $foo_$b". --unsigned talk from Sapient

I have to admit that my previous claim (" Since Wesnoth 1.1.5, all simple substitution was eliminated in favor of complex substitution, which is more versatile.") was incorrect, because of the above description of how Wesnoth sometimes does "switch back to simple substitution". --Kernigh 22:00, 15 July 2007 (CEST)

Let me see if I got this right: In theory, all attributes that perform any substitution perform complex substitution, but due to a bug, complex substitution sometimes does simple substitution instead. We therefore tell users that only simple substitution is performed in the stable branch, because that is the only thing that is guaranteed to work. Meriton 22:17, 15 July 2007 (CEST)

Incorrect. I suggest you disregard Kernigh's statement, because it is misleading and false. There is still *lots* of simple substitution in the stable branch. (Including the bug with complex substitution sometimes reverting to simple substitution when the first character is '$'). If you are doing anything complex with WML you should be using the development branch because many improvements have been made. --Sapient

Ok, thanks for the clarification. --Meriton

Substitution mode of [set_variable]value= in stable branch

In the forums, governor claimed

{VARIABLE var1 $var2.xxxx} is valid.

which desugars to

[set_variable]
    name=var1
    value=$var2.xxxx
[/set_variable]

I tested this in 1.2.5 with the code

{VARIABLE foo bar}
{VARIABLE test $foo}

Inspection of the save file revealed that "test" had been set to "bar".

What is the substitution mode for [set_variable]value= in the current stable branch?