[Koshy]

Yes please need uber solution to this problem is is a matter of life or death for me!!!

Thanks,
- Koshy

[Stinkyfax]

Come on guys, I need fresh ideas :-/

[Peoples Army]

Well the question is how often does it reset itself? If its only ever few seconds or longer then instead of using a on game frame , which is highly intense and will surely lag your server, try setting it at every weapon event, or every other player event.

[Flynn]

Originally Posted by Peoples Army If its only ever few seconds or longer then instead of using a on game frame , which is highly intense and will surely lag your server

I cannot say usage of OnGameFrame to modify HP lags the server. To be honest, I wouldn't use it if it did otherwise. Who would?

To the contrary, compared to the lack of alternatives it can be quite viable so long as operations are simple, short mathematic calculations. Heck, your game wouldn't even be running if it couldn't do that every frame (think of the amount of CPU and GPU required to parse graphics and player locations per frame (200 * a second)).

TF2's modification would just require additional checking to ensure HP is consistent throughout (as opposed to simply incapped below a certain amount). The hacky part would be ensuring the damages work.

Besides, I had hinted another way; disable the degeneration, or failing that, force whatever event stops it from running to run continuously, or even better, make it so when the degeneration of the HP occurs, give back the amount it drains.

The above is pseudo-ideas for people actually willing to hunt through the code-base for something that could match that. If you aren't desperate enough to try and experiment to get an idea working, you aren't desperate enough to need the code.

[Peoples Army]

Originally Posted by Flynn I cannot say usage of OnGameFrame to modify HP lags the server. To be honest, I wouldn't use it if it did otherwise. Who would? To the contrary, compared to the lack of alternatives it can be quite viable so long as operations are simple, short mathematic calculations. Heck, your game wouldn't even be running if it couldn't do that every frame (think of the amount of CPU and GPU required to parse graphics and player locations per frame (200 * a second)). TF2's modification would just require additional checking to ensure HP is consistent throughout (as opposed to simply incapped below a certain amount). The hacky part would be ensuring the damages work. Besides, I had hinted another way; disable the degeneration, or failing that, force whatever event stops it from running to run continuously, or even better, make it so when the degeneration of the HP occurs, give back the amount it drains. The above is pseudo-ideas for people actually willing to hunt through the code-base for something that could match that. If you aren't desperate enough to try and experiment to get an idea working, you aren't desperate enough to need the code.

If you don't care about how efficient the plugin is then by all means listen to Flynn, but optimizing code is part of your responsibility as a developer, why run a command 100,000 times if you only need to, key word NEED to, run it every once in awhile.

Just because it might not lag the server to un-usability does that make it a good idea to add 100,000 functions if their not necessary?

[Flynn]

Originally Posted by Peoples Army If you don't care about how efficient the plugin is then by all means listen to Flynn

Oh oh! Personal attack! Poisoning the well, and Ad Hominem.

Personal attacks on credibility only work if you know the person. Which you don't...

2 years studying a Degree in Computer Games Programming (into my third year, nicely set for a first). The engineering AI lecturer (who happens to be a psychologist) said to me when going over my code that I was 'obsessed with efficiency'. I still disagree with his comment of making code less efficient simply to make it more readable.

Wrote a functional 2D game from scratch within 2 days (visuals, sounds, etc), wrote another one within 2 days also from scratch (visuals, sounds, animation, etc), and finally, pulling another's arse out of a fire, built a basic one in under half a day with no notice whatsoever.

Now that I have extinguished your little credibility flame (I'm used to that, used to moderate forums), allow me to retort;

You misread, so allow me to lay out the points;
One, the server performs far more taxing operations per frame than simple mathematic calculations
Two, if it couldn't handle the OTHER more taxing operations per frame (player position, areabox/hit-detection, physics etc), it wouldn't run
Three, It runs, ergo it can handle simple mathematics per frame
Four, it would only lag if you were stupid enough to put in REALLY complex OR slow access functions (like read/writing to disk etc)
Five, I've already used it for HP operations (where no OTHER alternative exists) and it does not lag
Six, it cannot logically lag, has not lagged during usage, ergo, your argument of it being laggy is flawed
Seven, people are desperate enough for functional ideas, this idea is already functional, ergo, it's still a useful suggestion

The point is, the other practical ideas have seemingly run out. You need an every frame check as the HP degeneration (if you have even played TF2) is pretty much 'every second'. Skip a beat and the HP will oddly change making it look weird to the user.

Besides, I had highlighted other suggestions BESIDES OnGameFrame on the bottom (all three far better than a 'simple shaving' of a frame or two). Pessimists versus Optimists I guess.

And finally, don't... DON'T ever exaggerate. It's not '100,000' operations. At worst it would be 64*X (assuming setclienthealth only does 5 operations, 64*5). Don't play to the 'public panic' simply because it says 'avoid costly executions' - it's meant to run some; if it can't even run some simple mathematics calculation then what is the point?

Sheesh.

[NeoDement]

Well thanks Flynn, I always wondered if doing stuff every frame was safe, and now I know ;)

[Peoples Army]

You still avoided the point, it's unnecessary, which therefore makes it inefficient.

[Flynn]

Originally Posted by Peoples Army You still avoided the point, it's unnecessary, which therefore makes it inefficient.

Actually, that's a nice strawman.

Originally Posted by Flynn Seven, people are desperate enough for functional ideas, this idea is already functional, ergo, it's still a useful suggestion

Besides, I've dealt with more 'political' and 'slippery' people than simple mis-leading arguments. They'd bend you over like a memory metal spoon.

Besides, YOU missed the point; you unfairly attacked my credibility without basis, which is more a question of ethics than simple 'get the best code'. Just because I supply code that appears impractical (which if you read - I state that it is) does not mean I am not capable of better or more efficient code. But there isn't 'more efficient' code per se unless we can grab whatever functions modify the health.

EDIT: I imagined this forum as more of a teamwork element rather than a backstab/ignore people's post battle.

[Peoples Army]

Please display where I attacked your credability?