Armed-Assault.de Twitter
 
 
Themen-Optionen Ansicht
Alt 02.05.2014, 22:02   #1 (permalink)
Newbie
 
Registriert seit: 02.05.2014
Beiträge: 15
Standard SetOwner Problematik

Hallo zusammen,

ich programmiere nun seit 8 Wochen an einer eigenen Mod. Leider ist die API vom ArmaScript schlecht dokumentiert, meistens habe ich durch googeln oder durch reines Probieren eine Lösung gefunden. Tja, nun stehe ich aber seit Tagen vor einem neuen Problem und bin wirklich am verzweifeln. ICh versuche eine Client-Server Architektur aufzubauen und weiss noch nicht genau in wie weit das mit Arma möglich ist, jedenfalls habe ich versucht den Command "setOwner" zu nutzen. Das hat eigentlich auch geklappt, also Client A erzeugt Objekt, Client B stellt Anfrage Objekt zu übernehmen, Server überträgt Objekt an Client B. Jetzt soll Client B das Objekt einfach attachen, jedoch ist es quasi wie unsichtbar. Ich dachte zunächst das Offset stimmt nicht, aber wenn ich meine Implementierung manuell in der Konsole auf dem Server ausführe geht es, jedoch nicht im Script, obwohl alles gleich ist.

Ich hoffe einfach das jemand ein ähnliches Problem hatte und bereits eine Lösung hat. Wäre sehr dankbar für Hilfe.
manatarms ist offline  
Alt 02.05.2014, 22:36   #2 (permalink)
500 Beiträge1000 Beiträge
 
Benutzerbild von Pfandgiraffe
 
Registriert seit: 16.09.2008
Ort: Berlin
Alter: 38
Beiträge: 1.737
Pfandgiraffe eine Nachricht über ICQ schicken Pfandgiraffe eine Nachricht über Skype™ schicken
Standard

Ohne dein Script zu sehen wird dir keiner helfen können.
__________________
Niemand hat die Absicht eine Tüte zu bauen!
​​​​​​​
___<<<A3 Wounding System>>>___
Pfandgiraffe ist offline  
Alt 02.05.2014, 22:57   #3 (permalink)
Newbie
 
Registriert seit: 02.05.2014
Beiträge: 15
Standard

Hallo,

ja du hast natürlich rest ohne Code ist es schwer eine Aussage zu machen. Vielleicht erstmal zu einer grundsätzlicher Frage. Wie kann ich in Arma eine vernüftige, performante Client - Server Architektur aufbauen. Zur Zeit bin ich verschiedenste Varianten am ausprobieren und jedes Mal überlaste ich den Server mit anfragen. Ich brauche anscheinend etwas konzeptionelle Hilfe.
manatarms ist offline  
Alt 02.05.2014, 23:46   #4 (permalink)
500 Beiträge1000 Beiträge
 
Benutzerbild von Pfandgiraffe
 
Registriert seit: 16.09.2008
Ort: Berlin
Alter: 38
Beiträge: 1.737
Pfandgiraffe eine Nachricht über ICQ schicken Pfandgiraffe eine Nachricht über Skype™ schicken
Standard

Naja, grundsätzlich solltest du dich zuerst immer Fragen was und weiviel muß überhaupt übertragen werden. Sofern möglich solltest du soviel wie möglich lokal händeln. Das wissen darüber was lokal ausgeführt werden kann und soll/muss ist schon bald eher ein Erfahrungswert der mit der Zeit kommt.

Wenn man kategorisieren möchte:
- alles was gespawnt wird sollte der Server übernehmen
- JIP (Join in progress) handling ganz klar für den Server
- alles andere (optisch, akustisch) auf den Clients

