• Anmelden

1

Montag, 16. Februar 2009, 16:26

Das Brückenproblemchen...

Halli, hallo, die Joé meldet sich wieder einmal...
Schon ganz lange bastele ich herum, aber finde keine Lösung. Habe eine Brücke von einem berg zum anderem gebaut. Nun soll mein Charakter sie entlang laufen könnne. Oder aber unten durch. Aber mein Problem ist:
Ich kriege es nicht so eingestellt, dass beides geht. Nur so, dass wenn er drunter entlang geht, sein Kopf in der Brücke steckt (Sieht zwar lustig aus, ist aber nicht der Sinn der Sache :D )

Könnte mir bitte jemand sagen, wie und ob ich es einstellen kann, dass beides geht? Vielen Dank im Vorraus, für die, die mir helfen wollen.

Liebe Grüße

- Die Joé :)
SIgnatur:
Spoiler
____________________________________________________________________

(`Д´)凸 { Immer dran denken!!!)
(ノ^_^)ノBild ヘ(^_^ヘ)
(Wenn das mal so einfach wäre... } o(╥﹏╥'')o...... *snüff*
____________________________________________________________________
zum Lesen den Text mit der Maus markieren


Arbeit in Januar 2008:
Spoiler
Hier meine neueste fotografische Arbeit.
Modell: Tras
Titel: Engel (Wie einfallsreich :D )
Bild
zum Lesen den Text mit der Maus markieren

2

Montag, 16. Februar 2009, 19:57

Was mir dazu spontan einfällt, ist evt. die Grafik des Helden zu ändern. Sobald er unter der Brücke ist (oder ein Feld vor betreten der Brücke) benutzt du "Move Route" und dort dann "Change Graphic". Als Bild musst du dann nur noch eine transparente Grafik wählen und lässt ihn dann ebenfalls per "Move Route" unter der Brücke durchlaufen.

Die Sache hätte dann eben nur den Nachteil, dass man nicht selbst laufen kann. Es geht bestimmt noch anders aber mehr fällt mir gerade nicht ein. xD
Albion: Remake

TheBlackCherub

Ankömmling

Motto: Leute, ihr müsst die Sache viel gechillter angehen.

  • Nachricht senden

3

Montag, 16. Februar 2009, 20:15

das problem kenn ich
ich habs mit verschiedenen sachen gelöst, keine möglichkeit ist perfekt
1) wenn der player die brücke betreten sollte, dann transferierst du ihn ohne überblendeeffekt auf die map wo es halt so eingestellt ist.
wenn du jetzt noch events auf der map hast, wirds komplizierter
dann müsstest du ein script benutzen, das die eventpositionen speichert und dann auf die andere map überträgt
ich hab so was schonmal geschrieben und benutzt, es klappt, nur das da ein ganz kleines rucken ist, wo der player teleportiert wird
2) man kann die ganze brücke mit events mappen und mit nem switch ziwshcne 2 seiten umschalten, ich weiß net ob das geklappt hat, ich habs auf jeden fall mal versucht. schande über mein gedächnis. selbst wenn es klappt: es ist wohl die dreckigste lösung, absolut unelegant^^
3) du könntest gucken, ob du ein script findest, dass das tileset ändert, während man auf der map ist. es gab hier mal ne anfrage, ich weiß aber auch da nicht mehr was daraus geworden ist.

ich hoffe, du kann mit irgendwas von den ideen was anfangen
gruß,
cherub
Meine Scripte, nur eins öffentlich:
TBCs LightMap Script v1.1
Mein Spiel an dem ich grad arbeite:
Die Seraphim-Chroniken: Der letzte Lord Demo

Mal zu viel Freizeit?
http://www.albinoblacksheep.com/flash/demented

"Was ist schon zeit?" kann der sagen, der unsterblich ist.

4

Montag, 16. Februar 2009, 20:43

zeit für ein script, oder?
geile idee eigentlich.

könnt ihr euch noch ein wenig gedulden?
wird nichts großes.

cow
Spoiler: Sachen
zum Lesen den Text mit der Maus markieren

5

Montag, 16. Februar 2009, 23:29

Hey Cow, heißt das, du versuchst ein Script zu schreiben? das wäre natürlich super! :schock:
SIgnatur:
Spoiler
____________________________________________________________________

(`Д´)凸 { Immer dran denken!!!)
(ノ^_^)ノBild ヘ(^_^ヘ)
(Wenn das mal so einfach wäre... } o(╥﹏╥'')o...... *snüff*
____________________________________________________________________
zum Lesen den Text mit der Maus markieren


