Patch Notes ( v.1.0.1046.7 )
• Phoenix: Erkennung von erzwungenen InGame-Zuständen aufgrund der Discord WebHooks hinzugefügt
• Phoenix: AFK-Handling in InstantAction für die Anzeige auf der Website angepasst
• Phoenix: Verschiedene andere Verbesserungen für den Zuschauer-AFK-Modus vorgenommen
• BASE: Anpassung für verlassene jedoch bereits gestartete Karten vorgenommen ( Zuschauer zählen nicht mehr )
• BASE: Kleinere Anpassungen und Optimierungen
... Discord WebHooks
Mit einer der nächsten Builds werde ich die Möglichkeit für alle Serverbetreiber implementieren, Ereignisse durch die Definition von eigenen WebHooks, auf ihre eigenen Discord Server senden zu lassen. Für diese, initiale Version werden neu gestartete Runden mit Spielern direkt auf den CryServ.de Discord gesendet, so das man kein Spiel mehr verpasst 🙂.
... SSM nTEC 2.0
ermöglicht die unkomplizierte Nutzung aller in CryServ zusätzlich enthaltenen Features wie Fahrzeuge mit steuerbarer Tarnfunktion, anpassbare originale Kaufmenüs, platzierbare und optionierbare Geschütztürme, das am Untergrund perfekt ausgerichtete platzieren von Items, Fahrzeugen und Objekten sowie das jederzeit nachträgle repositionieren von diesen, ein Intelli-Reload System das nur Dateien lädt die geändert wurden. Es nutzt jede, der inzwischen 200 C++ API Erweiterungen die die Phoenix Dll zu bieten hat.
Anders als nTEC 1.0 ist es nun weniger eine Zwischenlösung sondern das mit Abstand modernste und Funktionsreichte SSM das für Crysis Wars jemals publiziert wurde, zudem dürfte es wie ich befürchte auch den Funktionsumfang der meisten privaten SSM Versionen etwas überragen ( nur so eine Ahnung 🙄😋🤐 ).
Bei entsprechendem Interesse, werde ich nächstes Jahr eine weitere Version erstellen, nTEC 3.0. Angemerkt: Nichts von nTEC 1.0 ist kompatibel mit nTEC 2.0 da sich der komplette Aufbau, Funktionsnamen, Variablen sowie die Funktionsweise im generellen geändert hat.
Nur eine Anpassung in diesem Update und auch nur, weil darum gebeten wurde, die Anzeige optional zu machen. Insofern kein Handlungsbedarf entstehen sollte, war dies das letzte DLL-Update für eine Weile.
Mit Hilfe der ersten Funktion ist es möglich, Objekte, Fahrzeuge sowie Items und so weiter, perfekt auf den Untergrund ausgerichtet zu spawnen, alle weiteren Informationen dazu finden sich in der C++ API Dokumentation. Die zweite gibt den aktuellen Profilnamen des Spielers zurück, unabhängig von den auf dem Server vorgenommenen Änderungen. Die beiden danach folgenden Punkte waren bisher nur für nTEC verfügbar und sind es nun für alle.
Die Patch Notes des neuen CryServ-Client werden am Wochenende folgen, da die Änderungen mit 171 nennenswerten Punkten diesmal sehr umfangreich ausgefallen sind, sollte ich diese demnach zunächst etwas zusammenfassen und kürzen ( Normal übernehme ich diese direkt ).
Als Vorabinformation: Die Funktion zum Taggen von Spielern, sowie der Code für das Radar, die Kartenansicht, die MiniMap ( Atomwaffensymbol ), der Marker für Explosives sowie die Anzeigetafel wurden fast komplett ersetzt. Die sporadischen Abstürze beim Wechsel zwischen Spielmodis ( vor allem zu PowerStruggle ) oder Servern ( Original Fehler ) wurden behoben, zudem wurden einige kritischere, original, Code-Teile geändert, das Radar sowie die Kartenansicht können nicht mehr missbraucht werden ... und wirklich viel, viel mehr 🙂.
Weitere Informationen und Videos wie immer auf Discord.
» Verfügbar ab dem 17.08.2022.
Patch Notes ( v.2.0.1046.0 )
• Die Anzeigetexte des Fadenkreuzes wurden für die Klassen Nachtsichtgerät, Fallschirm und Fernglas erweitert
• Inventar Beschränkung für die Klassen Nachtsichtgerät, Fallschirm und Fernglas angepasst ( Fehler im Originalspiel )
• Fehlende Lokalisierung für das Nachtsichtgerät hinzugefügt ( Fehler im Originalspiel )
• Die maximale Reichweite, die ein Spieler C4 werfen kann, wurde im Stärkemodus erhöht
• Das Werfen im Stärkemodus von Explosiven erfordert nun ein Minimum an Energie und verbraucht ebenfalls Energie
• Geschütztürme werden nicht mehr im Fernglas markiert, da ohnehin keine Anzeige im Radar erfolgt ( Fehler im Originalspiel )
• Fehlendes oder falsches Objekt beim Nachtsichtgerät, Fallschirm und Fernglas behoben ( Fehler im Originalspiel )
• Position des Fernzünders in der Hand in der 3'th Personen-Ansicht korrigert ( danke an Alex626, Fehler im Originalspiel )
• Kleinere Anpassungen und Optimierungen
Die Überarbeitung des Fadenkreuzes ist mit dieser Version abgeschlossen. Spieler können nun direkt und einheitlich bei allen Gegenständen sehen, ob sie diese bereits in ihrem Inventar haben, ob sie Munition oder sonstiges aufnehmen können. Außerdem wurde der Fehler behoben, dass Spieler bestimmte Gegenstände, unendlich oft aufheben oder erhalten konnten ohne diese tatsächlich zu erhalten ( Fehler im Originalspiel ).
... C4 Wurfweite
Enthält zusätzlich ein Sound- und Energiemanagement, so dass sich dieses Feature perfekt in die bestehenden Originalsysteme einfügt 🙂. Der Sound passt sich an die Wurfweite an, mit dem neuen Standardwert ist dieser nur leise zu hören. Erhöht man den Wert, wird dieser lauter und länger abgespielt, passend zu den anderen Funktionen der Nanosuit. Außerdem wird abhängig von der Wurfweite, die der Server eingestellt hat, Energie für die Aktion abgezogen. Ist die Nanosuit deaktiviert oder hat er zu wenig Energie, erfolgt der Wurf mit dem Standardwert.
» Verfügbar ab dem 17.07.2022.
Patch Notes ( v.1.0.1045.0 )
• Phoenix: Inventar Beschränkung für die Klassen Nachtsichtgerät, Fallschirm und Fernglas angepasst ( Fehler im Originalspiel )
• Phoenix: Fehlendes oder falsches Objekt beim Nachtsichtgerät, Fallschirm und Fernglas behoben ( Fehler im Originalspiel )
• Phoenix: Das Nachtsichtgerät, der Fallschirm sowie das Fernglas können nun normal gespawnt und genutzt werden
• Phoenix: CVar "g_c4ThrowRangeMultStrengthMode" hinzugefügt - Definiert die maximale Wurfweite von C4
• Phoenix: Vereinheitlichung einiger unnötiger doppelter CVars für Single- und Multiplayer
• Phoenix: Versionsnummer auf 1.0.1045 erhöht
• Phoenix: Phoenix.pak aktualisiert
• Phoenix: Server.cfg Dateien aktualisiert
• Kleinere Anpassungen und Optimierungen
• Phoenix: C++ API Dokumentation angepasst
» Verfügbar ab dem 17.07.2022.
Patch Notes ( v.2.0.1045.0 )
• Die Anzeigetexte für Gegenstände wurden überarbeitet, Spieler sehen nun sofort, was sie bereits im Inventar haben
• Unterstützung für zusätzliche aufnehmbare Munition für den Raketenwerfer hinzugefügt
• Mehrere Fehler im automatischen Zielerfassungssystem behoben ( Fehler im Originalspiel )
• Fehler im Zoom-Modus des TAC-Launcher behoben ( Zielfadenkreuz war dort nicht vorhanden, Fehler im Originalspiel )
• Zoom-Modus des TAC-Launchers reaktiviert
• Kleinere Anpassungen und Optimierungen
» Verfügbar ab dem 02.07.2022.
Patch Notes ( v.1.0.1044.0 )
• Phoenix: CVar "g_rocketLauncherAutoDrop" hinzugefügt - Fallen lassen des Raketenwerfers, wenn Munition aufgebraucht ist
• Phoenix: CVar "g_rocketLauncherCapacityLimit" hinzugefügt - Maximale Munitionskapazität des Raketenwerfers
• Phoenix: CVar "g_rocketLauncherAmmoCount" hinzugefügt - Standardmunitionsmenge des Raketenwerfers
• Phoenix: CVar "g_autoAimRocketLauncher" umbenannt zu "g_rocketLauncherAutoAim" - Harmonisierung der Benennung
• Phoenix: Versionsnummer auf 1.0.1044 erhöht
• Phoenix: Kleinere Anpassungen und Optimierungen
• Phoenix: Server.cfg Dateien aktualisiert
• Phoenix: C++ API Dokumentation angepasst
» Verfügbar ab dem 02.07.2022.
Patch Notes ( v.2.0.1044.0 )
• Es ist nun möglich, Fahrzeuge des anderen Teams zu reparieren ( unsinnige Abfragen für etwas was eigentlich niemand tut )
• Es ist nun möglich, Geschütztürme mit dem "LockpickKit" zu hacken
• Es ist nun möglich, Geschütztürme mit EMP-Angriffen vorübergehend zu deaktivieren
• Geschütztürme geben nun Statustöne von sich, wenn sie repariert oder gehackt wurden ( insofern sie nicht deaktivert wurden )
• Beschädigte Geschütztürme können nun wie ursprünglich vorgesehen repariert werden ( Fehler im Originalspiel )
• Reparierte Geschütztürme werden nun visuell korrekt angezeigt ( Fehler im Originalspiel )
• Geschütztürme funktionieren jetzt nach einer Reparatur vollständig und wie vorgesehen ( Fehler im Originalspiel )
• Soundfehler bei Geschütztürmen behoben ( Fehler im Originalspiel )
• Geschütztürme können nun durch automatische Zielsuchsysteme erfasst werden ( zum Beispiel vom Raketenwerfer )
• Unterstützung für teambezogene SpawnPoint's in TeamAction hinzugefügt ( SpawnPoint's mit zugewiesenen TeamIds )
• Explosives kann nicht mehr mit einem "RepairKit" entschärft werden, sondern nur noch mit einem "LockpickKit"
• SPARC Schadenswert von 400 auf 250 pro Schuss reduziert
• Kleinere Anpassungen und Optimierungen
... Geschütztürme
Die Geschütztürme wurden um einige zusätzliche Möglichkeiten erweitert, sie funktionieren nun in allen Spielmodi und können dort auch nachträglich durch ein SSM ergänzt werden. Es ist nun möglich, sie wie ursprünglich vorgesehen zu reparieren, wenn sie beschädigt oder auch komplett zerstört wurden. Wenn keine manuelle Reparatur erfolgt, wird diese nach der eingestellten Zeit automatisch durchgeführt.
Außerdem ist es möglich, Geschütztürme zu hacken, in PowerStruggle und TeamAction greifen diese dann das, jeweils andere Team für eine begrenzte Zeit an. In InstantAction hingegen kann man sie nur für einen längeren Zeitraum stilllegen. Zusätzlich ist es möglich, sie durch einen EMP-Angriff kurzzeitig zu deaktivieren - diese Möglichkeit entgegnet dem Hacking-Gameplay, da man einen auf diese Weise deaktivierten Geschützturm immer noch hacken kann. Es ist jederzeit möglich, den Geschützturm erneut zu hacken, um den vorherigen Zustand wiederherzustellen. Wenn ein Geschützturm komplett zerstört wurde, funktioniert er nach der Reparatur natürlich wieder einwandfrei. Weitere Informationen zu diesem Thema in Discord.
Alle hier genannten Funktionen erfordern eine entsprechende Konfiguration auf der Serverseite, um genutzt werden zu können!
... Entschärfung von Explosiven
Ein "RepairKit" sollte eigentlich nur in der Lage sein, Dinge zu reparieren, während das "LockpickKit" im Spiel bereits dafür vorgesehen ist, eine Sicherheitsvorrichtung zu überwinden, indem man sich damit Zugang zu gegnerische Fahrzeuge verschaffen kann. Es ist daher nur logisch, dieses Tool auch für das Entschärfen von Explosiven sowie für das neu hinzugekommene Hacking-Gameplay zu verwenden. Diese Änderung verleiht dem "LockpickKit" auch ein wenig mehr Bedeutung.
» Verfügbar ab dem 25.06.2022.
Patch Notes ( v.1.0.1043.0 )
• Phoenix: C++ API Funktion "g_gameRules.game:DefinedSpawnLocations()" hinzugefügt
• Phoenix: C++ API Funktion "entity.item:IsGunTurret()" hinzugefügt
• Phoenix: C++ API Funktion "entity.item:IsHackable()" hinzugefügt
• Phoenix: C++ API Funktion "entity.item:IsRepairable()" hinzugefügt
• Phoenix: C++ API Funktion "entity.item:OnHacked()" hinzugefügt
• Phoenix: C++ API Funktion "entity.item:SetOperationDefaults(vehiclesOnly,airVehiclesOnly,searchOnly,surveillance)" hinzugefügt
• Phoenix: C++ API Funktion "entity.item:SetRangeLimits(mg,rocket,tac)" hinzugefügt
• Phoenix: C++ API Funktion "entity.item:GetTeamId()" hinzugefügt
• Phoenix: C++ API Funktion "entity.item:SetTeamId(teamId)" hinzugefügt
• Phoenix: C++ API Funktion "entity.item:Activate(enable)" hinzugefügt
• Phoenix: CVar "g_gunTurretActiveWithoutFaction" hinzugefügt - Ob Geschütztürme ohne Teamzuweisung aktiv sein sollen
• Phoenix: CVar "g_gunTurretFindCloaked" hinzugefügt - Ob Geschütztürme auf getarnte Spieler, Fahrzeuge reagieren
• Phoenix: CVar "g_gunTurretAimTACShells" hinzugefügt - Ob Geschütztürme auf TAC Beschuss reagieren
• Phoenix: CVar "g_gunTurretTACShellsDetectionDelay" hinzugefügt - Verzögerung bis zur Reaktion
• Phoenix: CVar "g_gunTurretMaxHealth" hinzugefügt - Gun Turret Lebenspunkte
• Phoenix: CVar "g_gunTurretRepairDelay" hinzugefügt - Verzögerung bis zur automatischen Reparatur
• Phoenix: CVar "g_gunTurretEMPDowntime" hinzugefügt - Ausfallzeit nach einem EMP-Angriff auf einen Geschützturm
• Phoenix: CVar "g_gunTurretHackedResetDelay" hinzugefügt - Verzögerung, bis ein gehackter Geschützturm zurückgesetzt wird
• Phoenix: Fehler behoben, der verursachte, dass Geschütztürme nicht serverseitig gespawnt und konfiguriert werden konnten
• Phoenix: Fehler behoben, der verursachte, dass Geschütztürme nicht repariert werden konnten
• Phoenix: Fehler behoben, der verursachte, dass Geschütztürme nach der Reparatur nicht korrekt funktionierten
• Phoenix: Hacking-Gameplay hinzugefügt, Geschütztürme können nun mit dem "LockpickKit" gehackt werden
• Phoenix: Explosives kann nicht mehr mit einem "RepairKit" sondern nur noch mit einem "LockpickKit" entschärft werden
• Phoenix: Unterstützung für teambezogene SpawnPoint's in TeamAction hinzugefügt ( SpawnPoint's mit zugewiesenen TeamIds )
• Phoenix: Es ist nun möglich, Fahrzeuge des anderen Teams zu reparieren
• Phoenix: SPARC Schadenswert von 400 auf 250 pro Schuss reduziert
• Phoenix: Versionsnummer auf 1.0.1043 erhöht
• Phoenix: Kleinere Anpassungen und Optimierungen
• Phoenix: Phoenix.pak aktualisiert
• Phoenix: Server.cfg Dateien aktualisiert
• Phoenix: C++ API Dokumentation angepasst
Fast alles, was hinzugefügt wurde, ist über CVars konfigurierbar und kann demnach auch unabhängig von einem SSM, zum Beispiel in Vanilla verwendet werden. Die Standardwerte sind in C++ so vorkonfiguriert, dass keine der zusätzlichen Funktionen standardmäßig aktiv ist. Wie immer können die erweiterten Features genutzt werden - müssen es aber nicht. Weitere Informationen über das Update sind wie üblich in Discord zu finden.
» Verfügbar ab dem 25.06.2022.
Patch Notes ( v.2.0.1043.1 )
• Kleinere Anpassungen und Optimierungen
Die Vorteile der neuen Handhabung sind, dass Spieler mehr Energie für Tricksprünge übrig haben und auch impulsbasierte Mods können nun mit gutem Gewissen genutzt werden, ohne dass durch diese Frust entsteht.
» Der neue Spiel-Client ist jetzt zum Download verfügbar.
Patch Notes ( v.1.0.1042.1 )
• Phoenix: Kleinere Anpassungen und Optimierungen
Einleitung
Das vorgestellte Projekt nahm bereits 2011 seinen Anfang, damals noch in einer reinen Lua Umsetzung mit vielen Kompromissen und zum Teil nur als umständlich zu bezeichneten Lösungswegen. Aber nun zu dieser Version 🙂 ...
Ziel dieser Idee war es, Fahrzeuge wie die Nanosuit selbst mit einer steuerbaren Tarnfunktion ausstatten zu können. Ob nun für strategische Spielzüge, als Überraschungseffekt oder einfach nur der Coolness wegen es tun zu können. Diese sollte sich möglichst natürlich in den bestehenden Spielverlauf einfügen und vielleicht sogar noch weitere Vorteile mit sich bringen ohne dabei jedoch unfair zu werden oder wirken.
Grundfunktionen
Die Implementierung der eigentlichen Funktion hat komplett in C++ auf der Client- sowie Serverseite stattgefunden. Um den Nutzern/Moddern dennoch verschiedene Anwendungsszenarien zu ermöglichen, wurden C++ Lua-API Funktionen hinzugefügt mit der die Steuerung dessen vorgenommen werden kann. Ich habe mich bei der Umsetzung an dem Verhalten der Nanosuit selbst orientiert, diese Vereinheitlichung ist transparenter für Spieler und beinhaltet zudem, bereits pragmatische Lösungen.
Ist ein Fahrzeug mit einer Tarnfunktion ausgestattet so koppelt sich diese mit der Nanosuit des Fahrers und kann dann so durch diesen gesteuert werden. Sollte ein Schuss im getarnten Zustand abgegeben oder das Fahrzeug zerstört werden, wird die Tarnung sofort deaktiviert. Die Funktion ist Energieabhängig, der Verbrauch dieser kann differenziert über ein CVars konfiguriert werden, die Anzeige dessen findet über die Energieanzeige der Nanosuit statt.
Im getarnten Zustand ist es zusätzlich zu den Radareinschränkungen, nicht möglich das Fahrzeug mit einer automatischen Zielerfassung aufzuschalten - Geschütztürme wurden dabei jedoch aus strategischen Gründen nicht berücksichtigt. Fahrzeuge mit einer Tarnvorrichtung spawnen immer im getarnten Zustand, was das finden solcher, zuweilen erschweren kann.
Einsatzmöglichkeiten
Die hier beschriebene Verwendung entspricht meiner eigenen Integration in SSM iTEC sowie nTEC 2.0, diese kann sich durchaus von der in anderen SSM-Versionen unterscheiden und ist demnach nicht festgelegt.
Es ist möglich einen in der Konfiguration festgelegten Prozentsatz an Fahrzeugen mit einer Tarnfunktion auszurüsten, diese Fahrzeuge werden zufällig ausgewählt und unterscheiden sich normalerweise jede Runde. Weiterhin können über den Chat-Befehl /vehicle Fahrzeuge direkt mit einer solchen gespawnt und diese auch dauerhaft einer Karte über das LevelSetup-System hinzugefügt werden. Zudem gibt es einen Chat-Befehl um ein Fahrzeug nachträglich mit einer Tarnvorrichtung auszustatten oder eine solche aus diesem zu entfernen.
Genutzte C++ Lua-API Funktionen
➔ g_gameRules.game:HasVehicleCloakingDevice( vehicleId )
➔ g_gameRules.game:IsVehicleCloakingDeviceActivated( vehicleId )
➔ g_gameRules.game:IsVehicleCloakingDeviceOwner( vehicleId, playerId )
➔ g_gameRules.game:SetVehicleCloakingDeviceOwner( vehicleId, playerId )
➔ g_gameRules.game:DestroyVehicleCloakingDevice( vehicleId, removeDevice )
➔ g_gameRules.game:UpdateVehicleCloakingDevice( vehicleId, enable )
➔ CVar: g_vehicleCloakEnergyDrainAdjuster < float value >
Entwicklungszeit
Von den ersten Tests bis bis zur Fertigstellung der C++ Grundfunktionen vergingen etwa 30 Stunden. Es gab einige Tücken bei der Implementierung die verschiedene Lösungsansätze erforderten, bis sich schließlich eine Lösung fand, die frei von allen Anfälligkeiten war. Die Lua Integration hingegen, war unproblematisch und in etwa zwei Stunden erledigt.
Einleitung
Das hier vorgestellte Projekt ist Teil des LevelSetup-Systems von SSM iTEC. Da dieses System in iTEC sehr weitreichend ausgebaut/ entwickelt ist und bereits ein breites Spektrum an Änderungen an Karten ermöglicht, war es eine passende und zudem sehr pragmatische Ergänzung zu dem bestehenden. Kurzum ich wollte diese Möglichkeit einfach mit implementiert haben 🙂.
Funktion
Es können vorgefertigte Gruppen direkt aus der Sandbox2 importiert werden, entweder statisch, einer spezifizierten Karte zugewiesen oder aber dynamisch, überall und auf jeder Karte spawnbar. Es ist möglich eigene Prefabs im Spiel zu erstellen ( temporär für Vervielfältigungsprozesse oder dauerhaft ), bestehende zu entpacken oder zu erweitern, sowie die Skalierung, die Position und auch Rotation beliebig und jederzeit nachträglich anzupassen.
Die Prefabs können wie Objekte mittels des zusätzlich in CryServ implementierten Silhouetten-Systems ( Die beiden original enthaltenen sind dafür ungeeignet ) für eine Identifizierung kenntlich gemacht werden. Es ist möglich diese ( wie alles andere in iTEC ) automatisch anhand des Untergrundes passend ausrichten zu lassen ( Snap 2 Group ). Es können zusätzlich alle im Spiel vorhandenen original Prefabs verwendet werden, wenn man diese importiert. Durch das eigene und optimierte Spawnsystem für Entities, war es im Belastungstest möglich, annähernd 10.000 Einträge ohne einen einzigen Ruckler oder Lagg zu spawnen.
Einsatzmöglichkeiten
Als mögliche Einsatzszenarien wurde eine möglichst einfache und pragmatische Erweiterung sowie Modifikation bestehender Karten sowie die durch das statische System mögliche, Erschwerung einer ungewollten Kartennutzung durch Dritte herangezogen ( auf einer so angepassten Karte befindet sich in der Download-Version für Spieler nicht viel mehr als das Terrain und die ToD ).
Genutzte C++ Lua-API Funktionen ( nur zusätzliche Funktionen )
➔ g_gameRules.game:GetWorldPos( posLocal, posGlobal, anglesGlobal, scaleGlobal )
➔ g_gameRules.game:GetWorldAngles( anglesLocal, anglesGlobal )
➔ g_gameRules.game:GetWorldScale( vectorLocal, scaleGlobal )
➔ g_gameRules.game:IsAnglesEquivalent( angles, comparative )
➔ g_gameRules.game:SpawnEntity( params )
➔ g_gameRules.game:MoveEntity( entityId, pos, angles )
➔ g_gameRules.game:IntegrateCustomObject( entityId )
➔ g_gameRules.game:EntitySilhouette( entityId, color )
➔ g_gameRules.game:GetGroupData( file )
➔ g_gameRules.game:GetLevelSpecificGroupData( file )
Entwicklungszeit
Von den ersten Tests bis bis zu den Grundfunktionen vergingen etwa 30 Stunden, die ganzen Feinheiten jedoch und nötigen Änderungen die dieses System nach sich zog, bis hin zur abschließenden Optimierung und dem letzten Schliff forderten nochmals etwa 90 Stunden, also aufsummiert etwa 120 Stunden insgesamt. Allerdings konnte ich auf einige Funktionen zurückgreifen die bereits Teil des SSM sind, andernfalls wären es sicher noch einige Stunden mehr geworden.
Einleitung
Das vorgestellte Projekt ist ein Plugin für das SSM iTEC. Ziel dieser Idee war es, in jeder Karte eine frei platzierbare Plattform spawnen zu können, die dem was man unter einem richtigen Portal verstehen würde, so nah wie möglich kommt.
Auch sollten all die Konflikte die Teleportation im Spielgeschehen verursacht mit diesem Projekt beseitigt werden, Probleme wie das Spieler sich an Ort und Stelle dem Kampfgeschehen entziehen können, die fehlende Möglichkeit das ihnen ihr Gegenüber folgen kann oder das man in einer Gruppe nicht gemeinsam ans gleiche Ziel gelangen kann auf eine sich in den Spielverlauf integrierende Weise.
Funktion
Jeder beliebigen Karte können dauerhaft Portale hinzugefügt werden. Diese teleportieren beim betreten, einen oder auch mehrere Spieler gleichzeitig zu dem konfigurierten Zielportal ( Das letzte Ziel wird immer 10 Sekunden nach der jeweils letzten Teleportation erhalten, so das andere Spieler ans gleiche Ziel gelangen können, sollten sie folgen wollen ). Das Ziel kann dabei zufällig oder vorgegeben sein, zudem ist es möglich Ankunftsbedingungen zu definieren.
Einsatzmöglichkeiten
Als mögliche Einsatzszenarien wurde ( natürlich ) die allgemeine Überwindung von größeren Distanzen und somit die Möglichkeit größere Karten auch für kleinere Spielgruppen attraktiver zu machen sowie der Ersatz für die direkte Teleportation zurück in die Hauptquartiere, mit dem sonst üblichen Chat-Kommando "/base" in Power-Struggle Spielen, herangezogen.
Features
➔ Prüfung der Abmessungen beim spawnen ob es überhaupt an der Stelle platziert werden kann
➔ Prüfung auf mögliche zusätzlich störende Faktoren beim Spawnen wie Spawnpunkte, Spieler, Fahrzeuge
➔ Prüfung des Neigungswinkels des Untergrundes beim spawnen ( um eine korrekte Funktion zu gewährleisten )
➔ Automatische Ausrichtung, Anpassung an den Boden ( Snap 2 Ground )
➔ Jederzeit nachträgliche Änderung der X, Y, Z -Achse sowie Rotation eines Portals
➔ Es können mehrere Achsen gleichzeitig geändert werden ( 1-4 Variablen möglich )
➔ Automatische Begradigung eines Portals wenn es schwebend platziert wird
➔ Es können verschiedene Anreisekonditionen gesetzt werden ( Prestige Points, Teambezogen )
➔ Jederzeit nachträgliche Anpassung der Anreisekonditionen sowie Verlinkungen
➔ Automatische Verlinkung paarweise als Standardkonfiguration
➔ Die Portale können beliebig miteinander verlinkt oder nur als Ankunftsplattform genutzt werden
➔ Alle Ereignissounds sind in unmittelbarer Nähe in einer der Distanz entsprechenden Lautstärke zu hören
➔ Alle Entitätstypen werden unterstützt ( Players, Grunts, Items usw., außer Fahrzeuge, wegen ihrer Größe )
➔ Erhaltung des letzten Bestimmungsortes für 10 Sekunden jeweils nach der letzten Abreise ( Speichermodus )
➔ Die Abreisehöhe ist bei kleinen Entities auch die Ankunftshöhe ( Items als Beispiel )
➔ Sowohl die Effektgröße als auch die Position werden immer an die jeweilige Entität angepasst
➔ Fünf mögliche Ankunftspunkte die auf mögliche Störfaktoren im Vorfeld überprüft werden
➔ Verteidigungssystem gegen eine Blockierung mit Fahrzeugen
➔ Unproblematischer Betrieb auch mit hohen Geschwindigkeiten also im Speed-Modus oder freien Fall
➔ Informationssystem für Spieler falls keine Verlinkung also Ziel hinterlegt ist
➔ Anzeige der eingestellten Werte beim Betreten eines Portals im Geschützten Modus
➔ Auflistungsmöglichkeit aller auf einer Karte platzierten Portale inkl. ihrer jeweiligen Konfiguration
➔ Die Datenbank unterstützt das Intelli-Reload System des SSM
➔ Visuelle Integration in eine Karte durch Angleichung an die Umgebung ( Gefroren, Nass, … )
➔ Optimierte Funktionsweise, keine unnötige oder umständliche Berechnung, Generierung von Tables und so weiter …
Genutzte C++ Lua-API Funktionen ( nur zusätzliche oder angepasste Funktionen )
➔ g_gameRules.game:GetCurrentLevel()
➔ g_gameRules.game:PurgeAreaOfClaymores( position, radius, teamId )
➔ g_gameRules.game:SoundEvent( entityId, sound, radius=100, volume=10 )
➔ g_gameRules.game:MoveEntity( entityId, pos, angles )
➔ g_gameRules.game:MovePlayer( playerId, pos, angles )
➔ g_gameRules.game:AnglesToVectors( angles )
➔ g_gameRules.game:GetWorldAngles( anglesLocal, anglesGlobal )
➔ g_gameRules.game:IntegrateCustomObject( entityId )
➔ g_gameRules.game:SpawnEntity( params )
Entwicklungszeit
Von den ersten Tests bis zur abschließenden Optimierung und dem letzten Schliff vergingen etwa 35 Stunden. Allerdings konnte ich auf einige Funktionen zurückgreifen die bereits Teil des SSM sind, andernfalls wären es einige Stunden mehr geworden.
Ergänzend
Das ursprüngliche Design des Portals besteht aus mehreren Originalobjekten und wurde als Prefab gespawnt. Dj Copniker hat freundlicherweise ein passendes und optimiertes Objekt für dieses Projekt erstellt. Vielen Dank für diese Unterstützung an ihn 🙂.
Patch Notes ( v.2.0.1041.2 )
• Die kürzlich hinzugefügten Chat- und Third-Person- Funktionen in den PDF Dokumentation erläutert
• PDF Dokumentation allgemein überarbeitet
• Kleinere Anpassungen und Optimierungen
Ich werde die PDF-Anleitung für den Client in den nächsten Tagen anpassen, so dass die vor kurzem hinzugekommenen, zusätzlichen Chat-Funktionen sowie diese Steuerungsmöglichkeiten für den Third-Person-Modus auch darin erklärt werden.
» Der neue Spiel-Client ist jetzt zum Download verfügbar.
Patch Notes ( v.1.0.1041.1 )
• Phoenix: Geänderte Handhabe bei einem Versuch der Umgehung des Masterservers
• BASE: Vordefinierte Anticheat-Ausnahmen für Karten um zwei Einträge erweitert
Einleitung
Das vorgestellte Projekt ist ein Plugin für das SSM iTEC. Ziel dieser Idee war es, in jeder Karte eine frei platzierbare Plattform spawnen zu können, bei der sowohl die Impulsstärke als auch der Impulse-Neigungswinkel eingestellt werden kann.
Funktion
Jeder beliebigen Karte können dauerhaft Impulse-Pads hinzugefügt werden, die einen Spieler wenn er diese betritt, mittels eines physikalischen Impulses in die jeweils konfigurierte Richtung mit der konfigurierten Stärke beschleunigt.
Einsatzmöglichkeiten
Als mögliche Einsatzszenarien wurden die Überwindung von Abgründen, Höhenunterschieden oder einfach nur der Spaß am Sprung selbst betrachtet.
Features
➔ Prüfung der Abmessungen beim spawnen ob es überhaupt an der Stelle platziert werden kann
➔ Prüfung auf mögliche zusätzlich störende Faktoren beim Spawnen wie Spawnpunkte, Spieler, Fahrzeuge
➔ Prüfung des Neigungswinkels des Untergrundes beim spawnen ( um eine korrekte Funktion zu gewährleisten )
➔ Automatische Ausrichtung, Anpassung an den Boden ( Snap 2 Ground )
➔ Jederzeit nachträgliche Änderung der X, Y, Z -Achse sowie Rotation eines Impulse-Pads
➔ Es können mehrere Achsen gleichzeitig geändert werden ( 1-4 Variablen möglich )
➔ Jederzeit nachträgliche Anpassung der Impulsstärke sowie des Impuls-Neigungswinkels
➔ Visuell animierte Veranschaulichtung des eingestellten Impulse-Neigungswinkel
➔ Erkennung der Begehungsrichtung und somit kein fehlerhaftes auslösen
➔ Akustisches Feedback bei falscher Begehungsrichtung
➔ Alle Ereignissounds sind in unmittelbarer Nähe in einer der Distanz entsprechenden Lautstärke zu hören
➔ Alle Entitätstypen werden unterstützt ( Players, Grunts, Items usw., außer Fahrzeuge, wegen ihrer Größe )
➔ Unproblematischer Betrieb auch mit hohen Geschwindigkeiten also im Speed-Modus der Nanosuit
➔ Informationssystem für Spieler falls keine Konfiguration erfolgte ( Außer Betrieb )
➔ Anzeige der eingestellten Werte beim Betreten eines Impulse-Pads im Geschützten Modus
➔ Auflistungsmöglichkeit aller auf einer Karte platzierten Impulse-Pads inkl. ihrer jeweiligen Konfiguration
➔ Die Datenbank unterstützt das Intelli-Reload System des SSM
➔ Die maximal erzielte Reichweite mit einen konfigurierten Impuls ist immer für alle Entitäten gleich
➔ Visuelle Integration in eine Karte durch Angleichung an die Umgebung ( Gefroren, Nass, … )
➔ Optimierte Funktionsweise, keine unnötige oder umständliche Berechnung, Generierung von Tables und so weiter …
Genutzte C++ Lua-API Funktionen ( nur zusätzliche Funktionen )
➔ g_gameRules.game:GetCurrentLevel()
➔ g_gameRules.game:AddImpulse( playerId, direction, impulse, position )
➔ g_gameRules.game:SoundEvent( entityId, sound, radius=100, volume=10 )
➔ g_gameRules.game:GetWorldAngles( anglesLocal, anglesGlobal )
➔ g_gameRules.game:IntegrateCustomObject( entityId )
➔ g_gameRules.game:SpawnEntity( params )
Entwicklungszeit
Von den ersten Tests bis zur abschließenden Optimierung und dem letzten Schliff vergingen etwa 15 Stunden. Allerdings konnte ich auf einige Funktionen zurückgreifen die bereits Teil des SSM sind, andernfalls wären es einige Stunden mehr geworden.
Warum diese Projektvorstellung
CryServ war in der ersten Version von 2014 bis Ende 2019 sehr eingeschränkt in seinen modding Möglichkeiten. Da dies in der neuen von Grundauf überarbeiteten Version 2.0 nicht länger der Fall ist, möchte ich einfach verschiedene Projekte vorstellen um die Möglichkeiten anhand von Beispielen zu präsentieren.
