Bored at Work

[MQSEQ2]

The subject pretty much says it all.

I need some more ideas on the features that need to be added.

Working On:
Spawn Timers - 90% coded, just need to test the logic and then draw the markers. Will test tonight to see if the logic is working and if so I will wrap it up and realease it ASAP.

Server SnealPreview 2.0 is coming along very well. I need to try to work on it some today and see about adding the Server side filtering of Spawns. Need to make sure it doesn't cause a hit on the CPU since EQ and the Server is on same machine. I doubt it will since alot of folks run Server/Client and EQ all on same machine.

[Mixy!]

Just ideas, so if they're impossible dont flame :P.

Allow circle size adjustments around rares.
ZEM's
Show what mobs are holding like seq did.
Autotarget window debugging.
Aproximate exp, and number of kills to ding.
Groundspawn differentiation by zone. (IE Yew leaf= WL, Oak bark = BB)
Server in system tray.

I'll post more if i can think of any.

-Mixy!

[MQSEQ2]

Client Side = Allow circle size adjustments around rares.
Server 2.0 = ZEM's
Server 2.0 = Show what mobs are holding like seq did.
Client = Autotarget window debugging.
Server 2.0 = Aproximate exp, and number of kills to ding.
Client = Groundspawn differentiation by zone. (IE Yew leaf= WL, Oak bark = BB)
Server 2.0 = Server in system tray.

All of the stuff labeled Server 2.0 is being worked on already.

The stuff labeled Client can be added.

Question, AutoTarget Debugging, can you go into more detail?

Ground spawns, I just need to do the following:

EQ Name=Zone:Item,Zone:Item

IT_AUTDEFxx=WAKEN:Yew Leaf,BUTHER:Bark

Something like that and if it's not in the Ini just show the EQ name.

Slart was working on something with the size circle and suppose to get me the code.

[Dark]

One of the thiings i use SEQ for is the spell timers. Thats been real helpful.

So adding spell timers to MySEQ would be great.

[MQSEQ2]

I will look into the Spell Timer but it will go in the Server 2.0.

[xzero]

Yes the Spell timer would be great
I also would like to see the Hitpoints (%)

[MQSEQ2]

The HP, Exp, AA type of stuff will be coming out once the Server 2.0 is release and the rework of the client.

Server 2.0 update:
Testing done in the Bazaar.
557 Spawns


557 Spawns * 436 bytes = ~242Kbytes / 1500 bytes = ~162 packets

557 Spawns * 436 bytes = ~242Kbytes * 82% Compression = ~44Kbytes / 1500 bytes = ~30 packets

I don't have any timers setup up but it was able to read all 557 spawns and Compress it down in under 1 sec. I will see if I can get actual times and see about speeding it up some more

[Mixy!]

When i mentioned autotarget debugging i meant the target window of the client selecting the same thing as what's selected in EQ. I am still unable to get this to work, and i've read of a few others are having trouble as well.

I've posted the error logging, and offsets in other threads.

But lets keep this to development ideas! I dont want to hijack the thread.

[MQSEQ2]

I have been thinking about that. Folks say 1.10 works with no problems and I use 1.9b and it works fine.

The problem I'm think is that you may have the old 1.9b vs. the new 1.9b, yes there was a release but no version change.

Go to the site that is hosting 1.15.8 and download the 1.9b from there and make sure you have the correct offsets and it should work.

Back on track now. More Ideas (Creacking that whip!) hehe

[jag111]

Originally posted by MQSEQ2
I don't have any timers setup up but it was able to read all 557 spawns and Compress it down in under 1 sec. I will see if I can get actual times and see about speeding it up some more

Assuming the default poll time for the client is set to 250ms, won't the process mentioned above then have to complete in under 250ms at the very least in order for the server to keep up with the client requests?

[MQSEQ2]

You are correct but my brian wasn't quick enough to get the actual time hehe.

To read/compress/transfer should take that long. I need to find a high resoultion timer example to get some testing done.

[SurfAngel]

One thing I thought might be interesting is parsing. I guess for starter, a question:

How much load would it be to start passing combat and casting related info? All current parsers use the log files so there are some fuzzy logic employed in identifying which hits lands on what target. Since we can actually identify an_orc_pawn16 and an_orc_pawn37 instead an_orc_pawn and an_orc_pawn, the accuracy of when combat was initiated, exactly which damage lands where, etc. would increase dramatically.

Parsing code logic aside, back to the original question, does it create a heavy load to send cambat/casting info to the client side?

[MQSEQ2]

I have written a log parser in the past so I know kinda how to do it. The problem is it comes in through the channels and when you see it there it's by it's friendly name not EQ name. I will try to see if I can scan MQ and/or SEQ to see what they might have seen.

This option will fall in the Server 2.0 realm. Once I can get all the EQ data to the the client then it's wide open to what we can do.

[X-Elmo-X]

Not sure this is viable but since the origin of MySEQ was to kind of meld Macroquest and SEQ (I believe, correct me if I'm wrong), what would be a fantastic feature would be to enable targeting on the seq window to bring that target up in game. Much like the zone wide targeting the MQ already offers, and how when you target something, you get the info box in the current MySEQ.

Is this even possible? Cause that would rock .

Just an idea.

X-Elmo-X

[jag111]

While I wasn't around when the first revision of MySEQ was made, I don't believe the intent was to have it be a Macroquest / SEQ hybrid. I think it was just to have a windows version of SEQ with the "My" prefix being sort of a stab at Microsoft's whole My <blah> philosophy on user experience (My Documents, My Music, My Pictures, etc).

The only relation with Macroquest that MySEQ has is that it gets its data directly from EQ memory rather than sniffing the network packet stream like SEQ does.

In general, it's job is to passively collect game information, evaluate it, and display the results in a useful manner to the user.....not to actively affect the game itself.

But then, that's only my opinion. And to that extent, it's only what I'll personally work towards coding.

In other words, I don't want software to play the game for me. I just want software to give me more useful information so I can play the game better.