[Release] Droppdialog only C++

[rrrrrrremix]

Originally Posted by Seחsi

Eine Gruppierung:
Wenn (wert x > 0 und x < 123 ist) oder wert y == 987 ist, dann
return false

Zwei Gruppierungen:
Wenn wert x > 0 und x < 123 ist, dann
return false
Wenn wert y == 987 ist, dann
return false

Da finde ich es mit zwei Gruppierungen deutlich übersichtlicher

finde die erste variante besser
bin doch schreibfaul

[DasSchwarzeT]

Originally Posted by Lefloyd

Da sieht man mal wieder wie schnell man "Lücken" im Source einbaut :3
Zumindest wenn man Coredowner als Lücke bezeichnet^^

Ich rate dringend dazu, das Ganze um ein paar weitere Abfragen zu erweitern:

if (!CanHandleItem())
	return false;

if (pkItem->IsExchanging())
	return false;

if (pkItem->isLocked())
	return false;

if (quest::PC* pPC = quest::CQuestManager::instance().GetPC(GetPlayerID()))
{
	if (pPC->IsRunning() && GetQuestItemPtr() == pkItem)
	{
		sys_err("cannot delete item that is used in quest");
		return false;
	}
}

Ansonsten könnte das Ganze sehr schnell missbraucht werden...^^

Kind Regards,
Lefloyd

Exchange ist nicht nötig, wenn man handelt und jemand das Item, das im Exchangewindow liegt löscht:



Danke trotzdem, das mit der Quest ist nicht zu vernachlässigen

[Lefloyd]

DasSchwarzeT, doch die Exchange-Abfrage ist nötig. Es gibt durchaus einen Weg ohne diese Abfrage die Funktion als Coredowner zu missbrauchen; ich möchte den Weg aber nicht umbedingt hier erklären. Aber füg die Abfrage einfach ein, es schadet dir nicht..

Kind Regards,
Lefloyd