Arbeit in Januar 2008:
Spoiler
Hier meine neueste fotografische Arbeit.
Modell: Tras
Titel: Engel (Wie einfallsreich :D )
Bild
zum Lesen den Text mit der Maus markieren

Motto: Der RPG-Maker ist antiproportional, für Anfänger leicht - für Erfahrene schwer xD

  • Nachricht senden

6

Dienstag, 17. Februar 2009, 13:55

Hallo,

wie TheBlackCherub schon gesagt hat kannst du das per Schalter lösen und die Brücke per Events mappen.
Hier mal wie ich mir das vorstelle:

Vor der Brücke (und hinter der Brücke) ist ein Event das 2 Seiten hat und bei Seiten per Heldenberührung ausgelöst werden. Erste Seite:

Quellcode

1
Ohne Startbedinung. Befehle: Tab 1 = an


2te Seite:

Quellcode

1
Startbedinung: Tab 1 ist an. Befehle: Tab 1 = aus


So haben wir also gelöst, dass wenn der Held unter die Brücke durchgeht geht der Tab 1 an und wenn er durch ist geht der Tab wieder aus (egal ob sich der Held in der Mitte der Brücke umentscheidet^^). So lösen wir auch die Brücke:

Jedes Brückenteil hat 2 Seiten:

Erste Seite:

Quellcode

1
Startbedingun: keine. (Synchronisierung natürlich an) Befehle: keine. Grafik: Das ausgewählte Brückenteil.


2te Seite:

Quellcode

1
Startbedingun: Tab 1 ist an. (Synchronisierung natürlich an) Befehle: keine. Grafik: Das ausgewählte Brückenteil aber Transparent.


Jenachdem wie stark die Brücke transparent ist, desto besser ist der Held zu sehen.
Hoffe dir damit geholfen zu haben :D

mfg
Archelaus

Evrey

Oberschurke im Ruhestand

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

  • Nachricht senden

7

Dienstag, 17. Februar 2009, 20:56

1. Brücke mappen.
2. Jeden Part der Brücke mit Events bestücken die auf 'nen Switch reagieren.
3. Beim Auslösen des Switches sollen diese Events aktiviert werden. Diese sehen aus, wie die Brücke selbst, sind auf "always on top" und auf "through", außer die Reihe am Klippenrand, da man sonst durch kann o__O"
4. Zwischen dem Weg von Brücke richtung Tal eine Reihe Events, die a) den bestimmten Schalter aktiviert, wenn man runter geht, und b) den Schalter deaktiviert, wenn man hoch geht.

