On Mon, Aug 06, 2012 at 11:26:30PM +1200, Ralph Versteegen wrote: > I'm currently working on some interpreter improvements so that we can > add script "hooks", where the engine calls a script in "immediate > mode" and receives the script's return value. In immediate mode a > script may not do anything that causes a wait or other user > interaction such as opening a menu. It's debatable exactly what should > be allowed; commands like walkhero should perhaps not be. Examples of > hooks will be ones to allow people to customise the levelup experience > requirement, the stat increasing formula, and an attack's damage (I > assume we would also have regular triggers attachable to attacks, > which can continue running in-battle). > > So exactly what script hooks should we add? Almost everywhere where we > could use them there's a choice of how much to move into the script, a > trade off between complexity and flexibility. > > For example for attack damage we could have a hook for the base > damage, for attack minus defense (and we still hadn't made 'blunt', > 'sharp' and 'normal' damage more customisable), for applying elemental > bonuses, for the aim math, for total damage after taking into account > the whole huge pile of factors, or at an even more general level where > the script handles all of aim math, damage, damage bounds, revenge, > damage display... . I would lean towards having a couple, but > certainly not all, of these. For these sort of scripts we should > provide script commands to access builtin functions/formulae, where > the command calls a lower-level script hook if defined.
This is wonderful! > Another example which we were discussing in IRC; here's the current > code to update stats at levelup: > > FOR o as integer = 0 TO 11 > n0 = her.Lev0.sta(o) > nMax = her.LevMax.sta(o) > gam.hero(hero_slot).stat.max.sta(o) += > (atlevel(gam.hero(hero_slot).lev, n0, nMax) - > atlevel(gam.hero(hero_slot).lev - gam.hero(hero_slot).lev_gain, n0, > nMax)) > > '...simulate ancient levelup bug and apply stat caps ... > NEXT o > > One option is to add a hook to replace the 'atlevel' function. A > script to replicate the current function would look like this > (imagining we support floating point): > > script, atlevel hook, level, at 0, at 99, hero id, stat number, begin > if (level >= 0) then ( > return ((.8 + level / 50) * level * ((at 99 -- at 0) / 275.222) + at 0 + > .1) > ) > end Do we need to have support for floating point numbers before we can do this? That same script, adjusted to do the same math with only intergers would be vastly more complicated :( > (Note that we pass the hero id, not the hero slot, because you're not > meant to depend on the hero's actual stats. The formula is independent > of hero and stat) > > Another is to add a hook to replace the block of FB code above that > calls atlevel. That way you can do much more customisation, like > adding half of a hero's constitution stat to their HP stat every > levelup. Thinking about it I think it silly to not allow that sort of > thing, unless we insisted that people stick to the old way (writing an > afterbattle script). However, the atlevel function is also used to > compute a new hero's stats when they're added to the party, so would > have to provide both hooks. Yeah, I guess that makes sense. The atlevel hook would be plenty for doing a stat curve, but wouldn't be any good if somebody wanted D&D style dice rolls for level up, or who knows what else. > What about other hooks I haven't mentioned? I can't think of many > more. A lot of things like enemy AI should probably be handled with > regular script threads (once implemented) rather than a "next attack > ID" hook, for example. All I can think of is: experience stat growth attack hit/miss formulas attack damage formulas I imagine we may think of more later, but those are certainly enough to be useful. As for which commands should be allowed in immediate mode, I am inclined to think of it as a "calculations only" mode, so we should probably err on the side of caution and only allow the smallest set of commands that we can get away with (and we can add allowed commands later if people can think of good reasons for them to be allowed) --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
