Inventar Göße

10/13/2017 14:02 Xylenu#1
Hallo zusammen,
ich frage mich generell schon seit geraumer Zeit, was es denn jetzt bei dem Vergrößern des Inventars zu beachten gibt.
Manche behaupten, es würde ausreichen den m_dwObjIndex in der DB anzupassen und auch gegebenfalls den/die m_apItem. Andere wiederum empfehlen bestehenden Code neu zu schreiben bzw umzuschreiben.

Ich würde lediglich das Inventar auf bis zu 100 Plätze erweitern wollen.
Generell halte ich sehr wenig von dem "Tabbed Inventory" und bevorzuge das standard Inventar nur eben etwas größer.

Beste Grüße,
Xylenu
10/13/2017 17:56 Mike Oxmaul#2
Die m_inventory Spalte würde definitiv nicht ausreichen um alles zu speichern
10/13/2017 19:45 Wanetrain#3
Quote:
Originally Posted by Jupsi332 View Post
Die m_inventory Spalte würde definitiv nicht ausreichen um alles zu speichern
Why Not? SQL juckt das einen Furz. Genau wie den Server.

Also pass uf bub, man machte nicht umsonst das Tabbed Inventory, während das Tab 1 offen ist, sind 2, 3 und 4 Inaktiv. Würdest du jetzt aus einem Inventory Tab einfach mal 100+ plätze machen würdest du ganz schnell merken das der Client dir durch Schlampigen Code seitens GalaFuck in die Knie geht.

Also Variante 2, das ganze ding neu Schreiben.

Mfg.
10/13/2017 22:31 Мentus#4
Quote:
Originally Posted by Jupsi332 View Post
Die m_inventory Spalte würde definitiv nicht ausreichen um alles zu speichern
Je nach dem wie groß das Inventar werden soll, gibt es natürlich Limits im Source (und weitere in der Datenbank). Beispielsweise statisch allokierter Speicher (z.b Arrays)
Ich habe mir den Aufwand gemacht und ein kleines Tool geschrieben, was für mich die Arbeit übernimmt, denn Datenbankarbeit ist langweilig und nervend.

[Only registered and activated users can see links. Click Here To Register...]

Hat nur ein paar Funktionen, dennoch sehr hilfreich. Items werden beim Erweitern des Inventars nicht verschoben oder Sonstiges.

Ich lasse übrigens das Floral Inventar (glaub 128 Slots) in einem varchar(max) speichern, also scheiß auf weitere Tabellen.
10/14/2017 12:31 Mike Oxmaul#5
Quote:
Originally Posted by Wanetrain View Post
Why Not? SQL juckt das einen Furz. Genau wie den Server.

Also pass uf bub, man machte nicht umsonst das Tabbed Inventory, während das Tab 1 offen ist, sind 2, 3 und 4 Inaktiv. Würdest du jetzt aus einem Inventory Tab einfach mal 100+ plätze machen würdest du ganz schnell merken das der Client dir durch Schlampigen Code seitens GalaFuck in die Knie geht.

Also Variante 2, das ganze ding neu Schreiben.

Mfg.
Find ich immer wieder toll wie ihr mir einen erzählen wollt.
Ich sagte nicht das das ändern der spalte das einzige ist was man machen muss oder machen sollte.
Ich bin davon ausgegangen das der TE 168 Slots haben möchte, nur ohne Tab sortierung. SQL ist pro spalte auf 8000 Zeichen begrenzt, zumindest bei den älteren versionen, bei neueren weiß ich es nicht.

Ich habe auch nicht gesagt das es das einzige ist was man machen / ändern muss, wollte lediglich damit andeuten das dort EINS von mehreren Problemen bei der erhöhung der Anzahl ist.

Quote:
Originally Posted by Мentus View Post
Je nach dem wie groß das Inventar werden soll, gibt es natürlich Limits im Source (und weitere in der Datenbank). Beispielsweise statisch allokierter Speicher (z.b Arrays)
Ich habe mir den Aufwand gemacht und ein kleines Tool geschrieben, was für mich die Arbeit übernimmt, denn Datenbankarbeit ist langweilig und nervend.

