jkPatrol-Script V3 (ohne Beta) Release Now

[jnrk]

@ColonelChris

Ideen für mögliche Fehler:
- 492910.xml nicht ins x2/t-Verz kopiert
- Hast Du X2 nur mittels Alt-Tab in den Hintergrund geschaltet und den Krams reinkopiert ?
- ein anderes Script aktiv, dass auf COMMAND_TYPE_FIGHT_20 liegt ?

Bei V1 müssen nur genügend EZ im Frachtraum sein, bei V2beta ists egal da sie bei Bedarf direkt nachgekauft werden und somit der Laderaum entlastet wird.
Start mal die "init.cmd.jk.patrol.xml" über den Scripteditor von Hand.

Das Skript kann einfach mittels "kein-Kommando" aus der Kommandokonsole gestoppt werden - ist also unproblematisch.

Danke fürs Lob, verglichen mit Anderen muss es noch einiges zulegen, aber dann werd ichs sicher einreichen.

8 heiße Sektoren können defakto nicht vernünftig überwacht werden, da das Kämpfen schon sehr viel Zeit benötigt, es sei denn man setzt es wie ich, jeweils für 1-2 spannendere und 7-6 ruhige Sektoren ein. Insofern beschränkt dieses Skript sich von selbst.
Deine Idee es auf Sektoren mit NavSats/Stationen zu begrenzen gefällt mir gut und würde sich sicher viel besser (auch logischer) in die Spielwelt einfügen. => Kommt auf die ToDo

G+D,
jnrk

PS:Immer her mit der Kritik

[M.Kessel]

[jnrk]

Hallo Michael,

so hab ich das noch garnicht betrachtet. Da die Gegner auch erst per regulärem Sichtbereich erkannt werden sollen, ists naheliegend, dass Feindkontakte (an eine zentrale Stelle) gemeldet werden und von dort "angemessen" reagiert wird. Die Poll-Idee gefällt mir.

Eigentlich müssten alle IDLE-Kampfschiffe herangezogen werden und für den Einsatz müsste erstmal die als erste herangezogen werden, die am nächsten dran sind und dann die aus dem HQ, oder ?
Dies würde die taktische Komponente, durch geschickte Verteilung der eigenen Kräfte (besonders M1/M2), stärken.

Deine Ausführung ist ja

Ein solches Verhalten in der NPC-KI, könnte aber fatale Folgen haben, stell Dir vor beide Seiten haben es laufen und in einem Sektor sehen sich die Kontrahenten und ordern beiderseits immer mehr Verstärkung dahin.

Dein Vorschlag (Jumpdrive Ja/nein) bezieht sich auf das jetzige Script, oder ? Eine Einfachvariante wäre erstmal, dass jeder der Jumpdrive+EZ hat diese nutzt und der Rest geht zu Fuß


Gruß,
Sascha

PS: Wäre doch durchaus ok, wenn die Völker für ihre eigenen Wachen so ein (oder ein ähnliches) System selbst verwenden.
PPS: Was geschieht mit einem Script wenn das Objekt auf dem es ausgeführt wird, vernichtet wird (per Kampf oder Script) ?
PPPS: Je mehr ich drüber nachdenke, desdo besser gefällts mir.

[ColonelChris]

Also die Ideen von M.Kessel sind ja allesamt nicht schlecht, aber ein einfaches Patrouillen-Script, welches eine Hand voll Sektoren von den Khaakerlaken frei hält reicht mir eigentlich schon. Man sollte stets im Auge behalten, was schlussendlich mit der Engine des Spiels und den verfügbaren Systemressourcen machbar ist. Es sollte grundsätzlich erstmal verhindert werden, dass es in einem Sektor von Khaakis nur so wimmelt und der M6 im System nebenan sich die Eier schaukelt...

Ich würde mein Augenmerk eher auf die Spielbalance legen: Nicht zu mächtig machen, evtl. kaufbar machen (Kampfsoftware MK3 für 500.000 Cr oder so), Transporter für EZ-Einkauf notwendig machen, Kopfprämie auszahlen (ähnlich wie man selbst Prämien von den Völkern kriegt) und Erfahrungs-Levels mit steigender Anzahl Systeme, die das Schiff überwachen kann etc.

@jnrk: Lass dich nicht von uns verrückt machen. Wenn du weiter an dem Script arbeiten willst, dann setze dir erstmal nur erreichbare Ziele. Träumerthreads gibts in diesem Forum schon genug. Ich würde mich durchaus über ein Kampf-Äquivalent zum erfolgreichen Trade MK3 freuen und hier finde ich bisher die besten Ansätze.

