Beiträge: 472
Halli erstmal...
Ich habe jetzt folgendes Problem: Wenn ich einen NPC in nen Zustand bringen will, vorher aber noch AI_Teleport(), und/oder Wld_InsertNpc() aufrufe wird der Zustand sofort wieder abgebrochen.
mein Code sieht jetzt etwa so aus:
[Aufrufende Funktion]
AI_PlayAni(self,"sonstwas");
Wld_InsertNpc(NPC,"WP");
AI_Teleport(self,"WP1");
AI_StartState(self,ZS_SonstWas,0,"");
[EOF]
Anmerk.: "WP", "WP1", "sonstwas" sind richtige Strings(NPC ist ein vorhandener NPC), hab sie aber mal anders benannt, weil sie unwichtig sind (oder?).
Mal nebenbei gesagt, der ZS-Code ist korrekt (hab ihn ohne AI_teleport und WLD_insertNpc() getestet). Meine Vermutung ist, daß die States(ZS_SonstWas und TeleportState) sich überschneiden und er deshalb den ZS nicht akzeptiert. Allerdings würde das sofortige abbrechen des letzten Zustandes (die 0 in AI_StartState(self,ZS_SonstWas,0,""); ) dann aber keinen Sinn machen.
Nun bin ich aber am Ende meiner Fantasie.
Kann mir irgendwer n Tipp geben dieses Problem zu umgehen?
Beiträge: 6.225
Ich habe auch mal probiert, einen AI_Teleport auf unkonventionelle Weise auszulösen, in einem Dialog. Jedoch konnte ich mich auf den Kopf stellen, der Dialog war nicht zum Laufen zu bringen.
Wo und wie rufst du denn die Funktion auf?
Beiträge: 472
Jetzt rate mal, per Dialog :)
Also der geht in den ZS rein,(AI_teleport und Wld_InsertNpc funktonieren auch) aber dann durchläuft er den _Loop scheinbar nur einmal und bricht dann ab. D.h.: ein Durchlauf und dann die _End-Funktion. Ich kann für die _loop-funktion auch einfach nur RETURN LOOP_CONTINUE zurückgeben er bricht trotzdem ab...
Ich brauche eigentlich nur den Loop, um die Zeitspanne des ZS(in der sich der NPC befindet) zu bekommen, aber ich glaub ich muß auf ne Loop-Funktion von anderen NPCs zurückgreifen und diese Abfragen dort mit reinbasteln. Ist dann zwar extrem unübersichtlich, aber bessa als nix...
Wegen Teleport in Dias: Du solltest, bevor du AI_Teleport im Dia aufrufst, ein AI_StopProcessInfos() reinhaun, damit der Dialog beendet wird. Sonst kann es sein, daß der Spieler noch im DIA-Loop ist und das Gespräch nicht beenden kann, weil durch den neuen State der DIA für den Spieler noch nicht beendet wurde. Dann hängt man inner endlosschleife fest(war jedenfalls bei mir so).
Ich hatte eigentlich keine Probleme damit, außer das oben :(
Beiträge: 6.225
Hm verzwickte Sache....
Aber einen Teleport konnte ich trotzdem nicht aufrufen, AI_StopProcessInfos(self) war selbstverständlich drin. Nur funktionierte der Dialog nicht so wie er sollte, die Funktion wurde gar nicht erst aufgerufen. Ich habe einige Zeit rumprobiert, aber es doch relativ schnell aufgegeben.
Aber kannst du nicht dafür
AI_PlayAni(self,"sonstwas");
Wld_InsertNpc(NPC,"WP");
AI_Teleport(self,"WP1");
einen eigenen ZS verwenden? Teleports in Dialogen scheinen nicht zu gehen....
Beiträge: 472
Das hab ich auch schon gemacht, aber ich hatte eine eigene Funktion geschrieben. das sah dann so aus:
[DIA ende]
AI_StopProcessInfos(self);
EigeneFunktion;
In der eigenen Funktion waren noch andere Sachen (keine AI_ Befehle), der Aufruf AI_StartState(siehe oben) und in der ZS_ waren die ganzen Anis und Teleports. Die hatte er dann gemacht, aber wie gesagt dann gleich abgebrochen.
Wenn ich stattdessen AI_StartState von dem DIA aus aufrufe macht er kein Teleport mehr, Anis spielt er ab.
mhh... Komisch komisch....
Würde mich mal brennenst interessieren, wie die ganzen AI_ und ZS- zusammenhängen ...
Beiträge: 6.225
Ich vermute eher, dass die Teleport-Funktion unter gewissen Vorraussetzungen ignoriert wird, um irgendwelche schwerwiegenderen Fehler zu vermeiden. Aber so intensiv habe ich mich nicht damit auseinandergesetzt, umd jetzt irgendwelche Zusammenhänge erklären zu können.
Beiträge: 472
Hab mal den Aufrufzeitpunkt bestimmt.
Ergebnis: Nachdem der letzte Satz im Dialog beendet wurde wird der Rest durchlaufen und die AI-Befehle auf ne Liste gesetzt. Allerdings ist der NPC bereits im ZS_Sonstwas, bevor die Ani ausgeführt wird(wegen Durchlauf direkt nach letztem Satz).
AI_Teleport in einem ZS stören sich gegenseitig, weshalb ich wohl nach dem AI_Teleport noch n Satz (von wem auch immer) reinhauen werde um dieses Prob zu umgehen...
@Malek: Wenn du willst schicke ich dir mal meinen (kleinen) Dialog mit AI_Teleport zu. Wie bereits erwähnt habe ich keine Probleme mit Dias und Teleport erkennen können...
Beiträge: 134
Genau so siehts aus!
Sämtliche OU's gehen in ne Liste und die Ausführung schreitet weiter, ohne zu warten, bis der Satz zuende ist. Selbst AI_Wait oder AI_WaitTillEnd wird ignoriert.
Vorschlag: Nen Important-Dialog schreiben, der erst kommt, wenn der erste Dialog zuende ist. Da wird man quasi nochmal angelabert, aber es funktioniert, denn man kann nun die restliche AI-Befehle ausführen lassen.
(Wer will, kann sich meine Fletcher-Quest ansehen. Da hab ich nen Trialog gemacht (Wechselgespräch mir der Brückenwache vorm AL).
Beiträge: 2.715
Passt hier nicht ganz rein aber ich kanns nachher wieder löschen.
@avatarr
Keine einziger Link von dir funzt bei mir. Der in deiner Sig nicht und dem im Sammelmodthread auch nicht. Ist das nur bei mir? Kannst du die sachen mal probieren wo anders hochzuladen
Beiträge: 472
@Avatarr: Hättest du mir das mit dem Durchlaufen nicht schon ehr sagen können ? :)
Jetzt hab ichs auch...
[EDIT]
ps: wirst mir jetzt nicht so folgen können, aber immer wenn ich was fertiggestellt (und damit auch die dazugehörenden Probs gelöst) habe, kommt einer an und sagt er hatte es schon fertig...
[/EDIT]
Beiträge: 134
@BMW-Hawk:
Die Links funktionieren eigentlich.
Der Sammelmod ist aber so unübersichtlich - da hab ich wahrscheinlich noch nicht alles gefixt *gg*
In jedem Fall geht http://homepages.compuserve.de/uhboot/
------dieser post kann ggF gelöscht werden-------
Beiträge: 472
Mal noch ne andere Frage: Ich hab bemerkt, daß die TAs von NPCs die nicht in Sichtweite(oder ein wenig darüber?) sind nicht mehr abgearbeitet werden. Kann man das irgendwie umgehen?
Beispiel: Wenn man sich nach dem Start gleich zur Brücke vor dem AL beamt (W
OW_PATH_1_1) werden erstmal die Wachen eingefügt. oder: gibt es irgendwie/-wo ne Prioritätseinstufung für das Abhandeln der TAs von NPCs außer Reichweite? Anscheinend funzt ja die Bewegung von einem Ort zum anderen, also wird dort ja der TA ausgeführt auch wenn er nicht in Sichtweite ist, oder?
Also wie auch immer kann da einer Helfen?
cu und noch n schönes feierliches Besäufnis *g
Beiträge: 134
Daß die Wachen erst eingefügt werden, wenn Du sie siehst ist klar. Sonst wäre das Spiel a****-langsam.
Das heißt aber nicht, daß die TAs nicht abgearbeitet werden, denn: das werden sie. Sie werden sogar vorausberechnet.
Beobachte mal den zSpy, wenn du rumläufst. Es werden ständig NPCs eingefügt und entfernt. Allein aus Performance-Gründen.
Also nochmal: TAs werden immer abgearbeitet. Gothic weiß wegen der Vorausberechnung zu jedem Zeitpunkt, wo welcher NPC ist. Wenn du dich irgendwohinbeamst, "siehst" du nur, wie NPCs eingefügt werden. Ansonsten würde das im Nebel geschehen.....
Beiträge: 472
@avatarr: Nein , sie werden leider nicht abgearbeitet. Die Sache mit den Wachen ist, daß sie nicht an ihrer TA-Pos eingefügt werden, sondern an der Spawn-Pos.
Das mit dem Einfügen/Löschen von NPCs ist 100% nur zu Gunsten der Graka gemacht worden. Die Sache mit den TAs ist aber nur begrenzt mit Performanceeinbußen verbunden, weshalb es mich auch gewundert hatte daß sie es rausgenommen haben. Außerdem hätte man eine Art Priorität für TAs setzen können (wenn... *g). Darum auch meine Frage dazu(s.o.)
Zum Positionswechsel: Wenn ein NPC in seiner ZS-LOOP stehen hat, er soll nach xyz gehn dann wird das intern berechnet, wo er zu welchem Zeitpunkt ist. Das bedeutet aber noch lange nicht, das sein TA ausgeführt wird.
Aber: Ein Irrtum meinerseits ist durchaus möglich, deshalb stand für mich die Frage:
quote:
gibt es irgendwie/-wo ne Prioritätseinstufung für das Abhandeln der TAs von NPCs außer Reichweite? Anscheinend funzt ja die Bewegung von einem Ort zum anderen, also wird dort ja der TA ausgeführt auch wenn er nicht in Sichtweite ist, oder?
Anderes Beispiel: Ich hab nem NPC die Aufgabe gegeben (im ZS_..._LOOP) das er den Spieler immer bepinseln soll( also Mdl_SetVisualBody()), das funzt aber nur solange, wie der Spieler in Sichtweite des NPC ist. Wenn man aus der Sichtweite ist, speichert und neu lädt sieht man so aus, wie in der entsprechenden hero-Instanz. Kommt man dann wieder in die Sichtweite des NPCs dann wird erst wieder gemalt.
[EDIT]
Wenn man in dem Sichtradius speichert und neu lädt bleibt der hero so wie er vor dem Speichern war.
Von FPS-Abstrichen habe ich dabei nix bemerkt, obwohl ja bei jedem Durchlauf der Body des Spielers neu gesetzt wird. Is eigentlich cool *g
Nur warum wird die Modellskalierung gespeichert und die Visuals nicht ARRRGGGHHH
[/EDIT]
Würde das so gehn, wie du es gesagt hast, wäre das Prob mit der Sektenglatze schon längst vom Tisch, weil man nur sowas wie nen Storyhelper einfügen bräuchte.
Wenn dazu also noch irgendwer was näheres sagen kann, bitte melden!
Is wichtig (4 me) !
Dank
ps: Ich arbeite wenig mit zSpy, sondern gebe lieber ne Mess auf dem Screen aus, oder ins Logbuch(?), weil: bessere Kontrolle über die Ausgaben. Sonst haste 100Mrd einträge die du dann säuberlich durchsuchen darfst :)
Beiträge: 134
Speichern und Laden: Ich denke auch, daß alle Problem damit damit zusammenhängen, daß nicht alles abgespeichert wird und man sich halt drauf verlassen muß, daß der Rest beim Laden richtig initialisiert wird......
TAs: hm..... jetzt bin ich überfragt
zSpy: Da gibs ne Text-Filter-Funktion ;), aber stimmt schon. Manche Debugsachen geb ich auch direkt auf'm Screen aus.
| Seite 1 von 1 | 1 |