28 réponses à ce sujet

[MagicalMaster]

I developed this system for my recent February Adventure Building Challenge module, Siege of the Heavens to display health percentages and increase the maximum health a creature can have.  I figured other people might find it useful so I thought I'd share it.  You should be able to easily integrate the health percentage half into any module (regardless if you built it) - can easily install it in any module in a few minutes at most - while the massive health pools part takes slightly more work, mainly if you want healing to work properly with it.

Installation is literally this for the health percentages:

1. Download file from vault
2. Open module in toolset
3. Import erf with the script
4. Copy/paste one line of code into the OnSpawn script
5. Copy/paste a six line block of code into the OnPerception script

Done!

-----------------------------------------------------------------------------

Vault Page: http://nwvault.ign.c....Detail&id=3879

Video below is slightly out of date - the general concept is the same but the script is called in the OnPerception instead of OnSpawn and the script shuts down if no PCs are in the creature's area. See change log for v1 to v2.

Video Demonstration:

------------------------------------------------------------------------------

UpdateHP is a system with two primary features - the ability to display the health percentage of creatures and to allow effective hit points far beyond what the toolset can provide by default (toolset limit is roughly 13,000 whereas this system can support a little over two billion if somehow needed) without actually appearing to do anything special.  These two features are independent - you can use either or both of them as you desire.  The system can also be used to defend against the default Devastating Critical - see "Immortality" under Miscellaneous Information (though using the entire script for just that purpose is somewhat overkill).  The system is extremely easy to set up and configure in general, though if you use MassiveHP there are some special details you should know (regarding interaction with other scripts/effects, primarily healing and extreme burst damage).

In general, the system works by starting the script once the creature perceives an enemy or PC.  It then checks the creature every second (the frequency can be adjusted as per your needs).  If the creature's hit points have changed (taken damage or been healed) and the health percentage has changed, it updates the creature's health percentage.  If MassiveHP is enabled and the creature's hit points have changed, it updates the creature's effective hit points.  If hit points have not changed, it simply checks again in a second.  The checking speeds up to every half second if the creature is using MassiveHP and is below 3000 raw hit points.

If there are no PCs in the with the creature, the script shuts down and starts back up once the creature perceives another enemy or PC.  This prevents the script from using resources when it does not need to be running (it does not start until needed and stops when not needed).

If you use this system, I ask that you do not make major modifications to the script without asking me - I would prefer to be able to incorporate any significant improvements into the base system so everyone can take advantage of it (giving credit for the improvement, of course).  This does not apply to the frequency at which the script runs, adjust that as you would like.  There is also a function called "Special" which can be freely customized to suit your module if you need something special done every time the bulk of the script runs.  And, of course, feel free to comment out either ShowHP or MassiveHP if you only care about one of the features.  Thank you.

Have fun!

--------------------------------------------------------------------------

Version 4 is up.  Needed to fix a potential bug introduced in v3 that ONLY occurs if you use the advanced option. Specifically, the advanced option would call the script on any creature in the area, even if the script was not meant to run on the creature. New version will only run on creatures who previously had the script running on them.

- Fixed bug in advanced option introduced in v3 that would call the script on any creature in the area, even those who weren't meant to have the script run on them (potentially henchmen, summons, etc). No impact if you weren't using the advanced option

Version 3 is up.  Chunk of code provided to cover a fringe scenario.  Extra work to install for little gain, but possible if you want to cover it (more details in ReadMe under "Advanced Option"):

- Chunk of code provided in script header to place in OnEnter script for areas to avoid having an incorrect health percentage for a few seconds if a player attacks a regenerating creature and retreats (leaving the area entirely) without killing it and returns before the monster despawns (player would see an incorrect health percent for a few seconds upon returning before the script started running again)

Version 2 is up. Takes one additional (simple) step to install with the following improvements:

- Called with OnPerception when an enemy or PC approaches to avoid using resources until needed
- Shuts down if all PCs leave the creature's area and starts back up when approached again
- Calls itself every second by default once triggered (compared to previous 0.5 seconds), speeding up to 0.5 seconds if the creature is using MassiveHP and below 3000 raw hit points

Modifié par MagicalMaster, 18 mars 2013 - 07:03 .

[ffbj]

Really Cool! Thanks. Personally I would not mind a 30k hp monster only being healed back to 20k.
I suppose WM doing 2k a hit would be justification enough for something like this, why in the world did they ever made that possible. Oh well!

[MagicalMaster]

Vault page is up.  Thanks, Rolo.

ffbj wrote...

Really Cool! Thanks. Personally I would not mind a 30k hp monster only being healed back to 20k.

Fair enough!  If if you change your mind, healing to full health is simple - just heal the monster to full natural hp and set the "hpbonus" int to "hpmax" - 10000.

