die methode von makenshi ist ganz gut...
jedoch hat sie folgende schwachpunkte:
- das herauslesen der itemanzahl wird etwas aufwendiger...
um das zu entgehen, würde ich gleichzeitig mit einen pointer die itemanzahlen
parallel beim item-insert prozess einfügen: (von 90- 120 leg ich mal die variablen fest in denen die anzahl gespeichert werden...)
[Common Event: Inventar_Insert - Call]
Set [0061:Pointer] = 30; // Der Beginn unseres Inventarfeldes war 0030 !
set [0062ointer2] = 90
LABEL 1
IF [0061:Pointer] > 60 THEN //Das Ende unseres Inventarfeldes war 0060 !
End Event Processing;
ELSE // Es ist noch Platz im Inventar
Set [0062:Vergleichsvari] = [[0061:Pointer]];
IF [0062:Vergleichsvari] == 0 THEN // Die Variable ist leer und benutzbar
Set [[0061:Pointer]] = [0063:Parameter_Insert];
Set [[0062ointer2]]=[0064
nzahl des hinzugefügten items]
End Event Processing;
ELSE //die Variable ist belegt !
[0061:Pointer] = [0061:Pointer] + 1;
[0062:Pointer2] = [0062:Pointer2] + 1;
Jump to LABEL 1;
ENDIF
ENDIF
soooo.. jetzt brauch man natürlich neben der vari 0063 parameter_insert
noch die variable 0064, die die anzahl des hinzugefügten items beeinhaltet...
also wird der code so hinzugefügt:
Set [0063:Parameter_Insert] = GegenstandID(z.B. 10);
set [0064nzahl des hinzugefügten items] = itemanzahl.. zb 3 stück...
Call Event: Inventar_Insert
so... jetzt zum anderen schwachpunkt... wie man von dem code ablesen kann, werden die items ja in chronologischer reihenfolge angezeigt... dh. wenn item c und dann item a eingesammelt wurden, dann werden sie im itemmenü auch in der reihenfolge angezeigt...
jedoch würde bei makenshi, in dem falle man fände noch ein item a, dieses sepperat angezeigt... also c, a, a... was meistens nicht erwünscht wird...
man muss also in dem falle zusätzlich abfragen, ob die gegenstands ID die in parameter_insert gespeichert wird, bereits vorhanden ist, und in diesem falle einfach die itemanzahl dieses slots erhöhen um die gewünschte zahl...
würde also so aussehen:
Common Event: Inventar_Insert - Call]
Set [0061:Pointer] = 30; // Der Beginn unseres Inventarfeldes war 0030 !
set [0062ointer2] = 90
LABEL 1
IF [0061:Pointer] > 60 THEN //Das Ende unseres Inventarfeldes war 0060 !
End Event Processing;
ELSE // Es ist noch Platz im Inventar
Set [0062:Vergleichsvari] = [[0061:Pointer]];
IF [0062:Vergleichsvari] == 0 THEN // Die Variable ist leer und benutzbar
Set [[0061: Pointer]] = [0063: Parameter_Insert];
Set [[0062: pointer2]]=[0064: Anzahl des hinzugefügten items]
End Event Processing;
ELSE //hier muss überprüft werden, ob die ID schon vorhanden ist
IF [0062:Vergleichsvari] == [0063:Parameter_Insert] THEN
(Set [[0061:Pointer]] = [0063:Parameter_Insert]; ) //(kann weggelassen werden...)
Set [[0062ointer2]]=[[0062
ointer2]]+[0064
nzahl des hinzugefügten items]
End Event Processing;
ELSE //die Variable ist belegt !
[0061: Pointer] = [0061: Pointer] + 1;
[0062: Pointer2] = [0062: Pointer2] + 1;
Jump to LABEL 1;
ENDIF
ENDIF
sooo... das wäre das...^^
um mal eines vorwegzu nehmen... es ist einfacher die items in ner festen reihenfolge anzuzeigen, d.h. NICHT chronologisch... (aber immernoch OHNE die lästigen leerstellen) also wenn man zuerst item c und dann item a findet, dann wird im menü trotzdem A zuerst und dann C angezeigt...
das hat den vorteil, dass man nicht bei der itemaufnahme das callevent durchlaufen muss, sondern nur, wenn man ins itemmenü reinkommt, und zweitens kann man das mit dem items-bekomm zeugs (also items werden im maker weiterhin mit Add item hinzugefügt) beibehalten...
und drittens fällt es den wenigsten auf, dass diese items chronologisch angezeigt werden.. oder es stört niemanden, wenn diese nicht chronologisch angezeigt werden...
so nen chronologisches item anzeigs dingens hab ich schonmal gemakert:
http://rs11.rapidshare.com/files/222...e_ueHseins.rar