How bad are Pseudo HB's?

[Legacy_Mudeye]

               The heartbeat may run for each area, but if there is no heartbeat script it just checks that there is no script and goes on.  If there is a script then the overhead of running that script happens every heartbeat.  If you put the script in every area then that overhead adds up.

If you could put some notification information in a variable that indicated that an area(s) needed updating then a single hb script could check that variable and then update the required area(s).
               
               

               

                     Modifié par Mudeye, 24 juin 2011 - 05:54 .
                     
                  

            

[Legacy_henesua]

               The reason I ask is to defend my suggestion. If you only have two instructions typically running in a HB script (setting a variable and checking a variable) then you are not noticeably adding overhead. Its a minor hit at best even with a 1000+ areas. The engine as far as I understand it, essentially runs the HB event on every area regardless of whether you assign a script.

If NWN has a way of shutting off events that do not have scripts assigned to them, then I agree it is a problem to add scripts to HB events. But I don't believe NWN functions this way. If it does, then I am pleasantly surprised.
               
               

               
            

[Legacy_FunkySwerve]

               

henesua wrote...

I believe the heartbeat event runs for each area regardless of whether you apply a script to a particular event. Anyone have evidence to the contrary?

Do you have any evidence to support this belief? I never saw a Biowarean say as much.

From my discussions with virusman on the subject, every object in the mod is checked in something akin to a giant loop, up until a point when the game hits a given limit (which is why day/light would break, as well, under load). This isn't really like a heartbeat event 'running' when blank. Adding code to execute, especially in every area, is only going to slow things down. I'll point him to this thread and see if he wants to elaborate.

Either way, it's sort of irrelevant, again, because you still wind up executing extra code to no gain. 'It's only a little wasteful' is not an argument for doing something, especially when there are simpler ways to do it more efficiently, and especially when you're doing it a lot. Doing a number of things that, individually, don't add 'noticably' to overhead can add up to some VERY noticable overhead - the death of a thousand cuts, as it were. If you want efficiency, keep your code execution to a minimum.

Also, in your last post, you confused functions with instructions:

If you only have two instructions typically running in a HB script (setting a variable and checking a variable) then you are not noticeably adding overhead.

An instruction refers to machine code, and has no direct correlation to a function - a function can comprise many instructions. Likewise, the TMI limit applies to instructions, not functions.

Funky
               
               

               
            

[Legacy_henesua]

               

FunkySwerve wrote...

Either way, it's sort of irrelevant, again, because you still wind up executing extra code to no gain. 'It's only a little wasteful' is not an argument for doing something, especially when there are simpler ways to do it more efficiently, and especially when you're doing it a lot..

Not at all. The argument that it is not very wasteful is relevant because NWN is structured for you to use it in the way I suggested. Which makes it easier for a team to maintain the code, and simpler to implement. Complicated code maintained by an amateur team can get ugly. For a well organized team or a team of one - do whatever you like, but for the typical NWN PW with a team of folks coming and going its just much easier and effective to use the engine in the obvious way.

Now I don't mean to say that what you suggested is problematic. I understand your point about efficiency, and respect it. But my thinking is that if the engine checks heartbeat events every 6 seconds, you are not achieving much by avoiding them because the overhead is already there.

Throwing an extra apple on the apple cart is no big deal.

But if you are creating the apple cart, then I agree its not worth it.

So yes, I would like that clarified if anyone knows. Occam's razor alone suggests to me that the engine functions the way I assume it does. But I would be happy to be proven wrong. I just want to know.
               
               

               
            

[Legacy_FunkySwerve]

               Eh, fair enough. I do understand and agree with there being a trade-off between simplicity and efficiency. I think I would tend to go with six's method, though, in that case. Unless there were a lot of different types of area effects besides weather, in any case, at which point readability and compartmentalization of code would probably send me towards different heartbeats on the different areas. Then, if I found pseudos too complex or bothersome, I guess I would opt for area heartbeats. Compartmentalization is one of the reasons we use area entry pseudos to begin with.

I did ask virusman to comment, if he wanted, but there's a good chance he's asleep at the moment.

