MySEQ 1.22 Client Development

[Razzle]

I have been looking at the 1.22 client, and I think I can do some work on it. I havent'd used this client much. I have played more with the 1.19, because I don't have a scroll mouse on my laptop I use for MySeq. Most of the time I run ShowEQ. So I am going to try and back in tools for those of use that are scroll mouse impaired.

Currently, in the 1.22 client, what all needs fixed?

I am working on the spawn points, and timers currently.

I am kinda burned on the grind in EQ lately, but I have been having a blast playing with MySEQ and working on programing.

Let me know the best places to start. I am not the most savy programmer, but I try hard.

Razzle

[Hidron]

Honestly, I kind of gave up on the 1.22 client. It randomly crashed, and locked up on the error window, so I could never get any details on the error.

[Razzle]

There were alot of changes in 1.22. I will see if I can find out what is causing the crashes. Frankly I have only spent about 2hrs on the code for 1.22, and that was last night. I will be checkign if the spawn timers work tonight, all of that should be fixed now in the version I am working on. Maybe I will put up a beta in next few days, after I get a little mroe going on it.

I know when I have run the 1.22 client, I had problems with it. Maps not loading right. And a few crashes. The 1.19 is fairly stable. I have a few more things to tweak on the 1.19 client too, as I learned a bit more about programming in C#. Its fairly new to me though.

Razzle

[Razzle]

There may be just too much ripped out of 1.22 to fix it like I wanted easy. I wanted to add back in map support for seq .map files too.

I think I will look at 1.22 and 1.19, and combine the features that look good. I might play with the skittles in the 1.19, to allow options to change them. Some could be quite neat, if you can change them around.

I wonder what it would take to add in pcap support, to get rid of the server. That might be something fun to look at too.

Razzle

[bobster]

Do you still have some of the work you did on 1.22 around, Razzle ?
I've been playing around with it, and combined some of the work you did on the 1.23 (most notably the rightclick stuff), but having trouble with the spawntimer manager, and having spawnpoints appear on map. seems Seaxouri ripped all that out :(

bob

[Razzle]

Yes, he totally ripped out all the timer stuff.

I will see if what I was working on is close to anything workable. I had it a total mess at the point I stopped. I will see what I can find. Its on the old hard drive of my computer that was replaced, so not sure how much I can recover.

[Razzle]

I don't have anything useful of the code I was working on. I remember I thought I was getting close, but turns out I was doing it all wrong. Thats the point when I went back to working with 1.19 client. I could probably get in there and fix it now that I can program a bit better. There was just so much ripped out, and I didn't know enough to put it back in.

What in the 1.22 client do you like that is missing from the current 1.23?

I am adding features now to the current code.

Razzle

[bobster]

Okies, thanks for looking into it, guess I'll keep attacking it with my entry level knowledge ;(
maybe even heist more stuff from the 1.19/23

As for what I like about the 1.22 vs 1.23 : Its got a "cleaner" feel to it.
Not dissing your work on the program, but
I like the skittles, and the fact that it consumes less resources than 1.23.
I like the info-windows in upper right corner, and the "intelligent" statusbar.
I have no need for the million and a half options available. I have a scroll-wheel mouse.
I've even gone in and removed some more options from the 1.22 (who needs 5 servers ?)

As I said in the other post, I've taken some bits and pieces from the 1.23 code, like the rightclicking, searching Allakhazam(love that), adding to filters etc.

Only thing I really miss is the spawnpoint drawing to map/listview.

BoB

[bobster]

Ok, i've had a go at it, and made it at least collect timers correctly. using it on the timerlist/map seems to be a harder nut to crack.
Bare with me, this will get ugly :

Going from eqcommunications.cs

FormMain.Instance.ProcessSpawnTimer();
(equals f1.ProcessSpawnTimer(); in 1.23 code )

INTO

formMain.cs

public void ProcessSpawnTimer()
{
if (spTim.spawnTimers.Count > 0)
spTim.UpdateList(SpawnTimerList);
}


I get an object reference error to the first "spTim")
(object not set to object reference)
I've initialized the spawnTimer in frmMain with a simple

