16 réponses à ce sujet

[WhiteTiger]

To save the processor is recommended to cancel the actions if there is no players in?

[Shadooow]

yes they fire heartbeat no matter whether there are any players, same for creatures, placeables, AOEs everything

[Lightfoot8]

only two things will not fire a HB,   1)  a dead creature.  2) an inactive encounter. 

[WhiteTiger]

thank you Lightfoot8 and the community patch fundator

[Ed Venture]

I have several areas with HB scripts that handle lighting, population spawns, ect.

I put them on a plot placeable in the center of the area.

The script is always conditional to if the PC is in the area. If the PC is in the area, the main body of the script fires. If not, only the condional fires. I'm using an old Hp with Pentium4, and have not yet noticed any lag at all.

 

Ed

[Shadooow]

I have several areas with HB scripts that handle lighting, population spawns, ect.

I put them on a plot placeable in the center of the area.

The script is always conditional to if the PC is in the area. If the PC is in the area, the main body of the script fires. If not, only the condional fires. I'm using an old Hp with Pentium4, and have not yet noticed any lag at all.

 

Ed

heartbeats are indeed not that harmful as some claims

 

For example, when I joined Arkhalia PW builder team and gain access to areas I found out one area where someone placed 100 gargoyle statues (which all running heartbeat) only as a decoration. And this was there several years and it wasn't problem - Arkhalia was always fast and stable.

 

Pseudo heartbeats are often even worse replacement because there is a memory bloating issue when structures like effect or itemproperty are passed in (*acaos said that somewhere - I believe him). And generally are slightly worse, the only advantage is that pseudo heartbeats are not running all the time.

 

Personally used heartbeat for player, but not default.nss! because this script is running for all script created traps which in my module are many. I changed the PC heartbeat script via NWNX. And one heartbeat on placeable for LootBag cleaning purposes.

[WhiteTiger]

werewolf heartbeat scripts cause much lag? we have about 11 scripts werewolf OnHeartbeat

[WhiZard]

Personally used heartbeat for player, but not default.nss! because this script is running for all script created traps which in my module are many. I changed the PC heartbeat script via NWNX. And one heartbeat on placeable for LootBag cleaning purposes.

 

You can also simulate the PC heartbeat by using a GetFirst/NextPC() loop in the module heartbeat.  This is already done for adding the AC bonus for mounted combat.

[WhiZard]

werewolf heartbeat scripts cause much lag? we have about 11 scripts werewolf OnHeartbeat

 

 

Would need to see the scripts for the werewolf heartbeats to determine if they caused much lag.  That being said most lag is associate with actions, animations, and visual changes.  Retrieving and setting information will run into a TMI error long before it causes noticeable lag.

[Shadooow]

You can also simulate the PC heartbeat by using a GetFirst/NextPC() loop in the module heartbeat.  This is already done for adding the AC bonus for mounted combat.

true, but why to simulate something when you can have it for real (and I dont use horses at all)

[WhiZard]

If you desire separately executed scripts for each PC then executing these scripts from the module heartbeat really doesn't add in that much to processing time, while incorporating the PC heartbeat into the module heartbeart saves processing time.  So I'm not sure what this 'real' factor actually accomplishes.  Its not like PC heartbeats coincide well with combat round beginning and endings.

[Shadooow]

If you desire separately executed scripts for each PC then executing these scripts from the module heartbeat really doesn't add in that much to processing time, while incorporating the PC heartbeat into the module heartbeart saves processing time.  So I'm not sure what this 'real' factor actually accomplishes.  Its not like PC heartbeats coincide well with combat round beginning and endings.

If I didn't have the NWNX option then yes I would do it this way instead of using a pseudo-heartbeats or default script. But I have NWNX so I can change the PC's hearbeat event to script of my choice.

 

The difference is significant. Module heartbeat would need to loop all PCs all the time and do stuff for each of them. In some situations this might be a good, but the bigger the module heartbeat is (in my I loop areas this way) the better is to detach it. Furthermore this do stuff for all PCs in same exact time so if you are saving players each six heartbeat then all players will be saved in exact moment which then can make lag (as if you used ExportAllCharacters - in module with 10+ players). Of course this could be workarounded by utilising the timer for each player separately, but then you are making the script more complicated then it would be if you used the real OnPlayerHeartbeat.

[WhiZard]

Furthermore this do stuff for all PCs in same exact time so if you are saving players each six heartbeat then all players will be saved in exact moment which then can make lag (as if you used ExportAllCharacters - in module with 10+ players).

 

There is always DelayCommand() which could even things out even better than counting on a random distribution to be an even spread.

 

But I guess the biggest difference is statescripts.2da.  The PC heartbeat is replaced by a different heartbeat when the PC is under certain effects.

[Shadooow]

There is always DelayCommand() which could even things out even better than counting on a random distribution to be an even spread.

Yes thats what I meant with the "of course this could be workarounded". Seriously suggesting using delays only to avoid using a PC heartbeat and do all the stuff from module heartbeat seems to me like an overkill.

 

But I guess the biggest difference is statescripts.2da.  The PC heartbeat is replaced by a different heartbeat when the PC is under certain effects.