[x"Kazuki]

Jetzt batteln sich hier die C++ Spezis :P

@Kori

Danke für das Rlzzz

[DasSchwarzeT]

Originally Posted by x"Kazuki

Jetzt batteln sich hier die C++ Spezis :P

@Kori

Danke für das Rlzzz

Was heißt schon battlen. Das hier ist ein Forum, hier soll Informationsaustausch herrschen.
Wenn das in einem angemessenen Ton geschehen würde, dann käme es
auch niemals so rüber als wollte sich irgendwer bekämpfen oder zeigen, dass er besser ist. Das Problem ist einfach, dass es hier zu viele Leute mit nem großen Ego gibt und sich viele keine Fehler eingestehen können.

[.K0rí]

Originally Posted by x"Kazuki

Jetzt batteln sich hier die C++ Spezis :P

@Kori

Danke für das Rlzzz

Remix musste ja wiedermal alles besser wissen der rest wollte mir nur helfen

[MQTT.]

Trotz alldem Danke für das Release.

[​Arrow​]

Originally Posted by DasSchwarzeT

Was heißt schon battlen. Das hier ist ein Forum, hier soll Informationsaustausch herrschen.
Wenn das in einem angemessenen Ton geschehen würde, dann käme es
auch niemals so rüber als wollte sich irgendwer bekämpfen oder zeigen, dass er besser ist. Das Problem ist einfach, dass es hier zu viele Leute mit nem großen Ego gibt und sich viele keine Fehler eingestehen können.

Ich sehe hier keinen technischen Fehler von Remix also ergibt das keinen Sinn.

[Lefloyd]

Arrow, nimm das Folgende bitte nicht allzu Ernst aber es enthält keinen technischen Fehler:
Das Geschriebene von Remix enthält durchaus technische Fehler. Er sagt

20 if abfragen hintereinander die bei true das selbe machen ist genau so behindert wie 255 elemente wenn man 4 braucht

Allerdings ist das falsch, da ersteres lediglich ein Coding-Stil ist und letzteres ein unnötiger Ram-Verbrauch (was tatsächliche Auswirkungen im ausgeführten Programm hat). Das was er bei mir bemängelt hat, ist aber lediglich eine Verlängerung der Arbeitszeit durch erhöhten Aufwand beim Schreiben des Quellcodes und verschlechtert in keinster Weise die Ausführung des Programms. Ich bin gerade etwas zu faul noch weitere technische Fehler zu suchen, denn das ist nicht mein Job.

PS: Bei deiner Aussage liegt ebenfalls ein technischer Fehler vor. Du sagst es ergibt keinen Sinn, weil bei der Aussage von Remix kein technischer Fehler zu sehen ist (was schon mal nicht korrekt ist); dabei bezieht sich diese Aussage auf die Allgemeinheit und nicht nur auf diesen konkreten Fall. Es wird gesagt, dass es hier "viele Leute gibt", die so sind und so handeln - aber nicht dass all das was dort gesagt wird auch in diesem Beispielsthread auftritt.

So viel zu den technischen Fehlern. :3

Kind Regards,
Lefloyd

[​Arrow​]

Originally Posted by Lefloyd

Arrow, nimm das Folgende bitte nicht allzu Ernst aber es enthält keinen technischen Fehler:
Das Geschriebene von Remix enthält durchaus technische Fehler. Er sagt Allerdings ist das falsch, da ersteres lediglich ein Coding-Stil ist und letzteres ein unnötiger Ram-Verbrauch (was tatsächliche Auswirkungen im ausgeführten Programm hat). Das was er bei mir bemängelt hat, ist aber lediglich eine Verlängerung der Arbeitszeit durch erhöhten Aufwand beim Schreiben des Quellcodes und verschlechtert in keinster Weise die Ausführung des Programms. Ich bin gerade etwas zu faul noch weitere technische Fehler zu suchen, denn das ist nicht mein Job.

PS: Bei deiner Aussage liegt ebenfalls ein technischer Fehler vor. Du sagst es ergibt keinen Sinn, weil bei der Aussage von Remix kein technischer Fehler zu sehen ist (was schon mal nicht korrekt ist); dabei bezieht sich diese Aussage auf die Allgemeinheit und nicht nur auf diesen konkreten Fall. Es wird gesagt, dass es hier "viele Leute gibt", die so sind und so handeln - aber nicht dass all das was dort gesagt wird auch in diesem Beispielsthread auftritt.

So viel zu den technischen Fehlern. :3

Kind Regards,
Lefloyd

Subjektivität ist also ein technischer Fehler?
Interessant.
Ja, so viel zu den technischen Fehlern :3

Bleiben wir doch beim tatsächlichen Technischen und ignorieren subjektive Meinungen.

"nicht jeder compiler benutzt die gleichen optimierungsmethoden"

Ist das einzige technische, was noch nicht erwähnt wurde.
An sich ist es richtig, oder benutzt jeder Compiler die gleichen Optimierungen?
Wenn ja, wozu gibt es dann verschiedene Compiler (für z.B. Windows) und wieso ist der MSVC Compiler der beste unter Windows?

[Lefloyd]

Wenn Subjektivität ein technischer Fehler wäre, dann wären die Menschen in allem was sie sagen technische Fehler.. :P
Es ist aber Fakt, dass es nicht genauso "behindert" ist, einen eigenen Stil zu haben, wie an der Ausführung des Programmes etwas zu verhindern (aus Sicht eines Programmierers) - oder nicht? Das Ziel ist ja eigentlich nicht aus der eigenen Sicht Subjektiv (da es nicht von einem selbst gesetzt wird) sondern vom Auftraggeber gesetzt und daher ist es dort nicht mehr aus komplett der eigenen Sicht subjektiv bewertbar. Ich denke, das ist doch relativ offensichtlich oder? Aus diesem Grund ist in diesem Fall diese spezielle Subjektivität in der Tat ein technischer Fehler.

Aber du wolltest gerne beim "tatsächlichen Technischen" bleiben, was du schon mal nicht als subjektive Meinung festgelegt hast - also belassen wir es dabei.

Es stimmt was er sagte, dass nicht jeder Compiler die gleichen Optimierungsmethoden benutzt. Da diese grundlegende Optimierung (wie schon von Mi4uric3 gesagt) von (fast) allen Compilern unterstützt wird (mir ist keiner bekannt, der dies nicht unterstützt - allerdings kenne ich auch nicht alle Compiler), macht das in diesem Zusammenhang keinen Sinn. Und "kein Sinn" ist für mich ein technischer Fehler. Demnach ist diese Aussage durchaus ein technischer Fehler (betrachtet aus meiner minimalsten Subjektivität).

Auf deine letzten Fragen gehe ich mal nicht ein, da ich ja schon sagte, dass es unterschiedliche Optimierungsmethoden gibt.

Kind Regards,
Lefloyd

[​Arrow​]

In der richtigen Praxis würde es eh mit richtigen enum error codes zusammen hängen deswegen würde man es auch einzeln machen jedoch war (denke ich mal) das als subjektive Meinung gemeint.
Wie bereits mehrmals erwähnt wurde, hat jeder seinen eigenen Programmierstil.
Manche machen es lieber kurz - manche lieber ausführlich und übersichtlich.
Aber deswegen ist es noch lange kein technischer Fehler.

[Lefloyd]

Ich glaube, du hast mich da Missverstanden Arrow. Der technische Fehler bei Remix lag nicht an seinem Programmierstil, sondern an seiner Aussage, dass der Sourcecode von mir genauso bescheuert wäre, wie der von dem TE. Warum dies nicht der Fall ist, habe ich ja schon erläutert. Ich möchte keineswegs sagen, dass Remix Coding ein technischer Fehler ist. Das wäre tatsächlich unlogisch und daher ein technischer Fehler aus meiner sbujektiven Sicht. Allerdings befürchte ich, dass das ganze hier in einem Spam aus technischen Fehlern und Subjektivität enden könnte, weswegen ich nach dem nächsten Punkt lediglich noch 3 Wörter in diesem Thread verkünden werde.

Kind Regards,
Lefloyd

[DevBlade]

Originally Posted by DasSchwarzeT

Cool
Um das mit taos Release zu verknüpfen, einfach die Funktion von ihm ersetzen:
def DestroyItem(self, arg):

durch

	def DestroyItem(self, arg):
		net.SendChatPacket("/deleteitem %d" % (int(arg)))


		constInfo.SET_ITEM_DROP_QUESTION_DIALOG_STATUS(0)

Hey hab mit deiner Funktion leider das Problem das er immer nur den zweiten Slot im Inventar löscht und nicht den richtigen Slot. Könntest du mir dabei helfen?

Grüße

[DasSchwarzeT]

Originally Posted by fabiwunn

Hey hab mit deiner Funktion leider das Problem das er immer nur den zweiten Slot im Inventar löscht und nicht den richtigen Slot. Könntest du mir dabei helfen?

Grüße

Nimm das Release von Avenue per neuem Packet, ist wesentlich schöner.