Beta Changes

[Seaxouri]

As stated in another thread, I am currently overhauling the client and making some big changes.

In some places I am adding things, in other places I am removing them. I am also speeding things up and fixing various old bugs that have been around.

One thing I am considering removing is the MQConsole panel. I do not use it, I don't know how to test it, nor am I interested in it. For all I know it no longer works. It certainly does not talk to our server. I hate having something in there that seems like dead code.

If anyone who uses this has any strong objection to me removing it, and can tell me that it certainly does still work in v1.19, then I will leave it as is. If I don't hear anything for a few weeks I will remove it.

I may also remove the Spawn Timer Listbox. I am not sure. I don't see its usefulness really. Spawn Timers still function.. just the listbox that is closed most of the time will not be there sucking up CPU power. Can anyone tell me a *useful* need to list these? I mean something that cannot already be done with mouseovers, etc so that it doesn't consume extra resources to process it. Just because you don't see it, doesn't mean it isn't sucking power.

[MacQ]

Seaxouri, any work to improve performance of MySEQ is great. I also have no idea about the mqconsole and never use it myself, even though I do use MacroQuest.

I think your ideas to slim down MySEQ concentrating on the core features and improving performance is the right approach...compared to what the "other" people did with MySEQ by turning it into a bloated pile of garbage. Thank you for continuing this project.

[Seaxouri]

Still working on it. I am redoing the graphics part totally. I slowed down due to holiday stuff, but hope to resume it this coming week.

[bobster]

/bump

removing the mqconsole window is easy, as is removing the additional radar window.
If anything, removing mqconsole / radar window speeds up the loading of the client considerably.
Spawn timer window is a little more tricky, as other functions seem use the info / labels provided in "spawntimerlist".

2cp

bobster

[bobster2]

right, so my old login got borked somehow...

Having pulled and studied the 1.20 beta, found a minor thing, not sure if you are aware or not.
It was, in it's current state, not reading map files properly.
here goes, correct me if I'm wrong...

old code:
in spawn.cs


