Frage zu Afixen

[Sanguinus]

Hallo,

ich hätte da zwei Fragen zu den Afixen:

1. In der MagicSuffix.txt fiel mir auf, dass die charges mit "-Anzahl" und "-Level" angegeben sind, also z.B.
charged | skill# | -20 | -3

Als ich das anfangs übernahm (negative Werte) kamen im Spiel 11, anstelle von 10 (-10 in der .txt) Ladungen heraus.
Als ich die Werte dann normal positiv eintrug, passte alles?

2. Ich habe überlegt, dass es auf magischen Items im Grunde nur positive Eigenschaften gibt, keine Negativen (wie es glaube ich bei Diablo 1 noch der Fall war).
Könnte man denn a) einfach negative Werte verwenden, die wirklich negativ im Spiel ankommen und nicht wie bei Punkt 1? und könnte man b) die im Spiel generierten Items davon abhalten auch beim Händler zu erscheinen? (spawnable 0 wäre also keine Lösung)

3. In welcher Reihenfolge werden die Afixe vom Spiel gebildet?
Wird erst geschaut, welcher Waffentyp passt und dann die group in Abhängigkeit vom Level gewürfelt, oder wird erst gewürfelt und dann geschaut, ob der Waffentyp erlaubt ist?

Gruß

 

[destrution]

1. Jo, eigentlich gehören da positive werte rein... weiß jetzt nicht warum da negativwerte drin stehen^^

2. a) man kann negative werte verwenden, sicher. Musst bloß bei manchem via isc einstellen, dass diese eigenschafft auch negative werte zulässt und kein festes minimum von 0 oder so hat

b) eh... du willst also, dass die händler keine items mehr führen? oder was willst du genau...

3. Ersteres:
Item wird ausgewählt -> prüfung auf unique? set? rare? magisch? superior? normal? low quality? -> Generierung der eigenschaften

 

[Sanguinus]

@destrution
2. war leider nicht ganz genau formuliert: ich meinte, wenn es Items mit negativen Eigenschaften im Spiel gäbe, könnte man meines Wissens die Händler nicht davon abhalten auch diese negativen Items im Shop zu führen.
Wenn man das könnte, wäre das eine neue Idee für mein Mod. Wenn nicht, würde ich die Idee streichen, da aus meinem Verständnis kein Händler mit bestem Wissen was schlechtes verkaufen sollte!

3. D.h. die Prüfung auf itypeX und etypeX findet gleich am Anfang statt und aus diesem Pool wird nach group, frequency etc. gewürfelt?
z.B. wenn man 30 Charges (in einer Group) erstellen würde und nur eine passte auf ein Schwert, der Rest wäre Rüstung: Hätte ein Schwert dann dieselbe Chance diese eine Charge zu erhalten, wie ein Rüstungsteil auf eine der anderen 29 Charges? (gleiche Frequenz etc. vorausgesetzt)
Oder hätte ein Schwert dann eine ungleich schlechtere Chance auf eine Charge, nur weil es seltener in der Textdatei vorkommt?

Gruß

 

[Seltsamuel]

Hi,

man kann verhindern das Händler die negativen Eigenschaften verkaufen indem man den Level dieser Eigenschaften über den legt den die Händler im Shop maximal verkaufen können. Wäre nix für Lowlevelitems aber ich denke mal das war auch nicht die Zielgruppe ^^.
Ansonsten wären weitere Sachen über Codeedits filterbar was jedoch gute Kenntnisse vom Coden erfordert.

Davon mal ab warum sollten die Händler keine negativen Eigenschaften mit verkaufen? Heißt ja nicht automatisch das das Item an sich schlecht ist denn es könnte ja auch zusätzlich herrausragende positive Eigenschaften haben wo man sich überlegt Mensch den Malus nehm ich jetzt in kauf.
Ansonsten liegt die Kaufentscheidung immer beim Spieler und wie im RL kannst auch beim Autokauf übern Tisch gezogen werden.

Gruß

Seltsamuel

 

[Sanguinus]

@Seltsamuel
Dein Einwand mit den negativen Eigenschaften auf Items hat was für sich, ich werde das einmal überdenken!

