MegaMek InstantAction

Ich entwickele gerade ein paar Hiflsprogramme für MegaMek und brauche eure Hilfe. Was wären sinnvolle Funktionen?

Problem:
Ich bin ein typischer SinglePlayertyp. Ich bevorzuge 3025 MechGefechte eventuell im Kampf gegen Clans. Dazu habe ich jedesmal ein neues Spiel eröffnet, Einheiten und Map gewählt und dann gekämpft. Auf Dauer hat es kein Spaß gemacht, weil keine Entwicklung der Mechkrieger oder Kampagnen möglich waren.

Mein Lösungsansatz:
In letzter Zeit habe ich ein wenig in Java eingearbeitet. Als erstes entwarf ich ein Programm, das ein Szenario beliebiger Größe erzeugen kann. z.B. "Lanzenkampf" zweier Häuser mit zufällig gewählten Mechs oder "Hammer und Amboss" Teilzerstörte (zufällige)ClanMechs auf dem Rückzug erscheinen "tröpfchenweise" (in zufälliger Anzahl) auf einer Map auf der eine Kompanie 3025 Mechs auf der Lauer liegen.

Aktuell arbeite ich daran "Gamelog.txt" zu parsen. Das bedeutet: Ich kann in kürze alle Daten komprimiert aus Gamelog.txt auslesen. Beispielsweise
- Wie oft hat ein Pilot mit welcher Waffe getroffen und mit welchen Wurfwert?
- Wie oft hat ein Pilot erfolgreich ein Pilotenwurf abgelegt?
- Wie oft wurde Abschaltung verhindert usw. usw.

Aber: Was mach ich mit den Daten? Wie kann man das allgemein nutzen und nicht nur spezifisch für meine Zwecke?

Ich denke darüber nach eine automatische Kampagne zu generieren mit Piloten, die sich weiterentwickeln. Auch Kampagnenmaps können generiert werden.

Einheiten aus *.mul Dateien können in Szenarios importiert werden. OriginalMaps können temporär modifiziert werden (z.B. Wald, Schnee, Grass und Wasser auf BattleTech-Map) etc....

Bevor Fragen dazu erscheinen: Ich ändere die Megamek Dateien nicht, sondern arbeite mit den automatisch generierte Dateien von Megamek oder Standarddateien (Maps,Mechs). So kann ich zum Beispiel auf die Units.cache Datei etc. zugreifen.


So Leute,
Fragen, Vorschläge, Kritik sind erwünscht...

Alles kommt anders...

Endlich (Gestern) habe ich den SourceCode von MegaMek fehlerfrei in Eclipse importieren können. (Mann, das war affig! - Schon dumm wenn man einen alten EclipseCompiler besitzt, der die neuen Sprachkonstrukte nicht kennt und man selbst nicht weiß, dass Java vor einem Jahr erweitert wurde) Jetzt ist es mir Möglich innerhalb des Projectes Änderungen vorzunehmen und diese in eine spielbare Form zu exportieren.

MegaMek hat folgenden Aufbau:

Megamek.exe ruft MegaMeg.jar auf in dem die compilierten Javaobjekte enthalten sind. Beim Speichern einer geänderten Datei in Eclipse wird vollautomatisch die Datei bereits compiliert. Den compilierten Code muß man dann "von Hand" in das richtige Verzeichnis in der komprimierten *.jar Datei hinzufügen. Ab diesem Zeitpunkt sind die Änderungen im Spiel verfügbar.

Aktuell arbeite ich am ScenarioLoader.
Bereits implementiert:

Neue Anweisung für ScenarioDateien implementiert(*.mms)

"Themes=Thema1[, vonLevel, bisLevel[,Thema2, vonLevel, bisLevel]]..."

Thema: z.B. "Grass", "Moon", "Mars", "Snow"

Beispiel:
Themes=Grass, 0, 3, Snow, 5, 10

Belegt Höhenstufe 0 bis 3 mit Thema Gras und Höhenstufe 5 bis 10 mit Schnee

Beispiel:
Themes=Grass

belegt gesammte Map mit Gras. Bewuchs mit Bäumen ändert sich entsprechend des Themas.

Bedeutung:
Wenn eine Map geladen wird, dann wird den Hexfeldern ein bestimmtes Thema zugewiesen, z.B. "Grass", "Moon", "Mars", "Snow" Ohne Angabe von Höhenstufen wird die ganze Map mit dem angegebenen Thema belegt, ansonsten nur von Höhenstufe bis Höhenstufe einschliesslich.



Fragen und Anregungen sind herzlich willkommen.


Persönliche TODO-Liste (vorläufig):
Weitere Scenariobefehle z.B.

