|
-
Ich könnte mir vorstellen, dass es daran liegt, dass die Talent-Funktionen die AI-Variable nur gegen Null vergleichen aber nicht mit Hlp_IsValidHandle prüfen. Wenn es dann irgendwie passiert, dass in der AI-Variable etwas anderes gespeichert wurde oder das Handle ungültig gemacht wurde, kommt es da wahrscheinlich zu dem aufgeführten Problem.
Lehona, erinnerst du dich, ob es irgendeinen Grund gab, dort nicht Hlp_IsValidHandle zu verwenden oder ist das einfach einer der alten Codeteile, bei denen es einfach noch nicht gemacht wurde?
-
Ich denke das ist einfach Teil des alten Codes, der noch nicht entsprechend angepasst wurde. Unabhängig davon sollte es aber ein Fehler in LoA sein, wenn in der AIVar Werte ungleich 0 stehen, die kein gültiges Handle sind.
@Milky-Way: Ist sichergestellt, dass die AIVar-Konstante in der UserConstants nicht für anderweitige AIVars verwendet wird?
-
EventHandler.d loop break ?
@Lehona, @Mud-freak,
Let's say I have an event where I call Event_Execute with 2 listener functions listener1, listener2, is it possible to break the loop which iterates over listeners from listener1 function? I would like to evaluate some conditions in listener1 function and in some cases I no longer want to call listener2 function.
(I know I can declare some global variable which will indicate that listener2 wont do anything - I was just wondering if there is any trickery that can break the loop without additional variables )
-
No, that's not supposed to work. Events have to be independent, as different features (or code from different patches) might subscribe to the same event* and they should not influence each other to prevent bugs. You'll have to resort to global variables.
*There are some problems with events and script-patches via ninja, which might mean they won't ever subscribe to the same event, but events should be independent nonetheless.
-
Another thing to keep in mind is that the order of the listeners is not guaranteed. When removing a listener, the order may change. Listeners are removed from the event (just a zCArray) with MEM_ArrayRemoveValueOnce which moves the last entry of the array to the index of the removed entry.
So, communication between listeners of the same event does not seem to be a good idea in general (and also not intended as Lehona points out).
-
Lego\Locals.d
in my opinion, there is a bugs. Variable enumerations like in C don't seem to exist in daedalus
Code:
var string locals_retstr; var zCPar_Symbol retinst;
var int arr, var int type;
var int sPtr;
-
How can you say that when the parser accepts the code you have showed?
It's not very useful and very rare, but valid Daedalus. I think in the original scripts it's used as well, so any custom parser will have to deal with it anyway.
-
Zitat von Lehona
I think in the original scripts it's used as well, so any custom parser will have to deal with it anyway.
There are no variable enumerations in the original scripts.
But whether the scripting language of the game supports this or not, we are unlikely to know. The game's compiler skips this. The GS compiler (Redefix) is not.
-
Well Daedalus is defined by its original parser implementation, so I'd say it's supported That said there's really no use, so feel free to create a PR on GitHub to remove it
-
LeGo 2.8.0
- Komfortabler Strings und Floats über Speichern und Laden hinweg zu speichern: PM_BindString und PM_BindFloat, analog auch PM_BindInt
- Die mögliche Anzahl von Handles ist nun verdoppelt auf 4294967295
- In AI-Functions ist self korrekt gesetzt und bereitgestellt (Dank an Fawkes)
- Es gibt nun mehr AI-Function Variationen zum Übergeben von Instanzen
- Externe Enginefunktionen können nun gehookt werden
- Enginehooks berücksichtigen und setzen jetzt Argumente und Rückgabewerte der Daedalusfunktionen
- Erweiterte ASCII Zeichen werden nun auch escaped/unescaped
- Bars können jetzt wieder manuell versteckt und sichtbar gemacht werden (Dank an Milky-Way)
- Alphawerte von Bars werden jetzt korrekt für beide Views übernommen (Dank an Fawkes)
- Negative Rüstungswerte nach Trialogen behoben (Dank an Draxes)
- Verbesserte Kompatibilität von Enginehooks
- Views sind nun korrekt sichtbar wenn sie jedes Frame geöffnet werden
- Gültigkeit von Talent-handles wird nun überprüft (Dank an Milky-Way)
- Daedalushooks sind nun sicherer wenn in Sprünge (z.B. If-Blöcke) verschoben werden
- Speicherleck in PermMem behoben
- Datenstack wird zwischen FrameFunction-Aufrufen zurückgesetzt, um Stacküberläufe zu vermeiden
- Warnung in PM_Reset entfernt (Dank an Kirides)
- Überflüssige Abfragen in Anim8 entfernt (Dank an Kirides)
- Talente werden nicht länger erstellt wenn ein Buff nur abgefragt wird (Dank an Atariar)
- Buffliste wird nicht länger angelegt, wenn nicht erwünscht (Buffs_DisplayForHero == False)
-
Der Senlax war's
ein Modder-Krüppel schlecht hin
-
Zitat von Senlax
Vielen Dank an alle Leute, die das ermöglicht haben
Kann ich die neue LeGo-Version ohne Sorgen über meine alte LeGo-Version drüber ziehen
oder sollte ich irgendetwas bedenken / beachten?
Wenn du nichts in den LeGo scripten angepasst hast, solltest du es einfach rüber ziehen können.
-
Zitat von Senlax
Kann ich die neue LeGo-Version ohne Sorgen über meine alte LeGo-Version drüber ziehen
oder sollte ich irgendetwas bedenken / beachten?
Danke, dass du nachfragst. Das habe ich nicht erwähnt:
Falls man, oder Skripte, die man verwendet, irgendwo die Engine hookt, sollte man einmal die Funktionssignaturen überprüfen.
D.h. wenn in den Skripten (abseits von LeGo selbst), irgendwo eine der Funktionen HookEngineI, HookEngineF, HookEngine oder HookEngineS verwendet wird, sollte man sicherstellen, dass alle Daedalusfunktionen (jeweils drittes Argument) keine Rückgabewerte haben. Also so eine Funktionssignatur: func void foo(). Das sollte aber eigentlich immer so sein, es könnte höchstens aus Versehen dort bspw. int stehen.
Ab dieser LeGo Version wird der Rückgabewert einer hookenden Funktion nämlich in EAX geschrieben. Auch Funktionsparameter werden wenn möglich sinnvoll befüllt. Mehr Details dazu in der Verlinkung im Changelog und hier.
Geändert von mud-freak (26.04.2021 um 08:36 Uhr)
-
GameState suggestion
Hello Lehona, szapp,
Would it be possible for you to add one more state to Gamestate.d - where Event_Execute would be called right before game saving event ? I think it would be great addition.
I've done some testing and when I hooked oCGame::PreSaveGameProcessing I didn't get any prints in game - so assuming this function is not called by engine.
Atm I am using oCNpc::PreSaveGameProcessing where I call Event_Execute on player (so it's called once), seems to be working fine so far:
Code:
func void _hook_oCNpc_PreSaveGameProcessing () {
if (!Hlp_Is_oCNpc (ECX)) { return; };
var oCNpc slf; slf = _^ (ECX);
if (NPC_IsPlayer (slf)) {
if (_LeGo_Flags & LeGo_Gamestate) {
Event_Execute (_Gamestate_Event, Gamestate_PreSaveGameProcessing);
};
};
};
Let me know your thoughts
-
Vielen Dank fürs neue Lego! Da lohnt es sich doch glatt Gothic wieder zu reaktivieren.
-
Hallöchen, bin gerade darüber gestolpert, das LeGo Buffs für immer im Savegame sind und ewig ausgeführt werden, wenn deren Handle ungültig wird.
Ich wollte mal nachfragen ob das so korrket ist, oder ob der zugehörige _Buff_Dispatcher entfernt gehört.
Das Problem an dem ganzen ist beim Testen einer Mod aufgefallen, je öfter die Handles ungültig werden (Skripte aktualisiert werden) desto schlechter wurden die fps bis diese in den Keller gewandert sind.
EDIT: Das Problem tritt auch auf, wenn man den Buff während seiner Laufzeit entfernt über Buff_Remove.
Geändert von Kirides (03.07.2021 um 20:20 Uhr)
-
Ich denke es ist recht klar, dass das nicht so sein sollte
Ich schau mir das bei Gelegenheit mal an, aber die Klausurenphase geht bald los...
-
Apprentice
PermMem
Hello,
I am strugling a bit with PermMem. I am trying to save a subclass, but it always crashes.
The code:
viewPtr is a view pointer created by ViewPtr_Create.
What am I doing wrong?
Auronen
-
That's hard to say without an error mesage (it's been a while since I last looked into the PM code, and it's a huge fucking mess), but I can't think of anything that would stop you from saving a view in this way.
Is there any reason you aren't using a handle, i.e. using View_Create?
-
Apprentice
When I was trying to do the same with a handle it was crashing aswell, (not sure, if I am supposed to save the handle as int?).
Previously I had implemented it using handles, but that was crashing too, I thought maybe PermMem reinits handles to be different values, and that was the problem.
I am going to try again (with handles), and report, if it crashes still.
Thank you for your response
Auronen
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- Anhänge hochladen: Nein
- Beiträge bearbeiten: Nein
|
|