Difference between revisions of "SoC2011 Student Page Aethaeryn"

From The Battle for Wesnoth Wiki
(Phase 0: The Initial Changes: expanding the explanation)
m (Hide historical references to Subversion from the wiki search function)
(19 intermediate revisions by 2 users not shown)
Line 8: Line 8:
  
 
==IRC==
 
==IRC==
Aethaeryn
+
Aethaeryn, Aeth
  
 
==Introduction==
 
==Introduction==
Line 37: Line 37:
  
 
===Phase 1: Complex Interface Changes===
 
===Phase 1: Complex Interface Changes===
 +
<!-- fixme: rewrite in the style of the two phases and expand -->
 +
''Note: This section is outdated, I know, but I have to get to it after I actually write the wesnoth.gui_message{} function so I get a feel for the C API and how much time is necessary to do these tasks. I'm probably going to have to add at least two more weeks worth of work on top of what I originally intended.
 +
 
* Implement improved Lua access to the in-scenario GUI stuff, again without WML table hacks.
 
* Implement improved Lua access to the in-scenario GUI stuff, again without WML table hacks.
 
** This includes improving the syntax and implementation of the [http://wiki.wesnoth.org/LuaWML:Display#wesnoth.show_dialog dialog Lua].
 
** This includes improving the syntax and implementation of the [http://wiki.wesnoth.org/LuaWML:Display#wesnoth.show_dialog dialog Lua].
Line 47: Line 50:
  
 
==The Implementation: Details==
 
==The Implementation: Details==
''I'm sleeping. This section will be filled out when I can think again.
+
<!-- expand -->
  
 
===Phase 0===
 
===Phase 0===
 +
The goal of this phase is to implement similar behavior in Lua to important UI-related WML tags so that these elements can be used in Lua without WML tables, thus eliminating clumsy syntax and ensuring complete implementation. Currently, certain parts, including [option], require clumsy workarounds when implemented in WML tables due to the nature of the tag. This also sets the stage for the later phases by establishing a starting point for more complex feature additions.
 +
 
====Sample Syntax====
 
====Sample Syntax====
  local msg = gui_message{
+
  -- The function can be triggered directly by defining the table in the function call to gui_message{}.
 +
gui_message{
 
     message  = "Hello world!",
 
     message  = "Hello world!",
     settings = {
+
     speaker = "narrator",
      speaker = "narrator",
+
    image  = "wesnoth.png",
      image  = "wesnoth.png"
 
    },
 
 
     options  = {
 
     options  = {
 
           { text='hello', callback = foobar() },
 
           { text='hello', callback = foobar() },
 
           { text='goodbye', callback = say_goodbye() }
 
           { text='goodbye', callback = say_goodbye() }
    }}
+
    }
 +
}
 
   
 
   
  local msg2 = gui_message{
+
  -- The function can be used indirectly by setting it to a table first, and then using the table's
 +
-- reference variable as an argument for gui_message().
 +
msg = {
 
     message = "What's your name?",
 
     message = "What's your name?",
     -- no "settings =" makes it set reasonable defaults
+
     -- if the tag is not there, reasonable defaults are set
 
     -- text_input takes either a table containing the information, or a table of tables that are all valid text_input
 
     -- text_input takes either a table containing the information, or a table of tables that are all valid text_input
 
     text_input = {variable = "foo", label = "Name: ", max_length = 42}
 
     text_input = {variable = "foo", label = "Name: ", max_length = 42}
 
  }
 
  }
 
   
 
   
if side = host then
 
    msg.show
 
 
   
 
   
 
  function foobar()
 
  function foobar()
     msg2.show
+
     gui_message(msg)
 +
 
 +
====gui_message{}====
 +
The basic portion of gui_message{} is an implementation of the [message] WML tag without any of the subtags. Through the extensions below it allows absolutely everything in WML [message] to be converted except for the filters, which are better done through plain Lua. Note that the use of {} instead of () for the function means that it technically is fed in a Lua keyed table, meaning that the order of the arguments does not matter as long as they match the key. Default values are used for arguments that are not defined, just like the WML behavior.
 +
 
 +
gui_message {
 +
    message    = string,
 +
    speaker    = string,
 +
    side_for    = integer, -- or a table with a set of integers
 +
    image      = string,
 +
    caption    = string,
 +
    scroll      = boolean,
 +
    duration    = integer,
 +
    sound      = string,
 +
    options    = table, -- see below
 +
    text_input  = table, -- see below
 +
}
 +
 
 +
The best part about this is that the core function (excluding the options and text_input tables) can be easily converted into a form recognizable by WML and handled using the same function that handles the existing [message] code. Complexity and a difference from the WML definition only really enter when implementing [option] and [text_input].
 +
 
 +
The alternative form of gui_message{} is gui_message(table) where table is a table with keys that match the definition of gui_message{}.
 +
 
 +
====options====
 +
<!-- expand -->
 +
 
 +
Options has two possible syntax. If there is only one option, it can directly contain the option table:
 +
 
 +
options = {
 +
    text    = string,
 +
    filter  = condition, -- must evaluate to true for the option to show
 +
    callback = function, -- the actual effect of the command
 +
}
 +
 
 +
If there is more than one option, it must have a table containing tables:
 +
 
 +
options = {
 +
    {
 +
      text    = string,
 +
      filter  = condition, -- must evaluate to true for the option to show
 +
      callback = function, -- the actual effect of the command
 +
    }, {
 +
      text    = string,
 +
      filter  = condition, -- must evaluate to true for the option to show
 +
      callback = function, -- the actual effect of the command
 +
    },
 +
}
  
====gui_message()====
 
====option====
 
 
====callback====
 
====callback====
 +
<!-- expand -->
 +
 
====text_input====
 
====text_input====
 +
<!-- expand -->
 +
 
====set_menu_item()====
 
====set_menu_item()====
 +
<!-- expand -->
  
 
===Phase 1===
 
===Phase 1===
 +
<!-- expand -->
 +
 
====Dialog Improvements====
 
====Dialog Improvements====
 
====GUI 2 Access====
 
====GUI 2 Access====
====Commands?====
+
====Optional: Commands====
 +
Graphical User Interfaces are great for most tasks, but there are situations where text-based input is a better way for commands to be run. If possible, it would greatly improve the capabilities of Lua if it were able to interpret chat messages. Lua already has the capability to output to chat, but input from chat would allow for Lua to become even more powerful in this area. Commands could be thought of in two different types, each with different use cases:
 +
 
 +
'''Public chat.''' With Lua given the capability to parse public MP chat, this allows for the computer side, the AI, to be able to interact with the players given certain keywords, which would give certain scenarios a more immersive feel. Instead of being merely cosmetic, this chat could have an actual effect on gameplay. For instance, certain taunts could anger the AI, causing it to change tactics to attack a different player or recruit different units.
 +
 
 +
'''Private commands with a /lua command.''' One is currently able to run Lua through :lua when debug mode is on, but this is infeasible for multiplayer. Being able to interpret "/lua command", especially if it were context aware for which hex is currently selected, would allow for several possibilities. For instance, allied AI could uses Lua to respond to your input so that it can formulate a strategy with you. Also, advanced content that could use certain /lua commands to trigger actions, allowing for anything from an MP-compatible "debug mode" to more restrictive triggers that are fitting to the particular scenario. Perhaps the host would use "/lua difficulty hard" to change the difficulty mid-scenario, or a player could use "/lua inventory" on their turn to pop up an RPG-style inventory screen without having to use any right click menus at all.
 +
 
 +
Essentially, the Lua would be able to use certain input as a trigger for executing Lua functions, enabling a far broader range of possibilities for content creators. This would not actually implement any changes to the way the game is played. Rather, it would provide the ability for others to use this new feature in their own scenarios, eras, AI, etc.
  
 
===Phase 2===
 
===Phase 2===
 +
<!-- expand -->
 +
 
====Sample syntax====
 
====Sample syntax====
 
The final goal is to use wesnoth.ui.show() to hide almost all of the interface details by providing a syntactical shortcut to the functions in Phase 0 and Phase 1. More complexity will be possible, as in sample2, but the extremely basic sample1 will be legal syntax as well.
 
The final goal is to use wesnoth.ui.show() to hide almost all of the interface details by providing a syntactical shortcut to the functions in Phase 0 and Phase 1. More complexity will be possible, as in sample2, but the extremely basic sample1 will be legal syntax as well.
Line 105: Line 169:
  
 
==The Implementation: Timeline==
 
==The Implementation: Timeline==
 +
''Note: This timeline will be rewritten because I have to get Phase 0 in sooner than I anticipated, thus requiring me to shift up and expand Phase 1, as well as elaborate it in subtasks on the timeline.
 +
 
{| border="1"
 
{| border="1"
| now || April&nbsp;08&nbsp;-&nbsp;April&nbsp;22&nbsp;&nbsp; || Discuss details of the implementation with the various developers so that the proposal is ready for the summer. Work on basic patches, especially in the early areas of Phase 0, so that commit access can be granted before the designated GSOC period. Most of the design needs to be finalized in this period.
+
| now || April&nbsp;08&nbsp;-&nbsp;April&nbsp;22&nbsp;&nbsp; || <h4>Pre-Summer I</h4>
 +
Finalize design.
 +
 
 +
Get most of Phase 0 working.
 
|-
 
|-
| || April 23 - May 08 || Continue to familiarize myself with the project and its code by doing more of Phase 0.
+
| || April 23 - May 08 ||
 +
Finish Phase 0.
 
|-
 
|-
| || May 09 - May 18 || Spring semester ends. Availability may be limited during this period. (The days might be slightly off depending on what the final exam schedule is.)
+
| || May 09 - May 18 || '''Spring semester ends.''' Availability may be limited during this period.
 
|-
 
|-
| || May 19 - May 30 || My schedule should be ''entirely'' free in this time span, so Phase 0 should be completed (if it isn't already finished) and substantial progress should be made on Phase 1.
+
| || May 19 - May 30 || <h4>Summer I</h4>
 +
'''Phase 1 beings.''' (My schedule is be ''entirely'' free in this time span.)
 
|-
 
|-
| || May 31 - June 30 || The entire month of June will be spent on Phase 1.
+
| || May 31 - June 30 || <h4>Summer II</h4>
 +
My summer semester starts. I should still have Fridays through Sundays entirely free.
 
|-
 
|-
 
| || July 4 - July 8 || Expected busy week as my one summer course wraps up.
 
| || July 4 - July 8 || Expected busy week as my one summer course wraps up.
 
|-
 
|-
| || July 9 - July 17 || Phase 1, the bulk of the project, should be concluding around this point. Since this is around the middle evaluation point, part of the focus should be on reviewing the design and plans for the second half of GSOC. If I am ahead of schedule or behind schedule, adjustments can be made.
+
| || July 9 - July 17 || <h4>Middle of GSOC</h4>
 +
'''Phase 1 ends.''' The largest portion of the project, Phase 1, should be concluding around this point.
 +
 
 +
Since this is around the middle evaluation point, part of the focus should be on reviewing the design and plans for the second half of GSOC. If I am ahead of schedule or behind schedule, adjustments can be made.
 
|-
 
|-
| || July 18 - July 22 || Expected busy week as my other summer course wraps up.
+
| || July 18 - July 22 || '''Summer semester ends.''' Expected busy week as my other summer course wraps up.
 
|-
 
|-
| || July&nbsp;23&nbsp;-&nbsp;August&nbsp;15&nbsp; || Phase 2. Again, my schedule should be ''entirely'' free to focus on the project.
+
| || July&nbsp;23&nbsp;-&nbsp;August&nbsp;15&nbsp; || <h4>Summer III</h4>
 +
'''Phase 2 begins.''' Again, my schedule should be ''entirely'' free to focus on the project.
 
|-
 
|-
| || August 15 || According to Google: "'pencils down' date. Take a week to scrub code, write tests, improve documentation, etc."
+
| || August 15 || <h4>Pencils Down Date</h4>
 +
According to Google: "Take a week to scrub code, write tests, improve documentation, etc."
 
|-
 
|-
 
| || lim t<br>t→∞  || Continue to work on Wesnoth's Lua scripting capabilities because it certainly will take more than just one summer to perfect it.
 
| || lim t<br>t→∞  || Continue to work on Wesnoth's Lua scripting capabilities because it certainly will take more than just one summer to perfect it.
Line 131: Line 208:
  
 
==Goals==
 
==Goals==
 +
<!-- expand -->
  
 
==Patches==
 
==Patches==
''Work on the Phase 0 patches will resume immediately after this document is finished and submitted.
+
''Currently, the Phase 0 patches are in progress.
  
 
==Questionnaire==
 
==Questionnaire==
Line 178: Line 256:
 
===Experience===
 
===Experience===
  
My primary strength in terms of experience is that I've been with the Wesnoth project, doing almost everything possible except developing for the game engine itself over the course of almost four years. I know the Lua because I've made add-ons in Lua and will continue to port my active add-ons to Lua as time goes on. I know the community because I am part of it. I know the IRC channels because I've regularly been in many of the channels for years. I've even been using SVN as my means of downloading/updating/playing Wesnoth for at least two years now (for stable, development, and trunk).
+
My primary strength in terms of experience is that I've been with the Wesnoth project, doing almost everything possible except developing for the game engine itself over the course of almost four years. I know the Lua because I've made add-ons in Lua and will continue to port my active add-ons to Lua as time goes on. I know the community because I am part of it. I know the IRC channels because I've regularly been in many of the channels for years. I've even been using S&shy;&shy;V&shy;&shy;N as my means of downloading/updating/playing Wesnoth for at least two years now (for stable, development, and trunk).
  
 
'''2.1) What programs/software have you worked on before?'''
 
'''2.1) What programs/software have you worked on before?'''
Line 209: Line 287:
 
* add-ons (since 2007; published since 1.3.x)
 
* add-ons (since 2007; published since 1.3.x)
 
* unofficial Wesnoth-style sprite art (since 2008)
 
* unofficial Wesnoth-style sprite art (since 2008)
* wesnoth-umc-dev SVN repository (since 2009)
+
* wesnoth-umc-dev S&shy;&shy;V&shy;&shy;N repository (since 2009)
 
* wiki moderator (since 2009)
 
* wiki moderator (since 2009)
 
* Latin translator (since 2009)
 
* Latin translator (since 2009)
Line 238: Line 316:
 
Almost four years experience, mostly MP but also a significant amount of SP, especially when I first started playing Wesnoth. I've been playing since the 1.2/1.3 versions.
 
Almost four years experience, mostly MP but also a significant amount of SP, especially when I first started playing Wesnoth. I've been playing since the 1.2/1.3 versions.
  
'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.'''
+
'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our S&shy;&shy;V&shy;&shy;N (during the evaluation period or earlier) please state so.'''
  
 
I will not be able to submit a patch by the application deadline, but they will be [http://wiki.wesnoth.org/SoC2011_Student_Page_Aethaeryn#Patches here] when I have the time.
 
I will not be able to submit a patch by the application deadline, but they will be [http://wiki.wesnoth.org/SoC2011_Student_Page_Aethaeryn#Patches here] when I have the time.
Line 319: Line 397:
 
'''5.1) Are you familiar with any of the following tools or languages?'''
 
'''5.1) Are you familiar with any of the following tools or languages?'''
  
* Subversion (used for all commits)
+
* Sub&shy;&shy;version (used for all commits)
 
** Yes, I've used it for both wesnoth (updates only) and wesnoth-umc-dev (updates and commits) for several years.
 
** Yes, I've used it for both wesnoth (updates only) and wesnoth-umc-dev (updates and commits) for several years.
 
* C++ (language used for all the normal source code)
 
* C++ (language used for all the normal source code)
Line 348: Line 426:
 
[see GSOC submission page]
 
[see GSOC submission page]
 
|}
 
|}
 +
 +
==SoC Application==
 +
[http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/aethaeryn/1 Battle for Wesnoth - Google Summer of Code Application]

Revision as of 02:59, 21 March 2013


This page is related to Summer of Code 2011
See the list of Summer of Code 2011 Ideas



This is a Summer of Code 2011 student page
Project: SoC_Ideas_Your_Own_Ideas2011



Description

Michael Babich - Improving Lua's User Interface Capabilities

I intend to improve the ability for add-ons to customize the user interface through Lua. I will focus on providing simple, but powerful syntax for a set of functions that will enable add-on creators to have improved, easier access to features that already exist within the game engine so that they are free to creatively provide more innovative content.

The purpose of this project is to act as a middleman between the game engine and the add-on creators using the Lua scripting language so that simple and powerful add-on creation can help revolutionize future MP, just as [set_menu_item] and [option] allowed for a great evolution in the quality of add-ons since 1.3. This interface framework needs to be as broad as possible in the time given and the scope allowed so that creative add-on authors themselves can stretch Wesnoth content far beyond its traditional style, but it also must provide a simplified Lua helper library so that everyone can use it without necessarily having to delve deeply into the complexity that exists in the currently-existing GUI.

IRC

Aethaeryn, Aeth

Introduction

I have been making content for Wesnoth since 2007 and I have been gradually porting much of my more advanced content to Lua since late 2009. While doing so, I have noticed certain limitations to the current implementation of Lua as it relates to add-on creation, especially with certain elements only possible through WML or the rather poorly readable WML tables. As the title suggests, I wish to simply and extend the add-on creation capabilities in Lua. In particular, I will be working with various elements of the interface code because this is currently where Lua is weak and often just relying on WML tables. There are several problems with using WML tables in these areas:

  • Poor readability, clumsy syntax, and verbosity. The metatable in the helper library helps with readability, but does not always work (for instance on [or] and [and] boxes, where those words are reserved in Lua) and it still hides the underlying issue that true native Lua support is not there. It also is fairly difficult in certain applications where the XML-style WML syntax is clearly inferior and much more verbose than something done in pure Lua.
  • You're essentially using WML. This defeats the purpose of using Lua in the first place if the majority of your code in a particular area is in WML. This is made even more severe when one realizes that many of the areas that must currently be done via WML tables are complex things that are the kind of things best done in a real language in the first place. In particular, the [message], [option], and [set_menu_item] have no real Lua equivalent.
  • Calling Lua from WML tables is hacky. Currently, if one wants to call a Lua function from T.option {}, one has to set a string that is a call on a global Lua function.

An ideal scenario or campaign would be one that uses WML to define the basic structure and then call on Lua for any more advanced elements. As I spend most of my Wesnoth time making -- or playing -- content for MP that do things that WML was not originally intended to do, such as making Wesnoth an RPG instead of a TBS, I have noticed that WML does not scale very well as a general purpose language doing advanced scripting. Any traditional language, such as Lua, can handle certain advanced things in a much more readable and efficient manner, but there are certain gaps in Lua where WML tables must be integrated with the Lua, which defeats many of the primary reasons to use Lua in the first place.

Fortunately, the solution is rather obvious to the WML table problem. Lua needs to be extended to access features that almost all already exist in the game engine and these must be implemented through Lua functions and tables instead of WML tables so that the full benefits of using Lua for scripting can be realized. Although the problem and solution are fairly easy to describe, certain precautions must be taken to make ensure that save games are not broken and no new issues are introduced. In addition, the individual proposed changes must be enumerated for clarity as to the scope of the project.

The Implementation: Overview

The information can roughly be broken down into three separate phases, 0 through 2. First, I shall go through an overview so as to be straightforward with the overall planned changes, then I shall provide the details of each individual section, and finally I shall propose a detailed timeline as to when each part can be accomplished.

Phase 0: The Initial Changes

First, src/scripting/lua.cpp should be split into smaller, logically-organized files so that the file does not grow too large and unmanageable with the improvements planned. This has the additional effect of allowing me to get familiar with the core Lua code.

Next, various UI tags shall be implemented in native Lua without WML tables. The hardest portion of this is ensuring that the Lua changes can be implemented without breaking save files. Most of the existing WML code can be reused, so a key purpose of this is to get rid of the need for WML tables for this portion of the code so that it better interacts with files written purely in Lua and so it is in a consistent style with code in the later portion of this project. The trickiest part will be implementing the callback, which will allow menu options to trigger Lua functions.

Because the code already exists to handle the WML tags, most of the work is allowing these Lua functions to utilize already-existing code in the engine. In this phase, the Lua functions to be created more or less map one-to-one with WML tags, which is why this would be a "Phase 0". On the surface, the changes may seem subtle, but it will allow for a more Lua way of implementing these than WML tables, which will improve interaction with Lua scripting functions while also making the Lua side of Wesnoth scripting easier to learn. In addition, it will ensure that these very central UI actions are consistent with Phase 1 syntax.

The related WML tags that need to be ported to Lua functions:

  • [message]
    • [option]
    • [text_input]
  • [set_menu_item]

Phase 1: Complex Interface Changes

Note: This section is outdated, I know, but I have to get to it after I actually write the wesnoth.gui_message{} function so I get a feel for the C API and how much time is necessary to do these tasks. I'm probably going to have to add at least two more weeks worth of work on top of what I originally intended.

  • Implement improved Lua access to the in-scenario GUI stuff, again without WML table hacks.
    • This includes improving the syntax and implementation of the dialog Lua.
  • A way to take in text commands in a way similar to debug mode's :lua, but only using specific commands to do specific actions as defined by Lua code in the add-on.

Phase 2: Simplify Add-on Creation

Phase 0 and Phase 1 might seem somewhat unrelated, but Phase 2 is intended to unify them under a common, easily-accessible package of sorts that provides a highly-abstracted, clean syntax for add-on authors to manipulate various elements of the UI. The original implementation from Phases 0 and 1 will still exist for those who want more control and customization, while Phase 2 will make things available for those who do not wish to necessarily deal with the complexity. There are two areas that will allow the improvements to be immediately accessible in an easy manner to content authors:

  • I will implement a Lua "wesnoth.ui" that adds an additional abstraction layer on top of the already existing syntax, simplifying the appearance of the code at the expense of some finer control.
  • If I have the time, I will create new, defined-in-Lua WML tags that utilize wesnoth.ui so that one does not have to use Lua to benefit from the improvements to Lua.

The Implementation: Details

Phase 0

The goal of this phase is to implement similar behavior in Lua to important UI-related WML tags so that these elements can be used in Lua without WML tables, thus eliminating clumsy syntax and ensuring complete implementation. Currently, certain parts, including [option], require clumsy workarounds when implemented in WML tables due to the nature of the tag. This also sets the stage for the later phases by establishing a starting point for more complex feature additions.

Sample Syntax

-- The function can be triggered directly by defining the table in the function call to gui_message{}.
gui_message{
   message  = "Hello world!",
   speaker = "narrator",
   image   = "wesnoth.png",
   options  = {
         { text='hello', callback = foobar() },
         { text='goodbye', callback = say_goodbye() }
   }
}

-- The function can be used indirectly by setting it to a table first, and then using the table's
-- reference variable as an argument for gui_message().
msg = {
   message = "What's your name?",
   -- if the tag is not there, reasonable defaults are set
   -- text_input takes either a table containing the information, or a table of tables that are all valid text_input
   text_input = {variable = "foo", label = "Name: ", max_length = 42}
}


function foobar()
   gui_message(msg)

gui_message{}

The basic portion of gui_message{} is an implementation of the [message] WML tag without any of the subtags. Through the extensions below it allows absolutely everything in WML [message] to be converted except for the filters, which are better done through plain Lua. Note that the use of {} instead of () for the function means that it technically is fed in a Lua keyed table, meaning that the order of the arguments does not matter as long as they match the key. Default values are used for arguments that are not defined, just like the WML behavior.

gui_message {
   message     = string,
   speaker     = string,
   side_for    = integer, -- or a table with a set of integers
   image       = string,
   caption     = string,
   scroll      = boolean,
   duration    = integer,
   sound       = string,
   options     = table, -- see below
   text_input  = table, -- see below
}

The best part about this is that the core function (excluding the options and text_input tables) can be easily converted into a form recognizable by WML and handled using the same function that handles the existing [message] code. Complexity and a difference from the WML definition only really enter when implementing [option] and [text_input].

The alternative form of gui_message{} is gui_message(table) where table is a table with keys that match the definition of gui_message{}.

options

Options has two possible syntax. If there is only one option, it can directly contain the option table:

options = {
   text     = string,
   filter   = condition, -- must evaluate to true for the option to show
   callback = function, -- the actual effect of the command
}

If there is more than one option, it must have a table containing tables:

options = {
   {
      text     = string,
      filter   = condition, -- must evaluate to true for the option to show
      callback = function, -- the actual effect of the command
   }, {
      text     = string,
      filter   = condition, -- must evaluate to true for the option to show
      callback = function, -- the actual effect of the command
   },
}

callback

text_input

set_menu_item()

Phase 1

Dialog Improvements

GUI 2 Access

Optional: Commands

Graphical User Interfaces are great for most tasks, but there are situations where text-based input is a better way for commands to be run. If possible, it would greatly improve the capabilities of Lua if it were able to interpret chat messages. Lua already has the capability to output to chat, but input from chat would allow for Lua to become even more powerful in this area. Commands could be thought of in two different types, each with different use cases:

Public chat. With Lua given the capability to parse public MP chat, this allows for the computer side, the AI, to be able to interact with the players given certain keywords, which would give certain scenarios a more immersive feel. Instead of being merely cosmetic, this chat could have an actual effect on gameplay. For instance, certain taunts could anger the AI, causing it to change tactics to attack a different player or recruit different units.

Private commands with a /lua command. One is currently able to run Lua through :lua when debug mode is on, but this is infeasible for multiplayer. Being able to interpret "/lua command", especially if it were context aware for which hex is currently selected, would allow for several possibilities. For instance, allied AI could uses Lua to respond to your input so that it can formulate a strategy with you. Also, advanced content that could use certain /lua commands to trigger actions, allowing for anything from an MP-compatible "debug mode" to more restrictive triggers that are fitting to the particular scenario. Perhaps the host would use "/lua difficulty hard" to change the difficulty mid-scenario, or a player could use "/lua inventory" on their turn to pop up an RPG-style inventory screen without having to use any right click menus at all.

Essentially, the Lua would be able to use certain input as a trigger for executing Lua functions, enabling a far broader range of possibilities for content creators. This would not actually implement any changes to the way the game is played. Rather, it would provide the ability for others to use this new feature in their own scenarios, eras, AI, etc.

Phase 2

Sample syntax

The final goal is to use wesnoth.ui.show() to hide almost all of the interface details by providing a syntactical shortcut to the functions in Phase 0 and Phase 1. More complexity will be possible, as in sample2, but the extremely basic sample1 will be legal syntax as well.

sample1  = {message = "Hello world"}
sample2 = {message = {"Hello world", options = {speaker = "Konrad", side_for = 1}}}
wesnoth.ui.show(sample1)
wesnoth.ui.show(sample2)

This will allow for possibilities like the following, where the GUI message is literally as simple as providing one string:

function message_all(messageText)
   wesnoth.ui.show{message = messageText}

wesnoth.ui

WML additions

The Implementation: Timeline

Note: This timeline will be rewritten because I have to get Phase 0 in sooner than I anticipated, thus requiring me to shift up and expand Phase 1, as well as elaborate it in subtasks on the timeline.

now April 08 - April 22  

Pre-Summer I

Finalize design.

Get most of Phase 0 working.

April 23 - May 08

Finish Phase 0.

May 09 - May 18 Spring semester ends. Availability may be limited during this period.
May 19 - May 30

Summer I

Phase 1 beings. (My schedule is be entirely free in this time span.)

May 31 - June 30

Summer II

My summer semester starts. I should still have Fridays through Sundays entirely free.

July 4 - July 8 Expected busy week as my one summer course wraps up.
July 9 - July 17

Middle of GSOC

Phase 1 ends. The largest portion of the project, Phase 1, should be concluding around this point.

Since this is around the middle evaluation point, part of the focus should be on reviewing the design and plans for the second half of GSOC. If I am ahead of schedule or behind schedule, adjustments can be made.

July 18 - July 22 Summer semester ends. Expected busy week as my other summer course wraps up.
July 23 - August 15 

Summer III

Phase 2 begins. Again, my schedule should be entirely free to focus on the project.

August 15

Pencils Down Date

According to Google: "Take a week to scrub code, write tests, improve documentation, etc."

lim t
t→∞
Continue to work on Wesnoth's Lua scripting capabilities because it certainly will take more than just one summer to perfect it.

Goals

Patches

Currently, the Phase 0 patches are in progress.

Questionnaire

SoC Application

Battle for Wesnoth - Google Summer of Code Application