In general, you just also need to increment the "hpbonus" int by however much you want to heal and make sure the current hit points plus "hpbonus" don't exceed "hpmax."  It mainly gets tricky when you cross one of the health thresholds if you're trying to make the illusion perfect - if the monster is at 4999 actual HP, 9000 bonus HP, and thus 13999 effectuive HP, you don't want to heal the ACTUAL hit points by 500, you want to increment the bonus (so it stays at Badly Wounded).

On the flip side, if the monster is at 4999 actual HP, 10000 bonus HP, and thus 14999 effective HP...you'd WANT to heal the actual HP by 500, because it SHOULD transition back up to Injured.

Again, that's mainly about preserving the illusion - simply incrementing "hpbonus" (as long as actual HP + "hpbonus" doesn't exceed "hpmax") will always provide the correct amount of healing, it just won't look exactly perfect.

ffbj wrote...

I suppose WM doing 2k a hit would be justification enough for something like this, why in the world did they ever made that possible. Oh well!

That's with mundane gear too, sadly: http://nwnecbguild.4...22-t515455.html

If you're on a world with high weapon enhancements and tons of bonus damage, the numbers can get far higher.

Modifié par MagicalMaster, 14 mars 2013 - 09:45 .

[Shadooow]

i managed to make 20k hp boss simply via gff edit raising the bonusHP above 10k, not sure if there is limit, but seems like a better option than this...

[MagicalMaster]

ShaDoOoW wrote...

i managed to make 20k hp boss simply via gff edit raising the bonusHP above 10k

How universally applicable is that - one of my goals was to make an easy and simple way to accomplish this.

ShaDoOoW wrote...

seems like a better option than this...

Are you concerned with the principle (healing behind the scenes to simulate HP) or the method (psuedo heartbeat every x seconds)?

[Shadooow]

[quote]MagicalMaster wrote...

[quote]ShaDoOoW wrote...

i managed to make 20k hp boss simply via gff edit raising the bonusHP above 10k[/quote]

How universally applicable is that - one of my goals was to make an easy and simple way to accomplish this.
[/quote]
open the creature utc file from modules/temp0 in GFF editor, modify the field MaxHitPoints, CurrentHitPoints and HitPoints to desired value. Save file, save module, thats it. Little drawback is that this modification is often erased to 10k when that creature is opened and changed in toolset later, but not always probably only in cases when the changes touches HPs.

[quote]
[quote]ShaDoOoW wrote...

seems like a better option than this...[/quote]

Are you concerned with the principle (healing behind the scenes to simulate HP) or the method (psuedo heartbeat every x seconds)?
[/quote][/quote]The concept is brilliant the method to accomplish that a litttle less, but given there is easy way to get around that 10k hp limit, I don't see much of use for this.

Modifié par ShaDoOoW, 15 mars 2013 - 02:02 .

[ffbj]

While your method of fiddiling with the gif to add hits works, it could add a layer of difficulty for some who want to raise hp and offers no additional feedback.  In addition there are  two pieces to  his method. 
I wonder how it would work combined with one of the hitpoint bar graphs.  

Modifié par ffbj, 15 mars 2013 - 01:06 .

[Shadooow]

ffbj wrote...

Well he did show how this method could be used to create an absurd 20 billion hit point monster to, to demonstrate the flexibility and capability of this method. While you would never use such a thing you could create a creature with 100k 200k etc...Somehow your method of fiddiling with the gif to double the creatures hp's up to a max of 20k, a change that, by you own admission, is lost if the creature is edited later on, does not seem to equate with that. Mainly since at high levels characters can do thousands of points of damage in a round. It is something mainly for campaigns like higher ground or others with high powered equipment or where you can go beyond 40th level.

i didnt said 20k hp is max, just that thats what I achieved, i expected this cap to be much higher, though now I went to test that and it seems that cap is somewhere around 32ksomething, (meaning bonus hitpoints, still creature can get additonal hitpoints from constitution) 254con = 121mod*180lvl + 180toughness + 200epic toughness + 32k bonus hp = 86160maximum hitpoints in theory (untested)

Dont forget that MM's solution (same as my immunity to dev crit script) has downsides like immunity to any mind-affecting effect, devastating critical hit, death magic etc.

I was admin of a PW like that (legendary levels above 40, magic gear +9) and we didnt needed such absurd numbers especially if you can balance that with high regeneration, damage immunity or damage resistance

but yes - if you insist you need such massive ammount of HPs, than this is a good technique to achieve that

[ffbj]