Funky
               
               

               
            

[Legacy_virusman]

               

henesua wrote...

I believe the heartbeat event runs for each area regardless of whether you apply a script to a particular event. Anyone have evidence to the contrary?

When there is no script in OnHeartbeat slot, there is nothing to run.
The overhead of just having an empty area with no scripts is minimal: CNWSArea::AIUpdate only updates weather and calls Heartbeat script every 6 seconds if there is one.
DelayCommand uses complex structures, high resultion timers, saves and restores script situation data - all of this uses more CPU than a simple check in HB timer.
               
               

               
            

[Legacy_henesua]

               

virusman wrote...
When there is no script in OnHeartbeat slot, there is nothing to run. The overhead of just having an empty area with no scripts is minimal: CNWSArea::AIUpdate only updates weather and calls Heartbeat script every 6 seconds if there is one.

Thanks for the information. Thats helpful.

What I was referring to as overhead for area HB events is apparently CNWSArea::AIUpdate, since that is what calls Heartbeat scripts. So there IS something to run whether or not you link a script to an area's heartbeat event. However you seem to be suggesting that the process is extremely efficient if there are no heart beat scripts to call.

So is it the case that even a very simple heartbeat script suddenly generates measurable overhead? Even one in which only one or two lines of script are called? I would assume not since the scripts are compiled rather than interpretted, but I don't really know what "compiled" means in an NWN module.

Also does the overhead of CNWSArea::AIUpdate increase as you add areas even if you have no HB event scripts?
               
               

               
            

[Legacy_Shadooow]

               

henesua wrote...

virusman wrote...
When there is no script in OnHeartbeat slot, there is nothing to run. The overhead of just having an empty area with no scripts is minimal: CNWSArea::AIUpdate only updates weather and calls Heartbeat script every 6 seconds if there is one.

Thanks for the information. Thats helpful.

What I was referring to as overhead for area HB events is apparently CNWSArea::AIUpdate, since that is what calls Heartbeat scripts. So there IS something to run whether or not you link a script to an area's heartbeat event. However you seem to be suggesting that the process is extremely efficient if there are no heart beat scripts to call.

So is it the case that even a very simple heartbeat script suddenly generates measurable overhead? Even one in which only one or two lines of script are called? I would assume not since the scripts are compiled rather than interpretted, but I don't really know what "compiled" means in an NWN module.

Also does the overhead of CNWSArea::AIUpdate increase as you add areas even if you have no HB event scripts?

There is still a question that if you need heartbeat for each area why do you dont use modules's heatbeat and then do stuff on each area.
               
               

               
            

[Legacy_GhostOfGod]

               I was planning on putting a blank HB script in all areas as I'm building them just in case I want to put something in later. Now I'm not sure if I should. How much of a resource difference are we talking here?
               
               

               
            

[Legacy_FunkySwerve]

               Vman's strong preference was for a single modwide heartbeat, when we discussed it at length. That is, unless you have area scripts like drowning, which are somewhat time-critical, in which case he thought pseudos appropriate for those specific applications only. His ideas basically map to mine, though he isn't as fond of pseudos as I am.

There's no profiler that includes this kind of data, so there's no way to tell how much time with certainty. What IS certain is that it's wasting some, and that there's no need to put in placeholder heartbeats. If you need, you can Moneo them in later in a matter of a few minutes. I'll be happy to show you how - it's an incredible utility for any builder to have, making mass edits simple.

