ToME WikiIngeborgNorden: I've been discussing this idea with DarkGod on IRC, and was wondering what the other devteam guys would think. Instead of repeating similar hook code for each new god in a module, why not define some basic functions like these? (Please excuse the plain-English descriptions, since a lot of the Luafied changes look less familiar than I'd hoped.)
- Add flag X/faction Y to the list of monster-death hooks, and adjust piety by Z.
- Add item tval X/sval Y to the list of sacrificed-item hooks, and adjust piety by Z.
- Add damage type X to the list of relevant damage-type hooks, and adjust piety by Y.
New god entries under this system would have tables linked to each list of hooks--call them "kills", "sacrifices", "damage_types" and so forth. So instead of a hook list for each god, there'd be ONE general monster-death hook that said "check to see whether the player followed god A, and whether god A has any entries on his monster-death list." Defining religious enemies would be easier too: "if god A increases piety for killing the target, then let this item/damage type hit harder." What do you think?
BucketMan: My opinion probably isn't especially relevant, since I'm a) not 'devteam' and b) none of my modules are likely to have any gods whatsoever. But that having been said, reading over the above a few times, I'm not entirely certain what you're trying to accomplish. But that might be, as you say, 'plain-english' getting in the way.
In general, I like the idea of the god system being easy to use, but I don't understand what your proposal is supposed to simplify. You don't need lots of hooks to accomplish any of the above, and implementing it the way you appear to be describing seems like it would impose unnecessary limitations on the god system.
"Add flag X/faction Y to the list of monster-death hooks, and adjust piety by Z."
Do you really want fixed piety changes by flag/faction? Should an EVIL=true thief in town give the same piety reward as an EVIL=true Arch Lich? I suppose you could make it a function and allow it to accept monst data like levels and so forth, but isn't the above accomplished very easily by attaching OPPOSED_TO_THOR, OPPOSED_TO_ODIN, etc. flags to individual monsters, and then doing something like:
hook(hook.MONSTER_DEATH, function(m_idx)
local monst = monster(m_idx)
local r_ptr = race_info(monst)
local pty_mod = 1
if (has_flag(r_ptr, FLAG_GIANT)) then
pty_mod = 2
end
if (has_flag(r_ptr, FLAG_DEMON)) then
pty_mod = 3
end
if (has_flag(r_ptr, FLAG_OPPOSED_TO_THOR)) then
player.piety_thor = player.piety_thor + (monst.lev * pty_mod * worship_bonus(FLAG_GOD_THOR))
end
if (has_flag(r_ptr, FLAG_OPPOSED_TO_ODIN)) then
player.piety_odin = player.piety_odin + (monst.lev * pty_mod * worship_bonus(FLAG_GOD_ODIN))
end
end)
function worship_bonus(which_god)
if player_is_worshipper_of(which_god) then
return 2
else
return 1
end
end
Only one, simple hook needed to handle everything for all gods, and notice also that this method allows individual monsters to effect piety values for multiple gods, and variable bonuses based on the player's specific standing with each god. Of course, you'd want to expand it to incur piety losses for the killing of monsters affiliated with a faction/god as well.
"Add item tval X/sval Y to the list of sacrificed-item hooks, and adjust piety by Z."
Lots of thoughts on this one:
- Not every module is going to use sacrifice
- Some of those that do are going to want to allow the sacrifice of corpses, for which TVAL/SVAL isn't going to be enough information. You'd need either a monster pointer, or from reading over the alph17 notes, an instance of the corpse.
- It would be moderately tedius to deal with situations in which only specific SVAL's were applicable for sacrifice, vs. situations in which entire TVAL's would be applicable. But, it would be trivial to deal with this if you check by flags rather than TVAL/SVAL.
Is there a global engine-defined 'sacrifice' hook? Does there really need to be one? I would say no. It doesn't make much sense for there to be one. It doesn't do anything but encourage module writers to all implement sacrifice the same way, and there's no reason for that. I would personally either attach the 'sacrifice' action to a keypress hook, and then check if the player is on an appropriate terrain FEAT, or I would make it a custom function directly called by some location or event. How else is the engine supposed to 'know' when a sacrifice is taking place?
And, in any case, the sacrifice concept is easily resolved by properly assigning flags to items and using a single function to handle sacrifices. Whenever and wherever a sacrifice is performed, simply check the flags it has against the likes/dislikes of the god receiving the sacrifice, and adjust piety accordingly.
"Add damage type X to the list of relevant damage-type hooks, and adjust piety by Y."
...raise piety based on amount of damage delivered? Wouldn't it be better to handle this in the damage definition? Copy ToME's dam.VALINOREAN_FLAME, add piety gains and you're done. Also, if you do this, be sure to:
- Be careful about what you allow to deliver the damage type. You don't want the player gaining piety when monsters deliver damage. Or, you might, but only for certain 'pets.' But if so, you don't want those pets to give the player piety if they become hostile and damage the player.
- Be careful about the split heal/harm damage types you're planning. You might or might not want both heal and harm effects caused by the same damage type to cause the same amount of piety gain.
Remember it's also an option to have piety losses for using a gods damage type against inappropriate monsters. For instance, random townsfolk might not be holy enough to receive healing from being bathed in bolts of Thor's lightning. But he might still be annoyed if generally run around using his power to kill innocents.
"What do you think?"
Again, I'm not certain what you're trying to accomplish. Are you trying to make things more simple, or more powerful? How does what you're proposing accomplish either?
IngeborgNorden: I intended to simplify the problem of adding gods to a module's pantheon, and the problem of defining what each one likes and dislikes. As for power--the system I had in mind can backfire on a player if he isn't careful, causing him to rack up disadvantages for one careless spell.
The "sacrifice" examples I gave did assume that the hook was defined in the engine; if it's not, I can always copy from a module that uses it.
ShrikeDeCil I read the original comment as a desire for these things to be supported at the engine level, as opposed to being supported independently by every module. It isn't "lots of hooks" on a case by case basis, but there's a lot of reinventing the wheel going on. It seems like the perfect job for a subsystem to me, but that's just the peanut gallery.
IngeborgNorden: Shrike, what do you mean by a subsystem? I've got only limited coding/module-writing experience, but I'm always looking for ways to make ideas easier to implement.
ShrikeDeCil Inside the application (via Show Package Contents) go to Tome.app/Contents/Resources/game/engine. All the files here are part of the 'engine.' There's a 'subsystem' folder, holding a wide array of things. There's already a 'gods.lua' file here. But (AFAICT) what you're describing would be generic enough, and could be useful enough to put in there. BucketMan's 'dialogs' are another chunk that could be useful. The whole directory is sort of 'auxilliary APIs' for modules that they can add. If they want. The current 'gods.lua' subsystem has a function for praying, and a counter for GRACE, for instance. Adding a generic 'sacrifice' function seems in keeping with the idea. But, it wouldn't be 'part of your module', so you would want to convince people that you had a good implementation, etc. I don't know if the 'Holy damage' part would fit as a _generic_ function. But that file (gods.lua) would seem to be the right place - if it is truly useful beyond one module.