Oh sorry I edited my reply after I reread your earlier response while you were writing it.
I was thinking of ways to make monster tougher too, like you mentioned, immunities and resistance and such. So that seems to make it clear that you addressed the problem as most would, in only way you could. Yeah you could give every powerful monster 90% immunities to everything. As far as immunities to death magic and dev critical, I would weep no tears to see them gone, but maybe that is just me. Immunity to mind effects though is not something I would want.
But tell me how many of you super-powered monsters where immune to such effects?
I am less knowlegable in these high-powered creature areas but it seems useful to me, since as you have indicated you really have to a lot to buff your boss monsters, high regen, immunities, and resists. Just seems like a different approach, and in some ways preferable to the standard methods.
Thanks for the input.

Modifié par ffbj, 15 mars 2013 - 01:27 .

[Shadooow]

Again the concept is brilliant, but the method of doing that less so. Also for very massive hit points, 10k hp base is not enought to make proper illusion of the default HP percentage so for a more than 100k hp editing the creature's base hitpoint via the method I suggested would be preferred anyway.

My point is that this isnt any big breakthrough since need for massive hitpoints over this 30k is rare circumstance even in extremely high magic really. In cases builder wants more than 30k hp without need to alter constitution/levels from any reason, this would be ideal method though.

Modifié par ShaDoOoW, 15 mars 2013 - 02:02 .

[FunkySwerve]

MagicalMaster wrote...
How universally applicable is that - one of my goals was to make an easy and simple way to accomplish this.

It isn't. We're aware of Shad's approach, and we still don't use it, because it's such a pain. Tracking which creatures are modified so that you don't inadvertently revert them just isn't worth it. By contrast, we DO do this with areas, because there's no other way to achieve what gff edits can with them, and because we have to edit them much less often than creatures.

We found regeneration to be a much more palatable alternative. But then, that also seems to be the case with Shad:

ShaDoOoW wrote...
I was admin of a PW like that (legendary
levels above 40, magic gear +9) and we didnt needed such absurd numbers
especially if you can balance that with high regeneration, damage
immunity or damage resistance

That said, I wouldn't use your approach either - it sounds like an immense amount of unnecessary overhead. Was there no way to achieve this via ondamaged?

Funky

[Shadooow]

FunkySwerve wrote...

MagicalMaster wrote...
How universally applicable is that - one of my goals was to make an easy and simple way to accomplish this.

It isn't. We're aware of Shad's approach, and we still don't use it, because it's such a pain. Tracking which creatures are modified so that you don't inadvertently revert them just isn't worth it. By contrast, we DO do this with areas, because there's no other way to achieve what gff edits can with them, and because we have to edit them much less often than creatures.

Right. I have to admit I do use this approach only for a few bosses which also have a huge regeneration as a bonus. Using this approach for a general creatures could be really pain I guess.

[painofdungeoneternal]

I'd imagine you could implement ShaDoOoW's approach easier by setting variables on the creature, then on loading of the blueprint or other script event, do the adjustment via something like NWNx instead - basically use other tools to do it in a way that does not compete with the toolset, or which undoes any capped values put in by the toolset back to their above the cap values.

( or when the module is assembled via various means if you use a source repository, more like how elven's nwnlib lets you do it, basically dynamically adjust the GFFs via tool to ensure the toolset has not messed anything up. )

But it is a brilliant idea which solves the problem in a new way, and even if it's not used by everyone, it might inspire other similar ideas.

[MagicalMaster]

ShaDoOoW wrote...

Dont forget that MM's solution (same as my immunity to dev crit script) has downsides like immunity to any mind-affecting effect, devastating critical hit, death magic etc.

Only if you're worried about the creatures taking >2500 damage between calls of the script, and that's only a worry during the last 25% of the creature's effective health (because otherwise they'd need to take >5000 damage).

And of course it's independent of the health percentage display.

ShaDoOoW wrote...

I was admin of a PW like that (legendary levels above 40, magic gear +9) and we didnt needed such absurd numbers especially if you can balance that with high regeneration, damage immunity or damage resistance

The main problem with damage immunity is that it doesn't play nicely because it's additive.  For example, let's say you make a boss with 50% immunity to everything and also give him Elemental Shield.  Instead of taking 25% damage from Fire and Cold, he takes 0%.  Stuff like that means you need to be careful.  Regeneration can also have issues (such as the boss having more hit points the longer the fight goes on) which need to be considerd.

ShaDoOoW wrote...

Again the concept is brilliant, but the method of doing that less so. Also for very massive hit points, 10k hp base is not enought to make proper illusion of the default HP percentage so for a more than 100k hp editing the creature's base hitpoint via the method I suggested would be preferred anyway.

See below regarding method (in response to Funky).

Why do you think 10k isn't enough to make a proper illusion?  Unless you take 2500 or more damage between calls of the script, the illusion should be (nearly) perfect.

FunkySwerve wrote...

