15.10.2008, 02:32 | #1 (permalink) |
Extended Eventhandlers XEH -Wie geht das?
Hi, ich mache momentan für ne Mission ein paar Addons welche Init-scripts in deren config haben (so um zB. Setaperture zu setzen).Ausserdem haben noch weitere Addons Init-Scripts in deren Config.
Gehe ich recht in der Annahme das wenn dieses der Fall ist, es zu Problemen kommen kann und man dann dieses XEH braucht? Kann mir einer das mal an hand von ein paar kleinen Sätzen erklären, warum/wieso und: Kann mir einer helfen wie ich addons XEH-ready machen kann? Sprch meine init-script aufrufe aus der config.cpp/bin... Danke schonmal und gruss Christian |
|
15.10.2008, 19:39 | #3 (permalink) |
Registriert seit: 09.01.2008
Beiträge: 1.599
|
Hoi Christian,
mir ham'se leider in der Arbeit auf die Finger gehau'n wenn ich so weitersurfe Also xed-Einbindung siehst Du eigentlich in fast allen Addon's von mir. Geht genauso wie die normalen eventhandlers, nur die Übergabeparameter sind noch eine Ebene verschlüsselter: Config.cpp: Code:
class CfgPatches { class SmurfC_T72_NSV { ... requiredAddons[] = { "CATracked", "Extended_EventHandlers"}; }; }; ... class Extended_Init_EventHandlers { class smurfct72_nsv { smurfct72_nsv_init = "[_this] execVM ""\smurfct72_nsv_repl\init.sqf"";"; }; }; Im Skript: Code:
private ["_xehPars", "_unit", "_turret"]; //Definitions passed to script _xehPars = _this select 0; _unit = _xehPars select 0; _unit setObjectTexture [0,"\smurfct72_nsv\t72_nsv_co"]; _turret = "smurfct72_nsv_Barrel1" createVehicleLocal [0, 0 ,0]; sleep 0.05; _turret setDammage 1; sleep 5; deletevehicle _turret; Beim Init wird nur die Unit übergeben, bei den anderen Eventhandlers könnten das mehr sein. z.B: bei "IncommingMissile" Code:
//Definitions passed to script _xehPars = _this select 0; _unit = _xehPars select 0; _ammo = _xehPars select 1; _attacker = _xehPars select 2; ... |
15.10.2008, 21:17 | #5 (permalink) |
Aha, das heisst also das aus dem part meiner Config:
Das wird: Und ist das Egal ob es am Anfang oder Ende der Config steht? Danke dir nochmal! |
|
15.10.2008, 21:31 | #6 (permalink) |
Registriert seit: 09.01.2008
Beiträge: 1.599
|
Ich habe die Handler zumeist recht weit oben reingesetzt, aber hauptsächlich, weil es das letzte war, was ich integriert habe.
Mit deiner Art sollte es auch mit der normalen Handler-Syntax gehen, weil Du kein Array übergibst. Nur der getin ist ein eigener Eventhandler, also sollte es wohl so aussehen: Code:
class Extended_Init_EventHandlers { class mh6_police { mh6_police_init = " _this exec ""\mh6_police\data\scripts\ah64_flir_init.sqs""; "; }; }; class Extended_GetIn_EventHandlers { class mh6_police { mh6_police_getin =" _this exec ""\mh6_police\data\scripts\ah64_flir_init.sqs" "; "; }; }; |
15.10.2008, 21:41 | #7 (permalink) |
Ja danke!!!
Ja das ist vom Mapfact fake-fllir. Ich habe mir das mal ausgebrogt und etwas überarbeitet. Getout hatte ich da nicht gesehen. Das heisst, wenn ich bei allen meinen Addons der Mission die "normalen" Eventhandler durch die extended ersetze, das XEH Addon dann mitladen lasse (auf dem server+client) dann sollte man keine Probleme bekommen? Das XEH verwaltet ab da alles alleine? Na dann werde ich mich mal an das den Editorupdate 1.02 machen, der ca. 100erdte von Init-scripts hat. Hab da bereits diesen Schmodder entfernt, dass man alle Platzierten Objekte auf der Karte (Briefing/Ingame) sieht - war ja nicht mit an zu sehen. War(en) einfach eine/mehrere "falsche" Class Inheritances. |
|
15.10.2008, 22:18 | #8 (permalink) |
Registriert seit: 09.01.2008
Beiträge: 1.599
|
Sollte dann eingentlich alles klappen Zu 100% kann Dir das aber wohl nur BI und die xeh-Jungs sagen Ich mach's so wie Du es jetzt hast, und bis jetzt noch keine Beschwerden. Und Mapfact macht das FLIR aus, wenn man den Heli verlässt oder es Hell wird. Ich glaube die Prüfen zyklisch, ob man noch im Heli sitzt. Ist aber schon länger her, als ich das gechecked hatte... |
16.10.2008, 00:16 | #9 (permalink) |
Wow das ist ja Super danke nochmal!
Noch ne Frage: Wie sieht das denn bei sowas aus (Auszug Editorupdate): Code:
class AAMOW001 : M2StaticMG { displayName = $STR_AAMOW001; class EventHandlers { init = "_Path = ""EditorUpdate_v102\scripts\"";bplyTW=FALSE;Transporter = objnull;[(_this select 0),_Path,localize ""STR_AAMOW001"",""AAMOW001"",-1.01,60] exec format[""%1TransportWeapon\WeaponTransportPlayer.sqs"",_Path]"; }; }; sollte ich das dann ungefähr so machen (erst die normalen klassen mit vererbung und dann ganz unten die eventhandlers?): Code:
class AAMOW001 : M2StaticMG { displayName = $STR_AAMOW001; }; class Extended_Init_EventHandlers { class AAMOW001 { AAMOW001_init = " "_Path = ""EditorUpdate_v102\scripts\"";bplyTW=FALSE;Transporter = objnull;[(_this select 0),_Path,localize ""STR_AAMOW001"",""AAMOW001"",-1.01,60] exec format[""%1TransportWeapon\WeaponTransportPlayer.sqs"",_Path]"; }; }; Ausserdem weitere fragen dazu: Die Config bei dem Update ist über mehrere .hpp Files verstreut und eine "Haupt" Datei die alle anderen included. Es wäre natürlich jetzt fatal in jede der .hpp files eine "Class Extended_EventHandlers" zu machen, richtig? Also mache ich einfach eine "Extended_EventHandlers.hpp" und lasse diese ebenfalls includen? Warum splitted man den Configs auf mehrere Dateien auf? Kann man .hpp auch binarisieren? Geändert von Mr.g-c (16.10.2008 um 00:21 Uhr). |
|
16.10.2008, 10:02 | #10 (permalink) |
Registriert seit: 26.11.2006
Ort: Kiel, S-H
Alter: 57
Beiträge: 3.013
|
Jo, zudem wird auch geprüft ob man sich nicht in der 3rd Person Camera befindet und somit zu viel sehen kann.
__________________
Nur ein Beispiel das zeigt wie BI "support" definiert: https://feedback.bistudio.com/T75547 |
Stichworte |
eventhandler, extended, init, solus, xeh |
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1) | |
Themen-Optionen | |
Ansicht | |
|
|
Ähnliche Themen | ||||
Thema | Autor | Forum | Antworten | Letzter Beitrag |
es geht los !!! | hammergut | Community | 1 | 11.12.2006 18:31 |