[Only registered and activated users can see links. Click Here To Register...]

Hat nur ein paar Funktionen, dennoch sehr hilfreich. Items werden beim Erweitern des Inventars nicht verschoben oder Sonstiges.

Ich lasse übrigens das Floral Inventar (glaub 128 Slots) in einem varchar(max) speichern, also scheiß auf weitere Tabellen.
Ich hab deinen Code gesehen, du hast aber auch viele Item Eigenschaften in eine Andere Tabelle ausgelagert, den Rest hatte ich keine Zeit / Lust mir anzugucken.
10/14/2017 13:19 Blouflash#6
Quote:
Originally Posted by Jupsi332 View Post
Ich bin davon ausgegangen das der TE 168 Slots haben möchte, nur ohne Tab sortierung. SQL ist pro spalte auf 8000 Zeichen begrenzt, zumindest bei den älteren versionen, bei neueren weiß ich es nicht.
Also eigentlich kann man ja 2GB pro Spalte speichern und das gilt auch schon seit SQL Server 2008
10/15/2017 02:16 FlyffServices#7
Quote:
Originally Posted by Wanetrain View Post
Why Not? SQL juckt das einen Furz. Genau wie den Server.

Also pass uf bub, man machte nicht umsonst das Tabbed Inventory, während das Tab 1 offen ist, sind 2, 3 und 4 Inaktiv. Würdest du jetzt aus einem Inventory Tab einfach mal 100+ plätze machen würdest du ganz schnell merken das der Client dir durch Schlampigen Code seitens GalaFuck in die Knie geht.

Also Variante 2, das ganze ding neu Schreiben.

Mfg.
Was laberst du eigentlich für eine riesen Kacke.

Warum sollte das ab 100+ Zeilen code faxxen schieben? Und was hat "GalaFuck" damit zutun?
Man kann das Inventory auf 128 Slots erweitern alles darüber würde overflown wegen des Datentyps von objID etc. Wie du jetzt auf 100 kommst oder was daran scheise von GalaFuck sein soll versteh ich nicht.
10/15/2017 11:29 Wanetrain#8
Quote:
Originally Posted by FlyffServices View Post
Was laberst du eigentlich für eine riesen Kacke.

Warum sollte das ab 100+ Zeilen code faxxen schieben? Und was hat "GalaFuck" damit zutun?
Man kann das Inventory auf 128 Slots erweitern alles darüber würde overflown wegen des Datentyps von objID etc. Wie du jetzt auf 100 kommst oder was daran scheise von GalaFuck sein soll versteh ich nicht.
Jetzt gönnst du dir in Ruhe nochmal den Text und schaust dir den Quellcode an von FlyFF RICHTIG an.

Der Komplette Render Loop von FlyFF ist Bullshit, das dürfte jeder bereits wissen eigentlich, das zeug wurde 1 zu 1 aus einem Buch Kopiert (Wenn ihr wollt gebe ich euch noch die Quelle dazu..) und das "System" was hinter dem Inventory Steckt ist ebenso Bullshit da es viel zu viele Fehler aufweist die damals evtl. der Standard waren aber es heute bei weitem nicht mehr sind. Nun wir gehen hin und Böllern in die selbe Scheiße einfach mal das Doppelte an Items rein, was Passiert denn? Bedenke der Client geht das alles mit dem RENDER LOOP durch immer und immer wieder.

Das selbige Spielt habt ihr beim Chat, aber es ballert auch keiner irgendwie..
10/15/2017 18:21 Мentus#9
Quote:
Originally Posted by FlyffServices View Post
Was laberst du eigentlich für eine riesen Kacke.

