Beiträge von Hirschi

Ok .. Fehler gefunden ... hatte die falsche tbbmalloc.dll .....

Hatten auch Problem mit der Perf Bin V6 .. alles zum Kotzen ... Linux scheint stabil zu laufen ..

Ok ... teste sie auch mal

lt ArmA Feedbacktracker sollen alle die Probleme haben 0026878: Server crashes randomly - Arma 3 Feedback Tracker die Beta Version Arma3Test154RC drauf ziehen und die halt Testen ..

Arma 3 Release Candidate | Hostile Takeover Gaming Community

Ich stelle jetzt um auf extDB2 ... Was die Abstürze angeht, langsam haben wir keine mehr, die Spieler hauen uns ab .. Also hats bohemia doch gefixt bekommen .. grins ..

Bei der PReformance Bin ( die Version vorher ) is mir aufgefallen, das die RPT nicht so gespammt wird, Spams werden zusammen gefasst in ein Nachricht .. 3 mal mehr Performance ??? Naja ... wenn dann überhaupt 3 - 5 % ..

Clasnames ändern ... mhhh ... Hat Bohemia ja schon öfter gebracht, Clasnames zu ändern, aber das es solche Auswirkungen hat ??

Wir haben auch das Schiffswarack drinnen, aber mir ich konnte da kein Zusammen hang beobachten .. Da passiert ja auch nciht viel in dem Script ... Da hätte ich wenn dann schon ehr das Airdrop script im Verdacht, da es och irgendwelche Cargoboxen verwendet .. Frag mich aber ncih nach den Classnames .. müsste ich gucken jetzt ..

Hab hier noch ein relativ neues Script Komando gefunden .. "disableRemoteSensors" disableRemoteSensors - Bohemia Interactive Community

hab jetzt das mal in unsere init.sqf ( nicht \core\init.sqf ) den Spruch hier mit reingebaut -------> if (!getRemoteSensorsDisabled) then {disableRemoteSensors true;};
Ob´s hilft ... K.P... scheint aber so oder so sinnvoll zu sein, solange es kein negativen effekt hat ..

Hmpf ....
Watt is aus den guten alten Zeiten geworden wo es noch Amiga 500 gab und so .. grins ..

Ok ... lt. Changelog hat Bohemia was mit den allocators gemacht ... Hatte allerdings Crash mit system allocator und auch mit default allocator ..
Würde aber für die Out of Memmory geschichte sprechen die wir auch haben ...

Wir selbst hatten auch schonmal so einen Fehler, der aber selbst vereursacht war .. Und zwar haben unsere Cop´s in na ungetimten while schleife ( is das sleep abhanden gekommen bzw. waituntil ) das Scriptcomando setObjectTextureGlobal rausgehauen ... Der Server ist mit selber Error Meldung gecrasht ..

Allerdings ist damals der Client Upstream bis zum Anschlag hochgegangen und das dann irgendwann alles zusammenbricht ist kein wunder .. Besonders bei 50 Spielern gleichzeitig... war ordentlich was los im Netzwerk .. grins ..

Aber wie gesagt, der Fehler kommt so nicht in Frage .. der Upstream ist normal ... habs ausserdem mal provoziert via Script Console und da gehört schon einiges dazu um so einen Crash zu verursachen ..

Was ist überhaupt mit den ganzen Addon´s , die am anfang der Mission.sqm mit eingebunden werden.. braucht man die überhaupt ?? holt sich doch der Client von alleine wen er sie braucht oder ??? kann es da ein Problem mit gibt?? veralterte verweise oder so ??
Würde zu den Erros Server Object not found passen ..
Die haben ja auch krass was an der Altis Map geändert .. Script Command nearstBulding funktioniert nicht mehr so wie soll .. Mir ist aufgefallen, das manche Häuser zwar noch da sind, aber nicht mehr auf der 2D MAp verzeichnett sind (z.B.: Flugahafengebäude ).. und nearstBulding scheint zusammen zu hängen mit den 2D Map Häusern ...

Kann doch nicht unlösbar sein das Problem und wenn du sagst, das die Franzosen das hinbekommen haben muss es ja ne Lösung geben ... hmpf

mhhh ok ....

Das ist ja schonmal ne vernünftige Aussage... Trotzdem zum Kotzen das ganze.. Ich hasse ArmA Updates ... aber keins war so schlimm waie das ... Die Spieler selbst haben auch schon gar kein Bock mehr auf ArmA ... is klar ... grade bei Altis Life .. Stundenlanges Farmen fürn Arsch ...

Da können unsere Supps noch so kulant sein mit Rückerstattungen usw .. Aber irgendwann hat man verständlicherweise die Faxen dicke ..
Sry ... aber bin hier Tage lang dabei mich im Kreis zu drehen und Stück für Stück unsere Misson ausseinander zu reissen auf verdacht ---