Was there no way to achieve this via ondamaged?

You could remove main, some of the arguments being passed, and the DelayCommand call and stick the UpdateHP funtion in OnDamage (would take like 5-10 minutes to adjust it, I suspect).  However, that does raise additional problems:

1, it won't account for regeneration until you get damaged again (scripted or natural).
2, it won't account for any healing period until you get damaged again, though you could call the UpdateHP function every time a healing spell is cast at the creature or something
3, if you had, say, 10 mages unloading the default IGMS (20 missiles) at a target, that's already calling OnDamaged 200 times in about 3 seconds.  You wouldn't want/need to call this function that often, so you'd probably want to use a local int or something to make sure it doesn't fire more often than every 0.5-1.0 seconds or whatever.

In other words, it'd be workable, but requires more effort to set up and I don't know how much of a performance gain it would be (meaning I really have no idea, not that I'm sure they're roughly equal, see below).

FunkySwerve wrote...

That said, I wouldn't use your approach either - it sounds like an immense amount of unnecessary overhead.

Well, admittedly I understand very little of the technical aspects of NWN - you're the expert in that regard.  My thought process was to make the "heartbeat" extremely extremely simple to avoid the overhead.  The following is all that happens if the creature has NOT taken damage or healing since the previous call.

void UpdateHP(int nPrev, int nMax)
{

    int nCurrent = GetCurrentHitPoints(), nMassive;

    if (nPrev != nCurrent)
    {
    }

    DelayCommand(0.5, UpdateHP(nCurrent + nMassive, nMax));
}

1. Receive the arguments from the previous call
2. Retrieve the current hit points and set up another int called nMassive (which is 0)
3. Compare one of the arguments to currentHP and since they're equal do nothing
4. Call itself again in 0.5 (or 1.0 or 2.0 or whatever) seconds with equivalent arguments (since nMassive is still 0)

The main problem is that I don't know how expensive function calls are (and how DelayCommand affects that).  I assumed they were trivial, but if simply calling the function is a large constant while the work within the function is relatively immaterial, then obviously this approach could be made far more efficient by any of the following:

1, rework it to be put in OnDamaged  (and if the extra code within one script is seriously inconsequential compared to having another script running, then maybe you wouldn't even need the cooldown on running Update (though it might still be a good idea)).

2, have it run every, say, 6 seconds out of combat and every 0.5-1.0 seconds in combat.  I originally had it set up like this but it means you could go 5.99 seconds without any update if the creature entered combat right after the heartbeat ticked.  Not the end of the world, but I wasn't sure how much of a performance improvement it actually was.

3. Check to see whether an enemy is within 50 yards, and if so start running every second.  If not, don't run again for 12-18 seconds or whatever.

4. Only run while an enemy is in the area.  If no enemies are in the area, then stop running.  Start it back up with the OnEnter script for the area if enemies return.

1 and 4 require more work to set up, 2 and 3 have the potential problem of taking a few seconds to kick in.  In 3, for example, if an enemy moves from 51 yards to 30 yards in like 5 seconds and starts attacking with a ranged weapon, it could take 13 seconds for the percent/health pool to start updating.

So, yeah, it largely depends on how the engine handles things (and I don't know).  Is a separate script running a single line of code far more expensive than an existing script running 20 additional lines of code (obviously the actual operations matter, just as a general principle)?  How do psuedo heartbeat functions factor into that?

By default, my script has like 3 main actual operations per heartbeat.  If I added a while loop that checked the surrounding area or something, that would greatly increase the number of operations per heartbeat - but it still might be more efficient overall if the heartbeat itself was very expensive (regardless of the code in it).  #4 in the list up there seems like it might technically be the best solution (in OnExit, set a local int to 1 that indicates UpdateHP should stop running and then in OnEnter set it to 0 and call UpdateHP to restart the process, so only creatures in an area with enemies would have the heartbeat running), but you'd have to integrate that into every area's OnEnter/OnExit, which might be very complicated for some modules.

Modifié par MagicalMaster, 15 mars 2013 - 08:42 .

[FunkySwerve]

MagicalMaster wrote...

So, yeah, it largely depends on how the engine handles things (and I
don't know).  Is a separate script running a single line of code far
more expensive than an existing script running 20 additional lines of
code (obviously the actual operations matter, just as a general
principle)?  

I don't think so, but I can't say with any certainty.

How do psuedo heartbeat functions factor into that?

Psuedos take up about 5x the cpu of an equivalent heartbeat. You should use generally heartbeats instead on creatures, where they suit your needs. My general rule is to use a heartbeat instead of a psuedo if a) the function will be running less than ~20% of server uptime, it will actually run (some heartbeats are very low in engine priority, like those on spawned-in placeables and AoEs), and c) a heartbeat meets your needs. Here, I would still use a psuedo despite a and b, because you need a pseudo for the faster-than-6-second cycling - a heartbeat just doesn't meet your needs ©.

By default, my script has like 3 main actual operations per heartbeat.  If I added a while loop that checked the surrounding area or something, that would greatly increase the number of operations per heartbeat - but it still might be more efficient overall if the heartbeat itself was very expensive (regardless of the code in it).  #4 in the list up there seems like it might technically be the best solution (in OnExit, set a local int to 1 that indicates UpdateHP should stop running and then in OnEnter set it to 0 and call UpdateHP to restart the process, so only creatures in an area with enemies would have the heartbeat running), but you'd have to integrate that into every area's OnEnter/OnExit, which might be very complicated for some modules.

I agree, I would absolutely cut off the pseudo if there's no pcs in the area. Looping pcs and comparing their area to that of the caller is a very fast operation. After all, it's the players' perceptions your script is concerned with.

Anyway, I can understand why you did use ondamaged. I don't really see many good alternatives if you're concerned with universalizibility. Otherwise, I would just use nwnx_funcs' SetMaxHitPoints, though frankly, we haven't had to, given regen, damage reduction/resist/immunity, etc, and acaos WROTE the darn function.

Funky

Modifié par FunkySwerve, 15 mars 2013 - 09:50 .

[MagicalMaster]

FunkySwerve wrote...

I agree, I would absolutely cut off the pseudo if there's no pcs in the area. Looping pcs and comparing their area to that of the caller is a very fast operation. After all, it's the players' perceptions your script is concerned with.

...that actually gives me an idea.  Perception.

Whenever the creature perceives an enemy and a local int called "updatehp" is not true, it sets a local int on itself called "updatehp" to 1 and starts the script running, but only one time.  On each of the subsequent psuedo-heartbeats, it checks the areas of all PCs and if it doesn't find one in the same area, it sets "updatehp" to 0 and returns.

So now the psuedo-heartbeat is not running.  But when it is approached by an enemy in the future, the perception fires again and the psuedo starts back up.

Would that work?  Or is a PC permanently considered "perceived" once a creature has seen it once?

This would eliminate the need for any OnEnter/OnExit scripts and would stop any pseudos from running when no PCs are around.

Also, how much more expensive would it be to loop through creatures within 35 yards compared to looping through all PCs?  Solely dependent on the number of creatures within 35 yards or inherently more expensive?  Because if a PC ran away from a creature, the psuedo wouldn't stop until all PCs left the area - as opposed to stopping as soon as no PCs can perceive it, which would theoretically be better.

Edit: Could also check the distance between each PC and the creature - if there is no PC between 0.1 and 35.0, stop running it (since GetDistanceBetween returns 0.0 as an error).

If that works well, still one major issue: naming (since the script is no longer in OnSpawn).  Would have a few options.

1. Tell people to put a single line of code in the OnSpawn that adds on the six characters.
2. Have it run the first first time the script is called (setting a local int called "named" or something so it only runs once)
3. Have it run if the far right character isn't "%" - under the assumption no one would ever end a default name with that

FunkySwerve wrote...

Anyway, I can understand why you did use ondamaged.

Was that meant to be "didn't use ondamaged?"

FunkySwerve wrote...

I don't really see many good alternatives if you're concerned with universalizibility. Otherwise, I would just use nwnx_funcs' SetMaxHitPoints, though frankly, we haven't had to, given regen, damage reduction/resist/immunity, etc, and acaos WROTE the darn function.

Well, the MassiveHP part was a later addition, the health percentages were the initial goal.  But I was faced with a situation when building when I either had to add immunity to a creature or somehow increase its hit points massively - and I didn't want issues with Divine Might/Favor piercing through immunity or have the creature be the only one with damage immunity like that.  I had previously used the rough concept of MassiveHP in an OnDamaged script elsewhere, so I formally adapted it as a general script versus specific for one creature (since I was under the time pressure of the ABC, didn't have time to overhaul the combat system).

So if we can figure out a good way to minimize overhead but still update enough to make it relatively smooth, you'd be free to use the percentages part if you're interested in that while ignoring (and/or deleting/commenting out) the MassiveHP part.

Modifié par MagicalMaster, 15 mars 2013 - 11:22 .

[FunkySwerve]

MagicalMaster wrote...

Would that work?  Or is a PC permanently considered "perceived" once a creature has seen it once?

No, players can move in and out of perception. I'm not sure it's a good alternative, though, since it requires perception - think sneaking, invisibility, sanctuary, etc.