[jnrk]

Irgendwie habt Ihr Beide Recht, ein schönes mächtiges Stationsbasierendes Verteidigungs/Befehlssystem vielleicht sogar als extra Station die nichts anderes macht (Militärisches HQ) entlastet jenen der Flotten-Kommando und Imperiumsschutz betreiben muss. Der Kaufpreis dürfte, aus meiner Sicht, ruhig sehr hoch sein 50-100Mio, denn wer sich eine Flotte (mit ggf mehreren Verbänden) und ein Imperium mit XXX Stationen leisten kann, sollte auch ein entsprechendes Schutzbedürfnis und Zahlungsfähigkeit besitzen.

Dagegen bedarf es auch eines einfachen Systems (quasi das AutoPatrol-Script mit Transporter-EZ-Einkauf) für den mittelständigen Unternehmer.

Meine Idee geht daher dazu über, beide Anforderungen zu kombinieren. Wird das Script in einer Station ausgeführt (bestimmte Erweiterung oder Station als Vorraussetzung), dann gibts die "große" (Rundum Pool) Variante. Auf einem Schiff ausgeführt nur eine "kleine" (AutoPatrol) Variante.

Was haltet Ihr davon ?

[ColonelChris]

Mach lieber zwei Scripts. Eines für den Spieler, der einfach nur ein paar einzelne M6 oder M2 zur fortgeschrittenen Sektorwache abkommandieren will ("MK3", 500.000 - 1Mio Cr) und eines für den Ober-Magnaten, der so sehr mit den Khaakis zu kämpfen hat, dass er auch tatsächlich ein HQ benötigt und gerne 50 Mio für ein kombiniertes MK3 für seine gesamte Flotte ausgibt. Das sollte dann wenn möglich mit einem bestehenden HQ-Mod verbunden werden, quasi als Upgrade dafür.

Also mein Vorschlag:
"Fight Software MK3" -> Schiffsupgrade im Preisrahmen der Trade MK3
"Fleet Manager Software MK1" -> HQ-Mod-Upgrade im Preisrahmen eines M2

[jnrk]

@ColonelChris
Ist angekommen...ich darf gsl's EZ-Versorgungsroutine verwenden und baue sie ein. Bin gespannt wie das im Test aussieht (Zentaur+4Novas+1Manta) und obs funktioniert.

Gruß und Dank für Eure Eingaben/Anregungen und Idee,
Sascha

[jnrk]

Nachdem ich viel über die unterschiedlichsten Eingaben nachgedacht habe, wird es Zeit eine Neuausrichtung vorzunehmen, ausgehend von der Ziel&Funktionsgruppenbestimmung.


AutoPatrol

Für Alle gilt, korrekter Einkauf der EZ, Jumpdrive und ggf. eine passende Softwareerweiterung sind notwendig. Sektoren die patrouilliert werden sollen, müssen über NavSat bzw eine eigene Station verfügen, sonst gibt es keine Informationen über Feinde, demzufolge kann auch nicht patrouilliert werden. Als Feinde nur noch "Moveable" Einheiten...
Alle Einheiten springen gemeinsam in den "Problemsektor"
Wartet der Verband/die Einheit auf ihren neuen Einsatz verwenden sie die Idle-Funktion zur Bewegung.
Auftragsanzeige im Kommandokonsolenmenü des Hauptschiffs (derzeit steht dort "keine").

Im folgenden ist mit M6 immer Schiffsklasse M6 bzw. M2/M1 gemeint.

0. Patrouille mit einem M6
EZ müssen von Hand nachgekauft werden
=> Meldung erfolgt wenn EZ nicht ausreichen

1. Patrouille mit mehreren M3
der Einkauf der EZ wird jedes Schiff selbst durchführen

2. Pat mit einem M6+angedocktem M5
M5 als Versorger, Versorgung erfolgt nachdem der Sektor befriedet ist

3. Pat mit M6+M3+M5
M5 als Versorger, Versorgung erfolgt nachdem der Sektor befriedet ist

4. Pat mit Verband + TP/TS
TP/TS als Versorger, Versorgung erfolgt nachdem der Sektor befriedet ist
TP/TS muss über "Transporter-Erweiterung" verfügen

