Beiträge von vabene1111

ich habe den Thread (anders als in mienem eigenen forum) sehr wohl gelesen

man sollte auch nicht aus test eine Datenbank ohne passwort nehmen, vollkommen egal was ist, bevor eine DB ans internet geht kommt nen sicheres passwort drauf ...

aber wenn du der meinung bist das infistar gut ist und DB's ohne passwörter will ich dich davon nicht abbringen, mach das mal dann lernst du irgendwann warum ich das hier schreibe .. oder du hast glück .. oder du denkst das du glück hast und irgendein script kiddy freut sich weil sein port scanner botnet ne offene DB gecapert hat lässt es dich aber nicht merken

und was lernen wir daraus:

1. kein infistar nutzen

2. verdammt noch mal starke Passwörter und Zugriff Beschränkungen auf der Datenbank haben ... du kannst doch nicht ne DB ohne PW ans netzt hängen !!!

Also hatte keine Crashes mehr seit 15 Uhr, es scheint allerdings das Wetterscript gewesen zu sein und nicht das noLogs (das war gar nicht erst aktiv, weil der restarter die config nicht geladen hatte).

Danke für die Hilfe, sollte jemand crashes haben schaut mal nach dem wetter

Server logs absolut nichts, Client logs muss ich mir gerade noch organisieren, da auf dem Arma discord die leute schrieben das das nen allgemeines Problem vermute ich mal das das wieder so ein arma vodoo problem ist, aber mal gucken

ich sage auf jeden fall bescheid wenn der server jetzt ohne -noLogs durch läuft

das mit dem parameter ist interessant, wir haben zwar nicht das problem das die Leute von BE gekickt werden sondern das der ganze server einfach weg crasht aber ich habe die Periode gerade einfach mal ohne gestartet, mal sehen was passiert (abgesehen davon das die logs explodieren :D)

sehr interessant das bei euch alles läuft, im Arma Discord haben 3 leute geschrieben das sie crashes haben, mal sehen ob da die Tage was von BI kommt, euch auf jeden fall schon mal vielen dank

Hallo Zusammen,

seit dem 1.78 Update haben wir mal wieder das übliche neue "Feature" eines Arma Updates: Random Server Crashes ohne nennenswerte Logs (einfach immer wieder schön wie viel Mühe BI sich gibt uns dieses Feature mit jedem Update zu bringen)

Naja, ein paar leute meinten zu mir das das nicht nur bei Modded sondern auch Vanilla Altis Life so ist (oder KOTH/..), also wenn ihr nen Server habt dann schreibt doch mal fix hier nen paar kleine Eckdaten und ob ihr Crashes habt oder nicht, dann können wir mal herausfinden wie allgemein das Problem ist und ob es irgendwelche gemeinsamen Nenner gibt.

Zu uns:

Server Crasht mehrmals am Tag, üblicherweise bei > 70 Spielern, war aber auch schon bei < 30.

Mods: ACE, CBA, CUP Terrain und nen Haufen anderer Krams

- CBA ist schon manuell gepatcht

DB: ExtDB 3, SQL Custom (noch nicht die neuste Version)

Altis Life: irgendwas was mal auf der 4.3 oder so basierte, aber davon ist nicht mehr viel übrig

Server: Windows 2016, ein Arma Server auf der Hardware, Battleye Port getrennt (wie mit Update möglich)

Schau mal hier http://lmgtfy.com/?q=arma+3+play+sound

einfach eine ogg mit entsprechender Musik in der Mission oder Mod einbinden und dann in dem script aufrufen, von der länge halt anpassen das es sich mit der Cam deckt, ein sound kann meines wissens nach nicht einfach so gestoppt werden.

ja, wir haben das bei uns so das du in der init des NPC's nur noch angibst welche init aus einer config geladen werden soll, diese wird dann einfach reingeladen.

wir haben noch das man dem ganzen argumente übergeben kann, dann kann man z.B. sagen garage und übergibt dann als argument noch welche.

was halt auch noch übergeben werden muss damit das script weiß wo es die actions ran packen soll ist das objekt (also this)

wenn du genauere Fragen hast sag bescheid

Es ist außerdem Empfehlenswert die Keys regelmäßig zu aktualisieren, für den Fall das der Privat key verloren gegangen ist.

Wir machen es so das wir bei jedem Update die Signaturen neu generieren, dafür habe ich nen simples script gebastelt was das Keypair erzeugt mit dem aktuellen timestamp im namen, die signaturen baut und die bikeys für die Server alle in einen Ordner legt (man kann irgendwo im Wiki die DSSign.exe und so runter laden, dann einfach mal schaun was die so an parametern akzeptieren).

Es ist außerdem ratsam nicht die bikeys zu nutzen die bei einem mod dabei sind, es gab mehrere Fälle wo größere Modder ihre private keys "verloren" haben, womit sich dann jeder signaturen generieren konnte die dann wenn ihr den public key bei euch drin habt von euch aktzeptiert werden.

TLDR: TFAR reverse engineeren und auf gleiche weise nen neues Backpack mit Model bauen

also ohne das jetzt auswendig zu wissen gehe ich mal davon aus das jedes funkgerät ein paar bestimmte config werte hat, das heißt du musst die mal den TFAR Mod auf machen (einfach von github clonen) und in die configs der verschiedenen Rucksäcke gucken ..

dann musst du heraus finden ob TFAR irgendwo ne liste mit Backpacks hat die gehen (was ich nicht glaube) oder ob einfach alle backpacks aus der CfgVehicle (ist glaube ich die für backpacks) gelesen und geprüft wird welche die attribute haben.

