ID:1321849
 
I've found that when my game becomes a little bit bogged down the first thing to go is Mouse Procs (even though everything else works without any delay), is there a way to stop this..?

The cause of the lag is some AI, for which the background setting is active. Also, the lag is actually pretty negligible (you can still move and do other commands, the only thing that becomes unresponsive is mouse procs, as if their priority is just not existent).

I've even tested it by switching the functionality of mouse procs on and off with a verb (normally MouseDown() would fire; I have a toggle that instead just makes it print out "You've fired" and it even visibly lags while printing it out, that is it'll print out "You've" and then with about a 2 second delay it'll finally print "fired" whereas all other parts of the game go on without delay.

I understand that this is a performance issue (probably caused by crappy inefficient AI; that's only temporary though) however, the world.cpu doesn't even reach that high.. it gets to like 15, and even the actual dreamseeker.exe entry in the Task Manager shows that it's only using like 15% CPU, the game itself doesn't visibly lag, just mouse procs. Is there any way I can jack up their priority?
There are a few feature requests for this, even bug report somewhere. This is indeed annoying.
Make sure to test by running your game with Daemon and logging in with a separate seeker instance. This is because currently when you test a game using Run in Dream Maker, the server and the client are on the same thread.
Is this happening in networked games or only when running the client-server (dreamseeker.exe) version? Because the client-server is single-threaded, it tends to get bogged down and won't be as efficient as running the two programs on separate threads. We are working on multithreading support for a future version though.
It's not just the client/server combination, if I recall correctly. When the client itself becomes bogged down, keyboard input takes priority over mouse input, it seems. While that seems like something the programmer should be dealing with by not overloading the client, the Rich Text control is awful enough by itself to slow the client down with just a wordy conversation.
If you can get us a demo of this and file a bug, that would help. I haven't seen the client itself bog down, but have plenty of examples of the client-server. I'm looking at multithreading that right now but it's proving to be a pain in the ass as expected with 15-year old code.
I actually can't duplicate it and send it now... I've... reduced the lag on my end.
As far as what I was saying, I may be able to write something up, as far as the slowing down the client with the Rich Text output goes. As far as unresponsiveness with the mouse in that situation, I've never been able to reliably reproduce it. But I mean, this was over two years ago. I'll give it a go on Monday when I'm off of work.