PDA

View Full Version : MySEQ Client 2.0.0 is being started



MQSEQ2
01-16-2004, 11:16 AM
Ok folks enough time has gone by so today is the day that I have officailly created the Client 2.0.0 source directory. This means I've copied the 1.15.17 code ito a new directory and I'm in the process of converting the code to use the new Server 2.0.0. I will be devoting my time to the new version so the 1.x will not be changed to fix bugs.

ETA is ASAP, I plan on releasing a beta of the code sometime this weekend. I will add as much new stuff as I can but should have everything the current 1.x can do. I know the SpellInfo won't be totally done at first but I need to get the 2.x stuff out so we can get others to help program in the future. I'm also trying to clean up the code as I go without breaking it. Soon the code will be modular in respect to the functions.

You can thank TBird for riding my arse everyday ;) asking is it done yet, no, Is it done yet, No, IS IT DONE YET, NO!!!!!!!! hehe

Tbird038
01-16-2004, 11:18 AM
WOO HOOO...


Now....

Giddy-YEP.....little dawgie!!!!


hehehe

Cordan
01-16-2004, 01:16 PM
Wonderfull =) will test the client as much as possible =

Mixy!
01-16-2004, 02:54 PM
That's music to my ears !

Get moving ! :)

Mixy!

theknightmax
01-16-2004, 03:27 PM
Will 1.x and 2.0 be able to run side by side? So we can compare to previous versions?

MQSEQ2
01-16-2004, 03:40 PM
They currently do that's because the 2.x stuff is setup on a different port which is configurable.

Bob the builder
01-16-2004, 03:40 PM
In the immortal words of Special Ed

YEAAAAH !!!

MQSEQ2
01-16-2004, 03:50 PM
Currently Working in Client 2.0.0

Guild List - Working
Zone Info - Working
Spawn Info - In the process
Player Info - Not coded yet
Target Info - Not coded yet
Ground Items - Not coded yet

You can see the progress as I'm working on. The not coded yet is more like not finsihed the converting in the Client. I'm slowly but surely getting the stuff in there. I have also remove alot of of code that hadn't and/or won't be used anymore.

Tbird038
01-16-2004, 03:52 PM
WOOF....

NOW...

Back to work Spanky.....


hehehe

Sounds Awesome man....

MQSEQ2
01-16-2004, 03:54 PM
The map is loading and looking good.

I feel like the redhead sted step child ;)

maj021
01-16-2004, 04:51 PM
/cheer

ap50
01-16-2004, 05:45 PM
/cheer MQSEQ, wtg buddy.

newguy23
01-17-2004, 09:21 AM
Great news! ;)

But unless you can code and post here I suggest you get back to work! I'm just joking but seriously I did want to thank you for the amount of effort you are putting into this project. Thanks again.

I'm new...

sauron
01-17-2004, 10:50 AM
Woohoo! Looking forward to seeing the new verison! WTG!

MQSEQ2
01-17-2004, 10:55 AM
Can you say "WE HAVE SKITTLES" :D with con colors!

The SpawnInfo is now working.

Currently working on the PlayerInfo, I have the major part for the PlayerInfo working now I just need to capture the SpawnData for the Player so I can get link the Player to his proper SpawnInfo. This will allow us to have the correct heading, run speed, etc. for the player. It should be done in a bit.

Things are progessing very nicely and should have some type of Beta sometime this weekend.

Time to take a break and go work out so I can think clearly.

maj021
01-17-2004, 11:15 AM
Sounds great :)

MQSEQ2
01-17-2004, 09:01 PM
After 8 hrs of running 1.15.17 and 2.0.0 they both look identical :) so I will say they Spawns are working perfect.

Working on the Player and TargetInfo now and they are coming along pretty good.

AriB
01-18-2004, 03:56 AM
Great Work Bro....

I don't post much but... great work :p I may no post but I read everthing :p

MQSEQ2
01-18-2004, 09:49 AM
I have the simular issue. I post everything but never read anything. ;)

AriB
01-18-2004, 02:50 PM
lolol OK now go to http://www.keep-up-the-good-work-and-get-back-to-work-because-you-rock.com