dann musst du halt nen neuen Rucksack erstellen mit nem Model von dem gürtel und die entsprechend die TFAR werte setzen ..

ist jetzt nur so grobes vorgehen aus dem kopf, aber damit solltest du weiter kommen ..

bzw. in der server config einstellen das die altislife mission automatisch startet

auch mal gucken ob der bereich in der config auskomentiert ist, es gibt irgendwo im wiki nen template was man kopieren kann und ohne syntax highlighting sieht man das fast nicht

hmm interessant .. die action bekommt man auf jeden fall nicht weg, die ist engine code da kommt man nicht ran ...

mit nem mod könnte man die class einfach überschreiben aber ich nehme mal an es geht um nicht modded oder ?

was man noch probieren könnte wenn gar nichts anderes geht ob da nen event handler irgendwo ausgelöst wird und dann den spielern nach dem heilen einfach wieder den schaden von vor dem heilen geben, nicht hübsch aber wäre nen workaround ..

ich weiß das das direkt am fahrzeug ist, aber ich glaube das direkt am fahrzeug heilen geht nur wenn da first aide kits drin sind (jedenfalls war es früher mal so) .. davon das es einen virtuellen "healCargo" gibt wie bei den Tank/Ammo lastern habe ich noch nichts gehört ..

naja das brauchst du eigentlich nicht .. wenn du das mit der uid machen wollen würdest müsstest du das über die DB machen was mMn keinen sinn macht.

Grobe richtung:

Du machst den Dialog auf und speicherst das CursoObject oder Target (bei spielern relativ egal, geht beides ganz gut), dann wenn der spieler ok oder geben oder was auch immer der button sagt klickt rufst du per remoteExec bei dem cursorObject (also dem anderen Spieler) eine Funktion auf die ihm das Geld hinzufügt und nimmst bei dem client der es gibt das geld weg.

guck dir mal die moneyGive und moneyReceive oder so an, das sind die funktionen die im z Menü genutzt werden (bei den namen bin ich mir nicht 100% sicher aber einfach mal gucken was der button so macht)

naja da schaust du mal in die spawnVehicle und guckst mal welche Variablen so auf dein Fahrzeug gesetzt werden und wirst heraus finden das 2 Teile vom query result in eine Variable namens dbInfo* gesetzt werden.

Jetzt also bei der Halterabfrage nur noch was machen was diese Variable ausliest und voila du hast die PID und das Nummernschild

* Nicht ganz sicher ob das wirklich genau die Variable ist, habe das bei uns alles komplett neu geschrieben aber ich meine früher wäre das so gewesen...

ich bin mir nicht hundert prozent sicher und habe gerade kein arma um das zu testen aber kann es sein das in dem Fahrzeug medic kits drin sind und die spieler sich deshalb heilen können ?

Also ich kann nur sagen das es in arma bis zum heutigen Tag immer noch stupide einfach ist beliebige Scripts zu injecten.

Da hilft dir weder Spyglass noch Infistar und erst recht nicht BattleEye.

Ich konzentriere mich hauptsächlich darauf die Hacker an ihrem verhalten zu erkennen.

Ich will jetzt hier nicht zu viel erzählen (ja ich weiß security by obscurity ist kacke aber was soll man halt machen), aber vielleicht als grober Ansatz:

Überlege dir was typische verhalten von hackern sind: geld cheaten, unverwundbar sein, Teleport (was meistens über viele kleine setVectors oder so funktioniert) und vieles mehr

jetzt musst du dir für jedes dieser Probleme eine Lösung überlegen, nicht unbedingt wie du es verhinderst sondern vor allem wie du erkennst das es jemand macht Armitxes hat da schon ein paar ideen genannt.

Wenn du Verhalten erkennst was dir komisch vorkommt kannst du den Spieler automatisch bannen oder auch einfach nur noch strenger beobachten/loggen.

Was das Problem mit dem Geld und dem schaden der Ökonomie auf dem Server angeht so kann ich nur sagen: Habe logs für alle Transaktionen und zur not scripte oder zumindest backups um schnell den stand bestimmter oder aller spieler einfach etwas zurück zu setzen.

Das klingt jetzt vielleicht etwas traurig, aber ich habe oft genug gesehen wie unglaublich einfach es ist ein script in arma rein zu bekommen und wenn man als hacker sehr schlau vorgeht wird es nie jemand merken, aber dann hat man halt auch keinen riesen Vorteil mehr weil man auch nicht mehr verdient als man so tun würde (o.ä.).

Vielleicht hat aber hier ja auch jemand eine andere Meinung, würde mich interessieren

prinzipiell wird die größe des Virtuellen Inventars anhand der tatsächlichen Inventargröße berechnet, ich kenne die neuen Versionen nicht aber ich nehme mal an mittlerweile wurde was eingebaut damit man die werte auch einstellen kann, sonst muss man das einbauen oder die Configs der Rucksäcke überschreiben.

Generell ist es mMn nicht so schlau das ganze in der survival zu machen, da viel zu viele checks laufen um den Rucksack zu prüfen, sinvoll ist es die entsprechenden eventhandler zu nutzen um die größe nur zu berechnen wenn sich der rucksack auch ändert

So wirklich testen kann man das erst wenn mal 100 leute drauf sind, aber wir achten darauf überall möglichst performance sparend zu arbeiten und haben auch viele hundert stunden investiert um die Mission an jeder erdenklichen stelle auf performance zu verbessern, trotzdem kann es sein das die performance auf schlechten bis mittleren systemen nicht so gut ist, aber wie gesagt, so wirklich testen können wir das erst mit vielen leuten.