Tehadon

Kommentare anzeigen Worklog abonnieren
Gehe zu Seite Zurück  1, 2, 3, ... 10, 11, 12  Weiter

Worklogs Tehadon

Skybox und das kühle Nass

Sonntag, 21. Juni 2009 von peacemaker
Wird echt mal wieder Zeit für einen Eintrag.
Ich muss gestehen, viel hab ich nicht gemacht. Recht wenig Zeit, gepaart mit der Lustlosigkeit, die durch meinen verdammt langsamen PC aufkam, war ich längere Zeit nicht mehr aktiv.
Nun habe ich wieder etwas Zeit gefunden, an Tehadon zu werkeln und diesen Eintrag zu machen.
Als erstes hab ich die Skybox gewechselt, und diese etwas noch besser angezeigt. Seit einiger Zeit nämlich, waren die Ecken immer sichtbar.

Das hat dann etwa so ausgesehen:

user posted image

Dann hab ich etwas gemacht, was für die Insel an der wir gerade arbeiten unumgänglich ist: Wasser!
Eine zeitlang war es hardcoded, das hab ich dann entfernt, und es nun wieder um Längen besser eingebaut.

Meerwasser wird komplett in der Mapdatei gemacht. Jede Mapdatei (TMF) hat einen Header, in welchem verschiedene Mapspezifische Dinge gespeichert sind. Dazu gehören Skybox, Gravitation, oder eben auch das Meer.
Das würde dann so ausschauen:
Code: [AUSKLAPPEN]

Header
{
 waterTexture = data\gfx\mesh\static\water.JPG;
 seaWaterY = -392;
}

Das Meer wird dann an der Y-Position -392 positioniert.
Es wurd jedoch nur ein Meer erstellt, wenn der Wert 'seaWaterY' existiert.

Sehr wahrscheinlich werde ich später noch machen, das es im Skript, bei der 'TmfWorld'-Klasse noch ein Event namens 'onSeaCreate' gibt, welches mit dem B3DEntity der Seeplane gestartet wird. Damit kann man dann noch ein paar erweiterte Dinge machen, aber das wird wohl selten nötig sein.

Ich habe mehrere verschiedene Texturen ausprobiert, hier mal zwei Versionen:

user posted image

user posted image

So viel erstmal dazu, in Kürze mehr.

mfG

Scripting, Bugs

Donnerstag, 21. Mai 2009 von Jo0oker
Scripting, Bugs

Es wird Zeit von Marodiin zu berichten.

Da wir nun mit den ersten Locations in Tehadon beginnen wollen, darf Scripting natürlich in Marodiin nicht fehlen. Im moment bin ich dabei, die beste Variante rauszufinden, da ich gerne das Scriptsystem in C# schreiben will, es aber später nur ein Programm geben soll, und man alles in einem übersichtlich und schön hat.
In dem C# Editor geht schon Highlighting, registrieren von Variablen, Funktionen und dynamische größenveränderung der Fensters(die Elemete werden angepasst).
In Marodin kann man bereits bequem NPCs erstellen, hier mal von beidem ein Screenshot:

user posted image
user posted image

Der C#-Scripteditor wird über UDP mit Marodiin kommunizieren, über die Abhängigkeit voneinander bin ich mir noch nicht ganz klar.


Außerdem gab gibt es einige Bugfixis und Neuerungen:

Neuerungen:

-Meshterrains laden/speichern
-Ein Toolsystem, es wird ein dynamischer Eintrag im Menu gemacht, von wo aus man ein Tool starten kann.
-2 Tools wurden dazugetan(Ein tool um Bilder nach einem Raster zu teilen, und ein Meshviewer)
-Außerdem kann man Tehadon aus Marodiin heraus starten. So kann man in Zukunft das Programmiertes gleich testen.
-Nav files gehen nun auch. Diese sind dazu da, Wege in Form von Waypoints zu erstellen. Allerdings werden diese in einer extra datei gespeichert.

Bugfixes

-Tmf-Loader gibt nun detailliertere Fehlermeldungen und stürzt nicht mehr ab.
-Performance verbesserung
-Waypointbug behoben(Positionierung war falsch)

Hier noch ein paar weitere Screenshots:

Navigationseditor und Meshterraineditor:
user posted image
user posted image
Und zum Schluss ein Bild mit dem Toolmenu und der Tools.ini,
in der die Tools geladen werden:
user posted image