MQSEQ2
01-18-2004, 09:01 PM
Targeting works now. Still working on the Player Spawn Info (haven't really messed with it yet).

Will start working on the GroundItems next as well.

I also fixed the XY issue from the old code. Now the code has been converted to X=X and Y=Y vs X=Y and Y=X (the old way).

Everything is looking good so far. Sorry I haven't posted the beta yet but I was wanting to get a little more done.

maj021
01-19-2004, 01:27 AM
We'll try to live another day.. ;)

Tbird038
01-19-2004, 12:44 PM
Hmmmm...I'm starting to think it's time for the Pitchfork....cause the PROD is starting to be INEFECTIVE...

LMAO...Sounds great....Looking forward to that first release....

MQSEQ2
01-19-2004, 02:21 PM
After 20+ hrs of testing and everything looking good, I hit a road block today with corrupted data being processed. So this is throwing the Spawn Info off in the SpawnList but the Skittles are prefect.

I'm runing 1.15.17 and 2.0.0 at the same time so I can verify stuff.

I will have the issue tracked down soon (I hope cause that pitchfork could hurt).

AriB
01-20-2004, 11:21 PM
WAKE UP!:o <plays loud music>

Lets get this bord going agin so................

WAKE UP!!!!!!!!!!!!!!!!!!!!!!!!!!!!

<feels better>
<got all fo that out>
<Goes play EQ>
<Sighs>
<Wants to try out 2.0.0>
<gives myseq2 some Coffie>
<Tapes his hands to the keybord>
<thinks to self and says in mind "I know he can work windows for just a keybord>
<goes home>
<Finds 2.0.0 done>
<Jumps for joy>
<go back on EQ>
<Feels Good>


The End! :)

maj021
01-21-2004, 12:16 AM
ha, I just came here too for some friendly prodding :)

Can't wait to see it!

MQSEQ2
01-21-2004, 06:30 AM
hehe, what about the eyelids? Need toothpicks and/or duct tape to keep them open.

I'm going to redo the SpawnInfo handler to see why I'm getting corrupted info. Going to take it back down to the basic code.

MQSEQ2
01-21-2004, 07:20 AM
See, duct tape works! The SpawnInfo are now working againing will do some more testing to verify Spawn counts between 1.x and 2.x.

Time to move on to next stuff. A little side tracked but back on track now, just missing a wheel hehe

MySEQ_fanboi
01-21-2004, 06:35 PM
Time to move on to next stuff. A little side tracked but back on track now, just missing a wheel hehe

Doing a great job, keep it coming!

Do you need testers to start poking at this thing yet?

MQSEQ2
01-21-2004, 08:43 PM
not yet trying to resolve a few minor issues with drawing the Player stuff right now.

I will release it when I can have a somewhat stable environment.

cavemanbob
01-22-2004, 02:36 AM
So what's left to do? I've got time on my hands lately, and I'll be glad to help with the 2.0 stuff. I'm curious if any major changes are coming anyway, since I've been working on a 3D drop in replacement for the MapCon (This will clearly be more processor intensive then the current one).

MQSEQ2
01-22-2004, 04:28 AM
I have GroundItems and a few other little stuff to compelete. I've been working on the packet handleing system to try and weed out bad packets. I've been running the new changes for about 6hrs now and it has only filtered out 6 bad packets so it looks like it's working now.

I might setup up Server side processing for the SpawnList and it's job would be scan the spawns and only send the spawn data that has changed. For example if your in the Bazaar there might be 600 Spawns, under this thought process it would send all 600 spawns the very first time then it would only send the spawn data for those spawns that the X,Y locs have changed. This would reduce the spawn data down to say 20 spawns or so that are running around the Bazaar. This would speed up the client a great deal while slowing the Server down a little. I don't know what the trade off on Client - Server CPU utilization would be but currently the Server is at 0% to 2% utilized. So we could increase that to maybe 5% to 10% max and might shave off 10% to 20% off the client (which is currently running about 35% to 45%).