Neither vman nor myself could think of any reason to favor using 600 (or whatever your mod's area count is) individual heartbeats over a single mod heartbeat. If you're doing one thing in all areas, it makes no sense at all. Even if you have a fair amount of different applications in different areas, looping pcs and checking their areas was his preferred method (mine is generally pseudos there, in part because of modularity). Both of us think using one heartbeat per area is nuts.

To answer the OPs question, which I just realized I'd overlooked, no, putting pseudos in your areas will not result in you having 1 per area running constantly, if you set them up as area pseudos should be - to start when a player enters the relevant area, and to stop when the area is empty (all that can be done from the onenter script of the area). The only advantages pseudos have over heartbeats are flexibility and precision. You can turn them on and off at will, specify intervals which will be strictly adhered to, and specify start and stop conditions. If you don't take advantage of that flexibility to specify conditions that ensure the pseudo is running for 20% of uptime or less, you're spending more in cpu than a comparable heartbeat. You ensure that, for example, by only having them run when the players are in a given area. Still, though, if you plan to put the same pseudo in every area, then you're going to be wasting a lot of cpu as compared to a module heartbeat (nevermind individual area heartbeats, which are a complete waste), because you're going to have at least 1 pseudo running whenever anyone is around to care about the overhead - more, if your server isn't particularly party-oriented.

Funky
               
               

               

                     Modifié par FunkySwerve, 25 juin 2011 - 02:56 .
                     
                  

            

[Legacy_henesua]

               

ShaDoOoW wrote...
There is still a question that if you need heartbeat for each area why do you dont use modules's heatbeat and then do stuff on each area.

I think it depends on what you are doing. I do use a mod heartbeat and loop through PCs but I limit this to PC specific functions. There are many features that one can potentially add specifically for PCs in the PC Loop and I think there is a danger of putting too much in it. Also if you have many players, I would think that strapping everything into the PC loop could scale poorly.

Regarding weather, I think it would be better handled in area heartbeats as opposed to the mod heartbeat if the majority of areas are not exterior. That way the script is where you expect it to be, and you are not trying to do everything in the mod heartbeat's PC Loop. You also do not need to add this particular script to every area, only the ones that have weather which you want to control.

In my view, efficiency is only one part of the equation. More important to me is writing scripts that a team can easily maintain. After inheriting a very old persistent world and digging into the scripts, I could see first hand how establishing a clean and rational design to your scripts is probably the most important element of scripting for that world. So for that reason I don't see why (if you are working on a group project which the OP seems to be doing) you'd stick weather in a PC loop when you could use area focused scripts.

Now it is very likely that pseudos in the onenter for an area script are the best solution - because its relatively well organized, effcient, and probably scales well with increased players - but until I run into a problem with area heartbeats I prefer to use the events as they were intended to be used.
               
               

               
            

[Legacy_FunkySwerve]

               

henesua wrote...

ShaDoOoW wrote...
There is still a question that if you need heartbeat for each area why do you dont use modules's heatbeat and then do stuff on each area.

I think it depends on what you are doing. I do use a mod heartbeat and loop through PCs but I limit this to PC specific functions. There are many features that one can potentially add specifically for PCs in the PC Loop and I think there is a danger of putting too much in it. Also if you have many players, I would think that strapping everything into the PC loop could scale poorly.

The only danger of putting too much in it is one of inefficiency. There's no question that individual area heartbeats are worse in this regard. The only plausible reason for wanting to split them up is modularity, and there, as you say, pseudos are likely a better choice, if slightly more complicated than simply using the event bioware provided.

Now it is very likely that pseudos in the onenter for an area script are the best solution - because its relatively well organized, effcient, and probably scales well with increased players - but until I run into a problem with area heartbeats I prefer to use the events as they were intended to be used.

I assume that you'r simply reiterating your point about simplicity of use, especially in a team, in a different way. That's a totally valid goal, but the way you phrase it here, as adhering to the intents of the designers, is a terrible justification for doing anything. By way of example, they presumably intended builders to use the database package they put in the program, and it's atrociously bad. You have to remember they were on a production schedule, and hadn't had anything like the amount of time the community has had to tinker. There are usually better ways of doing things than the way they originally coded them, even when simplicity is of primary concern.

Funky
               
               

               
            

[Legacy_henesua]

               

FunkySwerve wrote...
The only danger of putting too much in it is one of inefficiency. There's no question that individual area heartbeats are worse in this regard. The only plausible reason for wanting to split them up is modularity, and there, as you say, pseudos are likely a better choice, if slightly more complicated than simply using the event bioware provided.

Modularity is one reason, and the one I am using , but its not the only plausible reason. Isn't there a danger of TMI?

I assume that you'r simply reiterating your point about simplicity of use, especially in a team, in a different way.

No, I was simply bringing the subject back for the OP, so as to keep this on topic. And add that I also agree with you that the onEnter pseudo heartbeat can be the best solution for this application.

That's a totally valid goal, but the way you phrase it here, as adhering to the intents of the designers, is a terrible justification for doing anything. By way of example, they presumably intended builders to use the database package they put in the program, and it's atrociously bad. You have to remember they were on a production schedule, and hadn't had anything like the amount of time the community has had to tinker. There are usually better ways of doing things than the way they originally coded them, even when simplicity is of primary concern.

I disagree. Arguments like yours keep some terrible game dev tools alive when they should die. (No, I do not think NWN should die. I am referring in particular to a commercial grade engine.) As a rule I use an engine as it was intended. If I need to make a few exceptions here and there that is alright, but when I find that more often than not I am working against the engine to achieve what i want, I will use something else.

I typically use Unity. NWN is for me an opportunity to avoid making custom game assets (textures, models, sounds etc...) and instead focus on protyping a role playing game. I've never made one before, and don't have the ability or time to make one from scratch on my own. After NWN, I'll go back and give it a shot. I've already learned the lessons by remaking a PW, and now I'm on to a single player thing. Its been lots of fun. NWN is good fun, but its maddening the amount of hard coded limitations one has to deal with. Pseudo Heartbeats being in my view just another example of a work around.
               
               

               

                     Modifié par henesua, 25 juin 2011 - 06:51 .
                     
                  

            

[Legacy_DM_Vecna]

               After looking I am not using a module heartbeat script nor a area. I use onEnter to save location and (onExit with psudo) to track posulation, clean up areas,  etc. But I am curious what others find that they use onmodheartbeat for? Maybe there are some good suggestions for some fun stuff I have not looked at yet. '> Weather makes sense but I am not sure what else.
               
               

               
            

[Legacy_FunkySwerve]

               

henesua wrote...

FunkySwerve wrote...
The only danger of putting too much in it is one of inefficiency. There's no question that individual area heartbeats are worse in this regard. The only plausible reason for wanting to split them up is modularity, and there, as you say, pseudos are likely a better choice, if slightly more complicated than simply using the event bioware provided.

Modularity is one reason, and the one I am using , but its not the only plausible reason. Isn't there a danger of TMI?

Fair enough, especially if you're going single player, as you say below. Generally, though, this shouldn't be an issue, and you can always avoid it by AssignCommanding problem segments of code to start the TMI count over. If you're dealing with multiplayer NWNX, you can just use the TMI plugin to up the limit temporarily, as we do on modload. It's worth remembering that the TMI limit is only there to prevent those with less experience from shooting themselves in the foot, so to speak (as well as to alert the rest of us to a loop problem). The devs just neglected to provide an off switch for the rest of us, though the community has seen to that since (via one of your 'terrible game dev tools' '> ).

I disagree. Arguments like yours keep some terrible game dev tools alive when they should die. (No, I do not think NWN should die. I am referring in particular to a commercial grade engine.) As a rule I use an engine as it was intended. If I need to make a few exceptions here and there that is alright, but when I find that more often than not I am working against the engine to achieve what i want, I will use something else.

Game dev tools like what, exactly? I'm only pointing out that religiously using certain techniques because they were put there by the designers will lead to some very bad results, given the options available. I don't see how that in any way supports the use of 'terrible game dev tools'. Good ones, sure.

NWN is good fun, but its maddening the amount of hard coded limitations one has to deal with. Pseudo Heartbeats being in my view just another example of a work around.

Recursive functions aren't exactly some newfangled thing... In any event, it is PRECISELY these types of limitations that call for end user workarounds. I'm having difficulty understanding why you malign willingness to use them when available as keeping terrible dev tools alive, and then complain about limitations militating for the use of such workarounds in the next breath.

Anyway, we should probably continue this in pms, to prevent further sidetrackig of the thread. I'll put future responses there, unless they have  more direct bearing on the topic.

Funky