Automatisch Laufen einer Person

[Rpgmaker11]

Ich habs hinbekommen aber wie du schon gesagt hast manchmal kann ich diese Person garnichtmehr ansprechen!

[Felski]

komisch das du sie nicht ansprechen kannst? wie sieht den atm dein code aus?

denke mal so ist es richtig:

Message: Hallo
MoveEvent: hin
MoveEvent: zurück
MoveAll
Message: Hier ist das Schwert

Anschließend noch einen switch an. neue seite. und die nicht mehr auf autostart.
wenn du dort was rein schreibst müsstest du ihn danach nochmal ansprechen können.

@Lachsen: Jup, richtig =D

[Rpgmaker11]

Hatt geklappt ja machmal hatte ich zuviele Movs All drine deswegen...
Aber jetzt z,B

Es geht jemand wo hin dann kommt er wieder zurück dann geht der
Held nach Hause dann mach ich Telport wenn das Move Event fertig ist
und dann wenn er drine ist will ich das er dann zu einer Frau läuft (Die im Haus drine ist) Und er sie anspricht wie mach das?

[~Jack~]

Ich verstehe nicht wieso du solch eine Frage stellst wenn du alles was du dafür brauchst schon längst angewendet hast...
Move Event für den Helden zu der Frau und dann show message und das natürlich in einem Autostart-Event auf der neuen Map...

[Rpgmaker11]

Ja aber wenn ich den Teleportiert haben.. Und auf eine stelle komme wo er dann anfängt zu laufen dann wirkt das nicht gleich! dann muss ich erst nach vorne und nocheinmal auf die stelle und dann läuft er dort hin nicht wenn ich ihn Teleportiert und auf die Stelle wo er laufen soll macht er das nicht !
Erst wenn ich auf die Seite oder nach oben unten gelaufen bin und dann wieder auf die Stelle...

[Felski]

beschreib das doch mal mit sätzen.
weil man sich dein problem einfach nicht vorstellen kann.

btw. prinzipiell hat jack aber recht

[R.F.]

Vorgehensweise beim Skripten:

1. Was will ich überhaupt?
2. Welche Befehle brauche ich?
3. Schritt für Schritt den Ablauf überlegen
4. So viel wie möglich auskommentieren (aber nicht übertreiben)
5. Immer den Überblick behalten (Schlimmstenfalls Skizzen auf ein Blatt malen)
6. Das wichtigste beim Skripten (genauso bei Foreneinträgen), ist jede noch so unwichtige Kleinigkeit zu notieren und verständlich wiederzugeben.
Oftmal löst sich das Problem dann von selbst.

Wird der auf das nächste Bewegungsereignis teleportiert?
Wenn ja, hast du es auf "on touch (Event, Hero)" gestellt? (sollte es so sein, dann ist dein rm Schrott)
Autostart muss immer starten, d.h. als Event auf der Map sobald du sie betrittst, daher versteh ich dein Problem grade nicht so wirklich.

Klingt zwar hart, aber man sollte sich schon die Zeit nehmen und die obigen Punkte beachten (irgendwann macht man das automatisch und wenn was richtig komplexes kommt, gehts erheblich leichter-> aus eigener Erfahrung)

[R.D.]

Vorgehensweise beim Skripten:
4. So viel wie möglich auskommentieren (aber nicht übertreiben)

...

Ich weiß, der Lehrer hat gesagt, dass das so muss, aber leider muss ich dir hier mal widersprechen.
Als alleiniger Entwickler muss man nicht jeden Code kommentieren.
Im Team kann das nützlich werden, aber auch nicht so viel wie möglich.
Ich spreche mich da ganz offen als gegner von viel Kommentar aus.
Wenn ich eine Methode "shuffle" habe die in einer Klasse "Kartenstapel" liegt, dann sollte sich das evtl von selsbt erklären.
Ich würde eher sagen, allein... das kommentieren was komplexer ist, weil man das gerne mal vergisst. (Ich hab hier schreckliche Beispiele, wo jede Klinigkeit kommentiert wird: Methode "Lege_ein_Element_dazu" in der Klasse "Stack" mit sage und schreibe 4 Kommentarzeilen )

