My first contribution... Here goes nothing...
Forgive me if I do something taboo, I have only been following this scene for a little over a week. Any way I dove head first into the code and decided to fix a few things that were bugging me (err.. yeah).
Any way here is what I did: -Zone Bind Points (added some fields to start_zones and fixed an issue that would crash the client if you died to your bind point) -Fixed an issue that was causing you character creation skin selections to be lost, now everyone doesn't have to look the same (Yeeaa!!) Additions -the start_zone table now has support for wildcarding on selection this means that DB developers don't have to put in (number of selections on map screen) *(number of races) *(number of classes)*(number of dieties) = number records in the database. putting a -1 in of these fields in the DB basically selects all of the combinations for that field. So if I only wanted to have 1 starting point for each class I would put -1 in the diety, choice and race coloumn for each record. When specifying start_zones just remeber this SQL statement (its the one we use now to get start_zones): Code:
SELECT x,y,z,zone_id,bind_id,bind_x,bind_y,bind_z FROM start_zones WHERE (player_choice=%i OR player_choice=-1) and (player_class=%i OR player_class=-1) and (player_deity=%i OR player_deity=-1) and (player_race=%i OR player_race=-1) ORDER BY select_rank DESC This allows you to specify things like I want all characters to start in the nexus as a default. However I want all warriors to start in Halas. This would require 2 records in the DB, one for the nexus with -1 for race,choice,class and diety and a select rank of say 10. And one for the warriors that go to halas and it would have -1 for race, choice, and diety and a select_rank of say 20. If later you wanted to further specify where agnostic warriors go, you would just add one more record with a higher select_rank. Zoneing Fixes well after I added that code I realised that bound characters that die crash thier clients (never knew that since I was never bound before). So I decided to hunt that bug down. It turns out that this peice of code was the culperit Code:
if (zc->zoneID != 0 && dead) I also cleaned up the code a little in OP_ZoneChange so you wouldn't do wierd things like go to -3,-3,-3 when there was a perfectly acceptable safe_zone to go too. Character skins The last thing I decided to tackle was character skins and this was acutually the hardest thing of all to debug. First I corrected struct that recieved info from the client on character creation as there were a few guessed at spots inside that struct. I did this through numerous tedious trial and error chracter creations (Ie create a gnome a certian way, then create a second gnome the exact same way except this time change just his beard and analysis the data we get). After I got the data for CharCreate_Struct ok, I moved onto trying to figure out why these character specific skin changes never got back to client. It turns out that CharacterSelect_Struct had about 60 bytes of unknown data. So I then went through a fairly painful process of trying to figure out what order the data went in on its way back. Fortunatly I was able to figure it out finally. It was challenging though. Hope everyone can benefit from some of my work at least a little :). Here are the diffs: First SQL changes Code:
ALTER TABLE start_zones ADD bind_x FLOAT DEFAULT "0" NOT NULL Code:
Index: database.cpp Code:
Index: eq_packet_structs.h Code:
Index: client_process.cpp Ves |
:o
Wow, great work! All this after only a week as well :) Don't suppoose you can post the whole file? Unles you can tell me how to use the diff :P Monrezz |
Good to see another code tinkerer join the ranks :-)
Nice work. |
Quote:
client_process.cpp goes in the zone directory and the other two go in the common directory. Hope that helps... Don't forget about the database changes (the 4 alter table SQL statements)... How do I submit these changes so they can be added to the next release?? Does posting it here do that for me? Should I PM someone specific? Ves |
Thanks, got it all compiled and it runs smoothly. Didn't crash on death either :)
As for submitting - when a dev reads this (trump) I'm sure he'll merge after a little testing. Monrezz |
Or you can catch them on IRC chat and let them know.
|
Not to knock on anyone, but if you're responsible for merging files you really should be familiar with diff/patch. If you're in the Windows world it can be a bit foreign, but there are some implementations out there that you can use. I haven't used it, but WinMerge (http://winmerge.sourceforge.net/) looks like it would work for this purpose.
Keep up the good work vesuvias :wink: |
only one guy merges the code into eqemu source... Trumpcard.
the rest of us just like to test out other people's tweaks. |
Quote:
The problem you run into with diff is that the source changes very dynamically. Several times a day in some cases at the developer level. So you end up with a diff that doesn't match the source you are working with. Quote:
|
I'm going to merge this into our server's code right away. And into cvs as soon after that as I can. :-)
We may have a problem. In 5.5 (eqlive patch compatible) the player profile has changed... it may/may not affect your fixes on player appearence. |
Quote:
Currently I am trying to analyze the packet sniffs from both a successful spell cast and bugged one (the spell bug is really pissing me off, so i am going to fix it). If I can get that fixed I will probably turn my attention toward why zoning is so unstable sometimes. I figured 5.5 might change everything completely and if thats the case it's no big deal. Everything I am doing now I chalk up to learning experiences. I have never had the need to analyze packets before so this project is providing me with some interesting challenges. I have more fun tinkering than playing for some reason (guess what race I favor when I do play online :lol: ). Ves |
Quote:
I have been messing around with it and once I set the correct points I can zone back and forth #zone in and out without crashing the client to desktop. I saw another thread here that shows a fix to the steamfont zone crash, check that one out and I bet it will fix many of the zone crash problems, basically there is an 8bit variable where there should be a 16bit variable so zone points are not getting either sent or received correctly. Here is the title of that thread -- Got akanon to steamfont zoneline to work (code & db) Great work btw. |
Rojan.
in the worldbuilders forum i posted up a fixed zone table. has everything except GoD zones. here is the link to it http://www.eqemulator.net/forums/viewtopic.php?t=12672 all #zone are working right. no underworld or bad locs. |
Quote:
|
Quote:
|
All times are GMT -4. The time now is 10:51 PM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.