GoD Progress
Made a couple of minor additions to the Garage of DOOM over the weekend.

First is a minor attempt to deal with potentially excessive sim load caused by the GoD. I've been watching things closely, to see exactly how much the game contributes to simwide lag. Unfortunately, without a full knowledge of what else is running in the sim, I can't draw any solid conclusions. Louise seems to drag intermittently whether a game is in progress or not, so I can't isolate the GoD's contribution. I swear, one of these days, I'm going to rent an event sim for the weekend and settle it once and for all. So far, I'm not quite frustrated enough to drop $40 US just to solve the problem. But I'm nearing that point. Maybe I'll just wait for the next new mainland sim to go live, and setup a temporary pirate facility until the autoreturns kick in.

But I digress. Frequently. Until I've located the source of the lag (either in the sim or in my own code), I've added a simple failsafe. Now, the monster rezzing routines check the sim's time dilation each time a new monster call is made (every few seconds). From the LSL Wiki: Time dilation occurs when the sim can't keep up with the processing of its tasks even after reducing the time allocated to scripts and physics. Avatars will experience this as slowed-down (slow-motion, "bullet-time") movement. This seems to be a reasonable indication of the sim's overall health. If the time dilation drops below 0.8, no new monster is rezzed. This does nothing to stop the existing monsters already in play, but at least it won't exacerbate the problem.

My next step would be to expand the monster server's dilation check to disable/freeze the monsters when time dilation drops too low. This would require using llSetScriptState to turn the major scripts (movement, damage detection, etc.) on and off as required. I'm hesitant to go that far, however. It'd be very messy to change the system to allow monsters to suddenly become unresponsive without warning.

The second change involves flight. At the suggestion of a couple of my informal beta testers (Thanks for the comments, folks, keep 'em coming!), I've taken steps to neutralize flight altogether. As you may remember from previous posts, I was of two minds about allowing flight in the game. But, ultimately, I think that it was allowing too much of an advantage to the slow, plodding zombies. Any monster fast enough to catch a flying player would be far too difficult to evade for running players.

I kicked around making flight-responsive monsters that would increase their speed to match their foes, as well as special "flight only" monsters that'd rez to deal with fliers. But, ultimately, I settled for a simpler approach. The HUD checks for flight status once a second, and freezes the player in place (using llMoveToTarget at his current position) if he is found to be flying while he's in the game. Nothing too fancy, but it works.

But, naturally, this had unintended consequences. In this case, I realized that it could cause problems if a player teleports away mid-game with an active HUD. He'd be locked in place next time he attempted to fly. So, I was forced to add a failsafe feature that probably should have been in place all along. Now, if the HUD doesn't hear a roll call request from the server for 15 seconds, it automatically ends the game, and incidentally disables the flight lock. So, worst case, the player is frozen for less than 15 seconds. That doesn't seem too unreasonable.

So, I guess that's kind of like progress.
Posted by Moriash Moreau at 5:35 PM