I like that ticker tape line:
I shows when player blows plants , makes a corp , is attacked by fighter and so much more.

The problem is I have been playing a game (by myself mostly)
and on my own server ...
I have been popping and blowing planets for 20 to 30 minutes straight.
And now that I have stopped like 3 hours ago , the ticker tape is still going ..
glittery , but still going ..
Is there a way to clear it ?
So I can see what others do in the 3 lost hours after I finished my planet blowing spree ?

Has anyone else seen problems with this ?

I have been thinking about that. It gets to be pretty redundant with heavily scripted actions. Maybe I could put some kind of a limit on activity for a particular user. It doesn't actually output every event that happens. Often events are coming in too fast for it to keep up, so it queues event text onto a string that's 1024 characters long. If the queue is full, it ignores a new, incoming message. So if you burst a bunch of events, it'll fill that queue, then run for as long as it takes to scroll 1024 characters. So in theory, if you dominate the ticker for a short time, then stop generating events, it'll start to clear and new events get tacked onto the end of the ticker to show once your events clear. But those events won't show up in a timely fashion.

A more elaborate implementation would store out individual event texts in a list with a timestamp, and include the ability to supersede older events with newer ones, and to use a cutoff so it doesn't even show an event that's more than, say, 2 minutes old.

But an option to clear the ticker might also be nice. I also think it might be nice to be able to replace the last several events as well, so you can see what happened while you're away.

Something else along these lines that I'd like to do is provide a graphical chart of server activity showing an hours, days, and weeks worth of activity, things like connections, bandwidth, and events. I hate when I come in and the server is dead, and I wonder if anyone has been playing. You can tell by the connection count, but it's doesn't give the full story.

Vid, thanks for catching this bug. It definitely wasn't behaving like it was supposed to behave. The ticker queue was growing very large, and it was really overtaxing the ticker. I've fixed it so it'll only queue up 10 events, and only put enough text on the scroll window to fill it. So it won't get bogged down with lots of events.

I did a test where I slammed it with 1000 events. It only took the first 10 and discarded the other 990. Once an event scrolled off, any new event was ready to get shoved onto the end so it would scroll by after the 9 previous events.

Now that I've done this, it wouldn't be too difficult to start making some smart decisions about how to distribute these events so it's not just taking the first 10 and ignoring the rest. For example, I could use an algorithm to replace queued events with newer events so you get a more even distribution of events when there are many coming in (as is so common with scripts). I could even do some basic pattern matching so I avoid showing a bunch of redundant events and favor events that are different. But I'll just put that in the todo folder for now. Other more important things to do.