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 .
