Erstmal müssen "ltxtool" and "changeFile" erstellt werden. Ich hatte um eine Rückmeldung gehofft, ob es zumindest ein funktionales Äquivalent zu "changeFile" schon in freier Wildbahn gibt. Man muss ja das Rad nicht neu erfinden.
Crystals-DSA-Foren
›
Allgemeines zur Nordlandtrilogie DOS
›
Technische Werkstatt
Reverse Engineering der NLT II
Reverse Engineering der NLT II
|
Reverse Engineering der NLT II
|
LTXTOOL ist erstellt, mit Funktionen "add", "replace", "delete" und "difference". "difference" zeigt die Unterschiede zwischen zwei Dateien. Im Anhang die Patch-Änderungen an den Textdateien zur Information. Zum richtigen Darstellung der Umlaute als Zeichensatz "OEM-US" wählen. Wenn der Rest fertig ist, wird das ganze eine richtige Form bekommen.
patch-text.7z (Größe: 14,4 KB / Downloads: 5)
Außerdem ist mir aufgefallen, dass es noch die *.TLK-Dateien gibt, welche vor dem Textblock noch anderes Zeug haben. Da muss ich mir noch anschauen, ob das LTXTOOL quasi miterledigen kann, oder ob das noch ein separates Werkzeug erfordert. 
Huhu ihr NLT-Veteranen,
Nach meinem erneuten Playthrough der NLT bekam ich Lust, Riva mal in einer modernen Grafikengine zu betrachten. Dank der super Doku (https://github.com/shihan42/BrightEyesWiki/wiki/3DM) ist es mir in den letzten Tagen auch gelungen. Hier mal drei(leider stark komprimierte) Screenshots: Ist ganz lustig damit durch die Stadt zu fliegen, aber noch bekommt man nicht ganz das nostalgische Riva-Feeling, da Nebel und Lighting noch fehlen. Falls Interesse besteht kann ich den Code und die Binaries gerne zur Verfügung stellen. Um rechtlich auf der sicheren Seite zu sein, möchte ich aber gerne vorher sowohl den NLT-Entpacker als auch das Ruby BoPa Skript in C# so umschreiben, dass es die benötigte DUNGEONS.ALF von der Riva-CD nur im RAM entpackt. @Hendrik, @Helios Ich hoffe das ist OK, da von euren Quelldateien abzuschreiben? So würde ich sichergehen, dass man das Programm nur mit einer eingelegten CD (oder Image) starten kann. Danach könnte man noch vieles Ausbauen, und z.B. mehr Debug-Informationen ausgeben, sich das Shading anschauen (siehe rötliches? Rathaus und Gericht), Beleuchtung, Collision-Boxes und weitere Rätsel lösen. Was mich gerade noch ärgert, ist das ich nirgendwo finden konnte, ob ein Objekt (oder eine Textur) als Billboard gerendert werden soll, das wäre noch wichtig zu wissen. Solange ich den entsprechenden Marker nicht gefunden habe, gebe ich die Info einfach noch extern dazu. @Shihan: Du meintest mal vor ein paar Jahren, dass du das Format auch gelüftet hast, aber im Wiki fehlen noch einige Dinge. Gerne stelle ich meine kürzlich gesammelten Erkenntnisse über die Grafikformate zusammen, damit man das auf den neuesten Stand bringen kann. Oder um das einfach mal mit deinem Renderer abzugleichen. Leider sind alle Bilder davon mittlerweile nicht mehr erreichbar. 
01.03.2023, 18:18
(01.03.2023, 17:06)cmfrydos schrieb: Nach meinem erneuten Playthrough der NLT bekam ich Lust, Riva mal in einer modernen Grafikengine zu betrachten.Das sieht tatsächlich mal richtig gut aus. 
"Haut die Säbel auffe Schnäbel."
01.03.2023, 21:13
Ich find's cool. Respekt, sehr beeindruckend.
01.03.2023, 23:04
Sieht gut aus! Und das ist dann in der Vollbildauflösung des Monitors gewesen?
"Alrik war durstig und hat getrunken."
02.03.2023, 11:03
Oh, toll. Was hast du verwendet, um die Daten zu laden und zu durchfliegen? Unity, Unreal, Blender?
Die der Götter Gunst verloren,
sind verfallen einer Macht - Die sie führt zu fernen Toren, und durch sie in ew'ge Nacht. 
02.03.2023, 13:07
Das ist ja richtig geil! Du hast also den Schritt gemacht, der mir noch nicht gelungen ist. Sehr cool
 Was meinen Renderer angeht: Das war ja eigentlich kein Renderer, sondern ein Exporter für Blender. Damit konnte ich die Vertex- und Face-Daten in Blender importieren. Daher kamen damals auch die Bilder (die jetzt nicht mehr da sind). Wenn ich mir Deine Bilder ansehe, wird mir sofort klar, dass dieser alte Code nichts beisteuern kann. Habe Ende letzten Jahres mal mit Ghidra die RIVA.EXE auseinandergenommen, um an den Code für das Rendering zu kommen. Ein paar Kleinigkeiten haben sich da ergeben, die ich im Wiki-Artikel zu 3DM auch eingebracht habe. Dort steht alles, was ich weiß. Von "gelüftet" kann man also nicht sprechen  Aber zusammen könnten wir das sicherlich gut nach vorne bringen! PS: Heute dachte ich mir, dass ich unbedingt nochmal nachsehen muss, was beim Crystal in seinen Foren abgeht. Und wie ich hier sehe, war der Wunsch genau passend
02.03.2023, 18:04
(Dieser Beitrag wurde zuletzt bearbeitet: 02.03.2023, 19:20 von cmfrydos.
Bearbeitungsgrund: Ergänzung zu Urheberrecht
)
Vielen Dank für die vielen positiven Rückmeldungen!
Größtenteils sollte das Lob natürlich an Attic gehen, da das Entwickler- und Arts-Team sich für 1997er Verhältnisse wirklich Mühe mit den vielen verhältnismäßig hochauflösenden Texturen gegeben haben. (01.03.2023, 23:04)Alrik Alrikson schrieb: Sieht gut aus! Und das ist dann in der Vollbildauflösung des Monitors gewesen? Ja, alle Bilder wurden im 3840x2080 Vollbildmodus aufgenommen, wobei ich eines auf HD runterskaliert habe. Das Programm unterstützt sowohl einen Fenstermodus in variabler Auflösung, als auch einen Vollbildmodus in nativer Auflösung des Monitors, und läuft mit konstant 60 FPS. Später kann ich noch Features wie einen rahmenlosen-Vollbild-Fenstermodus, variable Framerate und Grafikoptionen aus einem anderen Teamprojekt von mir kopieren, aber ich müsste wohl vorher noch etwas UI-System (Buttons, Panels, etc.) für ein Menü schreiben, oder einen Komilitonen bitten, ob ich seinen Code verwenden darf. (02.03.2023, 11:03)Alpha Zen schrieb: Oh, toll. Was hast du verwendet, um die Daten zu laden und zu durchfliegen? Unity, Unreal, Blender? Das Projekt habe ich in .NET C# erstellt, und als Engine benutze ich MonoGame (eine freie XNA Cross-Platform Implementierung). Das Framework ist einfacher als direkt OpenGL oder DirectX anzuprechen, aber nicht so komplex und "einschränkend" wie Unity oder Unreal. Dafür muss man aber alles was über Basisfunktionaliät geht selber schreiben. Um die Daten zu Laden, habe ich wie erwähnt die zusammengetragenen Infos und Entpacker hier aus dem Forum verwendet Rießen Danke dafür!.(02.03.2023, 13:07)Shihan schrieb: Das ist ja richtig geil! Du hast also den Schritt gemacht, der mir noch nicht gelungen ist. Sehr cool Mit Blender und 3D kenne ich mich leider noch nicht so gut aus, weswegen ich erst einmal MonoGame benutzt habe, das ich schon für einige kleinere 2D-Games benutzt habe. Wahrscheinlich bringst du da deutlich mehr 3D Knowhow als ich mit. Man könnte sicherlich einen Exporter in ein moderneres Format schreiben, falls das hilfreich ist. Ich freue mich, falls wir hier dann zusammen noch zu weiteren Erkenntnissen kommen So jetzt mal, was ich so (entgegen oder ergänzend zu den Infos im Wiki) herausgefunden habe. Die können gerne übertragen werden, oder mit einem Account könnte ich es auch selber machen. Außerdem mal alles, das noch Rätsel bereitet. Ich gehe mal in der Reihenfolge durch, wie man die Dateien am Besten lesen sollte: Zu meinem Viewer: Ich bezweifle, dass Hendrik und Helios hier noch regelmäßig reinschauen, deswegen werde ich u.A. einfach die beiden mit ihren Tools im Loadingscreen erwähnen. Etwas Bammel habe ich noch vor dem Urheberrecht von Attic an den Spieldaten, da es ja als Modifikation des Programmes zählen könnte (alter Code weg, neuer Code rein), was in vielen Fällen verboten ist. Das Riva HD Remake ist ja noch nicht ganz weg vom Crafty Studios Agenda, und haben damit sicherlich ein finanzielles Interesse daran, dass kein anderes Remake erscheint. Das hat Guido sogar mal geschrieben: https://www.crystals-dsa-foren.de/showth...t#pid22045 Aber da er hier das Forum kennt, weiß was wir in diesem Thread treiben, und sich noch nicht beschwert hat, hoffe ich, dass ein HD-Viewer, der hauptsächlich als Tool zum Erkenntnisgewinn dient, urheberrechtlich ok ist. Da steht was zu in Paragraph 69 glaube © Urheberrechtsschutzgesetz dass das OK sein könnte. Aber ich verstehe leider kein Juristendeutsch.. Seid ihr da besser unterwegs, und könntet das einordnen? Wenn ich den Thread richtig in Erinnerung habe, gab es sogar mal einen nachgebauten SchickViewer, was ja recht ähnlich ist. Also, wenns keine Einwände gibt, mache ich den Ladebalken/Credits noch fertig (bei mir lädt die Dungeons.ALF in 5-10s), und dann könnt ihr zum Wochenende mit den Binaries rechnen, um selbst mal durch alle Dungeons/Karten zu schauen.
04.03.2023, 09:01
Hier wie versprochen die Binaries. Ihr braucht dafür eine Riva CD, oder ein eingebundenes Image.
Ich bin mir nicht ganz sicher, wie das die verschiedenen Versionen lösen, aber ich denke das sollte überall mit dabei sein. Ich habe noch etwas mit der Maussteuerung zu kämpfen, da sollten noch Optionen kommen, um die anzupassen. Unter WSL Linux war die auch leider ziemlich verbuggt, hoffe es geht nativ. Ansonsten muss ich da nochmal ran. Vielleicht mache ich noch ein Video, um mal festzuhalten, an was noch geforscht werden kann. Ich habe richtig Lust auf Lighting, Shader und Collision. Auch könnte irgendeine Art Raytracing praktisch sein, um dann die Werte von dem Objekt anzuzeigen, auf das man gerade schaut. Download: https://github.com/cmfrydos/RivaHDViewer...ag/Alpha_1 
04.03.2023, 22:17
Du meinst eher Raycasting als Raytracing, glaub ich. Man könnte die Grafiken aber mit Displacement Maps (und Raytracing, wenn man es auf die Spitze treiben möchte) peppen, so ähnlich wie bei Minecraft.
05.03.2023, 12:18
Jep, Raycasting ist das Stichwort. Raytracing ist für Beleuchtung zuständig.
Hier gibt's einen tollen Artikel, der das Thema "object selection" ziemlich gut erklärt: https://antongerdelan.net/opengl/raycasting.html Werde die Tage mal Deine Infos in mein Github Wiki einpflegen. Was die rechtlichen Dinge angeht: Wenn man keine kommerzielle Absicht hat und versucht, keine Konkurrenz zu werden, sieht es etwas entspannter aus. Das Reverse Engineering ist durchaus in Europa (im Gegensatz zur USA) für Forschungszwecke ausdrücklich erlaubt. Und genau das ist der Hintergrund für mich gewesen, weil ich wissen wollte, wie eine 3D-Engine, die Integers anstatt Floats verwendet, wohl funktioniert Engine Reimplementation ist da leider etwas undurchsichtiger, einfach, weil das dazu bisher wenig Präzedenzfälle gibt. Aber wie oben gesagt, solange man niemandem auf die Füße tritt, sollte einiges möglich sein.
05.03.2023, 21:35
Ihr habt natürlich Recht, ich meinte Raycasting. Ein einzelner Strahl reicht,
Muss ja nicht durch Mandaras Spiegel die Welt untersuchen  .(05.03.2023, 12:18)Shihan schrieb: Das Reverse Engineering ist durchaus in Europa (im Gegensatz zur USA) für Forschungszwecke ausdrücklich erlaubt. Und genau das ist der Hintergrund für mich gewesen, weil ich wissen wollte, wie eine 3D-Engine, die Integers anstatt Floats verwendet, wohl funktioniert Wenn man es als Forschung betrachtet, denke ich auch, dass es rechtlich ok ist - immerhin lüften wir hier den ein oder anderen Nebel, und teilen unsere Ergebnisse:
Die Erkenntnisse zum Licht haben mir ziemlich die Nerven geraubt. Dass hier die Texturdaten X-Indizes innerhalb des aktuellen Helligkeitsverlaufes sind (Y kommt vom Grad der Beleuchtung), die dann wiederum die Indizes von den RGB-Farben sind, macht u.A. sinnvolles Mipmapping und Lineares/Anisotropes Samplen quasi unmöglich. Aber ich fande es mega spannend zu sehen, wie "Shading" unter DOS funktioniert haben könnte. Heute versteht man unter Shader den Code, der auf der Grafikkarte ausgeführt wird, aber ich denke mal dass man damals VGA-Karten nur ganz rudimentär ansprechen konnte  Da scheint mir dieses mehrfache Nachschlagen von ColorCodes, um Beleuchtung zu realisieren, doch recht smart.Als nächstes schaue ich mir mal an, ob ich die (externen) Lichter als Lichter in der .3DM identifizieren kann, und probiere mich damit mal an neuen Shadern.
07.03.2023, 06:14
Habe mir gestern noch die .NEI Dateien angeschaut. Steht wahrscheinlich für NEIghbours.
Da stehen in Textformat so Ketten an Zahlen drinnen. Beispiel BORON.NEI: Konnte es als Graph ausmachen, der von der Konnektivität und Zirkularität ziemlich gut zu der jeweiligen Karte passte. Dabei steht in der Datei die erste Zahl für einen Knoten, von dem jeweils eine gerichtete Kante zu allen in der Zeile folgenden Knoten besteht. Die Zahlen bezeichnen dabei eine Art Objektgruppe. In der .3DM haben die meisten Objekte so kryptische Namen wie "01N9999_w0". Die ersten zwei Ziffern benennen hierbei die Gruppe zu der das Objekt gehört. Die anderen habe ich noch nicht entschlüsselt.. Um die Theorie zu überprüfen habe ich mal für jede Gruppe jeweils eine Bounding Box um die enthaltenen Objekte gemacht, und dann die Boxen anhand der .NEI verbunden: Punkte sind Objekte, die Kästen die Objektgruppen, und Blaue Linien die Verbindungen. Ich gehe davon aus, dass dieser Graph Sichtbarkeit beschreibt. Beachte die fehlende Kante zum Grab der Feylamia, dieses befindet sich nämlich hinter einer Illusionswand. Offene Probleme: Eine Kante quer rüber ergibt leider keinen Sinn. Außerdem sind die Kanten gerichtet, wobei ganz wenige die entsprechende Rückkante nicht besitzen. Vielleicht heißt es dann sowas wie "wenn du im Gebiet der Gruppe XY stehst, kannst du ein Objekt der Gruppe ... sehen". Ganz selten geht das nämlich nicht beidseitig. Andererseits müssten dann die BoundingBoxes dieser Gruppen auch irgendwo beschrieben sein.. Wie diese Daten genau (und ob) benutzt werden, steht wohl in der RIVA.EXE.. Ich glaube aber, dass es bei den großen Karten durchaus sinnvoll ist zu wissen, welche Objekte man gerade überhaupt anschauen, updaten, und rendern müsste.
07.03.2023, 20:38
Kann gerade nicht wirklich viel Zeit für eine Antwort aufbringen, wollte aber ein kurzes Feedback dalassen:
Super Arbeit! Freut mich, dass du hier soviel weiter gekommen bist. Das Video ist großartig. Wenn ich mental wieder stabiler bin, sehe ich mit nochmal den Assembler-Code an. Die Stellen, wo die Dateien (.3dm, .nei, .dsc, ...) geladen werden, habe ich schon identifiziert. Danach gibt's aber ein paar indirekte Calls (passiert für gewöhnlich bei virtuellen Methodenaufrufen von C++), deren Nachverfolgung extrem hart ist und viel Debugging braucht, weil man das nur zur Laufzeit sehen kann. Daraus könnte man aber vielleicht ein paar Dinge ableiten, die mit reiner Analyse der Daten nicht sichtbar sind. Oder Vermutungen bestätigen. Wie gesagt, aktuell bin ich angeschlagen, aber ich halte die Augen offen und freue mich über Updates deines Fortschritts
08.03.2023, 13:14
(Dieser Beitrag wurde zuletzt bearbeitet: 09.03.2023, 17:59 von cmfrydos.
Bearbeitungsgrund: Ergänzungen wegen neuen Erkenntnissen
)
(07.03.2023, 20:38)Shihan schrieb: Kann gerade nicht wirklich viel Zeit für eine Antwort aufbringen, wollte aber ein kurzes Feedback dalassen: Danke! Mir macht das Knobeln an den Formaten gerade richtig viel Spaß. Das ist schon cool, wenn man nach längerem Probieren und Auswerten zu einer Lösung kommt. Naja das Video.. Ich wollte auf meiner Möhre kein 4k reencodieren, und war daher auf .mkv hintereinanderhängen beschränkt. Der langwierige Tag/Nachtwechsel in Riva nimmt da das Pacing raus, aber ich musste es mal festhalten, um das später schneller abzugleichen. Das ist überhaupt kein Problem, dass da gerade nicht die Zeit für dich ist, mitzutüfteln. Deshalb halte ich den Progress hier auch fest, damit später, wenn auch erst in ein paar Jahren, daran weitergearbeitet werden kann. Ich denke für mich ist in Riva bald Schluss. Vielleicht schaue ich mir das 3D in Schweif noch an. Zu Riva habe ich leider (noch) nicht die Skills und Tools, um da in Asm Dinge herauszulesen. Spannend finde ich es, aber ich wüsste nicht, wo man anfangen soll. Da dutzende Register und Speicherstellen im Auge zu haben, und überhaupt grob zu verstehen, was dort passiert, ist schon eine hohe Kunst. Und wie überhaupt kann man das Debuggen, wenn das Programm nur in der DOSBox läuft? Dann muss man sicherlich auch die Tools für DOS haben, und darin debuggen? Ich konnte mal noch teilweise den unbekannten Datenblock in der .3DM entschlüsseln: Da stehen wie erhofft die Lichtquellen drin! Aber ich vermute fast, noch mehr. Zumindest beim manuellen Nachzählen in den Leveln kam ich nicht ganz auf die Zahl der Einträge (EDIT: Habe die zwei Tageslichteinfälle (Leiter / Feylamia) vergessen. Scheint jetzt zu passen, und gehe davon aus, dass im unbekannten Datenblock nur die Beleuchtung steckt). Spannend wird sein, was der Marker U1 bedeutet. Auch die Daten in U2 und U3 könnten interessant sein. Was für Daten könnte eine Lichtquelle tragen? Richtung geht schlecht, da es nur nach 2 Integern aussieht. Vielleicht zwei begrenzende Radii der (flackernden) Lichtkugel? EDIT: Scheint genau das zu sein . In der Boronsgruft gibt es zwei Fackeln, die besonders abweichen:- Eines im ersten Leichenraum, das besonders hell ist (mit hohen U2 und U3-Werten) - Und eines im letzen kleinen Raum mit dem Fass, dass sehr dunkel ist (mit kleinen U2 und U3-Werten). U2 und U3 liegen auch immer recht nah beieinander. Es gilt immer entweder U2 == U3 == 0, oder U2 < U3. In Riva gibt es auch immer 2 Lichtintensitäten, zwischen denen die Lichter "flackern". Wahrscheinlich sind es genau die. Ich halte mal die Augen offen, ob ich auf anderen Karten Lichtquellen finde, bei denen U2 und U3 relativ identisch, oder besonders weit auseinander liegen. Eine Ausnahme gibt es noch: Ein Eintrag in STAR02 (die versunkene Abendstern) hat viel mehr Daten, als alle anderen Einträge. Das ist wohl ein Licht(?), das relativ weit außerhalb des Schiffes, wenn man in in der Mitte des ersten Raumes steht, etwa in Richtung der Ecke rechts überhalb des Ausganges positioniert ist. Habe glaube ich keinen Speicherstand direkt davor. Vielleicht scheint dort eben ein ganz spezielles Licht durch das löchrige Schiff. Ich habe in der Tabelle alle Daten, die nur für dieses eine Licht vorhanden sind, mit * markiert. EDIT: Da ist nichts. Es ist technisch gesehen aber auch eine Tages-"Nebel"-Karte (der blau ist), dh. dort gibt es gar keine Lichter bis auf die globale Beleuchtung. Eventuell steuert es aber genau diese, wobei die Position dann egal ist. Denn auf vielen "Nebelkarten" gibt es missplatzierte Lichter, zB. im Boronsacker, die keine Fackeln oÄ bei Nacht darstellen können. Interessanterweise gilt bei dem Licht U2==0==U3, was ja vermutlich die Leuchtkraft darstellt. Eventuell auch einfach nur ein Überbleibsel von einem Versuch der Entwickler, die globale Beleuchtung durch eine positionierte Sonne zu realisieren? ------------------------------------------------------------------------------------------------------------------------------------------------------------ Off Typ Name Anmerkung ------------------------------------------------------------------------------------------------------------------------------------------------------------ 0 short NameID Als String-Verweis in die String-Tabelle. Hier werden jetzt die bisher unbenutzten Einträge in der String Tabelle benutzt 2 char[4] Enabled Immer 0x00000101, falls Daten vorhanden. Jede Karte hat am Anfang immer 3 leere Einträge stehen 6 short Typ Immer 1 - Nur einmal 3 in STAR02* 8 short Gruppe Damit startet auch der Name, wenn nicht mit "Light" (nur einmal nicht, da startet der Name mit xx) 10 short U1 Entweder 44, 63 oder (nur in MAGT03) manchmal 17 12 int STAR02D1 Immer 0 (fast*) 16 short Null Immer 0 18 short Light? Meistens 0. Wenn der Name mir "Light" startet, immer 1. Manchmal auch sonst 1, dann steht aber immer ein L im Namen 20 int U2 Unbekannt. Fast immer mit Daten voll. EDIT: Ziemlich sicher 1. (geringere) Leuchtintensität / Reichweite 24 int U3 Unbekannt. Fast immer mit Daten voll. EDIT: Ziemlich sicher 2. (stärkere) Leuchtintensität / Reichweite 28 char[8] STAR02D2 Immer 0 (fast*) 36 int X X - Koordinate 40 int Y Y - Koordinate 44 int Z Z - Koordinate 48 char[40] STAR02D3 Immer 0 (fast*) ------------------------------------------------------------------------------------------------------------------------------------------------------------ Die Namen der Einträge tragen als ersten Buchstaben (hinter der Gruppennummer), immer entweder ein F oder L, wenn sie nicht mit "Light" beginnen. Das gesamte Namenschema, das auch Objekte tragen, würde ich gerne noch knacken.. EDIT: Fackeln tragen bisher immer ein F, Sonnenlicht/einfall ein L oder "Light" Ich denke ich gehe mal so vor, dass ich ein Lichtsystem/-shader in meine Engine einbaue, alle Einträge an ihrer Koordinate platziere, und dann einfach mal gucke, ob was leuchtet, dass nicht leuchten soll  EDIT2: Weil es nur eine kleine Sache ist als edit: Dass genau die .NEI bestimmen, welche Nachbar-Objektgruppen gezeichnet werden, hat sich bestätigt. Entfernt man zB. in der Stadt alles aus der .NEI, wird immer nur die aktuelle Gruppe gezeichnet. Kollision scheint aber von allen Gruppen aktiv zu sein. Auch interessant: Die Gruppengrenzen haben stark etwas mit den Zufallsbegegnungen zu tun. Also zB. Käsetoast, oder dass die Wachen an einem vorbeilaufen. Wenn man eine Gruppe wechselt, wird es sehr oft getriggert. Manchmal aber auch, wenn man eine zu einer Geraden erweiterten Linie anderer Gruppen übertritt. Das aber nicht bei allen, was mich etwas wundert. Aber evtl werden hier einfach sowohl X-Grenzen als auch Y-Grenzen sortiert gehalten, und wenn sich eine wechselt, kann es zu einem Wurf für eine Zufallsbegegnung kommen. Gruppen können sich auch überlappen. Ich bin mir noch nicht ganz sicher, wie gehandhabt wird, wenn man sich in mehreren Gruppen befindet. |
![[+]](images/collapse_collapsed.gif "[+]")
Spoiler
). Damit wird die Beleuchtung realisiert. 
. Anders kann ich mir das hier nicht erklären: SEWER01.PAL:
. Benutzer, die gerade dieses Thema anschauen: 3 Gast/Gäste