[ANNUNCIO FIX] Fix del 2016/09/21

[MagnetoStaff]

Ciao a tutti,

vi informiamo che, dal restart di domani mercoledì 21 settembre 2016, saranno attivi sul Main Server i seguenti fix:

1) modifiche al funzionamento del Remove Loss Deed:

- Loss da 20 minuti (16 per Premium): se mancano più di 10 minuti prima che esaurisca l'effetto del loss cliccando il deed riceverete un messaggio di errore che vi dirà quanto manca prima di poterlo usare
- Loss da 10 minuti (8 per Premium): cliccando il deed potrete usarlo immediatamente
- In entrambi i casi, una volta usato il deed ci sarà un cooldown da 10 minuti prima di poterne usare un altro
- Ora il deed ha una durata di 30 minuti (prima era di 12 minuti)

2) ora le Insane Dryad di Blighted Grove dovrebbero attaccare spontaneamente i target non honorati: non sarà pertanto più necessario rivelarle con spell ad area

3) aumentato il range di percezione per tutte le evocazioni a 16 tiles: questo dovrebbe far si che le summons attacchino ai champ con maggiore autonomia

4) fixato bug alla Special Ability "Dismount": ora non sarà più possibile dismontare da montati un avversario che, a sua volta, non dressi una lancia

5) dovrebbe essere stato corretto il bug per il quale i pet, dopo il restart, non riconoscevano subito il comando "all follow me"

6) crash fix per le spell di tipo bonus/malus: sono stati aggiunti ulteriori controlli alle spell di tipo bonus/malus (Bless, Curse, Weaken, ecc.) per evitare possibili anomalie e crash in game

7) ulteriori fix e modifiche cumulative: tali aggiornamenti del codice non impattano sulle meccaniche attuali note, ma sono propedeutici a future nuove implementazioni che seguiranno prossimamente

8) aggiornato il numero di Dragon Blood ottenibile carvando i diversi mostri: sono stati inclusi nell'elenco anche gli altri mostri validi precedentemente assenti, come ad esempio le White Wyrm


Vi ricordiamo che le modifiche in oggetto hanno richiesto la ricompilazione del Core, e che pertanto gli ID dei Gump potrebbero variare.

Vi invitiamo come sempre a segnalare prontamente ogni anomalia, grazie a tutti per la collaborazione!
Ciao a tutti e buon game

[_Hydro_]

Ottimo. Grazie

Inviato dal mio SM-G930F utilizzando Tapatalk

[turkice]

[fwiffo]

Vi ricordiamo che le modifiche in oggetto hanno richiesto la ricompilazione del Core, e che pertanto gli ID dei Gump potrebbero variare.

Gli ID dei gump variano perché usate MONO su linux, anche se una soluzione per ripristinare lo status identico a win c'è sempre mettendo le mani nel posto corretto:

in Server/Gumps/Gump.cs

public static int GetTypeID( Type type )
		{
			return Utility.GetHashCode32(type.FullName);//type.FullName.GetHashCode();
		}

ed ovviamente in utility.cs va generata l'opportuna funzione che mantenga il gencode di una macchina pseudo 32bit, come su windows:

public static int GetHashCode32(string s)
		{
			unsafe
			{
				fixed (char *src = s)
				{
					Contract.Assert(src[s.Length] == '\0', "src[this.Length] == '\\0'");
					Contract.Assert( ((int)src)%4 == 0, "Managed string should start at 4 bytes boundary");

					int hash1 = (5381<<16) + 5381;
					int hash2 = hash1;

					// 32 bit machines. 
					int* pint = (int *)src;
					int len = s.Length;
					while (len > 2)
					{
						hash1 = ((hash1 << 5) + hash1 + (hash1 >> 27)) ^ pint[0];
						hash2 = ((hash2 << 5) + hash2 + (hash2 >> 27)) ^ pint[1];
						pint += 2;
						len  -= 4;
					}

					if (len > 0) 
					{ 
						hash1 = ((hash1 << 5) + hash1 + (hash1 >> 27)) ^ pint[0];
					} 
					return hash1 + (hash2 * 1566083941);
				}
			} 
		}

Per gentile concessione.

Saluti

P.S: in questo modo i vostri gump non cambiano id ad ogni riavvio, nè ad un eventuale cambio architettura, nè tantomeno se cambiate OS (e sono uguali a prima che vi spostavate sul monoCESS)

[MagnetoStaff]

Ringrazio sentitamente per la porzione di codice, il fix - salvo imprevisti - verrà testato e, qualora fili tutto liscio, andrà up alla prossima tornata.

Solo un piccolo dubbio, perchè non ho colto il riferimento a monoCESS... che ha tanto di CESS il framework MONO, e tanto più il sistema operativo ospitante Debian Linux?
Da quando siamo transitati sotto Unix, i save sono passati - vabbè, anche per il cambio hardware, ma il SO ha fatto la differenza - da 30 secondi a 3, possiamo ospitare più macchine virtuali in container LXC efficienti, e molte altre cose.

Mi piacerebbe sinceramente capire cosa avrebbe di irrinunciabile il framework .NET sotto Windows (o dovrei direi winzozz per par condicio?)... domanda seria, sono curioso..

[seel82]

Per pura curiosità ho fatto una ricerca anche io
http://stackoverflow.com/questions/5...-be-consistent

Vedi uno non ci pensa mai all'architettura... Grande

[fwiffo]

Difendere a spada tratta il MONO non occorre, ha i suoi pregi, ma su RUN ha troppi difetti, troppe cose da manipolare e revisionare, soprattutto quando si usa un sistema simile.

Ho avuto il piacere di usare mono per un anno. Non parlo a caso, l'hardware vi assicuro che fa la differenza e che i termini di comparazione in termini di uso memoria e CPU non ve ne sono in un'applicazione come questa.

Poi se parliamo di altri usi, posso entrare nel merito ed essere in pieno accordo, ma evitiamo le prese di posizione per partito preso. .NET surclassa in diversi aspetti il MONO per una ovvietà, il sistema è de-facto pensato e fatto ed è perfettamente integrato nel suo ambiente originale.

Sfido a guarda un listato thread con relativo grafico dell'andamento uso e consumi tra le due piattaforme.

Poi, può darsi non vi sia ancora successo, ma ocio al console.writeline di mono, non è un'istruzione safe come quella presente sull'ambiente di win, il server tenderà a crashare. Soprattutto se a scrivere sulla stessa console sono thread separati come quello del network e soprattutto se poi questo implica il filewrite al console.log

Di usare l'ho usato...io ho solo scritturato la mia esperienza, ed allo stato de facto è un mezzo-cess, buono in certe applicazioni, ma mediocre in altre.