Manastone/Enchantment Stone Socket speed (Private Server)

[thilo12]

Anyone know where in the .config or .xml data i find the socket speed for manastones or echantment stones? Standart = 3 seconds

[dallas_extreme]

socket speed for manastones or echantment stones?

What's that?

[paulepaulepaule]

Simple answer read the code guess your emu have somekind of echantingservice, there you go, just check there if there are item use animations with delays, if they arent editable with a propertie then set one ;D

[dallas_extreme]

Manastone give you some atributes such +95 TP or +17 Crit, there is no casting animation or something

Enchanting give your gear an enchanting from 0 to 15 levels, there is no casting animation or something.

So what do you mean with 3 seconds?

[Shidoh.]

Dallas, wenn du VZ's oder Manastones in oder auf deine Waffe, Rüssi sockelst, gibt es eine Zeit (er beschreibt es als CastZeit, wir nennen es mal Socket Time). Seine Frage war ob man diese Zeit auf 0 setzen kann, damit man keine 300 Jahre für 10 Steine braucht.

Siehe YT:

[paulepaulepaule]

The item use animation (the bar).

[dallas_extreme]

Originally Posted by Shidoh.

Dallas, wenn du VZ's oder Manastones in oder auf deine Waffe, Rüssi sockelst, gibt es eine Zeit (er beschreibt es als CastZeit, wir nennen es mal Socket Time). Seine Frage war ob man diese Zeit auf 0 setzen kann, damit man keine 300 Jahre für 10 Steine braucht.

Siehe YT:

Das heisst Enchanting cast delay....und JA das kann man verkürzen wie das Ether casting, fällt mir nur auf Anhieb nicht in welche File.

[madmax188]

Originally Posted by dallas_extreme

Das heisst Enchanting cast delay....und JA das kann man verkürzen wie das Ether casting, fällt mir nur auf Anhieb nicht in welche File.

So viel ich mich erinnere ist es in der Item.Template

[Shidoh.]

Originally Posted by dallas_extreme

Das heisst Enchanting cast delay....und JA das kann man verkürzen wie das Ether casting, fällt mir nur auf Anhieb nicht in welche File.

Jop, ich weiß . Wollte dir nur verdeutlichen was er meinte.

[dallas_extreme]

Man kann diese Zeit nicht auf 0 reduzieren den, der Rechner braucht eine bestimmte Zeit die Kritchance zu berechnen. Und das mutipliziere auf ein paar hundert Spieler. Da ist nicht viel zu verbessern.

[paulepaulepaule]

Das enttäuscht mich aber das du ne CPU unterschätzt die solche berechnungen in nanosekunden ausführt, zweiter Denkfehler ist auch noch das der Server garantiert nicht hunderte ItemActions dieser Art zur gleichen Zeit handeln muss, selbst wenn who cares das ist so wenig Rechenaufwand.

@ TO depends on your EMU it could be in the ItemActions for this (for example EnchantItemAction), ItemService or EnchantingService. but easiest would be to follow up what the ItemActions are doing and calling. As i said look for ITEM_USE Action or smth smilliar that is added as a Task

[dallas_extreme]

@paulepaulepaule

Du darfst aber nicht vergessen das der CPU nicht nur einen Prozess und zwar nur deine ausführt. Und wenn du die ganze Prozesse summierst wirdst du schnell merken das du dich in einem Bereich bewegst wo deine Kenntnisse sehr bescheiden sind.

Diese delays sind nicht umsonst eingebaut und sind nicht für ein Offline Spiel programmiert sondern für ein MMO, wo tausende von Spieler bedient werden sollen.

Zauberwort:

# ----------------------------
# Thread config's:
# ----------------------------
# NOTE: If you don't know what this setting does, please don't change it!

# Default: 2
gameserver.thread.basepoolsize = 2

# Default: 4
gameserver.thread.threadpercore = 4

# That's only a warning.
# Default: 5000
gameserver.thread.runtime = 5000

[paulepaulepaule]

Originally Posted by dallas_extreme

@paulepaulepaule

Du darfst aber nicht vergessen das der CPU nicht nur einen Prozess und zwar nur deine ausführt. Und wenn du die ganze Prozesse summierst wirdst du schnell merken das du dich in einem Bereich bewegst wo deine Kenntnisse sehr bescheiden sind.

Diese delays sind nicht umsonst eingebaut und sind nicht für ein Offline Spiel programmiert sondern für ein MMO, wo tausende von Spieler bedient werden sollen.

Zauberwort:

# ----------------------------
# Thread config's:
# ----------------------------
# NOTE: If you don't know what this setting does, please don't change it!

# Default: 2
gameserver.thread.basepoolsize = 2

# Default: 4
gameserver.thread.threadpercore = 4

# That's only a warning.
# Default: 5000
gameserver.thread.runtime = 5000

