NcSource talk:Programming psi healing shields

Ok, i (r2) am currently working on getting the basic PSI and DoT (damage over time) system implemented. There a several things i would want to discuss with you.

The Source-Engine has afaik an entities cap of 2048 entities. Having this cap we should avoid creating an entity for every single shields/heal/dot. So i thought that one could just implement one single logical entity serverside that keeps track of all the shields, heals and dots serverside. If someone casts a heal, the psi manager will be called and it creates a particle effect (an entity) which will be attached to the player and which (the particle effect) will also handle the hud thingy showing up on the client who got that heal. The time how long that heal will last will be controlled serverside but the user will see the progress bar we all know and love ;) The shields will be more or less silently be kept track of. Every second they will be checked whether they ran out or not and the entitys belonging to the specific gui elements on the clients will be updated. So the gui elements are the only entites which are created. The shield particle effect will be created once a player recieves damage and will fade out quite fast (like the shields in NC). So basically the main informations about the psi effects will be stored in structs serverside and the graphical effects will only be spawned as entities when needed. That way we may reduce the amount of entities. But the downside of this is that the Think function of the manager class, called once a sec, may(it doesn't have to just maybe) become more or less huge and time consuming.

The other possibility would be to drop the concept of the manager class more or less completely and spawn a new entity once a shield/heal/dot is casted. This maybe makes sense for the heals but the shields which spawn their particle effects just once in a while that may create an entity overhead. But this approach would distribute the processing time needed a little bit better, but it would also consume more processing power. Apart from that, it is harder to handle. --R2d22k 12:34, 1 March 2010 (UTC)

Moved this to the talk page, and made a setup for the general page ;) (we can use the main page then to refine the actual one) --Biglines 17:50, 1 March 2010 (UTC)

Damn sorry ^^ totally forgot that wiki differentiates between talk pages and the normal pages ;) still have to get used to it. I just browsed the valve dev wiki a little bit to find out where i had that info about the total number of entities from. It can be found there: here. The limit i posted in the NC forum is not quite correct. As you can see on that page. But it's correct if you only consider networked entities which i am most worried about. Basically you may spawn 2048 non networked entities, which only live on the client or the server and then you may spawn an extra 2048 entities which live on both, the client and the server. During the first Phases there shouldn't be a problem with the number of entities, but it might become one when we move on to later phases. L4D solved that problem with a manager (they called it director) approach and so i think that's the way to go. If no one has any concerns about it i would start implementing the psi_manager_class tomorrow. --R2d22k 19:54, 1 March 2010 (UTC)

would temporary ones work too? http://developer.valvesoftware.com/wiki/Temporary_Entity does that number include map entities too btw? (such as props etc), and can't the effects just be part of the player entity? --Biglines 20:47, 1 March 2010 (UTC)

i just wanted to write that temporary ones won't work, but i just had an idea, they maybe work if you use something quite similar to the msg system the gui uses (to update the healtimer if one got a new heal casted), but you still might run into trouble cause you create quite some entities on the client side (or at least the solution i would use) (some problems can be overcome if we say that everything, shields, heals and buffs can't be recasted, but at least shields can be recasted in original nc), perhaps one should create a manager class on the client which is connected to the serverside manager, so we have just one entity on each side and then the particle effects are only spawned on the clientside... i personally don't like making the effects be part of the player entity cause that will definitely enlarge the already kinda huge player class and it will make changing the behaviour of the shields and such at least a little bit more complicated --R2d22k 09:44, 2 March 2010 (UTC)

ye just spouting, you're the expert ;) using a manager sounds good, it's not like we need to worry much about cheating ;) And true, if you make it part of the player class, I'm not sure but it prolly means more bandwidth usage anyway when people aren't buffed. --Biglines 12:35, 2 March 2010 (UTC)

i'm always glad about input even from "non-experts" ;), at first i would have completely dropped the idea of using temporary entities but when you mentioned it, the idea of using a message based approach, like the gui does, came to my mind, which may not be suitable for our current problem but it may be suitable for future problems, so i have learned something and i like learning things ^^ right, when making it part of the player class you probably will have more variables you have to synchronize between the clients and the server --R2d22k 13:00, 2 March 2010 (UTC)