Nun noch eine weitere Frage: Wenn ein Item Prefix und Suffix erhält, von welchem erhält es die Farbe?

Gruß

EDIT: nach meiner Einschätzung müsste es der Suffix sein, nach dem sich die Farbe richtet?

 

[Eimernase]

@Seltsamuel
EDIT: nach meiner Einschätzung müsste es der Suffix sein, nach dem sich die Farbe richtet?

Vorrangig ist Prefix für die Farbe zuständig.Ist in der magicprefix.txt allerdings keine Farbe für den State definiert,so wird beim generierten Suffix nachgesehen,ob dieser eine zugewiesene Farbe enthält.

 

[Sanguinus]

Hallo,

eine weitere Frage:
Ein Magic Item hat lt. "The Arreat Summit" folgende Chancen bzgl. Prefix und Suffix:
Both Prefix and Suffix: 25%
Only a Prefix: 25%
Only a Suffix: 50%

Leider steht dort nicht was passiert, wen bei Prefix+Suffix auf dem Item auch gleiche Typen eines Effekts aus beiden Listen gewählt werden, z.B. +Mana als Prefix und +Mana als Suffix. Unterschiedliche Gruppen sind selbstverständlich gegeben.

Addieren sich dann die beiden Werte zu einem größeren Wert auf dem Item, als sonst normalerweise erreichbar wäre? Z.B. wenn Prefix und Suffix aufgrund des aktuellen levels nur je max +20 Mana geben könnten, hätte das Item dann +40 Mana?

Gruß

 

[Eimernase]

Sofern sowohl Pre-wie auch Suffix die gleichen Eigenschaften mitbringen,würden sich diese dann auch entsprechend addieren...also eine Summe aus Pre-und Suffix.

Nur dürfte meines Wissens derartiges gar nicht von Haus aus gegeben sein,da es zwar die gleichen Eigenschaften gibt für Pre-und Suffix,diese aber dann nicht auf dem gleichen Itemtyp vorkommen,sondern auf andere Typen zugeschnitten sind.

 

[Sanguinus]

Könnte man die Pre- und Suffix.txt eigentlich auch komplett löschen und geordnet neu aufbauen? In der PK "Cubemain.txt Code Reference" steht z.B., dass die Cube-Recipe-Output-Parameter "pre=prefix (row # -2 from magicprefix)" und "suf=suffix (row # -2 from magicsuffix)" auf die beiden Dateien zugreifen, die Zeilennummern müsste man dann entsprechend anpassen (wenn man die Rezepte behalten möchte).

Oder gibt es außerdem noch feste Verweise / hardcoded stuff, so dass Daten im Original erhalten bleiben müssten?

Gruß

EDIT: @Eimernase
Charms haben im Prefix und im Suffix die Möglichkeit denselben Typ an Elementarschaden auszuteilen.

 

[Eimernase]

Man könnte diese beiden Dateien sicherlich löschen und neu aufbauen,fragt sich nur,ob man nicht mit einer Neustrukturierung ohne Löschen besser fährt.

Meines Wissens gibt es in beiden Dateien keinerlei hardcodiertes.

PS: Charms sind eh die große Ausnahme,bestes Beispiel waren schon immer Giftcharms

 

[Sanguinus]

Ich habe nun die Prefix und Suffix Dateien neu aufgebaut.
Mir war nicht klar, was es für einen Unterschied macht, ob ich in der bestehenden Datei Zeile für Zeile verschiebe, oder auf einem anderen Blatt alles vorbereite und dann zusammenfüge. Letzteres schien mir jedenfalls übersichtlicher.

Leider passt da irgendetwas mit den Prefix-/ Suffix-Names nicht, die habe ich nämlich z.T. neu gemacht und in der expansionsstring.tbl abgelegt (ersetzt sofern vorhanden, der Rest angefügt).
Bei Weapons und Armor sehe ich keinen Fehler (soweit ich auf die Schnelle beurteilen kann). Allerdings stimmen die Namen bei den Charms überhaupt nicht.