- Water=Levelx (erzeugt auf der Map einen Wasserstand auf der Höhe von Levelx)
-Burning=HexFeld1[, Inferno, Restrunden], Hexfeld2[, Inferno, Restrunden]... (brennende Felder vor betreten erzeugen)
-Escape_Faction1=HexFeld1 [, Hexfeld2]... (Wenn das Feld von der genannten Fraktion betreten wird, dann verläßt sie automatisch das Spiel = Flucht)
-Mapreplace=Gelände1, durchGelände2, Gelände3, durchGelände4 (Man kann beispielsweise Heavy Woods durch Rubble ersetzen)
- Unit_Teamname_1_DeploymentRound=Random:[frühestens zu RundeNr: ] spätestens zu RundeNr (Verstärkung kommt nach einer zufälligen Anzahl Runden)
-Play=endless () (Man kann die ganze Nacht die gleichen Gegner gegeneinander spielen lassen)
-Logfile=Pfad/Statistik.log (Das echte Ergebnis über alles wissenswerte aller Kämpfe in dieser Sitzung)

Also wenn ich deine Liste so durchschaue, dann muss ich mal fragen, welche Version von MM du denn bearbeiten moechtest.
Einiges, was du unter "ToDo" stehen hast finde ich durchaus in dem Game wieder.
Der Kampagnenmodus ist nett, aber die Sache mit dem "Thema" der Hexe ist in sofern bereits geloest, als das man hier klar auf das "generated" zurueckgreifen koennte...
Hinzu kommt, das mir das Projekt dem MM.NET doch sehr aehnlich ist, einziger Unterschied waere dann wohl, das man das halt alleine spielen koennte. Der Ansatz waere dann aber auch, sich von der Version die Source zu ziehen bzw mit den Leuten denn mal zusammenzuarbeiten, ich denke, das koennte die Sache erheblich vereinfachen, oder nit?

Die Version ist 0.32.2

"Generated" läßt sich als Map nicht in ein Scenariofile eintragen. Man muß zuerst eine Map generieren und dann explizit den Namen der Map in das Scenariofile von Hand eintragen.

Wenn man "Random" bei einem z.B. 2x2 Maps großen Board einträgt, dann kann man unter Umständen eine Mischung aus Hochgebirge, Mondlandschaft und dichten Wald bekommen. Durch ein gleichartiges Thema sieht das Spielfeld natürlicher aus.

Auf SourceForgeNet gibt eine HomeSeite, die an "willige Programmierer" gerichtet ist...

Da heist es in etwa (aus dem Gedächtnis) auf englisch:"Sie wollen an MegaMek mitprogrammieren? Sie sind ein guter Programmierer? Natürlich! Jeder, der schon mal ein paar Zeilen geschrieben hat, hält sich für einen guten Programmierer! Wenn sie uns unterstützen wollen, dann schaun Sie mal ob sie nicht noch ein paar Grafiken zeichnen können..."

Ich habe 29 Jahre Programmiererfahrung, aber nur ein, zwei Monate in Java. MikroController in C/C++ oder Assembler programmieren war mein Job. Aber in Java habe ich noch viel zu lernen.

Mein Ziel ist es außer möglichst viel in MegaMek zu automatisieren, evtl neben einen Build-In-Mek/Vehicle und sonstwasEditor hinzuzufügen auch an der KI zu arbeiten. (Ich habe mal diverse private Schachprogramme geschrieben).

Ich versuche aktuell nur eine einzigste Datei(ScenarioLoader) "aufzubohren", damit ich diese Datei bei Bedarf auch mal zur Gänze dort in einen Post stellen kann ohne das ich ein Mitglied dort im Programmierteam bin.

Es geht mir nicht dringend darum alleine spielen zu wollen, sondern die Möglichkeiten von MegaMek zu erweitern. Dazu muß ich mich im Verlauf der Zeit mit dem Projekt vertraut machen und beispielsweise schauen wo und wie das Programm Felder/Figuren speichert, oder nach welchen Kriterien ein Zug generiert wird.

Solche "Mikroaufgaben", wie ich sie mir gestellt habe, sind nützlich zum Erkunden der Aufgabenverteilung im Projekt MegaMek. Programmieren und eine neue Programmiersprache zu erlernen macht mir Spaß. Außerdem liebe ich MegaMek. Ich kann's nicht erwarten einen neuen Bot zu erzeugen. Das dauert aber noch...

Update:

Done komplett mit Fehlerbehandlung:

- Unit_Teamname_1_PilotHits=Anzahl Treffer --->Der Pilot eines Mechs wird vor Betreten des Feldes mit Anzahl Treffer verwundet
- Unit_Teamname_1_InfernoHits=Anzahl Treffer --->Die Einheit erhält vor Betreten des Feldes Anzahl Treffer Infernoraketen
- Fire=Hex_x,Hex_y,Anzahl Treffer[,Hex2_x,Hex2_y,Anzahl Treffer]* ----> Die angegebenen Felder stehen vor Beginn des Spiel mit Hilfe von InfernoTrefer in Flammen.
- Water=Wasserstand auf Geländehöhe ---> Wasser über Wasserstand wird entfernt bzw. Wasser wird bis zur Geländehöhe aufgefüllt. Negative Werte erlaubt
- Themes=Thema ---> Komplette Map wird mit Thema gefüllt.
- Themes=Thema, von Geländehöhe, bis Geländehöhe[,Thema, von Geländehöhe, bis Geländehöhe] ---> Themen werden nur in den jeweiligen Geländehöhen eingesetzt.

TODO:

- Den Archipelargo-Bug mit einstürzenden Brücken finden (Aufstehen für Einheiten nicht mehr möglich)

- Terrain= Geländetyp für ein Hex im *.board-Format
- Factions= File:/savegame/myKumpelz.mul, Nächste_Einheit ---> Fraktionen können entweder lokal im Scenariofile erzeugt werden oder aus einem *.mul importiert.

Update:

Done ohne Fehlerbehandlung:

- Factions = Faction1|Random:Faction1:Experience:TechBase:Size:Tonnage|File:Faction1: PfadDateiname*

Erklärung:
Experience kann die Werte "Elite", "Veteran","Regular","Green" haben.

Elite = Gunner 2, Pilot 3
Veteran = Gunner 3, Pilot 4
Regular = Gunner 4, Pilot 5
Green = Gunner 5, Pilot 6

Wenn TechnoBase CL_2 ist, dann werden die Werte um 1 verbessert. Dann ist Elite z.B. Gunner 1, Pilot 2

TechnoBase ist aktuell:"IS_1","IS_2","CL_2"

Beispiel (Random und File)
Factions=Random: BadBoys:Elite:IS_1:4:200,File:GoodGuys:savegames\\EarlGrey.mul

Erzeugt eine zufällige Fraktion namens "BadBoys" die Elitekämpfer sind (2,3) und 4 Techlevel IS 1 Meks besitzen, die zusammen 200t wiegen. Ausgewürfelt wird nach Mechwarrior RPG second Edition (Hab nix neueres)

Erzeugt eine zweite Fraction namens GoodGuys, die aus dem MegaMek/savegames-Ordner geladen wird. Namen der Datei: EarlGrey.mul. Alle Units, alle Piloten, alle Schäden, Restmunition wird aus der *.mul-Datei übernommen. Klingt zwar kompliziert, war aber relativ einfach. Mich wundert es, dass es nicht von Anfang an implementiert wurde.

Ich habe den Archipelargo-Bug finden aber nicht beseitigen können. An bestimmter Stelle im Programm wurde ein Konstantenname verwechselt. Statt BRIDGE_ELEV wurde nur BRIDGE eingesetzt. Das fürt dazu, dass man nicht die Höhe der Brücke zurückbekommt, sondern nur den Typ der Brücke (leicht, mittel, hart etc.) Das wird dann als "Brückenhöhe" weiterverarbeitet.

Beseitigt man diesen Bug, dann geht es trotzdem nicht korrekt weiter. Die Fallroutine ist etwas verwickelt und fast nicht kommentiert programmiert. Haarsträubend.

Beispiel:
Ein Mech wird von einer Lev 4 Klippe gestossen und fällt auf ein Building, auf dem ein Mech steht, auf dem es zu einen erfolgreichen Swarmangriff kam. Das Gebäude ist überlastet und bricht mit allen Einheiten darin auf verschiedenen Stockwerke verteilt sind zusammen in den Keller des Gebäudes. Einer der Mechs auf dem Dach des Gebäudes fällt in ein anderes Feld wo ein Level 3 Fueltank steht. Der explodiert natürlich. Auf dem Fueltank steht natürlich noch ein Mech. Einer der Meks fällt vom Dach des Fulltanks auf einen Hubrschrauber auf Level 2 in der Luft. Beide zusammen stürzen auf einen Panzer der auf einer Level 1 Brücke steht. Die Brücke bricht über einem HooverCraft auf der Wasseroberfläche zusammen und sinkt auf einen getauchten Mek.

Happy Birthday! Ich verstehe jetzt warum man den simplen Dominoeffekt nicht in den Griff bekommt. Manche der verwendeten Funktionen sind stark mit nebensächlichkeiten überladen. Man müßte dass Ganze richtig überarbeiten und komplett phasenweise durchparsen.