So mach' ich das immer^^ Klappt auch^^
  • :medal: Werbung

    Bild

    Cpp Quellcode

    1
    
    #define TRUE FALSE //Happy debugging suckers
    (Einfach nur wundervoll.)
  • :palette: 1plus3 :cake:

    Bild
  • :fires: Nuuuhminaaah

    Bild
  • :medal: compétences

    mes compétences
    :heart_full: :heart_full: :heart_full: :heart_full: :heart_full: max.
    :ruler-triangle: Maps machen :heart_full: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :media-player: Musik machen :heart_full: :heart-half: :heart-empty: :heart-empty: :heart-empty:
    :cup: Scripts machen :heart_full: :heart_full: :heart_full: :heart_full: :heart-break:
    :paper: Story ausdenken :heart_full: :heart_full: :heart_full: :heart-empty: :heart-empty:
    :cut: Pixeln und so :heart-empty: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :game: Events proggen :heart_full: :heart_full: :heart_full: :heart_full: :heart_full:
    (Dieser Tab ist rein satirisch.)
  • :folder-open: mes projets

    • :addressbook: Silentium
      :book: Name: Silentium
      :rmxp: Maker: Eigenbau (C++, x86-SSE/AVX-Assembly, Ruby/Lua)

      :paper: Story
      :game: NPCs
      :cup: Scripts
      :drill: Ressis
      :ruler-triangle: Maps
      :compile: Gesamt
      (3+4)% 42 69% 0815 -17.438 103.38% ± 6.3mm²

      (Die Tabelle erfüllt lediglich satirische Zwecke.)
    • :compile: Onyx
      Eine in C++ implementierte, modulare, plattformunabhängige, virtuelle Maschine. Die Test-Version ist bereits halb fertig. Ab dann gibt es vielleicht mehr Infos. Sie soll die auf dem ersten Blick LISP-artige und eigens dafür konstruierte Sprache Obsidian ausführen können. Experimentell wird auch ein Lua-Compiler für Onyx gebaut. Ziel ist eine leistungsfähige, virtuelle Maschine für beliebige Scriptsprachen. Theoretisch gesehen müsste man bloß noch einen kompatiblen Compiler schreiben, der Quellcode jener Sprache in Onyx-Assembly, oder direkt in Onyx-Bytecode übersetzt. Ob die jemand nutzen wird, ist eine andere Frage und nur ein sekundäres... nein, eher tertiäres Ziel dieser VM. Primär dient es mir lediglich dazu, mein Verständnis von Hardware, ISA, und Assembly zu vertiefen, sowie eigene Grenzen auszutesten.

      :exclamation: Warnung!
      Das Entwickeln einer virtuellen Maschine oder Programmiersprache (im wahnsinnigsten Fall beides) ist eine höchst komplizierte Tätigkeit, aus der viel Frust und Hirnmatsche hervor gehen. Sollte sich dennoch ein ähnlich wahnsinniger finden, der sowas zusammen schustern will, so lege ich ihm/ihr die folgenden Bücher ans Herz:
      • Compiler - Das Drachenbuch [978-3-8273-7097-6]
        Dieses Buch schlachtet ausführlich und leicht verständlich die Grundlagen bis hoch zu den Experten-Techniken des Compilerbaus aus. Es fängt mit der Automaten-Theorie und formalen Sprachen an, arbeitet sich durch Analysetechniken vor, und landet schließlich bei Techniken wie Optimierung und Register-Zuweisung. Das Buch wiegt 3Kg oder 4Kg. Hab's mal gewogen. Ist also nicht gerade die Lektüre für unterwegs.

      • Computerarchitektur [3-8273-7016-7]
        Hier werden leicht verständlich die wichtigsten Entwicklungen der Rechnerarchitekturen erklärt (Gut, das Buch ist in die Jahre gekommen, aber der Weg zu heute ist ein winziger Schritt, den man sich nach diesem Buch selbst erdenken kann). Hauptbestandteil des Buchs ist eine relativ umfassende Betrachtung der Funktionsweise dreier gänzlich unterschiedlicher, aber dominierender Prozessor-Typen am Beispiel des Pentium II, UltraSPARC II, sowie picoJava. Die meisten Elemente dieses Buchs sind zwar für die Konstruktion einer virtuellen Maschine irrelevant, oder aufgrund der Tatsache, dass die VM Software ist und z.B. Byte-Grenzen hat, sogar zu Leistungseinbußen führen kann, doch ist ein hinreichendes Verständnis dieser Maschinen, mit denen wir arbeiten, äußerst hilfreich für die Überlegungen, wie die VM arbeiten soll.

      Es kann sehr hilfreich und inspirierend sein, den Code quelloffener, virtueller Maschinen anderer Sprachen zu überfliegen. Meine Lieblings-Quelle war und ist stets die VM von Lua. Sie ist schlank, verständlich, in C implementiert, und basiert im Gegensatz zu vielen anderen Scriptsprachen-VMs auf einer Register-Maschine statt einer Stapelmaschine. Es wäre natürlich vorteilhaft, die entsprechende Sprache zu verstehen, in der man auch die eigene VM implementieren will. Weiterhin ist es äußerst vorteilhaft, eine leistungsstarke und bequeme Sprache wie C++ zu beherrschen, um die VM zu implementieren. Und bevor irgendwer auf die Idee kommt: Assembly ist NICHT als dominierende Sprache für den Bau einer VM geeignet. Wer die Frage des "Warum?" nicht beantworten kann, sollte zunächst die gewählte Sprache und Assembly hinreichend verstehen lernen, und es dann erneut mit der Frage versuchen. Es lohnt sich dennoch, Assembly zu lernen. Allein schon, um erneut das Verständnis zu vertiefen, zumal ihr mehr oder weniger gezwungen seid, auch für eure VM eine Assembler-Sprache zu entwickeln (Außer natürlich ihr schreibt eure Test-Programme Bit für Bit ;3).
  • :locale: enfin

    Je ne peux pas parler français.
    C'est tout ce que Goodle et les restes de cours de français.
