Rewriting macros as tags

[Luther]

I'd like to go through all the mainline macros that can be used in events and rewrite them in Lua as action tags. I think tags are easier to read than macros, and Lua makes it easy to replace them. I'd like some feedback as to how I might approach this project. I could do one of the following things:

• Try to get it into mainline. If I do this, I'll have to focus on 1.9 rather than 1.8.
• Try to get it into Wesnoth Lua Pack.
• Make it my own separate add-on. This would mean I can use my own coding convention, so I can use spaces for indentation.

I understand that if I choose one of the first two options, I'll probably have to make an add-on so people can see what I'm doing.

Obviously, some macros don't use action tags, so they can't be converted. I also will not convert macros like SET_OBJECTIVES, UNIT, and VARIABLE, where the tag provided by the engine does the job I want to do.

After that, I can maybe do the same thing with FrankenWML.

So what do you think? Would there be enough interest to get this into mainline?

[zookeeper]

There's definitely some macros which should IMO be converted to lua tags, but nowhere near all. Lua code is still harder to read and understand than WML, so maintaining the macros/tags is inevitably a bit harder if they're written in lua rather than WML, because far fewer people know lua, whereas WML is usually pretty easy to understand.

The things I'd most like to see would be a [modify_unit] tag:

Code: Select all

[modify_unit]
    [filter]
        id=Konrad
    [/filter]

    hitpoints=12 # sets unit.HP to 12
    moves=0 # sets unit.moves to 0

    [status]
        poisoned=yes # sets unit.status.poisoned to yes
    [/status]
[/modify_unit]

Also, a [move_unit] tag to replace the MOVE_UNIT macro would be nice.

So, I'm sure I'd gladly put tags like these in mainline. Commonly used macros like MODIFY_UNIT or MOVE_UNIT which have a reasonably complicated implementation are a good idea to convert to tags, but I don't want to overdo it and start converting all simple action-WML-containing macros to tags.

[Sapient]

Well, modify_unit as I had envisioned it was also smart enough to handle unit_type advancements correctly (by setting type= attribute), the use of percent notations, self reference via $this_unit, etc.

But, that version would be a good starting point I guess.

[Anonymissimus]

(I'm always impressed by the ambitiousness of people announcing what they're gonna do in the wesnoth forum...)
If you want to get them mainline'd submit them as patches.

Hm, my add-on features a custom modify_unit tag with syntax

Code: Select all

{VARIABLE some_var experience}
[modify_unit]
 	side,canrecruit=1,yes
 	variables=$some_var|,status.petrified
 	values=1,yes
 [/modify_unit]

intended to provide backwards compatibility

Code: Select all

#ifdef MODIFY_UNIT
#undef MODIFY_UNIT
#endif
#define MODIFY_UNIT FILTER VARIABLES VALUES
	[modify_unit]
		{FILTER}
		variables={VARIABLES}
		values={VALUES}
	[/modify_unit]
#enddef

There's one in the lua pack but I'm afraid its author has disappeared and it also isn't "good code" imo.

[Luther]

Wow, good response! Here's my plan so far: I'll start by making an add-on for 1.9. I'll also try to maintain a version for 1.8. If I need to make patches, I'll copy stuff from the add-on. I'll work on the more complex macros first, as Zookeeper suggested, since they're more in demand. I'll also consider everyone's suggestions for [modify_unit] when I get to that.

There's definitely some macros which should IMO be converted to lua tags, but nowhere near all. Lua code is still harder to read and understand than WML, so maintaining the macros/tags is inevitably a bit harder if they're written in lua rather than WML, because far fewer people know lua, whereas WML is usually pretty easy to understand.

I would think Lua would be easier to maintain than WML because it's more flexible. Also, I found it much easier to learn Lua than WML. Maybe my programmer brain is more accepting of procedural/object-oriented languages than markup.

[zookeeper]

Wow, good response! Here's my plan so far: I'll start by making an add-on for 1.9. I'll also try to maintain a version for 1.8. If I need to make patches, I'll copy stuff from the add-on. I'll work on the more complex macros first, as Zookeeper suggested, since they're more in demand.

I think the first thing to do when considering whether a macro should be turned into a lua tag is to grep for the macro in all the mainline campaigns and see how much it's really used. If there's a complicated macro which is used in just a couple of places, then I don't think it's worth the trouble. However, if it's used a lot (like MOVE_UNIT and MODIFY_UNIT) then it sounds like a good idea.

There's definitely some macros which should IMO be converted to lua tags, but nowhere near all. Lua code is still harder to read and understand than WML, so maintaining the macros/tags is inevitably a bit harder if they're written in lua rather than WML, because far fewer people know lua, whereas WML is usually pretty easy to understand.

I would think Lua would be easier to maintain than WML because it's more flexible. Also, I found it much easier to learn Lua than WML. Maybe my programmer brain is more accepting of procedural/object-oriented languages than markup.

