Manastone/Enchantment Stone Socket speed (Private Server)

[x-AcT]

Dass die Resourcen mit der Castdauer zusammehängen sagt ja auch niemand.. oh man..
Was sog. Prozesse sind, solltest du dir vielleicht doch nochmal zu gemüte führen. Denn ein Enchant eines Spielers ist sicher kein Prozess.. nichtmal ein Thread. Es ist lediglich nen Runnable, das eh zu 99% schläft und abgesehn vom Scheduler gar keine Resourcen frisst. Und weshalb neuerdings das Initialsieren ansich so viel Aufwand ist, solltest du mir vielleicht auch mal erklären.

Ach Dallas, du bist mir einfach der Liebste xD

[dallas_extreme]

Originally Posted by x-AcT

Ach Dallas, du bist mir einfach der Liebste xD

Das glaube ich dir

Übrigens, ein Enchant ist ein Prozess der berechnet der SuccessRate ob er gesockelt wird oder failt.
Und wenn das kein Prozess ist....

[InPanic Kev]

Originally Posted by dallas_extreme

Übrigens, ein Enchant ist ein Prozess der berechnet der SuccessRate ob er gesockelt wird oder failt.
Und wenn das kein Prozess ist....

you made my day


nrg hat schon recht mit dem was er sagt
Ich denk ich weiß das du meinst uns sagen zu wollen Dallas aber prozess ist nicht das richtige wort

[dallas_extreme]

Kev, lass mal lieber, damit kennst du dich wirklich nicht aus.
Das Enchanting ist ein Serverseitiges Prozess, kein Clientseitiges wie du mit deiner Fake Bild zeigen willst.
Sobald der Server ein Vorgang berechnen muss, IST ein Interne Prozess.
Diese berechnungsvorgang wird mit jeder Versuch neu initialisiert.
Naja, egal...mach wie ihr wollt, tausende von Spieler hat sowieso keiner.
Aber, wenn ihr von Materie so viel versteht, wundert euch nicht das eure Server lagt.

[x-AcT]

Dallas, setz dich mal mit ThreadPools auseinander und dann denk nochmal drüber nach, ob du das wirklich so meinst, wie du es sagst

[dallas_extreme]

Originally Posted by x-AcT

Dallas, setz dich mal mit ThreadPools auseinander und dann denk nochmal drüber nach, ob du das wirklich so meinst, wie du es sagst

Genau das meine ich. Desto wird diese Enchanting Delay verkürzt, gibt den Spieler die Möglichkeit das der Java Application Ressurces management mehr belastet wird. Wie ich sagte, jeder Enchanting führt eine Random Berechnung aus. Das kann man nicht zwischenspeichern, (Cachen/Queken) weil bei jeder Vorgang muss neu berechnet werden.

 Spoiler

Why thread pools?

Many server applications, such as Web servers, database servers, file servers, or mail servers, are oriented around processing a large number of short tasks that arrive from some remote source. A request arrives at the server in some manner, which might be through a network protocol (such as HTTP, FTP, or POP), through a JMS queue, or perhaps by polling a database. Regardless of how the request arrives, it is often the case in server applications that the processing of each individual task is short-lived and the number of requests is large.

One simplistic model for building a server application would be to create a new thread each time a request arrives and service the request in the new thread. This approach actually works fine for prototyping, but has significant disadvantages that would become apparent if you tried to deploy a server application that worked this way. One of the disadvantages of the thread-per-request approach is that the overhead of creating a new thread for each request is significant; a server that created a new thread for each request would spend more time and consume more system resources creating and destroying threads than it would processing actual user requests.

In addition to the overhead of creating and destroying threads, active threads consume system resources. Creating too many threads in one JVM can cause the system to run out of memory or thrash due to excessive memory consumption. To prevent resource thrashing, server applications need some means of limiting how many requests are being processed at any given time.

So jetzt kommt was du meinst:

A thread pool offers a solution to both the problem of thread life-cycle overhead and the problem of resource thrashing. By reusing threads for multiple tasks, the thread-creation overhead is spread over many tasks. As a bonus, because the thread already exists when a request arrives, the delay introduced by thread creation is eliminated. Thus, the request can be serviced immediately, rendering the application more responsive. Furthermore, by properly tuning the number of threads in the thread pool, you can prevent resource thrashing by forcing any requests in excess of a certain threshold to wait until a thread is available to process it.