MfG

Innenräume

Montag, 18. Mai 2009 von peacemaker
Mal wieder Zeit für einen Eintrag.

Wir sind nach wie vor beim Einbau der ersten Storylocation, des Gefängnisses. Es wurden nun einige Dinge nötig, die ich einbauen musste, und dazu gehört sicherlich auch, endlich Innenräume richtig zu unterstützen.
Gesagt getan, das funktioniert schonmal. Der Charakter richtet sich korrekt am Boden, und jetzt gibt es auch so einen Sensor, ein virtuelles Objekt welches in bestimmtem Abstand vor dem Spieler ist und die Umgebung abtastet.
Wofür?
Der Spieler wird immer zuoberst auf dem Objekt positioniert, auf welchem er ist. Läuft man jetzt in eine steile Wand, hebt es den Spieler meterhoch in die Luft. So hingegen, wird immer die Differenz zwischen Spieler Y und PunktY auf dem Objekt geprüft. Ist sie zu gross, kann der Spieler nicht mehr weiterlaufen. Simpel.
Auch die Kamera stört nicht mehr so gross in innenräumen. Sie sollte jetzt nicht mehr hintern Wänden verschwinden, sodass man den Spieler nicht mehr seht, und nur die Wand.

Was noch fehlt sind Viewzones für Eingänge. Das werden unsichtbare Objekte sein (in Gothic 2 hiessen die Teiler 'Portale'), die dafür sorgen, das nur das gerendert wird, was wirklich nötig ist. Ist man in einem Haus drin und kann nicht rausschauen bringt es nichts, wenn die Objekte gerendert werden.
Man könnte jetzt einfach immer alle Objekte durchgehen und alle Unsichtbaren Objekte Hiden. Eigentlich recht simpel, nur wieder unnötiger Zeitverlust.

Diese Viewzones haben immer einen Trigger. Aktiviert man diesen, werden alle Objekte geprüft, und ausgeblendet. Und: es werden alle Objekte ausgeblendet, welche sich nicht innerhalb der Zone befindet. Zonen sind einfach beispielweise Cubes, welche ein Haus darstellen (natürlich unsichtbar).
Das ganze ist noch etwas theoretisch, und es gibt ein Problem: Schaut man von innen durch die Tür, sieht man draussen einfach nichts ausser den Himmel. Das ist etwas gefährlich.

Zum Schluss noch ein paar Bilder. Das Gebäude das da zu sehen ist, ist von mir, also nicht über die 'hohe' Qualität wundern :biggrin:

Zuerst noch ein Bild vom Strand:

user posted image

(Ist schon etwas dunkel)

user posted image

user posted image

Gefängniszelle in Marodiin

user posted image

mfG

Einige Dinge

Mittwoch, 6. Mai 2009 von peacemaker
Wieder einmal liegt der letzte Eintrag zurück. Das ist nicht weiter verwunderlich, ich find nämlich kaum Zeit längere Einträge zu verfassen, dem Projekt tut dies jedoch keinen Abbruch, das wird natürlich weiter entwickelt.
Zuerst einmal haben wir dank Jo0oker nun ein neues SVN-Repository. Nun können wir auch die restlichen Files, also Meshes, Skripte, etc. über SVN handhaben. Das ist in der Editing-Phase sehr praktisch, da nun alle immer Zugriff auf die neusten Meshes haben, und auch auf die neuste Version von Tehadon.

Ich habe weiterhin an Magie-System gewerkelt, und einige neue Flags hinzugefügt. Des weiteren gibt es nun auch Explosionen! Es gibt beispielweise Spells die beim Aufprallen explodieren. Explosionen sind nicht nur Partikeleffekte sondern haben auch weitere Eigenschaften. Beispielweise physikalische Auswirkungen. Alle Objekte die in der Nähe stehen, werden davongeschleudert. Alle NPCs die da in der Nähe stehen, kriegen Leben abgezogen. Der Spieler natürlich auch.
Bilder dazu hab ich keine, denn mir ist aufgefallen das wirklich schicke Explosionen mit der Devil PFX kaum hinzukriegen sind. Da werd ich vermutlich die Tage was eigenes machen, aber das ist erstmal nicht so wichtig.

