Mein Plan zur Eroberung der Welt... eh drops

[Vigurias]

Ist es nicht egal wieviel mf jeder hat? Es geht doch darum wann welche Grunditems fallen oder irre ich mich?

Man müsste also gucken wann Monarche wann Ringe und wann Wasimmermanhabenwill fällt. Die Farbe spielt doch keine Rolle dabei. Diese beeinflusst man dann durch mehr mf.

 

[Dr.Dre]

nene wir wolln schaun ob zu bestimmten zeiten besonders viele gegenstände in uniqu ausführung dropen. (man könnte natürlich auch versuchen die itemart mit der zeit in verbindung zu bringen, nur is mir das, so muss ich gestehn, doch zu viel aufwand weils zu viele itemarten giebt )

@ Charlie83: ich werd mal versuchen so ein progi zu finden. Sehr fein, dass du das dann testen kannst! thx schon mal.

mfg
dre

 

[zeroGraphix]

nunjaa ich glaube ja das an der sache da was drann ist und das man auch den drop auf diese weise beeinflussen könnte allerdings ist es nicht möglich alle auf den selben tick zu bringen

und servertick is ja eh unbekannt wie bereits erwähnt


aber falls der drop was damit zu tun hat das die tickrate von eigenene rechner hoch ist so gibt es eine tolle methode hochzudrehen

man modeliere ein aufwendiges projekt in 3d und rendert eine etwas längere animations sequenz oO
man erhällt beispielsweise folgendes endprofukt
http://www.zero-graphix.net/Harogath/test3.mov

und es Dropen 7 guls in folge bei 7 Necros beim Rune quest auf hell

nunja paar tage drauf beim nächsten rq rush war der spaß dann auch schon zuende ..

 

[Phosgen]

wenn ich alle gleichungen die ein system determinieren kenne kann ich 100ig genaue vorhersagen treffen.

