So I continue re-factoring code to make this a smooth running beast. One of the benefits I've seen already is that TICKS actually happen closer to when they should (between 15-45 seconds). Just one of the things I'm now keeping an eye on.

I've added in goals & validation around all functions in our update_handler() function (this basically is what runs the game). If any function exceeds the goals I've set all the IMPs get notified, so we can go make appropriate changes. As of now, the majority of functions have a target goal of 0.03 seconds, there are a few that do the most grunt-work that have a target goal of 0.25 seconds (like mobile_update() which does various things to every mob/character in the game every 4 seconds, and char_update() which is the function that takes care of the TICK for every mob/character).

Right now my hope is to keep the goals less than 0.25 seconds, and add new functionality as necessary to meet those goals.

I know of about a dozen or more things that don't meet these goals right now, and I'm slowly working through them.

So long, and thanks for all the fish!

I spent most of last night on some fairly mindless refactoring of a handful of things that don't run very fast into equivalents that run faster. Some of these things happen at the tick, some more often.

I don't expect any of it to have near the impact that the stuff Zulg has done to this point did, but that code should be live soon-ish and we'll see. I figured it made sense to start with the things I knew how to do and knew really should have been done a different way.

Any idea on what's causing the frequent crashes? Bug introduced w/ Zulg's recent performance fixes?

Mostly no (I know where things are crashing, but not what went wrong at some indeterminate point or process before that to cause it) though I have a theory or at least an observation I need to remember to talk through with Zulg at some point.

I swear, if I had a year and nothing to do I'd rewrite CF in a "modern" language just to get away from C's Thunderdome style of memory management.

n/t

So long, and thanks for all the fish!

nt

But that's mostly personal familiarity/preference.

Also, if Visual Studio pisses me off, I can swear at Zulg.

What is cf actually written with, and what languages are compatible with it.

I am actually delving into C#, all the dif browser languages, Vstudio, SQL, etc..., for work

n/t

So long, and thanks for all the fish!

nt

http://forums.carrionfields.com/dc/dcboard.php?az=show_topic&forum=6&topic_id=15243

I knew the ticks were coming slower.

Thanks Zulgh, youdaman.

nntt

Several big functions may not fit 0.25s (a pulse time?).
Did you guys consider splitting them into several smaller pieces and spear across different pulses within a tick?
For example you could update all characters and mobile hps at a tick front and move mobiles in the next pulse. Then update weather and area repops in a consequent pulse, etc?
While, certainly, some things can't be split, I think there are opportunities where you could actually do different updates in different pulses even if it implies slightly changed game mechanics (different != bad).

>Several big functions may not fit 0.25s (a pulse time?).

That's why I'm tracking the data...to find out.

>Did you guys consider splitting them into several smaller
>pieces and spear across different pulses within a tick?

Right now, the functions that are causing things to be out of whack are because they are written poorly, and have been easily refactored into the existing infrastructure. If I get to a point where that is not the case, I'll think about it. I agree different != bad, but there are also things to keep in mind like "Will people be able to determine a tick is coming if XYZ always happens here", which used to be the case with some things.

So long, and thanks for all the fish!

>but there are also things to keep in
>mind like "Will people be able to determine a tick is coming
>if XYZ always happens here", which used to be the case with
>some things.

Yep. That may be an issue. So it make sense to keep important things (like hp updates) several pulses ahead of less important things (like weather change).

PS. And notice, that I don't propose to parallelize CF code and move to a fancy multi-core Nehalem-based server

Nice. Any idea what the overhead is for the run-time performance checks? Seems like something you'd eventually want to disable once you clean up all the current problem functions. Then just enable it periodically to see if any new ones have started misbehaving.

I hate "back seat coders" though, so I'll shut up now.

>Nice. Any idea what the overhead is for the run-time
>performance checks? Seems like something you'd eventually
>want to disable once you clean up all the current problem
>functions. Then just enable it periodically to see if any new
>ones have started misbehaving.

Right now it seems negligible (set a clock_t before calling the function, set a clock_t after calling the function, subtract the clocks and compare against the goal, and report).

I'm actually inclined to leave them in if the overhead continues to prove to be minimal, because I'd rather have some checks in for new code that gets added without having to code review everything anyone checks in, and I'd be curious how some of these functions scale based on the number of players online.

So long, and thanks for all the fish!

I LOVE YOU ZULG!

(and you other Imms working in the dark and letting Zulg take all the credit )

I just meant to put them all in #ifdef blocks so you could enable/disable the whole set en masse without much effort.

But yeah...if the overhead isn't high and if those functions' performance isn't static then having them there all the time is probably the right way to go.