Wir haben uns nun entschieden die erste storyrelevante Location einzubauen, die auch ins Spiel kommt. Das bedeutet nun, das wir langsam in die Editing-Phase rüberwechseln. Ich denke wir sind genug weit, um diesen Schritt zu wagen, immerhin funktionieren viele Systeme schon gut.
Diese erste Location ist die Gefängnisinsel, in welcher der Spieler aufwacht, und abhauen muss. Es soll jedoch noch einige Quests dort geben, bevor man abhaut.

Grosserboss hat dazu mal ein paar Mauerelemente gemacht.

user posted image


Quantarie, unser Terrain-Mann hat das Terrain-Mesh so weit, das es benutzbar ist. Fertig texturiert ist es noch nicht ganz, denn die Übergänge fehlen noch.



user posted image

user posted image

user posted image

Kommentare sind erwünscht,
mfG

HDSS: Release #1

Sonntag, 26. April 2009 von peacemaker
Ich habe soeben einen ersten HDSS-Release samt Api gemacht. Somit kann jeder HDSS in sein Projekt einbinden.
Weitere Infos gibt es im Projektthread.

mfG

Gottes Werkzeug

Samstag, 18. April 2009 von peacemaker
Zum 100. Worklog-Eintrag haben wir uns etwas besonderes überlegt. Demo? Nun, dazu fehlen noch einige Dinge, und auch Bugs gibt es noch reichlich. Was also? Die Antwort kommt gleich, aber zuerst ein bisschen blabla, worums überhaupt geht.
Vielleicht erinnert sich der ein oder andere noch an den T-Editor. Der Editor, mit dem die Maps für Tehadon gebastelt wurden (hier ein paar Bilder). Vielleicht ist auch aufgefallen, das ich schon lange nichts mehr davon erzählt habe.
Vor mehr als einem halben Jahr hat sich Jo0oker bei uns als Tool-Programmierer beworben. Da ich immer weniger Zeit hatte, mich um den Editor zu kümmern, hab ich mir gedacht das er das machen könnte.
Leider ist mir dazumal auch aufgefallen, dass der T-Editor, so gut er geplant war, trotz allem viele Bugs hatte, und auch die WinBlitz3D-GUI hat sich als reichlich verbuggt erwiesen. Neuanfang? Ja, wieso nicht, jetzt wo wir einen neuen Mitarbeiter hatten, der sich nur darum kümmern konnte.
Also begann eine umfangreiche Planungsphase, in der wir uns einige Dinge zum neuen Editor überlegten. Der Name stand schnell fest: Der Gott, der nämlich die Welt von Tehadon erschuf heisst Marodiin, also nannten wir den neuen Editor auch so.

Ich hatte einiges dazu gelernt, bei den 3 Editoren, die ich für Tehadon schon angefangen habe. So war Plugin-Fähigkeit von Anfang an bei Marodiin ein grosses Thema. Leider fehlen BlitzBasic dazu viele Sprachelemente wie z.B. Funktionspointer, sodass sowas reichlich schwer ist.
Zu dieser Zeit war die HDSS-Skriptsprache relativ weit fortgeschritten, wesshalb wir uns dann auch recht schnell entschieden diese auch in Marodiin zu verwenden, um eine Plugin-Architektur zu ermöglichen.
Dann ist relativ schnell auch die Frage nach der GUI aufgetaucht. Welche nutzen? Es war wichtig hier eine gute GUI zu wählen, da dies einer der Hauptpunkte für die teilweise miserable Bedienung des T-Editors war.
Die Wahl fiel dann auch bald mal auf die Xlnt II. Diese ist gut zu bedienen, hat einen einigermassen ansehbaren Code und besitzt viele nützliche Features.

So, in der Zwischenzeit wurde Marodiin im Stillen von Jo0oker beinahe komplett aufgezogen, und kann auch schon so ziemlich alles was der T-Editor konnte, und noch vieles mehr. Alle grundsätzlichen Dinge wie Objekte verschieben / skalieren / drehen, TMFs laden und speichern, Waypoints setzen, Heightmaps setzen, und noch vieles mehr, funktionieren. Sehr gut sogar, und vor allem schick und bequem zu bedienen.

Eine Neuheit ist beispielweise der Projektbrowser. Dort werden alle Dateien die in dem konfigurierten Arbeitsordner sind, angezeigt. Handelt es sich dabei um ein Mesh, kann man es ganz einfach in die 3D-Ansicht rüberziehen, ist es eine Heightmap, öffnet sich der Heightmap-Editor.