Also, how much more expensive would it be to loop through creatures within 35 yards compared to looping through all PCs?  Solely dependent on the number of creatures within 35 yards or inherently more expensive?  Because if a PC ran away from a creature, the psuedo wouldn't stop until all PCs left the area - as opposed to stopping as soon as no PCs can perceive it, which would theoretically be better.

Edit: Could also check the distance between each PC and the creature - if there is no PC between 0.1 and 35.0, stop running it (since GetDistanceBetween returns 0.0 as an error).

Distance comparisons are more costly than looping through pcs. Can't say how much more, but I'm guessing a factor of 10 at least, on average.

If that works well, still one major issue: naming (since the script is no longer in OnSpawn).  Would have a few options.

1. Tell people to put a single line of code in the OnSpawn that adds on the six characters.
2. Have it run the first first time the script is called (setting a local int called "named" or something so it only runs once)
3. Have it run if the far right character isn't "%" - under the assumption no one would ever end a default name with that

Not sure what you're getting at here, since I haven't read the script. Is the percentile health being added to the end of the critter's name? Should've figured, I guess - health bar would mean engine hacks, and nonuniversalizable.

Was that meant to be "didn't use ondamaged?"

Yup, sorry.

Funky

[MagicalMaster]

FunkySwerve wrote...

I'm not sure it's a good alternative, though, since it requires perception - think sneaking, invisibility, sanctuary, etc.

Isn't that exactly WHY it would be a good alternative?  If a rogue is sneaking past a bunch of mobs, none of them will have this script start running because they never perceived him.

FunkySwerve wrote...

Distance comparisons are more costly than looping through pcs. Can't say how much more, but I'm guessing a factor of 10 at least, on average.

Does that include GetFirstObjectInShape loops?  I'm guessing it's probably more expensive than looping through PCs, but I'm wondering by how much - being able to stop the script from running if a PC leaves the visual range of a creature after it perceived him (while the PC is still in the area).

FunkySwerve wrote...

Not sure what you're getting at here, since I haven't read the script. Is the percentile health being added to the end of the critter's name? Should've figured, I guess - health bar would mean engine hacks, and nonuniversalizable.

Correct.  Adds on 6 characters and then adjusts those six as needed.  Looks like this:



Can see it briefly in action here: http://www.youtube.c...f0caA-3Dw#t=75s

[MagicalMaster]

Pulled the file for now - will repost with some major efficiency improvements tomorrow.

Goals:
- Won't execute until PCs engage enemy, so you can spawn enemies up ahead without eating up any resources
- Won't execute if PCs leave the area, meaning not cleaning up creatures shouldn't be a problem.

More info tomorrow.

[Nissa_Red]

I watched your video yesterday, and I must say that I was intrigued.

Not that much by the "adding inordinate" (to me) amounts of HP to monsters" feature, but by uncoupling the HP as the game perceives it (the condition that the creature is in, "badly wounded" in your screenshot above) from the HP as the player would perceive it ("10 000 hp").