Ansonsten stimme ich deinen Punkten zu. Ich hab es sogar oft so gemacht, das ich eine bestimmte Funktion gescriptet habe um sie dann zu vereinfachen.

[makenshi]

Ich weiß, der Lehrer hat gesagt, dass das so muss, aber leider muss ich dir hier mal widersprechen.
Als alleiniger Entwickler muss man nicht jeden Code kommentieren.
Im Team kann das nützlich werden, aber auch nicht so viel wie möglich.
Ich spreche mich da ganz offen als gegner von viel Kommentar aus.
Wenn ich eine Methode "shuffle" habe die in einer Klasse "Kartenstapel" liegt, dann sollte sich das evtl von selsbt erklären.
Ich würde eher sagen, allein... das kommentieren was komplexer ist, weil man das gerne mal vergisst. (Ich hab hier schreckliche Beispiele, wo jede Klinigkeit kommentiert wird: Methode "Lege_ein_Element_dazu" in der Klasse "Stack" mit sage und schreibe 4 Kommentarzeilen )

Ansonsten stimme ich deinen Punkten zu. Ich hab es sogar oft so gemacht, das ich eine bestimmte Funktion gescriptet habe um sie dann zu vereinfachen.

...

Kommentieren ist definitiv wichtig, vor allem bei Makercode. Wenn du dir deinen Code nach langer Zeit wieder anschaust und ihn versuchst zu verstehen, bist du für jede sinnvolle Kommentarzeile dankbar. Auch ein anständiger Kommentarkopf kann da Wunder bewirken. Wer Kommentare ablehnt ist entweder faul oder hat ihren Sinn nicht verstanden.

[~Jack~]

Er hat sich ja nicht gegen jede Art von Kommentar ausgesprochen, nur eben das jede Kleinigkeit kommentiert wird, was nunmal wirklich unwichtig ist.
Klar, wenn du ein eigenes KS machst wäre es schon sinnvoller Kommentare zu machen bevor du irgendwann selber nicht mehr durchblickst, aber z.B. bei irgendwelchen simplen Minispielen ist das wirklich übertrieben.

[R.D.]

Kommentieren ist definitiv wichtig, vor allem bei Makercode. Wenn du dir deinen Code nach langer Zeit wieder anschaust und ihn versuchst zu verstehen, bist du für jede sinnvolle Kommentarzeile dankbar. Auch ein anständiger Kommentarkopf kann da Wunder bewirken. Wer Kommentare ablehnt ist entweder faul oder hat ihren Sinn nicht verstanden.

...

Siehe ~Jack~
Im Studium arbeiten wir ja auch in Teams, da wird nur das kommentiert was auf den ersten Blick nicht ersichtlich ist.
Ich sagte nicht, das es unwichtig sei oder so ^.~ Übrigens habe ich vorallem bei Makercode wenig Schwierigkeiten, aber bei komplexeren Sachen -wie gesagt- wird kommentiert ^.~

[R.F.]

War lediglich ein Tipp, der vor allem an die Anfänger gedacht war, da diese oft schon Probleme mit den "einfachen" Sachen haben.
Wenn man mit denen das erste mal arbeitet, wäre es jedenfalls sinnvoller Kommentare zu setzen und wenn sie dann geübter sind, können sie sie natürlich auch weglassen, weil sind ja dann überflüssig.

[makenshi]

So wurde es aber nicht ausgedrückt oder erklärt.

Ich spreche mich da ganz offen als gegner von viel Kommentar aus.
Wenn ich eine Methode "shuffle" habe die in einer Klasse "Kartenstapel" liegt, dann sollte sich das evtl von selsbt erklären.