Thats not problem for me - since I use CPP and the switch to set duration of all disable effects to 3 rounds. But you are right, I havent though of that - this could indeed be a problematic with a specific usage of PC heartbeat.

 

Anyway - just if you didn't know. There are lots of system using default.nss for various effects, PRC, DnD 3.5 ruleset among others. This is pretty efficient way and its very convinient especially for the 3.5 ruleset that this does work regardless of the module event so this can be used as override/patch. But since I found the issue with traps created in script running the same script I had to change this method.

[kalbaern]

_{I've never seen that heartbeats in general caused lag, but rather when its laggy they'll more often fail.}

 

_{Actually. let me qualify that. Heartbeats if used sparingly and sensibly shouldn't be a big lag concern. The key is "sensibly".  There's also the matter of priorities under which scripts/events are handled by the CPU over others. I.e, the module clock may fail/falter before anything else. Next comes placeables with heartbeats failing or firing only after extreme delays.}

 

_{The only true case of heartbeats on placeables causing server-wide lag issues was on a PW that over the years used lots (and I mean alot!) of CEP placeables that had lighting scripts to turn on/off, whether based on a PC nearby, time of day or toggling a switch IG. This PW had around 9,000 such instances in their module. After going through their roughly 500 areas and replacing/disabling all these things (which never worked anyhow due to lag) the IG clock began working, placeable gargoyles and other things now worked and lag in general decreased by leaps and bounds.}

 

_{On my own PW, I use lots of placeables with heartbeats. Being somewhat anal about efficiency though, I usually spawn the placeables in only when PCs enter the area and despawn them (if needed) after they have left. I use this not only for gargoyles and other statues that "come alive", but for mushrooms that glow in my underdark, petrified trees in a certain forest, obsidian statues (drop a shadow shield visual to a placeable statue), trees that "awaken" and are treants and many other things. That I also like to keep folk guessing, I usually have two versions of each of these things, one with the heartbeat event that will transform or do something and a second scriptless version that does nothing. Then I spawn things in semi-randomly. I.e., not every gargoyle statue is a true gargoyle or every tree a treant. Where Statue "A" was a gargoyle yesterday, today it could just be a inanimate statue.}

[WhiZard]

 

 

 _{There's also the matter of priorities under which scripts/events are handled by the CPU over others. I.e, the module clock may fail/falter before anything else. Next comes placeables with heartbeats failing or firing only after extreme delays.}

 

 

Just to note: Spawned placeables are different in priority than Toolkit placed placeables.  Spawned ones have very low priority, while placed ones seem to have higher priority than creatures and are quite reliable for heartbeats.

[FunkySwerve]

heartbeats are indeed not that harmful as some claims

 

For example, when I joined Arkhalia PW builder team and gain access to areas I found out one area where someone placed 100 gargoyle statues (which all running heartbeat) only as a decoration. And this was there several years and it wasn't problem - Arkhalia was always fast and stable.

 

Pseudo heartbeats are often even worse replacement because there is a memory bloating issue when structures like effect or itemproperty are passed in (*acaos said that somewhere - I believe him). And generally are slightly worse, the only advantage is that pseudo heartbeats are not running all the time.

 

Personally used heartbeat for player, but not default.nss! because this script is running for all script created traps which in my module are many. I changed the PC heartbeat script via NWNX. And one heartbeat on placeable for LootBag cleaning purposes.

This is just wrong. I'm happy to post a few hundred of acaos' pseudoheartbeats to prove the point, if I have to. Pseudoheartbeats are very often the best way to do something.

 

You're absolutely correct about the memory leak when structs are passed through recursive functions, but it's pretty easy to avoid that. We use only one permanent heartbeat on HG - the module heartbeat. Ours is pretty hefty, including MySQL calls, but it runs just fine. All other heartbeat functionality is implemented either on a temporary object (think creatures) where the heartbeat ends when the object ceases to be, or via pseudoheartbeat or other event (like timestamped area enter/exit). We don't use spawned in places for with heartbeats already on them, as they get low engine priority like AoE heartbeats. Instead, if we want the place itself to run the code, we'll use a pseudo on it.

 

While I agree that a lot of the dire warnings about heartbeats are overhyped, I have seen firsthand what too many and/or poorly written heartbeats can do to module performance. The PoA base module of HG when I first took over actually had a perceivable heartbeat, because of the absurdly bloated module heartbeat that was, among other things, cycling all player inventories several times a heartbeat. It would quite literally do a brief hang about every 7 seconds (not 6 - non-linux systems seem to have longer heartbeats in general, with our lin server turning over about every 5.2 seconds, but Win-based servers all seem more susceptible to increased delays between heartbeats due to serverload).

 

Once you work out how, it's not difficult to replace most heartbeat functionality in a more efficient way - and that will often include pseudos. Overhead is overhead, and while I don't hold to the extreme position that efficiency must override all other building concerns (that's just absurd thought-hyperbole, as you could waste countless hours to eek out a few saved cycles - think law of diminishing returns), I also believe in good coding practices, which means minimizing overhead when it's not difficult or overly time-consuming to do so.

 

Funky