So, zuerst einmal ein paar Bilder.

user posted image user posted image user posted image user posted image user posted image

user posted image user posted image user posted image user posted image

Und nun könnt ihr euch selber auch noch von Marodiin überzeugen. Jo0oker hat nebenbei auch noch einen Updater gemacht, der euch automatisch die neuste Version die auf dem Repository liegt, downloaded. Auch ein Konfigurations-Tool gibt es, welches die Konfiguration stark vereinfacht.

Download

Die Bedienung ist relativ einfach, trotz allem hat Jo0oker einige Video-Tutorials gemacht, welche hier zu finden sind.

Kommentare sind ausdrücklich erwünscht, bei Fragen oder sonstigem Feedback wendet euch an uns.

mfG peacemaker

Lebenszeichen

Samstag, 4. April 2009 von peacemaker
Hallo,
wiedermal ist einige Zeit vergangen, wesshalb ich mir wieder etwas Zeit nehme, einen Eintrag zu machen.
Ich hab weiterhin am Magie-System gewerkelt, es gibt jetzt schon einige neue Details.
Beispielweise kann ein Zauber ein Fliegverhalten haben. Das sagt aus, ob er seinem Ziel (falls vorhanden) folgt, falls ja, wie lange, und noch andere Dinge die so nötig sind.

Hier ein Skriptausschnitt der nötig ist, um eine Feuerkugel zu machen:

Code: [AUSKLAPPEN]

// Partikeleffekt
$PFX_FireSphere = new (pfx);
$PFX_FireSphere->texture = "data\gfx\particle\Particle_008.png";
$PFX_FireSphere->SetTemplateColor (255,0,0,255,0,0);
$PFX_FireSphere->setParticleLifetime (10, 25);
$PFX_FireSphere->setVel (0,0,0,0,1,5);
$PFX_FireSphere->interval = 1;
$PFX_FireSphere->alphavel = 1;
$PFX_FireSphere->SetParticleSize (32, 32);

$SpellFireSphere->name = "Zauberkugel";
$SpellFireSphere->description = "Eine magische Kugel die erheblichen Schaden macht.";
// Beim beschwören:
$SpellFireSphere->onActivate = fref (spellFireSphere_onActive);
$SpellFireSphere->activePfx = $PFX_FireSphere;

// -----------------------------------------------------
// beim fertigen beschwören:
void spellFireSphere_onActive ()
{
   message ("Beschwöre magische Kugel");
};
// -------------------------


Das schaut dann so aus:

user posted image

user posted image

Ansonsten ist nicht wirklich viel geschehen, ich hatte kaum Zeit. Hier noch drei Screenshots auf denen ein paar neue Baummodelle zu sehen sind:

user posted image

user posted image

user posted image

mfG

Magie und TMF

Samstag, 21. März 2009 von peacemaker
So, weiter gehts.

Ich habe nun grosse Teile des Magiesystemes implementiert. Man kann schon Zauber beschwören, welche schon einige Attribute / Funktionalitäten haben. Das Magiesystem ist bisher noch relativ simpel: es gibt die Zauber, die man in seinem Zauberbuch auswählt. Nun kann man, wenn man genug Mana hat, diese beschwören (gelingt nicht immer), woraufhin dann der Zauber ausgeführt wird.
Wie immer wird das extern geskriptet, hier mal eine Feuerkugel:

Code: [AUSKLAPPEN]

$SpellFireSphere = new (spell);
$SpellFireSphere->name = "Zauberkugel";
$SpellFireSphere->description = "Eine magische Kugel die erheblichen Schaden macht.";
// Beim beschwören:
$SpellFireSphere->onActivate = fref (spellFireSphere_onActive);
// Beim Treffen
$SPellFireSphere->onHit = fref (spellFireSphere_onHit);

// -----------------------------------------------------
// beim fertigen beschwören:
void spellFireSphere_onActive ()
{
   message ("Beschwöre magische Kugel");
};
// -----------------------------------------------------
// wenn die Zauberkugel getroffen hat
void spellFireSphere_onHit ()
{
   $other->live = $other->live - 20;
};