Gibt´s evtl. nen Filter der Extension whitelisted ??

Sry.. kann nicht mehr bearbeiten,

[lexicon]extDB[/lexicon] gibt übrigens auch keine Logs auf dem Client

Moin Moin,

ich hab folgendes Problem.

Ich versuche [lexicon]extDB[/lexicon] via Client einzubinden leider ohne Erfolg.

Warum das ganze? Ich benötige eine Datenbank Anbindung für nenn Headless Client.

Netzwerk u Initialisierung des HCs ist kein Problem. aber [lexicon]extDB[/lexicon].

was ich bereits versucht bzw rausgefunden hab.

Battleye scheint die dll von [lexicon]extDB[/lexicon] zu blockieren.
Also Battleye auf Server aus ( Client natürlich auch )

Da die [lexicon]extDB[/lexicon] Ordner nicht gepackt sind habe ich auch allowfilepatching=2 gesetzt u -filepatching auf dem HC an.
auch nix.

dann mal versucht mit nenn normalen Client auf n Server zu joinen, ([lexicon]extDB[/lexicon]) Ordner
natürlich eingebunden und via Console versucht [lexicon]extDB[/lexicon] "anzusprechen" :

[]spawn{
_result = call compile ("[lexicon]extDB[/lexicon]" callExtension "9:ADD_DATABASE:Database1");
hint format["%1",_result];
diag_log format["%1",_result];
};

meckermeldung tbbmalloc.dll Not Found. aber das Problem hab ich auch
schnell behoben. .
Die Meldung zeigt mir aber das da was passiert, das [lexicon]extDB[/lexicon] zumindest angesprochen wird. aber warum kommt nix zurück?

Was kommt, isn ScriptError, _result undefinierte Variable ... bla bla .... klar, weil die Zeile "_result = call compile ("[lexicon]extDB[/lexicon]" callExtension "9:ADD_DATABASE:Database1");" kein Ergebniss liefert .. Zumindest aufn Client nicht...

Hab auch versucht das Ganze mal in ne *.pbo zu packen, bzw sogar (testweise ) [lexicon]extDB[/lexicon].dll in die missionsdatei zu hauen, aber nix..

selben versuche mit extDB2 und Arma2net. genauso erfolglos.

wie gesagt, via Server alles kein Problem. hab sogar [lexicon]extDB[/lexicon] dazu gebracht
sich mit 2 verschiedenen DBs gleichzeitig zu verbinden. .

jetzt wäre ich für nenn Tipp echt dankbar.

Gruß Hirschi - Die Liga

Wir haben auch die Probleme ... ich vermute auch ganz stark das es an [lexicon]extDB[/lexicon] liegt ...

ne andere Vermutung wäre InfiStar ...
Aber ich denke mir auch mal das es an [lexicon]extDB[/lexicon] liegt

Ich hab mir extDB2 mal angeschaut und ... puhhh .. oh man ... isn Arsch voll arbeit ...

Hab hier auch mal was gefunden ... da is sogar alles schon fretig für 4.0
How to: extDB2 with sql_raw protocol - Script Releases - Altis Life RPG

Allerdings hilf uns das nicht weiter da wir mit 3.1.4.8 arbeiten..

Also .. entweder umsteigen auf extDB2 oder .......

Is jetzt nur ne Idee,
eine Art controlling sytem ( oder wie auch immer der Fachausdruck dafür wäre ) zu bauen..
Weil, wenn man sich das Chaos anguckt, wie die Anfragen an [lexicon]extDB[/lexicon] weier geleitet werden, dann wundert mich das nicht, das es nicht vorher schon Probleme damit gab..
Mit Chaos meine ich vorallem den Eintag hier immer wieder -> waitUntil{sleep (random 0.3); !DB_Async_Active}; bzw. waitUntil{ !DB_Async_Active};

controlling system in so fern, das alle Anfragen in ein Array gespeichert werden, und von fn_asyncCall sauber nacheinander und getaktet abarbeitet werden kann .. Sogar das prioritisieren der leseanfragen wäre möglich.

Jetzt ist die Frage, ob das hilft bei unserem gemeinsamen Problem.. Es würde definitiv helfen , [lexicon]extDB[/lexicon] zu entlassten ..

Möglich wäre es für mich sowas zu schreiben evtl..Sowas ähnmliches hab ich auch schonmal gebaut.. ( Erfahrung aus µContorller Bereich Mavlink Protokoll ).

Ich würde es euch auch zur verfügung stellen aber is immer noch die Frage ob sich der Aufwand lohnt oder der Fehler eigentlich ganz woanders liegt.. Dann wäre die Arbeit für die Katz..

Wie ist Eure Meinung dazu ??? Oder habe ich irgendwas nicht bedacht ???

Gruß,

Hirschi - Die Liga