On Tue, Aug 07, 2012 at 09:42:42AM +1200, Ralph Versteegen wrote:
> On 7 August 2012 03:39, James Paige <[email protected]> wrote:
> > 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 :(
>
> No, I think it's OK with integers. You can't quite get the same
> precision and you have to know what you're doing, but it's not too
> bad.
Hmmm. so to replicate the built-in forumal you would need something
like:
script, atlevel hook, level, at 0, at 99, hero id, stat number, begin
if (level >= 0) then (
return ((800 + level * 1000 / 50000) * level * ((at 99 -- at 0) *
1000 * / 275222) + at 0 + 100)
)
end
Erm... good gosh. I am 100% positive that I did that completely wrong. I
know how simulating fixed point math using integers is supposed to work.
I totally understand the concept... but when it comes to actually doing
it, I feel like my brain is broken :(
> >> (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.
>
> Those sort of triggered script threads would be sort of intermediate
> between script triggers and immediate mode: they can wait, but the
> engine automatically kills or pauses them (when the battle ends for an
> enemy AI thread, or when leaving the map for an NPC AI thread). Also
> attack animations, textbox and menu open and close animations...
Ah, that makes sense. So those would not really be restricted in what
they can do, but there would be automatic cleanup of them in certain
situations.
> > 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.
>
> And the equipment elemental resist merge formula (yuck).
>
> Maybe something to do with running from battles?
Ohh! Definitely! That is a good one.
> > 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
>
> Right. We might want to call the script hook in places that the user
> doesn't expect (like atlevel from inside a shop when hiring heroes) or
> add new call sites in future. And also commands that modify whatever
> state that the code calling the hook is operating on would be very
> bad. Even settag could be a dangerous command.
Yeah, that makes sense.
---
James
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