I would be very interested in your system if you also ported it over to the player character (I can't tell if that's already how it works, since it seems that you've pulled the files).

To motivate my request, please let me explain that my background is the one of a party/single-player module builder. If your system manages the player character's HP in the same way that it manages monster's HP, it would allow for some very high level stuff, like locational damage, or additional "HP/health" parameters, like "stamina" or why not "sanity" and "psy points". Would it possible to extend it ? or is that not your goal at all ?

On a side note (and this has perhaps already been adressed by you, or Funky), how does your system behave when fighting several creatures ? several PCs fighting several creatures in different areas (PW) ? I imagine there's a limit : what is the recommended one to avoid TMI's ?

Also, I see a potential for abuse if players ran across your server, attacking every creature they happen to find, just enough time to initiate the pseudo-HBs, and then leave your server crawling under the extra pressure of the scripts.

Thank you for sharing your discoveries and work with us.

[ffbj]

Yeah! I dl'd it before it got pulled. I was going to fool around with it this weekend.
I like the modular aspect. So for instance if you were concerned about lag from so many creatures having it you could use just the maximum hp part of Boss monsters. In that instance you would usually only have 1 creature running the script at any 1 time.
You could also have some of you lesser creatures that came in as single individuals or pairs running the other scripts. For instance I don't think you want this script to be on rats.
So I guess what I am getting at is that you would only have a limited number of creatures with the scripts on them.

As far as extending it to players as Nissa_Red suggests I imagine that would be possible. I currently have a stamina system, but it is probably more expensive than this as it is checking AC, PC condition(poisoned, diseased, wounded), shield/ weapon size. But in single player since it's only ever running of 1 PC you can get away with a lot more.  My fatigue method only fires in combat.  Out of combat you recover fatigue naturally just standing around revovers up to 50% of your max fatigue, while potions and campfires can boost it too.
Resting naturally recovers all fatigue. Finally nagging wounds reduce your maximum fatigue and how much fatigue you have is based on your class/con/str. 

Modifié par ffbj, 16 mars 2013 - 03:03 .

[FunkySwerve]

MagicalMaster wrote...

FunkySwerve wrote...

I'm not sure it's a good alternative, though, since it requires perception - think sneaking, invisibility, sanctuary, etc.

Isn't that exactly WHY it would be a good alternative?  If a rogue is sneaking past a bunch of mobs, none of them will have this script start running because they never perceived him.

Not really - you're concerned with player perception, not monster perception. My point was that this would yeild inconsistent play experience. Of course, if a player isn't damaging a monster, it's entirely possible that you just don't care about having a 100% by its name.

As for closing it down when a player leaves perception, that's also problematic, since some monsters heal via regen.

I really haven't taken the time to work through all the permutations, but you're going to have to do some fine-tuning. I still think it'll work, though.

Funky

[Nissa_Red]

ffbj wrote...
As far as extending it to players as Nissa_Red suggests I imagine that would be possible. I currently have a stamina system, but it is probably more expensive than this as it is checking AC, PC condition(poisoned, diseased, wounded), shield/ weapon size. But in single player since it's only ever running of 1 PC you can get away with a lot more.  My fatigue method only fires in combat.  Out of combat you recover fatigue naturally just standing around revovers up to 50% of your max fatigue, while potions and campfires can boost it too.
Resting naturally recovers all fatigue. Finally nagging wounds reduce your maximum fatigue and how much fatigue you have is based on your class/con/str. 

That sounds very interesting to me.

Instead of reinventing the wheel, may I ask if you made your system publicly avalaible by chance, ffbj, so that I could perhaps have a look at it ?

[MagicalMaster]

Version 3 is up.  Chunk of code provided to cover a fringe scenario.  Extra work to install for little gain, but possible if you want to do it:

- Chunk of code provided to place in OnEnter script for areas to avoid having an incorrect health percentage for a few seconds if a player attacks a regenerating creature and retreats (leaving the area entirely) without killing it and returns before the monster despawns (player would see an incorrect health percent for a few seconds upon returning before the script started running again)

Version 2 is up. Takes one additional (simple) step to install with the following improvements:

- Called with OnPerception when an enemy or PC approaches to avoid using resources until needed
- Shuts down if all PCs leave the creature's area and starts back up when approached again
- Calls itself every second by default once triggered (compared to previous 0.5 seconds), speeding up to 0.5 seconds if the creature is using MassiveHP and below 3000 raw hit points

Nissa_Red wrote...

Not that much by the "adding inordinate" (to me) amounts of HP to monsters" feature, but by uncoupling the HP as the game perceives it (the condition that the creature is in, "badly wounded" in your screenshot above) from the HP as the player would perceive it ("10 000 hp").

You'd be surprised how fast a group of PCs and/or henchmen can chew through HP unless you give high immunity/resistance to damage.

Nissa_Red wrote...

I would be very interested in your system if you also ported it over to the player character (I can't tell if that's already how it works, since it seems that you've pulled the files).

The general principle of MassiveHP can be applied to players...but the health percentage cannot because SetName does not work on player characters.  Which means the player would have a hard time knowing how much HP (s)he is supposed to have.

Nissa_Red wrote...

To motivate my request, please let me explain that my background is the one of a party/single-player module builder. If your system manages the player character's HP in the same way that it manages monster's HP, it would allow for some very high level stuff, like locational damage, or additional "HP/health" parameters, like "stamina" or why not "sanity" and "psy points". Would it possible to extend it ? or is that not your goal at all ?

Yes, locational damage, stamina, and all of that sort of stuff is entirely possible, since in effect it's a puesdo heartbeat firing on the PC.  It would be easy to set it up so that taking more then X damage would have a chance of causing some severe injury or something, though that would be taking the method behind the system (pseudo heartbeat) and applying it to something else entirely.

My goal really isn't to extend this particular script - the goal was a modular script that is easy to install and not performance intensive that shows health percentages and allows for high hit point pools if needed.  I could probably set up a separate script for what you're talking about, though .

Nissa_Red wrote...

On a side note (and this has perhaps already been adressed by you, or Funky), how does your system behave when fighting several creatures ? several PCs fighting several creatures in different areas (PW) ? I imagine there's a limit : what is the recommended one to avoid TMI's ?

In my module (single player, level 40, high damage/lots of spells/abilities going off), I had probably 60ish creatures spawned with the script running with zero issues, and that was the older version of the script (where 40 of those 60 creatures were in another zone entirely).  It's never caused a TMI because that usually means an infinite loop or something that loops way too much - the "overhead" of this script is simply the fact it's called freqently.

I don't know how the older version would hold up to a  PW with 10+ players and potentially a few hundred monsters spawned, though, which is why I revamped it to only have it running where needed.  For example, if you were building a module and placed monsters manually instead of spawning them, having 1000 monsters alive and running this script probably would have caused an issue.

With the new version, it won't, because the script won't fire until the creature is approached and it'll shut down when the player leaves.

Nissa_Red wrote...

Also, I see a potential for abuse if players ran across your server, attacking every creature they happen to find, just enough time to initiate the pseudo-HBs, and then leave your server crawling under the extra pressure of the scripts.

Well, in the original version, they didn't even have to attack the creature, it just started running on the spawn.  Now they have to attack the creature, but if they leave the area it shuts down, which prevents that abuse.

ffbj wrote...

Yeah! I dl'd it before it got pulled. I was going to fool around with it this weekend.

Sorry!  New version is up now.  I just didn't think of the potential for someone to place 1000 monsters manually in the toolset or something because I try to make sure not too many creatures are spawned at once.  Didn't want someone to download the old version, try running it in a module like that, and have massive issues.

New version doesn't require the builder to worry about anything like that (or rather, my script won't make the situation any worse than it already would be in that situation).

ffbj wrote...

I like the modular aspect. So for instance if you were concerned about lag from so many creatures having it you could use just the maximum hp part of Boss monsters. In that instance you would usually only have 1 creature running the script at any 1 time.

You could also have some of you lesser creatures that came in as single individuals or pairs running the other scripts. For instance I don't think you want this script to be on rats.
So I guess what I am getting at is that you would only have a limited number of creatures with the scripts on them.

Especially with the new version, it honestly shouldn't matter.  As I mentioned, I had the older, more generally inefficient script running on 60+ creatures with massive 20 creature battles going on without issue.  But yes, you could limit it to more powerful enemies - you probably don't care about the exact health percent of a rat with 4 HP.

FunkySwerve wrote...

Not really - you're concerned with player perception, not monster perception. My point was that this would yeild inconsistent play experience. Of course, if a player isn't damaging a monster, it's entirely possible that you just don't care about having a 100% by its name.

The new version has the 100% placed at spawn - it just doesn't update until perception occurs, and it only needs to update (generally speaking) if combat occurs.

FunkySwerve wrote...

As for closing it down when a player leaves perception, that's also problematic, since some monsters heal via regen.

True, in theory a player could attack a monster down to 50% HP and then run away.  While he's absent, the creature could heal back to full but the HP would still say 50%.  Then when the player comes back, it would still say 50% until the monster perceives the player again, at which point the percent will adjust to the correct amount.

So until the player engaged again, the 50% would be inaccurate, but a second later it would be correct (might mislead the player, though).

However, so far I'm not thinking of a solution to that situation that's easily implemented within the main code - dramatically raising the cost of the pseudo to try to cover fringe scenarios like that doesn't seem to be worth it.

One possibility might simply be to say that if builders are considered about that that situation, they can set up a small chunk of code in an area's OnEnter that calls the script on any creatures which are alive (instead of waiting for perception again since the creature already engaged in combat and thus might have regenerated health).  I've uploaded v3 which includes the following code fragment in the comment section at the top of the bulk script which accomplishes that purpose:

object oCreature = GetEnteringObject();

if (GetIsPC(oCreature))
{
    oCreature = GetFirstObjectInArea(OBJECT_SELF);
    while (GetIsObjectValid(oCreature))
    {
        if (GetObjectType(oCreature) == OBJECT_TYPE_CREATURE && !GetLocalInt(oCreature, "updatehp"))
        {
            SetLocalInt(oCreature, "updatehp", 1);
            ExecuteScript("mm_updatehp", oCreature);
        }

        oCreature = GetNextObjectInArea(OBJECT_SELF);
    }
}

Modifié par MagicalMaster, 17 mars 2013 - 08:05 .

[Nissa_Red]

Thank you for your extensive reply.

I understand in which context you've developed it, and in which most other builders will probably use it, since it would reach its full potential there : well equipped and high-level characters.

Just saying that my players (well their characters) will probably die out of old age before being able to kill a 100 000 hp boss ^.^ My module is really meant to be rather low-key in levels and quality of equipment, focusing on story and survival instead. Being able to manage locational damage, and/or potentially other secondary systems, is therefore the *true* value of your system to me, at least in a first time. Also, the fact that players can't see their "true" current hp is another plus to me. Not excluding anything though, who knows what other good things it could inspire me in a second time.

My real concern was mostly on the side of the extra scripting load this system would apply to a module, and you have adressed it. I am now eager to get it up and running, so that I can test it and use it.

I would like to thank you again for sharing, documenting and supporting this system as you do.