ToME: the Tales of Maj'Eyal

nate wrote:I'm trying to figure out superloading so that I can write mods the right way. Running into problems.

Here's (what I believe to be) my troublesome code, in /mod/class:

Code: Select all

local _M = loadPrevious(...)

local base_onEnterLevel = _M:onEnterLevel

function _M:onEnterLevel(zone, level)
	game.logSeen(self, "This is a test of superloading.")
    return base_act(self, zone, level)
end

return _M

local _M = loadPrevious(...)

local base_onEnterLevel = _M:onEnterLevel

function _M:onEnterLevel(zone, level)
	game.logSeen(self, "This is a test of superloading.")
    return base_onEnterLevel(self, zone, level)
end

nate wrote:So, if I understand correctly, when you declare a _M:myFunction, you're creating a function that gets added to the the table of everything of class Actor?

local _M = loadPrevious(...)

nate wrote: So then you can call myActor:myFunction(), or myOtherActor:myFunction()? I'm still trying to figure a lot of this stuff out. Knowing why it's _M (and not _N) would probably help me wrap my head around things.

nate wrote:I would love to hear more about usage of : and . if you have any information. It seems like you use function myTable:myFunction to define/create a function, myTable:myFunction() to call that function, but duplicateHandleToFunction = myTable.myFunction to assign that function someplace else? After which you could call duplicateHandleToFunction() with the same effect as myTable:myFunction()?

Am I correct in that understanding?

function _M:thingy()

function _M.thingy(self)

_M:thingy()

_M.thingy(_M)

nate wrote:1) So these two statements are functionally identical:

function myTable:thingy(arg 1, arg2)

vs

self = myTable
function myTable.thingy(self, arg1, arg2)

(just to clarify how the arguments work)

self = myTable

nate wrote:And during execution, thingy can refer to self, even if declared in the first way and not sent an argument of self?

nate wrote:What about in calling the function, as opposed to declaration? Will

myTable.thingy(self, arg1, arg2)

work as well as

myTable:thingy(arg1, arg2)

local myTable = {}
function myTable:complicate()
	return self.elsewhere
end

local myTableInstance = { elsewhere = "Confused yet?" }
setmetatable(myTableInstance, { __index = myTable })

print(myTableInstance:complicate())
-- Prints "Confused yet?"

-- Definitions
function myTable:odds(arg)
function myTable.ends(self, arg)

-- Calls
myTable.odds(myTable, ": declared, . called")
myTable:ends(". declared, : called")

nate wrote:2) What about code like that in mod/class/interface/combat.lua, where _M is not explicitly defined, and yet is used as the table that contains all of the functions defined therein? Is it using a definition from a different file? Is it using _M in the same way that I am in my Player.lua superload?

nate wrote:Now I'm taking a look at talents and trying to figure out how to superload them. Talent files are collections of what look like tables labelled newTalent, but that can't be quite right, because wouldn't each of these tables overwrite the last? So what exactly are these?

-- Two ways to pass a single table as a function argument
myfunc{}
myfunc({})

-- All identical
myfunc2""
myfunc2 ""
myfunc2("")

myfunc3 "First", "second"

nate wrote:And, from a superloading perspective, how do I go about accessing their individual functions and changing them? Do I have to figure out the talent id in some table of talents to access their individual .actions and .infos? It seems like this is perfectly possible, but wouldn't work along the same lines of the previous superloads. It also seems like there is probably more than one way to do it. (I've never used a powerful interpreted language like Lua before, it kind of scares me :) )

nate wrote:EDIT: Oh, and let me clarify something: even though I am modding player.lua, onEnterLevel is still a function belonging to class Actor, because the beginning of player.lua loads module (x, class.inherit(mod.class.Actor, etc)) ? Is that correct?