Aber wie ich sagte, ein RANDOM Berechnung ist nie gleich, also cann man nicht in einem Thread Pool stecken. Vogänge die in einem ThredPool stecken kann müssten fixe Werten haben, bzw. eine immer das gleiche Berechnung der sich wiederholt. Ein Random tut es aber nicht.

Eine andere Frage ist, inwieweit ist der Core optimiert um die folgende "tunning" zu gewähleisten?

by properly tuning the number of threads in the thread pool, you can prevent resource thrashing

Siehe noch Work queues

[x-AcT]

Oh gott dallas.. du hast echt keine Ahnung oder?

Da du deine tollen Zitate scheinbar in keinster Weise verstehst ein ganz kurzer Crashkurs:

Ein "Thread" ist ein Abarbeitungsstrang innerhalb eines Prozesses. Das bedeutet, dass innerhalb eine sog. "Prozesses" eine Vielzahl unterschiedlicher Threads laufen.
Diese Threads werden auf Multicore Prozessoren tatsächlich parallel abgearbeitet. Das bedeutet aber nicht, dass man auf einem Quadcore nur 4 Threads parallel laufen lassen kann. Auf einzelnen Cores werden auch mehrere Threads schein-parallel abgearbeitet. Das wird erreicht indem man die Prozessorzeit immer unterbricht und an einen anderen Thread weitergibt, während die restlichen Threads schlafen gelegt werden, bis man die aktuelle ausführung wieder unterbricht und einen anderen Thread weckt. Da das ganze mehrfach in einer Millisekunde passiert, werden die Threads scheinbar parallel abgearbeitet.

Was du da zitierst:

A thread pool offers a solution to both the problem of thread life-cycle overhead and the problem of resource thrashing. By reusing threads for multiple tasks, the thread-creation overhead is spread over many tasks. As a bonus, because the thread already exists when a request arrives, the delay introduced by thread creation is eliminated. Thus, the request can be serviced immediately, rendering the application more responsive. Furthermore, by properly tuning the number of threads in the thread pool, you can prevent resource thrashing by forcing any requests in excess of a certain threshold to wait until a thread is available to process it.

hat nichts aber auch gar nichts damit zutun, dass die "Vorgänge die in einem ThredPool stecken fixe Werte haben müssen" ... das ist der wohl größte Dünnpfiff, den ich je gehört habe.

Bei ThreadPools geht es darum, dass dieser Mechanismus für das parallele Abarbeiten von Runnables oder auch Futures zu einem Performance - "overhead" führt. Damit man diesen "overhead" etwas umgeht, recycled man einfach alte Threads, und "schmeißt" neue Runnables oder Futures in den "Pool", damit sie von den alten Threads, die es noch gibt übernommen werden.
Der overhead zum initialisieren und schedulen neuer Threads wird damit ein stück weit auf viele Tasks aufgeteilt.

In den Emulatoren werden dazu beim Startup eine Konfigurierte Anzahl Threads "hochgefahren", wobei die Anzahl sich nicht nur an der Config orientiert, sondern auch an der verbauten Anzahl Cores...

Und dallas, tu uns einfach allen mal einen Gefallen und mach nicht immer einen auf dicke Hose, denn es mag ja sein, dass die Leute, die keine Ahnung haben, dir das in irgendeiner Weise abkaufen, aber jeder der auch nur etwas vom Java Programming versteht, macht sich über deine Aussagen lustig.

[dallas_extreme]

Wir reden von einender vorbei und du merkst nicht mal.
Und wie üblich, als Letzes, wenn man keine Argumentation hat, holt die Käule raus.
Du redest von nichts.
Lediglich geht es darum ob man das System mit kurzere delays belasten sollte oder nicht.
Wie ich sagte, es ist nicht gleich ob 1.000 Spieler drei Sekunden warten müssen bis eine Berechnung anstoßen oder oder jede eine Sekunde damit spammen können. Egal wo und wie diese Prozess abläuft der System wird mehr belastet. Ganz simpel und logisch.
Und wenn du mit so ein Mentalität JA geführt hast, ich wundere mich nicht das JA immer ein Lag Problem hatte.

Thema damit beendet, zumindest meinerseits, den das ist wieder ein unsinnige Thema mit dir, was ist besser Linux oder Windows Server für Java Applicationen.

[x-AcT]

So kennt man dich Dallas. Du verlierst die Diskussion und damit ist das Thema beendet