Well, sure, I guess it's a matter of what one is used to. However, do note that a lot of WML authors don't know lua; when you convert a WML macro to a lua tag, the burden of maintenance partially shifts from the people who know WML to the people who know lua. For example, I can easily fix problems in WML macros or revise and extend them when needed, but I don't know lua enough to locate subtle bugs in other peoples' code; if MOVE_UNIT breaks, I can fix it, but if [move_unit] breaks, someone else has to do it.

Of course, one could argue that there's currently more developers who know lua well than developers who know WML well. It might be the case or it might not, I don't really know.

[Luther]

If you want to get them mainline'd submit them as patches.

I forgot to ask earlier: Do I have to submit each tag as a separate patch?

Also, any tips on how to test new tags as I write them?

And BTW, I also want to work on some of the tags in FutureWML.

[Anonymissimus]

I forgot to ask earlier: Do I have to submit each tag as a separate patch?

I'd do.

I've submitted a patch for modify_unit, I hope you weren't working on it...

Also, any tips on how to test new tags as I write them?

If you need to ask, how are you going to write new tags then... ?
e.g.:

Spoiler:

Code: Select all

	[event]
		name=turn 2
		{VARIABLE some_value yes}
		[modify_unit]
			[filter]
				side=1
				[not]
					canrecruit=yes
				[/not]
			[/filter]
			hitpoints=1
			experience=10
			[status]
				poisoned=$some_value
				petrified=yes
			[/status]
		[/modify_unit]
	[/event]
	[event]
		name=turn 3
		[modify_unit]
		[/modify_unit]
	[/event]
	[event]
		name=turn 4
		[modify_unit]
			[filter]
				side=1
			[/filter]
		[/modify_unit]
	[/event]
	[event]
		name=turn 5
		[modify_unit]
			[filter]
				side=1
			[/filter]
			[portrait]
				image=""
			[/portrait]
		[/modify_unit]
	[/event]

[Luther]

I've submitted a patch for modify_unit, I hope you weren't working on it...

I've looked into modify_unit, and it looks like the hardest part would be deciding exactly how this tag should behave. The examples I've seen imply that the user's code should simply overwrite what's already in the unit. That's fine, but if you want really robust behavior, you're going to need some more complex syntax. We'll have to make a decision on this to make sure we're on the same page. Here's the complex version as I envision it:

• To avoid name conflicts, [modify_unit] should not take arbitrary code at its top level.
• [filter] Standard unit filter.
• remove_keys= Takes a comma-separated list of keys to be deleted.
• [add_wml] Any keys of this tag are written directly to the unit. Any subtags are appended to the unit as-is.
• [remove_tag] Removes entire tags from the unit.
  • name= Name of the tag(s) to be removed. If omitted, tags of any name may be removed.
  • index= The number of a specific subtag to remove, with the first one being 0. If 'name' is provided, it will only count through tags of that name.
  • [filter_wml] Only tags matching this filter will be removed.
• [modify_tag] Takes the same key and subtags as [modify_unit] (except [filter] becomes [filter_wml]), and recursively modifies the subtags. Also takes name= and index= keys as in [remove_tag].

That looks rather monstrous to me, but it all depends on what kind of features you guys want.

Also, any tips on how to test new tags as I write them?

If you need to ask, how are you going to write new tags then... ?

I had to ask because any tag that takes arbitrary code is bound to have more test cases than I can think of off the top of my head.

[Sapient]

no, [set_variables] should be used for the class of modifications you described above as "arbitrary"; stored units, on the other hand, have many well-defined attributes and are organized in what is certainly a non-arbitrary structure.

[Luther]

I was under the impression that WML authors can add whatever data they want to a unit. Is there something else I need to read up on?

[AI]

Arbitrary data was only allowed inside the [variables] tag, but this wasn't enforced. Now, it is.

[Pentarctagon]

the FOREACH/NEXT macros would be one of the best candidates to rewrite into a single tag since it would be both easy to do and is probably one of the 'worst looking' macros.

[Anonymissimus]

My mind is twisted while trying to envision what it would look like. You expect to deliver an arbitrary code block, the body wml, to be executed as an argument to a function; I doubt it's possible. It's rather a case where you should actually use a macro instead of a function.

[Sapient]

Maybe something like this?

Code: Select all

[foreach]
  array=stored_units
  index=i # default i,j,k...

  [if]
   [variable]
     name=$stored_units[$i].race
     not_equals=spartan
   [/variable]
   [then]
     [continue]
       # skip to next iteration
     [/continue]
   [/then]
  [/if]
  [message]
    id=$stored_units[$i].id
    message="This is SPARTA!!!"
  [/message]
  [break]
    # terminate loop
  [/break]
[/foreach]