Alles anzeigen
Hallo und herzlich willkommen zum 22. Development Blog.
In dieser Woche haben wir eine Menge Arbeit in sehr verschiedene Teile unserer Modifikation gesteckt, also kommen wir gleich zu den Details.
Parachute sync
Diese Woche haben wir die Arbeit an der Fallschirm Synchronisierung fortgesetzt und waren in der Lage, es fertig zu bekommen - außer manche dinge die noch nicht so recht wollen: Wir haben immer noch einige Probleme damit, wenn man den Greifhaken benutzt, dass sich der Fallschirm nicht öffnet (man muss erst den Wingsuit öffnen und dann zurück zum Fallschirm wechseln, damit jeder den Fallschirm sieht).
Checkpoints
Wir haben mit den Checkpoint-Funktionen für unsere Server seitige Scripting-API angefangen. Dies ist zwar noch in einer frühen in Entwicklungsphase, z.B. werden Checkpoints nur gezeigt, wenn das Spiel in einen "Rennmodus " gezwungen wird, aber wir haben beschlossen euch trotzdem einige Screenshots zu zeigen, die wir währen dem testen aufgenommen haben.
Greifhaken
Neben der Arbeit an den Checkpoints, haben wir auch damit begonnen den Enterhaken genauer zu untersuchen. Bis jetzt, verwenden wir die gesammelten Daten noch nicht für die Synchronisation, weil wir erst dinge wie den Fallschirm / Wingsuit abschließen möchten, aber wir haben schon angefangen ein paar coole Sachen zu machen, wie das Ändern der Farbe die durch die haken ausgestrahlt wird. Bereitet euch darauf vor, dass als Scripting Funktion in den nächsten Wochen zu sehen.
Crashfixes
In dieser Woche haben wir uns auch sehr auf die Fehlerbehebung von Spiel abstürzen konzentriert.
Einige Abstürze beim Trennen und respawnen haben wir in den Testsitzungen dieser Woche gefunden und behoben. Außerdem haben wir ein Problem, bei dem die Position von Objekten nur aktualisiert wurde wenn der Spieler sie berührt behoben.
Wir haben unseren Launcher aufgeräumt und einen bug behoben der auftritt, wenn man die Einstellungen des Spielverzeichnisses zu ersten mal setzt oder ändert. Auch die steam überprüfungen (um zu überprüfen, ob Steam ausgeführt wird) wurden erst einmal entfernt, da die Umsetzung unter bestimmten Umständen gescheitert ist. Dies wird in einem späteren Punkt der Entwicklung neu geschrieben und hinzugefügt werden.
Weitere Änderungen
Wenn das Hauptmenü geöffnet wird, wird das Spiel nicht mehr pausiert, was das Ausnutzen mancher Leute verhindern sollte, die das Spiel pausieren um verhindern zu wollen, dass sie zum Beispiel von einem anderen Spielern erschossen werden.
Last but not least haben wir den Standard JC3 crashreporter deaktiviert, damit nicht nur die nanos JC3:MP Abstürze an Avalanche gesendet werden (welche sie nicht in der Lage sind, zu reproduzieren oder zu fixen ), aber auch um Abstürze zu debuggen die direkt während der Entwicklung geschehen.
Also, das ist es für diese Woche. Wir hoffen, dass euch der Development Blog gefallen hat.
Bis zum nächsten Sonntag!
Beiträge von dennismitzwein
-
-
Bei den vollwertigen Servern handelt es sich um 50 Slots und mehr.
Wer braucht denn einen 50 Slot Testserver für 1-2 Tage?
Testserver haben dann nur 1-3 Slots maximal.
Reicht doch. Möglichkeit B ist deutlich sinnvoller.
-
Inwiefern stellst du dir eine Einschränkung bei Testservern vor?
Ich würde Möglichkeit b.) je nach Einschränkung bevorzugen, einfach weil es mir beim Testen total auf die Nerven gehen würde, wenn ich ständig den Testserver neu beantragen müsste.
-
Weil die Bestrafung umso heftiger ist. Wir werden uns steigern!
Würde bei jeder Toastbrotchallenge einfach sagen "bei 50.000 Likes gibt es ein Video von der Bestrafung" und dann läuft das.
Schlage als Bestrafung einen Kampf mit einem Wildschwein vor. Das wäre mal was anderes.
-
Ich hätte mich nicht an die Toastbrotchallenge getraut. Respekt!
Was hebt euren Kanal eigentlich genau von den anderen 26272747472718 Kanälen in dieser Richtung ab?
-
Der Blitzkrieg Mod macht das ganze Spiel etwas realistischer (gerade in Sachen Schaden und Flug der Projektile). Allerdings funktioniert das nicht in der Kampagne, d.h. man spielt im MP gegen Bots oder Freunde.
Die Mod funktioniert soweit ich weiß nur mit der New Steam Version. Btw: eine Blitzkrieg Mod für CoH 2 ist in Arbeit.
-
Ich spiele schon seit Ewigkeiten Company of Heroes mit dem Blitzkrieg Mod. Lohnt sich aufjedenfall damit gegen ein paar Freunde zu spielen.
-
Um was für Infos handelt es sich denn, wenn du nur Leute mit einer größeren Instagram Page suchst? Können die "kleinen Fische" da nicht mitreden?
-
Ich denke das ist kein großer Aufwand wenn man weiß wie man mit Photoshop umgeht.
Kommt auf die Beschaffenheit des Bildes an. Stell doch 1-2 Beispiele hier rein, damit man ungefähr abwägen kann wie aufwendig das Ganze ist. Zudem wäre eine genaue Anzahl von Bildern ganz nice zu wissen.
Würde es bei nicht allzu großem Aufwand machen.
-
Wenn es gute Preise zu gewinnen gibt, werden sicher auch Teams von außerhalb des Forums mitspielen wollen, was sowohl dem Turnier als auch dem Forum an sich zugute kommt. Daher wäre ich für Teams außerhalb des Forums.
-
Bei allem hast du recht. Aber wer sich einfach so offensichtlich an Dingen bedient, die nicht einem selbst gehören, hat es auch nicht anders verdient.
-
Habe ich nicht überlesen, wollts dennoch gesagt haben
-
Ja stimmt. Es ist Müll etwas zu kritisieren, was einfach völlig offensichtlich copy paste ist. Am Besten sollte man gar nichts mehr kritisieren. Interessiert ja eh keinen.
-
<link href="https://gta-mp.net/assets/style/bootstrap.css" rel="stylesheet">
<link href="https://gta-mp.net/assets/style/font-awesome.min.css" rel="stylesheet">
<link href="https://gta-mp.net/assets/style/jquery.jscrollpane.css" media="all" rel="stylesheet" type="text/css">
<link href="https://gta-mp.net/assets/style/main.css" rel="stylesheet">
<link href="https://gta-mp.net/assets/style/index.css" rel="stylesheet">
<link href="https://gta-mp.net/assets/style/vmp_essential.css" rel="stylesheet">cuz thei hev sweg and thei ar kaliti so fancy lel
Ernsthaft: entweder trollen die oder die sind tatsächlich total unseriös. Die haben sogar unseren Analytics Code drin.
-
"I'm pretty excited about these other mods! - You should be, but don't get your hopes up. Some mods are just out there to make money, and charge people for something as simple as owning a server. It's Okay to jump on a bandwagon!, but you should be careful. "
Ahja okay.
Trotzdem finde ich es sehr interessant was dort geschrieben wurde, vielleicht klappt es ja doch
Die können so viel privat entwickeln wie sie möchten, spätestens mit der ersten Welle an Aufmerksamkeit sind die genauso weg wie alle anderen.
-
Dieser Post ist eine Übersetzung meines Posts aus dem englischen Forum: https://community.nanos.io/ind…-communication-explained/
Hallo zukünftige nanos JC3:MP Serverbesitzer und Scripter!
Heute möchte ich mir die Zeit nehmen und euch erklären, wie die Kommunikation zwischen unterschiedlichen Packages, dem Client und der CEF-Integration funktioniert. Jedoch wird sich vermutlich bis zum ersten "richtigen Release" (sprich nicht STP1) noch einiges ändern, besonders in Bezug auf die Client <> CEF-Kommunikation.
Ich habe euch ein Diagramm gemalt, das den kompletten Kommunikationsfluss darstellt:
Das sieht zu erst vielleicht nach viel aus, ist es aber eigentlich gar nicht. Ich werde euch nun das Diagramm in kleineren Teilbereichen erklären.
Inter-Package Kommunikation
Bei der Inter-Package Kommunikation handelt es sich um den Informationsfluss zwischen mehreren verschiedenen Packages innerhalb einer Applikation, also Server Package <> Server Package oder Client Package <> Client Package.
Bei nJC3:MP wird dazu das selbstentwickelte Event-System verwendet:- events.Add(String name, Function handler) um auf ein bestimmtes Event zu reagieren
- events.Call(String name, args...) um ein Event mit den gegebenen Argumenten aufzurufen
Wie bereits erwaehnt erlauben diese beiden Funktionen nur einen Informationsfluss zwischen zwei Packages innerhalb der selben Anwendung. Das Event-System ist nicht an irgendeine Programmiersprache gebunden. Das Event System wird auch intern bei JC3:MP verwendet. Einige dieser Events werden auch an das Scripting weitergegeben:CodeClientConnected, ClientDisconnected, PlayerCreated, PlayerDestroyed, PlayerRespawn, PlayerDeath, ChatMessage, ChatCommand
Das sind jetzt nicht alle Events, aber das ist mal eine grobe Übersicht. Eine Liste mit allen Events wird soon(tm) auf das scripting-docs repo hochgeladen.
Kommunikation zwischen Server und Client
Ich hoffe ihr habt inzwischen das Event-System nicht komplett verdrängt. Wir werden es jetzt in leicht abgewandelter Form erneut betrachten:
Wir sehen, das Event-System wird erneut verwendet, nur mit anderen Funktionen:- Um auf ein vernetztes Event zu reagieren wird events.AddRemoteCallable(String name, Function handler) verwendet.
- Um vom Server aus ein Client-Event (was über oben genannte Funktion gehandhabt wird) aufzurufen, wird events.CallRemote(String name, Player target(null = an alle), args...) verwendet
- Um vom Client aus ein Remote-Event im Server aufzurufen wird events.CallRemote(String name, args...) verwendet.
Wie bereits gesagt kann mit CallRemote nur ein Event aufgerufen werden, das ueber AddRemoteCallable registriert wurde.
Kommunikation zwischen dem Server und CEF
Ha! Das geht nicht. Wer sich das Diagramm angeguckt hat wird gemerkt haben, dass diese Art von Kommunikation nicht möglich ist, das der Server keinen direkten Einfluss auf CEF haben soll. Das war eine bewusste Entscheidung bei der Entwicklung unseres Frameworks.
Kommunikation zwischen dem Client und CEF
Die derzeitige Kommunikation zwischen diesen beiden Komponenten ist wie erwähnt noch nicht zu 100% fertig und wird sich vermutlich noch ändern.- CEF kann from Client aus mit invokeCEF(String eventName, String data) aufgerufen werden.
- CEF kann auf eingehende Events mit addEventHandler(function(String eventName, String data) {}); reagieren.
- Client-Packages können von CEF aus mit invoke(String eventName, String data) aufgerufen werden.
- Das Client-Package kann eingehende Events von CEF über events.Add('CEFCommand', function(String eventName, String data) {}); handhaben.
Derzeit ist es nur möglich, Strings umherzuschicken. Der interne workaround für das ist derzeit, einfach alles mit JSON.stringify zu encoden und anschliessend auf der anderen Seite JSON.parse zu verwenden.
Zeit für Beispiele!
Ich habe für jedes der genannten Szenarios (+ ein Beispiel für Server <> Client <> CEF) Beispiele erstellt. Ihr könnt sie hier bewundern: jc3mp/communication-explained
Das jc3mp/server-default-package und jc3mp/client-default-package zeigen auch ein funktionierendes Beispiel der Kommunikation zum Linksklick-Spawnen von Objekten.
Fragen?
Antworten kriegst du so schnell wie moeglich hier im Thema. -
Schade, das Finale am Ende wäre ein netter Abschluss geworden.
-
Wieso zum Teufel findet das Finale eigentlich vor dem Spiel um Platz 3 statt? Soll das Finale nicht das abschließende Highlight sein?
Der Strem heute Abend wird aufgrund spontaner Ausfälle aller Voraussicht nach ausfallen.
Ach man
-
Ich bin der Meinung, dass die prozentualen Anteile nicht so weit auseinander liegen sollten, einfach um die Leistungen der anderen Teams gerecht zu würdigen. 60/30/10 ist da in meinen Augen eine vollkommen gerechte Verteilung.
-
Wenn du so denkst kannst du auch gleich 100/0/0 machen. Es ging mir nur um eine gerechtere Verteilung. Das Hauptaugenmerk bei der Gewinnverteilung soll zwar bei den Gewinnern liegen, aber dennoch sollten die anderen nicht zu kurz kommen; immerhin haben die auch ihre Leistungen gebracht und das sollte man an der Stelle auch würdigen.
Sprich das doch am Besten mit den Teams ab. Faire Spieler setzen sich ohnehin für eine gereche Verteilung ein.