Naja. Um das mal aufzugreifen: Wenn du mit der Mentalität AE führst, weiß ich warum das nichts wird

[madmax188]

man leutz ist das bei euch Hass Liebe ????????

[thilo12]

Leute anstaat hier rum zu diskutiert ob das nen prozess oder nen Thread ist kann mir jetzt jemand sagen wo ich genau was verändern muss damit ich zb in 1sek nen kack mana/verzauberungs stein in meine rüstung knallen kann? xD Ich hab nen projekt vor und würde das nähmlich gerne wissen also bitte ^^

Alle leute die jetzt denken boar der weiß das nichtmal, wie will der'n projekt starten?Die sollen hier bitte NICHT antworten!

Wenn ich mal bei item_templates.xml gucke bekomme ich das hier!
Jetzt wer ne ahnung was ich da ändern muss?^^

<item_template id="166000190" name="L190 Enchantment Stone" level="190" mask="12414" category="ENCHANTMENT" max_stack_count="100" item_type="NORMAL" quality="COMMON" price="950" race="PC_ALL" option_slot_bonus="0" restrict="1,1,1,1,1,1,1,1,1,1,1,1" desc="1493017" attack_gap="0.0" slot="0" activate_count="1">
        <actions>
            <enchant/>
        </actions>
        <weapon_stats/>
    </item_template>

[dallas_extreme]

Ich dachte kommt ein schnelle Lösung von ein grosse Java coder, aber fehl Anzeige.Wie üblich, er gibt nie Tips oder eine Konkrete Lösung.

Also, ich mach jetzt eine "Dicke Hose" und gebe euch die Lösung für Enchanting 1 Sekunde;

Index: /src/com/aionemu/gameserver/model/templates/item/actions/EnchantItemAction.java
===================================================================
--- /src/com/aionemu/gameserver/model/templates/item/actions/EnchantItemAction.java	(revision 00)
+++ /src/com/aionemu/gameserver/model/templates/item/actions/EnchantItemAction.java	(working copy)
@@ -93,7 +93,7 @@
 		final boolean isSuccess = isSuccess(player, parentItem, targetItem, supplementItem, targetWeapon, currentEnchant);
 		player.getController().cancelUseItem();
 
-		PacketSendUtility.broadcastPacketAndReceive(player, new SM_ITEM_USAGE_ANIMATION(player.getObjectId(), parentItem.getObjectId(), parentItem.getItemTemplate().getTemplateId(), 5000, 0, 0));
+		PacketSendUtility.broadcastPacketAndReceive(player, new SM_ITEM_USAGE_ANIMATION(player.getObjectId(), parentItem.getObjectId(), parentItem.getItemTemplate().getTemplateId(), 500, 0, 0));
 		player.getController().addTask(TaskId.ITEM_USE, ThreadPoolManager.getInstance().schedule(new Runnable() {
 
 			@Override

das heist, suche nach "SM_ITEM_USAGE_ANIMATION" und ändere die Werte (5000,3000) auch bei;
src\com\aionemu\gameserver\model\templates\item\ac tions\ExtractAction.java
src\com\aionemu\gameserver\model\templates\item\ac tions\RideAction.java
\src\com\aionemu\gameserver\model\gameobjects\play er\Equipment.java

Viel Spamm.....ahhh, Spass damit

[Bathori]

// check use item multicast delay exploit cast (spam)

Also diese Java Dev. warrn schon von einen delay cast exploit wegen eventuelle zu viele spamms. Da wundere mich das nrg andere Meinung ist.
Den Spamm war schon immer eine unagenehme Sache.
Von 5000 auf 500 ist der 10 fache, zusammen mit die andere Möglichkeiten addiert sich Masslos diese Spamm. Ich frage mich wozu soll das gut sein. In jeder MMO sind solche Castbalken bei Crafting oder plusen, in manche Spiele sogar viel länger als 3 sekunden. Ich denke nicht das hier es sich um einen Schönheitseffekt oder Timesink handelt.

[x-AcT]

Das ist durchaus nen Spielinhalt. Denn das "bauen" und "craften" von Materialien soll eben wie in der Realität Bestandteil der Kämpfe sein. Es soll die Vorbereitung auf die Kämpfe darstellen.
Technisch gesehen ist es überhaupt kein Problem, auch wenn es instant wäre.

Dieses Kommentare gibt es, weil man früher diese vorgesehene Spielmechanik durch gezielt veränderte Packets umgehen konnte

[wolfgang26]

xD