...

So wie es hier gesagt wurde ist es der völlig falsche Ansatz. Eine ganze Methode erklärt sich sowieso nicht von selbst. Da sollten Kommentare her. Ob für sich selbst oder für andere.

Ich spreche mich da ganz offen als gegner von viel Kommentar aus.

...

Das ist halt auch ein Satz der so in meinen Augen Unsinn ist. Der Extremfall das ein Code zu gut kommentiert ist, ist immer noch besser als gar keine Kommentierung.

[R.D.]

So wie es hier gesagt wurde ist es der völlig falsche Ansatz. Eine ganze Methode erklärt sich sowieso nicht von selbst. Da sollten Kommentare her. Ob für sich selbst oder für andere.

...

Ich glaube hier liegt ein missverständnis vor. Ich denke ich sehe viel Kommentar anders als du. Vom Studium kenne ich, das für ganz einfache Sachen echt einer 2 Kommentare für eine Codezeile gemacht hat, das ist imho
zuviel. Klar mach ich auch über fast jede Methode ein Kommentar, aber maximal mit einer Zeile (sofern es nicht näher erklärt werden muss, wie gesagt bei Teamarbeit ist das was anderes). Setter und Getter würde ich nur einmal kommentieren und nicht jedesmal neu.

Das ist halt auch ein Satz der so in meinen Augen Unsinn ist. Der Extremfall das ein Code zu gut kommentiert ist, ist immer noch besser als gar keine Kommentierung.

...

Ich sehe viel Kommentar halt so, das man im Detail beschreibt was eine Methode macht. Ich meine, es reicht wenn man das Stichpunktartig macht, bzw haben wir das bei der Teamarbeit auch so beschlossen (und ich bin noch lange nicht so gut in Java wie mein Teampartner).

[makenshi]

Ich glaube hier liegt ein missverständnis vor. Ich denke ich sehe viel Kommentar anders als du. Vom Studium kenne ich, das für ganz einfache Sachen echt einer 2 Kommentare für eine Codezeile gemacht hat, das ist imho
zuviel.

...

Das ist eine so nicht haltbare Pauschalaussage. Je nachdem was in dieser einen Zeile Code passiert kann es durchaus sinnvoll sein viel Kommentar dahinter zu hängen. Besonders in Skripten in denen Erklärungen stehen ist es besser eine Zeile ausführlich zu erklären als sie der Interpretationsgabe des Leser zu überlesen. Man kann immerhin im voraus nie wissen welchen Stand dieser hat.

Klar mach ich auch über fast jede Methode ein Kommentar, aber maximal mit einer Zeile (sofern es nicht näher erklärt werden muss, wie gesagt bei Teamarbeit ist das was anderes). Setter und Getter würde ich nur einmal kommentieren und nicht jedesmal neu.

...

Setter und Getter sind ein absoluter Sonderfall. getTime() im Bezug auf ein Dateobjekt bspw. ist da ausnahmsweise Beschreibung genug. Eine ordentliche Methodenkommentierung sieht immer noch so aus:

Code:

/**
* Generiert ein Objekt.
* @param parameter Daten die für die Erzeugung des Objekts
*                  erforderlich sind.
* @return Das generierte Objekt
*/
public Object generateObject(Datentyp parameter){
// ...
}

Das ist jetzt am Beispiel einer Javadoc zusammengebaut. Bei diesem Methodenkopf kann erstmal jeder schon bei reiner Benutzung sehen wie sie zu benutzen ist, was sie erwartet und was man zurückbekommt.
Eine Zeile für eine Methode ist also viel zu wenig. Professioneller Quellcode sieht imo anders aus. Es heisst nicht umsonst das richtige "Programmierer" kommentieren. Und zwar anständig.

