Go Back   EQEmulator Home > EQEmulator Forums > Development > Development::Server Code Submissions

Reply
 
Thread Tools Display Modes
  #1  
Old 12-24-2010, 11:44 AM
l0stmancd
Fire Beetle
 
Join Date: Apr 2005
Posts: 23
Default

Hey folks,

I took a look at the errors that thepoetwarrior mentioned and as Trevius mentioned, I do not believe those would be resolved from this patch.

Specifically, this was targeting the errors surrounding a zone crashing causing world container items to be lost.

I spoke to a few of the guys from the EZ Server and they mentioned they see this only when they are removing an augment using the SoD client that they put on using the Titanium client. I tested this out with the container approach and did not reproduce this issue. This means nothing, though, because I tested this out using the augmentation pool approach and did not reproduce this issue either.

I see the area in the code where this deletion is occurring but I do not know what would be causing it beyond what Trevius mentioned. We cannot remove that part of the code as it was added to deal with an exploit in.. shared bank I believe?...

Will research that issue, if it is still happening, in another thread post.

---

Update - spoke to thepoetwarrior and it seems that this (the item deletion message) happens on his server about once a week to some player. I believe this is all centered around the augmentation pool. I do not know if the tradeskill container would have an effect on this.

---

Update 2 - In consideration of this "Deleting Item!" issue, while it may not be directly worldcontainer related it may still have something to do with this in an indirect fashion. I assume this issue comes from moving an item from your character to a world container and back. With this patch, you have the option of saying that all aug items can be combined on your local container ___. This means, unless this item deletion is -directly- related to the augmentation procedures, this should move the chance to hit the "Deleting Item!" defect to what you would normally get when you re-arrange your packs or move equipment from one slot to another. IE: It may not fix the underlying issue, but it should make it as common as you get when you take off your chest slot or put your chest slot back on.
Reply With Quote
  #2  
Old 12-28-2010, 09:48 AM
trevius's Avatar
trevius
Developer
 
Join Date: Aug 2006
Location: USA
Posts: 5,946
Default

Finally had a chance to review this code a bit. I think it is a good idea, but not sure I follow the code enough to commit it myself.

I am not really sure why you check 10 slots in this function (and a few other spots):

Code:
bool ItemInst::WillAugmentCauseLoreCollision(ItemInst* newAugment)
Max aug slots on an item is currently 5 slots and if anything, should be coded to use the defined value for max aug slots, "MAX_AUGMENT_SLOTS". The only thing I can think of that would run through 10 slots would be bags. I don't really know the goal of this function. I would think you could just use CheckLoreConflict(), but maybe I am missing something here. Aug Lore checks should be done against the entire inventory, not just per item. I haven't looked too in-depth into it, though.

Also, I don't think the DB query you have is required. You should be able to pull that info directly from shared memory, I think.

There were a few other things I am not quite clear on yet, but I don't really want to go into each one.

