Beiträge von NetFusion

    Endlich haben wir den TechCheck-Server online:


    IP: 138.201.248.21
    Port: 2302


    Bitte testet bis Samstag selbständig, ob ihr euch einwandfrei verbinden könnt.
    In der Mission sind Kisten mit Medic-Material und Funkgeräten platziert, sodass ihr bei Bedarf euch ACE und TFAR Einstellungen überprüfen könnt.


    Solltet ihr Fragen oder Probleme haben, kommt bitte auf unser Teamspeak.

    Der Testserver ist online!


    Ihr könnt ihn unter 213.239.202.133:2302 erreichen.
    Das Passwort lautet: AWEvent


    Bitte beachtet, dass wir am Samstag mit der 32-bit Version spielen.
    Stellt bis dahin sicher, dass ihr euch einwandfrei mit dem Server verbinden könnt und alle Mods (ACE, TFAR) funktionieren.


    Bei Fragen oder Problemen sind wir auf dem AW TS3 oder via PM zu erreichen.

    Ich persönlich glaube, dass BI da ihren eigenen Termin etwas verschlafen hat. Es gab ja zwischenzeitlich (mittlerweile gelöscht) sogar eine Petition um die Monetarisierung weiterhin zu erlauben, da von seiten BI kein vernünftiges Statement kam als das eine Jahr abgelaufen war.
    Nun haben sie mit der Verlängerung ein weiteres Jahr Zeit um Daten und Feedback zu sammeln. Ich hoffe sie verpassen es nicht nochmal eine frühzeitige Entscheidung zu fällen wie sie weiter verfahren möchten.


    Was das Thema Monetarisierung aktuell betrifft, finde ich persönlich gut, dass sich Gedanken gemacht wird, wie man den Leuten eine Möglichkeit gibt ihren eigenen Aufwand zu refinanzieren. Jedoch ist das aktuelle System zu primitiv und deckt bei weiten nicht alle Bereiche der Community ab in denen Kosten entstehen.


    Viele Modder empfinden das als unfair, denn sie selbst dürfen für die Mod nichts verlangen

    Hier würde mich mal intressieren ob/wo der Unterschied zwischen einem Mod und einem Skript gemacht wird. Denn es gibt ja durchaus Arma 3 Skripte für Echtgeld zu erwerben (und das ist auch allgemein bekannt, Stichwort: Cheat-Protection). Dort fehlt es dann an Informationen seitens BI meiner Meinung nach.


    Also ich denke das Monetarisierungssystem wird nicht in der aktuellen Form langfristig bestehen bleiben sondern muss angepasst werden. Die Frage ist ob sich BI die Mühe macht oder ob sie den einfachen Weg gehen: Abschaffen.

    Wow ich hätte nicht gedacht das mein Post doch soviel Diskussionsstoff bietet...


    Auch wenn hier viel sinnvolles steht will ich nochmal auf meinen vorletzten letzten Absatz hinweisen, denn dazu wurde noch nichts geschrieben:


    Letztendlich würde ich dir empfehlen, wenn es möglich ist, die Ziele nur aus- bzw. einzublenden (hideObjectGlobal), denn Erstellen und Löschen von Objekten (besonders im Sichtfeld des Spielers) führt gerne mal zu "Framelags".
    Dann sparst du dir eingangs das Löschen aller 200+ Objekte und musst nicht die Positionen und Ausrichtungen der Ziele zwischenspeichern.

    Ich freue mich das du das Skripten entdeckst :)
    Ich hoffe du nimmst mir das nicht böse, du kennst mich ja schon und weißt, dass ich dir und den Leuten die das hier lesen nur helfen will.

    Code
    1. KHtargetsall = (getMarkerPos "KHmark") nearObjects ["TargetBootcampHumanSimple_F", 100];
    2. KHtargetsallPos = KHtargetsall apply {[getPosATL _x, getDir _x]};
    3. {
    4. deletevehicle _x;
    5. nil
    6. } count KHtargetsall;


    Hier ein paar Verbessrungen für deinen Code:
    nearObjects statt nearestObjects: das Ergebnis ist nicht sortiert und daher ist der Befehl etwas schneller
    count statt forEach: forEach nur benutzen wenn du auch den _forEachIndex brauchst, denn dieser wird bei forEach immer mitgezählt und macht daher forEach langsamer als count (wenn du mit count nichts zählen möchtest immer nil im code-block zurückgeben)
    apply statt pushBack: wenn du für jedes Element eines Arrays einen neuen Wert berechnen und in ein neues Array legen möchtest ist apply genau dafür gemacht



    private vor den Variablen: die variablen existieren dann nur im aktuellen Scope (innerhalb der geschweiften Klammern oder der Datei falls keine Klammern da sein) und verhindert dadurch Überschneidungen mit anderen Skripten
    params statt select: wenn du einzelne Werte eines Arrays in getrennte Variablen schreiben willst ist das genau der richtige Befehl
    createVehicle array statt createVehicle mit setPos: mit der akternativen syntax kannst du hier CAN_COLLIDE angeben und dadurch die exakte Position gleich mit (ein extra setPos entfällt dann)



    Die Idee mit BIS_fnc_arrayShuffle ist zwar nicht schlecht, erfordert aber ein Durchlaufen des gesamten Arrays.
    Mit einem zufällig sortierten Arrays lässt sich jedoch die array select [start, count] Syntax nutzen, die dann mehrfaches Selektieren aus dem Array (in der for-Schleife) überflüssig macht.


    @stoffl:
    Letztendlich würde ich dir empfehlen, wenn es möglich ist, die Ziele nur aus- bzw. einzublenden (hideObjectGlobal), denn Erstellen und Löschen von Objekten (besonders im Sichtfeld des Spielers) führt gerne mal zu "Framelags".
    Dann sparst du dir eingangs das Löschen aller 200+ Objekte und musst nicht die Positionen und Ausrichtungen der Ziele zwischenspeichern.


    Abschließend noch etwas das nicht zu Fehlern fürt aber mir persönlich wichtig ist:
    Nutzt bitte 4 Leerzeichen anstatt Tabs zum Einrücken und achtet auf Groß- und Kleinschreibung bei den SQF-Befehlen

    Ich schaue auch seit mehreren Jahren traditionell jeden ersten Sonntag im Februar zu.


    Dieses Jahr halte ich wie sonst auch immer zu den Patriots! Aber es soll natürlich spannend werden und unterhaltsam...
    Ich kann ürigens auch die original Übertrgung auf Englisch empfehlen, allein schon wegen der Werbung genial :)

    Interesse besteht definitiv.


    Problempunkte wurden ja hier schon genannt:
    Anreise bzw. Veranstaltungsort
    Kosten
    Zeitpunkt


    Das ganze an eine größeres Event wie die GamesCom anzukoppeln (davor, danach, währenddessen) halte ich für sinnvoll, dann dann macht es mehr Sinn für Teilnehmer anzureisen.
    Auch kann man dann eher jemanden von BI begeistern auf dem Event vorbeizuschauen.


    Was die Erwartungen angeht:
    Ich stelle mir eigentlich vor, dass einige Leute kurze Vorträge halten über Themen die uns beschäftigen. Da wäre Technisches, Taktisches und Organisatorisches im Groben zu nennen. Dazu dann eine Q&A Runde mit einem der Devs als "Highlight".
    In den Pausen ein bisschen "Networking" an der Bar. Je nach Teilnehmerzahl kann dann auch noch gegen Abend ein Grill angeschmissen werden.
    Weiterhin könnte man eine (oder mehrere) Stationen aufbauen, an denen kurze Missionen gespielt werden können. Zum Beispiele ein Helikoptermission im Racingseat reizt mich als Flugbegeisterter auf jeden Fall. Auch müsste man mal schauen ob man nicht eine Station mit VR aufgebaut bekommt damit sich jeder das mal mit Arma anschauen kann (soll ja mit entsprechender Hardware funktionieren). Die benötigte HW dazu müsste man sich natürlich für das Event von einem Hersteller stellen lassen (was auch für eine Nähe zu einem größeren Event spricht).
    Vielleicht könnte man auch noch kleine Schießstände aufbauen, falls das gesetzlich machbar ist (Airsoft, Paintball oder sowas) an denen die Zielfertigkeiten in der Realität geprüft und verglichen werden können.


    Für das Ganze würde ich natürlich als Teilnehmer einen Beitrag zahlen, denn die Kosten sind sicherlich nicht gering.

    Versuch doch mal in der Funktion (die ausgeführt wird wenn der Button gedrückt wird) abzufragen ob das Display schon existiert. Den Code dazu hast du ja auch schon geschrieben.
    Dann sparst du dir das schließen und neu erstellen des Display denn die Controls, die du ändern willst sind ja schon existent.


    Ich erinnere mich, dass ich schon mal ein ähnliches Problem hatte:
    https://github.com/TaktiCool/A…nUI/fn_clientInit.sqf#L86


    Wenn dein Code im "unscheduled environment" läuft (also kein execVM oder spawn) dann kannst du mit einem PerFrame-EventHandler genau bestimmen in welchem Frame dieser ausgeführt wird. Wir bei Arma At War aktualisieren unsere Displays immer ein Frame nachdem wir es erstellen um (unter anderem) solche Fehler zu vermeiden.
    Das sollte auch bei dir das Problem lösen wenn du den Vorschlag aus dem ersten Absatz nicht Umsetzen kannst.

    Ich würde dir empfehlen möglichst wenig der orginalen Exile Dateien und Tabellen zu verändern. Bau am Besten eine Art Erweiterung die zwar Exile vorraussetzt, aber getrennt gespeichert wird.
    So kannst du bei einem Update Exile einfach austauschen oder deine neue Kreation unabhängig veröffentlichen falls du soetwas geplant hast.


    Kleine Beispiel:
    Wenn man einen Mod baut der CBA nutzt, dann fügt man die neuen Skripte auch nicht bei CBA hinzu...
    (Ist ein schlechtes Beispiel aber das Prinzip sollte klar sein)

    Die Z Koordinate des Bodens ist 0. Zumindest bei einer ATL-Position.
    Mit setPosATL kannst du also mit folgendem Code deine Decke/Wand auf den Boden bewegen:

    Code
    1. private _position = getPosATL _object;
    2. _object setPosATL [_position select 0, _position select 1, 0];

    Wenn du dabei noch Objekte (z.B. Felsen) beachten möchtest musst du AGLS-Positionen nutzen. Allerdings funktionieren diese dann über/unter Wasser nicht mehr, sodass hier eine Fallunterscheidung notwendig wird.
    Details kannst hier nachlesen:
    https://community.bistudio.com/wiki/Position