Loot e loot condivisi

[fengyr]

non so quando siano state introdotte le modifiche ai loot ma i problemi persistono da quando sono tornato attivo da novembre, anomalie che nel passato non esistevano.
credo che sia cosa nota a tutti piu o meno ma non e' cosi' semplice da spiegare...

negli ultimi mesi in cui ho ricominciato a giocare i looter da script, e lo stesso uosteam fanno capricci quando il loot e' condiviso, ovvero il mob viene ucciso da piu player che siano in party o meno non c'e' differenza.
ebbene la cosa che ho notato e' che in quei casi l'id del gump del corpse non corrisponde all'id del corpo del morto... nel momento in cui il loot ridiventa pubblico gli id tornano a coincidere, script e steam funzionano come previsto.

altra anomalia mi e' capitata di notarla poco fa nel lootare il beetle di un amico che era morto su tokuno: non siamo nella stessa gilda, clicko il corpse del beetle e ricevo puntualmente il messaggio "You may not loot this corpse" ma il corpse si apre comunque e posso lootarlo. il funzionamento in passato era che nei primi 2-3 minuti si riceveva il messaggio ma non si potevano aprire o lootare tali corpi, passato il tempo il loot diventava pubblico ed era lootabile, discorso diverso x felucca.

[fastandfurious46]

è steam, lo faceva anche prima

[Alexdan]

