LuaWML/Reorganization - Revision history

Laela at 21:53, 23 July 2025

2025-07-23T21:53:59Z

Toranks: errata unit > units

2023-03-20T19:50:20Z

errata unit > units

Celtic Minstrel: Remove wml.error since it was implemented

2020-09-07T19:10:59Z

Remove wml.error since it was implemented

Celtic Minstrel: Remove sides module (move implemented), location_set module (move rejected), and last piece of units module (move rejected)

2019-12-06T05:09:07Z

Remove sides module (move implemented), location_set module (move rejected), and last piece of units module (move rejected)

Celtic Minstrel: /* unit */ Update for latest batch of moves

2019-11-16T06:18:29Z

‎unit: Update for latest batch of moves

Celtic Minstrel: Remove implemented bits to make it easier to see everything else

2018-11-12T01:18:45Z

Remove implemented bits to make it easier to see everything else

Show changes

Celtic Minstrel: Move proposal for get_displayed_unit to interface

2017-06-03T14:55:17Z

Move proposal for get_displayed_unit to interface

Pentarctagon: /* sound */

2016-11-19T18:04:08Z

‎sound

DeFender1031: /* file */ update

2016-11-06T20:56:43Z

‎file: update

DeFender1031: more questions

2016-11-06T19:22:46Z

@@ Line 5: / Line 5: @@
 Some portions of the original proposal have already been implemented (though not always in precisely the proposed manner). These portions have been removed from this document; see the page history for more information on removed portions.
-Most names will remain the same, but some will be changed for consistency (ex: anything previously referring to a "tile" now refers to a "hex"), accuracy (ex: "theme_items" has nothing to do with themes or items), or because their category makes part of their name redundant (ex: "wesnoth.get_unit" is now "wesnoth.units.get")
+Most names will remain the same, but some will be changed for consistency (ex: anything previously referring to a "tile" now refers to a "hex"), accuracy (ex: "theme_items" has nothing to do with themes or items (renamed to wesnoth.interface.game_display)), or because their category makes part of their name redundant (ex: "wesnoth.get_unit" is now "wesnoth.units.get")
 Note also that the metatable functions are planned to be modified to no longer require a table to be passed in for use, and simply return a proxy table for whatever kind of metatable is being created, and as such, their names will be radically changed in this proposal to reflect their primary purpose (to get a proxy table which behaves a certain way). This also raises the question of why exactly certain data need to have a proxy returned from some creation function (such as the proxy for working with WML variables), and certain others are available through direct access to proxy tables (such as sides, game config, current, etc.), and others yes are modified through getters and/or setters despite being heavily id-based and thus prime candidates for proxy table usage (such as traits and eras). There is also the question of missing functionality and providing access to data which should be available but is not. These topics can and should be discussed and fleshed out as well, but are beyond the current scope of this document, which is to perform a one-to-one reorganization of existing functionality.

@@ Line 5: / Line 5: @@
 Some portions of the original proposal have already been implemented (though not always in precisely the proposed manner). These portions have been removed from this document; see the page history for more information on removed portions.
-Most names will remain the same, but some will be changed for consistency (ex: anything previously referring to a "tile" now refers to a "hex"), accuracy (ex: "theme_items" has nothing to do with themes or items), or because their category makes part of their name redundant (ex: "wesnoth.get_unit" is now "wesnoth.unit.get")
+Most names will remain the same, but some will be changed for consistency (ex: anything previously referring to a "tile" now refers to a "hex"), accuracy (ex: "theme_items" has nothing to do with themes or items), or because their category makes part of their name redundant (ex: "wesnoth.get_unit" is now "wesnoth.units.get")
 Note also that the metatable functions are planned to be modified to no longer require a table to be passed in for use, and simply return a proxy table for whatever kind of metatable is being created, and as such, their names will be radically changed in this proposal to reflect their primary purpose (to get a proxy table which behaves a certain way). This also raises the question of why exactly certain data need to have a proxy returned from some creation function (such as the proxy for working with WML variables), and certain others are available through direct access to proxy tables (such as sides, game config, current, etc.), and others yes are modified through getters and/or setters despite being heavily id-based and thus prime candidates for proxy table usage (such as traits and eras). There is also the question of missing functionality and providing access to data which should be available but is not. These topics can and should be discussed and fleshed out as well, but are beyond the current scope of this document, which is to perform a one-to-one reorganization of existing functionality.

@@ Line 38: / Line 38: @@
 !New Access Point
 !Comments
 |-
 |wesnoth.message

@@ Line 169: / Line 169: @@
 |helper.adjacent_tiles
 |wesnoth.map.adjacent_hex_iterator
+|
 |}
@@ Line 241: / Line 199: @@
+|
 |}
 == game ==

@@ Line 180: / Line 180: @@
 !New Access Point
 !Comments
 |-
 |wesnoth.unit_types

@@ Line 191: / Line 191: @@
 |helper.move_unit_fake
 |wesnoth.interface.move_unit_fake
+|
 |}
@@ Line 251: / Line 255: @@
 |wesnoth.remove_dialog_item
 |wesnoth.dialog.remove_item
+|
 |-

@@ Line 311: / Line 311: @@
 |wesnoth.set_music
 |wesnoth.sound.set_music
+|wesnoth.music.set or wesnoth.music.play?
 |-
 |wesnoth.add_sound_source

@@ Line 543: / Line 543: @@
 |wesnoth.dofile
 |wesnoth.file.run
+|Should this remain as "dofile", which is the standard name used by lua?
 |-
 |wesnoth.require

@@ Line 12: / Line 12: @@
 *Whether there should be a "misc" category for stuff that doesn't fit nicely anywhere else
 *The specific names and categorizations of each specific API item
 *Pretty much anything and everything else about this proposal, indeed, all the way down to "should we even DO this at all?"