Why not LUA?
Moderator: Forum Moderators
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.
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.
-
- Retired Developer
- Posts: 1086
- Joined: September 16th, 2005, 5:44 am
- Location: Hamburg, Germany
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".
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".
Smart persons learn out of their mistakes, wise persons learn out of others mistakes!
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.
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.
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
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.
[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.SkeletonCrew wrote: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.
- Viliam
- Translator
- Posts: 1341
- Joined: January 30th, 2004, 11:07 am
- Location: Bratislava, Slovakia
- Contact:
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.CIB wrote:Sorry, I don't get you, you are describing a simple plaintext editor there.Viliam wrote: I tried to imagine some WML editor which could load existing scenario code (for example the mainline campaigns) and allow user editing it.
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]
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.)
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.allefant wrote: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: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).Code: Select all
if x == 1 then x = 2 end
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]
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
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.
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.
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:
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
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]
More details of how it works can be found here: http://code.google.com/p/silvertree/wik ... reeFormula
David
“At Gambling, the deadly sin is to mistake bad play for bad luck.” -- Ian Fleming
- irrevenant
- Moderator Emeritus
- Posts: 3692
- Joined: August 15th, 2005, 7:57 am
- Location: I'm all around you.
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?WML is better for storing wesnoth-related data.
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.
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.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 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.
Want to post a Wesnoth idea? Great! Read these:
Frequently Posted Ideas Thread
Giving your idea the best chance of acceptance
Frequently Posted Ideas Thread
Giving your idea the best chance of acceptance
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
Does this only allow C++ functions or also 'wml' defined functions?Dave wrote:It would be nice to make formulas easier in WML. While developing SilverTree, I developed a formula language that allows this.
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.
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.http://code.google.com/p/silvertree/wiki/SilverTreeFormula wrote:Certain SilverTreeWML attributes can contain formulas.
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)"
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]
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]
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
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]Jetryl wrote: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.
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.SkeletonCrew wrote:Does this only allow C++ functions or also 'wml' defined functions?Dave wrote:It would be nice to make formulas easier in WML. While developing SilverTree, I developed a formula language that allows this.
It probably wouldn't be all that hard to backport.SkeletonCrew wrote: 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.
I think it has to be in 'certain places'. in your example, $unit is only going to be valid in certain contexts.Sapient wrote: 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.
David
“At Gambling, the deadly sin is to mistake bad play for bad luck.” -- Ian Fleming
'certain places'Dave wrote:I think it has to be in 'certain places'. in your example, $unit is only going to be valid in certain contexts.Sapient wrote: 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.
David
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.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."