Why not LUA?

[allefant]

Problem with C++ is, it has to be compiled, so it's just not usable for this kind of scripting, and can't be compared to WML or Lua.

And I'd agree that even if it was possible to replace WML with Lua with only a reasonable amount of work, the difference would not be huge - you'd still have to learn the API to communicate with the main game, and still need something like the WML reference on the wiki to do anything much.

Scripts just would look nicer (at least to me), some things like the rather hackish macros would be handled in a proper way - and in cases where actual scripting with variable manipulation, conditionals, program flow and so on is involved, things would get much easier. Static data declarations on the other hand actually might get slightly harder or at least not change much at all.

[Yogibear]

Before i start: I never saw LUA, so if i say something stupid about it, that's why .

I think WML is a very good technical choice for creating scenarios, because it is much more easy to understand than a scripting language. Don't forget, the target group for this is not programmers, who already have the background to use a scripting language effectively.

However, allefant's example is very convincing. Even more: If this level of complexity is needed, you would have to start thinking like a programmer anyway. And then an archaic syntax is not much of a help, as all the programmers around here know well enough.

So, no, replacing WML completely with LUA is not a good thing in my opinion but finding replacements for the "programming script parts" (with LUA or a proprietary self made solution) would be of much help.

Then, if you want to get in touch with things, there is an easy way to do that. If you need more complexity, you will have to dive deeper into things and learn "the programmers way of scripted thinking".

[zookeeper]

I'll restate what I always do: sure, let's rather use LUA, but in another game, not in Wesnoth.

Trying to convert Wesnoth to use LUA instead of WML or to support both equally at this point would be like converting Wesnoth to an RTS. What's the point (let's assume for a moment that an RTS Wesnoth would be much cooler than the current Wesnoth), when you'd have to rewrite a third of the C++ code for that, not to mention the WML code? WML is clearly good enough for Wesnoth, considering the tasks the language needs to be able to perform. Just rather make a new game altogether if you want to tackle a project as big as replacing WML with LUA.

[SkeletonCrew]

I've been thinking about adding some scripting support to wesnoth as well especially for arithmetic it may be nice eg
[set_variable]
name = foo
script = "(2 * $bar) - 3"
[/set_variable]

or event
script = "$foo = (2 * $bar) - 3"

I think it should be possible to combine both WML and script support, personally I think WML is great to describe data structures but lacks when you want to do programming, it gets verbose quickly and thus a lot of macros are generated to reduce the amount of typing.

I have no experience in LUA as well so don't know whether it's good language.

[zookeeper]

I've been thinking about adding some scripting support to wesnoth as well especially for arithmetic it may be nice eg
[set_variable]
name = foo
script = "(2 * $bar) - 3"
[/set_variable]

or event
script = "$foo = (2 * $bar) - 3"

I think it should be possible to combine both WML and script support, personally I think WML is great to describe data structures but lacks when you want to do programming, it gets verbose quickly and thus a lot of macros are generated to reduce the amount of typing.

I have no experience in LUA as well so don't know whether it's good language.

Sure, it'd be great to have some support for arithmetic operations and stuff like that.

[Viliam]

I tried to imagine some WML editor which could load existing scenario code (for example the mainline campaigns) and allow user editing it.

Sorry, I don't get you, you are describing a simple plaintext editor there.

I think it would be nice to have an editor with more support. Like when you create a tag, it would automatically insert possible attributes, perhaps with some reasonable default values or comments. It could display tags that are possible sub-tags of the current tag. It could also provide a few templates, for example the normal day/night cycle. When adding a unit, it could dynamically list all available units, so that user does not have to memorize unit id's, and check for typos. Etc.

For example when you create a tag "[unit]", the editor could make this:

Code: Select all

[unit]
  x,y=1,1                 # coordinates where unit appears
  type=Footman            # unit type
  description=joe         # identifier of the unit
  user_description=_"Joe" # translatable name of the unit, visible to player
[unit]

I think that having a few templates like this could make game creating more convenient for beginners.

OK, this is pretty off-topic, but it is an example of thing that is difficult to do, because of the macro-heavy WML. (LUA is not necessary for this, some additions to language could fix this too.)

[Sapient]

WML:

Code: Select all