Signaturstand: 24.07.2013

Reborn

hat beim Stromkonzern schon Rabatt

Motto: Wer noch was vom Wochenende weis, hat es nie erlebt!

  • Nachricht senden

8

Dienstag, 17. Februar 2009, 22:58

XD, das ist praktisch unmöglich^^. Bräuchtest wenndann schon eni Script, wüsste dann aber auch nicht wirklich wie das gehen soll.
Mehr als a Allgäuer ka a Mensch it wera.


Wie soll ich wissen was ich denke, bevor ich nicht höre was ich sage?


Spoiler: OpenSource-Projects
NES-Emulator - a simple NES-Emulator
ERDL - a embedded Ruby Interpreter with the abilltiy to render images with DirectX ERDL shall be 100% compatible to RPGXP-Ruby Scripts
zum Lesen den Text mit der Maus markieren

Motto: Der RPG-Maker ist antiproportional, für Anfänger leicht - für Erfahrene schwer xD

  • Nachricht senden

9

Mittwoch, 18. Februar 2009, 12:44

Hallo,
1. Brücke mappen.
2. Jeden Part der Brücke mit Events bestücken die auf 'nen Switch reagieren.
3. Beim Auslösen des Switches sollen diese Events aktiviert werden. Diese sehen aus, wie die Brücke selbst, sind auf "always on top" und auf "through", außer die Reihe am Klippenrand, da man sonst durch kann o__O"
4. Zwischen dem Weg von Brücke richtung Tal eine Reihe Events, die a) den bestimmten Schalter aktiviert, wenn man runter geht, und b) den Schalter deaktiviert, wenn man hoch geht.

So mach' ich das immer^^ Klappt auch^^
Hab ich das nicht zufällig grad schon gesagt?^^
Ist im prinzip so ziemlich dasselbe nur das man den Helden dann halt nicht sieht. Ist allerdings geschmackssache wie man das haben will.


XD, das ist praktisch unmöglich^^. Bräuchtest wenndann schon eni Script, wüsste dann aber auch nicht wirklich wie das gehen soll.
Erklär mir mal bitte warum das praktisch unmöglich sein sollte. Ich weiß zwar nicht ob du das meintest, aber du kannst nicht nur begrenzt als Grafik auf die Charsets zugreifen sondern auch auf das angewendete Tileset :) .

mfg
Archelaus

sorata

Champion

Motto: Eines Tages werden auch Schildkröten fliegen, jawohl! Und wenn es nur wie bei Gamera ist! °^°

  • Nachricht senden

10

Mittwoch, 18. Februar 2009, 13:01

Jupp, wie Evrey sagte, braucht man dafür absolut kein Script. Man muss nur bei komplexeren Brücken (mit Seilen an den Seiten) zusätzlich im Tileset Tiles anlegen, die die einzelnen Bestandteile dann (so würdest du ja erst die Brücke mappen und eine Ebene drüber das Geländer machen) zusammenfügen, um sie dann für diesen Effekt verwenden zu können.
Sonst läuft es halt ab, wie Evrey beschrieben hat.
Der Clou an der Sache ist nämlich (kann man auch für andere Probleme anwenden), wenn man ein Stück des Tilesets als Eventgrafik auswählt, ist dieses Standardmäßig mit denselben Eigenschaften wie die Tiles beim Mappen versehen (also was man in der Database einstellt).
Ich hoffe, das hat dir noch etwas Wissen dazugewonnen ^^"
  • Projekte

    Bild

    Vollversion:
    Fortschritt: 50%

TheBlackCherub

