Beiträge von Stig

Zitat von Kaibu

weiß nicht was der Status von dieser Go Geschichte ist.

Finch, Attacke! Mach Werbung!

TL;DR

Eine Gaming Community, hauptsächlich bestehend aus TS-Server und Forum. Planen eigene Gameserver und sind hilfsbereit.

Nicht zu vergessen: Das Forum bietet ein "unvergleichliches Erlebnis".

https://account.maverick-applications.com/support/

Dafür musst du https://community.bistudio.com/wiki/setMarkerText in das Einnehmen-Script einbauen.

Hi,

as you probably know you can use PBOManager to unpack PBO files.

For information about WRP files this could be helpful:

https://community.bistudio.com/wiki/BIS_File_…nd_File_Formats

Brandy Scotchland

Ein Telefonat läuft circa so ab:

1. Spieler A will B anrufen, B wird per remoteExec und Dialog oder so gefragt ob er den Anruf annimmt.
2. Wenn ja: Server erstellt neuen Channel (https://community.bistudio.com/wiki/radioChannelCreate).
3. Server fügt A und B dem neuen Channel hinzu (https://community.bistudio.com/wiki/radioChannelAdd).
4. Vielleicht noch bei A und B den "Telefonchannel" als aktuellen Channel setzen und darauf hinweisen, dass sie jetzt verbunden sind (https://community.bistudio.com/wiki/setCurrentChannel).
5. Damit es cool ist, wird jede Minute ein Dollar von A und B abgezogen als Gebühr.
6. Wenn der Anruf beendet werden soll, dann https://community.bistudio.com/wiki/radioChannelRemove

Dabei musst du darauf achten, dass es nur begrenzt viele custom Channel geben kann. Am besten Punkt 2 ignorieren und schon vorher ein paar leere Channel erstellen, irgendwo in einer Variable speichern und immer wiederverwenden. Dann muss man sich darum kümmern, welche Channel voll/leer sind und das ganze per Script koordinieren.

Zitat von Lassi262612

von mehren bei uns gesagt worden das das bei vielen usern zu schlechterer Performance führen würde.

Man kann Vieles sagen ohne darüber nachgedacht zu haben^^

Das sollte nicht viel mehr Leistung und Bandbreite fressen als ein Gespräch über einen Teamspeakserver, denn es ist auch nur Sprachübertragung.

_{Aber vielleicht hat Bohemia tatsächlich etwas dabei verkackt und es läuft wirklich scheiße...}

Zitat von Turbar Redhorst

bin mit Gdata schon viele Jahre Virenfrei unterwegs!

Denkst du...

Aber zum Thema:

Kannst du mal das Fahrzeug-Spawn Script hier reinstellen?

Zitat von Marius1773

oberer Teil von dem Wiederstand muss man noch gucken welches Land

Widerstand ist auch eine Idee, er muss ja nichteinmal eine große Armee sein, sondern kann auch aus Widerstandskämpfern der Bevölkerung bestehen, die von ihrer eigentlichen nationalen Armee abgeschnitten sind.

Was wird das für ein Setting?

Mir fallen da diese Möglichkeiten ein:

• Gebiet durch Deutschland besetzt (Wehrmacht und Zivilbevölkerung)
• Gebiet umkämpft, Front verläuft durch die Map, aktive Kampf und Verschiebung der Front (Wehrmacht, entsprechende andere Armee, Zivilbevölkerung)
• Gebiet umkämpft, Front verläuft durch die Map, Stellungskrieg und statische Front (Wehrmacht, entsprechende andere Armee, Zivilbevölkerung)

BeFreezy

Du hast _unit getVariable ["mic", false] geschrieben, müsste aber _x getVariable ["mic", false] sein.

Zitat von BeFreezy

Holy... vielen Dank!

Gerne, aber das macht dann 2,70€.

Die Namen über den Köpfen der Spieler werden durch Altis_Life.Altis/core/functions/fn_playerTags.sqf erzeugt. Um ein Mikrofon-icon vor den Text zu machen, wird <img image='\A3\ui_f\data\igui\rscingameui\rscdisplayvoicechat\microphone_ca.paa'></img> vor den Namen geschrieben.

Das Schwierige ist jetzt, herauszufinden ob ein Spieler spricht oder nicht. Es gibt zwar den Befehl getPlayerChannel, der das kann, aber ausgerechnet den "Direct"-Channel unterstützt dieser Bfehl nicht.

Die (gezwungene) Alternative:

Lokal anhand der UI überprüfen, ob ein Spieler spricht und die Information über das Netzwerk an andere Spieler weiterleiten.

Soetwas ähnliches hat Just4FunGaming auch getan:

Zuerst wurde ein Eventhandler für keyDown/keyUp angelegt, der mit player setVariable["mic", true/false, true] für jeden anderen PC abfragbar macht, ob ein Spieler gerade redet oder nicht. Das ganze wird hier ähnlich wie bei Killzonekid anhand der Icons festgemacht (!(isNull findDisplay 55) && { !(isNull findDisplay 63) }).

// Written by Kupferkarpfen
// License: CC BY-NC-SA 4.0

// Anti-Side-Talking Script
// Inspired by http://www.armaholic.com/page.php?id=28897

private _fncCheckVoice = {
    if( !(isNull findDisplay 55) && { !(isNull findDisplay 63) } ) then {

        // User is speaking, check channel...
        if( !(currentChannel in [3, 4, 5]) ) then {
            titleCut [" BITTE NICHT IM SIDECHAT REDEN ", "BLACK IN", 15];
            // Talking side/globally/command, switch to direct:
            setCurrentChannel 5;
        };

        if( currentChannel == 5 && { !(player getVariable["mic", false]) } ) then {
            player setVariable["mic", true, true];
            [] spawn {
                waitUntil { sleep 0.5; isNull (findDisplay 55) || isNull (findDisplay 63) };
                player setVariable["mic", false, true];
            };
        };
    };
    false
};

waitUntil { sleep 1; !(isNull (findDisplay 46)) };
(findDisplay 46) displayAddEventHandler ["KeyDown", _fncCheckVoice];
(findDisplay 46) displayAddEventHandler ["KeyUp", _fncCheckVoice];

Dann kann schonmal jeder Spieler für jeden anderen Spieler abfragen, ob er/sie gerade redet.

if(_targetPlayer getVariable ["mic",false])then{ /* _targetPlayer redet gerade */ };

Wenn X also redet, wird nur noch das Symbol vor den Namen geschrieben:

if( _unit getVariable ["mic", false] ) then {
   _text = format["<img image='\A3\ui_f\data\igui\rscingameui\rscdisplayvoicechat\microphone_ca.paa'></img> %1", _text];
};

Und siehe da, du hast den Mikrofonstatus in den Nametags.

MfG Stig

blackfisch

Wie ZorG schon schrieb, die Probleme entstehen, wenn man es "too frequently in a given period of time" benutzt. Das Variablen, die durch publicVariable entstehen, langsamer sind, bezweifle ich stark, da sich die Dinger vollständig wie normale Variablen verhalten.

Zitat von Fl0rixn

Problem gefixt. Danke an alle

Woran lag es letztendlich?

Zitat von blackfisch

Das mit serverseitig lagern ist böse. Wenn du zu viele publicvariables hast geht das hart auf die Performance, genau so wie wenn du alles serverseitig ausführst du die Server performance abschießen kannst.

Erstens meine ich weiterhin clientseitig ausführen, lediglich serverseitig lagern.

Aber warum sollen die publicVariables "hart auf die Performance" gehen und "böse" sein? Diese Variablen werden nur zum Spielbeginn übertragen, das geht wohl kaum auf die Performance, denn es handelt sich hier um konstante Variablen und nicht um irgendwelche Dauerschleifen die zu viel Zeug über das Netzwerk verschicken. Auch die Netzwerkbelastung wird nur minimal höher sein, denn jede Funktion die per publicVariable übertragen wird, erleichtert die Größe der Missionsdatei. Es wird vermutlich lediglich ein geringer Overhead durch die einzelnen publicVariable-Übertragungen im Vergleich zur Übertragung als gebündelte Missionsdatei erzeugt.

Stimmt, auch wenn es nicht ganz sicher ist, hält es dennoch viele Leute vom Code fern. Das gilt ja in Arma sowieso für jede Verschleierung/Verschlüsselung.

Ich kann dir übrigens auch empfehlen, den Code serverseitig zu lagern und nur per publicVariable/remoteExec an die Clients zu verteilen, dann kannst du deine Scripte ganz aus der Missionsdatei herausnehmen und brauchst gar nicht erst eine Verschleierung/Verschlüsselung.

Falls du fit in JavaScript bist, kannst du dir unter https://simplicity-gaming.com/sqf/bin/js/editor.js ab Zeile 816 auch den Verschlüsselungscode anschauen.

Anstatt Database Exception Error: Connection attempt failed: SSL connection error: protocol version mismatch

hast du jetzt Database Exception Error: MySQL: [MySQL]: create session: specify user name, was genau hast du verändert?