Is creating 125 new objects in one server tick, and deleting another 125 a laggy process?

Creating--not really. Deleting--yes (or it was last I checked). Deleting tends to be pretty slow. One workaround is to move them into null and delete them over a period of time--say 10 or 20 ticks.

Does the server recieve any pain when asked to create and load an html sheet featuring the entire statistical readout of any given mobile, possibly deciphering the type, value, and name of 500+ variables?

That's probably not too bad, actually. The lag from sending the html is probably more important than the CPU hit taken by generating it.

If you were to change the values of 100+ variables at the same time, would it cause much slowdown?

This shouldn't be too bad. Changing variable values is a pretty quick operation.

-AbyssDragon

AbyssDragon wrote:

Is creating 125 new objects in one server tick, and deleting another 125 a laggy process?

Creating--not really. Deleting--yes (or it was last I checked). Deleting tends to be pretty slow. One workaround is to move them into null and delete them over a period of time--say 10 or 20 ticks.

Only one problem with this. It's a special proc I created called FadeToBlack(), which essentially creates a screen object for every availible space, sleeps for 5 ticks, then creates a slightly darker screen object, deletes the lighter ones, waits another 5 ticks, and sets the BLIND bit on sight (since it's otherwise unused in my games), and deletes the dark screen objects. This is done at the beginning of every battle ^_^ Thus far, I have seen no real problems, although I'm not sure how well it would display given lag, as the whole operation is completed in a second, and most 56k modems have a .33 second delay between operations/updates on BYOND games (according to my fairly limited testing).

Another question. How often do stat panels refresh? I was under the impression that is was every tick, but only if there was a change in values in the stat(etc,etc) lines. Also, what is the data sent to refresh these stat panels? Does it resend the entire panel's contents, or just changes, or maybe resends all the runtime values (as opposed to sending both runtime and compiletime)?

Put the datums in a list for every player. Don't save them.

I've been tossing around the idea of putting a fadeout into DBTC... It would just make "scene" or location transitions much nicer looking...

That approach is pretty similar to what I was thinking of... Darkening screen objects to an eventual blackness, and then the opposite after the player has moved or the event has been set up...

I think a neat idea would be to make the screen object's icon's normal state as nothing but an empty icon... Then give it two animated icon_states...one that goes from light to black, and another that does the opposite... That way, it wouldn't be seen during regular gameplay...but when you need a transition, just perform a flick() on all of the client's screen objects to begin the fade-out animation... Do the transition, then flick() the screen objects to the fade-in animation...

I'm not sure how much strain a screen full of screen objects creates, though... So it might not be wise to keep them on there all the time... But it still shouldn't be too much work to create them, do the flick()s, then delete them...

Polatrite wrote:

How often do stat panels refresh?

It's every 8 ticks by default, I believe you can code a workaround to make it refresh quicker/slower, but I'm not 100% sure, seeing as how I've never had to do it before.

Heh, I didn't see that post, until you pointed it out, that's funny.

Here is a snippet of my fade transition routine:

var/obj/Screen = new()
Screen.screen_loc = "SOUTHWEST to NORTHEAST" // cover the whole map
Screen.layer = 250 // over top of everything
if(client)
client.screen += Screen

for(var/Icon in list('dither25.dmi','dither50.dmi','dither75.dmi'))
Screen.icon = Icon
sleep(1)

loc = null
sleep(1)

// move to the new location here

sleep(1)
movelock = 0
for(var/Icon in list('dither50.dmi','dither25.dmi'))
Screen.icon = Icon
sleep(1)

if(client)
client.screen -= Screen
del(Screen)

It's much easier to just use a single dithered icon than to calculate new icons. Over a time span of 3/10ths of a second, most people won't really notice which method you use but your CPU definately will. ;)

The approach I settled upon last night (and have spent the last half an hour upgrading all of my transitions to use) is the following:


The client.screen is always filled with an object (added at Login, running from SOUTHWEST to NORTHEAST) that has a blank (default) icon_state that is just a solid mask icon... It then has other icon_states named things like "fadetoblack", "black", and "fadefromblack"...

The states with the "fadeto/from____" are animations of increasing or decreasing dithers of the color in the blank (so far, I use a black one, a white one, a red one, a yellow one, and a green one) The one that is just a color name is a solid icon of just that color..

Then, in all of my transitions, I call the player's Fadeout() proc with the desired color as the parameter... If I want it to fade to black, then I call 'Fadeout("black")'...

So far, it seems to work very nicely... And I've already thought up all kinds of cool uses for it... Like an upgrade to my battle animations for ki attacks that will flood the whole screen with the color instead of just a single animated icon_state change of the attacker's icon...

All in all, though... Even though it seems like such a simple thing, it really makes the game look much nicer... Especially since I change the view size between the World Map and the individual location maps... It covers up the rather sloppy looking switch from a client.view = 5 to a client.view = 10 and vice versa... Really neat...

Nah, I don't want it to be a random color... I like the control I have over what color is used...

But that would definitely be a cool way to have a random colored transition...