still having eq input issues

[hendar]

My last post on the topic was in Aug, and I have been limping along ok. (Although still needing to send the returns after a short delay). The problem was commands sent via a remote uplink were being truncated.

Today I started experimenting with running Lavishscript from the uplink console (that is, no sessions). The idea was to have a gui running on a notebook with some common commands.

I am seeing incredibly slow typing on the remote session. It acts as if there is a half second delay between characters. Am I missing something in my configuration?

I am sending the text via something like:
relay host.EQ2 type "/pet attack\n"

(in this case sending the return in the string, some strings seem to work OK, it may be because there are are no variable substitutions.)

An earlier suggestion to use ISXEQ isn't appealing to me. The last time I built it with VS2008 there appeared to be a library incompatibility. Having to rely on someone else to build it is not attractive. I'd like to use something which is part of an official distribution.

Also, in the back of my mind I worry that SOE would be more likely to go after ISXEQ users than IS users who didn't have ISXEQ loaded. I have no rational basis for this belief. I suppose if I renamed the DLL, SOE wouldn't detect it as loaded.

Anyhow, I would think that IS would get the job done. I just want a quick and dirty UI, and for months I have been able to reliably control multiple sessions with a mouse click. I don't know what changed, but I am not looking forward to working with these delays. (For example, I want the pet to attack before the fight is over).


Anyhow, I'd like to add my thanks for this product. It works better than anything I've thrown together.

[Lax]

The typing with the type command cannot be instant, but it's not going to be a half second between characters unless your framerate is really bad... It can't be instant because many games, I believe including EQ, ignore when anything is held down for less than a specified amount of time. (for example, to attempt to ignore accidental presses).

What I would recommend instead is pressing EQ hotkeys instead of using slash commands wherever possible. I honestly don't know what all that includes these days, but that'd be ideal. e.g. press ctrl+1 or something (and that would be the syntax.. press ctrl+1) for pet attack.

If you havent checked out the new stuff available for IS ([[IS:WindowSnapper|WindowSnapper]], [[IS:Repeater|Repeater]], [[IS:KeyMapper|KeyMapper]], and [[IS:ISBoxer|ISBoxer]] which configures all 3, and finally [[ClickBoxer]] an example UI perhaps like what you are working with) that might be worth a shot

[hendar]

Hmm framerates... that is probably what changed.

I'm getting 9fps with two sessions, and the relayed commands echo at a very slow speed. It seems that I used to have these commands relay at a faster rate.

I have a GTX 260 with 896MB, and recently configured things to run with two monitors. I am running a Q6600 with 8G of RAM, and the sessions themselves are not taxing the system. I've ran 4 instances of EQ on this machine with no difficulty. But the last time I was seriously using this machine I was only using one monitor. I normally get around 25fps when running 1900x1200. Anyhow, I was really looking forward to the second 24-inch LCD.

Dropping the session resolution to 640x480 gives me a little better response time, running the session full screen gives even more of a
speedup.


I have better performance with the single keypress macros, although that removes my ability to have all of the editable stuff in one spot. I am also
limited by the number of available unused key combinations
Clickboxer is somewhat like what I have put together, although instead of having the relay commands in the UI I have them in scripts which are ran from the UI. That way I have "nuke.iss" which can be edited on the fly if needed.

As an aside, I accidently had one of my sessions go full screen tonight, instead of windowed, and it swapped monitors and minimized itself. Trying to activate the session with a global hotkey was a disaster, and resulted in a complete party wipe.

I have two requests as a result of this:
* sessions which go from windowed to fullscreen, or vice versa should remain on their previous physical display.
* activating a session should never minimize another session

I just ran a test with two sessions (EQ1 and EQ2). EQ2 is full screen, and EQ1 is windowed. When I activate EQ1 via a global bind EQ2 minimizes and will not come back until I restore the window from the Windows Explorer. Pressing its global bind logs the message "Game is in Full Screen Mode. Window commands disabled" on its console. But fullscreen sessions seem to have a higher framerate (around 15fps).

[Lax]

The thing with actual full screen mode is that you can't pick where it's going to go after it got launched. You would have to tell IS to launch it on that particular display. It's lucky enough that you can move the window to the other monitor in windowed mode without a major FPS drop (in Windows XP without special software, this would cause the game to be software rendered instead of hardware, causing said FPS drop. with Windows Vista as long as the monitors are on the same video card, the window can be moved between the monitors without dropping the hardware rendering). You could try forcing windowed mode instead (via the game configuration window in IS), or add a new profile (also via the game configuration window in IS) to select the secondary display.