Few down-the-line suggestions

[Midnight]

CMB -

Just a few thoughts incase you get bored (doubt you have) and wonder what else would be beneficial to add to the program. Pardon me if most of these have already been requested, as I know some have.

1. A drop down menu either above or below the spawn list that gave you the option to only show PC's, NPC's, door/item spawns.. etc

2. Coloring the spawn list by con just like you have the spawns now colored in the map. I like to sort my spawn list by level rather than name or whatnot.. and it's easier for me to see whites/blacks as even, yellows as 1,2 levels above, red as 3 or more, blues, greens, etc... rather than checking the specific level right off the bat.

3. I notice a good handful of traits in the spawn list (run speed, race/class, etc). Another pull down menu giving you the option to flag on/off those traits would be nice

4. I know you can change the map background color.. but what about having the option to make the spawn list black/red/blue, etc?

5. New blinking dots on the main map (with a timer) counting down to when the next spawn will pop up. I assume this will be difficult unless the server automatically sends a 'respawning soon' flag of some sort to the client... which I'm pretty sure it doesn't.

6. Someone want to code in a damage parser as good as the one in SEQ?

7. I loved the highlight option of SEQ where you could move your mouse over a dot on the map and it would show who it was, level, etc.

8. A place in the MSEQ client that displays your stats, level, hp, etc.. Beeps on low hitpoints? Beeps when you get a /t ?

9. A very small scrollable window at the bottom of the client that reads from your log file and posts all tells, group messages, /gu, etc... then saves it when you exit the program... so you can look back on what was said throughout the past few days. (yea I'm dreaming on this one)

10. Wayyyy down the road.. but something simliar to EQ's in game cartography system. Where you can type in your own text on the map.. and make your own points and maps customizable.

Just some thoughts while bored at work. Keep up the good work.

[MrDoh]

Just to save Caveman a little time, I'm gonna take it upon myself to make a few comments on things that I know about (or at least *think* I know about):


#2) I Really like that idea, and never though of it myself. This kinda ties in with your first request as it is a filter of the spawn list of sorts. To expand upon this idea (oh boy, Caveman is gonna wish I never found his nice little program! hehe) we could also, and user selectably, use colors in the list to define PC/NPCs, Vis/Invis, or pretty much anything else, if it was coded.


#3) If you mean "flagged" as whether they (that particular column) is shown or not, according to the release notes posted with client version 1.7, if you choose a column width of 0 for any column, i will hide that column. I personally have not tried this, but it is included in the release post
(If this isn't what you meant, I apologize, and please hit me over the head a little harder so I know what ya mean)

#7) This has been commented on by Caveman in the past. If I recall, he said it should not be very hard to impliment. It will probably be easily done in the form of a tool tip. (as this finally seems to be a good use for a tool tip in my opinion.)
Another great and usefull idea.

#5, 6, & 8) All of these could probably been done, if you know the memory offsets to read the data from. I do not know if he has this information for all these you listed. Also, antime the offsets change, a bunch more may have to be found before it would be back to full functionality. Not to terrible, but I'd be much happier if *I* knew how to find the offsets as to not to have to rely on others quite so much.

#9) I'm sure this could be done, but I have no idea if he intends to move in this direction at all. First you would have to make sure every time you started you have the right logfile loaded. (I have yet to see anything that can automatically detect it, mostly due to the filename format changes SOE has implemented since EQ began. If he did decide to read from the log file, then the beeping on recieving a tell you mentioned in #8 would become easier as you would no longer need the offset.. This could also be used in the damage parser instead of reading all that info from memory as well.

#10) I'm not sure that anything has been released, but I have heard tell of a map editing program for these formats. Adding a quick note from inside myseq would be cool, but for any heavy editing, personally, I'd rather use an external prgram. (just my opinion)

Please keep in mind, that all of this information may not be completely accuate. I am drawing on personal information, and all I have gleaned by reading all that has been posted by caveman.


***caveman,
If you see all this, and I seem to be stepping over my bounds, please yell at me! I like this software to much to have the devloper mad at me! :D

Mr. Doh

[Midnight]

Good thoughts. I didn't notice the option that fixed #3 in the new version. Much thanks..

[Gilson]

#1 on the list would be my personal favorite... :)

[cavemanbob]

1. Good idea

2. Another good idea. Should be fairly easy to do, I looked at this before, but got sidetracked by other stuff. User selectable colors for virtually anything is not only possible, but almost trivially easy. However big bugs come first.

3. Already covered by MrDoh

4. Should be easy I'll look into it.

5. This is more a matter of looking at where something popped the last couple of times. There is no offset for this (I hope LOL) because the client really doesn't ever need to know this.

6. This isn't really possible due to the nature of the data. It's really not ever stored in the client, the packet is just sent off. EQCompanion does a really good job of this anyway.

7. In the works.

8. Level & HP are fairly easy, but I'm too lazy to do this myself, my UI does it for me already. Stats are harder, they aren't stored with the spawninfo data as far as I know, so the pointer to the new structure and the data structure itself are needed. /t's see above about eqcompanion.

9. Again EQCompanion + /log on

10. I've been thinking about this one for a while now, it wouldn't be particularily difficult, but I don't know when I'll get to it.


Make any comments you like mrdoh, it doesn't bother me any

[Elmo]

For #6 & #9, it could be done, but instead of reading from memory, you would simply read changes to the log file. It would be a completely new input source for the server to handle, and as Cavemanbob mentioned it would be reimplementing functionality that other available tools already have, but if you wanted a "one tool does it all" solution, it could be added.

You would also need somewhere to store an option for the log directory and filename, unless you were able to find memory offsets for the character name and server and added code to deduce the log filename from those (you'd still need the directory, which you could default to C:\Program Files\Everquest but it would be good to let people change it).

Alternatively, you could look for the log file with the most recent timestamp in the EQ directory and read from that, which might be a more dynamic solution that would work for all characters without modifying the options (again, you'd still need the directory).

For #6 (damage parser as good as what SEQ has), I would think someone could just adapt the SEQ code, reading the values from the log file instead of the network stream.

--

Of course, for any feature along the lines of "feature X that SEQ has" could also be accomplished by modifiying SEQ to get it's information from the MySEQ server. I know that's a whole separate project, and has been mentioned before, but depending on the scope of features it might be less effort than duplicating SEQ in another language. and it would give the Linux crowd a working solution.

[cavemanbob]

--- Of course, for any feature along the lines of "feature X that SEQ has" could also be accomplished by modifiying SEQ to get it's information from the MySEQ server. I know that's a whole separate project, and has been mentioned before, but depending on the scope of features it might be less effort than duplicating SEQ in another language. and it would give the Linux crowd a working solution. ---

To some extent this likely will happen.