• Anmelden

1

Montag, 27. Juni 2011, 18:44

Geschlechts System

hallo, wollte hier mal fragen ob jemand so nett wäre ein simples script für mich zu schreiben ?!
ich benötige ein script welches jedem actor in der databse ein geschlecht zuweist.
das geschlecht sollte per script-condition branch abgefragt werden können.
eg. if game.actor[ID].gender = 1 (1 für mann 0 für frau oder mit string wäre noch besser)

ausserdem sollte man das geschlecht mit einem scriptcall auch ändern können.
eg. game.actor[ID]gender = 1 (genau wie bei der anderen methode)

nun jezt kommt sicherlich die frage auf wofür das ganze ?
nunja ich möchte in über ein array eine abfrage haben die checkt welche rüstungen nur für männer oder nur für frauen sind.
diese sollten dann nicht equipbar sein sollte man nicht das entsprechende geschlacht haben.
alle undefinierten rüstungen sollten für alle geschlechter equipbar sein.
eg. Male_Armors = [1,2,3,4,5]
Female_Armors = [6,7,8,9,10]

man könnte nachträglich ja auch noch andere sachen damit abfragen aber für mich ist nur das mit den rüstungen wichtig...

hoffe jemand wäre so nett mir da weiter zu helfen.
thx in advance, buddy

Evrey

Oberschurke im Ruhestand

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

  • Nachricht senden

2

Montag, 27. Juni 2011, 18:47

... und wozu nun das Script, wenn der Maker bereits bietet, was du brauchst? Erstelle für jedes Geschlecht 'ne neue Klasse, fertig. Und wenn deine Leute plötzlich transvestit werden, wechseln sie einfach die Klassen.
  • :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

3

Montag, 27. Juni 2011, 18:56

ah habe vergessen zu erwähnen das alle klassen in meine jobsystem angezeigt werden...
das sieht ziemlich scheisse aus wenn da alle jobs 2x stehen...

4

Dienstag, 28. Juni 2011, 18:19

Nimm doch Spiel Variablen.
Spielvariable 1 ist Held#1, Spielvariable 2 ist Held#2 etc.
Ist doch egal wo du den Wert ablegst, ob du das in einem Attribut der Game_Actor Klasse machst, oder in einer Spiel Variable ~ in dem Fall nicht so wichtig.

Ansonsten wäre tatäschlich der Vorschlag von Evrey denkbar, die Anzeige deines Jobsystems kann man problemlos umschreiben.

5

Dienstag, 28. Juni 2011, 19:21

also mit normalen variablen bekomm ich das wohl eher net hin weil ich ja schlecht equip nach variable sperren kann...
und das job system umschreiben und dafür dann ca 100 variablen anlegen (ja mein game hat mehr als 100 charactere) ist wohl noch mehr arbeit als ein kleines einfach zu konfigurierendes script ?!
bitte nicht falsch verstehen aber ich habe den request nicht ohne grund gemacht.
es ist ja im enteffeckt ja auch ne ganz simple funktion die man aber wie gesagt am besten mit einem script lösen könnte...
trotzdem danke erstmal

6

Dienstag, 28. Juni 2011, 22:16

Natürlich kannst du die Equipmethode nach Variablen sperren, dass sind nur ein paar Zeilen Code .-.
Bisher würde ich sagen, es ist einfacher dein Jobsystem Script umzuschreiben, als da neue Sachen einzuführen - ich wäre für Evreys Vorschlag.


Nun, wenn du aber auf deinem Lösungsweg bestehst, dann beschreibe genau, wo was abgefragt werden soll (Shop/SpielMenü/Bla), was in den einzelnen Fällen passieren soll und welche extra Scripte du nutzt (nein, ein Name reicht nicht, Quellcode muss her)

Social Bookmarks