public SpawnTimerManager spTim;
SpawnTimerManager is found in mobstimer.cs from 1.22 code.

I know this is a longshot, since I'm working on code you don't have, but
Any idea on how I'll get past it ?

[lumplump]

Is there a way to track when traps will reset? IE traps in plane of earth for fabled weapon mobs?

[Hidron]

Believe PoE traps were 30 minute respawns. Been a while, but it tracked them there. Just have to wait an hour for the program to start keeping track of when the spawns will occur.

[Seaxouri]

/sigh

Wow. It looks like you just totally tossed all my work in 1.22.

I was looking at the server additions and was happy with that. When I got to the client changes I was not terribly pleased. Not only did you undo all the stuff I did in 1.22, which was listed in the overhaul file, you removed 1.22 from the history file.. something you really should not do. I spent almost a year overhauling the code, and to remove my work from the history is not really fair.

As far as spawntimers, there were several threads discussing why they were disabled. Sony changed the way they did spawning and a lot of the old code won't work in the new zones. Putting the old code back in will work in some of the older zones, but not the newer ones. You will see a lot of missing spawns, or invalid spawn pops. I actually got spawntimers working in the old zones again pretty easily, but in a lot of the newer zones things just didn't work. Im pretty sure that was the only thing missing from 1.22 that was in 1.19, but crippled.

Now everyone has the disconnected map lines, no smart zoom, old boring skittles and that horrid memory pig rendering design. There were also tons of bug crashes I fixed so those are all back in there now. Try going to one of the larger zones and see how much CPU and memory you use. The autotracker was also smooth in 1.22 and now is probably all choppy again.

Oh well, I'm old news anyhow. I stopped playing a year ago. Do what you want with it. I would have preferred you stayed on the 1.19 branch, since that is really what you are doing. People that liked 1.22 (which I got a lot of feedback that many people liked it a lot better) will probably be disappointed in losing all the new stuff.

/depressed

-Seaxouri

[Razzle]

Sorry to disappoint you Seaxouri. But if I had more knowledge of how to use CVS I would have understood that there was a 1.19 branch. But due to not knowing how to use CVS at all, I managed to get a download of 1.19.2 source and started there. The version I started with did not have your overhaul file as what I started with did not have those changes.

I thought about including the overhaul file, but I thought it would be more confusing.

I worked on the 1.19 client because I had looked at that code before and understood it more. The 1.22 was so different, and missing so much, I was not near the programmer you are to fix the things in it that were broken. It really was personal choice, I liked 1.19 better, and you weren't around to help. I know I sure could have used it.

There are a few people who prefer the 1.22 over the 1.19 branch. I would like to get stuff merged together personally, and make everyone happy. But one of my biggest problems with 1.22, was I do not have a scroll mouse. I run MySEQ on an old laptop with no mouse. That made 1.22 unusable.

Nothing is stopping you from coming back and picking up where you left off on 1.22. I only picked up way before that, where you left 1.19.2

No offense was intended.

Razzle

[Seaxouri]

Thats fine. I realize you meant no offense.

Kudos to you for even helping out.. its a difficult cross to bear.

As for CVS, you can create what is called a 'branch tag', which is like a normal tag, but allows you to actually make changes off that version of code without affecting the main trunk/head. You can even make branches off of branches.

A 'normal' tag allows you to pull a version of the code from the source tree, but does not allow checkins against that 'node'.

Normally when viewing (in your mind) a CVS code repository, its easiest to view the main trunk/head of code as a series of nodes in a flat line progressing from left to right, like this:


1.1-----1.2-----1.3-----1.4-----1.5-----1.6----->

Note: These are major and minor versions of the code. Normally we only change the major version if there is a major overhaul to the code, requiring other parts to change. For example, your new world addition to the server might be cause to move to a new major revision if it was not backwards compatible. Because the 'other MySEQ' guys already stole 'version 2' and 'version 3', I didn't want to confuse people so I elected to remain 1.x for MySEQ Open forever. Normally we might see a CVS repo that looks like:


1.1-----1.2-----1.3-----1.4-----2.0-----2.1-----3.0----->

