[Cast Speed] Guardate quanto velocemente castate ..

[Vash1986]

aiutaci a correggerlo

set #lpc 100
set #targcurs 0

loop:
onhotkey Z
  gosub cast
sleep 10
goto loop

sub cast
event macro 15 3
set %start #systime
while #targcurs = 0
  sleep 1
set %end #systime
set %delta %end - %start
set %time %delta
event sysmessage %time
set #targcurs 0
return

Questo fa la magia di primo circolo e per attivarlo bisogna premere il pulsante Z. Per le magie di altri circoli basta modificare il comando event macro mettendo per esempio 9 al posto di 3 (ogni numero corrisponde a una magia).

E' molto primitivo, l'ho buttato giù alla svelta giusto per aiutare l'autore a correggere il suo.

Io casto il primo circolo in 320-350ms circa, il secondo in 550-600.

Infatti il delay di runuo è 250, al quale bisogna aggiungere il mio ping che varia da 50 a 100 in game.
Per il secondo circolo, è 500, più il mio solito ping, e quindi questi valori sono esatti.

Quello che DJFlash non ha considerato è che ci sono dei ritardi in Easyuo legati all'utilizzo dei comandi event macro e target, e che il comando linespercycle non funziona da un pezzo. Se guarda il mio script capirà come aggirarli.

[DJ_Flash]

Allora .. il comando linesperciclye funziona perfettamente .. prefettamente identico a set #lpc .. poi il tuo script nn tiene conto di una cosa fondamentale .. non targetta O.o .. cioè lo so ankio dei ritardi di event macro e di target ma non è ke mi interessino piu di tanto .. lo script è fatto solo per fare un confronto .. cmq usando while #targcurs = 0 sleep 1 effetivamente si velocizza lo script di 20ms circa ma poco importa .. lo script nn è fatto per castare al massimo è fatto per un confronto .. cmq farò la v0.6 che dice effettivamente il tempo di cast con i tuoi accorgimenti ..

[Dobermann]

Questi sono i miei con lo script di vash, (anceh eprche il tuo non mi setta il taghet) fatto al volo senza riavviare con scritp easy uo accei, icq msn map ts explorer.

Ho FW e questi sono i minimi si rieptono spesso al massimo ho visto 0.80 in piu di punto massimo, poi qunado ho tempo faccio tutto senza aver aperto niente.

297
547
797
1032
1297
1547
1766
2000

[legolas93]

Dobby, penso che per il primo circolo tu sia quello che casta piu veloce a 297

[Vash1986]

Allora .. il comando linesperciclye funziona perfettamente .. prefettamente identico a set #lpc .. poi il tuo script nn tiene conto di una cosa fondamentale .. non targetta O.o .. cioè lo so ankio dei ritardi di event macro e di target ma non è ke mi interessino piu di tanto .. lo script è fatto solo per fare un confronto .. cmq usando while #targcurs = 0 sleep 1 effetivamente si velocizza lo script di 20ms circa ma poco importa .. lo script nn è fatto per castare al massimo è fatto per un confronto .. cmq farò la v0.6 che dice effettivamente il tempo di cast con i tuoi accorgimenti ..

Dunque, ho controllato un paio di cosette. Effettivamente il linespercycle funziona ma cmq ti sconsiglio di usarlo, sia perchè è un comando deprecato e potrebbero prima o poi rimuoverlo da una delle future versioni di easyuo, sia per un motivo di text highlighting e quindi chiarezza/estetica del codice che scrivi.

LPC 100 significa che easyuo tenta di interpretare 2000 righe di codice al secondo, quindi mettendo lo start time dopo l'event macro, hai un'incertezza di soli 0,0005 secondi, mentre mettendolo prima, come hai fatto tu, consideri un notevole lasso di tempo in più, qualche decina di millisecondi, perchè entra in gioco un certo ritardo di easyuo a mandare l'event macro al client.

Inoltre, il mio script non tiene conto del target semplicemente perchè questo non importa nel calcolare la velocità della spell. Infatti, se provi a castare magie di primo circolo in movimento ti accorgerai che non c'è bisogno che il tuo pg stia fermo oltre 400ms come risulta dal tuo script, ma molto meno, infatti sembra di castare quasi in corsa con una buona connessione.

Ma anche volendo considerare il tempo di targeting, hai fatto un altro errore che causa un ulteriore ritardo nei calcoli dello script. Infatti, se si utilizza un sistema di target immediato, come il target self di razor oppure di injection, non ci sarà alcun ritardo dovuto al target, se non metà del proprio ping, che con un'adsl significa circa 30 millisecondi.