Liegt da evtl. doch etwas hardcodiertes vor?

Wenn ich die alten Prefix und Suffix Textfiles widerherstelle, stimmen die Namen wieder - es liegt also nicht am .tbl-Import, sondern an den Textfiles, oder den alten Affix-Namen. Offenbar werden neue Affix-Namen bei Waffen und Rüstung akzeptiert, aber nicht bei Charms?!
Oder die Namen der Charms werden an anderer Stelle gesucht (Zeilennummer kann nicht sein), womöglich in der patchstring.tbl?
An "Version 100" für jede Zeile kann es ja wohl auch nicht liegen? (Spiele ausschließlich Expansion)

Gruß

EDIT:
das hat sich wohl geklärt: offenbar ist nur die bereits vom Char getragene Magic- und Rare-Ausrüstung betroffen.
Neu gefundene, d.h. neu gespawnte Charms, Rings und Amulets haben genau die erwarteten Effekte.
Also, kein Fehler!

 

[Sanguinus]

Hallo,

meine Idee, negative Affixe einzuführen, scheint nicht so ganz zu funktionieren.
Ein Prefix, der "dmg% | -5 | -10" hat, erscheint im Spiel als "+1 to Maximum Damage".
Ein Prefix, der "ac | -5 | -10" hat, erscheint im Spiel korrekt als "-7 Defense".

Hat hier jemand schon Erfahrungen gesammelt?

Gruß

EDIT:
meine bisher gefundenen Codes, die mit negativen Werten funktionieren und grafisch im Spiel auch Sinn ergeben:
ac
light
stam
ease
regen (wird zu "Life Drain")
light
res-cold
res-fire
res-ltng
res-pois
mana
hp
str (anscheinend max -32)
dex (anscheinend max -32)
vit (anscheinend max -32)
enr (anscheinend max -32)

 

[SirSamusAran]

die maximalwerde im nedativ bereich werden durch die spalte "Add" in der itemstatscost.txt geregelt

dieses add subtrahiert sich dann aber vom maximum im posivien bereicht!
man verschiebt also die variable damit

z.b. von savebit:10 Add:0 0 - 1023
auf Savebit:10 Add:23 (-23) - 1000

savebit sind die anzahl bit´s mit der der statt abgespeichert wird und angibt wieviele variablen damit möglich sind
2^10=1024
0 is auch ein wert - deshalb 0-1023
ein statt kann maximal mit 32 bit gespeichert und verrechnet werden von d2
das wären also 2^32= 0-4.294.967.295 (mehr exp kann ein char z.b. nicht sammeln)

um also werte über das die bekannte maximum zu steigern muss du den entsprechenden savebit erhöhen

das charlevel wird von vanilla lod z.b. nur mit 7 bit gespeichert und verrechnet
daher kann man ohne das erhöhen dessen maximal bis charlevel 127 gehen

wenn man savebits verändert werden alle chars die noch reste mit den unveränderten savebits enthalten inkompatibel - können also nciht mehr geladen werden

bei itemstats kann man das noch verhindern in dem man alle item auf dem char einfach wegschmeißt/verkauft die den statt aufweisen dessen savebit man verändert hat
bei sachen wie z.b. dem charlevel kann man die alten chars nicht mehr übernehmen
das sollte man wissen um unschöne überraschungen zu erleben wenn man in einer modversion plötzlich mit den savebits rumspielt und sichd ann wundert warum die chars scheinbar kaputt sind (sie sind natürlich nicht kaputt aber das game rechnet nun mit anderen werten - würde man die zurückstellen könnte man die char wieder laden)

es gibt aber auch einige hardcoded caps
wie z.b. das maximum von 511 pfeilen in einen köcher
dem dmgcap(/lopp) pro element bei 86.xxx schaden (vor resis/ds/cs verrechnung)
oder z.b. dem anzeigecap(/loop) der life und manakugel (hier handelt es sich nur um ein cap der anzeige - man kann dennoch mehr life haben - sieht man nur nicht richtig^^) bei 32.xxx life


so nun hab ich warscheinlich wieder nen halben roman geschrieben^^
und beende damit diesen post *g



