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?
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?
Benutzerinformationen überspringen
Motto: Wer anderen eine Bratwurst brät, der hat ein Bratwurstbratgerät.
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.
Oder du schreibst ein Script das der Database sagen kann: Das da ignorieren <__<" Also unrentabel^^"
-
Werbung -
1plus3
-
Nuuuhminaaah
-
compétences(Dieser Tab ist rein satirisch.)mes compétences
max.
Maps machen
Musik machen
Scripts machen
Story ausdenken
Pixeln und so
Events proggen
-
mes projets-
Silentium
Name: Silentium
Maker: Eigenbau (C++, x86-SSE/AVX-Assembly, Ruby/Lua)
Story
NPCs
Scripts
Ressis
Maps
Gesamt(3+4)% 42 69% 0815 -17.438 103.38% ± 6.3mm²
(Die Tabelle erfüllt lediglich satirische Zwecke.) -
OnyxEine 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.
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). - Compiler - Das Drachenbuch [978-3-8273-7097-6]
-
-
enfinJe ne peux pas parler français.
C'est tout ce que Goodle et les restes de cours de français.
reichts nich einfach wenn man unter "game" -> "select rtp..." das standart abstellt???
man brauch das rtp nich aufm Pc zu haben um es spieln zu können
doch es hat was davon
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^^"
man brauch das rtp nich aufm Pc zu haben um es spieln zu können

Sofern man nicht Teile aus dem Standart-RTP benutzt 
Lg

Lg
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.
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.
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.



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.)