Each of these 'nodes' start life as a 'normal tag'. Now let's assume that we are currently shipping v3.0 but some user of v1.4 wants a small bug fixed. We can do this by changing the 1.4 node to a 'branch tag' using the cvs tag command (I just use 'cvs tag -h' to see the options or view the man pages). Now the repo looks like this:


1.1-----1.2-----1.3-----1.4-----2.0-----2.1-----3.0----->
|
`-1.4.0-----1.4.1

All the tags here are normal tags except 1.4, which is a branch tag. The 1.4.0 tag is optional, but if we need to make another branch tag off of it for some reason, its nice to have a normal placeholder tag there. 1.4 and 1.4.0 are technically identical, or at least point to the same revisions of files. Now we can make our changes on the 1.4.x branch and release the update as 1.4.1. Now we don't disturb the trunk, which is v3.0, and its clear that if people like the v1.x line, they should get the v1.4.1 release to get the latest. They also know if they move to v2.x or v3.x, the interface may be completely changed.

That said, all is not lost. CVS can be fixed. Now that I think about it, and because so much time has passed (over 5 years now!) that I now think it was silly not to use v2.x. I should have done that in the first place. What I may do is convert back to the corrent naming convention and make the trunk based off 1.22 but call it 2.0, which is what it is. Since there is really a limited tag history anyhow, I will branch the 1.x line for continued use for the legacy version. So the repo would look like this:


1.0-----2.0----->
|
`-1.19-----1.25----->

This will allow the v1.x progression to continue as is, but also all the v2.x to progress if anyone decides to work on that again. At least it would be clearer what is where.
If you have any additional tags in the 1.x line you want kept, like 1.23 or whatever, let me know so I can keep the important ones. I can always create a tag based on any date, so if something is lost, its never lost forever.

-Seaxouri

[Razzle]

I have learned more about CVS now, and realize the mistakes I have made with it. It would have been better to have two seperate branches for what I have done compared to what you did.

I am not much of a programmer, and that was what I was doing, was trying to become better at it. I would say I have made it to being fair at programming, but I rank myself as poor at maintaining the source safe. I even set up my own CVS server and spent quite a bit of time learning how it works.

From everyone I talked to at work, the first thing they say is usually, why the hell are you using CVS? They all say its crap, and sub version is the way to go.

If someone wants to pick up 1.22 and start developing on it again, I would probably recommend maintaining the code in SVN, rather than CVS. But I dont know how to use SVN at all either.

Razzle

[Seaxouri]

I've been programming since 1980, and theres one thing I continue to come across, and that's that most programmers tend to say 'the stuff I learned on is great' and 'everything else sucks'. When someone makes claims like SVN is better than CVS, I ask them, 'in what way specifically'. You will find they start to stumble on their words.

SVN and CVS have their pros and cons. I have used several different source code respository tools over the years, each with their set of pros and cons.

For all intensive purposes, SVN and CVS are probably the *closest* to each other than any other repository system, so I just laugh when I hear people say things like that.. it shows me their lack of experience if anything else.

For our small project here, CVS is more than adequate. And the code is housed on SourceForge. SF has supported CVS longer than they have SVN, and SVN wasn't even around when this project was created. CVS was created in 1990, SVN was the follow-on to CVS, arriving circa 2000. I don't think SF added SVN support until 2006.

In any case, it looks like the SEQ project already has SVN support enabled as well as CVS. Apparently its only one click for the SEQ Admins to do this. It appears the myseq subproject is still not converted, however.

That said I am certainly not against a move to SVN. It certainly has more future than CVS does and I am all for that. As long as there is a good *reason* to do something, I am always for it. CVS has been a wonderful tool for many, many people for a long, long time. Like a long lost knight, it should be honored, thanked and peacefully laid to rest, not mocked and compared to today's standards or expectations. The greatest of heroes can only boast because they have stood on the shoulders of giants.

If I might make a suggestion: Never take anyone's word on anything.. not even mine. Listen to what people say, then do your own research and make your own informed decisions. Parroting other people's ignorance, especially when you finally confront someone else who is *really* informed, only makes you look bad in the long run. Parroters are a dime a dozen, and noone respects anything they say. People will only respect your words once they realize that when you finally say something, they know it has been researched and verified.