Quote:
Originally Posted by ldevil
Ich denke das Problem vom "doppel Loggen" ist rel. schwer zu beheben, weil wenn du mehrmals den Boden Scannst, dann überlappen sich die "Suchkreise" und so kommt's, dass Items mehrfach aufgeführt werden. (Muss nicht der Grund sein, aber würd ich Mal annehmen.
Evtl. kannst du den geloggten Items noch die Koordinaten befügen (weiss nicht ob die verfügbar sind) und dann halt jeweils überprüfen, ob das Item schon geloggt wurde.
|
Schonmal was von der Eigenschaft
gid gehört, welche für so ziemlich jedes Objekt innerhalb eines Spieles definiert ist?
Eigentlich müsste dir das mittlerweile mal über den Weg gelaufen sein. :P
@topic
Es gibt eigentlich zwei Ansätze, wobei der eine deutlich einfacher, aber eingeschränkter nutzbar ist.
Obwohl das "eingeschränkt" mehr aus Programmierersicht zu sehen ist. Man kann damit falsche Ausgaben erzeugen, die Lösung ist nicht optimal.
In der Praxis aber unproblematisch, weil erst dann Fehler entstehen können, wenn dein Char NTSI_PickItems() in einer Ebene aufruft, in der er vorher schonmal Items geloggt hat. In der Praxis kommt das aber selten vor, darum sollte der Ansatz reichen. Ansonsten müsste man mit Filehandles arbeiten, etwas komplizierter und von der Laufzeit her schlechter.
Da ich etwas Zweifel habe, dass du weisst, wie die Änderungen umzusetzen sind, wenn ich sie nenne, würde ich dich bitten, mal deine komplette
NTSI_SnagIt() Funktion zu posten, dann füge ich dir schnell die nötigen Änderungen ein. ;)
Wirklich schwierig ist es nicht, man muss nur wissen, wie Item Objekte ticken.
Lg
Muddy
@Eichenlaub
Was mir gerade noch in deinem Code Beispiel auffällt:
Du rufst
GetArea() auf und gehst dann blind davon aus, dass das Objekt auch definiert ist.
Das ist gefährlich, denn wenn das nicht der Fall ist und das Objekt nicht definiert ist, führt Zugriff auf dessen Eigenschaften und Methoden zu einer Exception, die letztenendes zu einem Restart führt.
Darum immer Prüfen, ob die Objektinstanz auch existiert.
GetArea() ist übrigens ohnehin gefährlich, da die Funktion auch allergisch auf falsche Parameter reagiert. Bei mir habe ich die Funktion deshalb mittlerweile in eine common library Funktion verlegt, bei der zunächst die Richtigkeit der übergebenen Parameter sichergestellt wird.