Ich sehe viel Kommentar halt so, das man im Detail beschreibt was eine Methode macht. Ich meine, es reicht wenn man das Stichpunktartig macht, bzw haben wir das bei der Teamarbeit auch so beschlossen (und ich bin noch lange nicht so gut in Java wie mein Teampartner).

...

Nein, viele Kommentare müssen nicht zwangsläufig sein das man im Detail beschreibt was dort abläuft. Das ist bei Erklärungsskripten wie gesagt sinnvoll, in einer "richtigen" Anwendung eher nicht. Dort sind Stichpunkte ok, jedoch sollten dort auch allerlei Informationen untergebracht werden die nötig sind um den Context des Codes zu verstehen. Warum wurde Methode xyz aufgerufen? Warum wende ich den regulären Ausdruck dort an? Das ist nicht immer aus den Reihen Codezeilen ersichtlich.

Ich denk einfach das gute Programmierung grundsätzlich was damit zutun hat das man auch diesen Part richtig angeht. Und Aussagen die in Richtung "das ist nicht immer so wichtig", sind mit äußerst Vorsicht zu begutachten. Sie zeugen meist von falschem Verständnis was die Kommentierung angeht.

[Rpgmaker11]

Also.....

Ich mach ein MoveEvent und dann ein Teleport in ein Haus!
Und nach dem Teleport soll er zu jemand laufen und ihn ansprechen...
Aber bei mir funktioniert es nicht das er nach der Person das Move
Event ausführt ... Bleibt stehen und ich kann mich nicht bewegen...

Muss ich dann bei der Seite bleiben also z.B
>Move Event : ----
>Message: Hallo
>Message: (Held) Tschüss"
>Move Event: (läuft der Held an eine Tür)
>Teleport : Ort **/**
>MoveEvent (Nach dem er Teleportiert ist bewegt er sich nicht mehr obwohl ein Move Event da ist Move All drine ist"

Hoffe es ist verständlich

[~Jack~]

Du könntest auch einfach mal das Projekt hochladen damit man sehen kann was du falsch machst.
Hier z.B.

[R.F.]

Mach das Event doch als CommonEvent (wenn es auf mehrere Maps zugreift, meine ich)

[R.D.]

Code:

/**
* Generiert ein Objekt.
* @param parameter Daten die für die Erzeugung des Objekts
*                  erforderlich sind.
* @return Das generierte Objekt
*/
public Object generateObject(Datentyp parameter){
// ...
}

Das ist jetzt am Beispiel einer Javadoc zusammengebaut. Bei diesem Methodenkopf kann erstmal jeder schon bei reiner Benutzung sehen wie sie zu benutzen ist, was sie erwartet und was man zurückbekommt.
Eine Zeile für eine Methode ist also viel zu wenig. Professioneller Quellcode sieht imo anders aus. Es heisst nicht umsonst das richtige "Programmierer" kommentieren. Und zwar anständig.

...

Ja, genau das ist für mich auch normal. Was ich aber "gelernt habe" ist sowas:

Code:

/**
 * Die Klasse In dient zum Einlesen von Daten �ber Klassenmethoden bis Eingabe
 * und Ausgabe (input output kurz IO) im 2. Semester behandelt werden.
 * Dann werden die M�ngel der In Klasse besprochen und diese verbessert.<br>
 * <br>
 * Folgende globale Klassenvariable ist implementiert: private static BufferedReader tastatur <br>
 * <br>
 * Die Klassenmethoden erm�glichen das Einlesen der einfachen Datentypen 
 * und einer Zeichenkette (String) von Konsole, Diee Methoden sind nach folgendem Schema benannt:
 * readDatentyp.<br>
 * <br>
 * Der Eingabestrom wird nicht geschlossen, damit mehrere Methoden gleichzeitig eingesetzt werden k�nnen. 
 * Deshalb auch die globale Klassenvariablen! <br>
 * 
 * @author Gabriele Schmidt
 * @version 1.2
 * 
 */