Da ist ein gewisser Herr Heisenberg (und viele andere) aber anderer Meinung (OK, ist in diesem Fall wahrscheinlich nicht so ganz relevant, aber sei's drum )

Wenn ich nicht alle faktoren kenne muss ich versuchen relevante heraus zu finden. Dies ist unser/mein plan.

Was du aber, wie ich beschrieben habe, nicht kannst, weil du nicht mal die bekannten Faktoren genau genug messen oder festlegen kannst. Du kannst, selbst wenn du einen vermeintlichen Zusammenhang glaubst gefunden zu haben, diesen nicht beweisen, da du deine Ergebnisse nicht reproduzieren kannst.

ja, ich kann net genau auf die millisec nen kill durchführn. aber wenn ich weiß dass um punkt so und so ein item meiner wahl dropt, dann kann ich wenigstens versuchen annähernd zu diesem zeitpunkt nen kill hin zu legen. Somit würd mir diese erkenntnis weiter helfen.

1.: Es gibt keinen Zeitpunkt, zu dem etwas bestimmtes droppt. Was zu einem bestimmten Zeitpunkt droppt variiert von Computer zu Computer je nach Tickcount.
2.: Verpaßt du den gewünschten Zeitpunkt auch nur um eine Millisekunde, wird höchstwahrscheinlich etwas vollkommen anderes generiert. Wäre dem nicht so, würden z.B. im Cow, wenn du da mit ner Java durchfegst, ständig gleiche Items auf einem Haufen liegen. Dem ist aber nicht so.

Im übrigen wärs auch eine neue erkenntnis wenn man behaupten könnte: Nein! Es gibt keine über zeit zum mfen.

Nö, wäre nicht neu.


Wenn du wirklich herausbekommen willst, ob es weitere Faktoren gibt, wirst du nicht darum herumkommen, richtig an's Eingemachte heranzugehen, d.h. Debugger, Deassembler oder was es da sonst so gibt. So wurden viele relevante Formeln und Mechanismen im Spiel herausgefunden und gerade bei etwas so technischem, was im (gemoddeten) Spiel eben nicht direkt getestet werden kann (im Gegensatz z.B. zur Reihenfolge von Schadensberechnung etc.) sehe ich da keinen anderen Weg.

 

[Dr.Dre]

Schau, in der großen weiten welt gibts soviele zusammenhänge die wir nur vermuten können. Da kann man net debuggen und schaffts dennoch mit hilfe der statistic recht genaue vorhersagen zu treffen (man denke hierbei an wetbüros. die typen machen gewinn obwohl sie sicher net alle einflussfaktoren kennen...).

Vielleicht generiert ja der Tick-counter nur den randomwert für die itemart die fällt und die zeit is für die qualität wichtig? wer weiß das schon.
Vielleicht spielen aber auch die, seit dem pcstart gedrückten tasten und gefahrenen maus-killometer eine rolle (Diese werte sind jetzt keine schnapsidee sondern werden wirklich von einigen Zufallsgeneratorn verwendet). Tatsache ist dennoch, dass es in der it-welt keinen wirklichen zufall gibt.

Meiner Meinung nach ist das Problem auf jeden fall untersuchungswürdig. Weil ich jedoch, wie du schon sagst net alle Faktoren kenne bzw bestimmen kann muss ich mit der statistic ans werk gehn.

 

[Phosgen]

Schau, in der großen weiten welt gibts soviele zusammenhänge die wir nur vermuten können. Da kann man net debuggen und schaffts dennoch mit hilfe der statistic recht genaue vorhersagen zu treffen (man denke hierbei an wetbüros. die typen machen gewinn obwohl sie sicher net alle einflussfaktoren kennen...).

Wettbüros machen Gewinn durch Mischkalkulationen, d.h. sie gestalten die Quoten so, daß die Einnahmen aus verlorenen Wetten der Kunden höher sind als die Ausgaben durch gewonnene Wetten der Kunden. Sie wissen also grob, welche Mannschaften (mal auf Sportwetten bezogen) stärker sind, wo sie ihre Schwächen haben usw. Sie kennen also allgemeine Trends und wissen, wie sie ihre Quoten gestalten müssen um über längere Zeit gesehen Gewinn zu machen. Was ein Wettbüro aber nie kann, ist genau voraussagen, wie etwas ausgeht.
Verglichen mit D2 würde dies wie folgt aussehen: Der Spieler (=Wettbüro) weiß, welche Monster was am besten droppen können und kann den Aufwand und die durchschnittlichen Dropqualitäten gegeneinander abwägen. Was er nicht kann, ist für jeden Drop voraussagen, was fällt (=für jedes Spiel das Ergebnis voraussagen).
Statistik schreibt sich übrigens auf Deutsch mit K, nur so am Rande.

Vielleicht generiert ja der Tick-counter nur den randomwert für die itemart die fällt und die zeit is für die qualität wichtig? wer weiß das schon.
Vielleicht spielen aber auch die, seit dem pcstart gedrückten tasten und gefahrenen maus-killometer eine rolle (Diese werte sind jetzt keine schnapsidee sondern werden wirklich von einigen Zufallsgeneratorn verwendet). Tatsache ist dennoch, dass es in der it-welt keinen wirklichen zufall gibt.

Warum sollte Blizzard zwei (oder noch mehr) verschiedene weniger gute Randomfunktionen schreiben anstelle einer besseren? Hochgradig unlogisch. Es reicht eine Zufallsfunktion, die recht gute Zufallswerte liefert.

Meiner Meinung nach ist das Problem auf jeden fall untersuchungswürdig. Weil ich jedoch, wie du schon sagst net alle Faktoren kenne bzw bestimmen kann muss ich mit der statistic ans werk gehn.

Und wie konkret stellst du dir die Auswertung vor? Wie willst du jemals zeigen können, daß die Zufallszahlen von etwas bestimmten abhängen? Wie willst du ausschließen, daß ein beobachtbarer Effekt nicht ausschließlich durch Systemzeit und Tickcount bestimmt wird? Was willst du denn da statistisch auswerten, wo du die Inputwerte (=Systemzeit + Tickcount) nicht konkret kennst und nicht weißt, wie diese verarbeitet werden und wie aus diesen Quellwerten dann die Itemeigenschaften generiert werden? Mach das doch mal bitte am konkreten Beispiel fest. Statistik schön und gut, aber das System läßt viel zu viele Möglichkeiten und Ergebnisse zu, als daß du das jemals vernünftig auswerten kannst mit den von dir vorgegebenen Methoden.

 

[Dr.Dre]

mir is der tick-counter egal. aber sowas von mega egal.

Ich schau nur nach der zeit. steht übrigens im startpost.
Mir sind auch die generierten zufallszahlen egal. Ich will net wissen welche zufallszahl zu welchem item führt. Ich will nur sehn obs ne zeit gibt in der gewisse drops häufiger fallen. Dies werte ich aus indem ich, wie bereits gesagt, mittelwerte miteinander vergleiche. Wenn also durchschnittlich 10pgems bei meppel fallen und jemand 150 findet, kuck ich ob das mit dem zufall vereinbar ist oder obs eher unwahrscheinlich ist.

Um nochmal aufs wettbüro zurück zu kommen: Ich will keineswegs genaue vorraussagen treffen aufgrund dieses tests. Ich will auch nur trends herausfinden.


Ums nochmals auf den punkt zu bringen: Mich interessiert nicht wie die drops funktionieren. Ich will keine technischen feinheiten herausfiltern. Ich will lediglich wissen obs bessere mf zeiten gibt.

 

[fallenphoenix]

Fragwürdig bleibt trotzdem der Sinn dahinter...

Denn selbst, wenn der Dropgenerator nicht vom Tick abhängig wäre, sondern nur von der Systemzeit initialisiert würde, würde dich das nicht in die Lage versetzen ohne Clockfreeze irgendwelche objektiven Tendenzen im Drop nachzuweisen.

Angenommen es gibt diese ominöse Superdropzeit und du findest sie, z.B. am 29.09. um 23:59 droppen nur Uniques... Dann probierst du es am nächsten Tag um 23:59 und hast ein komplett anderes Ergebnis, denn 29.09. 23:59 =/= 30.09. 23:59.
Ma ganz abgesehen davon, dass die Systemzeit nicht im Minutentakt abgerechnet wird , geschweige denn in halben Stunden.

Ohne extremes Modding um die Eingangsgrößen für den Zufallsgenerator zu verändern wirst du da nichts rausbekommen.

Da kannst du genausogut versuchen herauszufinden, wie sich Ping-Pong-Spielen auf das Wetter in Honululu auswirkt... im Sommer wird's warm und nachts ist es dunkler als draußen.

 

[SiC42]

Ma ganz abgesehen davon, dass die Systemzeit nicht im Minutentakt abgerechnet wird , geschweige denn in halben Stunden.

Also das wäre wirklich nicht das Problem, dass diese vielleicht in Millisekunden abgerechnet wird.
Man will mit dem Projekt ja sowieso nur eine Tendenz ausrechnen, also z.B. dass es in demUndDem Zeitraum die meisten guten Dropgenerierungen gibt, jetzt mal davon abgesehen, dass die "Ticks" des Servers usw, eine Rolle spielen

 

[fallenphoenix]

Naja, man muss aber schon ganz schön blauäugig sein, um da etwas aufzeigen zu wollen....
Vielleicht ist auch einfach nicht klar, wie sich der Drop/Levelgenerator in D2 von dem in D1 unterscheidet....

In D1 war die einzige relevante Größe die Systemzeit des Servers. Wenn man da mittels Clockfreeze die Systemzeit festsetzte, dann hat man auf 2 separaten Rechnern mit derselben Systemzeit die Möglichkeit gehabt, in D1 ein identisches Level zu generieren, in dem von jedem Monster auch identische Items droppten.
Diese Items hatten auch dieselbe Item-ID und haben z.B. Dupe-Warnungen hervorgerufen.

In D2 ist die Systemzeit höchstens zur Initialisierung der Zufallsgenerators relevant. Der Zufallsgenerator wird trotzdem dafür sorgen, das zufällige Level entstehen, die auch auf Rechnern mit identischer Systemzeit nicht identisch sind.
Das einzige was passieren wird, ist dass sich die generierten Level irgendwann abhängig von der Anzahl der übrigen Eingangsgrößen wiederholen könnten.
Je nachdem wie gut der Generator ist wird das aber erst nach einigen hundert, tausend oder sogar nie passieren.

Das ales wohlgemerkt unter der Vorraussetzung, dass die Eingangsgrößen ALLE festgesetzt sind. Was natürlich unter normalen Bedingungen nie der Fall sein wird. Geschweige denn, dass überhaupt alle Eingangsgrößen bekannt sind.

Und der Drop ist davon sogar noch unabhängig!

Also bißchen nettes Mfen, ok... aber irgendwelche Ergebnisse wird es da nicht geben...

 

[Order of Chaos]

zieht euch einfach die algorithmen des spiels raus >_>

(tja, wie ihr das macht: euer bier^^)


Tip: PK

 

[Spalty]

Also ich halte es für schier unmöglich irgendwelche mysteriöse Faktoren ausfindig zu machen - denn wer weiß schon welche Faktoren wirken?
Vielleicht ist der drop von 12.00 - 12.29 nicht für eine sorc besser sondern nur fürn pala. aber für den Pala nur, wenn er zuvor mit Alkor spricht und dann nen Heiltrank bei Jamella kauft.
Vielleicht ist der Drop zu einer bestimmten Zeit auch nur dann besser, wenn das Datum des Tages gerade oder ungerade ist....... etc etc

Da man nich weiß welche und wie viele Faktoren es gibt (und die Vermutungen sind ja schon ziemlich umfassend)
wird es einfach nicht möglich sein diese (so denn es sie denn gibt) zu finden.

 

[Evilshady]

Zu diesen Faktoren möcht ich auch nochma was sagen:
Kann es sein, dass die doch nich so kompliziert sind wie man denkt?


Ich habe innerhalb von 2 Tagen 3 mal Ormus, 2 Arach und 2 Stormis gefunden, und es ist nicht so, dass ich die 2 Tage durchgespielt habe, höchstens so 6 stunden pro Tag (und auch nich die ganze Zeit MF-Runs). Hab das im Chat mal kundgetan, da meinte auch einer "Joa schon 5 Sojs in 2 Tagen gefunden", bei nem anderen wars ein Shako... bzw mehrere. Dieser D-Fens hier hat ja auch seinen geilen Shako-Counter von 28.
Einer meinte mal, man braucht 200 MF und mind. Lvl 90, dann droppen Shakos in A5 Hölle wie nix.

Vom Herold z.B. hingegen hab ich noch nie das Basisitem in IRGENDEINER form droppen sehen, noch nie

Ich fühl mich beschissen... (also im Sinne von abgezogen)

 

[Ma-lana]

Der Thread-Ersteller hat dazu aufgefordert, sich PRO seiner Überlegungen zu äussern.
Es ist nicht nur unnötig sich mit anderen meinungen hier einzuklinken und mit anderen Meinungen dagegen zu wettern, sondern auch im größten Maße störend.

Ich persönlich halte weitere MF-beeinflussende Faktoren für möglich, einfach aufgrund temporär sehr auffallendem Dropp-Verhalten, den ich nicht immer mit der Erklärung "Zufall" abtun kann.

Aber ich empfinde die hier vorgeschlagene Methode dem auf die Spur zu kommen für nicht erfolgversprechend. Trotzdem geb ich hier nicht meinen Senf dazu, und versuche den Threadersteller unbedingt von meiner Meinung zu überzeugen.

Lasst die Leute die das ausprobieren wollen doch einfach in Ruhe. Eure negativen Anmerkungen zerstören letztlich nur solche Diskussionen/Threads. Schaut einfach ob was am Ende dabei heraus kommt und gut ist.

Im übrigen. auf Seite 2 meinte jmdn man könne dem nur per debuggen/Disassemblieren auf die Spur kommen.
Solche eine Aussage ist definitiv falsch.

Es gibt Programmier-Methoden, die durchs debuggen nicht unbedingt immer erkennbar werden.
Beispiel dafür:
Wird im Programmcode an einer Stelle auf die MF-Kurve, Basis-MF-Werte per Modifikation zugriff genommen, NUR wenn ein bestimmter Zustand eintritt, dann bleibt die Abarbeitung sämtlicher einzelner Schritte um den Dropp zu generieren unberücksichtigt.
D.h. per debuggen müßte man per Zufall in genau dem zeitl. Zeitraum debuggen in dem dieser Umstand eintritt.
Dieser bestimmte Zustand, der es z.b. auslöst, das es eine glücksserie gibt, könnte ein bestimmtes Ergebnis einer Rechnerei mit versch. Faktoren sein.
Wenn z.B. der Mittelwert einer zeitangabe/Kalenderwoche geteilt durch eine Klassen-Nummierung, addiert mit einer Regions-/Boss-Nummer einen zahlenwert von XX ergibt, wird z.b. der MF-Wert, mit dem in Items gerechnet wird, einfach um 300 angehoben oder was auch immer.
Ist halt nur ein beispiel und nur wenn aus dieser Rechnerei etwas bestimmtes rauskommt, könnte eine Procedure die sonst nie im programm abgearbeitet wird, das Ergebnis des Dropps verändern.
In solch einem Fall müßte einer der debuggt extrem viel glück haben,um sowas überhaupt bei programmabarbeitung zu bemerken.
Und Disassemblieren ist nicht so einfach, zumindest nicht, wenn man aus dem Disassemblierten Code wieder lesbaren und zu verstehenden Quell-Code erzeugen möchte.
Bei der Komplexität von D2 würde ich schätzen das einer allein da wahrscheinlich mind. wochenlange Zeit im Stück dran setzen muß und selbst das garantiert es nicht, sämtliche Geheimnisse aufzudecken.

Sogar die programmierer bei Blizzard haben Probleme sich durch ihren selbst erstellten Code (der sicherlich zudem auch noch mit Hilfstexten dokumentiert) durchzuwühlen. Wär das alles so einfach, gäbs nicht so viele Bugs im Programm.

 

[Firnblut]

In D1 war die einzige relevante Größe die Systemzeit des Servers.

Wenn mich meine Erinnerung nicht arg täuscht, dann stimmt das so nicht ganz.
Da gibt es diesen Typen im Dungeon, der einem ein Item gibt. xxx the mad oder so.
Wenn du ein SP game erstellst und dann genau vor ihm speicherst, wirst du merken, dass du über Mausklicks die Itemgeneration beeinflussen kannst.
In D1 scheint sich Blizzard also auch auf verschiedene "Zufalls"-Generatoren verlassen zu haben. Das schließt doch die Möglichkeit ein, dass sie das in D2 auch gemacht haben.

 

[Evilshady]

Ich persönlich würds mehr als unfair finden, wenn der "Spielstil" (inkl. clvl und mf) eine markante Auswirkung drauf hätten. Und was man so hört, scheint das arrrg der Fall zu sein.

 

[Phosgen]

Der Thread-Ersteller hat dazu aufgefordert, sich PRO seiner Überlegungen zu äussern.
Es ist nicht nur unnötig sich mit anderen meinungen hier einzuklinken und mit anderen Meinungen dagegen zu wettern, sondern auch im größten Maße störend.

Was der Threadersteller will ist aber mehr oder weniger die Quadratur des Kreises, d.h. eine vollkommen unmögliche Sache. Der Threadersteller unterschätzt das System einfach maßlos.

Im übrigen. auf Seite 2 meinte jmdn man könne dem nur per debuggen/Disassemblieren auf die Spur kommen.
Solche eine Aussage ist definitiv falsch.
[..]
Und Disassemblieren ist nicht so einfach, zumindest nicht, wenn man aus dem Disassemblierten Code wieder lesbaren und zu verstehenden Quell-Code erzeugen möchte.
Bei der Komplexität von D2 würde ich schätzen das einer allein da wahrscheinlich mind. wochenlange Zeit im Stück dran setzen muß und selbst das garantiert es nicht, sämtliche Geheimnisse aufzudecken.

Wenn nicht mit Debuggen/Deassemblieren/Ähnlichem, womit dann?

Um mal was konkretes zu liefern:

Liste mit bekannten Funktionen aus den dlls

Infos, wie Itemgenerierung technisch im Detail funktioniert (insbesondere Post 2+3)

Soweit ich das verstehe (man korrigiere mich, wenn ich falsch liege), sieht es genau so aus, wie ich es in meinen letzten Posts bereits beschrieben habe: Es ist praktisch unmöglich einen Drop identisch zu reproduzieren und bereits eine kleine Veränderung der Ausgangssituation ändert das Ergebnis i.d.R. drastisch. Damit dürfte es praktisch unmöglich sein mit den vom Threadersteller vorgeschlagenen Tests statistisch signifikante Ergebnisse, welchen reale Zusammenhänge zugrunde liegen, zu erhalten.
Wenn es also wirklich jemanden interessiert, welche Faktoren einen Einfluß haben, dann sollte er/sie sich einfach an eine der Fachkräfte (Jarulf etc.) in den von mir verlinkten Foren wenden, das dürfte die schnellste Methode sein das herauszufinden.