That task may come a little later after 2.x has been released. The CPU increase with the 2.x is very minimal compared to the large amount of data being handled.

Tbird038
01-22-2004, 10:10 AM
Just my 2 cents....so tell me to shut up when you would like....

I personally want the server as lean as possible...(client can be a PIG for all I care)...as I am running EQ on a box that does NOT have as much juice as I would like, seems like any addition load would not be a gerat thing...

(Course the brain-trust here might just tell me that this is a REALLY miniscule thing..and I should SHUT MY DAMNED MOUTH)...in which case I will just say...

IF ya don't hurry....the prods are gonna get BIGGER, SHARPER, LONGER...AND...ELECTRIFIED.....LMAO!!!!!

MQSEQ2
01-22-2004, 11:37 AM
hmmmmmmmmm ouch

Tbird038
01-22-2004, 11:39 AM
or should that be....

BZZZZZZZZZZT......ouch....DAY-UMN...lol

MQSEQ2
01-22-2004, 11:48 AM
I like the abuse (wipe me, beat me call me Edna)

maj021
01-22-2004, 12:11 PM
I personally like the balance the way it is. Most of the time I'll have the MySEQ server open, a window or two of everquest, and sometimes a window of subspace open all at the same time. If the server takes up more processor time than it does right now, my computer would be a hurting unit.

Just speaking for myself, I like that the client does more work since I run it off a seperate machine. I doubt it could handle something like a 3d map since its about 4 years old, but it takes on the current client just fine.

MQSEQ2
01-22-2004, 12:27 PM
If I do it, it would be configureable on turning it off/on at client/server.

cavemanbob
01-23-2004, 01:36 AM
I agree about the light processing of the client, I personally prefer as little as possible there as I have other tasks that need to co-exist wth my EQ habit. As myseq requires a network connection (most liekely at least 10Mbit) anyway it shouldn't be a big deal in most cases.

Squiffy
01-23-2004, 02:19 AM
3D is a good idea :P

Seriously, though, one thing that always miffed me about MySEQ was the Z-filter. The map doesn't Z-filter at all, and if you turn on depth-filtering, your map just shows the bottom-most areas of the map 3d-wise.

Another nifty lil' idea for the client (I know this is the wrong thread n all, but hey) would be the possibility for 2 child maps in the parents.

So you could zoom in heavily on your surroundings in one map, and on the other, either a zoomed out zone-wide map, or the immediate vicinity of your selected mob, or whatever you like.

I'd find it handy, personally, as a pulling monk and quadding wizard. But if it'd be a headache to program or a huge system drain, nevermind :P

Edit: Keep up the good work, bro. Wish I could lend a hand, but it'd take me ages to catch up to where you're at. I'm a competent C and VB programmer, but my knowledge of network programming and memory handling isn't so hot :(

cavemanbob
01-23-2004, 02:58 AM
A 3D showeq view is something I've always wanted, but it introdues other problems (which is largely why it's not done...). The EQ S3D is utterly insane and I have no clue why it was designed the way it was besides chasing off decompilers, and lets not even get into the WLD format... Wall transparency is the major problem I have at the moment, if someone knows how to pull raw texture data out of a managed D3D texture I would love to know.

JustAnotherUser
01-23-2004, 05:14 AM
Why do you need the textures ? Wouldnt it be enough for a map tool to present only a wireframe model ? That way you could orientate and lokate mobs in 3D and wouldn have to hassle with textures especially as loading up a whole zone with all textures would be a killer with quite a lot of CPU usage.

Oh and you can convert the s3d files or rather the wld files into .x files which managed DX can read in easily. I use a mixture of ZoneConverter and 3DS Max though i can by no means get that stupid .x Converter from the SDK get compiled. Thats whats hindering me atm to experiment some more with a 3D Map. Oh and the fact the DirectX 9b doesnt know at all what Managed Code is.

MQSEQ2
01-23-2004, 08:41 AM
The Z Filter works but the issue is the map directory needs to be deleted and all the maps need to be redone from scratch hehe.

Most maps was done in a XY format vs. XYZ format so there is no depth to the maps.

