Why not LUA?

[Prog-ramix]

Im just wondering why wesnoth doesn't use LUA scripts instead of WML?
In my opinion is LUA much better then WML.

[CIB]

Im just wondering why wesnoth doesn't use LUA scripts instead of WML?

Because WML is a specialized language made for Wesnoth, LUA isn't? Implementing a high-level scripting language for scenario creating has been suggested before, but no dev seems to think that it's worth it.

The WML syntax is so easy that you probably can learn it in one day if you're familiar with other scripting languages.

[zookeeper]

Im just wondering why wesnoth doesn't use LUA scripts instead of WML?

No particular reason.

In my opinion is LUA much better then WML.

Probably not many would disagree with you.

[Weeksy]

I think it would probably be a fair amount of work. It could prove very useful, but you're faced with two options, both of which would have problems:

1. Have both LUA and WML support, which would probably slow the engine down a fair amount.

2. Have just LUA support, which would mean rewriting of all mainline/UMC content, including the terrain system, all mainline units, and all campaigns, and so on.

[CIB]

1. Have both LUA and WML support, which would probably slow the engine down a fair amount.

If there is no LUA code, how can it slow down the engine? If there is lua code, you could have functions instead of macros getting expanded to 1.000.000 lines.

[Sapient]

Could someone please explain all the merits of LUA over WML?

I'd like to see a line item for each improvement that you feel LUA offers over WML, rather than just a blanket "it's better" statement.

Also, please explain how non-coders will be expected to use it when creating their user made campaigns.

For example, there is a claim that the syntax would be cleaner.

In LUA, I presume all strings would need to be surrounded by quotes and all attributes would be set by function calls; so, instead of writing key=value, would you write set_key("value")
And for translateable strings, it would be set_key(_("value"))
That doesn't seem very advantageous to me.

One nice thing would be the ability to do mathematical manipulation inside expressions. There are ways this could be added to WML, too; probably the only reason it hasn't been added yet is because how often do you need to do advanced arithmetic for ScenarioWML ? WML features are added as they are needed. To program a Wesnoth scenario, you probably don't need access to sinusoidal, exponential, or logarithmic calculations. If you did, it could be added.

Another problem is that some of the limitations of WML are intentional. The C++ code could become very unstable if WML were allowed to change any variable at any time.

All in all, I am not convinced. Why would a general purpose scripting language be better for writing Wesnoth scenarios than WML, a language designed specifically for writing Wesnoth scenarios? You have to back up your claim.

[Boucman]

I've looked into LUA already, it's clearly a better language than WML, I won't go deep into it, let's just say that LUA is a real programming language with loops, scoping, functions... everything

the problem is that WML is so deeply intermixed with the code that it's impossible to have it removed, and adding the LUA engine is far from trivial

As usual, if somebody does it, it has fairly good chances to be included, just like python was...

however it hasn't hapenned yet

[turin]

I've looked into LUA already, it's clearly a better language than WML, I won't go deep into it, let's just say that LUA is a real programming language with loops, scoping, functions... everything

So? There's a difference between being a more powerful language and being a better choice for a particular purpose... one of WML's benefits is the ease of learning it; a more complex and powerful language would probably be worse in that department.

[Sapient]

I've looked into LUA already, it's clearly a better language than WML

That's like saying that a shovel is better than a spoon; it just depends on what you want to do with it.

I won't go deep into it

Please do go deeper... it is beneficial for us to find out areas where WML is really lacking, then we can brainstorm about the best fixes, which may or may not involve total conversions of the entire language's syntax.

loops- wesnoth has loops; is your point that it only has [while] loops? please explain.

scoping- wesnoth has event scoping in the form of auto-stored variables ($unit, $this_unit, and $second_unit) and also container variables can be used as variable scopes. Eventually, the event variables $x1, $y1, $x2, and $y2 should be converted to use the autostores so that they will also be scoped. Other than scoping of autostored variables at the event level, or inside containers, it is probably best to use the global scope to avoid confusion. Remember the target user base here.

functions- WML doesn't need to support functions because things which would actually require the use of a function are converted into tags that are understood by the language. We have taken the design approach that if a function would really be useful to WML authors, then it should be integrated into the language so that users who don't understand functions can use it the same way they use every other WML feature. They don't have to learn a new syntax.

As usual, if somebody does it, it has fairly good chances to be included, just like python was...

however it hasn't hapenned yet

I'm still not convinced that LUA would be better for authoring Wesnoth scenarios than WML.

[Viliam]

I would like to see the LUA too, but... well, removing something that works right now and replacing it with some vague idea, that's not a good move. So I recommend this for everyone who proposes LUA -- start working on it. Make a more specific proposal how exactly should data be presented in LUA. Write an example translation of one campaign scenario, of unit definition, etc. Give something specific, not just general statements. And then we can discuss if the specific proposal in LUA is "better" than current implementation in WML -- if it fixes some problems without introducing other problems of comparable size.

In my opinion the worst part of WML is its macro abuse. Macros are used in places where constant, reference, or function call would be more appropriate. (But this can be fixed in WML, it is not argument for switching to other language.) I tried to imagine some WML editor which could load existing scenario code (for example the mainline campaigns) and allow user editing it -- but because the use of macros, such program would be extremely difficult (if you want it to preserve the existing macro calls, and allow user to use existing macros).

[CIB]

functions- WML doesn't need to support functions because things which would actually require the use of a function are converted into tags that are understood by the language. We have taken the design approach that if a function would really be useful to WML authors, then it should be integrated into the language so that users who don't understand functions can use it the same way they use every other WML feature.

In that case, what are all those "Can already be done"-sayers doing here? It should be "Yes, you are right, we must include a new tag that does what you want in a more simple way!"..

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.

[Sapient]

functions- WML doesn't need to support functions because things which would actually require the use of a function are converted into tags that are understood by the language. We have taken the design approach that if a function would really be useful to WML authors, then it should be integrated into the language so that users who don't understand functions can use it the same way they use every other WML feature.

In that case, what are all those "Can already be done"-sayers doing here? It should be "Yes, you are right, we must include a new tag that does what you want in a more simple way!"..

I'm sure they mean well, but in many cases where a big ugly solution is required, there could and should be a new WML tag which performs the difficult and awkward parts of the problem.

In other cases, it really just doesn't seem like something useful to other WML authors or no one has gotten around to coding the tag yet.

[CIB]

In other cases, it really just doesn't seem like something useful to other WML authors or no one has gotten around to coding the tag yet.

For those cases functions would be useful IMO.

[allefant]

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).

[Mist]

Allefant, but going in this direction why not give people direct C++ input? Would save us the need for parser, all redundancy would be gone in an instant an the code wouldn't get bloated at all. Just call respective functions behind the WML. It would be sllek, fast, well optimised, unconstrained and so on. But at the same time impossible to debug, open to abuse and completely unreadable to someone without coding background. WML has it's limitations (some of them annoying) but it's a safe, easy to learn, and easy to maintain wraper for using C++ functions.