DisableUserInput Aktiveiren / Deaktivieren aus verschiedenen Datein

Moin,

ich will disableUserInput in Datei A auf true setzen, davor wird datei B aufgerufen.

in datei B will ich disableUserInput auf false setzen um somit wieder den input zu ermöglichen.

Jetzt ist das problem das der input einfach deaktiviert bleibt.

Hat jemand eine idee?

Zitat von CrypteX

Schonmal versucht in Datei B erst disableUserInput auf true und darunter direkt auf false zu setzen ?

Ansonsten am Ende von Datei A wieder auf false setzen.

Ja hat leider nicht funktioniert

Also kurz zum problem:

Man kann mit einem lagswitch realativ simpel das i Inventar dupen (zu zweit zb)

also soll das I inventar nur von einer person aufmachbar sein.

wenn das erreicht ist gibts noch das problem das man einfach ein lagswitch anmachen kann und dadurch 2 personen zugreifen können weil der eine nicht vom server übermittelt bekommt das da jdm dran ist.

also wäre die nächste idee ein Ping Pong system so wie es zb. Lucian (für das T inventar) umgesetzt hat zu benutzen.

Jetzt zu Problematik, das T inventar wird erstellt als ein Dialog, wenn der befehl zum erstellen nicht aus geführt wird, öffnet sich es einfach nicht.

Das I Inventar wiederum hat nur einen Inventhandler für das schließen des Inventars wenn die Person zb an ein fahrzeug will was nicht ihr gehört.

Was bedeutet das man das I Inventar von anfang an blocken und wieder aufrufen müsste, was mir bis dato noch zu kompliziert war / ist.

Meine Aktuelle idee / plan:

Eventhandler löst als erstes die datei auf die checked ob das fahrzeug überhaupt ihn gehört etc

Als nächstes verbietet es den user input

jetzt schickt es eine ping anfrage an den server

und wartet bis eine lokale variabel sich von false auf true setzt (waituntil - sollte damit doch so gehen oder?)

sobald sie true ist wird der input wieder erlaubt.

Hat da jemand eine bessere idee oder plan?

Zitat von Lucian

Ich würde kein WaitUntil nehmen, da das dann vom Code Verständnis schwerer zu lesen ist. Eine Aufruf Kette ist da einfacher.
D.h. onInventoryOpened (Checks + Sperren von Input) -> ping zu Server (mit methode die danach aufgerufen werden soll) -> pong von Server -> aufruf der mitgegebenen Methode.

Das problem wäre das in der gleichen datei wo der input gesperrt wird der input auch wieder freigegeben werden muss.

Wenn man in datei A den input sperrt und in datei B ihn nochmals sperrt und dann wieder freigibt klappt das (meine ich ) auch nicht.

wenn man die onInventoryOpened mit 2 methoden ausstattet die erste checked, sperrt den input und pingt dann, hätte man ja durch den zurückkommenden pong wieder ein neuaufruf der datei und somit wieder die geschichte das es so gesehen nicht die "ursprüngliche datei / befehlskette" ist

Basicly das gleiche wie man mit dem T Inventar dupen kann geht auch beim i Inventar

Wenn man vor der Open Datei ein Ping Pong ausgeführt ist die Geschichte nicht schnell genug zu verhindern das man zb an einem nicht gehörenden Fahrzeuge rangeht

Würdest du das inv schließen über Close Dialog machen?

Zitat von Lucian

Du kannst im EVH das blocken wenn du glaube ich false zurück gibst?

wait what?

player addEventHandler ["InventoryOpened", { 

false;
}];

das hat noch nicht gefunzt...

waitUntil { !isNull findDisplay 602 }; 
closeDialog 602;

das genauso wenig

steh grade komplett auf dem schlauch

Zitat von blackfisch

das funktioniert. Könnte aber schwierig werden wenns davon mehrere gibt.

in der fn_setupEVH.sqf ist folgender evenhandler einmal angelegt:

player addEventHandler ["InventoryOpened", {

false;
}];

ich kann ingame problemlos mein sowie fahrzeug inventare öffnen und benutzen...

Ich bekomm das inventar ums verrecken nicht geschlossen, das treibt mich seit 2 tagen in den wahnsinn xD

Zitat von blackfisch

1. Doch das geht

2. Wieso nochmal sperren?

Du musst nur sicherstellen, dass B definitiv nach A ausgeführt wird, also so

richtig

Code: A

...
disableUserInput true;

call B;
...

Code: B

...
disableUserInput false;
...

statt

falsch

Code: A

...
call B;

disableUserInput true;
...

Code: B

...
disableUserinput false;
...

-> du musst ja schließlich sicher stellen, dass B nach A ausgeführt wird sonst wirds nie deaktiviert. Statt direkt B aufzurufen machst du jetzt da dein Ping-Pong

Wobei Lucian natürlich recht hat. Sowas mit disableUserInput zu regeln ist blöd, vor Allem wenn da doch mal was schief geht bei der Nummer und zack -> UserInput is weg und was wars. Und so schwer ist es nicht das Inventar wieder auf zu machen

Alles anzeigen

Ich werde das nochmal probieren, ist vorhin leider untergegangen