public bool ReadMapFile(string filename)
{
// REMOVE THIS, never used:
IFormatProvider NumFormat = new CultureInfo("en-US");
/* snip */



new code:
in MapReader.cs


ADD :
using System.Globalization;
// snip

public static class MapReader
{
public static MapFileLine WorkingLine = new MapFileLine();
public static MapFileLabel WorkingLabel = new MapFileLabel();
public static MapFileLineType ParseLine(string line)
{
// ADD:
IFormatProvider NumFormat = new CultureInfo("en-US");
/* snip */
switch
{
case 'L': //and case 'P'
// call Cultureinfo for map coordinates x,y,z...

// REPLACE :
WorkingLine.from.x = (int)float.Parse(tokens[0]);

//with :
WorkingLine.from.x = (int)float.Parse(tokens[0], NumFormat);
// ++ all the other lines down to, but not including r, g, b tokens.


Tossing in a small "tweak"...


// In spawns.cs, line 34 : Change from :
public string mapName = "";
// to :
public string mapName = "no-map";

//spawns.cs, line 612+ :
public void SaveMobs()
{
string mobDumpFilename;

if (mobsHashTable.Count == 0)
return;
mobDumpFilename = String.Format("Spawns-{0}-{1}.txt", mapName, DateTime.Now.ToString("g").Replace("/","-").Replace(":","_"));
// adds Zone Name to dumpfile
mobDumpFilename = Path.Combine(Settings.logDir, mobDumpFilename);
using (StreamWriter sw = File.CreateText(mobDumpFilename))
{
sw.AutoFlush = true;
sw.WriteLine("Name\tLevel\tClass\tRace\tLastname\tType\tInvis\tR un Speed\tSpawnID\tX\tY\tZ\tHeading");
// changed from sw.Write to sw.WriteLine to keep with rest of code, removed /n

foreach (SpawnInfo si in mobsHashTable.Values)
{
sw.WriteLine("{0}\t{1}\t{2}\t{3}\t{4}\t{5}\t{6}\t{7}\t{8}\t{9}\t {10}\t{11}\t{12}", si.Name, si.valLevel, PrettyNames.GetClass(si.valClass), PrettyNames.GetRace(si.Race), si.Lastname,
PrettyNames.GetSpawn(si.valType), PrettyNames.GetVis(si.valHide), si.SpeedRun, si.SpawnID, si.Y, si.X, si.Z, si.MapHeading);
// added spacing to X, removed /n
}
sw.Close();
}
}


looks like solid code btw, I'm gonna enjoy this one. Unable to test this up against a running EQ instance atm though.

One thing I've wanted to try out is "remembering" each spawnpoint across zones.
Figured I'll do this by having client experience the spawnpoints, then pull the x, y, z data and insert into the Filter.Zone.cfg files, or the custom filter.
thus, next time I zone in, the client will pull spawnpoints from the filter, and add as as empty mapPoint.
In that regard, I could use a quick little hint on which hashfile be best to pull info from., Haven't looked much, but would the "X" Settings.c12w (etc) be best to use in this regard ?

One last thing...
I never looked much into the mqconsole thing, or crosschecked with 1.19.x
but I belive "bodytypes.txt", "Lookup.ini" and "weapons.txt" are obsolete now, and can be removed from the release build.
Seems they were used last around release of 1.9b / 1.10.

Better bobster

[flopz]

Any chance of a MySEQ port to Linux? ;)

Just to keep us tied over until the native SEQ is finished~

[Carpathian]

I'm currently working on a QT(Win,Mac,Linux) version of MySEQ. It's not a true port, however. Either way though, I created a plugin for it which will allow it to communicate with MySEQ server. I should hopefully have time to get something out soon, as I've had lots of time to work on it since school got out.

[Seaxouri]

Bob,

Not sure why you cant read map files, it works for me, but if that works for you, great.

As for the SpawnTimers, check the MobTimers.cs file. I want to rename 'SpawnTimers' to 'MobTimers' because there is just too much reference to 'spawns' everywhere. Really we are tracking mobs spawning, not all spawns, which can include players or ground items.

I did a bunch of work on 1.19 with MobTimers, and it is a deep rabbit hole to go down. It seems every little improvement I made caused additional havoc. I spent several weeks of tweaking, and MobTimers.cs is the result. v1.20 currently does little with the info, although it does look like I send the mobs info to the MobTimerManager when a new mob is detected. But I think thats where it ends. I never render anything yet.

Previously I hated the idea of having a unique 'ListView' for the MobTimers. It was a waste of CPU resources filling that stupid thing out, and it bogged down the system. However, I changed my mind slightly in that I think it would be useful to the point where the ListView only contains a dynamic list of Mobs that are awaiting to spawn. Once it 'pops', it should disappear from the MobTimer list and appear on the SpawnList list.

I also tried getting clever discovering 'portals'. Portals are places where any type of mob can appear from. A good example is in front of Qeynos, the newbie zone. There is a spot over near where the skeletons pop where all the rats and bats appear to pop from. This is a portal. However, portals are something very old, and the logic to discover them is complicated and causes tons of problems. Even once you find it, its not very helpful. My plan was to scrap all that crap and make it much simpler.

Sony did some crap awhile back to circumvent the MobTimers from detecting spawn points by allowing a mob to pop with a 'close' x/y/z value and then it literally 'falls' to its resting point. This caused the detector to think different mobs were popping in unique locations and nothing was being added to the Timer list. I added some 'range' logic which detects and counters this. One problem with this is the 'quick aggro' problem. What happens is that a mob pops, aggroes you, runs towards you, then we snapshot the x/y/z value. This can screw things up, since a timer might be waiting to see a pop, but we get a quick aggro pop, so the timer expires, and we never see the 'popped' timer mob (because its a quick aggro pop). Because we dont see it, we dont know when it dies, so we cannot start the next timer. This causes us to miss cycles. For example, if there were 3 mobs, Left Middle and Right that all were planning to pop at the same time, but you were standing too close to the LEft mob, at the time they all 3 pop, the Left one aggroes and runs to you. The other two remain still. We then snapshot the xyz values. We detect that Middle and Right are known 'timed pops' because their xyz values are in range of what we expect. However, Left has moved from his original pop spot before we took his xyz. We then think this is not really Left, but some other mob (well call it Random), so we skip it. We never see Left pop. So when Random dies, we didnt know that Random was really Left. We dont care about Random dying, because we know nothing about it. If we then kill Middle and Right, as soon as they die we start their timers going. After the timeout period elapses, we will see Middle and Right blink, but Left was lost, so we dont see it ever blink, and when it does appear, it will be a surprise.

Theres a lot more, but the point is that MobTimers is a BIG thing to undertake. It is not as straightforward as you might think, until you get dirty with it. I spent *weeks* on the 1.19 code, and it was about 70% functional.

[flopz]

I'm currently working on a QT(Win,Mac,Linux) version of MySEQ. It's not a true port, however. Either way though, I created a plugin for it which will allow it to communicate with MySEQ server. I should hopefully have time to get something out soon, as I've had lots of time to work on it since school got out.The server is where the issue lies. I'm by far in the minority, but I play EQ under Linux (using Cedega/WINE). I can't help but severely doubt a simple port of the MySEQ server would work, because the memory would be mapped out completely differently.

[Carpathian]

Yes, I imagine it would be a problem. One way you might be able to work around it is if you can start eqgame from the MySEQ server itself. Just a thought.

[bobster2]

Seaxouri wrote:

Not sure why you cant read map files, it works for me, but if that works for you, great.

When I built and ran the client, but not connecting to server, I would open map manually, and debug log would go mental over the L 123.456, -654.321 format maps were in. it would read up to the " . ", then mtl.invalid.. Figure this is because my xp is set up with a non-US regional setting, and therefore need to be told how to read the " . " properly.

Check your code and see how many times your IFormatProvider is called, bet you'll find none, like I did.
For sake of internationalization, I would suggest doing as suggested above.

Had a look at the mobtimer.cs. You're right, it IS crazy code right there.

Poked around in it, and for a first try, I figured I'd copy and modify the savetimer instance (not used atm) for writing to filterfile, extract some of the mapreader class, modify for the filterfile reading, and put it back in with the map rendering.
That way all the spawnpoints in zone will be laid out, populated or not.
Will worry about timers later.

anyways..

What, in Your opinion remains to be done before you release the 1.20.0 ?

better bobster

[Seaxouri]

A lot really.

1) Filtering. I want to make two sliders that provide a floor/ceiling range. The two sliders can lock together to move the z-axis window, or autolock around the Gamer's z value. I will probably scrap my old dynamic alpha, which is cool for like one zone. These slices will filter out map lines, mobs, players, nameds or any combination thereof.

2) MobTimers. First simplify it to its basic function again. I want to improve it in some ways, like maintaining a persistant list of mobs for each zone. This is already done to a point, but its not what I really want. The idea is to minmize the number of mob deaths seen before we can figure out what timers to apply.

3) Tagging. Sort of like selecting a mob, but sticky. Right now I have two boxes, one keeps track of the current in-game target (purple line) the other is any target selected with the mouse (white line). You can add up to four additional tagged mobs, which are selected with the mouse. Tagged mobs can be assigned roles, like MA.

