PureBoard

Dickes Danke fürs Testen

Habe nun die Fehlerquellen einkreisen können.

Es ist jetzt nicht böse gemeint, aber ich brauche keine weiteren Screens

mal sehen was sich in der Nacht entwickelt ...

Will nur mal sagen : Hammer !

Ziemlich flott das ganze !
Also wenn da jetzt noch 3 Achsen berücksichtigt werden ... könnt man damit grad was in 3D machen

Weiter so!

Cheers,
Thalius

sauber.

Des is echt genial.

wäre es möglich, dass er evtl ab z.b. 100 knoten rechnen aufhört, und erst, wenn "der spieler da ist" das eigendliche Ziel wieder weiterberechnet wird? zur leistungseinsparung (kann zwar dann sein, dass er unmögliche Ziele ausgibt, aber bevor die Figur einfach stehnbleibt, wie in spellforce, wäre eine Aufteilung der Strecke doch evtl besser praktischer (k.a.)

viel erfolg

-Max

@Thalius

Das ganze im "echten" 3D zu machen ist mit meiner Methode nicht möglich, da ich an den Mauern im 3D (welche Flächen darstellen) keine festen "weg optimierenden" Knoten anlegen kann, da ich ja nicht einfach die Ecken nehmen kann sondern es auch an jedem belibigen Punkt an der Kante sein könnte.
Wenn dann müsste man dort wieder in 2D (Karte) umwandeln.

@Max_der_Held
Klar wäre das möglich, nur dieses "schon mal loslaufen" führ in 90% der fälle zu einem riesen Umweg.

Im 3D wird auch alles einfach nur in skalare Felder unterteilt. Meistens sind Octrees sowieso schon vorhanden.

Wenn 2 Achsen liesse sich trotzdem was machen.

Wenn du die Möglichkeit lässt Maps mit "Mappunkten" zu verbinden - ob diese nun übereinander oder nebeneinander dargestellt werden ist ja im prinzip egal. Sprich die Wegsuche zum Ziel eine Art Zeiger oder "Portal" zu einer anderen Map anlegen kann und dort wiederum von start -> end durchworked.

Somit wärs möglich auch so eine wegsuche auf eine region zu begreenzen ( speedfactor bei grösseren maps ) - dadurch könnte man eine verteilung auf mehrere 2D Ebenen vornehmen - womit sich in 3D mit wegsuche und vorausgesetzt "Interconnected Nodes" schon sowas wie Dune 2000 / 3D umsetzen liesse

Oder die Wegsuche auf verschiedene labyrinthe die man runtime-nachlädt erweitern.

Cheers, Thalius

irgendwie macht das alles kein spaß mehr

da denkt man, man halt die Bugs entfernt, und alles mögliche unternommen, und testen dann auch erfolgreich Mauernstellungen aus, die vorher nicht funzen, und in der neuen version dann gehen. UND trotzdem kommt irgendwann wieder n dumme Mauer die aus der reihe fällt ...

Trotzdem hier noch mal n Update

PathFind - Demo
(Link aktuallisiert 9.7.2010)

Hinweiß:

Mir ist klar das diese Wegfindung mit allen dingen klar kommen muss.
Aber es ist nicht der Sinn das Programm mit NanoMauern zu nerven oder Mauernhaufen.

Die Sache das der Thread abschmiert, verstehe ich nicht. denn normalerweise starte ich immer n neuen Thread pro Wegsuche und kille den Alten und lösche den Speicher ...

Ich werde Am Wochenende oder so den Code freigeben, dann könnte ihr ja mal reinschauen.

Das Problem liegt wahrscheinlich am 'killen' selbst. Du solltest NIE einen
Thread mit KillThread beenden. Am besten Du baust Dir ein Signalhandling auf, damit sich der Thread selbst beendet. Nur in diesem Fall wird alles sauber beendet und der Speicher freigegeben..

Ausserdem dürfte es zum testen helfen, den Thread nicht als Thread auszuführen, sondern direkt.
Auch wenn dann erst mal das ganze Eventhandling einfriert, du bekommst einfach die besseren Debugmöglichkeiten.

Zumindest mache ich das immer so, wenn ich Probleme mit einem unregelmässig abschmierenden Thread habe, oder er einfach nicht das tut, was ich von ihm erwarte.

Ansonsten:
Fettes Teil, was du da bastelst, lass bloss den Kopf nicht hängen

Wirklich schönes Beispiel. Bei mir kommt es zwar auch in unregelmäßigen Abständen zu Abstürzen des gesamten Spiels, aber im wenn das Spiel arbeitet, arbeit es korrekt. Macht Spaß, sich mit der Sache zu beschäftigen. Bleib dran!