Jump to content
  • 0

Augmented Items Storage?


Bumble

Question

Hi,

 

I'm trying to figure out where augmented info is stored on an item. I'm using L2OFF Epilogue.

 

I know that usually augmentations are stored in dbo.user_items table, in the variation_opt1 and variation_opt2. But where is it stored before then?

 

Let's say an augmented item dropped on the ground. I know it's not possible by default, but how does the item know that it's augmented?

 

I'm using Emca's extender to do my testing, and I'm able to generate an augmentation on an item as soon as it drops. It works completely, but the augmentation doesn't save on logout. I need to figure out a way to call some kind of force-item-save functionality. I don't know where to look!

 

I hope someone here can help me out.

 

I'm also looking into removing the cannot drop/trade limitation.

 

Thanks!

-B

Edited by Bumble
Link to comment
Share on other sites

13 answers to this question

Recommended Posts

  • 0

I'm able to generate augmented items that are stored in the database, now they persist between sessions.

 

I'm looking for two last things:

 

1. Where can I disable the "augmented items cannot be traded/dropped" limitation? I've looked through all the interface files to see if I could find anything, but no dice. Am I missing something?

 

2. What's the packet I need to send from the server to make the character do the pickup animation? The way I'm generating the augments makes the pickup animation disappear.

 

Thanks!

Link to comment
Share on other sites

  • 0

To get the item to "save" properly, this might be one of the cases you have to implement your own Server ->cached packets, and save it yourself in cached, as far as picking up an item goes, something as simple as 

pUser->Action(pItem2, false, false);

will cause the player to walk to the item, and pick it up

As far as for where to patch to allow dropping, it should be somewhere inside User::OnDropItemPacket
and User::DropAndDestroyItem for when a user dies, if you want augment items to drop on player death

Link to comment
Share on other sites

  • 0
12 minutes ago, pada said:

To get the item to "save" properly, this might be one of the cases you have to implement your own Server ->cached packets, and save it yourself in cached, as far as picking up an item goes, something as simple as 

pUser->Action(pItem2, false, false);

will cause the player to walk to the item, and pick it up

As far as for where to patch to allow dropping, it should be somewhere inside User::OnDropItemPacket
and User::DropAndDestroyItem for when a user dies, if you want augment items to drop on player death

 

Thank you for your reply! I've been fighting this issue for days :)

 

I've made it work with a workaround. The "cannot be dropped" seems to be a hardcoded limitation in the epilogue client, it doesn't even send the packet unless it's a viable option. My workaround is to send the RequestDestroyItem packet instead, and before destroying the item on the server, I drop a copy of the item on the ground. One issue is that I don't know where the augmentations are stored on the dropped copy (or the original item for that matter), so I don't know what to check for when the player picks it up. Because I don't know where to check for this, I can drop and pick up the item again, and it'll re-roll augments.

 

I'll look into the cached packet option, but I'm still learning. If you have any examples, that'd be awesome.

 

I'll try the pUser->Action thing soon!

Thanks!

-B

 

 

Link to comment
Share on other sites

  • 0

I've managed to make the augments stay on items, as well as making the items droppable.

 

The "last" thing I need now, is to figure out where the augments are stored on an item. I know it's in the database, but where are the augment skills located in the CItem object?

Link to comment
Share on other sites

  • 0
class CItem : public CWorldObject
{
public:
	CSharedItemData* SD;						// 0x058	*
	CItemData* pItemData;						// 0x060	*
	CYieldLock* pLock;							// 0x068	*
	DWORD _unk60;								// 0x070	*
	int nOwnerNpcID;							// 0x074	*
	bool bIsOwnerBoss;							// 0x078	*
	BYTE _arUnk79[7];							// 0x079	*
	unsigned long nDropTime;					// 0x080	*
	bool bContribute;							// 0x084	*
	BYTE _arUnk85[3];							// 0x085	*
	CSmartID<CContributeData> spContributeID;	// 0x088	*
	int nVariationOption1;
	int nVariationOption2;
	BYTE _arUnk8C[0x124];						// 0x08C	*
	BYTE etcitemdata[8]; // DO NOT USE THIS, IT IS HERE TO HOLD THE SIZE TO CEtcItem size, for extending reasons

I dont know if its the same in GF, as i do not have the time to check quickly, but this is what it is in what i am working with, augments being VariationOptions

Link to comment
Share on other sites

  • 0
1 hour ago, pada said:

class CItem : public CWorldObject
{
public:
	CSharedItemData* SD;						// 0x058	*
	CItemData* pItemData;						// 0x060	*
	CYieldLock* pLock;							// 0x068	*
	DWORD _unk60;								// 0x070	*
	int nOwnerNpcID;							// 0x074	*
	bool bIsOwnerBoss;							// 0x078	*
	BYTE _arUnk79[7];							// 0x079	*
	unsigned long nDropTime;					// 0x080	*
	bool bContribute;							// 0x084	*
	BYTE _arUnk85[3];							// 0x085	*
	CSmartID<CContributeData> spContributeID;	// 0x088	*
	int nVariationOption1;
	int nVariationOption2;
	BYTE _arUnk8C[0x124];						// 0x08C	*
	BYTE etcitemdata[8]; // DO NOT USE THIS, IT IS HERE TO HOLD THE SIZE TO CEtcItem size, for extending reasons

I dont know if its the same in GF, as i do not have the time to check quickly, but this is what it is in what i am working with, augments being VariationOptions

 

Thanks for posting that. It's different from GF as far as I know. Which chronicle is that from?

 

The CItem I have access to looks like this:

	/* 0x0000 */ unsigned char padding0x0000[0x001C - 0x0000];
	/* 0x001C */ UINT32 itemId;
	/* 0x0020 */ unsigned char padding0x0020[0x0048 - 0x0020];
	/* 0x0048 */ CSharedItemData *sd;
	/* 0x0050 */ ItemInfo *itemInfo;
	/* 0x0058 */ class CYieldLock *lock;
	/* 0x0060 */ unsigned char padding0x0060[0x0078 - 0x0060];
	/* 0x0078 */ std::vector<CSkillInfo*> skills;
	/* 0x0098 */ unsigned char padding0x0098[0x00B8 - 0x0098];
	/* 0x00B8 */ UINT32 contributeDataObjectId;
	/* 0x00BC */ unsigned char padding0x00BC[0x0130 - 0x00BC];
	/* 0x0130 */ UINT16 attributeAttackType;
	/* 0x0132 */ UINT16 attributeAttackValue;
	/* 0x0134 */ UINT16 attributeFire;
	/* 0x0136 */ UINT16 attributeWater;
	/* 0x0138 */ UINT16 attributeWind;
	/* 0x013A */ UINT16 attributeEarth;
	/* 0x013C */ UINT16 attributeDivine;
	/* 0x013E */ UINT16 attributeDark;

There is no direct reference to variationOptions, itemOptionKeys or augments. But looking at your addresses, it kinda looks like they might be hiding in the skills pointers.

 

I'll report back, thanks!

Update: There's nothing in the skills array :/ I'm still not sure where to look.

Edited by Bumble
Link to comment
Share on other sites

  • 0

found my GF DB, it is at 

 

00000070 m_vItemSkill    std::xvector_CSkillInfo ?
00000090 m_Unkn_0098     dq ?                    ; offset
00000098 m__Unkn_00A0    dq 3 dup(?)             ; offset
000000B0 m_ContributeDataSmartId dd ?
000000B4 field_B4        dd ?
000000B8 m_nVariationOption1 dd ?
000000BC m_nVariationOption2 dd ?

 

  • Thanks 1
Link to comment
Share on other sites

  • 0
12 hours ago, pada said:

found my GF DB, it is at 

 


00000070 m_vItemSkill    std::xvector_CSkillInfo ?
00000090 m_Unkn_0098     dq ?                    ; offset
00000098 m__Unkn_00A0    dq 3 dup(?)             ; offset
000000B0 m_ContributeDataSmartId dd ?
000000B4 field_B4        dd ?
000000B8 m_nVariationOption1 dd ?
000000BC m_nVariationOption2 dd ?

 

Thanks for this! I was doing some testing in setvariation, and I calculated the 0xB8 offset as well, but I wasn’t sure I was correct. It’s great to see that I’m on the right track. 
 

now I just need to find a way to grab that address at the same time... efforts don’t far are not really successful. I’d like to grab it during the useitem packet. I feel like I’m getting close!

Link to comment
Share on other sites

  • 0

use item packet you have access to the items ServerID, so a simple call to CInventory::GetByServerID will get the CItem and you can do what ever checks you want on UseItem packet

Link to comment
Share on other sites

  • 0
36 minutes ago, pada said:

use item packet you have access to the items ServerID, so a simple call to CInventory::GetByServerID will get the CItem and you can do what ever checks you want on UseItem packet

 

I've gotten that far, but any attempts I've made at isolating the augment IDs after that have not been working. I have the correct CItem pointer, but I'm really unsure of what to do next. I'm just trying a bunch of things, seeing if I can grab the data. I'm just not getting anywhere yet.

 

It feels like it should be simple. Like something like this:

 

            UINT32* itemOptionKeyA = reinterpret_cast<UINT32(*)>(item + 0xB8);
            INT16 testAA = static_cast<INT16>(itemOptionKeyA[0]);
            INT16 testAB = static_cast<INT16>(itemOptionKeyA[1]);

Edited by Bumble
Link to comment
Share on other sites

  • 0
1 minute ago, pada said:

You will save yourself alot of work in the long run, to just properly define classes so you can do pItem->m_nVariationOption1 ect

 

I'm sure you're right, and I would do that if I knew how :) I'm still learning! Thanks for helping out.

Link to comment
Share on other sites

  • 0

I'm still trying to figure this out.. I have so many questions, but I really just need to know how to grab the data that one time during the useitem packet.

 

Could someone please give an example of how to do it? I'd be so thankful. C++ is not my strong suit.

 

E: Solved, thanks pada

Edited by Bumble
  • Upvote 1
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

AdBlock Extension Detected!

Our website is made possible by displaying online advertisements to our members.

Please disable AdBlock browser extension first, to be able to use our community.

I've Disabled AdBlock