@mkess & BurnIt! & ColonelChris & Sagittarius
Mein besonderer Dank an Euch, aus einer "billigen" Funktion, wird alsbald ein schönes System für kleinere bis Mittelständige Unternehmer. Die Pool-Defend-HQ-Variante möchte ich gerne angehen, wenn das HQ verfügbar ist.
Würde mich über Eure Kommentare und Anregungen zu diesem Ausrichtungskonzept freuen.

Herzliche vom Eingeschneiten,
jnrk

[ColonelChris]

Hmm, wie schauts aus, klappt es bereits, einen TS/TP zuzuweisen, der dann die EZ heranschafft oder ist das nur Theorie? Die Sache mitm M5 als Versorger ist nett, jedoch glaub ich nicht, dass das je einer machen wird. Ein M6 braucht locker 300-500 Einheiten "Vorrat" an EZ, die M5 haben aber bestenfalls 30-50 Einheiten Platz für Cargo. Das würde dann gerade mal fürn Sprung in die "Nachbarschaft" reichen, oder sie müssten mehrmals hin- und hertingeln. Kritisch ist deshalb wohl die Sache mitm TS/TP als Versorger, worauf du ganz eindeutig deine Bemühungen konzentrieren musst. Ich hoffe mal, dass das von dir erwähnte Versorgerscript von gsl auch was taugt.

BTW: Wenn du mir erklärst, wie man scriptet, würde ich dir glatt dabei helfen.

[OT]Viel cooler wärs natürlich noch, wenn Egosoft endlich mal offiziell EZ an Werften und Raumpiers verkaufen ließen. Das wäre mit Sicherheit noch die vernünftigste Lösung. Reincheaten würde ich das aber nicht. Frei nach dem Motto: So wenig vom Originalgame ändern wie möglich.[/OT]

[jnrk]

Moin,

die Einzelelemente funktionieren soweit (die einen besser, die anderen schlechter) und ich setz mich gleich mal die Kombination. Die TS/TP fliegen schön artig einkaufen (bei Bedarf auch mehrfach, denn einen Verband zu versorgen ist schon was mehr Aufwand) und wenn sie in Reichweite sind, werden (Transporter-Erweiterung vorrausgesetzt) die EZ die letzte Meile gebeamt...
Derzeit bekomme ich den gedockten M5 per Script nicht zu fassen und weiß da nicht weiter..
...
Gruß und schönen Sonntag

[gallo]

Warum lässt du den TS die EZ nicht einfach als object ware in den Raum ausladen und die zu versorgenden Schiffe diese Pakete dann einladen? Damit wäre das Problem mit der Inkompatibilität zwischen den Schiffen was Docken angeht beseitigt ^_^

Edit: Vll. etwas dumm ausgedrückt. Entferne die EZ aus dem TS, dann mit 'create flying ware' eben jene EZ im Raum an der Stelle des Schiffs oder knapp daneben erstellen, die anderen Schiffe jeweils zu ihrem Paket fliegen lassen mit 'move to object' (?) und das dann aufnehmen lassen per 'catch object ware'

[jnrk]

Die Variante mit dem Transporter ist soweit ok, logisch korrekt und X2-konform.

@gallo
Deine Lösung hat natürlich auch einiges für sich....

[ColonelChris]

Dann müssten konformerweise aber auch alle Schiffe die Spezialsoftware drauf haben. Wenn ihr das Script signiert haben wollt (und das wär ziemlich geil), dann muss es in sich logisch und konform bleiben.

Was mich viel mehr wundert, und da mache ich mir doch einige Sorgen, ist wie jnrk die Sache mit der Flottenzugehörigkeit regelt?!? Also, du kaufts die Patrouillensoftware für das Führungschiff und stellst den Rest auf "Bewachen" oder "Folgen". So weit alles klar, aber wie willst du dann konform und in-sich-logisch den Frachter dann zum EZ holen schicken? Logischerweise müsste man also zwei Softwares kaufen. Oder die Software müsste so konstruiert sein, dass sie nur auf einem Schiff funktioniert, das einen TS/TP im Verband hat. Aber woher wissen die gegenseitig, dass

a) die Flotte auf den EZ-Tanker warten
und
b) der Frachter wirklich restlos alle Mitglieder der Flotte versorgt, ehe durch einen Angriff irgendwo die Flotte plötzlich springen muss.

Der Frachter wäre in Fall b) evtl. noch nicht fertig und die Flotte könnte dann entweder gar nicht springen oder es würden nur die springen, die genug EZ haben und der Rest würde zurückbleiben. Als Resultat könnte die Flotte dadurch empfindlich geschwächt werden, oder (nicht ganz so schlimm) muss nervigerweise von Hand neu gruppiert werden.

