Naja, dann probier mal!
Wenn du noch fragen hast, werd ich sehen ob ich dir vielleicht helfen kann!
*ab ins Bett*
MfG
Naja, dann probier mal!
Wenn du noch fragen hast, werd ich sehen ob ich dir vielleicht helfen kann!
*ab ins Bett*
MfG
Juhu
Mir ist aber etwas aufgefallen: Das man es später noch einbauen kann, ist sicherlich kein Problem. Aber man sollte etwas beachten, nämlich: Hat man zB. auf einer Map einen Lichteffekt als Show Picture im Parallelen Prozess laufen, muss dieses eine höhrere ID haben als die Pictures im Menü. Hat man zB. 4 Bilder insgesamt im Menü, so muss überall, wo ein Bild auftaucht (zB. Lichteffekt) dieses auf ID 5 gesetzt werden, sonst ist das Menü nicht aufrufbar. Oder man deaktiviert eben das Menü dann.Zitat
Ja klar!
Nun hab ich aber immernoch Fragen zum Logbuch: Dieses funktioniert ja ähnlich einem Menü, weil man eben darin auch navigieren kann. Deshalb kann ich mir immernoch nicht vorstellen, dass dafür ein Common Event ausreicht. Das Menü alleine braucht ja schon 3 Events + je ein Event für je einen Menüeintrag.
--
Ich schreib mir das immer auf, welche Picture,w elche ID haben, dann kann nix passieren! ^^
Warum nicht?
Nimm ein Comment Event und stell die Start Kondition auf "Rufen"
Dann machst du immer Forks in denen Abgefragt wird, ob der Switch/Variable An/Aus ist/welchen Wert die Vari hat.
Darunter kommt dann einfach der restliche Code.
Das ist nicht schwer!
Hallo,
du meinst ein Common Event, wo per Forks alle Variablen abgefragt werden und am Schluss dieser "Abfrage" dann der Code, der die bestimmten Aufgaben und Bilder dann anzeigt, je nachdem welche Variable aktiv ist?
OK, dann versteh ich schon so ungefähr. Muss es nur mal umsetzen und probieren ...
--
Ein Logbuch...
In deiner PN hast du ja angesprochen, dass du es so haben willst, dass die Aufträge in der Reihenfolge aufgelistet werden wie man sie findet (nach Datum sortiert zozusagen).
Ich werde mal versuchen das so gut wie möglich zu erklären.
Um ein vernünftiges Logbuch zu bauen brauchst du als erstes eine "Liste" in der du die Aufträge, bzw. deren IDs einträgst. Ich werde als Beispiel diese benutzen:
Die Zahl steht natürlich jeweils für die ID welche dieser Auftrag im Maker hat. Am besten legst du dir gleich eine Liste (z.B. in Word) an in der du alle Aufträge mit Erläuterung abspeicherst.
Die Liste im Maker lässt sich am besten durch eine Reihe von Variablen (z.B der Bereich von Variable 100 bis Varibale 200) herstellen. Jede dieser Variablen hat nun einen Wert. Zu Beginn des Spiels ist dieser Wert 0. Bekommt man den ersten Auftrag wird die Variable 100 auf die ID dieses Auftrages gesetzt. Beim zweiten Auftrag entsprechend die Variable 101.
Problem bei der Sache ist nun, das es sein kann, das der Variablenplatz aufgebraucht wird. Daher empfiehlt sich, bei z.B. Variable 1000 anzufangen und bis 1300 freizulassen (nur für alle Fälle).
Es ist nun also sehr wichtig, das diese Variablen auch nur von den Aufträgen und deinem Questlog angetastet werden. Ansonsten heißt es "Finger weg!".
So, wie genau sieht jetzt ein einzelner Auftrag aus, bzw. woraus besteht er?
Wir haben also nun unsere Variablenliste von 1000 - 1500 und pro Auftrag ein bis zwei Variablen (Zustand und Belohnung). Die Belohnung lasse ich jetzt der Einfachheit halber weg.
Die Liste ist jedoch noch nicht ganz komplett. Wir benötigen noch soetwas wie "Zeiger", bildlich gesprochen "Finger" die immer genau auf einen Eintrag in der Liste zeigen. Veranschaulichen kann man sich dies mit einem 1000 Meter hohen Schrank mit Schubladen. Auf jeder "Etage" des Schrankes befindet sich eine Schublade. Diese Schubladen sind durchnummeriert (von 1000 bis 1500). Nun haben wir mehrere Fahrstühle (oder eben "Finger") die an der Vorderseite dieses Schrankes auf und ab fahren. Dabei lässt sich die Position jedes einzelnen Fahrstuhles eindeutig mit einer Nummer bestimmen. Diese Nummer ist die Nummer der Schublade vor der er sich gerade befindet. (Ich denke ich muss nicht erwähnen, dass man nur über diese Fahrstühle auf die Schubladen zugreifen kann, denn wer will schon 1000 Meter an einem Schrank hochklettern?)
Was müssten wir nun tun um z.B. auf die Schublade 1025 zuzugreifen?
Genau! Wir sagen einem von unseren Fahrstühlen, den wir z.B. "Aktuell" nennen, er soll zur Nummer 1025 hochfahren (wir würden also bildlich in ihm auf die 1025 drücken). Er saust hoch und gewährt uns zutritt zu dieser Schublade.
Andersherum geht es natürlich auch. Stell dir vor wir schicken den Fahrstuhl zu der Schublade in der z.B. ein Teddy liegt. Der Fahrstuhl fährt einfach so lange weiter bis er eine solche Schublade gefunden hat. Wir brauchen dann nichts weiter zu tun, als uns den Inhalt der Variable "Aktuell", also bildich die Position des Fahrstuhles, anzeigen zu lassen, und schon haben wir die Schublade.
Genau dies machen wir auch mit der Liste, nur dass jede Schublade eine ID ist, hinter der Titel, Beschreibung, Belohnung, Zustand und Bild des Auftrages versteckt sind und die Fahrstühle in wirklichkeit normale Variablen sind, die mit ihren Werten auf irgend eine Variable zeigen.
Nochmal zusammenfassend: Was brauchen wir für unsere Liste?
Wofür wir die Seiten-Variablen brauchen wirst du später erfahren.
Nun aber zurück zu unserem Auftrag. Ich spiele dabei einfach ein Beispiel durch:
Der Hauptheld kommt in das erste Dorf und spricht dort einen Mann an. Dieser bittet ihn darum ihm einen Fisch zu besorgen, er hätte am Morgen immer solchen Hunger. Der Held willigt ein.
Was passiert technisch dahinter? Wie wir wissen hat der Auftrag: "Ein frischer Fisch am Morgen" die ID 3 (diese hast du dir niedergeschrieben). Wir müssen nun also herausbekommen, welche Variable in unser Liste frei ist. Dazu setzen wir die Variable "Aktuell" auf 1000, den Start unserer Liste.
Der Code sieht dann so aus:
Um das Questlog später übersichtlicher zu gestalten, solltest du einige einzelne CEs anlegen, welche deine Liste für dich verwalten. Das erste CE hieße z.B. "Springe zur ersten freien Stelle" (im Maker geht allerdings nur weniger, z.B. "ZurErstFreistelle").
Der Code wäre dann dieser:
Sobald du diesen Code ausführst weißt du, dass dein Fahrstuhl "Aktuell" nun bei der ersten Schublade hält, in der nichts drinn ist. Die Lable-Schleife läuft so lange weiter, bis die Varibable "Kontrolle" einen Wert enthält der nicht 0 ist. "Kontrolle" entspricht hierbei dem Inhalt der Schublade mit der Nummer "Aktuell".
Nun bist du also an dieser Stelle, jetzt willst du dort die ID deines Auftrages hinterlegen. Das machst du dann so:
Auf dem Weg zurück begegnet man nun aber noch einer Frau, welche in voller Sorge erklärt, dass ihr Mann seit zwei Tagen verschollen sei. Er hatte zu einer alten Mine gehen wollen, da er dort noch unentdeckte Bodenschätze vermutete, doch nun sei seine Rückkehr schon einen Tag überfällig.
Wiedermal ein neuer Code:
Es wird wohl schnell deutlich, dass sich dieser Codeschnipsel überall weider verwenden lässt.
Wie sieht nach diesen beiden Aktionen nun unsere Liste aus?
Für weitergehende Erklärungen füge ich jetzt noch 10 weitere Aufträge mit unterschiedlichen IDs an. Die Geschichten dazu können uns egal sein.
Die Liste sieht nun z.B. so aus:
Nun kommen wir zum eigentlichen Teil des Questlogs. Ich gehe dabei davon aus, dass du es über einen Menüpunkt deines eigenen Menüs aufrufst.
Als erstes brauchen wir ein Hintergrundbild, 3 Cursor, 10 Auftragsüberschriften, 1 Bild und eine Erklärung.
Das sähe z.B. so aus:
Cursor 1 dient dazu, direkt einen Auftrag auszuwählen. Belohnung, Beschreibung und Bild wechseln sofort mit der Bewegung des Cursors 1.
Cursor 2 und 3 dienen zum Umblättern, sollte man mehr als 10 Quests haben.
Nun aber zum Technischen. Ich kann dir hier nicht den gesammten Code zum Questlog posten, dass könnte ich auch nicht einfach so fehlerfrei runterschreiben, daher versuche ich lieber es möglichst gut zu erklären.
Die größte Herausforderung bei einem Questlog ist es, immer die richtigen Quests anzeigen zu lassen und das umblättern ordentlich hinzubekommen. Durch unserer Liste ist dies aber nun ganz einfach. Für eine bessere Übersicht solltest du neben dem CE für das QL noch ein weiteres erstellen, in dem du dann das Anzeigen des Bildes, der Belohnung und der Beschreibung einbaust.
Dieses sähe dann z.B. so aus:
Natürlich kannst du Beschreibung, Bild und Belohnung in ein Picture packen. Das macht die Sache sogar noch einfacher.
Den Titel des Autrages musst du anders anzeigen lassen. Da kommt leider ne Menge Arbeit auf dich zu. Da die Aufträge variabel sind, können sie theoretisch an jeder Stelle im Questlog stehen. Das heißt du brauchst für jeden Quest bei 10 angezeigten Aufträgen gleichzeitig auch 10 Show Pictures.
Daher würde ich dir empfehlen nur 5 Aufträge pro Seite zu machen.
Beim Aufrufen muss nun Folgendes geschehen:
Hier wird nur der Variablenbereich abgesteckt in dem wir uns momentan befinden. Das Umblättern sieht so aus:
Hier muss gleich zwei mal überprüft werden, ob das Ende der Liste erreicht ist. Einmal ist das umblättern nur dann möglich wenn unser Bereich noch nicht an das "Nichts" grenzt. Zum anderen wird die oberere Grenze zurückgezogen, sollte sie versehentlich über den Rand gerutscht sein.
Nun zur Anzeige:
Der Großteil wiederholt sich einfach. Hierbei lasse ich meinen Aktuell-Fahrstuhl immer eine Etage höher fahren und hohle mir den Inhalt der Schublade.
Nun brauchst du noch das "Auftrag Anzeigen" CE:
Die Cursorbewegung läuft dann wie in jedem anderen Menü auch. Allerdings kannst du, um zu ermitteln welcher Auftrag gerade unter deinem Cursor ist, diese Rechnung benutzen:
Sollte funktionieren ^^°
Leider fange ich selber an, an der Verständlichkeit des obigen Textes zu zweifeln. Mag daran liegen das ich heute aus dem Urlaub gekommen bin und abgesehen von zwei, drei 15 Minütigen Nickerchen auf unbequemen Sitzen im Zug seit nunmehr 36 Stunden keinen Schlaf mehr hatte. Ich werde mich gleich ins Bett verziehen, wollte nur noch den Text so einigermaßen zuende bringen. Bis morgen hätte ich es bestimmt vergessen ^^°
mfg
Phönix Tear
--Zu Java und C++ übergelaufen...
Hallo,
erstmal vielen Dank für die Mühe mit der ausführlichen Erklärung... habe mir den Beitrag mal gedruckt, um ihn auch ohne Browser durcharbeiten zu können.
Bin die Erklärung nun zweimal durchgegangen, werde es aber nochmals in aller Ruhe machen. Das Prinzip habe ich aber soweit verstanden.
Eines aber erstmal:
Hab mir sicherheitshalber die PN nochmal angesehen, aber nein - hab das nicht erwähnt dort
Ich bin schon eine ganze Weile am überlegen, wie ich das Logbuch am Besten aufbauen könnte. So wie ich es aus deiner Beschreibung verstanden habe, ist es eine komplizierte Methode, auch wenns nachher schön aussehen würde.
Die Beschreibungen als Bild anzuzeigen ist sicherlich eine tolle Idee - was mich dann aber stört ist folgendes: Die Überschriften für jede Quest müssen ja schon als Bild dargestellt werden - die Beschreibungen würden sich aber auch per Show Message aufrufen lassen, sobald man eine Quest ausgewählt hat.
Außerdem könnte ja jemand auf die Idee kommen, sich den Ordner "Pictures" anzugucken und schon vor dem Spielen erfahren, was es für Aufgaben geben wird. Die Beschreibung dann als Message anzuzeigen würde dies dann ausschließen
Eine andere Art für ein Logbuch habe ich in der Demo "Der Bote des Königs" gesehen. Dort kann man die Quests erst getrennt in einer Show Choice auswählen (ob Haupt- oder Nebenquest). Danach werden die Aufgaben dann als Message angezeigt (bei mehreren Aufträgen habe ich jetzt nicht nachgesehen wie es ausschaut).
Ich stelle mir das Logbuch so vor:
1. aufrufbar über einen eigenen Eintrag im Menü
2. Hintergrundbild wird angezeigt (man könnte hier einen Notizblock darstellen oder sowas)
3. Da mehr als 3 Aufgaben aufgelistet werden sollen, werde ich die Überschriften als Pictures nehmen müssen ist klar - also werden dann über das Hintergrundbild alle vorhandenen Aufgaben eingeblendet.
4. Neben den Aufgaben sollte sich dann ein Cursor befinden, mit welchem man zwischen den Aufgaben navigieren kann
5. Wählt man eine Aufgabe aus, so wird ein Picture eingeblendet, über welchem man dann eine transparente Message anzeigen lässt (das Picture natürlich passend zum Logbuch und anders als eine normale Textbox, damit man den Unterschied erkennt und das Ganze auch gut aussieht) - als weitere Hilfe bei wichtigen Quests könnte man dann auch ein Faceset anzeigen lassen oder an anderer Stelle ein Bild (zB. eine Karte oder einen Screenshot von dem Ort wo sich die Quest befindet)
6. Sollte man mehr Aufgaben haben als Pictures sich anzeigen lassen, dann natürlich noch zwei weitere Bilder, die ein vor/zurück geben sollen - vielleicht noch einen "Zusatzbutton" zum Verlassen des Logbuches.
Was ich nun noch nicht sicher weiß ist, was mit den erledigten Aufgaben geschehen soll, ob sie weiterhin angezeigt werden sollen. Hier würde ich dann das bevorzugen, was von der Umsetzung her einfacher ist.
Für den Fall, dass bereits erledigte Aufgaben weiterhin angezeigt werden, würde ich die Überschriften dann farblich anders gestalten (eventuell noch ein Häkchensymbol dahinter) - sodass man also die einzelnen Quests unterscheiden kann.
Natürlich könnte man auch mehrere Seite im Logbuch machen, wo der Spieler dann auswählen kann, ob er aktuelle Quests sehen will, bereits erledigte, oder sogar eine Statistik ("Du hast bereits X Aufgaben gelöst") - Möglichkeiten gibt es da eben viele.
Wie sieht es also mit der Umsetzung für diese Art von Logbuch aus? Ich denke dass sie etwas einfacher ist. Es ist übrigens auch egal, welche Reihenfolge die Aufträge im Logbuch haben, zumal jeder sicherlich unterschiedlich spielt und zuerst an anderer Stelle sich aufhält, als die erste aller Aufgaben wirklich wäre.
Erstmal bis dann, werden heute Mittag mal ein wenig herumprobieren um zu schauen, ob ichs irgendwie hinbekomme.
--
Gut in diesem Fall hast du wieder zwei Möglichkeiten.
Möglichkeit 1 ist die, die ich oben beschrieben habe (also mit der Liste).
Möglichkeit 2 lässt überall dort ein Feld frei wo du den entsprechenden Auftrag noch nicht gefunden hast. Diese sieht man häufig in Spielen mit Fähigkeitsmenüs oder auch bei etwas wie dem Pokedex aus Pokemon. Meiner Meinung nach ist das nicht wirklich schön. Der Pokedex ist allerdings in sofern noch in Ordnung weil er einem ne schöne Übersicht bietet wie viele Pokemon man noch nicht entdeckt hat. Bei Aufträgen kommt es (gerade wenn nur 5 oder so pro Seite angezeigt werden) zu unnötigem Blättern. Bei 10 oder 15 Aufträgen pro Seite könnte das aber wieder gehen. Damit würde es dann nur schwerer noch Extra anzeigen einzubaun (Häkchen, etc.). Daher würde ich 10 empfehlen.
Wenn dir die Methode 1 zu schwierig ist kannst du Methode 2 mit einer Reihe von Forks nachbaun. Dabei brauchst du im Maker nur aufzulisten welcher Auftrag wo steht. Also z.B. so:
Das sieht erstmal nach viel aus, ist aber sehr einfach zu ergänzen und funktioniert mit Sicherheit. Das Questlog wäre dann einfach zu machen:
So, nun brauchst du noch die CEs "Cursor bewegen" und "Auftragsbeschreibung".
Warum diese komische Berechnung?
Ich gehe davon aus, dass deine Aufträge alle untereinander stehen mit einem Abstand von 20, beginnend bei der Position [100|80]. Das müsstest du natürlich anpassen.
Die Berechnung selbst spart mir im Haupt-CE jedes mal die neuen Cursor-Positionen angeben zu müssen. Das kann man natürlich auch machen. Hier bot sich nur diese Methode an
Dann noch das "Auftragsbeschreibung"-CE:
Damit ist dein Questlog fertig.
Jetzt kannst du noch im "Auftags-Anzeige"-CE weitere Pictures, wie ein Bild des Auftragsgebers, etc. hinzufügen. Der Phantasie ist dort nur die Grenze der maximalen Pictures gesetzt
Was dann auch noch zu erledigen wäre, ist das anzeigen der Seiten-Cursors. Das dürfte jedoch sehr einfach sein
Ich hoffe mit der Methode kannst du was anfangen
mfg
Phönix Tear
--Zu Java und C++ übergelaufen...
Hallo,
leider wurde aus dem Test am Mittag nichts, aber mal sehen ob ich gleich etwas Zeit dafür finde ... naja, ansonsten, es läuft ja nicht weg^^.
Auf den ersten Blick muss ich sagen, siehts genauso schwierig aus wie beim Ersten
Mir kommen jetzt aber ein paar Fragen auf zur 2. Methode:
1. Wird das jeweils alles in ein Common Event gepackt?
2. Warum werden bei dem ersten Code zu Anfang alle Pictures gelöscht?
3. Die Anzeige der Postionen der einzelnen Aufträge klingt verständlich, so müsste es dann sein. Aber, wie sieht es dann aus, wenn ein Auftrag noch nicht erledigt ist? Wird dann nicht eine "leere Fläche" erscheinen zB. zwischen Auftrag 1 und 3 ?
Die Berechnung mit dem Cursor finde ich schon mal in Ordnung so, dann muss man nicht alles mehrfach berechnen
Hmm, das lässt mir einfach keine Ruhe, werde jetzt mein Testprojekt starten und mal loslegen!
Edit: Habe mal ein bisschen herumprobiert und mir dabei deinen Beitrag angesehen. Jetzt ist es schon ein wenig klarer, ebenso konnte ich mir obige Fragen schon teilweise selbst beantworten.
1. Ja, alles in Common Events
2. Der Picture-Löschbefehl am Anfang deshalb, weil das gesamte Common Event mehrmals, je nach Fork, abgerufen wird, und dann immerwieder ermittelt, welche Aufgaben man schon hat, damit er diese anzeigen kann. Ohne das Löschen der Pictures vorher, würde die erneute Anzeige nicht klappen - richtig?
Wenn ich jetzt noch eine Antwort auf die 3. Frage hätte, wäre ich schon gaaaaanz weit
--
Geändert von Jadoo (09.04.2007 um 20:35 Uhr)
^^
Ja, das finde ich ist der große Nachteil an der zweiten Methode. Meiner Meinung nach kommt da ein "Noch kein Eintrag" Picture in einem unauffälligen grau ganz gut. Trotzdem ist es nicht so schön wie Methode 1
Zu deinen Fragen:
1: Eben je nachdem wie viele du haben willst. Manchmal ist "Auslagern" ganz praktisch, wenn man einige Code-Segmente häufig benutzen will.
2: Solltest du bei nicht gefundenen Aufträgen keinen "Noch kein Eintrag" Schriftzug verwenden wollen, muss dies ausgeführt werden, damit nicht der Eintrag der letzten Seite da bleibt. Richtig erkannt ^^
3: s.o. ^^°
Ich würde jedoch, da diese Methode ja gerne Löcher lässt, die Schriftfarbe erledigter Aufträge auf grün ändern. Damit hat der Spieler ein besseres Gefühl, weil er gleich sieht was er alles schon geschafft hat. So kommt dann auch ein größerer Anreiz auf einen speziellen Auftrag zu erledigen, der vielleicht der letzte rote auf einer Seite ist).
Ich bin leider im Moment sehr beschäftigt (einmal mit meinem Tetris, zum anderen damit, die letzten 2 Ferientage möglichst gut auszunutzen ^^), sonst könnte ich dir das einmal im Maker umsetzen. So lange dürfte das ja nicht dauern (wenn man es einmal verstanden hat ist es ja ganz leicht
Die Methode 1 dürfte um einiges klarer werden, wenn man Java im Informaitk-Unterricht hatte. Ich schätze meine Erklärung war etwas schlecht, weil ich einfach ein paar Sachen aus dem Unterricht übernommen habe, die zum Maker nicht so gut passten.
mfg
Phönix Tear
--Zu Java und C++ übergelaufen...
Achso meinteste das, jetzt verstehe ich. Dachte erst, du meinst, ich solle da ein Feld frei lassen wo keine Aufgaben sind, lol ^^
Mir ist jetzt aber noch etwas klar geworden, und zwar die einfachste aller Möglichkeiten (meiner Meinung nach im Moment): Die Aufgaben alle als Text anzeigen lassen und eventuell Facesets oder Pictures nebenher zu nutzen
Einziger Nachteil: Der Spieler kann dann nicht selbst auswählen, welche Aufgabe er sehen will, sondern alle Beschreibungen werden nacheinander eingeblendet. Wenn bereits gelöste Aufgaben aber nicht mehr angezeigt werden, verringert sich der Nachteil jedoch und es ist erträglich. Außerdem wird der Spieler dann automatisch erinnert, wenn er eine Aufgabe noch nicht erledigt hat. Man kann den Text hier ja auch auf normaler Schnelligkeit laufen lassen, dann kann man bestimmte Texte schneller wegdrücken
Ansonsten würde ich mich über dein Angebot freuen (falls es eins war), dass du mir das mal als Spiel zeigst und ich mir das im Maker ansehe. Ich denke dann wird es für mich verständlicher. Du kannst dir damit aber ruhig noch Zeit lassen, es eilt nicht!
LG
--
So, ich hab mich mal drangesetzt und das in etwa so umgesetzt wie ich mir das vorgestellt hatte (Methode 2).
Die Graphik sollte man nicht beachten, ist ja wie immer nur ein Lückenfüller.
An einigen Stellen hab ich ein bisschen mit Variablen-Nummern gespielt, was den Code komplizierter erscheinen lässt als er ist. An all diesen Stellen musste man nämlich einfach Stumpf die richtigen Variablen auswählen. Da ich 23 Aufträge eingebaut habe war mir das zuviel Arbeit, wesshalb ich das dort abgekürzt habe. (Hat lange genug gedauert die ganzen Pics für die Aufträge zu machen und zu importieren xD).
Der Großteil ist im Code erklärt, von daher sollte das kein Problem sein
Sobald du startest stehst du auf einer Map voll mit Soldaten. Von oben links beginnend gibt dir jeder von ihnen einen Auftrag. Beim ersten ansprechen wird er aktiviert, beim zweiten ansprechen als "erledigt" verbucht. Die beiden Soldaten links aktivieren gleich mehrere Aufträge. Der obere die von 1-10, der untere die von 1-23 (also alle).
Das die Titel meiner Aufträge so eintönig sind (Auftrag 1, Auftrag 2, Auftrag 3, etc.) liegt daran, dass ich mir nicht auf die schnelle 23 Titel ausdenken konnte. Die "Spezifikationen" (also Bild, Beschreibung und Belohnung) sind nahezu bei allen Aufträgen gleich. Auftrag 1 und 2 haben ein Bild. Alle Aufträge haben nur eine Platzhalter beschreibung und die Aufträge 1-10 bringen 10 Gold als Belohnung, die danach 99 Gold. Das wars auch schon
Eingebaut ist die "-kein Eintrag-" Funktion, sowie die rote und grüne Schrift für erledigte und noch ausstehende Quests. Dabei lasse ich die Spezifikationen der Quests die erledigt worden sind weiterhin anzeigen, damit man im späteren Spiel nochmal zurückblicken kann, was man alles schon erlebt hat
Tja, mehr gibts garnicht zu sagen.
Hoffe du kannst damit was anfangen
Hier der Download Link (375 KB bei Rapidshare)
mfg
Phönix Tear
--Zu Java und C++ übergelaufen...
Das ging ja schnell, vielen Dank für die Mühe
Ja, das entwerfen der Grafiken und importieren ist denke ich (für die, die das andere auch schon drin haben) am schwierigsten, vor allem wenn man sie noch passend gestalten muss fürs Hauptprojekt.
Das Logbuch sieht natürlich super aus, auch was die Funktionen angeht. Was die Umsetzung aber betrifft siehts immernoch so aus:
Hab jetzt ca. 1 Stunde so vorm Bildschirm gehockt ---><--- und überlegt. Ich muss mich da nochmal ganz in Ruhe ransetzen und am Besten erstmal Schritt für Schritt nachbauen.
Hatte gestern noch selbst ein Logbuch mal angefangen zu machen, wie gesagt allerdings nur aus ein paar Show Pictures und Messages, das klappt ganz gut und ließe sich ausbauen.
Ich werde in den nächsten Tagen längere Zeit nicht Zuhause sein und deshalb auch nicht Werkeln können. Aber mal sehen, vielleicht sieht es danach ja besser aus, wenn ich mich "frisch" wieder der Aufgabe begebe.
Ich bedanke mich nochmal bei euch für eure Mühe, werde mich melden, sobald ich etwas, was wie ein Logbuch aussieht zustande gebracht habe
LG
--
Hallo
Es gibt ein paar tolle Neuigkeiten: Habe es geschafft, auf einfacher Weise ein Logbuch zu erstellen (ohne Navigation, sondern nacheinander anzeigende Messages)
Bin auch nochmal ganz in Ruhe die erste Methode durchgegangen und habe sie bis zum Punkt mit dem Cursor verstanden. Das was danach kommt muss ich nochmal in Ruhe durchgehen, aber so betrachtet und das Resultat daraus in dem Script ist mir jetzt folgendes aufgefallen:
Es werden alle Einträge je Seite angezeigt, wo man auch sofort blättern kann, weil ja je nach Cursorbewegen rechts die Beschreibung usw. angezeigt wird. Wollte das schon früher fragen, aber hatte erstmal nachgesehen, falls sich die Frage von selbst beantwortet.
Wenn ich aber einbauen möchte, dass erst nach dem Drücken der Entertaste ein Bild bzw. Text angezeigt wird, kann man das irgendwie einbauen oder muss dann das gesamte Logbuch ganz anders aufgebaut werden?
Was mir noch aufgefallen ist: Ist es denn nicht so, dass auch bei der ersten Methode immer eine freie Stelle dort bleibt, wo noch kein Auftrag vorhanden ist? Wenn zB. bei der Abfrage ob Var Aktuell = < 1004 .... sagen wir mal 1002 hat noch keinen Eintrag, wie sieht es dann aus?
LG
--
Ersmal zu Frage 2:
Ne, das Logbuch von der ersten Methode hat nur dann ein "Loch" wenn du überhaupt keine Einträge hast. Dadurch das jedes Mal, wenn du einen Auftrag bekommst, die erste Freistelle in der Liste gesucht wird (welche logischerweise immer am Ende deiner Liste ist), kann garkein Loch entstehen.
Solltest du später einen Auftrag löschen - also seine Varibale wieder auf 0 setzen - müsste man noch einen Nachrück-Algorithmus bauen. Das wäre allerdings auch nicht weiter schwer:
Was macht dieser Code?
Nun, hier haben wir wieder zwei Fahrstühle ^^, nämlich "Verschiebung 1" und "Verschiebung 2". Außerdem noch eine Kiste die "Verschiebungs Inhalt" heißt.
Nun fahren wir beide Fahrstühle zur ersten Schublade ohne Inhalt. Daraufhin lassen wir Fahrstuhl 2 (also "Verschiebung 2") eine Etage weiter nach oben Fahren. Da wir eine Lücke haben ist diese Schublade logischerweise gefüllt. Nun packen wir alles aus Schublade 2 (also auf der Etage bei der "Verschiebung 2" gerade ist) in unsere Kiste "Verschiebungs Inhalt". Danach schicken wir diese Kiste an "Verschiebung 1", der ja eine Etage weiter unten ist, und packen die Kiste dort in die Schublade.
Nun fahren beide Fahrstühle eine Etage weiter nach oben, packen die Kiste erneut und schicken sie nach unten. Das geht so lange weiter bis Fahrstuhl 2 eine weitere leere Schublade entdeckt.
Da ich davon ausgehe das maximal ein Loch auf einmal entsteht ist damit das Ende der Liste erreicht und die Prozedur kann beendet werden.
Fertig ^^
Nun zur Frage 1:
Das sollte auch nicht weiter das Problem sein. Wenn du dir meinen Skript anschaust musst du dort in das CE "Questlog" schaun. Dort steht die Cursor-Bewegung drinn.
Unter dem "Lable 1" wird die Tasteneingabe abgewartet. Drückt man Pfeil unten oder Pfeil oben soll der Cursor bewegt werden. In der Makersprache bekommt meine Variable "QL Passwort" also entweder den Wert "1" (für oben) oder "4" (für unten).
Nun musst du in die Fork-Verschachtelung schauen. Dort wird gleich ganz oben abgefragt ob "QL Passwort" 1 ist. Und etwas weiter unten ob sie 4 ist.
Der Code in den Forks ist dabei nahezu identisch.
Er lautet bei 1:
Das wichtige ist dabei das markierte. Dort wird das CE aufgerufen, welches das Bild, die Beschreibung und die Belohnung anzeigt. Dieses Call-Event musst du einfach in den Forks für 1 und 4 entfernen. Dafür packst du es bei der Fork für 5 rein in der aktuell nur steht:
Nun musst du reinschreiben:
Damit bist du auch schon fertig. Allerdings sollte nun beachtet werden, dass die Spezifikationen des Auftrages bei dem du Enter gedrückt hast auch bestehen bleiben wenn du den Cursor weiterbewegst. Dazu empfehle ich ein "Erase Picture" Befehl bei der Cursorbewegung einzubaun. Setzt einfach in der Fork für 1 und 4 ein:
Damit wäre auch das Problem behoben
mfg
Phönix Tear
Edit:
Habs gerade getestet und es fehlt noch was, bzw. ist noch was zu viel.
In den Forks für 2 und 3 (bei denen die Seite gewechselt wird), muss das Call Event ebenfalls weg. Außerdem noch beim Menüaufruf. (Lösch es im CE "Questlog" einfach überall wo du es siehst, außer in der Fork für 5
Edit 2:
Mir fällt gerade auch noch auf, dass es einen Fehler in der Anzeige des Seitencursors gibt. Ist man auf Seite 1 wird der linke anstatt des rechten Pfeils gelb iluminiert. Du müsstest in der Fork dafür bei "Seite = 1" den Picture von "Questlog Seitencursor Gelb unten" auf "Questlog Seitencursor Gelb oben" ändern (insgesamt drei mal, einmal beim Aufruf des Menüs und in den Forks zum ändern der Seite).
--Zu Java und C++ übergelaufen...
Geändert von Phönix Tear (15.04.2007 um 11:44 Uhr)
Berechtigungen
Zitieren
