CBuffPet::Release - How does it work?

[Offspringfan1234]

Hallo Epvpers,

Ich würde gerne wie der Titel schon sagt gerne diese Funktion verstehen:

 Spoiler

void CBuffPet::Release( CBuffMgr* pBuffMgr )
{
#ifdef __WORLDSERVER
pBuffMgr->GetMover()->ResetDestParam( HIWORD( GetLevel() ), LOWORD( GetLevel() ), TRUE );
#endif // __WORLDSERVER
}

Die Funktion wird gecallt, wenn man ein normales Pet (Unicorn, Lion, Tiger, etc) deaktiviert. Die Parameter des Pets werden scheinbar mit Buffs gehandelt. HIWORD und LOWORD von GetLevel() holen sich den Parameter sowie den Wert des Parameters vom aktuell aktivierten Pet.

- Wie aber funktioniert das?
- Wäre es möglich hier weitere Parameter des Pets abzufragen - wenn ja wie?

Wäre über jeden Tipp sehr dankbar, gerne auch über andere Messenger oder pn.

Liebe Grüße Offspring

[Avalion]

If I recall, LOWORD returns the first 2 bytes of the value inserted into it, and HIWORD returns the last 2 bytes.

[Mognakor]

Originally Posted by Avalion

If I recall, LOWORD returns the first 2 bytes of the value inserted into it, and HIWORD returns the last 2 bytes.

PC's usually use Little-Endian-Architecture, thus LOWORD returns the last 2 bytes because they store the lower values.


@:

Was willst du erreichen?
Mit etwas Fantasie und Können geht alles.

[Offspringfan1234]

Mehr oder weniger habe ich das ja schon gesagt. Im Moment ruft er damit den einen Parameter und dessen Value vom Pet ab. Wenn man nun aber Pets mit mehreren Parametern hat, wie kann man es dann realisieren? Ich habe das im Moment mit einem ganz anderen Weg gelöst, da mir die Byte Variante aber neu ist würde ich diese gerne verstehen (was ich jetzt tue) und wissen ob es mit der Variante auch möglich ist mehrere Parameter + Value's abzurufen.

Vielen Dank schonmal!

[Mognakor]

Die Flyff Methode dass ein Pet ein Buff ist etc. ist designtechnischer Irrsinn.

Objekte die offensichtlich verschieden sind, sollten durch verschiedene Klassen realisiert werden.

Da die Methode ohnehin bereits der Klasse "CBuffPet" angehört gibt es keinen Grund Daten in Variablen zu verpacken die dafür nicht vorgesehen sind. Arbeitsspeicher hat heutzutage jeder Rechner mehr als genug also kommt es auf ein paar Byte mehr oder weniger auch nicht an.

Dafür verhindern eigene Variablen Bugs und funktionieren bei ordentlicher Benennung als Teil der Dokumentation auch ganz ohne Kommentare.

Am besten postest du mal deine Lösung.

[Avalion]

Originally Posted by Mognakor

PC's usually use Little-Endian-Architecture, thus LOWORD returns the last 2 bytes because they store the lower values.

intsafe.h

#define LOWORD(_dw)     ((WORD)(((DWORD_PTR)(_dw)) & 0xffff))
#define HIWORD(_dw)     ((WORD)((((DWORD_PTR)(_dw)) >> 16) & 0xffff))

[Mognakor]

Originally Posted by Avalion

intsafe.h

#define LOWORD(_dw)     ((WORD)(((DWORD_PTR)(_dw)) & 0xffff))
#define HIWORD(_dw)     ((WORD)((((DWORD_PTR)(_dw)) >> 16) & 0xffff))

The last bytes are on the right side..

Little-Endian Bit-Pattern:

fedc ba98 7654 3210

Big-Endian Bit-Pattern:

0123 4567 89ab cdef

Notice how HIWORD is shifted towards the end before using bit-AND.

[Avalion]

Originally Posted by Mognakor

The last bytes are on the right side..

I was reading from right to left, which is why I was saying the 'last' two bytes were the 'first' two bytes.

[Offspringfan1234]

I'm sorry that I haven't answered for such a while, but due to a stupid occurence my source got killed and I had to reset the source x)

Now I'm back on track and still try to make this pet-parameter thingy possible.

The interessting function is this one I guess:

 Spoiler

void CMover::ProcessPetAvail( void )
{
	CPet* pPet	= GetPet();
	if( pPet )
	{

#ifdef __NEW_PET_PARAMS

		if( HasPet() == FALSE )
		{
			CItemElem* pItemElem	= GetPetItem();

			DWORD _dwDstParam[3];
			int nParam[3];
			for( int i = 0; i < MAX_PET_AVAIL_PARAM; ++i )
			{
				pPet->GetAvailDestParam( i, _dwDstParam[i], nParam[i] );
				if( _dwDstParam[i] > 0 )
				{
					// wID: dwItemId
					// dwLevel: dwDestParam(H) + nParam(L)
					//AddBuff( BUFF_PET, (WORD)( pItemElem->m_dwItemId ), MAKELONG( (WORD)nParam[i], (WORD)_dwDstParam[i] ), 0 ); 
					SetDestParam( _dwDstParam[i], nParam[i], NULL_CHGPARAM );
				}
			}

#else	// __NEW_PET_PARAMS

		if( HasPet() == FALSE )
		{
			CItemElem* pItemElem	= GetPetItem();
			DWORD dwDestParam;
			int nParam;
			pPet->GetAvailDestParam( dwDestParam, nParam );
			if( dwDestParam > 0 )
			{
				// wID: dwItemId
				// dwLevel: dwDestParam(H) + nParam(L)
				AddBuff( BUFF_PET, (WORD)( pItemElem->m_dwItemId ), MAKELONG( (WORD)nParam, (WORD)dwDestParam ), 0 ); 
				SetDestParam( dwDestParam, nParam, NULL_CHGPARAM, TRUE );
			}

#endif	// __NEW_PET_PARAMS

#if __VER >= 12 // __PET_0519
			SetDestParamRandomOptExtension( pItemElem );
#endif	// __PET_0519
		}
	}
	else
	{

#ifdef __NEW_PET_PARAMS

		if( HasActivatedEatPet() == TRUE )
		{
			CItemElem* pItemElem	= GetPetItem();
			DWORD _dwDstParam[3];
			int nParam[3];
			for( int i = 0; i < MAX_PET_AVAIL_PARAM; ++i )
			{
				pPet->GetAvailDestParam( i, _dwDstParam[i], nParam[i] );
				ResetDestParam( _dwDstParam[i], nParam[i], TRUE );
			}
			PetRelease();
		}

#else	// __NEW_PET_PARAMS

		PetRelease();

#endif	// __NEW_PET_PARAMS

	}
}

So with the #ifdef's you're able to see what I've changed.
But since all kinds of pets, so also buff-pets are using this function, I have to be really careful if I change something.
So The HasPet() function still returns FALSE, even if the EatPet (Just a normal Pet) is active. And so the Params are added in the tick-time of the worldserver and u get like every second the stats of the pet which should only be added once.

Any suggestion on how to do it the smartest way?

Thanks in advice!

Offspring

[Mognakor]

Can you just write a concise description what you are trying to achieve.

aka.

WHY you want to understand the function.


Assuming FlyFF is programmed properly, you should be able to simply add/remove Buffs in the functions for using/unusing the pet.

[Offspringfan1234]

Maybe u could just add me on skype? I guess it's easier to explain things

[Mognakor]

nope