Die Sache mit dem Frachter ist zwar ziemlich cool (weil auch realistisch), aber mir wird jetzt schon schwindelig, wenn ich nur daran denke, wie der ne ganze Flotte versorgen soll.

[jnrk]

@ColonelChris
Hab Dank für Deine Bedenken/Anregungen, so gibst Du mir Einblicke von einem anderen Standpunkt aus, und das hilft ungemein.

Die Verbandsschiffe müssen nur den Befehl "Folgen" oder "Bewachen" ausführen und benötigen hierfür bereits ein Softwarepaket, das sollte reichen. Da die Führung des Verbandes (wie in der Realität) dem Führungsschiff obliegt und hier das Script drauf läuft, ist es selbstverständlich, dass hier eine extra-Software drauf muss (nennen wir sie mal Patrol MK I)

Versorgung einer Flotte ist garnicht so schlimm, außer bei der Erstbetankung muss immer nur der Verbrauch des letzten Sprungs ersetzt werden.
Beispielverbrauch bei einem Verband wie folgt:
4M6&20M3=140EZ/Sektorabstand
ist ein M2 dabei verschwinden die M3 darin und der Verbrauch hält sich ebenfalls in Grenzen. Also nichts was ein TS/TP nicht locker versorgen könnte.

Was funktioniert derzeit ? Stand der Entwicklung 29032004-2250

Das Script erkennt ob ein TS/TP im Verband ist und verwendet diesen als EZ-Käufer. Der Verband springt erst, wenn alle mit genügend EZ für den Sprung versorgt sind. Der Sprung erfolgt demzufolge weitesgehend geschlossen, dennoch beginnt die Bekämpfung der Feinde im neuen Sektor erst, wenn der Verband vollständig angekommen ist. Mein derzeitiger Testverband besteht aus 1 M6 (als MVU), 2 M3 (Barracuda), 2 M3 (Novas) und einem TP (Manta). Besteht der Verband zB nur aus M3/M4/M5 und ist dabei ein M3 Führungsschiff, versorgen sich alle selber.

Die Versorgung ist im übrigen sehr unterhaltsam, ist zB der ganze Verband versorgt und man wirft manuell EZ bei einem Verbandsschiff ins All, wird derjenige direkt aus dem Vorrat des Versorgers wieder aufgefüllt. Hat der Versorger selbst zuwenig an Board, fliegt er los und kauft artig Nachschub.

Besteht die Patrouille nur aus einem M6, meldet sich dieser per Message, wenn sein EZ-Vorrat aufgebraucht ist und der Spieler muss manuell handeln.

Das klingt doch Alles nicht so schlecht, oder ?

Derzeitge Herausforderungen:
h1. nach dem Sprung ins Kampfgebiet soll der Versorger in der nächstgelegenen Station in Deckung gehen und nach der Befriedung wieder rauskommen und seiner Aufgabe nachkommen. Dies würde ich am liebsten mit Signalen realisieren, aber noch hab ich kein eigenes Signal lauffähig in X2 hinbekommen
h2. wenn Friede herrscht im Sektor, könnten sich der Verband einfach so umher bewegen zB Move.Idle, aber wenn sie als Verband Idlen folgt keiner mehr dem Führungsschiff oder wenn das Führungsschiff Idled und der Verband folgt, kann das Führungsschiff nicht gleichzeitig die anderen Sektoren scannen.
h3. M2/M1 und ihre angedockten Schiffe, ich bekomme sie nicht per Script gegriffen und somit nicht ausgeladen. Idee wäre wenn man das Script startet, müssen alle Schiffe im All sein und werden per Script eingeladen (dabei kann ich Alle einfach in einem Array speichern) und später wieder beliebig wieder ein/ausgepackt. Müsste gehen, oder ?
h4. wenn die Schiffe schon rumstehen und alle versorgt sind, könnten sie eigentlich "zu Fuß" zum nächsten zu patrouillierenden Sektor fliegen (vorrausgesetzt er liegt direkt nebenan). Eigentlich das gleiche Problem wie h2.

Ungetestet:
u1. mehrere Versorger in einem Verband (Umsetzung erfolgt später)
u2. Verband nur aus einem M6 und einem Versorger (NEW getestet und für gut befunden)
u3. Alles größer als M6 (NEW getestet und für gut befunden)

Ziele bis zum Erscheinen der V3beta:
h1 lösen und u1 testen

Gruß und Dank,
jrnk

[ColonelChris]