|
-
Das habe ich früher schonmal gemacht (da gab es das Buffs-Paket noch lange nicht), das sollte ziemlich gut möglich sein. Ich habe das ebenfalls in den Issue Tracker aufgenommen.
Geändert von Lehona (17.01.2019 um 07:22 Uhr)
-
Zitat von Lehona
Mir ist noch etwas bei den Buffs aufgefallen. Sämtliche Buff-Texturen aktiver Buffs des Helden werden auch weiterhin angezeigt, wenn das Spiel pausiert ist oder wenn der Spieler sich in einem Dialog befindet. Da beim pausieren des Spiels und in Dialogen das HUD ausgeblendet wird, sollten mMn. auch die Buffs dann nicht mehr sichtbar sein.
-
Guter Gedanke! Ich habe das ebenfalls aufgenommen.
-
Zitat von mud-freak
I've been in contact with pawbuj about this issue and have fixed the above mentioned "Negatives" of Fawkes solution (fixing of the animation) and updated the code. I took the liberty to reorganize the functions a bit.
This should completely fix the problem. It should also be the most robust way to do it. I had originally added state and state_target to the archive by hooking the oCMobInter-zCArchiver. While being slightly more elegant it had some issues of its own.
Code:
/*
* This function is called whenever an NPC interacts with an oCMobInter object and stores its state in
* ocMob.visualDestroyed
*/
func void FixMobSwitches_OnTick() {
var oCMobInter mob; mob = _^(ECX);
mob._oCMob_visualDestroyed = IntToString(mob.state);
};
/*
* These functions are called on loading and iterates over all oCMobInter objects to restores their state as
* previously stored in oCMob.visualDestroyed
*/
func void FixMobSwitches_Restore_Sub(var int vobArrayPtr) {
var zCArray vobList; vobList = _^(vobArrayPtr);
repeat(i, vobList.numInArray); var int i;
var int vobPtr; vobPtr = MEM_ArrayRead(vobArrayPtr, i);
var oCMobInter mob; mob = _^ (vobPtr);
if (mob.state == 0) {
if (Hlp_StrCmp(mob._oCMob_visualDestroyed, "1")) {
mob.state = 1;
mob.state_target = 1;
// Call modified reset function to update animations
const int oCMobInter__Reset = 6803776; //0x67D140
const int call = 0;
if (CALL_Begin(call)) {
CALL__thiscall(_@(vobPtr), oCMobInter__Reset);
call = CALL_End();
};
};
};
end;
};
func void FixMobSwitches_Restore() {
var int vobArrayPtr; vobArrayPtr = MEM_ArrayCreate();
if (SearchVobsByClass("oCMobInter", vobArrayPtr)) {
FixMobSwitches_Restore_Sub(vobArrayPtr);
};
MEM_ArrayClear(vobArrayPtr);
if (SearchVobsByClass("oCMobSwitch", vobArrayPtr)) {
FixMobSwitches_Restore_Sub(vobArrayPtr);
};
MEM_ArrayFree(vobArrayPtr);
};
/*
* Overwrite the default animation state after unarchiving of oCMobInter objects
*/
func void FixMobSwitches_Reset() {
var oCMobInter mob; mob = _^(MEM_ReadInt(ESP+20)); //esp+3Ch-28h
var zString ani; ani = _^(ECX); // "S_S0"
const int ASCII_0 = 48;
MEM_WriteByte(ani.ptr+3, mob.state+ASCII_0); // Modify last character
};
/*
* Initialization: Call this function from Init_Global
*/
func void FixMobSwitches_Init() {
const int oCMobInter__Reset_setAniState = 6803955; //0x67D1F3
const int oCMobInter__Reset_resetState = 6804058; //0x67D25A
const int oCMobInter__OnTick = 6804096; //0x67D280
// Remove resetting of mob state
const int nop12Btyes[3] = { -1869574000, -1869574000, -1869574000 }; // 0x90 * 12
MemoryProtectionOverride(oCMobInter__Reset_resetState, 12);
MEM_Copy(_@(nop12Btyes), oCMobInter__Reset_resetState, 3);
// Overwrite resetting of animation
HookEngineF(oCMobInter__Reset_setAniState, 7, FixMobSwitches_Reset);
// Record mob state in oCMob.visualDestroyed
HookEngineF(oCMobInter__OnTick, 9, FixMobSwitches_OnTick);
// Restore mob state
FixMobSwitches_Restore();
};
@mud-freak I found a bug. while this package is active, NPCs can not use properly all mob interacts like bench, water pipe, etd. However all mob switches are OK.
-
Zitat von pawbuj
@mud-freak I found a bug. while this package is active, NPCs can not use properly all mob interacts like bench, water pipe, etd. However all mob switches are OK.
I'm sorry, that my scripts cause these bugs. Unfortunately, I'm very busy at the moment. I don't think I'll have time to look at it soon. You could start debugging by checking if the problem also arises with the original code from Fawkes. Also you could try to determine which part of the code is causing the issue (writing to the "visualDestroyed" property, resetting the "state" or "state_target", or the changes in "oCMobInter::Reset"). You can just remove different parts of the code and check. Maybe someone will help you to find the bug.
-
Zitat von mud-freak
I'm sorry, that my scripts cause these bugs. Unfortunately, I'm very busy at the moment. I don't think I'll have time to look at it soon. You could start debugging by checking if the problem also arises with the original code from Fawkes. Also you could try to determine which part of the code is causing the issue (writing to the "visualDestroyed" property, resetting the "state" or "state_target", or the changes in "oCMobInter::Reset"). You can just remove different parts of the code and check. Maybe someone will help you to find the bug.
I am sorry for bodering you. I have already fix without changing ur code,
What I did is just to modify one routine code, which works perfectly fine from now.
Geändert von pawbuj (05.02.2019 um 13:40 Uhr)
-
Zitat von pawbuj
I am sorry for bodering you.
No problem, asking doesn't hurt
Zitat von pawbuj
I have already fix without changing ur code,
What I did is just to modify one routine code, which works perfectly fine from now.
Good to hear. If I remember, I'll come back to the code to try to fix the bug, once I have a bit more time and finished some other stuff (e.g. Ninja).
-
Zitat von F a w k e s
Hey pawbuj,
I had same problem! It took me a while till I fixed it - I have noticed in zSpy log following message:
NPC: Output-Unit: ... not started. Another NSC is having conversation with targetNPC: PC_HERO
[Bild: gm_fix_dialog.png]
From that I assumed that hero got somehow into another conversation with another NPC's. As soon as I have updated these 2 functions below - problem was fixed (red is old code, green adjusted):
Code:
FUNC VOID B_Say (var C_NPC slf, var C_NPC oth, var string text)
{B_SmartTurnToNpc (slf, oth); //AI_OutputSVM (slf, oth, text);
if (NPC_IsInState (slf, ZS_Talk))
|| (NPC_IsInState (oth, ZS_Talk))
{ AI_OutputSVM (slf, oth, text); } else { AI_OutputSVM (slf, NULL, text); }; };
FUNC VOID B_SayOverlay (var C_NPC slf, var C_NPC oth, var string text)
{B_SmartTurnToNpc (slf, oth); //AI_OutputSVM_Overlay (slf, oth, text); if (NPC_IsInState (slf, ZS_Talk))
|| (NPC_IsInState (oth, ZS_Talk))
{ AI_OutputSVM_Overlay (slf, oth, text); } else { AI_OutputSVM_Overlay (slf, NULL, text); }; };
That "bugfix" causes the Npc to say FRIENDLYGUILDGREETINGS out of dialogue. Its nicer if you write
Code:
FUNC VOID B_Say (var C_NPC slf, var C_NPC oth, var string text)
{
B_SmartTurnToNpc (slf, oth);
if oth.aivar[AIV_INVINCIBLE]==TRUE
&& slf.aivar[AIV_INVINCIBLE]==TRUE
{
AI_OutputSVM (slf, oth, text);
} else {
AI_OutputSVM (slf, NULL, text);
};
};
This causes the Npc to always say Guildgreetings in Dialogue and say everything else ambiently.
(Also sometimes the hero does not start the ZS_Talk state, its not safe to use this to fix that problem in G1)
"Das erinnert doch sehr erfreulich an das, was man sich als Gothicfan wünscht!"
-Korallenkette
Geändert von Bisasam (10.02.2019 um 09:31 Uhr)
-
Ich möchte eine neue Waffenart in Gothic 2 einbauen, anscheinend muss ich dazu die MAX_HITCHANCE um Eins erhöhen.
Jemand eine Idee wie?
Code:
const int MAX_CHAPTER = 5;
const int MAX_MISSIONS = 5;
const int MAX_HITCHANCE = 5;
class C_Npc
{
var int id;
var string name[5];
var string slot;
var string effect;
var int npcType;
var int flags;
var int attribute[ATR_INDEX_MAX];
var int HitChance[MAX_HITCHANCE];
var int protection[PROT_INDEX_MAX];
var int damage[DAM_INDEX_MAX];
var int damagetype;
var int guild;
var int level;
var func mission[5];
var int fight_tactic;
var int weapon;
var int voice;
var int voicePitch;
var int bodymass;
var func daily_routine;
var func start_aistate;
var string spawnPoint;
var int spawnDelay;
var int senses;
var int senses_range;
var int aivar[100];
var string wp;
var int exp;
var int exp_next;
var int lp;
var int bodyStateInterruptableOverride;
var int noFocus;
};
-
a) Das ist keine Frage und b) geht das nicht, die Klassen, die die Engine kennt, kann/darf man nicht verändern. Die Engine verlässt sich auf deren Layout.
-
Hallo,
ich bräuchte Hilfe bei einer (denke ich) eigentlich sehr einfachen Funktion.
Code:
func void oCNpcDoDie_Init()
{
HookEngineF (7563104, 7, Hook_oCNpcDoDie); // Hook at "oCNpcDoDie" (0x00736760)
};
func void Hook_oCNpcDoDie(var C_NPC slf)
{
Print ("NPC gestorben!");
if (Hlp_GetInstanceID(slf) == hero) && (PlayerDead < 6)
{
Print ("Der Held ist gestorben!");
PlayerDead = PlayerDead +1;
if (PlayerDead == 5)
{
Print ("Insgesamt 5x gestorben!");
};
};
};
Ich möchte, dass, sobald die Adresse 0x00736760 aufgerufen wird, abfragen, ob es sich bei dem gerade gestorbenen NPC um den Helden handelt. Die Funktion selbst funktioniert wunderbar und wird auch aufgerufen, sobald der Held stirbt. Allerdings will die Abfrage nicht funktionieren, ob es sich bei dem NPC um den Helden handelt, denn es wird immer nur der erste Print angezeigt (also "NPC gestorben!"). Vermutlich muss ich den NPC irgendwie anders abfragen... Nur wie?
-
Zitat von Bloodfly91
Hallo,
ich bräuchte Hilfe bei einer (denke ich) eigentlich sehr einfachen Funktion.
Code:
func void oCNpcDoDie_Init()
{
HookEngineF (7563104, 7, Hook_oCNpcDoDie); // Hook at "oCNpcDoDie" (0x00736760)
};
func void Hook_oCNpcDoDie(var C_NPC slf)
{
Print ("NPC gestorben!");
if (Hlp_GetInstanceID(slf) == hero) && (PlayerDead < 6)
{
Print ("Der Held ist gestorben!");
PlayerDead = PlayerDead +1;
if (PlayerDead == 5)
{
Print ("Insgesamt 5x gestorben!");
};
};
};
[...]
Du bist "im" Helden, wenn er stirbt, oder? Du machst also nicht sowas wie z.B. in einen anderen NPC zu wechseln und dann den PC_Hero zu killen?
Falls der Spieler immer PC_Hero sein wird, kannst du wie in den Dialog_Mobsi-Skripten
Code:
var C_NPC her; her = Hlp_GetNpc(PC_Hero);
if (Hlp_GetInstanceID(slf) == Hlp_GetInstanceID(her))
verwenden.
Ansonsten: Ist slf denn richtig befüllt? Welche Werte spuckt Print(IntToString(Hlp_GetInstanceID(slf))); aus?
“Da ist auch noch ein anderer Geruch in der Luft, der Geruch von Feuern, die in der Ferne brennen, mit einem Hauch Zimt darin - so riecht das Abenteuer!”
― aus Walter Moers' "Die 13 1/2 Leben des Käpt'n Blaubär"
-
Code:
func void oCNpcDoDie_Init()
{
const int oCNpc__DoDie = 7563104; //0x736760
HookEngineF (oCNpc__DoDie, 7, Hook_oCNpcDoDie);
};
func void Hook_oCNpcDoDie(var C_NPC slf)
{
var C_Npc slf; slf = _^(ECX);
Print ("NPC gestorben!");
if (Npc_IsPlayer(slf)) && (PlayerDead < 6)
{
Print ("Der Held ist gestorben!");
PlayerDead = PlayerDead +1;
if (PlayerDead == 5)
{
Print ("Insgesamt 5x gestorben!");
};
};
};
An eine hookende Funktion werden keine Argumente übergeben. slf musst du dir erst "holen". In diesem Fall ist ein Zeiger auf den NPC im Register ECX, weil du am Anfang einer thiscall-Funktion hookst. Dort entspricht this dem Register ECX und this ist hier der NPC für den die Enginefunktion aufgerufen wird.
Falls du den Mörder auch noch haben willst kannst du den so ermitteln:
Code:
var int othPtr; othPtr = MEM_ReadInt(ESP+4); // Erstes Argument der Enginefunktion
var C_Npc oth;
if (Hlp_Is_oCNpc(othPtr)) {
oth = _^(othPtr);
} else {
oth = MEM_NullToInst(); // Es mag keinen Mörder geben (z.B. Tod durch Fallschaden, Ertrinken, ...)
};
// ...
if (Hlp_IsValidNpc(oth)) {
// ...
};
PS: An der Stelle noch Gratulation zum Release von Velen! Hattest du dort die Buffs eingebaut? Wenn ja solltest du beachten, dass bei etwaigen Updates/neuen Versionen der Mod, in der sich die Skripte ändern, ein neues Spiel angefangen werden muss, denn die Buffs speichern die Symbolindices der entsprechenden NPCs, die sich durch Änderungen verschieben. Dieses Problem ist mittlerweile schon behoben, ist allerdings noch in der aktuellen Releaseversion von LeGo enthalten.
EDIT: Wenn ich mich nicht irre, kann es vorkommen, dass oCNpc::DoDie zwei mal aufgerufen wird. Darauf solltest du zur Sicherheit noch Rücksicht nehmen.
Geändert von mud-freak (17.02.2019 um 09:52 Uhr)
-
Zitat von mud-freak
Code:
func void oCNpcDoDie_Init()
{
const int oCNpc__DoDie = 7563104; //0x736760
HookEngineF (oCNpc__DoDie, 7, Hook_oCNpcDoDie);
};
func void Hook_oCNpcDoDie(var C_NPC slf)
{
var C_Npc slf; slf = _^(ECX);
Print ("NPC gestorben!");
if (Npc_IsPlayer(slf)) && (PlayerDead < 6)
{
Print ("Der Held ist gestorben!");
PlayerDead = PlayerDead +1;
if (PlayerDead == 5)
{
Print ("Insgesamt 5x gestorben!");
};
};
};
An eine hookende Funktion werden keine Argumente übergeben. slf musst du dir erst "holen". In diesem Fall ist ein Zeiger auf den NPC im Register ECX, weil du am Anfang einer thiscall-Funktion hookst. Dort entspricht this dem Register ECX und this ist hier der NPC für den die Enginefunktion aufgerufen wird.
Falls du den Mörder auch noch haben willst kannst du den so ermitteln:
Code:
var int othPtr; othPtr = MEM_ReadInt(ESP+4); // Erstes Argument der Enginefunktion
var C_Npc oth;
if (Hlp_Is_oCNpc(othPtr)) {
oth = _^(othPtr);
} else {
oth = MEM_NullToInst(); // Es mag keinen Mörder geben (z.B. Tod durch Fallschaden, Ertrinken, ...)
};
// ...
if (Hlp_IsValidNpc(oth)) {
// ...
};
PS: An der Stelle noch Gratulation zum Release von Velen! Hattest du dort die Buffs eingebaut? Wenn ja solltest du beachten, dass bei etwaigen Updates/neuen Versionen der Mod, in der sich die Skripte ändern, ein neues Spiel angefangen werden muss, denn die Buffs speichern die Symbolindices der entsprechenden NPCs, die sich durch Änderungen verschieben. Dieses Problem ist mittlerweile schon behoben, ist allerdings noch in der aktuellen Releaseversion von LeGo enthalten.
EDIT: Wenn ich mich nicht irre, kann es vorkommen, dass oCNpc: oDie zwei mal aufgerufen wird. Darauf solltest du zur Sicherheit noch Rücksicht nehmen.
Vielen Dank, so hat es wunderbar funktioniert!
Ja, Buffs verwenden wir. Oh... Was genau bedeutet das denn für den Spieler? Was für Probleme würde bzw. könnte es dadurch denn geben, wenn man einfach einen Spielstand lädt, der mit einer älteren Version der Mod erstellt wurde?
-
Zitat von Bloodfly91
Was für Probleme würde bzw. könnte es dadurch denn geben, wenn man einfach einen Spielstand lädt, der mit einer älteren Version der Mod erstellt wurde?
Es kann beim Spielladen mit geänderten Skripten zu Abstürzen kommen. Ich bin mir gerade nicht sicher, aber das sollte nur dann passieren, wenn zum Zeitpunkt des Speicherns gerade ein Buff aktiv war.
Bei einer nächsten Version der Mod könntest du deine Buffs.d im LeGo-Verzeichnis mit dieser hier ersetzen. Da wurde das Problem behoben (zwar schon getestet, aber ich kann nichts versprechen). Allerdings wird das Problem dadurch erst aus dem Weg geräumt nachdem diese Änderung eingebaut wurde. D.h. bis dahin kann eine neue Version der Mod (die Skriptänderungen enthält) beim Spielladen zu Abstürzen führen.
Sollte tatsächlich ein Absturz auftreten wäre dann eine Notlösung, die SCRPTSAVE.SAV des entsprechenden Spielstand-Ordners mit einem Texteditor zu öffnen und alle Einträge mit lCBuff zu löschen. Wie gesagt sollte ein Absturz aber nur dann auftreten, wenn beim Speichern ein Buff aktiv war.
Vielleicht hat Lehona noch eine andere Idee dazu?
-
Ich würde nur hinzufügen wollen, dass es natürlich egal ist, auf welchem (N)PC der Buff aktiv ist, d.h. es geht hier nicht unbedingt um den Spieler. Wie mud-freak allerdings schon sagte wäre ein Crash der daraus resultiert relativ leicht zu beheben, indem man die SCRPTSAVE.SAV bearbeitet. Das ist einfach genug, um es wahlweise den Spieler per Hand oder per RegEx machen zu lassen.
Eine scriptseitige Migration (man müsste dann in Daedalus die lCBuff-Handles aus der SCRPTSAVE.SAV löschen, bevor sie von PermMem geladen werden) wäre auch möglich, aber ein wenig umständlich ohne eine RegEx-Implementierung (allerdings keinesfalls unmöglich). Wenn ihr beim Testen feststellt, dass der beschriebene Crash auftritt, wäre das eine Möglichkeit.
-
Zitat von mud-freak
Es kann beim Spielladen mit geänderten Skripten zu Abstürzen kommen. Ich bin mir gerade nicht sicher, aber das sollte nur dann passieren, wenn zum Zeitpunkt des Speicherns gerade ein Buff aktiv war.
Bei einer nächsten Version der Mod könntest du deine Buffs.d im LeGo-Verzeichnis mit dieser hier ersetzen. Da wurde das Problem behoben (zwar schon getestet, aber ich kann nichts versprechen). Allerdings wird das Problem dadurch erst aus dem Weg geräumt nachdem diese Änderung eingebaut wurde. D.h. bis dahin kann eine neue Version der Mod (die Skriptänderungen enthält) beim Spielladen zu Abstürzen führen.
Sollte tatsächlich ein Absturz auftreten wäre dann eine Notlösung, die SCRPTSAVE.SAV des entsprechenden Spielstand-Ordners mit einem Texteditor zu öffnen und alle Einträge mit lCBuff zu löschen. Wie gesagt sollte ein Absturz aber nur dann auftreten, wenn beim Speichern ein Buff aktiv war.
Vielleicht hat Lehona noch eine andere Idee dazu?
Zitat von Lehona
Ich würde nur hinzufügen wollen, dass es natürlich egal ist, auf welchem (N)PC der Buff aktiv ist, d.h. es geht hier nicht unbedingt um den Spieler. Wie mud-freak allerdings schon sagte wäre ein Crash der daraus resultiert relativ leicht zu beheben, indem man die SCRPTSAVE.SAV bearbeitet. Das ist einfach genug, um es wahlweise den Spieler per Hand oder per RegEx machen zu lassen.
Eine scriptseitige Migration (man müsste dann in Daedalus die lCBuff-Handles aus der SCRPTSAVE.SAV löschen, bevor sie von PermMem geladen werden) wäre auch möglich, aber ein wenig umständlich ohne eine RegEx-Implementierung (allerdings keinesfalls unmöglich). Wenn ihr beim Testen feststellt, dass der beschriebene Crash auftritt, wäre das eine Möglichkeit.
Vielen Dank, dann sollte das ja gar kein so großes Problem sein, wenn es sich ohnehin relativ leicht beheben lässt. Die Buffs.d werde ich vor dem nächsten Update dann ersetzen.
Nun bräuchte ich aber leider NOCH mal Hilfe bei einer Funktion:
Code:
var int DIV_Geheimlabor_Questregal_Bugfix_Applied;
func void DIV_Geheimlabor_Questregal_Bugfix()
{
if (DIV_Geheimlabor_Questregal_Bugfix_Applied == FALSE)
{
var int Geheimlabormoverptr; Geheimlabormoverptr = MEM_SearchVobByName("RUINE_GEHEIMLABOR");
var zCMover GeheimlaborRegal; GeheimlaborRegal = _^(Geheimlabormoverptr);
GeheimlaborRegal.bitfield[0] = GeheimlaborRegal.bitfield[0] &~ zCVob_bitfield0_collDetectionStatic;
GeheimlaborRegal.bitfield[0] = GeheimlaborRegal.bitfield[0] | zCVob_bitfield0_collDetectionDynamic;
GeheimlaborRegal.bitfield[0] = GeheimlaborRegal.bitfield[0] &~ zCVob_bitfield0_staticVob;
DIV_Geheimlabor_Questregal_Bugfix_Applied = TRUE;
Print ("Geheimlabor-Regal Bugfix angewendet!");
};
};
Hiermit soll bei dem zCMover, der den Vobnamen "RUINE_GEHEIMLABOR" trägt, eigentlich einfach nur cdStatic und staticVob deaktiviert und cdDyn aktiviert werden. Leider funktioniert das aber nicht so wirklich, das Skript wird zwar aufgerufen, da der Print angezeigt wird, allerdings ändert sich am Mover selbst nichts.
Aufgerufen wird die Funktion in der INIT_GLOBAL der Startup.
-
Zitat von Bloodfly91
Vielen Dank, dann sollte das ja gar kein so großes Problem sein, wenn es sich ohnehin relativ leicht beheben lässt. Die Buffs.d werde ich vor dem nächsten Update dann ersetzen.
Nun bräuchte ich aber leider NOCH mal Hilfe bei einer Funktion:
Code:
var int DIV_Geheimlabor_Questregal_Bugfix_Applied;
func void DIV_Geheimlabor_Questregal_Bugfix()
{
if (DIV_Geheimlabor_Questregal_Bugfix_Applied == FALSE)
{
var int Geheimlabormoverptr; Geheimlabormoverptr = MEM_SearchVobByName("RUINE_GEHEIMLABOR");
var zCMover GeheimlaborRegal; GeheimlaborRegal = _^(Geheimlabormoverptr);
GeheimlaborRegal.bitfield[0] = GeheimlaborRegal.bitfield[0] &~ zCVob_bitfield0_collDetectionStatic;
GeheimlaborRegal.bitfield[0] = GeheimlaborRegal.bitfield[0] | zCVob_bitfield0_collDetectionDynamic;
GeheimlaborRegal.bitfield[0] = GeheimlaborRegal.bitfield[0] &~ zCVob_bitfield0_staticVob;
DIV_Geheimlabor_Questregal_Bugfix_Applied = TRUE;
Print ("Geheimlabor-Regal Bugfix angewendet!");
};
};
Hiermit soll bei dem zCMover, der den Vobnamen "RUINE_GEHEIMLABOR" trägt, eigentlich einfach nur cdStatic und staticVob deaktiviert und cdDyn aktiviert werden. Leider funktioniert das aber nicht so wirklich, das Skript wird zwar aufgerufen, da der Print angezeigt wird, allerdings ändert sich am Mover selbst nichts.
Aufgerufen wird die Funktion in der INIT_GLOBAL der Startup.
Ich denke das du hier das falsche bitfield behandelst. Wenn du das Teil als zCMover behandelst, kannst du mit GeheimlaborRegal._zCVob_bitfield[0] auf das zCVob bitfield zugreifen.
Alternativ könntest du das Objekt als zCVob behandeln:
Code:
var zCVob GeheimlaborRegal; GeheimlaborRegal = _^(Geheimlabormoverptr);
dann wäre GeheimlaborRegal.bitfield[0] richtig.
-
Zitat von Cryp18Struct
Ich denke das du hier das falsche bitfield behandelst. Wenn du das Teil als zCMover behandelst, kannst du mit GeheimlaborRegal._zCVob_bitfield[0] auf das zCVob bitfield zugreifen.
Alternativ könntest du das Objekt als zCVob behandeln:
Code:
var zCVob GeheimlaborRegal; GeheimlaborRegal = _^(Geheimlabormoverptr);
dann wäre GeheimlaborRegal.bitfield[0] richtig.
Perfekt, funktioniert als zCVob ohne Probleme. Vielen Dank!
-
Zitat von pawbuj
@mud-freak I found a bug. while this package is active, NPCs can not use properly all mob interacts like bench, water pipe, etd. However all mob switches are OK.
I finally got around to taking a closer look at this issue. The problem was the changes in oCMobInter::Reset. I believe I have fixed the problem now. I updated the script in the original post here.
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- Anhänge hochladen: Nein
- Beiträge bearbeiten: Nein
|
|