4) Raid Mode. I want to add some features which may be helpful on raids. For example, if you tag a player and enable him as Pulling role, when he runs toward the raid, we might play an 'incoming' wave sound. Also, if you are in a zone with Raid mode enabled and your main raid force leaves you, a sound "the raid is moving" will play, or some alert sound. Whenever a raid mob is detected to move, a warning will sound.

5) Map buffer. This is all setup, I just need to punt it. Right now we paint the map every cycle like before. However, there is a way to draw it, then stick it in a buffer. Future render cycles will not repaint the map, but slap the buffer onto the graphics surface. If you zoom or pan, this needs to be regenerated, but that is already done now anyhow.

6) Auto Tracking. Following the player or a tag. I want to setup a hotbox field where the map autocenters only when the trackee leaves the hotbox.

7) 3D Mob view. Off to the side, I would like a small, 3/4 overhead view of the mobs in the zone. This will add some perspective on different levels in the zone. This can be toggled off.

8) More skittles. I already have a ton of them. I love my skittles.Traps have slow white exploding circles. Nameds have spinning 3/4 circle guard rings, pets are small, ground items are X's, the list goes on.

9) Bug fixes. I have some intermittant bugs. I removed all the wrapping try/catch blocks in the old code. It was stupid nuts. Try/catch blocks slow things down, so you only want them when you are calling out to code that is generally not yours, but you need a generic way to catch when a problem occurs. Like opening a file. You should wrap that probably in a try/catch. However, if you are accessing a hashtable that is accessable via multiple threads, you DONT wrap it in try on the off chance you have thread contention, essentially skipping the operation with the idea of 'we will get it next time around'. Thats just bad coding. In these cases I removed the try block and put a mutex on the resource... the right way to do it.

There are still a handful of circumstances that can occur where I get an Unhandled Exception, and they are usually some odd corner-case that is easily fixed, like not having a map file at the character selection screen.

