Mir ist grad aufgefallen, dass beim 2k die "unerwünschten" Richtungstasten nicht deaktiviert werden können. Dann ist meine Lösung eigentlich viel zu umständlich. Dhans 2. Vorschlag ist aber so oder so besser
Mir ist grad aufgefallen, dass beim 2k die "unerwünschten" Richtungstasten nicht deaktiviert werden können. Dann ist meine Lösung eigentlich viel zu umständlich. Dhans 2. Vorschlag ist aber so oder so besser
oô
Mach doch einfach ein PP dass die Heldenposition und Blickrichtung abfragt und dann eben schaut, ob die Position Anlass für'n Pic gibt.
Du weißt ja auf welche Koordinaten du das jeweilige Event (Truhe, Kiste, bla) gepackt hast. Dann fragst du eben ab, ob die Koordinaten des Helden gleich der eines der umliegenden Felder ist und falls ja, wie die Blickrichtung ist.
Ein bedeutender Mehraufwand ist das auch nicht, da du je nur, sobald du das Truhenevent platziert hast, ein paar neue Forks einbauen musst - was per Copy&Paste sogar sehr fix geht.
Mit dieser Methode hättest du alles wichtige in einem Event - solltest aber zu große Maps vermeiden, da ich mir gerade nicht sicher bin, wie sich das auf die Performance auswirkt wenn man da zu viele Abfragen reinpackt.
Alternative Idee wäre, du fragst ab, ob auf einemd er vier an den Helden angrenzenden Feldern ein Event liegt - wenn ja, setzt du ne Variable, die auf dieser Map für's Bilder anzeigen gut ist, auf die jeweilige Event-ID. (bspw.) Wenn da nichts ist, isse eben 0.
N anderes Event hat als Startevent dass die Variable größer 0 ist - und zeigt das Bild an, je nach dem Wert der Variable eben.
EDIT:
Hier mal als Script.
Man kann einen NPC ansprechen, eine Truhe öffnen, auf nen Schalter treten und ein Schild lesen.
Man braucht eigtl. nur Copy&Paste wenn man was neues einbauen will, man muss nur bei der Abfrage die Event-ID angleichen - also am besten dem Event erst nen Namen geben, nachdem du dir die ID gemerkt hast. Bei Ttuhen musst außerdem noch für jede Truhe nen Switch angleichen, damit bei ner geöffneten Truhe nicht auch "Öffnen" erscheint - eben den, den du auch bei Truhe verwendet hast.
Die Methode hat vor allem den Vorteil, dass du zum einen bei den Events selbst nichts außer der ID beachten musst und dass du sie auch für bewegliche Events wie eben NPCs nutzen kannst. Bei Dhans Methode würde es schon sehr kompliziert, da weder die Terrain-ID noch extra-Events die drumrum platziert werden da komfortabel wären.
Ich bin mir zwar gerade nicht sicher ob das genau das ist,w as du wolltest, aber auch okay. Es ist... multifunktiuonal. xD
Hier mal der Code aus dem Script zur Veranschaulichung.
Hier der 1. PP:
Zitat von EasyEventExporter
Und der 2.PP:
Auf der Map, auf die sich das Bezieht, hat mein NPC eben die Event-ID 6, die Truhe 4, der Schalter 5 und das Schild die ID 3.
Die beiden Switches Truhe1 und Schalter1 sind eben die üblichen Switches die in Truhen- und Schalter-Events verwendetw erden um dem Maker zu sagen dass das Teil aktiviert/geöffnet wurde.
Ich muss aber gestehen ich bin mir nicht sicher wie's bei dem Teil mit der Performance bei größeren Maps mit vielen Events aussieht, aber ich denke es sollte nicht zu Problemen kommen...
Achja, und: Wenn man auf nem Event steht, das direkt unter einem liegt, hat das immer Vorrang. Da ist noch n kleiner Bug drin - der Schalter wurde aktiviert, also zeigt der Maker das "drücken" Bild nicht an - aber auch kein anderes, da er NUR den SChalter gerade abfragt, auch wenn man vor etwa nem Schild steht.
Ich weiß gerade nicht wie ich das lösen könnte. =/
Mit einigen extra-Abfragen, klar, aber das würde das ganze wieder für meinen Geschmack zu umständlich machen.
Da wäre es vermutlich am besten, fürs Erste so zu mappen, dass die Situation nicht auftritt...
EDIT2:
Wozu genau brauchst das jetzt eigtl. wenn man AUF einem Event steht? Schalter bspw. aktivieren sich ja meist schon durch berührung. Bei Truhen, etc. gehts ja darum,d ass der Held DAVOR steht.
Wenn du's nur für Teleporter etc. brauchst ist der Bug egal, nur eben bei nur einmalig benutzbaren Sachen isses was komplizert... Hast du viele Events die unter diese Kategorie fallen?
Geändert von BDraw (04.09.2010 um 14:46 Uhr)
Hier mal eine Lösung für: Ich steh auf dem Event und es zeigt ein Bild. Dann geh ich runter und das Bild ist weg.
Obendrein:
- nur 4 Variablen
- kopierbar -> mehrere pro Map
Geändert von Felski (12.09.2010 um 23:20 Uhr)
Hat auf den ersten Blick 3 große Probleme.
1. - Man kann eben nicht mehrere auf eine Map packen, da dann alle auf dieselbene Variablen zugreifen und sich in die Quere kommen würden. Man müsste bei jedem dann die Variablen austauschen.
2. - Bei deinem Truhenbeispiel: Ich stehe vor ner Truhe, drücke nach "oben" - bewege mich aber nicht, weil ja die Truhe davor steht. Trotzdem verschwindet dann das Bild,w eil die Taste abgefragt wird anstatt der Bewegung.
3. - Wenn der Held weit oben auf der Map steht kann es passieren, dass das Picture außerhalb der Map angezeigt wird.
Mag aber sein, dass ich da auch nur wo aufm Schlauch stehe, da du ja gerade sagtest, es sei kopierbar....
Geändert von BDraw (13.09.2010 um 09:04 Uhr)
Ich habs nicht getestet aber es könnte sein, dass der Maker die Rechenzeiten derart langsam verteilt, dass die PPs tatsächlich jeweils sequentiell durchgeführt werden - dennoch, der Maker beherrscht keine synchronized-Funktion für Threads, daher bleibt das unsauber auch wenns praktisch klappen kann.
Was mich wundert, ist, dass du (BDraw) fragst, wozu Sushi es braucht... das hat er doch geschrieben.
Jop, aber mich hatte gewundert, dass er erst fragte wie man es macht, dass ein Pic angezeigt wird wenn man AUF nem Event steht, und dann plötzlich VOR nem Event (eben bspw. ner Truhe).
Ich weiß jetzt nicht ob er's nur für Events benutzen will, die vor dem Helden stehen (dann wäre der Ganze Quark der ausgelöst wird, wenn der Held vor UND auf was steht eh erledigt), oder für beides, oder auch für NPCs - die sich ja bewegen, wodurch eben das Platzieren von Events drumrum hinfällig wäre.
Dazu kommt, dass man bei Schaltern berücksichtigen muss, dass die meist nur einmal benutzt werden können, was man auch wieder extra berücksichtigen muss.
War mir zumindest jetzt nicht ganz ersichtlich, daher bin ich mal von allem ausgegangen.
Wenn er's für was ganz spezielles braucht kann man das Script eben auch dadrauf zuschneiden; bei allgemeinem Gebrauch dagegen muss man zusehen, dass das Script nicht in Fall xy rumzickt und möglichst vielfältig einsetzbar ist, ohne dass an's ständig anpassen muss.
Geändert von BDraw (13.09.2010 um 09:05 Uhr)
es ist kopierbar, weil zwei dieser events nicht aufeinander liegen!
es ist also zeit zwischen zwei events
das sie dann dieselbe variable benutzen ist dann kein problem
Edit:
habs eben mal mit 2 Events dieser Art getestet die nebeneinander liegen. Das geht nicht.
Aber solange du zwei dieser Events nicht nebeneinander setzts geht es einwandfrei.
Edit2:
Bei mir ists nur ein Event auf One Hero Touch.
Wenn man davon runter geht ist das Bild auch schon wieder weg. Also sind alle Variablen wieder frei.
Geändert von Felski (13.09.2010 um 14:53 Uhr)
Also haben es jetzt geschafft, mit Canlace Hilfe
Wir benötigen dazu keine Variablen, es ist ganz einfach. Die Events um die "Truhe (Objekt) darum mit Bild anzeigen und löschen. Sind zwar mehr Events, aber das ist simpler und geht auch schneller.
--
Der Kutscher kennt den Weg.
also vier events zum anzeigen um die truhe und um die vier events nochmal drei zum löschen?
klingt für mich nach zu viel arbeit. aber jeder wie er mag^^
Viel copy&paste
--Someone asked Jesus: "How much do you love me?" "This much!" and he streched out his arms and died.
Fette Beute <.< Who doesn't wanna get it!?
@Sushi
Ich wollte noch einmal sagen, das man bei meiner Variante nicht 2 Events pro Bild brauch, sondern nur ein Event, das alles lenkt und eine beliebige Anzahl an Events, die dem Controller halt ein Ereignis liefern.
--
Berechtigungen
Zitieren