Gruß SamusAran

 

[Seltsamuel]

Hi,

damit negative Werte funktionieren müssen die stats entsprechend in der Itemstatcost eingestellt sein das sie einen negativen Bereich überhaupt haben. VORSICHT Änderungen in der Itemstatcost.txt machen vorhandene savegames und chars mit hoher Warscheinlichkeit unbrauchbar!

Gruß

Seltsamuel

 

[Freiik]

Versuch außerdem mal -10 -5 anstatt -5 -10, denn -10 ist kleiner als -5
(oder sollte das gar egal sein?)

Wenn man vorm Ändern der savebits alle Items mit dem entsprechendem Stat rauswirft, funktionieren die Chars idR weiterhin.

 

[Sanguinus]

D.h. wenn ich hier im "Original-ItemStatCost.txt" bei z.B.
str Save Bit 8 habe und Add 32, dann kann der Wert von -32 bis 223 gehen.
Bei dex, vit und enr habe ich Save Bit 7 und Add 32, d.h. von -32 bis 96.

Hier fände ich auch u.a. die Zeilen
item_armor_percent
item_maxdamage_percent
item_mindamage_percent
welche dann vermutlich negative Werte bei ac%, dmg% etc. ermöglichen (Standard ist Add 0).

Die Werte betreffen zudem nur "temporäre" Boni durch Items, nicht die Char Stats, die ja mit den Send Bits (alle 11) gespeichert werden. Betrifft das ein Item, oder alle Items gemeinsam?

Alles korrekt soweit?

Kann man die Save Bits beliebig erhöhen? Zumindest auf die höchsten einstelligen Werte, oder gibt es da irgendwann Probleme?

@Freiik
Du meinst, ich soll nicht von der 0 ausgehen, da es die ja bei dieser Bandbreitenverschiebung nicht wirklich gibt, sondern immer vom aktuellen Minimum in der ersten Zelle ausgehen? Bei meinen Tests hat es zumindest keinen Unterschied gemacht, aber ich habe auch nur kurz getestet, ob es funktioniert.

Gruß

EDIT: Ich glaube, ich schiebe das ganze mit den negativen Werten erst einmal auf die lange Bank
Ich habe ja inzwischen (theoretisch) herausgefunden, wie man alle Werte auch ins Negative rutschen lassen kann. Oft stimmt dann aber der String im Spiel von der Logik her nicht mehr. Ein vormals "+x% Enhanced Defense" lässt sich nicht einfach mit negativen Werten versehen. Hier könnte man dann in der ItemStatCost.txt auch negative Strings angeben - was auch mit bestehenden funktioniert, doch einen neuen habe ich nicht einbinden können.
Das ist mir dann doch bis auf weiteres zuviel Gewurschtel - es gibt ja noch andere Baustellen

 

[Sanguinus]

Hallo,

mal wieder eine Frage zu MagicPrefix/Suffix.txt, es geht um "Frequency" und "Group":

So wie ich die Beschreibung von PK verstehe, führt eine hohe "Frequency" nur zu priorisierter Auserwählung des Affix innerhalb einer "Group", nicht aber zu aber einer Priorisierung bestimmter Gruppen vor anderen. Mit anderen Worten findet die Auswahl der Group als möglicher Affix, vor einer und ohne Berücksichtigung der Frequency statt.

Beispiel: ich habe 10 Groups, alle haben dieslben Level und LevelReq, sowie dieselben möglichen Ziel-Items. Gruppen "1" bis "9" beinhalten Frequencies von 1. Eine Gruppe "10" hat Frequencies von 5 bis 10.
Erscheinen die Affixe von Gruppe "10" dann häufiger auf einem Item, oder haben alle Gruppen diesselbe Chance gespawnt zu werden?

Letzeres ist, wie ich denke der Fall. Wenn ja - wie kann man ganze Gruppen seltener spawnen lassen? Denn selbst wenn man 100 Gruppen hätte und Gruppe 1 aus 100 einzelnen Einträgen und Frequencies bestünde, so wäre die Chance dennoch 1:100 auf eine bestimmte Group.

Gruß