MegaMek ist nicht LogiTek. Stürze benötigen keine Zeit Ein Mek kann von einer Level 200 Klippe stürzen und ein anderer von Level 1. Beide kommen gleichzeitig an.

Scotty, bitte beamen!

Das klingt eigentlich sehr interessant. Wenn du erlaubst, würde ich es gerne mal Antesten.

Du hast aber schon gelesen, worum es hier geht, ja?

Edit: Wieso bin ich eigentlich auf die Idee gekommen einen Post zu schreiben um mein Interesse zu rechtfertigen ?
Rechtfertigung gelöscht.

Tut mir leid, dass ich erst jetzt antworte.

Aktuell habe ich das Projekt um eine "Megamek Random Unit File" erweitert. Diese läßt sich editieren und Wahrscheinlichkeiten, Hauszugehörigkeit, Mechtyp, Gewichtsklasse etc. selbst einstellen.

Das ist noch nicht fertig. Gib mir noch zwei Tage, dann lade ich das Programm und alle erforderlichen Daten (inclusive Quellcode wegen OpenSource und so...) auf eine Downloadseite. (Hat jemand einen Tipp welche Seite gut ist?)

Ähem, habe ich was verpasst? Worum gehts hier im Thread?

Update:

Nach langen Ringen und Daten zusammenfassen, habe ich eine vorläufige Definition der MRU-Datei festgelegt. Eine sinnvolle Dateidefinition zu machen ist sehr viel schwieriger als im Code "herum zu hacken".

Eigenschaften:
- IS und Clan werden auf auf getrennten Gewichtsklassentabellen erwürfelt.
- IS und Clanfraktionen lassen sich zusätzlich vom Benutzer definieren.
- Fraktionseigene Mechwürfeltabelle
- Die verwendeten Würfel für jede Tabelle sind einstellbar: 2W6= Zwei sechsseitige Würfel, 1W12 = Ein 12-seitiger Würfel, 3W7 = Drei siebenseitige Würfel...
- Söldner können entweder als eigene IS Fraktion mit eigener Mechwürfeltabelle anlegen oder es wird Gewichtsklasse, dann Haus erwürfelt von dessen Würfeltabelle der Mech stammt.
- Folgene ClansMechtabellen nach den schwammigen Angaben in TR 3050 definiert: JadeFalken, Wolf, Geisterbären, Nebelparder
- In den Mechtabellen sind nur die Chassis der Mech angegeben. Varianten werden vom Programm gewählt. Will man eine spezifische Einheit, dann kann man sie an entsprechender Stelle statt eines "nackten" Chassis eintragen... auch wenn es dann eine sprungfähige AntimechInfantrie ist!(Pfui!)

Ganz glücklich bin ich mit der Definition nicht. Auf manche Tabellen muß ich explizit zugreifen. Eigentlich will ja vom Programm aus gesehen nur eine zufällige Einheit nach der anderen unter bestimmten Randbedingungen. Egal durch wieviel Tabellen ich mich wurschteln muß.

Das Fertigprogrammieren der genannten Funktionen dürfte im Vergleich zum Dateientwurf deutlich schneller gehen.

Update:

Bevor jemand glaubt ich sei untergetaucht...

Ich habe die endgültige Definition der MRU-Datei... Es war so simpel.

Zwingend vorgeschriebener Eintrag:
Fraktionsname_getUnit=TabellenName oder eingetragene explizite Einheit

Tabellenformat:

TabellenName=Anzahl Würfel:Anzahl Seiten pro Würfel
TabellenName_NiedrigstesWurfergebnis=explizite Einheit oder TabellenNameX
bis
TabellenName_HöchstesWurfergebnis=explizite Einheit oder TabellenNameY

Folgerung für das Programm---> Es muß nicht mehr wissen durch wie viele Tabellen es gehen muß bis eine bestimmte Einheit gefunden wird.
Folgerung für das Benutzer---> Er hat alle Entscheidungen in der Hand... vom Anteil der Panzer bis zur Auswahl erlaubter MekTypen und Varianten. z.B. Kann eine IS2_Locust_Variant-Tabelle auch einen Eintrag auf eine IS1_Locust-Tabelle besitzen.

Ich bin einfach zu pingelig... Ich mußte am Dateiformat solange herumfeilen bis ich zufrieden damit war. Das Dateiformat ist selbsterklärend und einfach selber in jeder Hinsicht zu erweitern. Das Erzeugen der Daten ist wegen der Recherche erst einmal etwas zeitaufwendig. Aktuell plane ich nur IS1-Komplett mit verschiedenen Einheitentypen für alle Häuser+ vereinfacht IS2 und CL2.