ToME: the Tales of Maj'Eyal

Everything about ToME
It is currently Fri Oct 19, 2018 4:13 am

All times are UTC




Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Sat Feb 16, 2013 2:21 am 
Offline
Wyrmic

Joined: Fri Jan 18, 2013 8:35 am
Posts: 261
I think that's about as clear as its possible to be, actually; thanks.

Your linked explanation seems like a perfectly reasonable way to handle talent modification, although I could imagine that there's other stuff in data for which I might have trouble finding an identifier. (I was actually thinking about making a string out of the talent definition, manipulating the string, then doing my altered string, and was all googly about my potentially limitless power.)

In your linked post, you describe an undocumented hook. Is there a complete list of hooks anywhere? Is there a way that I could search the game code (maybe the svn code?) to identify all hooks?

Even though I don't imagine inheritance to be important to anything I might do, I certainly didn't understand it before, and feel like I've got a bit of a grip on it now. At least enough to trace inherited elements.

_________________
Proud father of Fx4fx and Chronometer add-ons; proud mother of Fated add-on


Top
 Profile  
 
PostPosted: Sat Feb 16, 2013 3:09 am 
Offline
Sher'Tul Godslayer

Joined: Mon Mar 14, 2011 10:32 am
Posts: 1709
Location: Canada
nate wrote:
In your linked post, you describe an undocumented hook. Is there a complete list of hooks anywhere? Is there a way that I could search the game code (maybe the svn code?) to identify all hooks?

This should work:http://git.develz.org/?p=tome.git&a=search&h=HEAD&st=grep&s=triggerHook

_________________
Some of my tools for helping make talents:
Melee Talent Creator
Annotated Talent Code (incomplete)


Top
 Profile  
 
PostPosted: Sat Feb 16, 2013 7:58 am 
Offline
Wyrmic

Joined: Fri Jan 18, 2013 8:35 am
Posts: 261
Thanks, that's perfect! (And I was wondering where to find a changelog... edit:which that link answers, just to be perfectly clear)

_________________
Proud father of Fx4fx and Chronometer add-ons; proud mother of Fated add-on


Top
 Profile  
 
PostPosted: Tue Feb 19, 2013 5:55 pm 
Offline
Wyrmic

Joined: Fri Jan 18, 2013 8:35 am
Posts: 261
Okay, another question:

I've run into trouble when superloading functions that call another function from an absolute name rather than a relative name-- _M:init in mod/class/uiset/minimalist.lua, for example, calls UISet.Init(self), causing an error ("Lua Error: .../widgettemplate/superload/mod/class/uiset/Minimalist.lua:32: attempt to index global 'UISet' (a nil value)").

Well, at least, that's what seems different about this call, so I figure that's what's responsible for the error. That's with a basic superload-- loadPrevious followed by a redefinition of _M:init that's identical to the old definition. Overloading (with the entire contents of minimalist.lua) doesn't cause an error. When the original definition is instead assigned to a base_init and called from that, no error.

Is this because of path issues? What's the best way around this? (Technically speaking, do superloads even need to go into a superload directory? The code suggests that loadPrevious and redefinition could occur anywhere.)

_________________
Proud father of Fx4fx and Chronometer add-ons; proud mother of Fated add-on


Top
 Profile  
 
PostPosted: Wed Feb 20, 2013 1:14 am 
Offline
Wyrmic

Joined: Wed Aug 22, 2012 12:16 am
Posts: 200
nate wrote:
I've run into trouble when superloading functions that call another function from an absolute name rather than a relative name-- _M:init in mod/class/uiset/minimalist.lua, for example, calls UISet.Init(self), causing an error ("Lua Error: .../widgettemplate/superload/mod/class/uiset/Minimalist.lua:32: attempt to index global 'UISet' (a nil value)").
If you look at line 22 of v1.0's Minimalist.lua, you'll see the line
Code:
local UISet = require "mod.class.uiset.UISet"
which defines a local variable. That variable is local only to that file. It's not part of the class definition table. loadPrevious() can't and doesn't pull that into your superloaded file. You have to require() those kinds of file dependencies into local variables in your own superloaded files, too.

nate wrote:
(Technically speaking, do superloads even need to go into a superload directory? The code suggests that loadPrevious and redefinition could occur anywhere.)
Yes and no. They have to go into superload/ or they won't have loadPrevious() defined for them, but you could change the argument to loadPrevious() to any class table you wanted. That's just heartburn waiting to happen, though, and more work than making a couple subdirectories.


Top
 Profile  
 
PostPosted: Wed Feb 20, 2013 4:37 am 
Offline
Wyrmic

Joined: Fri Jan 18, 2013 8:35 am
Posts: 261
Ahh-- I ran into a bunch of problems until I realized that scope didn't extend into superloads. I probably missed UISet because of the "require"-- that's one of those things that, since I don't know what it does, I glaze over.

