• Anmelden

1

Sonntag, 7. Dezember 2008, 18:40

RTP Battlers/Charsets löschen

Hallo Community, wie kann man die RTP Battlers bzw. Charsets aus seinem Projekt löschen?
Ich habe es schon folgendermaßen versucht: (Bsp. an den Battlers) Battlers exportiert, erneut importiert (um sie löschen zu können). Wenn ich das so mache tauchen die battlers jedoch immer wieder auf...
Kann mir jemand helfen?
Bild

CaK

Rekrut

Motto: Drunken Master

  • Nachricht senden

2

Sonntag, 7. Dezember 2008, 18:42

Wozu sollte das gut sein? Aber ansonsten würd ichs einfach aus dem Ordner löschen, wo das RTP gespeichert ist...


Seid ihr des Denkens leid?
http://thinktanic.blogspot.com/

3

Sonntag, 7. Dezember 2008, 18:44

Hallo du hast Glück das ich da bin^^ :rolleyes: Bevor ich dir helfe habe ich mal ne Frage, wozu willst du die löschen? Es könnten dabei Probleme auftreten! (Ich habe schlechte Erfahrung damit.)

EDIT:Mist Cak war schneller^^ :schock:

Neo-Bahamut

Himmelsgleicher

Motto: Wer anderen eine Bratwurst brät, der hat ein Bratwurstbratgerät.

  • Nachricht senden

4

Sonntag, 7. Dezember 2008, 19:00

Du müsstest alle Ressourcen aus dem RTP, die du brauchst, ins Projekt importieren und dann einfach alle RTPs aus der Game.ini löschen.
Spoiler: Wurstinator
zum Lesen den Text mit der Maus markieren

Spoiler: Lazer-Wurst
zum Lesen den Text mit der Maus markieren

Spoiler: Hallowurst
zum Lesen den Text mit der Maus markieren

Evrey

Oberschurke im Ruhestand

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

  • Nachricht senden

5

Sonntag, 7. Dezember 2008, 22:51

Oder du schreibst ein Script das der Database sagen kann: Das da ignorieren <__<" Also unrentabel^^"
Edit Macht eh' keinen Sinn. Alles was im RTP is' is' nicht im Projekt, somit hat dein Projekt nix davon, wenn du Dateien des RTP ignorierst, da der Platzbedarf der gleiche bleibt^^"

  • :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

6

Sonntag, 7. Dezember 2008, 23:09

reichts nich einfach wenn man unter "game" -> "select rtp..." das standart abstellt???

Zitat

Macht eh' keinen Sinn. Alles was im RTP is' is' nicht im Projekt, somit hat dein Projekt nix davon, wenn du Dateien des RTP ignorierst, da der Platzbedarf der gleiche bleibt^^"
doch es hat was davon
man brauch das rtp nich aufm Pc zu haben um es spieln zu können ;)
:king:

GUMPi

Landsknecht

Motto: Ich finde den "Like-Button" so ziemlich uncool, echt mal.

  • Nachricht senden

7

Montag, 8. Dezember 2008, 17:32

Sofern man nicht Teile aus dem Standart-RTP benutzt ;)

Lg
Bild

8

Montag, 8. Dezember 2008, 23:55

Oh mein gott... machts doch schwerer als es ist.. -.-

Also..
Ob du jetzt battler ausm RTP verwendest, oder nicht.. Dein Spiel wird immer dieselbe größe haben...
Ist dein projekt 100,00 MB groß, und du entscheidest die battler ausm RTP doch noch einzubau ( geht ja ohne import ).. ist dein projekt danach immernoch 100,00MB groß..

Warum:
Die RTP wird ja nicht in dein projekt reinkopiert, sondern ist eine selbstständige Bibliothek. Darum müssen andere user ja auch das RTP installieren wenn sie ein Spiel spielen wollen.
also lass die battler ruhig drin.. und kümmer dich ned um die. Sie ändern an der Projektgröße oder leistung nix.

RTP unterscheidet sich im übrigen ( hast hoffentlich gemerkt ).. an den blauen Kreisen in den Ressourcenauswahl..
Alle Ressis, welche du importiert hast, haben einen roten kreis.
D.h. alle Ressourcen in deinem Ressourcen manager, die einen blauen Kreis haben, kannste ignorieren wenn du willst.


Aber ich will die nicht in meinem projekt haben:
Hast du auch nicht. Und selbst wenn du sie aus dem RTP löscht.. Der Spieler wird das RTP installieren müssen.. und spätestens dann, sind die battler beim Spieler wieder da.. demnach isses so hoch wie breit und tief ob du sie in der liste hast, oder ausm RTP verezichniss gelöscht hast. Allerdings bringt das löschen mancher Ressourcen fehler.. daher rate ich grundsätzlich davon ab.
There was a Cave,
below a Silent's Grave.
Tunnels, extending far, running wide,
going deep into the World on the other Side.
Poor little Child, that was to brave,
died painfully deep down, in the Devil's Cave.

Social Bookmarks