Kleine RmXP FAQ

[CapSeb]

Der Thread hier ist bekanntlich schon etwas älter und geht inhaltlich von Grundlegenden Unterschieden zwischen RM2k und RMXP bis zu speziellen Ruby Fragen. Und da konnte ich bisher rauslesen, dass es für performance-abhängige Spiele quasi notwendig ist, sich mit (Ruby-)"Threads" auszukennen. Inwiefern kriegt man bei den grundlegenden Ruby-Tutorials das Wissen darüber vermittelt? Oder andersherum gefragt: Wie lange muss ich mich mit Ruby auseinander setzten, bis ich all das umsetzen kann, was mit dem RM2k ohne Ruby und Performance-Verluste machbar ist (siehe kelvens KS)?
Vielleicht kann auch jemand mal kurz beschreiben, was ein Thread überhaupt ist. Im übrigen kann ich bisher kein Bisschen Ruby, außer das, was hier beschrieben wurde... ... ...

[Macros]

Der Thread hier ist bekanntlich schon etwas älter und geht inhaltlich von Grundlegenden Unterschieden zwischen RM2k und RMXP bis zu speziellen Ruby Fragen.
[

...

Also su musst Ruby nicht unbedingt können. Ich kann selbst auch keine Scripte schreibe.
Ich kann sie in besten Falle verstehen und einfachste Dinge austauschen.
Die Performence des Xp's kannst du kaum verbessern. Es gibt ein Ruby-Script was Lags bei zu vielen Events verhindert, das wars dann aber schon.

Wie lange muss ich mich mit Ruby auseinander setzten, bis ich all das umsetzen kann, was mit dem RM2k ohne Ruby und Performance-Verluste machbar ist (siehe kelvens KS)?
[

...

Im Pronzip kannst du ein Ks genauso im Xp bauen wie im 2k.
Ich selbst habe mein AKS mit Events gemacht und es funktioniert.
Wenn man es gescheit macht braucht ein Event-Script auch nicht sehr viel mehr Systemressourcen als ein Ruby-script (glaube ich).
Allerdings kannst du es mit Ruby schneller erstellen.

Vielleicht kann auch jemand mal kurz beschreiben, was ein Thread überhaupt ist. Im übrigen kann ich bisher kein Bisschen Ruby, außer das, was hier beschrieben wurde...

...

Erlichgesagt weis ich es nicht und ich brauchte es bisher auch nicht, aber hier ist die Definition von Thread in Wikipedia

[MagicMagor]

Der Wikipedia-Artikel ist vielleicht etwas hoch. Einfach gesprochen erlaubt ein Thread es, einen bestimmten Code gleichzeitig neben dem Hauptprogramm auszuführen. Der neue Thread läuft dann, quasi wie ein zweites Programm im Programm, nebenher.
Normalerweise muss man damit vorsichtig sein, da man nie weiß an welcher Stelle der Abarbeitung der andere Thread ist und es zu Problemen kommen kann wenn zwei Threads auf die gleiche Variable zugreifen.

In Ruby kann man aber einen Thread fragen "bist du fertig?" und wenn der dann ja zurück gibt entsprechend damit arbeiten, ansonsten läßt man ihn weiterlaufen. Die Auslagerung von Berechnungen in andere Threads entlastet den Hauptthread (also das Programm) was im Falle des XP sich dann wohl in weniger ruckeln äußert.

[faucon]

Ich hoffe mal, hier kann man auch Fragen reinstellen.

Ich suche nämlich...
...den Befehl "Set terrain ID"
...die Option "Wait until key hit"

Ich hoffe, mir kann jemand weiterhelfen.

[Kelven]

Für "Set Terrain ID" gibt es bei dem XP unter "Control Variables" bei "Character" die Option "Terrain Tag". Wenn du das Terrain unabhängig von einem Event ermitteln willst, kannst du das auch per "Call Script" machen. x und y sind die Koordinaten auf der Map. In meinem Beispiel wird das Ergebnis vom Scriptaufruf der ersten Variable zugewiesen.

Code:

$game_variables[1] = $game_map.terrain_tag(x,y)

Wenn du mit "Wait until key hit" die Option bei "Enter Password" meinst, dann ist das bei dem XP das Eventkommando "Button Input Processing". Die Abfrage wartet automatisch solange bis eine Taste gedrückt wurde.

[faucon]

Danke für die Antwort.

[Ascare]

Ich habe gerade gemerkt das es bei den Common Events alle PPs/Autoruns nur mit einem Switch aktiviert werden können. War ja beim 2k/3 nicht so. Ist zwar nicht so schlimm und schützt einen auch davor unnötige PPs laufen zu lassen, aber sicher kann man per Ruby eine Lösung finden. Vorschläge?

[Kelven]

Ich bin zwar eher Rubynoob, aber trotzdem mal ein Vorschlag. In dieser Methode von Game_CommonEvent werden ja anscheinend die PPs abgehandelt.

Code:

  def refresh
    # Create an interpreter for parallel process if necessary
    if self.trigger == 2 and $game_switches[self.switch_id] == true
      if @interpreter == nil
        @interpreter = Interpreter.new
      end
    else
      @interpreter = nil
    end
  end

Hier könnte man evtl. eine weitere Kontrollstruktur mit der Abfrage der ID des Common Events (@common_event_id) einbauen und dort die Bedingung für den Switch weglassen. Berichtigt mich wenn ich mich irre.