Have you the energy to explain what "require" does? Is it specific to Tome, specific but common practice, something general to Lua?

(And don't worry, I'm not going to superload anywhere else, although the ability to edit functions on the fly is one of those things that seems really appealing and powerful to me, even if I don't have any application in mind. Yet. :) )

_________________
Proud father of Fx4fx and Chronometer add-ons; proud mother of Fated add-on


Top
 Profile  
 
PostPosted: Wed Feb 20, 2013 4:46 am 
Offline
Wyrmic

Joined: Wed Aug 22, 2012 12:16 am
Posts: 200
nate wrote:
Have you the energy to explain what "require" does? Is it specific to Tome, specific but common practice, something general to Lua?
It's a Lua function for loading files.


Top
 Profile  
 
PostPosted: Wed Feb 20, 2013 5:39 am 
Offline
Wyrmic

Joined: Fri Jan 18, 2013 8:35 am
Posts: 261
Wow. I was just about to sit down and figure out how to start a library of my own functions. You just saved me a lot of effort. Thanks again.

_________________
Proud father of Fx4fx and Chronometer add-ons; proud mother of Fated add-on


Top
 Profile  
 
PostPosted: Thu Feb 28, 2013 12:45 am 
Offline
Wyrmic

Joined: Fri Jan 18, 2013 8:35 am
Posts: 261
Okay, another question: what about multiple superloads? If two add-ons superload the same file, do they superload in series? Like, one add-on superloads the default code, then the second add-on superloads the superloaded code?

I'm asking because I'm trying to design code that's friendly for people that want to do the same thing later. Here's an example:
Code:
local _M = loadPrevious(...)
local base_setupCommands = _M.setupCommands
--function from loadPrevious that I'm inserting a new function into
local base_addNewMenuItems = nil
--declaration just to make sure I keep my base local, don't want it overwriting earlier superloads, don't want it overwritten by later superloads using same code
if _M.addNewMenuItems then base_addNewMenuItems = _M.addNewMenuItems end

function _M:addNewMenuItems(list)
   list[#list+1] = {"Test", function() game.logSeen(game.player, "Menu test!") end}
   if base_addNewMenuItems then return base_addNewMenuItems(self, list) end
      --percolate through superloads that are doing things the same way I am
end


Is that the right way to do things?

_________________
Proud father of Fx4fx and Chronometer add-ons; proud mother of Fated add-on


Top
 Profile  
 
PostPosted: Thu Feb 28, 2013 1:02 am 
Offline
Perspiring Physicist

Joined: Sun Sep 09, 2012 7:43 am
Posts: 5759
I'm not sure you need to worry about keeping the base local.

I use the format on the wiki that is supposed to allow for chaining superloads.
I haven't seen anything that would suggest it doesn't work.

(and if it doesn't, we just blame DarkGod)

_________________
My feedback meter decays into coding. Give me feedback and I make mods.


Top
 Profile  
 
PostPosted: Thu Feb 28, 2013 7:54 am 
Offline
Wyrmic

Joined: Fri Jan 18, 2013 8:35 am
Posts: 261
Is there something specifically about chaining superloads? That affect the same function, or use the same function? I'm concerned that if base_function is used by two addons, that the second will superload from the first, reassigning the address of the globally scoped base_function, and the first's function will end up calling a base_function that now refers to itself-- infinite loop, whee.

I guess I could just design it and see if it works or breaks. That seems to be what I always end up doing anyways.

_________________
Proud father of Fx4fx and Chronometer add-ons; proud mother of Fated add-on


Top
 Profile  
 
PostPosted: Fri Mar 01, 2013 7:11 am 
Offline
Perspiring Physicist

Joined: Sun Sep 09, 2012 7:43 am
Posts: 5759
Its sitting at the bottom of http://te4.org/wiki/addons

It suggests you replace the function you wish to superload with a wrapper function that contains you code and the original function.

_________________
My feedback meter decays into coding. Give me feedback and I make mods.


Top
 Profile  
 
PostPosted: Sun Mar 03, 2013 6:49 pm 
Offline
Wyrmic

Joined: Fri Jan 18, 2013 8:35 am
Posts: 261
I did some testing, just to verify-- global base_function, in two superloads, works just fine, like you say.

But _M:base_func in two superloads does the infinite loop thing, so the "if _M:newfunc then base_newfunc = _M:newfunc end" and/or "if base_newfunc then return base_newfunc end" structure for chaining superloads doing the same thing seems like a good idea.

Must be a scope issue-- I don't yet fully understand when scope is going to penetrate.

_________________
Proud father of Fx4fx and Chronometer add-ons; proud mother of Fated add-on


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group