[if]
    [variable]
        name=x
        numerical_equals=1
    [/variable]
    [then]
        [set_variable]
            name=x
            value=2
        [/set_variable]
    [/then]
[/if]

Lua doing the same:

Code: Select all

if x == 1 then
    x = 2
end

To me it's clear which one is better. Someone who never programmed seing the WML would run away screaming - but the second one looks quite understandable (even though compared to Python, the "then" and especially the "end" seem somewhat redundant).

If a non-coder was trying to understand this LUA he might ask what does two equals signs next to each other mean? Why not leave off one equals sign there, or leave off the 'end', etc? I think we can become so accustomed to these common programming paradigms that we take them for granted. Certainly the WML is more verbose for certain tasks (such as variable assignment), but it is more self-describing.

Now if verbosity is the real problem here, and if macros are not the desired fix, then there could be support for something like:

Code: Select all

[script]
  language=LUA
  script="""
if x == 1 then
    x = 2
end
"""
[/script]

Being able to assign to one user variable in LUA more easily than in WML, doesn't prove that it would be a better language for authoring scenarios. Of course doing variable manipulations is easier in LUA. I'd like one of these LUA proponents to take the challenge and show us what an entire scenario would look like using only LUA.

[Jetrel]

WML is better for storing wesnoth-related data. It's been specifically designed to have syntax that is optimal for that, and very readable for that. For example, in an entire unit file, we've got little-to-no use for a function. About the only thing in a whole unit file would be conditionals and macros.

The conditionals are handled in the animation code; I'm not really sure how, there are a number of different possibilities, but the key thing is that all the actual conditionals are (in a way), pre-provided by the animation C++. It knows the full gamut of possibilities, and only needs to handle those. If we actually used some scripting language to govern the drawing; actually executing the conditional in the scripting language, every time we did a draw cycle ... well, that would be preposterous, from a performance standpoint.

As for the macros (such as, say, the defense animations), in my limited knowledge, there really isn't a better solution for that kind of problem (self-generating code) than macros. LISP uses macros for the same kind of "saving code by abstracting away redundancy, and allowing you to do global changes to those things rapidly". That's one of the reasons it kicks butt, and to tell a funny secret, WML is actually what helped me 'grok' that language feature of LISP.


So, some of the only places we need functions are places where we're altering state, or when we need some simple computation done. We pretty much only do that when events happen in a campaign. "When X happens, do Y" -> "When unit walks onto tile X, do Y". "do Y" could be a function. It would be useful as one if similar actions were frequently performed.


The point is that our need/use for functions in WML is smaller, perhaps by an order of magnitude, than our need to use WML as a data storage markup. And for the data storage purpose, it kicks ass, IMHO. I think we should certainly continue using WML for all our data storage. Whether we consider using something else as a script language we can call to use functions when doing campaigns, etc - that's a different concern.

[Dave]

WML isn't really designed to be a programming language. It's a data language that allows you to configure many aspects of Wesnoth.

WML does have a few programming constructs to give it the power it needs where necessary.

It would be nice to make formulas easier in WML. While developing SilverTree, I developed a formula language that allows this. For instance, an 'if' statement in SilverTree looks like this:

Code: Select all

[if]
condition=gold > 100
  [then]
    ...blah blah blah...
  [/then]
[/if]

I think it'd be nice to 'backport' this system to Wesnoth.

More details of how it works can be found here: http://code.google.com/p/silvertree/wik ... reeFormula

David

[irrevenant]

WML is better for storing wesnoth-related data.

I'd be interested to know if this is true. Certainly, WML is well-suited to storing Wesnoth data but Wesnoth data consists of standard data forms: strings, integers, booleans etc. Wouldn't most languages handle those elegantly in something like the <object>.<parameter>=<value> format?

This is genuinely a question, I honestly don't know. I'm particularly unfamiliar with LUA.

It sounds like WML is slowly being converted to have more programming features anyway. My question would be: if you're going to end up with a programming language anyway are you better off ending up with a standard one that many people are already familiar with, or is the implementation cost too high?

Again, this is genuinely a question.

The point is that our need/use for functions in WML is smaller, perhaps by an order of magnitude, than our need to use WML as a data storage markup.

I suspect this is a self-fulfilling prophecy. There's a fair amount of ideas discussed in the WML forum that aren't implemented because they can't be. If more powerful functions were available in WML, IMO they'd get used.