Però Easyuo non ha un metodo di targeting immediato, infatti vedi spuntare fuori il mirino prima che targetti, cosa che non succede in razor e injection. E quindi, ancora una volta, il tuo script calcola un delay aggiuntivo troppo elevato, a causa dei "limiti" di easyuo.

Il mio script vi dà un'idea di quanti millisecondi esattamente il vostro pg impiega dall'inizio della spell allo spuntare del target. Poi bisogna aggiungere altri 30 millisecondi circa, prima che il target venga mandato al server, e altri 30 prima che il vostro client se ne accorga.

Però considerate che durante questi ultimi 60ms siete già liberi di muovervi, inoltre gli ultimi 30 ai fini del gaming non importano perchè lato server la spell è stata già completamente castata. L'unico effetto collaterale è che a volte (l'avrete sicuramente notato) vedrete l'animazione della spell arrivare solo dopo che avete cominciato a muovervi.

Spero di essere stato chiaro.

[DJ_Flash]

Dunque, ho controllato un paio di cosette. Effettivamente il linespercycle funziona ma cmq ti sconsiglio di usarlo, sia perchè è un comando deprecato e potrebbero prima o poi rimuoverlo da una delle future versioni di easyuo, sia per un motivo di text highlighting e quindi chiarezza/estetica del codice che scrivi.

LPC 100 significa che easyuo tenta di interpretare 2000 righe di codice al secondo, quindi mettendo lo start time dopo l'event macro, hai un'incertezza di soli 0,0005 secondi, mentre mettendolo prima, come hai fatto tu, consideri un notevole lasso di tempo in più, qualche decina di millisecondi, perchè entra in gioco un certo ritardo di easyuo a mandare l'event macro al client.

Inoltre, il mio script non tiene conto del target semplicemente perchè questo non importa nel calcolare la velocità della spell. Infatti, se provi a castare magie di primo circolo in movimento ti accorgerai che non c'è bisogno che il tuo pg stia fermo oltre 400ms come risulta dal tuo script, ma molto meno, infatti sembra di castare quasi in corsa con una buona connessione.

Ma anche volendo considerare il tempo di targeting, hai fatto un altro errore che causa un ulteriore ritardo nei calcoli dello script. Infatti, se si utilizza un sistema di target immediato, come il target self di razor oppure di injection, non ci sarà alcun ritardo dovuto al target, se non metà del proprio ping, che con un'adsl significa circa 30 millisecondi.

Però Easyuo non ha un metodo di targeting immediato, infatti vedi spuntare fuori il mirino prima che targetti, cosa che non succede in razor e injection. E quindi, ancora una volta, il tuo script calcola un delay aggiuntivo troppo elevato, a causa dei "limiti" di easyuo.

Il mio script vi dà un'idea di quanti millisecondi esattamente il vostro pg impiega dall'inizio della spell allo spuntare del target. Poi bisogna aggiungere altri 30 millisecondi circa, prima che il target venga mandato al server, e altri 30 prima che il vostro client se ne accorga.

Però considerate che durante questi ultimi 60ms siete già liberi di muovervi, inoltre gli ultimi 30 ai fini del gaming non importano perchè lato server la spell è stata già completamente castata. L'unico effetto collaterale è che a volte (l'avrete sicuramente notato) vedrete l'animazione della spell arrivare solo dopo che avete cominciato a muovervi.

Spero di essere stato chiaro.

Completamente daccordo .. ai fini del confronto però anke se aggiungi mettiamo 200ms a tutte le magie nn cambia nulla .. chiaro devi interpretare in maniera differente i risultati.. cmq cm già detto appena posso modifico lo script ..

[FireFox86]

Dunque, ho controllato un paio di cosette. Effettivamente il linespercycle funziona ma cmq ti sconsiglio di usarlo, sia perchè è un comando deprecato e potrebbero prima o poi rimuoverlo da una delle future versioni di easyuo, sia per un motivo di text highlighting e quindi chiarezza/estetica del codice che scrivi.

LPC 100 significa che easyuo tenta di interpretare 2000 righe di codice al secondo, quindi mettendo lo start time dopo l'event macro, hai un'incertezza di soli 0,0005 secondi, mentre mettendolo prima, come hai fatto tu, consideri un notevole lasso di tempo in più, qualche decina di millisecondi, perchè entra in gioco un certo ritardo di easyuo a mandare l'event macro al client.

Inoltre, il mio script non tiene conto del target semplicemente perchè questo non importa nel calcolare la velocità della spell. Infatti, se provi a castare magie di primo circolo in movimento ti accorgerai che non c'è bisogno che il tuo pg stia fermo oltre 400ms come risulta dal tuo script, ma molto meno, infatti sembra di castare quasi in corsa con una buona connessione.