Per quanto riguarda gli assist per il loot è normale in quanto:
- Steam è un progetto chiuso (Non verra' più aggiornato) e di conseguenza non ha gli update per supportate i loot condiviso col tempo sparira' nel momento che ci sara' un nuovo client non sara' più supportato in quanto cambierà l'encription o l'entry point per la funzione di encrypt e decrypt dei pacchetti.

- Script, bisogna scrivere uno script per lootare i loot condivisi

Non è un bug ma semplicemente gli script e assistant che non sono aggiornati con i tempi
Un esempio banale: Se cambiano gli id della legna è normale che il luber scorna non vada e deve essere aggiornato, la stessa cosa avviene per il loot condiviso

Io con steam ho scritto uno script per lootare i corpi condivisi semplicemente bindando un tasto e lanciare un moveitem gold da un finditem corpi attorno (nulla di complicato)

Per quanto riguarda i beetle non ci ho mai fatto caso

[Alexdan]

Da ulteriore verifiche l'ID del corpo è sempre 0x2006 non cambia mai.. L'id del gump non anche se cambiasse non so a cosa ti serve in quanto quello che deve fare uno script di loot è cercare ongroud i copri con id 0x2006

[fengyr]

@fester no, non e' un bug di uosteam quanto piuttosto un cambiamento introdotto nel server in tempi recenti.

0x2006 e' l'id grafico che corrisponde al gump del corpse, ed e' chiaro che sia costante.
forse non mi sono espresso bene ma quello che intendevo nel topic e' l'id ( o serial chiamalo come vuoi) univoco proprio del gump, in certi casi coincide con quello del corpo del mob morto, in altri casi che ho illustrato, sono differenti e sono la causa dei problemi ai programmi esterni al client.
il problema credo che sia da attribuire nei codici che generano l'istanza temporanea del loot condiviso, che come ho detto danno un gump con id/serial non corrispondente ad un oggetto del mondo di gioco cosa che invece non accadeva in passato.


detto questo vado OT per rispondere al post precedente di Alexdan e do delle opinioni personali.
non credo che debba essere normale un anomalia introdotta che causa negli assist del client un funzionamento parziale. non tutti gli utenti sono esperti con gli script per riuscire a trovare delle soluzioni, nonostante come ha detto correttamente possa richiedere uno sforzo minimo.

[Alexdan]

@fester no, non e' un bug di uosteam quanto piuttosto un cambiamento introdotto nel server in tempi recenti.

0x2006 e' l'id grafico che corrisponde al gump del corpse, ed e' chiaro che sia costante.
forse non mi sono espresso bene ma quello che intendevo nel topic e' l'id ( o serial chiamalo come vuoi) univoco proprio del gump, in certi casi coincide con quello del corpo del mob morto, in altri casi che ho illustrato, sono differenti e sono la causa dei problemi ai programmi esterni al client.
il problema credo che sia da attribuire nei codici che generano l'istanza temporanea del loot condiviso, che come ho detto danno un gump con id/serial non corrispondente ad un oggetto del mondo di gioco cosa che invece non accadeva in passato.


detto questo vado OT per rispondere al post precedente di Alexdan e do delle opinioni personali.
non credo che debba essere normale un anomalia introdotta che causa negli assist del client un funzionamento parziale. non tutti gli utenti sono esperti con gli script per riuscire a trovare delle soluzioni, nonostante come ha detto correttamente possa richiedere uno sforzo minimo.

Facciamo un attimo una cosiderazione...

Partiamo dai presupposti per evitare casini:

- Serial: è un valore di tipo uint a 16 bit contenente un numero idetificativo UNIVOCO per ogni item presente in game che sia un cropo un dagger o qualsiasi cosa.
- ID: L'id o conosciuto come grafica è un uint 8, che contiene l'ID dell'immagine (art.mul) che il client deve visualizzare riferita a quell'oggetto.
- DispID: è una variazione di questa immagine, ma con base ID uguale.
- GumpID: un uint 8 che contiene il gump che deve apparire nel momento dell'apertura riferito a (gump.mul). Se è un container.

L'entità di un item contiene queste e molte altre informazioni ma la chiave rimane il serial.

Analizziamo i corpi:
Un corpo non è altro che un contenitore come se fossa un backpack o un puch ecc
- Il suo serial è univoco in quanto non puo' esistere un altro uguale.
- Il suo ID è: 0x2006
- Il suo DISPID: corrisponde all'immagine del mob morto
- Il suo GumpID: corrisponde all'immagine del gump del cadavere aperto (quello con il teschio sopra per intenderci).

Appena il corpo appare in schermata o viene generato il server invia al client un pacchetto contenente l'entity del nuovo oggetto.

Caso non sia condiviso:
Una volta che viene aperto mostra il contenuto e tutto va bene il serial rimane quello

Caso Condiviso:
Nel momento che uno dei membri del party lo apre vengono generate delle copie virtuali in base del corpo con Serial differenti in quanto ognuno ha il suo contenuto! e il serial base dell'item a terra non è piu' valido o meglio non contiene quello che cerchiamo.

Il problema degli agent o script che tentano di lootare ancora dal serial di riferimento da quando hanno visto il corpo generarsi per terra e non gestiscono la possibilità che questo sia cambiato visto che è condiviso.
Dovrebbero semplicemente ricercare di nuovo a terra ed acquisire il nuovo serial e lootare da quello.


Per la mia scuola di pensiero questa non è un anomalia del server o bug (in quanto non possono esistere corpi, cioe' item con lo stesso serial) questa è la programmazione base dell'emulatore. Ma gli agent e script che non sanno gestire questa variazione. Semplicemente gli manca l'aggiornamento per questa evenienza!

L'esempio è se tento di usare una versione vecchia di ICQ, Non ti lascia connettere in quanto il protocollo è cambiato.. è la stessa situazione che avviene qui.

Potrei dilungarmi per pagine sulla struttura del pacchetto NewItem inviato dal server a client ma non servirebbe a nulla

Per steam un semplice script per lootare il gold dei corpi a terra condivisi basta bindarselo su un tasto e via:

while @findtype '0x2006' 'any' 'ground' '1' '2'
  useobject 'found'
  setalias 'cc' 'found'
  pause 300
  while @findtype '0xeed' 'any' 'cc'
    moveitem 'found' 'backpack'
  endwhile
  ignoreobject 'cc'
endwhile

[fengyr]

Grazie per le puntualizzazioni, seguendo le tue linee guida sicuramente riusciro' a farmi capire meglio

0x2006 e' l'id grafico che corrisponde al gump del corpse, ed e' chiaro che sia costante.

precisazione: mi ero conufuso, parlavo di GumpID (gump.mul) ma in realta' e' l'ID (art.mul)

ma il nocciolo della discussione, e cito te e' questo:

Caso Condiviso:
Nel momento che uno dei membri del party lo apre vengono generate delle copie virtuali in base del corpo con Serial differenti in quanto ognuno ha il suo contenuto! e il serial base dell'item a terra non è piu' valido o meglio non contiene quello che cerchiamo.

e quindi concordi con me che il meccanismo e' cambiato.
oggi mi sono riguardato gli script di RunUO, ho scritto 2 volte un papiro di post e quando arrivavo a inviarlo il forum mi richiedeva i dati del login per postare e perdevo il testo XD scusa se ora sono stringato ma spero capirai.
effettivamente nelle ultime release pubbliche di RunUO il meccanismo di 'istanziazione' dei loot e' quasi esattamente come lo hai descritto tu.
personalmente SteamUO lo uso parzialmente e non ne so molto nonostante agli albori abbia collaborato con gli sviluppatori (era una cosa molto basilare, non era ancora implementato il sistema di scripting , la mappa ed aveva un altro nome ), quindi non so bene come si interfacci al client e i sorgenti che ho io sono ben lontani dal prodotto di oggi. tutte le mie supposizioni iniziali in base a steam erano piu' basate sulle logiche che adotto negli script di easyuo (lo so, e' inefficiente arcaico etc ma per un mezzo-programmatore amatoriale pigro come me e' sufficiente).
perche' questa premessa? per tornare al punto iniziale, prima il seriale (ed intendo il ContID di easyuo, ovvero il seriale del gump in primo piano) coincideva sempre e in ogni caso al corpo del mob a terra nel mondo di gioco, e per questi credo che il problema sia imputabile a eventuali modifiche introdotte.

ecco una breve ricerca che ho fatto su come si e' evoluto il loot system (nei link i codici originali di corpse.cs che contiene il loot system oggetto di discussione)

possibile sistema attuale (RunUO 2.5 / RunUO 2.3 ultima release ufficiale reperibile) :

List<Mobile> attackers = new List<Mobile>( m_Aggressors );

			for ( int i = 1; i < attackers.Count -1; i++ )  //randomize
			{
				int rand = Utility.Random( i + 1 );

				Mobile temp = attackers[rand];
				attackers[rand] = attackers[i];
				attackers[i] = temp;
			}

viene generato un serial random temporaneo, che mi compare come "ContID" temporaneo (il mio imputato)

possibile sistema passato (RunUO 2.0) :

private Dictionary<Mobile, List<Item>> m_InstancedItems;

non veniva generato nessun serial temporaneo o "contenitori" ma creato un dizionario con indice il seriale del mob.

come ho detto nell'incipit, non so a che punto sia stata cambiata la cosa ma me ne sono accorto da quando ho ricominciato verso novembre e da semplice giocatore non posso sapere se sia esattamente cosi'.
scusami per eventuali imprecisioni lessicali anche in questo post, ho scritto in fretta
ps: con questo ho cercato di spiegare anche il percorso logico che mi ha portato ad aprire questo tread, se le ragioni dei problemi sono imputabili ad altro e sono completamente fuori strada chiedo venia per avervi sottratto tempo inutilmente ^_^

[Alexdan]

E' esattamente la stessa cosa che dico io ma in modo diverso con nomi dei parametri diversi

Esattamente il ContID di EasyUO non è altro che il riferimento UNIVOCO al container dove stanno gli item E ovviamente in caso di condivisione è istanziato per ogni membro del party! Ora non ricordo con esattezza ma EasyUO quello che io chiamo serial lui lo gestisce come ContID per i contaier

Ovviamente per il loot condiviso deve cambiare il meccanismo, non puoi condividere un loot in un container uguale altrimenti tutti hanno lo stesso risultato, nel momento che il server invia al client il contenuto del container.

Il modo in cui viene generato da RunUO puo' cambiare ma il succo per renderlo compatibile con il protocollo di comunicazione del client non puo' cambiare, i pacchetti devono rimanere come sono stabiliti dal client. E l'unico modo per generare un loot istanziato (a mio parere) sono container diversi!

Ora questo ID ne viene generato uno UNIVOCO (al momento dell'apertura) per ogni membro del party! ma il problema è facilmente aggirabile forzando una nuova ricerca unground in modo che la "lista" di item in cache nell'assistant si aggiorni con l'attuale stato del game e un eventuale moveitem (che non è altro che la funzione dell'autoloot un moveitem da source destination) dell'assistant abbia come source il contenitore "virtuale" esatto, rispetto a quello base.
Non è altro che il funzionamento del mio script base che ho messo sopra.

Il problema rimane questo gli assistant attuali non gesticono la possibilita' di un cambio del container dal momendo che appare il corpo a terra al momento che viene aperto. Per loro rimane quello di quando è apparso il corpo.

[fengyr]

Il problema rimane questo gli assistant attuali non gesticono la possibilita' di un cambio del container dal momendo che appare il corpo a terra al momento che viene aperto. Per loro rimane quello di quando è apparso il corpo.

ok, abbiamo chiarito che siamo d'accordo su quali siano le meccaniche trattate. forse l'incomprensione sara' stata causata da parte mia spiegandomi male: se secondo VOI non si tratta di bug ma e' una feature, causa in ogni caso dei disagi ai giocatori COSTRETTI a giocare con uosteam.

facciamo un passo indietro adesso, il vecchio sistema di loot aveva delle pecche effettivamente (ad esempio in passato capitava che i player aprendo il corpo si vedessero comparire al posto degli item degli zaini colorati che corrispondevano ai loot istanziati).
ma e' proprio necessario introdurre un sistema che aggiunge inutilmente inefficienze e quindi complessita' al gioco dei player (a che pro 'sto benedetto seriale temporaneo random, non ci trovo una logica)? ribadisco, e' vero come hai detto, si risolve con una macro di poche righe ma e' comunque un tampone che l'utente deve mettere su una montagna di cerotti.
oltretutto la questione del flagging del looting dei pet che ho messo come secondo punto nel topic, e' a tutti gli effetti un bug, non dimentichiamo.


giusto ieri alcuni amici hanno voluto provare a ricominciare a giocare su UOD, ma effettivamente per chi si affaccia la prima volta al gioco non si trova in una bella situazione pensa solo a tutta la trafila che c'e' da fare per poter soltanto loggare (creazione account su un portale diverso da quello del server, istruzioni sul sito che rimandano con un link al forum con altre istruzioni che rimandano a host esterni per scaricare un client che un utente ha avuto la buona volonta' di mettere insieme, con altre istruzioni da seguire), 2 su 4 hanno avuto problemi di ogni sorta ed un altro aspetta che gli installi tutto io.
e' impossibile accontentare tutti in qualsiasi contesto, ma creare dei deterrenti vuol dire allontanare molti potenziali giocatori.
e qui chiudo senno' finiamo nell'OT piu profondo, non voglio criticare nessuno e non pretendo che ci siano dei cambiamenti, ma secondo me e' bene tenere presente i sopracitati esempi

[Alexdan]

[OT]
Sul fatto che andrebbe riordinato un po sito, istruzioni per loggare e download mi trovi pienamente d'accordo Non vedo perché il client deve essere scaricato da un mirror di un altro host e non caricato direttamente sul host dello shard.. alla fine non lo scaricano in 100000 tutti i giorni quindi non vedo questo carico sulla banda eccessivo.

E anche un riorganizzato il forum, in quanto ci sono 1000 post stickati andrebbero riunuti e rimosse cose vecchie, tipo modifiche al regolamento stickate ecc ecc andrebbero aggiornate sul sito direttamente e fatte sparire dal forum.. Sarebbe piu' ordinato e leggibile per tutti