Progress report, and a few more questions

I've made some progress. I can kick off a team spanning a couple of computers, and I cobbled together a few keys to get team members to follow and assist and cast nukes and even camp out of the game when I'm done with a session. Enough already working to be useful, though it is going to take me a while to get used to it.

I've been playing my game (Everquest) for 14 years, and my interfaces have accumulated a lot of junk... key assignments and socials of all sorts for example.

Which means that much of the stuff that ISBoxer might try to set up to help me play everquest will conflict with something already in my setup. (I died pretty quickly when I first tried to run in one of your windows after allowing the system to install some standard helpers... my "attack" key was causing me to duck and immediately stop attacking, my "duck" key spun me in circles, plus a few other surprises.) I'm not ready at the moment to clean everything out and start from scratch with a cleaner but unfamiliar approach to the game.

So for now I chose "bare" with no window layouts or keys or anything pre-defined. The virtual files are helpful for keeping my own layout so I don't have to reposition during startup, and as I say I managed to get a few useful keymaps going.

Questions:

---

A click on an Inner Space window which does not have the focus only brings the window into focus. It does not perform the action I clicked on. That takes a second click. I guess I can get used to double clicking the first time I go to a window, but I would rather not have to. Is there a way to fix this? In my normal play style I have the windows mostly overlapped in a stack with corners showing, and a couple of critical buttons like "assist on a new mob and cast initial debuffs or whatever" and "nuke the current mob" showing in the corners. I can cycle through them pretty quickly clicking on them one after another round-robin, but the need to double click gets in the way, especially since I have to switch to single clicks if the window happens to already have the focus.

Why does it take an extra click when running in an Inner Space session, but not with normal windows? Is this a controllable behavior?

----

Some things would be easier to set up if I could send a whole series of characters (a character string) in response to a button press. That way I could send in-game commands like "/assist johndoe"<ENTER>" rather than configuring individual macros ("socials" in EQ) and corresponding hotbuttons for every character.

I suppose I could code each character in the string individually as a series of steps in a hotkey but even if possible that would be cumbersome. I haven't really looked at it yet. Was hoping that there was a "send character string" function somewhere that I just haven't stumbled across yet. Is there such?

....

I've been having a lot of trouble with windows getting stuck behind others, even though they have the focus. I think this is a Windows problem, since I see it occasionally without ISBoxer/InnerSpace running. But it seems a lot more frequent now, and several times I have had to drag a stubborn character window out of my session-stack to another screen or minimize the things on top to access other than the corner buttons. It seems to affect different windows randomly... I'll have a few that I can bring to the top easily, and then another one or two of the same kinds of windows that refuse to surface. And then the problem may go away and things start working right again.

As I say, this has nothing to do with ISBoxer: it affects anything, like browser screens or file manager displays, willy nilly. But it does seem to be exacerbated by running ISBoxer, and reading over the responses in the forums I've been impressed by the technical expertise some of you display. So I thought it could not hurt to ask if you have any insight into why this happens.

....

Just a comment on something I saw in another thread, I think in the Everquest section. Yes, the mouse position seems to be very noticeably offset on the Server Select screen. I can click about 1/4" below the "Play" button to make it work, and clicking in the center of the button does nothing. The color shading on the button that lights up when the cursor moves over it is misplaced upward, in the opposite direction of the shift of the active click region. Not a big deal once you know about it, since the mouse seems to be properly calibrated in the game itself, but it ONLY happens when running under InnerSpace. The buttons behave normally when starting under windows itself.

Thanks for any answers

edit: changed to show that it is the Server Select screen, not the Launcher, which has a mouse position calibration problem.

[firescue17]

Some things would be easier to set up if I could send a whole series of characters (a character string) in response to a button press. That way I could send in-game commands like "/assist johndoe"<ENTER>" rather than configuring individual macros ("socials" in EQ) and corresponding hotbuttons for every character.

ISBoxing EverQuest: /Slash Commands and Text Strings

Just a comment on something I saw in another thread, I think in the Everquest section. Yes, the mouse position seems to be very noticeably offset on the Launcher screens. I can click about 1/4" below the "Play" button to make it work, and clicking in the center of the button does nothing. The color shading on the button that lights up when the cursor moves over it is misplaced upward, in the opposite direction of the shift of the active click region. Not a big deal once you know about it, since the mouse seems to be properly calibrated in the game itself, but it ONLY happens when running under InnerSpace. The buttons behave normally when starting under windows itself.

This is due to not having a Window Layout assigned to your Character Set. Once a Window Layout is created, assigned to the Character Set and exported this issue will resolve itself.

ISBoxing EverQuest: /Slash Commands and Text Strings

Ok, the first part of that was what I had dismissed as probably "too cumbersome" (doing the string as a series of individual key actions), but maybe the end result is worth the bother.

Then they talk about the "key string" thing, which sounds like exactly what I wanted: something to send a series of keys defined by a character string rather than by a series of individual keys. But it seems it is not that. Instead of sending the keys as though they were typed into the window, they are "pasted" into the window, and this does not work in EQ. Hmm. I guess I have to study it some more, but even with the workaround of using the windows clipboard and the in-game paste, it seems rather roundabout and cumbersome, especially since the ordering of mixed keystrings and individual key actions is not preserved. Why doesn't the key string just type the string into the window???

I guess I haven't assimilated the details well enough yet. I will read it a few more times, and think about it.

This is due to not having a Window Layout assigned to your Character Set. Once a Window Layout is created, assigned to the Character Set and exported this issue will resolve itself.

Again I don't quite understand what I am seeing yet. The window layouts seem to be setting up tiles or panes to hold the different character screens, with no overlap. This seems to mean that even the main window can take up at most only about half the screen. My normal character windows are over 3/4ths of screen size on a 1920x1080 screen, and are cluttered with lots of chat windows and hotbutton banks arranged outside a relatively small viewport. They don't shrink very well. I normally use a staggered overlapped stack arrangement. Is something like that possible in a window layout?

I guess I will try assigning a window layout and see what happens.