Ma anche volendo considerare il tempo di targeting, hai fatto un altro errore che causa un ulteriore ritardo nei calcoli dello script. Infatti, se si utilizza un sistema di target immediato, come il target self di razor oppure di injection, non ci sarà alcun ritardo dovuto al target, se non metà del proprio ping, che con un'adsl significa circa 30 millisecondi.

Però Easyuo non ha un metodo di targeting immediato, infatti vedi spuntare fuori il mirino prima che targetti, cosa che non succede in razor e injection. E quindi, ancora una volta, il tuo script calcola un delay aggiuntivo troppo elevato, a causa dei "limiti" di easyuo.

Il mio script vi dà un'idea di quanti millisecondi esattamente il vostro pg impiega dall'inizio della spell allo spuntare del target. Poi bisogna aggiungere altri 30 millisecondi circa, prima che il target venga mandato al server, e altri 30 prima che il vostro client se ne accorga.

Però considerate che durante questi ultimi 60ms siete già liberi di muovervi, inoltre gli ultimi 30 ai fini del gaming non importano perchè lato server la spell è stata già completamente castata. L'unico effetto collaterale è che a volte (l'avrete sicuramente notato) vedrete l'animazione della spell arrivare solo dopo che avete cominciato a muovervi.

Spero di essere stato chiaro.

E aggiungerei un per critiche costruttive di questo genere che aiutano a migliorare

[drudrusk8]

1° 440 CON RAZOR script di djstanzetta
2° 695
3° 923
4° 1180
5° 1432
6° 1678
7° 1925
fc2/f6

script di vash valori tra i 320-330

CON injection vash media 280-311

[isterico]

quello di vash dove sta di script?

ah, e' un 3d vecchio. mi pareva di averlo gia letto

[gramoz]

1°:961
2°:1205
3°:1482
4°:1688
5°:1950
6°:2207
7°:2450
8°:2668 

Velocità:3
Wait_Fcr:10
Client:6.0.1.3
EUO:1_50_00

con razor, fastweb. bello eh?

ps: non sapevo quanto mettere di precisione test e quindi ho lasciato 3, al momento avevo attivi: Razor, EasyUo, Miranda e Antivirus Nod32

[bergamo]

cn msn icq ed emule adunanza accesi :
precisione 3
1=259
2=693
3=989
4= 1198
5= 1401
6= 1680
7=1904
8= 2497
fc3 fcr6 client 6.0.2.0 euo :1_50_00
Fastweb regna XD

però adunanza viaggiava basso tipo 150\170 kb\sec l'avevo settato basso per sto test.
Ah se serve avevo oltre al client di ultima aperto pure itunes e una puntata di dr house

[XearEvil]

fate schifo...



Tutti

[androix]

1° circolo = 425 ms
2° circolo = 660 ms
3° circolo = 922 ms
4° circolo = 1172 ms
5° circolo = 1435 ms
6° circolo = 1673 ms
7° circolo = 1914 ms
8° circolo = 2188 ms

precisione 10
avevo attivi uo, razor, miranda, antivirus, easyuo, mozzilla, winamp

[DJ_Flash]

1°:961
2°:1205
3°:1482
4°:1688
5°:1950
6°:2207
7°:2450
8°:2668 

Velocità:3
Wait_Fcr:10
Client:6.0.1.3
EUO:1_50_00

con razor, fastweb. bello eh?

ps: non sapevo quanto mettere di precisione test e quindi ho lasciato 3, al momento avevo attivi: Razor, EasyUo, Miranda e Antivirus Nod32

Wait_Fcr:10 .. all'inizio devi settare fcr a 6 .. se metti ad esempio 5 ti mette il delay per consentirti di recuperare .. cmq precisione a 3 è buona .. piu aumenti quel valore piu magie castera e farà quindi una media piu precisa ..

cn msn icq ed emule adunanza accesi :
precisione 3
1=259
2=693
3=989
4= 1198
5= 1401
6= 1680
7=1904
8= 2497
fc3 fcr6 client 6.0.2.0 euo :1_50_00
Fastweb regna XD

però adunanza viaggiava basso tipo 150\170 kb\sec l'avevo settato basso per sto test.
Ah se serve avevo oltre al client di ultima aperto pure itunes e una puntata di dr house

1=259 .. non ci credo

[bergamo]

rifatto con 10 di precisione
il primo circolo sviaggia a palla 1 =261 poco cambia dal primo risultato poi gli altri circoli sono piu o meno nella norma o_O o piu lenti di altri nn chiedetemi il perchè >_>