As it is currently, I think this could probably be done in a different and maybe more user-friendly way. With the limitations of how this is coded (such as you can't select which aug slot to remove), I think it might be a bit too much of a hack to make it into the SVN. Even though it would be another hack, I think this could be done by tricking the client into thinking it is interacting with a real aug pool. It would probably take more work and innovation to make it work as I am thinking, but I think it may be possible to trick the client into using a bag as a real aug pool. I can imagine how to do part of it (may only work for SoF+ clients though), but the part I am not sure of offhand is how it would actually be saved in the inventory in the case of a crash.

Sorry, I don't mean to shoot down your submission, but if something like this was added, I just think it would have to be done a bit differently.
__________________
Trevazar/Trevius Owner of: Storm Haven
Everquest Emulator FAQ (Frequently Asked Questions) - Read It!

Last edited by trevius; 12-28-2010 at 09:59 AM..
Reply With Quote
  #3  
Old 12-28-2010, 11:57 AM
l0stmancd
Fire Beetle
 
Join Date: Apr 2005
Posts: 23
Default

Hi Trevius,

Thanks for taking the time to review this.

The lore conflict may simply be confusion on my part. I was under the impression that a lore augment was simply an augment that could not be in an item twice. The client itself and other server checks have already determined if a user can hold two of an augment (in hand, etc) by the time the user has them. This check was simply to guarantee there would not be another of the same lore item (or lore group) in the item they are augmenting. If the game should not allow two of the same lore augment -anywhere, in any augmentation slot, on any item - then we should definitely remove the check lore augment code and move to the CheckLoreConflict code. Mind you - this may be unnecessary since by the time the user has two of these same lore augments, the CheckLoreConflict should already have been called (which is why it does not exist in the augmentation procedures as they are in trunk).

Regarding the database query? You are absolutely correct. Can remove this function and switch to the following code snippet.

Code:
				for(uint8 ctr = 0; ctr < MAX_AUGMENT_SLOTS; ctr++) {
					ItemInst* augToRemove = toBeAuged->GetAugment(ctr);
					
					if (augToRemove) {
						if (idOfAssumedSolvent == augToRemove->AugDistiller) {
							slotToRemove = ctr;	
							break;
						}
					}
				}
Holding off on fixing those and resubmitting until I understand your last note.

If it is possible to change this to work as a hand held augmentation pool (with item select, etc) this would be a good fix as long as it would handle zone server crashing. I am afraid, though, I am not familiar with how you would do that. If you do not have time to look into this, would you mind giving a two sentence explanation that I can take and dig into?

I agree that this fix is not perfect in so far as you could not select which augment to remove (just the first one it finds of a given type that has been inserted) but it would fix an issue that is causing problems now. That said, given that this would be an optional rule and does not seem to pollute the code surrounding tradeskills / augmentation I do not believe this would be hard to revert out if there was a better solution in the future. I will gladly spend the time to fix any issues you see / think can be improved here if you would still consider the concept for submission. If it would be easier, I can create a set of much smaller diffs that show the code progression more obviously.

Let me know - Took off work until Tuesday of next week and will gladly spend that time working on this.
Reply With Quote
  #4  
Old 01-02-2011, 05:55 AM
trevius's Avatar
trevius
Developer
 
Join Date: Aug 2006
Location: USA
Posts: 5,946
Default

Well, I had another chance to look into this a bit further to find a way to do this that I think would be good enough to make it into the SVN and I think I found it!

I had a feeling that there may be some existing way to let aug pool windows work from inventory and was about to start experimenting with some ideas. First, I figured I would look into what it is that causes the different existing containers like Collapsible Spit to bring up a tradeskill window. The answer is simple; bagtype. So, I checked the wiki page here:

http://www.eqemulator.net/wiki/wikka...uDBSchemaitems

Under Bagtype there, it lists each type. One of them happens to be:

Quote:
53 = Augmentation Sealer (for applying augments)
So, searching the DB for an item with that bagtype yielded this:

66180 - Augmentation Sealer

Checking that item out looks like it should be fairly simple to implement a fully functional aug pool that works from inventory.

I don't really have the time to work on the code for it, but I think implementing support for bagtype 53 to act as an aug pool in the inventory would be perfectly acceptable.

You won't need a rule for setting item ID of the item, just need to have it only work from bagtype 53 items.

Also, I don't think you really need to worry about doing things that aren't already done in the current aug pool code. Stuff like the extra lore conflict checking shouldn't be necessary. Though, since the existing aug pool code probably isn't perfect, I don't think some adjustments here and there would be bad if they make sense to do.

I am still a fairly novice to intermediate coder myself. I don't know how best to put it, but if I am finding issues with your code like the previous stuff, it concerns me a bit. So, if you do make another rewrite and submit it here, I will have to make sure I fully understand everything in it 100% before I will consider committing it. Otherwise, I may have to defer to one of the more experienced devs to commit it if it passes their inspection.
__________________
Trevazar/Trevius Owner of: Storm Haven
Everquest Emulator FAQ (Frequently Asked Questions) - Read It!
Reply With Quote
  #5  
Old 01-02-2011, 06:16 PM
l0stmancd
Fire Beetle
 
Join Date: Apr 2005
Posts: 23
Default

Hi Trevius,

I see what you mean by the bagtype change. Just started working on it here. Changing the bagtype to 53 has given a lot of things by default but there still needs to be a code change. Looking into this now.

Thanks!
Reply With Quote
  #6  
Old 01-02-2011, 08:20 PM
l0stmancd
Fire Beetle
 
Join Date: Apr 2005
Posts: 23
Default

This is actually a pretty clean change. Still working through it but I think the only really odd part is in the slot numbering. The client is sending slots for the "container" that appear to be shifted. IE: Sending slot 30 for container slot 8 in inventory (29). Consistent in SoD inventory, havent tested bank yet...

Will see if we are handling this in a consistent way in the code already...
Reply With Quote
  #7  
Old 01-03-2011, 03:38 AM
trevius's Avatar
trevius
Developer
 
Join Date: Aug 2006
Location: USA
Posts: 5,946
Default

It is normal for all SoF+ clients to send shifted slot IDs for all slots over slot 21, since Power Source replaced the Titanium Ammo slot and bumped them all up by 1. This is all handled directly in the <patch>.cpp files near the top such as in this file for SoD:

http://code.google.com/p/projecteqem...atches/SoD.cpp

I made slot converting functions that adjusts Titanium slots to later clients slots and visa versa.

So, even though you see it sending slot 30 (cursor slot in Titanium), when it is in slot 29, it is actually converted back to slot 29 before it is actually handled in any way.

If something is making it into the handling without being converted, it is most likely due to us missing an encode/decode in that .cpp file for that particular packet type. It is pretty easy to add encodes/decodes if needed, we just need to know which packet it is that isn't in there already.
__________________
Trevazar/Trevius Owner of: Storm Haven
Everquest Emulator FAQ (Frequently Asked Questions) - Read It!
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 06:58 PM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3