I have one odd bug where the ListView gets double vision sometimes. It usually happens during an Evac or Death or something. The spawns skittles look good, but the ListView never lost the old list, so there are 2 of everything shown.

I've been working on a few other projects, so this work has come to a standstill. This is why I updated 1.19 with grounditems so folks had something decent while I went another direction. I do eventually plan to resume work on it, once real life work slows down, but its been pretty hot for the last 4 months. I think it will cool down a lot around August, so I can probably pick it up then. It totally works as is, the big thing I miss is the map filtering. I can't even use the old client anymore because I like my new big skittles and my smart zoom feature so much.

[brianp]

I never used the spawn timer window itself much, as you can just mouseover the spawn location on the map and find the remaining time. Usually, as the mob listed is a placeholder, you couldn't find the particular one you were looking for in the list anyway.

As for the possible updates, they all sound great! 3d mob view would be wonderful, but I think it would be useless unless you could click and drag the view around, which would be a lot more complicated.

I would also like to see the mouse wheel zooming improved. Right zooming in or out is likely to make you scroll around to get back to where you were. It would be great if it zoomed in toward the mouse pointer, so you could hover near a mob at one end of the zone, and easily zoom in for a closer look, without having to zoom, drag a bit, zoom some more, etc. When you mention your "smart zoom feature," is this something you are working on or something I missed in the current client?

Aside from this, didnt the old rexpage version of myseq have mob health listed? Even a % would be nice, but an actual number would be great if that data is there.

I will be doing more programming classes next fall and maybe get around to trying my hand at this myself.

[trustno1]

Someone mentioned a Linux port of the MYSeq client? I would love that. I was actually thinking about making my Linux box a Windows box just to get the client on a different computer so I could look at it easier, but I just can't bring myself to do it.

I've used SEQ for years now, and it's a shame that something borked it so bad, but it gave me the chance to experience MYSeq and it isn't a bad program at all.

Thanks for all your hard work.

[Seaxouri]

Brianp,

Yes my smartzoom works like that. Where ever the mouse is, that becomes the center zoom point. Actually, just before you zoom, I re-center the image so that whatever was under the mouse tip becomes the center of the screen, then I move the mouse to the center too, then I zoom in. I wanted to skip the auto-pan but the match was very complicated and could not get it to work. This works very nicely and I am very happy with it.

The 3d window would rotate based on the gamer direction. The purpose would be to see 'layers' of mobs in the zone, since most mobs all have common z-axis values. So I would expect to see distinct floors of mobs. If that works, I may add in auto-floor filter, where mobs are assigned a floor level and only mobs on your floor are visible.

[flopz]

Someone mentioned a Linux port of the MYSeq client? I would love that. I was actually thinking about making my Linux box a Windows box just to get the client on a different computer so I could look at it easier, but I just can't bring myself to do it.

I've used SEQ for years now, and it's a shame that something borked it so bad, but it gave me the chance to experience MYSeq and it isn't a bad program at all.

Thanks for all your hard work.I was actually talking about a Linux port of both the client and the server. I play on Linux and right now I'm beat for SEQ...cause MySEQ works, but doesn't run...and the native SEQ is still fux0r'd by the networking changes. I know that'll be running sometime (hopefully soon ;)) but I'm hurting for my skittles~

[Carpathian]

A linux port of the server wouldn't do much good. Since, as someone mentioned earlier, they are in two completely different "virtual memories." You would need both myseqserver.exe and eqgame.exe running within the same instance.

Another option would be to find out how wine stores the memory in it's process. Then you could write a native server to pull the memory properly from the wine/cedega process. Things you'd need to fiddle with to know for sure.

[BlueAdept]

I'm currently working on a QT(Win,Mac,Linux) version of MySEQ. It's not a true port, however. Either way though, I created a plugin for it which will allow it to communicate with MySEQ server. I should hopefully have time to get something out soon, as I've had lots of time to work on it since school got out.

I came across this today while looking for something else. Looks interesting. Might make a port to linux a lot easier.

http://dev.mainsoft.com/Default.aspx?tabid=45&gclid=COjOv5nm4IwCFSgRGgodXmHA7g

Use the Visual Studio .NET IDE and Grasshopper to Deploy .NET Apps on Linux!

[Carpathian]

That would be up to Seaxouri, to do a true port of MySEQ to linux. The one I'm working on just happens to support the MySEQ server, nothing more. Mainly wanted the Mac support =).