You should be able to filter the spawns via Depth Filter.

There are a few ideas I have had with mapping. The biggest thing is to redo it so the zone is drawn on a offscreen bitmap once then stretchBlt it to the working copy off screen for only the area needing to be shown. This would then be copied to the onscreen area (that's called double buffering to prevent flickers). We currently redraw the map during every poll cycle with the double buffering.

I have written a Map viewer in VB 6.0 that shows the map in one pane and then allows you to Zoom In/Out in another pane and as you move the mouse around in the normal pane it copies the area to the Zoom pane. This is very quick since it's using the StretchBlt techniques. This was the beging of my personal SEQ type program. But I decided to help this project out and learn C# even tho I know VB like the back of my hand.

Squiffy
01-23-2004, 03:31 PM
LONG LIVE VB! :D

I've always like I wanted to contribute to this project in some way (apart from money, since I'm a poor bastard.) If you can think of anything a learned VB programmer and partially trained C/Java programmer can do, lemme know. I also run an EQEmu server at times if somehow that could be any use :P

MQSEQ2
01-23-2004, 03:47 PM
I just wished one day I could learn C# so I could program in it.

I have everyone fooled here in thinking that I know what I'm doing hehe. Reality is I probably should be put in a white jacket with the buckles in back with nice white walls with pads.

The Mad Poet
01-23-2004, 04:57 PM
I know you are learning C# - but is there a reason server code switched out from C++ to C#?

C++ would do the server side processing much faster I'd think...

MQSEQ2
01-23-2004, 05:55 PM
I made it C# so that the memory sniffing code can be added to the Client as well for those who only need or want to run the Client on the smae machine as EQ.

I see no major speed difference between the two versions. Server 2.x is processing alot more data than the 1.x.

The 3.x version will be written in VB 3 using thunking to process 32 Bit API's :)

The Mad Poet
01-23-2004, 07:31 PM
eeeek you said the "T" word....

in terms of performance I think if you add the server side processing then it will be much faster native...

To compile into a single .exe - make the server a .dll? :) Actually I noticed you are a member of Code Project - but reading through your code has taught me quite a bit about C# - I wish I could pick your brain a bit about the graphics routines and how you do the map updates.

Keep it up - just seeing the server moved over to C# was amazing, purely from a greedy code stealing point of view.

and finally - do you plan to put a license disclosure into the work to protect your copywrights?

MQSEQ2
01-23-2004, 08:25 PM
I'm not the original programmer of the system.

I created the Server 2.x from scratch with basic guildlines from the 1.x and MQ for referrence as well as a few CP examples.

As for Copyrights it falls under GNU license since all the examples are GNU that I used for refferrence. Now if I made it closed source then it would have been different hehe.

I will put a disclosure in the code sooner or later.

As for programming knowledge I was a professional VB instructor that sold some commerical software world wide as a side job. Now I just play with C type programming and only do VB for real projects.

The Mad Poet
01-24-2004, 09:32 PM
catch { /* How does one log an error if the logging function is the one erroring? */ }


Try

catch (Exception e)
{
MessageBox.Show("Error in Log file : " + e);
throw (e);
}

MQSEQ2
01-24-2004, 10:17 PM
That was Jag's being funny. The point was if you are trying to write a error to the log file and the routine had an error there's not a whole lot to do.

Your example would be good as a normal routine but you may get a lot of Message Boxes popping up which would lock down the program.

The Mad Poet
01-25-2004, 11:03 AM
If an exception is thrown the code stops executing at that point (when it is an unhandled exception) - by catching any exception and tossing out a MB like that it shows you that it happened int he log file (the added text) by re-throwing the exception it makes it unhandled and closes the app.

That at least lets you know where the error came from - where otherwise you get the exception but without any kind of detail. The better way to do it is setup your own exception class for the types of errors you expect and then try..catch at each major operation (that you would *expect* to have a problem) and then catch them allowing full controll over what happens when they occur.

Generall my code doesn't do anything your's doesn't other than add the text showing you *exactly* where the exception came from so you don't have to guess.