Die Zauber besitzen immer ein virtuelles Objekt (ein 3D-Pivot), welches das Zauber-Objekt darstellen. Will man nun, dass während des Fliegens ein Feuerschweif hinterherkommt, muss man beim onActive-Event (wenn der Zauber erfolgreich beschwört wurde), einen Partikeleffekt an das Zauberobjekt hängen.
Partikeleffekte werden ja über die PFX-Klasse gehandhabt (siehe hier).
Geschwindigkeit, Bewegungsrichtung, und noch einige Attribute mehr des Zauberobjektes lassen sich einstellen. Das Zauberobjekt ist eine Instanz der B3DEntity-Klasse, wesshalb man es auch manuell verschieben kann, und die Methoden davon anwenden.
Es gibt auch ein onMove-Event, welches für jeden Frame festgelegt werden kann, um die Flugbahn etc. definieren zu können / es manuell zu verschieben. Ich rate jedoch von deren Benutzung ab, da bei vielen Zaubern da, trotz der hohen Geschwindigkeit von HDSS, einige Performance-Einbussen bemerkbar werden.
Ein Bild hab ich dazu nicht, aber ihr werdet schon bald eines davon kriegen.

Bisher kann nur der Spieler Zauber beschwören, das entsprechende State für NPCs ist jedoch schon drinnen.

Dann steht da noch TMF. Ich habe tatsächlich das komplette Mapsystem auf den Kopf gestellt, und die interne Struktur komplett verändert. Jetzt ist auch asynchrones Nachladen einzelner Mapsektoren im Spiel möglich. Das geschieht immer über mehrere Frames verteilt. Blitz besitzt zwar keine Möglichkeit mit Threads zu arbeiten, aber durch das Verteilen ist das Nachladen im Hintergrund kaum zu bemerken.
Das ganze funktioniert so, das einfach pro Frame immer die TMF_Update-Funktion aufgerufen wird. Diese besitzt beispielweise 5 Millisekunden pro Frame. Also wird immer genau so viel geladen, was man in 5 MS laden kann. Dieser Wert ist flexibel, und kann varieren. Bei grossen Mapsektionen kann man den Wert beispielweise hochschrauben, und so während des Ladens nur beispielweise 24 FPS, anstatt 30 zu nutzen. Desto grösser der Wert, desto schneller ist der Sektor geladen, desto mehr Zeit geht jedoch da hin, folglich sinkt die FPS-Rate.
Natürlich kann man immernoch synchron einzelne Sektoren in einem Frame laden. Das wird beispielweise zu Beginn gemacht. Dann erscheint auch ein Ladebildschirm.

Das geschieht dann so:
Code: [AUSKLAPPEN]

// Lädt die ganze Datei und die Sektoren ein
TMF_LoadFile ("testmap.tmf")
// Wählt einen Sektor
TMF_SelectChunk (TMF_GetChunkByName ("root"))
// Lädt die TMF-Datei und wählt den Sektor-Block aus
TMF_LoadSelectedChunk ()
// Führt nun den gesamten Sektor aus
TMF_ExecuteChunk (g_pMap, 0)


Die TMF-Files sehen immernoch gleich aus:
Code: [AUSKLAPPEN]

SECTOR (0,0,0,10000, "root")
{
 // Hier steht alles Content-Zeugs (Meshladen, etc)
};

Die SECTOR-Anweisung hat 5 Parameter: die ersten drei sind die Koordinaten, des Hauptpunktes, von wo immer geprüft wird, ob der Spieler drin ist, um es nachzuladen.
Der vierte Parameter definiert die grösse des Sektors. Der fünfte ist die ID, bzw. der Name des Sektors. Wenn ihr mal genau hinschaut, werdet ihr merken, dass oben beim Laden der Map bei der TMF_SelectChunk als Parameter TMF_GetChunkByName ("root") steht. Das liefert einfach die Instanz des Sektors zurück.

Ich denke das reicht erstmal,
mfG

Fernkampf, Level, ...

Dienstag, 17. März 2009 von peacemaker
Nachdem der Worklog nun längere Zeit geschwiegen hat, wird es mal wieder Zeit ein paar Infos rauszulassen. Es sind wieder nur kleine Dinge, teilweise sogar unfertig.
Zum einen hab ich angefangen den Fernkampf, also die Möglichkeit beispielweise mit Pfeil und Bogen rumzuhantieren gemacht.
Ich hab mich mal rangesetzt und schonmal hingekriegt, das der Spieler nen Bogen in die Hand nehmen kann. Und auch das ganze Zeugs drunter, wie das Laden und Verwalten, die Munition, usw. steht schon.
Beispiel, wie ein Bogen erstellt wird:

Code: [AUSKLAPPEN]


$pfeil = new (item);
$pfeil->meshPath = "data\modelle\item\FK\ITEM_FK_Pfeil.B3D";
$pfeil->name = "Pfeil";
$pfeil->flag = ITEM_FLAG_WEAPON_COUMPOUND_MUNITION;
$pfeil->value = 12;

$bogen = new (item);
$bogen->meshPath = "data\modelle\items\FK\ITEM_FK_Compound.B3D";
$bogen->handslot = "hand_slot";
$bogen->name = "Holzbogen";
$bogen->value = 55;
$bogen->flag = ITEM_FLAG_WEAPON_COMPOUND;
$bogen->munition = $pfeil;

Recht simpel soweit. Das einzig Neue ist dieses "munition". Dort legt man fest, welches Item ein anderes Item verschiesst. Kann ja auch sein das eine bestimmter Bogen nur verzauberte Feuerpfeile verschiesst, etc.

Jetzt gibt es auch Level. Das Level erhöht sich immer wenn genug Erfahrungspunkte vorhanden sind. Diese bekommt man beispielweise durch Lösen von Quests, oder durch töten von NPCs / Tieren. Das ist dort dann davon abhängig, wie stark das Tier oder der NPC war.
Die Formel selber für den Levelaufstieg ist einfach:
Code: [AUSKLAPPEN]

this\nextLevelExp = this\experience + (this\experience*2.5)

nextLevelExp beschreibt, wieviel gebraucht werden, um zur nächsten Stufe zu kommen. Der Wert 2.5 ist einfach konstant. Je kleiner der Wert ist, desto schneller gehen die Levelaufstiege. Mit diesem Wert müssen wir dann später herumexperimentieren.
Wenn der Spieler aufgestiegen ist, bekommt man ja üblicherweise ein paar Punkte gutgeschrieben die man dann auf seine Fertigkeiten verteilen kann. Man könnte es auch so machen, das man bei jedem Aufstieg Lernpunkte kriegt, die man dann bei irgendnem Lehrer investiert, der einem das oder das lernt.
Man könnte auch machen das sich diese Fähigkeiten immer dynamisch verteilen. Wer mehr mit dem Schwert kämpft, wird hier beispielweise die besseren Werte haben, als mit dem Bogen, den er fast nie berührt. So ganz in "Übung macht den Meister"-Manier.
Eure Meinungen sind gefragt!


mfG

Ein paar Dinge

Samstag, 7. März 2009 von peacemaker
Quantarie hat sich mal wieder etwas aktiv gemacht, und ein Schwert für Intenare gebastelt. Das ganze hat 300 Polys.

user posted image

Dann hat noch psychokill, einer aus der Community, einen Inventar-Entwurf gebastelt. Weil der mir so gefallen hat, poste ich ihn auch gleich mal:

user posted image

Falls das ganze umgesetzt wird, werden die Item-Kästchen etwas kleiner werden, und eventuell das gesamte Fenster grösser.

Dann noch was aus meinem Tätigkeitsbereich. Ich habe nun wieder Kollision Spieler/NPC zu Umgebung eingebaut. Jetzt kann der Spieler mal wieder nicht durch Bäume etc. laufen.
Auch die Kamera hab ich etas angepasst. Jetzt sollte es nicht mehr passieren, dass sie einfach hinter einer Wand verschwindet. Es gibt aber immernoch genügend Bugs, manchmal verhängt sie sich in den Baumkronen, und dann kriegt man sie nicht mehr wieder raus.
Auch die Steuerung wurde komplett auf den Kopf gestellt. Die Bugs der letzten Techdemo, beispielweise das fehlerhafte ziehen der equippten Waffe, sind behoben. Auch das herumlaufen etc. ist etwas besser geworden.

Dann hab ich der Webseite noch eine weitere Sektion hinzugefügt: Tagebuch. Dort wird monatlich ein kleiner Überblick zum Stand abgegeben. Dabei ist das ganze nicht so technisch wie der Worklog verfasst, sodass auch normale Leute das ganze begreifen.
Hier gehts zur Tagebuch-Sektion.

mfG

Gehe zu Seite Zurück  1, 2, 3, ... 10, 11, 12  Weiter