Okay du willst mir jetzt also weißmachen das du selber glaubst was du schreibst das eine CPU überfordert ist nen simplen Randomseed zu generieren mit nen tail.min und tail.max und daraus ne Zahl zu picken und diese mit simplen if else zu vergleichen, bitte ich glaube ehrlich nicht das du das wirklich glaubst. Mir mangelndes Wissen im Angesicht des Fehlens solch trivialer Kentnisse vorzuwerfen ist unpassend, ich glaub du bist dir nicht mal im klaren was du mir da verlinkt hast mit "Zauberwort". Ich mein bitte du hast wirklich viel Erfahrung ich denke also das du bissl was aufm Kasten hast, auch du solltest doch wissen das die ITEM_USE impl. dort garnichts schwieriges macht, es schickt einfach das item use packet, dann addet es thread in den queue und dieser wird dann nach x sekunden ausgeführt wo ist da (für dich) ersichtlich das man dies zur Sicherung der Leistung macht, es ist sogar aufweniger erst nen Thread abwarten zu lassen der code nach x sekunden ausführt als einfach den besagten code sofort auszuführen.

NCSoft benutzt diese Delays einfach nur als einfaches Mittel den Enchanting Prozess langwierer zu machen, ist ja spannender mit so einer Bar, sonst könnte man ja 100 Stones in paar Sekunden verbraten so braucht man halt viel länger.

Du kannst auch gerne mal das Code Snippet verlinken wo du denkst der braucht soviel Rechenleistung das es lange zum berechnen brauch.

[x-AcT]

Das Delay hat absolut nichts mit dem Einsparen von Rechenleistung zutun, sondern erzeugt sogar eine Zusatzlast...

[dallas_extreme]

Originally Posted by x-AcT

Das Delay hat absolut nichts mit dem Einsparen von Rechenleistung zutun, sondern erzeugt sogar eine Zusatzlast...

Was eigentlich mit Absicht so gemacht worden ist.

	// check use item multicast delay exploit cast (spam)
		if (player.isCasting()) {
			// PacketSendUtility.sendMessage(this.getOwner(),
			// "You must wait until cast time finished to use skill again.");
			player.getController().cancelCurrentSkill();
			// On retail the item is cancelling the current skill and then procs normally
			// return;
		}

Und noch ein bisschen Dokumentation. Den es geht hier nicht um desto länger ist der Dauer von der Castingtime, desto mehr Ressource verbraucht sondern genau das Gegenteil. Desto öfters ist der/ein neues Prozess initialisiert.

Zum Beispiel:

100 Spieler enchanten. In 60 sek. werden 60 *100 Prozesse initialisiert
100 Spieler enchanten. In 60 sek. werden 30 *100 Prozesse initialisiert

 Spoiler

The Cast Bar and Lag

The cast bar is a representation of how far along in the spell cast/channel the character is. The length of the cast bar is determined by the base cast time of the spell, flat cast time reductions and application of spell haste, (whether from talents, gear or buff/debuffs) in that order.

There are several copies of the cast bar maintained at any given time: one on the client machine which controls the caster, one on the World of Warcraft server and copies of the cast bar are distributed from the server to other clients' machines as they need.

Following is a brief nontechnical explanation of how the initiation of a cast is handled by World of Warcraft:
The client initiates an spell cast
The client locks out the majority of the actions on the character's action bars and sends a message to the server saying that a spell cast has been initiated.
The server receives the message and checks to see if another action is being performed. If not, it begins counting down the castbar; the server sends a message to the client that it has received notice of the action being taken. Otherwise, the server rejects the action
The client receives notice that the server has received its initiation of a spellcast and starts rendering the cast bar if the action has been accepted.
So, if one attempts to perform an action while casting, the client will pass that action on to the server, regardless of the casting state as registered by the client. Previously, the client could reject actions based on the state of its casting bar. This led to the filling up of macro slots with macros that altered the state of the client-side cast bar to account for latency. Currently, however, these are not necessary. However, it is important to activate your spells at the right time.

If one initiates one's casts late (that is, after the spell effect is rendered on the client) this has the same effect as adding approximately one's latency to the cast time of one's spells. This is due to the manner in which the rendered castbar lags the actual start of spell cast by one's latency. When the spell is shown to be going off on the client side, it has gone off server side earlier by the value of one's latency, so waiting for the spell effect animation will cause one to lose dps.

If one initiates an action too early, the action may be just about to complete server side, but the server will send a notice rejecting the action back to the client. This notice will take the same amount of time as one's latency to get back to the client. During this time, the action might have been completed server side but one will be unable to act until the client gets the message from the server to rescind the global cooldown and allow initiation of another action. The upshot of this is that mashing the button while you wait for the cast bar to fill up will, on average, add latency to your cast time.

Hence, it is important to initiate your next action at the right time while your client shows that you are casting. The proper method for casting would be to wait until the cast bar indicator reaches the point where the time left until completion of the cast is equal to your latency and then mash the button you use to activate your spell. A good castbar mod will tell you when that time is, which will reduce, if not eliminate, loss in dps/hps due to latency.