Healing Bug

[Gast]

durch das rumtesten mit dem skript kontne ich den fehler eingrenzen, er tritt imemr dann auf, wenn das skript grade was in die hand nimt, oder benutzt und man gleichzeitig items bewegen will, zB aus dem loot, oder evtl per autoloot skript.

ich sehe solange sijection keine möglichkeit bietet die subroutinen zu snychronisieren auch keinen workaroudn dafür.

[Blood.Hawk]

Ich frag' mich ja immer noch warum man jeden Mist scripten muss... und ansonsten kann man ein Script ja auch von Hand starten (oder liege ich da völlig daneben?)

[Gast]

nun es ging um bugs in scripten, oder ? scripte sind hier erlaubt, also liegt die entscheidung bei jedem einzelnen, korrigier mich wenn ich da falsch leige. wenn dich der thread nicht interessiert lies ihn einfach nicht.

wenn man sich dafür entscheidet zu scripten, dann muss man halt damit rechnen dass unvorhergesehene wechselwirkungen auftreten, so ist das halt beim programmieren.

[Falwis]

ich sehe solange sijection keine möglichkeit bietet die subroutinen zu snychronisieren auch keinen workaroudn dafür.

Hmm, kann man das nich eventuell mit Variablen machen?

[Gast]

es gibt keine globalen variablen in sijection...und die exec function frisst für subs keine parameter. zumal es wenn man von hand lootet und das script kickt ein, müsste man den Thread der ParserInstanz irgendwie mit dem Client abgleichen und das ist ein Problem, da die synchro mit dem Client in injection.dll passiert.
Ein möglicher, wenn auch sehr uneleganter weg sowas wie threads direkt im skript zu emulieren wäre halt dass man in einer endlos while schleife IF abfragen in deren blöcken dann die einzelnen skripte wie das autoheal oder das autoloop dann direkt laufen lässt und nicht als sub. das hat einen haufen nachteile, erstens raubt es massig performance da der scheduler den man sich so für die skripte selbstgebaut hat, ständig laufen muss im hintergrund und zwar mit sehr wenigen waits, damit mit minimaler latenzzeit zwsichen den skripten umgeschaltet wird. Und zwar unabhängig davon ob das skript nun was macht oder nicht. Dies führt zu sehr eienr sehr starken belastung des clients, weil sijection dadurch dem client unverhältnissmässig viel prozessorzeit wegnimmt.
Eine weitere umständliche Möglichkeit der Synchronisierung wäre, dass sich die skripte über das journal ein "lock token" weitergeben und jedes skript eine gewisse zeit bzw einen gewissen zugesicherten zyklus laufen würde, bis es zum nächsten umschaltet. auch dies ist ineffizient weil so häufig skripte drankommen die eigentlich gar nix machen. will ich das verhidnern müsste ich einen komplexeren scheduler algorithmus benutzen, der wieder mehr clientzeit fressen würde..usw

also wenn du dich berufen fühlst, dann nur zu

[Falwis]

War nur so ne Frage, hatte mit SiJection sehr schnell abgeschlossen nachdem ich mit dem Target-Handling da nich so klar kam und Sijection zu heftigen Lags bei UO geführt hatte .... - War da wohl auch etwas ineffizient. Aber das schaffe ich inzwischne auch mit EUO ....

[Gast]

*G* deswegen sollte man auch grade mit sijection viele waits benutzen, insbesondre in leeren loops...sijection ist halt recht eng mit dem client verzahnt, während easy uo als eigenständiger prozess von aussen eingreift, jedes der beiden verfahren hat halt seine vor und nachteile.

[Bytehawk]

EasyUO hat den großen Vorteil, dass es nichts macht was der user nicht auch machen könnte. Es sendet nichts anderes als Tastendrucke, Mausklicks/-bewegungen und interne UO-Makros an den server. Auf OSI ist nämlich nichts an anständigen Makroprogrammen erlaubt, und man wird sofort gebannt wenn sie einen damit erwischen. Theoretisch könnten sie einem sogar ein Verfahren anhängen.
Programmen wie Injection, die im Datenstrom rumpfuschen traue ich jetzt als Betreiber noch weniger über den Weg denn damals als Spieler. Das ist der Grund warum es SiJection gibt, damit nicht jeder sich den Injection source schnappt, und ihn sich zurechtschreibt um unseren server abzuschießen oder zu sabotieren. Wir würden auch viel lieber ohne arbeiten. Aber Yoko hat diesen Fluch nun mal in die Welt gesetzt.

Hm, Thema verfehlt, wie? Na egal, ich mach jetzt eh Feierabend *räkel* Seid artig, macht nix kaputt, ja?

[Gast]

wiiiiiiiiiir ? würden wir nie tun *olapaloma pfeif*

[Gast]

okay, zumindest nicht mit vorsatz

[Gast]

Ich habe 2 Lösungsansätze für das Problem der locked down Items gefunden beim einatz mehrer Skripte.
Der Erste, von dem ich nicht weiss ob er funktioniert, wäre der Befehl ",set safeequip 1". Wenn das geht haette es den Vorteil, dass man auch manuell Dinge sicher anheben kann während ein skript grade werkelt.

Möglichkeit Nummer 2:
Einzelne Skripte kann man in den kritischen Sektionen aufeinander timen, in dem man die Sijection Objectlist als globale Variablenliste missbraucht.

Hier ein Beispiel:

Code: Alles auswählen

sub script1()
   IF (uo.getserial('scrip2_nobreak')<>'0xFFFFFFF1')    THEN
       uo.addobject('script1_nobreak', '0xFFFFFFF1')
       uo.disarm()
       wait(500)
       uo.arm('waffe')
    ENDIF
    wait(500)
    uo.addobject('script1_nobreak','0xFFFFFFF0')
end sub


sub script1()
   IF (uo.getserial('scrip1_nobreak')<>'0xFFFFFFF1')    THEN
       uo.addobject('script2_nobreak', '0xFFFFFFF1')
       #hier kommt zB der aufruf der autoloot routine hin
    ENDIF
    wait(500)
    uo.addobject('script2_nobreak','0xFFFFFFF0')
end sub

Natürlich müssen vor dem ersten Aufruf script1_nobreak und script2_nobreak gesetzt werden, am besten in einer init() Funktion die man vor dem Starten der anderen Funktionen aufruft:

Code: Alles auswählen

sub init()
   uo.addobject('script1_nobreak','0xFFFFFFF0')
   uo.addobject('script2_nobreak','0xFFFFFFF0') 
   uo.setarm('waffe')
end sub

hoffe ihr koennt was damit anfangen.

[Genesis]

von was redest du ?

[Gast]

von eienr lösung für das thema des threads...

[Bytehawk]

Mehr oder weniger erledigt, würde ich sagen.
Interessierten können's ja auch noch in de Ablage lesen, in "Bugs" gehört es jedenfalls nicht mehr.