Ankömmling

Motto: Leute, ihr müsst die Sache viel gechillter angehen.

  • Nachricht senden

11

Mittwoch, 18. Februar 2009, 14:09

@ sorata
kleine ergänzung: den effekt kann man ausnutzen wenn man beispielsweise mal ein tileset mit anderen eigenschaften belegen will, zum beispiel, wenn eine grafik mal unpassierbar werden soll, die im tileset als passierbar eingestellt ist:
man nimmt einfach ein event, gibt ihm die grafik von ner wand oder irgendwas undurchlässigem und macht die opacity auf 0,
dann ist das tile unpassierbar
so, das nur am rande, auch wenns eigentlich damit nix zu tun hat:-D, manchmal ist das praktisch, dann muss man nicht gleiche grafiken 2 mal ins tileset tun, um verschiedene passage-einstellungen zu haben.
gruß,
cherub
Meine Scripte, nur eins öffentlich:
TBCs LightMap Script v1.1
Mein Spiel an dem ich grad arbeite:
Die Seraphim-Chroniken: Der letzte Lord Demo

Mal zu viel Freizeit?
http://www.albinoblacksheep.com/flash/demented

"Was ist schon zeit?" kann der sagen, der unsterblich ist.

Evrey

Oberschurke im Ruhestand

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

  • Nachricht senden

12

Donnerstag, 19. Februar 2009, 21:20

Zitat

Hab ich das nicht zufällig grad schon gesagt?^^
Ich wollt's nochmal in kurz und knackig xD Also Detail und Kurzfassung sozusagen xD Tolles Lernprinzip^^

Zitat