Nein, viele Kommentare müssen nicht zwangsläufig sein das man im Detail beschreibt was dort abläuft. Das ist bei Erklärungsskripten wie gesagt sinnvoll, in einer "richtigen" Anwendung eher nicht. Dort sind Stichpunkte ok, jedoch sollten dort auch allerlei Informationen untergebracht werden die nötig sind um den Context des Codes zu verstehen. Warum wurde Methode xyz aufgerufen? Warum wende ich den regulären Ausdruck dort an? Das ist nicht immer aus den Reihen Codezeilen ersichtlich.

...

Ok, da hast du natürlich recht. Arg aber auch
Ich muss zugeben das ich bei den Code hier:

Code (java):

for(int i = 0; i < enemy.size(); i++) {
        if(waveStart.get(i) < distance && waveStop.get(i) > distance) {
          for(int j = 0; j < enemy.get(i).size(); j++) {
            if(enemy.get(i).get(j).isAlive() && !enemy.get(i).get(j).isOutOfWindow()) {
              g2d.drawImage(enemy.get(i).get(j).getImage(), enemy.get(i).get(j).getX(), enemy.get(i).get(j).getY(), this);
            }
          }
        }
      }

Tatsächlich Kommentare habe, auch wenn es eigentlich klar ist was passiert (nur halt nicht für meinen Partner).

Ich denk einfach das gute Programmierung grundsätzlich was damit zutun hat das man auch diesen Part richtig angeht. Und Aussagen die in Richtung "das ist nicht immer so wichtig", sind mit äußerst Vorsicht zu begutachten. Sie zeugen meist von falschem Verständnis was die Kommentierung angeht.

...

Ich denke, du hast schon Recht. Ich bin wahrscheinlich noch viel zu unerfahren und habe noch gar nicht so kompliziertes Zeug gebaut (Außer beim Maker, da habe ich auch etwas komplere Sachen nicht kommentiert, einfach weil ich damit Erfahrung habe.

[Kyuu]

Kommentare sollten - ausgehend von einer sauberen Programmierung - nicht beschreiben was der Code macht, sondern wieso er da ist. Was der Code macht sollte aus dem Namen der Routine hervorgehen. Der folgende Kommentar ist zum Beispiel vollkommen redundant:

Code (C++):

 
/* Tut dies und das. */
void tueDiesUndDas() {
    /* ... */
}
 

Während dieser durchaus gerechtfertigt ist:

Code (C++):

 
void tueDiesUndDas() {
    /* ... */
    A* a = new A();
    /* da ältere MSVC-Versionen bei fehlgeschlagener Speicherreservierung
        statt std::bad_alloc zu werfen einen Nullzeiger zurückgeben */
    if (!a) {
        throw std::bad_alloc();
    }
    /* ... */
}
 

Oft wird natürlich auch die Kommentierung des Rückgabewertes, sowie der Parameter einer Routine benötigt, besonders bei komplexeren Datenstrukturen in Verbindung mit fehlender automatischer Speicherbereinigung (C/C++), oder der Vermerk der Vor- und Nachbedingungen, sowie der Invarianten (Design By Contract). In diesen Fällen sind auch seitenlange Kommentare völlig gerechtfertigt.

Die Aussage, dass es unsinnig ist eine Zeile Code mit 4 Zeilen Kommentar zu versehen ist selbst unsinnig. Vom Code- zu Kommentarzeilen-Verhältnis kann man nicht auf den Sinn, oder Unsinn eines Kommentars schließen.

Das Kommentar-Beispiel von makenshi dient eher der API-Dokumentation für Tools wie Javadoc, oder bei C/C++ Doxygen, was natürlich auch seinen Sinn hat, aber als Beispiel dafür, wie professioneller Code kommentiert wird, würde ich es nicht nehmen. Ein allgemeingültiges Beispiel kann man sowieso schlecht finden, da es immer auf die Situation ankommt.