Warum sollte das ab 100+ Zeilen code faxxen schieben? Und was hat "GalaFuck" damit zutun?
Man kann das Inventory auf 128 Slots erweitern alles darüber würde overflown wegen des Datentyps von objID etc. Wie du jetzt auf 100 kommst oder was daran scheise von GalaFuck sein soll versteh ich nicht.
Ich hatte definitiv schon über 128 Slots und da hatte ich nur eine kleinere Komplikationen und zwar beim Serialisieren.
Hier der Offi-Code:
Code:
template <class T> void CItemContainer<T>::Serialize( CAr & ar )	// 0-673	// 466-631
{
	DWORD	adwObjIndex[128];

	unsigned char chSize	= 0;

	if( ar.IsStoring() )
	{
		
		ar.Write( m_apIndex, sizeof(DWORD) * m_dwItemMax );
		
		u_long uOffset	= ar.GetOffset();
		ar << chSize;

		for( u_char ch = 0; ch < m_dwItemMax; ch++ )	// 0-504
		{
			if( m_apItem[ch].IsEmpty() == FALSE )
			{
				ar << ch;
				m_apItem[ch].Serialize( ar );
				chSize++;
			}
			adwObjIndex[ch]		= m_apItem[ch].m_dwObjIndex;
		}

		ar.Write( adwObjIndex, sizeof(DWORD) * m_dwItemMax );

		int nBufSize;
		LPBYTE lpBuf	= ar.GetBuffer( &nBufSize );
		*( lpBuf + uOffset )	= chSize;
	}
	else
	{
		ar.Read( m_apIndex, sizeof(DWORD) * m_dwItemMax );
		// Clear
		for( u_long i = 0; i < m_dwItemMax; i++ )
			m_apItem[i].Empty();

		ar >> chSize;

		unsigned char ch;
		for( i = 0; i < chSize; i++ )
		{
			ar >> ch;
			m_apItem[ch].Serialize( ar );
		}

		ar.Read( adwObjIndex, sizeof(DWORD) * m_dwItemMax );
		for( i = 0; i < m_dwItemMax; i++ )
		{
			m_apItem[i].m_dwObjIndex	= adwObjIndex[i];
		}
	}
}
Ich glaube, mehr brauche ich auch nicht zum Serialisieren zu sagen.

Das was Wanetrain sagen wollte, dass der Quellcode von Flyff nicht für sowas ausgelegt ist. Man kann durchaus das Inventar so weit erweitern wie man möchte, dennoch sollte man realistisch sein und sich fragen:

Wieso braucht man so viel Platz?
Sollte man den Clienten wirklich noch weiter belasten?

Bei so einem alten Quellcode wie Flyff sorgt dies meist für Instabilität.
10/15/2017 18:36 FlyffServices#10
Quote:
Originally Posted by Wanetrain View Post
Der Komplette Render Loop von FlyFF ist Bullshit, das dürfte jeder bereits wissen eigentlich, das zeug wurde 1 zu 1 aus einem Buch Kopiert (Wenn ihr wollt gebe ich euch noch die Quelle dazu..) und das "System" was hinter dem Inventory Steckt ist ebenso Bullshit [........] Nun wir gehen hin und Böllern in die selbe Scheiße einfach mal das Doppelte an Items rein, was Passiert denn? Bedenke der Client geht das alles mit dem RENDER LOOP durch immer und immer wieder.
Was laberst du schon wieder für eine gequirlte Kacke?

Du bekommst vielleicht bei 100.000 Items im Inventory Probleme aber dem Client juckt es nicht ob er 42 oder 200 item icons rendert.
Wir haben das Jahr 2017 und nicht 1990.

Quote:
Originally Posted by Wanetrain View Post
...da es viel zu viele Fehler aufweist die damals evtl. der Standard waren aber es heute bei weitem nicht mehr sind...
ohja
früher war mal "der standard" viele fehler zu haben
nice

Quote:
Originally Posted by Мentus View Post
Ich hatte definitiv schon über 128 Slots und da hatte ich nur eine kleinere Komplikationen und zwar beim Serialisieren.
Hier der Offi-Code:
Sorry stimmt! das maximum liegt glaube ich bei 214 items die man maximal ins Inventar packen kann.


@[Only registered and activated users can see links. Click Here To Register...]

Antworte doch auf meine PN. Wie hast du diesen super "login any account" hack zu deiner brutalen Fuck'IT Zeit gemacht? Das geht doch garnicht sagst aber in großen tönen bevor Pumaaa sein fehler einsah das du es schon vor jaaaaaahren geused hast?