XD, das ist praktisch unmöglich^^. Bräuchtest wenndann schon eni Script, wüsste dann aber auch nicht wirklich wie das gehen soll.
Och,, du Pessimist^^ Ja, geht auch mit Script, da könnte man 'ne hardcore Tileeinstellung schreiben, die das erledigt, aber wozu, wenn das auch fast ohne Performenceeinbuße ohne Script geht?^^ Ein Script lohnt sich hier erst bei a) denen, die (wie NB) z.B. einfach Langeweile hatten, und/oder b) bei denen, die eine SOOO lange Brücke haben, dass über 100Events fällig wären xD Aber selbst im Falle b) wirken Entruckler Wunder^^
  • :medal: Werbung

    Bild

    Cpp Quellcode

    1
    
    #define TRUE FALSE //Happy debugging suckers
    (Einfach nur wundervoll.)
  • :palette: 1plus3 :cake:

    Bild
  • :fires: Nuuuhminaaah

    Bild
  • :medal: compétences

    mes compétences
    :heart_full: :heart_full: :heart_full: :heart_full: :heart_full: max.
    :ruler-triangle: Maps machen :heart_full: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :media-player: Musik machen :heart_full: :heart-half: :heart-empty: :heart-empty: :heart-empty:
    :cup: Scripts machen :heart_full: :heart_full: :heart_full: :heart_full: :heart-break:
    :paper: Story ausdenken :heart_full: :heart_full: :heart_full: :heart-empty: :heart-empty:
    :cut: Pixeln und so :heart-empty: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :game: Events proggen :heart_full: :heart_full: :heart_full: :heart_full: :heart_full:
    (Dieser Tab ist rein satirisch.)
  • :folder-open: mes projets

    • :addressbook: Silentium
      :book: Name: Silentium
      :rmxp: Maker: Eigenbau (C++, x86-SSE/AVX-Assembly, Ruby/Lua)

      :paper: Story
      :game: NPCs
      :cup: Scripts
      :drill: Ressis
      :ruler-triangle: Maps
      :compile: Gesamt
      (3+4)% 42 69% 0815 -17.438 103.38% ± 6.3mm²

      (Die Tabelle erfüllt lediglich satirische Zwecke.)
    • :compile: Onyx
      Eine in C++ implementierte, modulare, plattformunabhängige, virtuelle Maschine. Die Test-Version ist bereits halb fertig. Ab dann gibt es vielleicht mehr Infos. Sie soll die auf dem ersten Blick LISP-artige und eigens dafür konstruierte Sprache Obsidian ausführen können. Experimentell wird auch ein Lua-Compiler für Onyx gebaut. Ziel ist eine leistungsfähige, virtuelle Maschine für beliebige Scriptsprachen. Theoretisch gesehen müsste man bloß noch einen kompatiblen Compiler schreiben, der Quellcode jener Sprache in Onyx-Assembly, oder direkt in Onyx-Bytecode übersetzt. Ob die jemand nutzen wird, ist eine andere Frage und nur ein sekundäres... nein, eher tertiäres Ziel dieser VM. Primär dient es mir lediglich dazu, mein Verständnis von Hardware, ISA, und Assembly zu vertiefen, sowie eigene Grenzen auszutesten.

      :exclamation: Warnung!
      Das Entwickeln einer virtuellen Maschine oder Programmiersprache (im wahnsinnigsten Fall beides) ist eine höchst komplizierte Tätigkeit, aus der viel Frust und Hirnmatsche hervor gehen. Sollte sich dennoch ein ähnlich wahnsinniger finden, der sowas zusammen schustern will, so lege ich ihm/ihr die folgenden Bücher ans Herz:
      • Compiler - Das Drachenbuch [978-3-8273-7097-6]
        Dieses Buch schlachtet ausführlich und leicht verständlich die Grundlagen bis hoch zu den Experten-Techniken des Compilerbaus aus. Es fängt mit der Automaten-Theorie und formalen Sprachen an, arbeitet sich durch Analysetechniken vor, und landet schließlich bei Techniken wie Optimierung und Register-Zuweisung. Das Buch wiegt 3Kg oder 4Kg. Hab's mal gewogen. Ist also nicht gerade die Lektüre für unterwegs.

      • Computerarchitektur [3-8273-7016-7]
        Hier werden leicht verständlich die wichtigsten Entwicklungen der Rechnerarchitekturen erklärt (Gut, das Buch ist in die Jahre gekommen, aber der Weg zu heute ist ein winziger Schritt, den man sich nach diesem Buch selbst erdenken kann). Hauptbestandteil des Buchs ist eine relativ umfassende Betrachtung der Funktionsweise dreier gänzlich unterschiedlicher, aber dominierender Prozessor-Typen am Beispiel des Pentium II, UltraSPARC II, sowie picoJava. Die meisten Elemente dieses Buchs sind zwar für die Konstruktion einer virtuellen Maschine irrelevant, oder aufgrund der Tatsache, dass die VM Software ist und z.B. Byte-Grenzen hat, sogar zu Leistungseinbußen führen kann, doch ist ein hinreichendes Verständnis dieser Maschinen, mit denen wir arbeiten, äußerst hilfreich für die Überlegungen, wie die VM arbeiten soll.

      Es kann sehr hilfreich und inspirierend sein, den Code quelloffener, virtueller Maschinen anderer Sprachen zu überfliegen. Meine Lieblings-Quelle war und ist stets die VM von Lua. Sie ist schlank, verständlich, in C implementiert, und basiert im Gegensatz zu vielen anderen Scriptsprachen-VMs auf einer Register-Maschine statt einer Stapelmaschine. Es wäre natürlich vorteilhaft, die entsprechende Sprache zu verstehen, in der man auch die eigene VM implementieren will. Weiterhin ist es äußerst vorteilhaft, eine leistungsstarke und bequeme Sprache wie C++ zu beherrschen, um die VM zu implementieren. Und bevor irgendwer auf die Idee kommt: Assembly ist NICHT als dominierende Sprache für den Bau einer VM geeignet. Wer die Frage des "Warum?" nicht beantworten kann, sollte zunächst die gewählte Sprache und Assembly hinreichend verstehen lernen, und es dann erneut mit der Frage versuchen. Es lohnt sich dennoch, Assembly zu lernen. Allein schon, um erneut das Verständnis zu vertiefen, zumal ihr mehr oder weniger gezwungen seid, auch für eure VM eine Assembler-Sprache zu entwickeln (Außer natürlich ihr schreibt eure Test-Programme Bit für Bit ;3).
  • :locale: enfin

    Je ne peux pas parler français.
    C'est tout ce que Goodle et les restes de cours de français.
Signaturstand: 24.07.2013

Social Bookmarks