-
Für das Verhalten von Dingen, die aus Gothic selber stammen, können wir leider nichts. In anderen Worten: Gothic macht da Murks, weil die PBs wohl nicht davon ausgingen, dass jemand die Textur ändern wollte. Da wirst du selber schauen müssen, dass das passt
-
Lehona
With 81 - 82 revision mod now much more stable and not crash with new game or change level
There are some problems in the bars. In the mod bar is used to display the aiming a bow that appears bar_show(xxx) only when hero get target , other times bar disappears bar_hide(xxx). But if during aiming, when the bar is displayed on the screen to save the game, and then load it, or move to another location, or start a new game, this bar remains on the screen even if the scripts condition it is hidden bar_hide(xxx). Remove this bar can be, if the script condition bar_hide(xxx), but it still remains on the screen, and then save the game, exit, start game again, load game, after that bar is hide
Can this be fixed?
-
As long as I can reproduce it, I can fix it I probably won't have time to look at it before Monday, but you'll get your fix!
-
Zitat von Lehona
Die neue LeGo-Version ist soweit fertig, dass die Öffentlichkeit sich an sie herantrauen kann - aber da ich damals noch nicht die Gewichtung von Branching oder Test Driven Development kannte, bin ich mit dem Testen soweit hinter her, dass ich jetzt erstmal gerne eine Alpha releasen würde.
Es wäre sehr nett, wenn ihr diese neue Version kurz installieren (ggf. ein Backup eures alten LeGo-Ordners machen - nur zur Sicherheit!) und dann testen könntet. Auch wenn ich natürlich auch die versteckten Bugs gerne finden würde, wäre mir am wichtigsten zu wissen, ob ich irgendwas Größeres kaputt gemacht habe. Ein kurzes "Alle meine LeGo-Anwendungen funktionieren noch." wäre also das, was ich gerne hören würde Ansonsten halt soweit es geht eine kleine Beschreibung des Fehlers, das erleichtert mir die Arbeit und spart viel Zeit (gerade, da ich mittlerweile alleine arbeite).
LeGo 2.3.0a
Also scheint diese LeGo-Version ganz gut zu funktionieren? Oder sind noch Änderungen / Ausbesserungen für die nähere Zukunft geplant?
(bzw. gibt es überhaupt Pläne für weitere Updates, oder werden nur noch Fehler ausgebessert, wenn sie bekannt werden?)
-
Die Version ist nach meinem Wissen stabil - ich habe keine Abstürze produzieren können, allerdings ist sie nicht annähernd so ausführlich getestet wie die Releaseversionen. Aber ich habe auch gar nicht die Zeit, um das alles zu testen (sieht man ja, wie viel Zeit ich gerade mal für LeGo aufwende).
Aber wenn selbst Ukur (Der hatte vorher reichlich Crashes) sagt, dass es stabil ist...
Was momentan noch fehlt ist die Dokumentation von neuen Sachen (Es gibt jetzt z.B. einen Itemrenderer), ob ich noch größere Sachen für LeGo tun möchte weiß ich nicht (wer gute Vorschläge hat: Raus damit!). Auf jedenfall wollte ich nochmal ein neues Inventar scripten, das wird dann aber nichts direkt mit LeGo zu tun haben (Aber natürlich LeGo nutzen).
-
Habe mal eine Frage. Folgende Situation:
Code:
var string s; s = "sonne";
var string s2; s2 = "baum";
var int list_ptr; list_ptr = List_Create(_@s(s));
List_Add (list_ptr, _@s(s2));
Print (MEM_ReadString (List_Get (list_ptr, 0)));
Print (MEM_ReadString (List_Get (list_ptr, 1)));
Es wird 2x "sonne" ausgegeben. Liegt es an mir oder ist da ein Fehler bei den Lists?
Noch eine Frage am Rande...
Liegt das 2. Element der Liste nicht an folgender Adresse:
Code:
List_Get (list_ptr, 0) + 4
??
Grüße
Rantragon
-
Das erste Element einer Liste (Der Listenkopf) hat die Nummer 1. Für die Nummer 0 wird ebenfalls der Listenkopf zurückgegeben, ob das nun ein Bug oder ein Feature ist, darüber lässt sich streiten. Das zweite Element würde also den String "baum" beinhalten.
Zu deiner zweiten Frage:
List_Get liefert dir bloß den Wert des Listenelements. Dieser Wert steht im Listenelement, aber List_Get gibt gar nicht die Adresse, sondern bloß den Wert zurück.
List_Node liefert einen Zeiger auf das Listenelement zurück. List_Get macht ungefähr MEM_ReadInt(List_Node(list, nr)) und wenn du den Zeiger auf das nächste Listenelement auslesen möchtest, wäre es MEM_ReadInt(List_Node(list, nr)+4). Die Listenelemente selber stehen aber nicht zwangsweise hintereinander im Speicher.
-
-
Sears!
Code:
AI_Function_I (hero, EquipWeapon , ItMi_Practice_1H);
Auf diese Funktion hin wird diese Ausnahmeregelung in EquipWeapon ausgeführt:
Code:
if (!Npc_GetInvItem(slf, ItemInst)) {
MEM_AssertFail("Unexpected behaviour in EquipWeapon.");
return;
};
Gesamte Equip-Funktion (von Sekti):
Code:
const int EquipWeapon_TogglesEquip = 1;
func void EquipWeapon (var C_NPC slf, var int ItemInst) {
if (!Npc_HasItems (slf, ItemInst)) {
CreateInvItems (slf, ItemInst, 1);
};
if (!Npc_GetInvItem(slf, ItemInst)) {
MEM_AssertFail("Unexpected behaviour in EquipWeapon.");
return;
};
if ((item.mainflag == ITEM_KAT_NF) && (Npc_HasReadiedMeleeWeapon(slf)))
|| ((item.mainflag == ITEM_KAT_FF) && (Npc_HasReadiedRangedWeapon(slf))) {
MEM_Warn ("EquipWeapon: Caller wants to equip a weapon while weapon of the same type is readied. Ignoring request.");
return;
};
if (item.flags & ITEM_ACTIVE)
&& (!EquipWeapon_TogglesEquip) {
/* calling EquipWeapon would unequip the weapon. */
MEM_Info ("EquipWeapon: This weapon is already equipped. Ignoring request.");
return;
};
CALL_PtrParam(MEM_InstToPtr(item));
CALL__thiscall(MEM_InstToPtr(slf), oCNpc__EquipWeapon);
};
Wie kann das sein, wenn die Waffe 100% im Inventar liegt? (ist angelegt)
-
Ich würde nicht auf Npc_GetInvItems() vertrauen, das hat bisher bei mir nicht richtig funktioniert (Habe aber auch nicht viel/lange getestet). Nach CreateInvItems() zeigt item auf das richtige Item. Ein böser Hack könnte also eher so aussehen:
Code:
const int EquipWeapon_TogglesEquip = 1;
func void EquipWeapon (var C_NPC slf, var int ItemInst) {
if (Npc_HasItems (slf, ItemInst)) {
Npc_RemoveInvItems(slf, ItemInst, 1);
};
CreateInvItems(slf, ItemInst, 1);
if ((item.mainflag == ITEM_KAT_NF) && (Npc_HasReadiedMeleeWeapon(slf)))
|| ((item.mainflag == ITEM_KAT_FF) && (Npc_HasReadiedRangedWeapon(slf))) {
MEM_Warn ("EquipWeapon: Caller wants to equip a weapon while weapon of the same type is readied. Ignoring request.");
return;
};
if (item.flags & ITEM_ACTIVE)
&& (!EquipWeapon_TogglesEquip) {
/* calling EquipWeapon would unequip the weapon. */
MEM_Info ("EquipWeapon: This weapon is already equipped. Ignoring request.");
return;
};
CALL_PtrParam(MEM_InstToPtr(item));
CALL__thiscall(MEM_InstToPtr(slf), oCNpc__EquipWeapon);
};
-
Hi Lehona, wurden eigendlich die Sachen, die du mir auf dem Moddertreffen gezeigt hast, in der neusten LeGo Version hinzugefügt?(Levitation zum Beispiel )
-
-
-
Zitat von ukur
Lehona
With 81 - 82 revision mod now much more stable and not crash with new game or change level
There are some problems in the bars. In the mod bar is used to display the aiming a bow that appears bar_show(xxx) only when hero get target , other times bar disappears bar_hide(xxx). But if during aiming, when the bar is displayed on the screen to save the game, and then load it, or move to another location, or start a new game, this bar remains on the screen even if the scripts condition it is hidden bar_hide(xxx). Remove this bar can be, if the script condition bar_hide(xxx), but it still remains on the screen, and then save the game, exit, start game again, load game, after that bar is hide
Can this be fixed?
There was a bug that would cause handles not to be deleted properly when a new game was started, it should be working now
-
-
Ich verstehe gerade eine Lego-Funktion nicht ganz.
Und zwar möchte ich mittels "AI_PrintS" den Print "Neuer Tagebucheintrag" in längeren Dialogen zur richtigen Zeit anzeigen lassen, und nicht ganz am Anfang.
Wenn ich das versuche, erscheint aber kein Text, sondern nur eine Meldung im zSpy:
Code:
[w] 00:27 Warn: 0 D: zModel.cpp(zCModel::StartAni): Ani not found: CALL S Raman\_will,\_dass\_ich\_mich\_ab\_jetzt\_regelmäßig\_bei\_ihm\_melde. 8214 .... <zModel.cpp,#2581>
Der Funktionsaufruf geschieht in der B_LogEntry, die direkt im Dialog aufgerufen wird. Testweise habe das so gemacht:
Code:
func void B_LogEntry (var string topic, var string entry)
{
Log_AddEntry (topic, entry);
PrintScreen (PRINT_NewLogEntry, -1, YPOS_LOGENTRY, FONT_ScreenSmall, 2);
AI_PrintS (PC_HERO, entry);
AI_PrintS (VLK_5_RAMAN, entry);
Snd_Play ("LogEntry");
};
VLK_5_RAMAN ist der Npc, mit dem der Testdialog stattfindet.
Aber keiner der beiden Prints scheint zu funktionieren (auch nicht wenn man wartet, bis der NPC nichts mehr macht) und für beide Prints gibt es obige zSpy Meldung.
Ist das überhaupt auf diese Weise möglich?
-
Das Spiel stürzt aber nicht ab, richtig?
Kannst du einmal ausprobieren, statt PC_Hero einfach hero zu verwenden?
-
Zitat von Milky-Way
Das Spiel stürzt aber nicht ab, richtig?
Kannst du einmal ausprobieren, statt PC_Hero einfach hero zu verwenden?
Das Spiel stürtzt nicht ab, korrekt.
Wenn ich nur "hero" verwende, passiert das gleiche. Egal von wo ich "AI_PrintS" aufrufe.
Da fällt mir gerade ein: Ich bekomme bei jedem Start Fehlermeldungen, dass irgendwelche Animationen nicht gefunden werden. Das ist aber schon sehr lange so und ich habe es immer so hingenommen. Könnte ein Zusammenhang bestehen?
Unvollständig:
Code:
[w] 00:09 Warn: 0 D: zModel(zCModelAni::ResolveReferences): Could not find nextAni: S_WALK, this:T_WALKL_2_WALK .... <zModelProto.cpp,#3352>
[w] 00:09 Warn: 0 D: zModel(zCModelAni::ResolveReferences): Could not find nextAni: S_WALK, this:T_WALKR_2_WALK .... <zModelProto.cpp,#3352>
[i] 00:09 Info: 2 N: MSB: Loading Model-Script (binary) 'HUMANS_1HST1.MDS' .... <zModelProto.cpp,#4849>
[w] 00:09 Warn: 0 D: zModel(zCModelAni::ResolveReferences): Could not find nextAni: S_1HSNEAKL, this:T_1HRUNL_2_1HSNEAKL .... <zModelProto.cpp,#3352>
[w] 00:09 Warn: 0 D: zModel(zCModelAni::ResolveReferences): Could not find nextAni: S_1HSNEAK, this:T_1HRUN_2_1HSNEAK .... <zModelProto.cpp,#3352>
[w] 00:09 Warn: 0 D: zModel(zCModelAni::ResolveReferences): Could not find nextAni: S_RUN, this:T_1H_2_RUN .... <zModelProto.cpp,#3352>
[i] 00:09 Info: 2 N: MSB: Loading Model-Script (binary) 'HUMANS_2HST1.MDS' .... <zModelProto.cpp,#4849>
[w] 00:09 Warn: 0 D: zModel(zCModelAni::ResolveReferences): Could not find nextAni: S_2HSNEAKL, this:T_2HRUNL_2_2HSNEAKL .... <zModelProto.cpp,#3352>
[w] 00:09 Warn: 0 D: zModel(zCModelAni::ResolveReferences): Could not find nextAni: S_2HSNEAK, this:T_2HRUN_2_2HSNEAK .... <zModelProto.cpp,#3352>
[w] 00:09 Warn: 0 D: zModel(zCModelAni::ResolveReferences): Could not find nextAni: S_RUN, this:T_2H_2_RUN .... <zModelProto.cpp,#3352>
[i] 00:09 Info: 2 N: MSB: Loading Model-Script (binary) 'HUMANS_BOWT1.MDS' .... <zModelProto.cpp,#4849>
[w] 00:09 Warn: 0 D: zModel(zCModelAni::ResolveReferences): Could not find nextAni: S_BOWRUN, this:T_BOW_2_BOWRUN .... <zModelProto.cpp,#3352>
[i] 00:09 Info: 2 N: MSB: Loading Model-Script (binary) 'HUMANS_CBOWT1.MDS' .... <zModelProto.cpp,#4849>
[w] 00:09 Warn: 0 D: zModel(zCModelAni::ResolveReferences): Could not find nextAni: S_CBOWRUN, this:T_CBOW_2_CBOWRUN .... <zModelProto.cpp,#3352>
Ingame kann ich keinerlei Fehler in den Animationen erkennen.
-
Können die Moderatoren dieses wichtige Thema mal entsprechend markieren, damit der Thread immer oben bleibt?
-
Zitat von blackpirate
Können die Moderatoren dieses wichtige Thema mal entsprechend markieren, damit der Thread immer oben bleibt?
Es ist auf Milkys Wunsch auch in meiner Signatur verlinkt, da findest du es also auch immer
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- Anhänge hochladen: Nein
- Beiträge bearbeiten: Nein
|