I guess this again comes back to: Is WML really a better way to store Wesnoth data than the data structures of existing languages? It would seem more elegant to use the same language for both if there isn't a benefit to WML for the data storage.

[SkeletonCrew]

It would be nice to make formulas easier in WML. While developing SilverTree, I developed a formula language that allows this.

Does this only allow C++ functions or also 'wml' defined functions?

I looked at the wiki and I really like what you with this formula language and would like to get it in Wesnoth as well. Would be nice to get it in before the feature freeze or otherwise for 1.5.

[Sapient]

Certain SilverTreeWML attributes can contain formulas.

I don't feel good about the word "certain" there. With a rapidly evolving language like WML, we really don't want another hodge-podge situation where in some places formulas work, and in other places they don't.

I agree with ESR from an earlier #irc discussion that a perloid syntax would be better for in-line functions which could then be used anywhere variable substitution is allowed.

For example:

Code: Select all

   value= _ "$if($unit.level > 1,Veteran,Youth)"

And for WML functions, I agree that eventually it would be nice to allow WML authors to define their own tags without knowing C++.

This could be something like:

Code: Select all

[set_function]
  id=side_kill
  [default]
   target_side=1
  [/default]
  [command]
    [kill]
      side=$param.target_side
      animate=yes
      fire_event=no
    [/kill]
  [/command]
[/set_function]

...

[side_kill]
  target_side=2
[/side_kill]

or for the ambitious LUA proponents...

Code: Select all

[set_function]
  id=side_kill
  [default]
   target_side=1
  [/default]
  [command]
   [lua]
    kill_cfg = config()
    kill_cfg["side"] = param.target_side
    kill_cfg["fire_event"] = "no"
    kill_cfg["animate"] = "yes"
    fire_event("kill", kill_cfg)
    clear_variable("kill_cfg")
   [/lua]
  [/command]
[/set_function]

...

[side_kill]
  target_side=2
[/side_kill]

[CIB]

It knows the full gamut of possibilities, and only needs to handle those. If we actually used some scripting language to govern the drawing; actually executing the conditional in the scripting language, every time we did a draw cycle ... well, that would be preposterous, from a performance standpoint.

On big and complex scenarios, the engine having all the possibilities at hand is not neccessarely something good. And a scripting language that just creates static WML would be useful, too. The preprocessor isn't that good to save you work and make the thing more readable, either. It only has a very limited condition handling that can't interact with WML at all. It can't manipulate text, it can only duplicate it, which is a big flaw.[/code]

[Dave]

It would be nice to make formulas easier in WML. While developing SilverTree, I developed a formula language that allows this.

Does this only allow C++ functions or also 'wml' defined functions?

At the moment it only allows builtin functions (i.e. functions defined in C++), however being able to define functions in the formula language itself is planned.

I looked at the wiki and I really like what you with this formula language and would like to get it in Wesnoth as well. Would be nice to get it in before the feature freeze or otherwise for 1.5.

It probably wouldn't be all that hard to backport.

I don't feel good about the word "certain" there. With a rapidly evolving language like WML, we really don't want another hodge-podge situation where in some places formulas work, and in other places they don't.

I think it has to be in 'certain places'. in your example, $unit is only going to be valid in certain contexts.

David

[Sapient]

I don't feel good about the word "certain" there. With a rapidly evolving language like WML, we really don't want another hodge-podge situation where in some places formulas work, and in other places they don't.

I think it has to be in 'certain places'. in your example, $unit is only going to be valid in certain contexts.

David

'certain places'

Perhaps I should clarify my statement. I think formulas should be valid everywhere variable substitution is valid, which in Wesnoth version 1.3 means every tag encountered inside an [event], with the exception of [set_variable] literal=.

(BTW, $unit is valid inside any event as well)

To do otherwise would invite confusion and inconsistency, much like the confusion and inconsistency surrounding variable interpolation in Wesnoth version 1.2 and lower.

proposed syntax

My primary objection to the proposed syntax was this: using syntax if() instead of $if() would invite ambiguity when formulas are supported across wide varieties of text value situations.

While the simple constraint of comma separators can also be seen as a limitation on versatility, such limitations are not easily avoided without resorting to escape characters. However, in the case of undecorated keywords as function names, there appears to be no great benefit which corresponds to the loss of versatility.