Das was dann übrig bleibt, also übers Netzwerk geschickt werden muss, sind Dinge die ein Client lokal ausführt (z.B. eine Animation, die aber für alle anderen zeitgleich sichtbar sein soll. Nur solche Sachen müßen dann über den Server an die anderen Clients verteilt werden.



In deinem Fall kann ich z.B. nicht auf anhieb erkennen welcher Sinn hinter dem Ziel stecken soll. Den Befehl setOwner kann ich mir eigentlich in nur einer ganz speziellen Anwendung als sinnvoll vorstellen. (wenn ein Headless Client connected / disconnected)


Grüße
__________________
Niemand hat die Absicht eine Tüte zu bauen!
​​​​​​​
___<<<A3 Wounding System>>>___
Pfandgiraffe ist offline  
Alt 03.05.2014, 02:27   #5 (permalink)
Newbie
 
Registriert seit: 02.05.2014
Beiträge: 15
Standard

Hello again,

danke für das schnelle Feedback.

Ich bin noch in der Evaluierungs- bzw. Probierphase...Ich werde versuchen ein typischen Spielablauf zu erklären und wie ich es aktuell umgesetzt habe.

Ich habe ein Adminmenü gebaut mit einer Liste von allen Objekten die Arma zur Verfügung stellt. Wenn ich ein Objekt aus der Liste auswähle wird es lokal via createVehicle erzeugt und direkt an meinen Spieler attached. Ich habe dann die Möglichkeit das Objekt in alle Richtungen zu rotieren und in der Höhe oder Tiefe zu verstellen. Verschieben in X, Y ist gerade in der Mache . Sobald ich meine gewünschte Ausrichtung erreicht habe, setze ich das Objekt mit detach ab. Damit ich mit diesem Objekt alle Transformationen machen kann, muss ich mir diverse Daten merken. Diese Daten wie die Richtungsvektoren vectorDir und vectorUp und die letzte Position ( positionASL) über dem Meeresspiegel habe ich in einem Array "objectData" gespeichert. Lokal also kein Problem alles geht wunderbar. Jetzt kann es aber sein das ein Spieler "B" mein Objekt auch attachen möchte. Er kennt aber die Daten des Objektes nicht. Hier hätten wir also das Problem das er nur das Objekt selber kennt, aber irgendwie an meine Daten herankommen muss. Mein erster Ansatz war es mit setVariable das Array zu broadcasten, jedoch würde dieses immer an alle Spieler auf dem Server geschickt werden. Es braucht aber in diesem Moment nur ein bestimmter Spieler den Input. Ich gehe davon aus dann bei einer gewissen Anzahl an Objekten der Netzwerktraffic zu hoch wöre und die Spielumgebung abstürzt. Das habe ich also erstmal wieder hingeschmissen und einfach die Regel aufgestellt wenn ein Spieler ein Objekt eines anderen Spielers attachen will dann gibt es Defaultdaten, quasi wie die Ausgangslage als das Objekt das erste Mal erzeugt wurde. Prompt hat sich dann das nächste Problem aufgetan. Ein Spieler der ein Objekt eines anderen Spielers attached kann keine Rotation mehr darauf ausführen, da es ihm nicht gehört!!! So, nun kommen wir zu dem setOwner Fall . Idee war es, das der Spieler dem das Objekt nicht gehört den Server per publicVariableServer anfragt und der Server ihm mit setOwner das Objekt zuweist. Das hat in soweit geklappt das Spieler B das Objekt attachen konnte, aber wie in meinem ersten Post erwähnt das Objekt einfach unsichtbar ist. Naja, so viel zu meinen Versuchen mit Arma Freund zu werden .

Deinen Ansatz das der Server ausschliesslich die Objekte erzeugt finde ich interessant. Könntest du das vllt näher erläutern ? Wenn ich dich richtig verstehe müsste ich für jede Aktion wie Rotation, Verschieben etc einen EventHandler bauen. Somit könnte jeder Client Objekte Transfomieren, indem er das Event triggered und der Server die Transformation auf das Objekt anwendet. Klingt erstmal ziemlich vernüftig, aber kann ein Server n-viele Events gleichzeitig verarbeiten ?
Ich stelle mir einfach die Frage, ob die Arma-Engine überhaupt meine Anforderungen erfüllen kann. Bei beispielsweise 100 Spielern die gleichzeitig 100 Objekte ändenr möchte würde der Server wahrscheinlich in die Knie gehen. So etwas wie ein Abarbeitungsliste kam mir in den Sinn, aber dann würde es automatisch zu delays kommen. Wäre auch nicht so schön. Du merkst ich dreh mich im Kreis, hilf mir raus zu kommen

Geändert von manatarms (03.05.2014 um 02:38 Uhr).
manatarms ist offline  
Alt 03.05.2014, 03:49   #6 (permalink)
Newbie
 
Registriert seit: 02.05.2014
Beiträge: 15
Standard

Ich habe gerade meine Änderungen abgeschlossen und ein wenig getestet. DAs Objekte wird vom Server erzeugt und alle Manipulationen laufen über EventHandler. Der Client weiss fast nichts und sagt nur was er gerne machen möchte. Beim Testen ist mir aufgefallen das die Transformation die der Server ausführt bei mir erst sehr verzögert ankommt. Kann man das optimieren ?
manatarms ist offline  
Alt 03.05.2014, 08:40   #7 (permalink)
500 Beiträge1000 Beiträge
 
Benutzerbild von Pfandgiraffe
 
Registriert seit: 16.09.2008
Ort: Berlin
Alter: 38
Beiträge: 1.737
Pfandgiraffe eine Nachricht über ICQ schicken Pfandgiraffe eine Nachricht über Skype™ schicken
Standard

Objekte soll der Server spawnen weil der diese i.d.r. auch weiter verarbeitet / transformiert - in welcher Form auch immer.

Der Server kann eine gewisse Anzahl an Events bzw. Rechenoperationen pro Frame ausführen. Ein Delay in der Abarbeitung von Events (eine Abarbeitungsliste entsteht automatisch) kommt also zustande wenn die Frames des Servers in die Knie gehen. Erfahrungsgemäß tun sie das bei sehr vielen Spielern auf dem Server. Wenn du deine Arbeit also prüfen möchtest wirst du zwingend im MP prüfen müßen während du den Server beobachten kannst. Fällt der Server erstmal unter 5fps hast du schon fast verlohren. Dann holt er die Abarbeitungsliste nicht mehr auf und verschluckt auch gerne mal die Abarbeitung von ein paar Operationen komplett.


Wird bei dir jedes Objekt nur einmal erzeugt und dann weiter gereicht? Müßen deine Objekte für jeden sichtbar sein oder würde auch lokal für den jeweiligen Spieler reichen?

Der Ansatz klingt schon ganz gut so wie du es angehst. Warum da jetzt große Verzögerungen auftreten bis du siehst was der Server mit dem Objekt anstellt kann ich nicht sagen. Was konkret wird denn verzögert? Positionierung?
__________________
Niemand hat die Absicht eine Tüte zu bauen!
​​​​​​​
___<<<A3 Wounding System>>>___
Pfandgiraffe ist offline  
Alt 03.05.2014, 13:22   #8 (permalink)
Newbie
 
Registriert seit: 02.05.2014
Beiträge: 15
Standard

Zitat:

Wird bei dir jedes Objekt nur einmal erzeugt und dann weiter gereicht?

Hmm...

...aktuell erzeuge ich das Objekt einmal auf dem Server, dieses wird nicht explizit von mir an den Client weitergereicht bzw. das übernimmt ja die Engine.

Zitat:

Müßen deine Objekte für jeden sichtbar sein oder würde auch lokal für den jeweiligen Spieler reichen?

Da ich vorhabe Spielmechanismen von Minecraft zu addaptieren, müssen schon alle Objekte für jeden sichtbar sein. Idee ist es ein Art gemeinsames Bauen (Housing) zu ermöglichen. Kann aber auch mit Kompromissen leben, wenn die Engine das nicht hergibt.

Zitat:

Der Ansatz klingt schon ganz gut so wie du es angehst. Warum da jetzt große Verzögerungen auftreten bis du siehst was der Server mit dem Objekt anstellt kann ich nicht sagen. Was konkret wird denn verzögert? Positionierung?

Transformationen werden via Events auf dem Server ausgeführt, die der Client auslöst. Wenn ich beispielsweise einaml um 90 Grad drehe, dann dauert es ca eine Sekunde und dann nimmt das Objekt erst die neue Rotation ein.

Eine Überlegung wäre es für die Zeit der Transformation ein lokales, geclontes Objekt zu erzeugen und das später wieder zu löschen wenn der Server sein eigenes Objekt transformiert hat. Das hätte eventuell den Vorteil das die Animation flüssig auf dem CLient läuft. Fragen über Fragen

Geändert von manatarms (03.05.2014 um 13:46 Uhr).
manatarms ist offline  
Alt 03.05.2014, 15:40   #9 (permalink)
500 Beiträge1000 Beiträge
 
Benutzerbild von Pfandgiraffe
 
Registriert seit: 16.09.2008
Ort: Berlin
Alter: 38
Beiträge: 1.737
Pfandgiraffe eine Nachricht über ICQ schicken Pfandgiraffe eine Nachricht über Skype™ schicken
Standard

Gut, jetzt begreif ich langsam was du vor hast.
In dem speziellen Fall erzeuge die Objekte direkt vom Client und transformiere sie dort auch. Das Objekt ist eh global sofern du den Befehl createVehicle verwendest. Positionierung ist ebenfalls global. Sollte also keine Probleme im MP geben und du sparst dir eine menge Arbeit.

Wenn ein Clien vom Server disconnected gehen die übrigen Objekte die von ihm gespawnt wurden automatisch in den Besitz des Servers.


Grüße
__________________
Niemand hat die Absicht eine Tüte zu bauen!
​​​​​​​
___<<<A3 Wounding System>>>___
Pfandgiraffe ist offline  
Alt 03.05.2014, 18:38   #10 (permalink)
Newbie
 
Registriert seit: 02.05.2014
Beiträge: 15
Standard

Die von dir beschriebene Variante habe ich ja als erstes versucht, deshalb habe ich auch setOwner verwendet. Wenn nämlich Client A ein Objekt erzeugt, attached, rotationen vornimmt und und dann detached, dann kann Client B es zwar attachen aber keine rotation ausführen. Es springt immer wieder zurück auf die Ausgangslage. Das konnte ich nur umgehen, indem Client B den Server dazu beauftragt ihm das Objekt zu übergeben mit setOwner. Danach waren Transfomationen möglich. Dies hatt aber einen grossen Nachteil das das Objekt unsichtbar war plötzlich. Erstmal dachte ich das der Offset beim attachen vielleich falsch gesetzt wird, aber ich habe es ein paar mal manuell gemacht und es ging nicht.
Beim zweiten ansatz habe ich dann immer gesagt das wenn ein Client ein Objekt attachen will das ihm nicht gehört dann soll er das vor ihm löschen und ein gleiches bei sich erzeugen. So wird der Server nicht angefragt, aber das hatte natürlich auch Nachteile. Wenn Client A das Objekt mit sursorTarget identifizieren möchte, dann geht das so gut wie nie. Es kommt meistens Null zurück, obwohl ich genau aufs Objekt zeige. Erst wenn ich mit "player reveal object" arbeite funktioniert alles wie erwartet. Das bedeuted jedoch das ich immer einen Broadcast auslösen muss, damit jeder SPieler diese Info bekommt. Ich habe mehrfach einen Broadcast hintereinander ausgelöst und RuckZuck war Ende im Gelände. Spielumgebung zusammengebrochen !

Ich glaube am sinnvollsten wäre es das ausschliesslich der Server Objekte erzeugt und ich nur mit EventHandler arbeite. Damit die Animation ohne Delay abläuft erzeuge ich ein Dummyobjekt lokal für den Client. Die Rotation wird dann auf dem lokalen Objekt und parallel auf dem Remote Ojekt angewendet. Wenn die Rotation abgeschlossen ist lösche ich einfach das lokale Objekt. Alle Objekte wären dann zentral auf dem Server. Hat den weiteren Vorteil das wenn ich die Transformationsdaten der Objekte in eine Datenbank schreiben will direkt der Server alle Objekte kennt. Wie findest du meine Idee ? Hat es einen neuen Haken ?

Geändert von manatarms (03.05.2014 um 19:12 Uhr).
manatarms ist offline  
Alt 05.05.2014, 15:34   #11 (permalink)
Newbie
 
Registriert seit: 02.05.2014
Beiträge: 15
Standard

Vielen Dank für deine Hilfe, ich habe es nun so implementiert das einfach jeder Client für sich die Objekte lokal erzeugt und andere Clients diese nicht attachen können. Das hat mir eine Menge Arbeit erspart und hat noch den Vorteil das nicht so viel Traffic entsteht zwischen den Clients.
manatarms ist offline  
Alt 05.05.2014, 17:11   #12 (permalink)
500 Beiträge1000 Beiträge
 
Benutzerbild von Pfandgiraffe
 
Registriert seit: 16.09.2008
Ort: Berlin
Alter: 38
Beiträge: 1.737
Pfandgiraffe eine Nachricht über ICQ schicken Pfandgiraffe eine Nachricht über Skype™ schicken
Standard

Sehr gut.
__________________
Niemand hat die Absicht eine Tüte zu bauen!
​​​​​​​
___<<<A3 Wounding System>>>___
Pfandgiraffe ist offline  
 


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 
Themen-Optionen
Ansicht

Forumregeln
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus


Kontakt - HX3.de - Archiv - Nach oben

Angetrieben durch vBulletin, Entwicklung von Philipp Dörner & Tobias



SEO by vBSEO 3.2.0 ©2008, Crawlability, Inc.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119