"PROPOSTE INTERESSANTI"

[Martinus]

Rispondo brevemente e generalmente, non riguardo all'argomento, ma al modo di fare.
Come hai gia' detto Mizar:

Fate vobis, come qualcuno piu' di una volta ha ricordato, il mud non e' una democrazia..

Ma questo non vuol dire che tutto quello che si propone passa direttamente nel cestino. Ti diro cosa puo succedere e ti daro anche un'esempio.
1) Non sempre gli implementor al momento della proposta hanno tempo e/o voglia di implementare quello che si propone. Magari hanno anche un'elenco lungo di bug da sistemare e/o altre cose nella coda delle implementazioni.
2) Non e' che lo facciamo cosi tanto per dire, per quel motivo ho creato la sezione proposte interessanti, per ricordarci noi delle cose che ci sono piaciute, e per dare ai player che hanno proposto un feedback. Se vai a vedere quella sezione ci sono comunque cose non implementate ancora, ci sono cose che sono state riadattate e implementate etc etc.

Ti faro anche un'esempio concreto, per una cosa che tu stesso hai proposto qualche tempo fa'.
Nel codice del tester e' presente la nuova versione del "charge" con cariche multiple e altre belle cosine.
Al tempo avevo detto pisc... stavo praticamente smettendo di codare, e cosi a occhio sembrava una modifica abbastanza consistente per il modo in cui era stato implementato il charge. Poi 1 mese fa' tipo l'ho rivisto con calma, ne ho discusso con nis e zaken, e alla fine si e' implementato, ed era meno complicato di quello che si credeva.
Quindi... pazienza. Non fatevi prendere dall'euforia della proposta nuova. Ogni cosa ha la sua importanza e avra il tempo che merita al momento oportuno.

[Mizar]

MARTINUS!!! Che piacere!!! Mi mancano i tuoi nuke ingame!!!
Vado con ordine sperando che la vena polemica non si accenda piu' del dovuto.

Rispondo brevemente e generalmente, non riguardo all'argomento, ma al modo di fare.
Come hai gia' detto Mizar:

Fate vobis, come qualcuno piu' di una volta ha ricordato, il mud non e' una democrazia..

Ma questo non vuol dire che tutto quello che si propone passa direttamente nel cestino.

Potrebbe essere utile classificare le proposte in termini di "codificabilita'" e "impatto di bilanciamento": questo darebbe una misura a chi propone di quanto si e' "sulla strada giusta" per avere dei modelli di proposta che rendano le operazioni di screening e testing piu' veloci ed efficienti, poi ovvio che dipenda dalla disponibilita' degli implementor prendersi quelle 2 orette per scrivere le procedure.

Ti diro cosa puo succedere e ti daro anche un'esempio.
1) Non sempre gli implementor al momento della proposta hanno tempo e/o voglia di implementare quello che si propone. Magari hanno anche un'elenco lungo di bug da sistemare e/o altre cose nella coda delle implementazioni.

Non discuto sulle priorita' di debug rispetto a nuove implementazioni, ma la fase di instabilita' l'abbiamo superata da tanto mi pare..

2) Non e' che lo facciamo cosi tanto per dire, per quel motivo ho creato la sezione proposte interessanti, per ricordarci noi delle cose che ci sono piaciute, e per dare ai player che hanno proposto un feedback. Se vai a vedere quella sezione ci sono comunque cose non implementate ancora, ci sono cose che sono state riadattate e implementate etc etc.

Che dire.. i mob "freccer" del lab sono stati ideati a partire da una mia proposta quando esploravo altri OLG, in particolar modo la classe arciere e l'abilita' "scatter" (colpo fisico ad area). Quindi non metto indubbio la capacita' di adattare possibili migliorie al codice attuale di TS.

Ti faro anche un'esempio concreto, per una cosa che tu stesso hai proposto qualche tempo fa'.
Nel codice del tester e' presente la nuova versione del "charge" con cariche multiple e altre belle cosine.
Al tempo avevo detto pisc... stavo praticamente smettendo di codare, e cosi a occhio sembrava una modifica abbastanza consistente per il modo in cui era stato implementato il charge. Poi 1 mese fa' tipo l'ho rivisto con calma, ne ho discusso con nis e zaken, e alla fine si e' implementato, ed era meno complicato di quello che si credeva.

Ma e' proprio quello che dico io! Non capisco perche' a fronte di proposte "obbiettivamente" realizzabili sia in termini di tempo, che di difficolta', che di bilanciamento i tempi di attuazione si dilatino a dismisura (il rolling decap implica la modifica del valore lag_post_action da 3 a 0.2, non serve mica un anno di coding). Da sempre il mud e' ritrovo di programmatori di vario genere, e le "risorse umane" per buttare giu' bozze di codice sono l'unica cosa che e' sempre abbondata su TS. I player PWP sono gli stessi che hanno strutturato il loro gioco sulle procedure esistenti, ottimizzando la resa dei propri pg. Come sappiamo tutti, siamo arrivati ad un punto in cui alcuni PG sono stati trasformati in un contro-codice per le azioni ripetitive in cui il divertimento tende a 0. Non vedo perche' il rapporto tra player e admin debba essere necessariamente conflttuale piuttosto che collaborativo. Se gli implementor sono "occupati" e qualcosa di "carino" puo' essere implementato a breve termine, perche' non attingere dal potenziale dei PG stessi?

Quindi... pazienza. Non fatevi prendere dall'euforia della proposta nuova. Ogni cosa ha la sua importanza e avra il tempo che merita al momento oportuno.

Permettimi di precisare che il "tempo che merita" e "momento opportuno" sono 2 variabili dell'ottica admin. Per i player e' tutta un'altra cosa. Se le modifiche sul charge fossero state analizzate ai tempi, magari TS avrebbe il doppio della popolazione attuale. Questo non fa di voi dei cattivi implementor, ma sicuramente avete ampio margine di miglioramento sulle "tempistiche" di implementazione. Era chiaro sin da allora che la modifica non avrebbe richiesto 2 anni per l'implementazione, ma i PISC non hanno avuto certo un'effetto invogliante per gli utenti, o mi sbaglio? Le analisi fatte nel corso degli anni, anche in maniera tecnica con numeri alla mano, non sono state fatte per portare acqua al mulino di druidi, sorci o chierici in particolare, ma per evidenziare i buchi di gameplay.
Quando mi venne in mente la "frammentazione", la prima cosa che feci e' chiedere a qualcuno piu' esperto di me nel coding se e cosa fosse attuabile. Nello specifico esposi la cosa a Nis e Zaken, che mi risposero "Seeeeeeeeeeeeee". Non mi scandalizzai, mi rendevo gia' all'ideazione che a livello di codice avrebbe richiesto PARECCHIO sbattimento, ma il detto dice "chi comincia e' gia' a meta' dell'opera", per cui mi rivolsi qualche gradino piu' sotto a Venus. Esposi la mia idea e pur non essendo chiarissima, con parecchi buchi concettuali, e chiesi di buttar giu' una bozza di implementazione (che trovate sempre in sezione OT). Ora io ci capisco pochissimo di codice, ma non credo che quel papello sia completamente inattuabile o inadattabile. Se ci si pensa bene sono tutte sfumature di gameplay che gia' esistono nel gioco, si tratta solo di raggrupparle in maniera differente per tirare fuori skill o classi nuove. E di certo non avrei mai presteso che la cosa passasse in blocco, ho passato tempo sufficiente sul mud (cosi' come in RL) per capire da solo che gli aggiustamenti sono necessari SEMPRE. Quello che indispone e' il NO a prescindere, senza nemmeno dare la possibilita' di uno screening. Ai tempi chiedemmo una porzione del obj_DB in modo da sgravare un po' di lavoro dalle spalle degli implementor, fare qualche media, e fare delle correzioni base alle procedure in quesione. Quello che sto cercando di dire, e' che se in termini di tempo una cosa non e' fattibile ad 1 persona, si puo' "commissionare" parte del lavoro a chi di tempo ne avrebbe. L'ultima parola e le modifiche finali spetterebbero comunque ai gestori, e i "coder a progetto" tornerebbero volentieri a fare i player una volta conclusa la nuova implementazione, che in fondo e' la stessa cosa che avviene per gli AB ad un livello piu' basso.

[Martinus]

Permettimi di precisare che il "tempo che merita" e "momento opportuno" sono 2 variabili dell'ottica admin.

Appunto... non abbiamo risorse per permetterci di assumere un coder a tempo pieno
Ritornando brevemente al discorso sul charge.
Le cose che sono cambiate tra allora che ti ho detto pisc e ora sono 2: l'ispirazione e il tempo.
Non e' detto che se hai un'idea buona questa venga tradotta automaticamente in un algoritmo buono sul codice. E' capitato che avevo un pomerigio libero, e mi e' pure venuta l'idea su come implementarla in 40 minuti... e l'ho fatta. Nulla di piu semplice. Ma quello che voglio dire e' non ostinatevi a chiedere che venga implementato ORA... Ho gia' detto che accettiamo suggerimenti, ma come, quando e se saranno implementati, lo decide lo staff.

[Mizar]

Permettimi di precisare che il "tempo che merita" e "momento opportuno" sono 2 variabili dell'ottica admin.

Appunto... non abbiamo risorse per permetterci di assumere un coder a tempo pieno
Ritornando brevemente al discorso sul charge.
Le cose che sono cambiate tra allora che ti ho detto pisc e ora sono 2: l'ispirazione e il tempo.
Non e' detto che se hai un'idea buona questa venga tradotta automaticamente in un algoritmo buono sul codice. E' capitato che avevo un pomerigio libero, e mi e' pure venuta l'idea su come implementarla in 40 minuti... e l'ho fatta. Nulla di piu semplice. Ma quello che voglio dire e' non ostinatevi a chiedere che venga implementato ORA... Ho gia' detto che accettiamo suggerimenti, ma come, quando e se saranno implementati, lo decide lo staff.

Parlaimm e nun c capaimm..
I coder non serve che li paghi, ci sono i player che sanno codare e sono sicuro che lo farebbero "aggratise" solo per il senso di contribuire all'evoluzione del mud.
Nessuno si ostina che venga implementato niente sedutastante, l'idea ha piu' di un anno di invecchiamento, e per quanto un vino migliori con l'invecchiamento, se non lo imbottigli ti diventa aceto. Per cui un primo passo potrebbe essere "bella questa idea, mumble mumble, chissa' se c'e' qualcuno disposto a farci i calcoli sopra in modo da strutturare il tutto? tanto se qualcosa non mi piace posso sempre ripartire da 0 o da 0+x.."
Secondo me e' pretenzioso voler necessariamente mettere il proprio TM sulle modifiche.
Lo stesso mud e' una confluenza di contributi, idee, pezzi di codice, aree, PG, mob, che nella fase finale vengono tarati su quello che e' il sistema di gioco da chi ha l'ultima parola, che si riserva di modificare e scremare per un miglior adattamento.
Se ci fosse da codare 100 algoritmi, 1 persona ci impiega diciamo 100 ore, 2 persone ce ne mettono 50 e cosi' via. I tempi di attesa si accorciano, la giocabilita' e il rinnovamento ne guadagnano e vissero tutti felici e contenti.
In sostanza, se l'unica problematica e' il tempo e l'ispirazione algoritmica, sono certo che qualcuno interno al mud che abbia tali requisiti si trova senza troppo sforzo ^^, piu' utile sarebbe capire se le idee possano portare effettive migliorie dal vostro punto di vista che avete lo "sguardo d'insieme".

[Martinus]

Per come la metti tu, sarebbe facile dare da fare un pezzo di 10 righe di codice ad un player qualsiasi, e poi implementarlo.
Ma intanto ci vuole un po' per capirlo il codice di TS, per usare le procedure e le varie cose... Per fare questo pero' bisogna averlo il codice... e per avere il codice devi avere la fiducia dello staff, cosi com'e' stato nei vari passaggi di mano degli implementor.
Il punto e che la fiducia non si puo chiedere, la si deve guadagnare, e non con le parole. In fondo hai ragione, solo che hai semplificato un po' troppo il percorso che c'e' tra l'idea e l'implementazione

[Nis]

Quoto in pieno Martinus innanzi tutto.
Del resto qua pare che non ci si capisca. Non ho detto che per fare una skill nuova ci vuole un anno, ho fatto un esempio generico. Quello che invece dico che non si puo' fare, o se si puo' fare devi cambiare proprio tutto, e' tanto quanto mi pare di aver capito dopo un paio di letture dei tuoi post.
Per quanto riguarda le proposte ce ne sono tante che sono state realizzate, anche dopo molto tempo.
Non capisco se prendi solo le frasi che ti interessano apposta per contestare, oppure non riesci a capire proprio il contenuto dell'intero messaggio.
Ma poi mi chiedo come fai a dire che una determinata cosa si fa in 2 ore quando tu stesso affermi di non saper programmare, ne' tantomeno sai come e' fatto il codice.
Il problema e' che nonostante ho detto che il discorso delle skill a xp a me piace, si continua a ribattere non so per che cosa.
Certo, non si fara' domani, ma e' un idea da tenere in considerazione.

[Mizar]

In fondo hai ragione

Svengo e mi commuovo..
anzi mi commuovo e svengo..
Cavolate a parte, non e' che voglia necessariamente polemizzare visto che la storia ha dimostrato che il 90% delle mie analisi offre materiale da implementazione. Semplicemente volevo far notare che non c'e' un assoluto bisogno del codice per scriptare qualche algoritmo. Non lo sto chiedendo e anche se me lo offriste non saprei che farci. Io contribuisco in altro modo, ci metto ideee, tempo per i test lato_player, ma non sono un coder.
Io non ne sono capace ma chi ha dimestichezza puo' farlo e voi avreste solo da tradurre o riadattare il lavoro perche' il grosso e' stato fatto.
Se vai a guardare il thread dei save e' la riprova che qualcuno puo' brainstormare, qualcuno scripta e qualcuno approva. Il tutto con notevole risparmio di tempo, incremento della soddisfazione e un generale brindisi al nuovo traguardo evolutivo, senza necessariamente perdersi "pezzi" per strada a causa dei lunghi tempi di scrittura/test/implementazione o "incomprensioni" sul projecting (tanto per citarne un altro, il compose e i socket l'ho portati io, e zeppo l'ha codati).

Quello che invece dico che non si puo' fare, o se si puo' fare devi cambiare proprio tutto, e' tanto quanto mi pare di aver capito dopo un paio di letture dei tuoi post.

Perdonami ma sta frase proprio non la capisco..

Per quanto riguarda le proposte ce ne sono tante che sono state realizzate, anche dopo molto tempo.

E' proprio la tempistica che cerco di accorciare, fermo restando l'approvazione "sulla carta" della modifica o della nuova skill/build/gameplay.

Non capisco se prendi solo le frasi che ti interessano apposta per contestare, oppure non riesci a capire proprio il contenuto dell'intero messaggio.

Un po' entrambe, ma piu' verosimilmente perche' in questa maniera riesco a essere meno confusionario e piu' incisivo sui vari concetti espressi.

Ma poi mi chiedo come fai a dire che una determinata cosa si fa in 2 ore quando tu stesso affermi di non saper programmare, ne' tantomeno sai come e' fatto il codice.

2 ore e' come il tuo "anno tanto per dire" di inizio post (poi non dire che sono io lo gnorri), semplicemente le skill (non l'intero sistema di "frammentazione") incidono su pochissimi campi, la scrittura dell'algoritmo e' breve, mentre il ragionare sul bilanciamento e' cio' che allunga i tempi, e se ci sono piu' persone a risolvere l'enigma la soluzione arriva prima, credo.

Il problema e' che nonostante ho detto che il discorso delle skill a xp a me piace, si continua a ribattere non so per che cosa.
Certo, non si fara' domani, ma e' un idea da tenere in considerazione.

Beh non prenderla sul personale, ma e' fondamentalmente la stessa risposta che e' stata data, dopo tanti tira e molla, sulla questione "frammentazione". Bella ma troppo lunga e complessa da attuare. Solo che torniamo al punto di partenza, non si tiene in considerazione per la questione tempo/sforzo seppur interessante. Accantonarla senza dare possibilita' A NESSUNO di svilupparla ci porta alla lentezza di evoluzione e alla perdita di utenza che poteva essere trattenuta e/o acquisita tramite l'innovativita' del sistema di gioco.
Mi spiace solo che le mie parole vengano prese sistematicamente come attacchi al potere quando il piu' delle volte (controllatevi tutti i post di brainstorming) danno le idee fondanti alle svolte muddistiche.
Quanto e' frustrante essere un genio incompreso

[Nis]

E' normale che non capisci cosa scrivo se quoti solo la frase da contestare, e magari non ti vai a rileggere quello di cui si e' discusso prima. Non capisco per cosa ci voglia cosi' tanto tempo, per creare le nuove skill? ma scusa perche' ancora non lo scrivi questo algoritmo? mica devi avere l'approvazione di qualcuno per scrivere un algoritmo...

[Mizar]

Non quoto solo la frase da contestare bensi' una frase che leggendola non ha un senso compiuto (a mio parere) quindi piu' di chiedere spiegazioni o dire che non l'ho capita non so davvero che fare..
"Tanto tempo per" e' un concetto relativo che dipende, come abbiamo convenuto prima, dalla complessita' della modifica, dalla disponibilita' dei coder e dalla volonta' di attuare la modifica, qualunque essa sia.
La skill di per se' credo ci voglia poco a scriverla (algoritmo), un po' piu' di tempo a testarla (bilanciamento e debug), mentre l'implementazione vera e propria consiste nel linkaggio della modifica e reboot del sistema (2minuti).
Non scrivo l'algoritmo perche' non so farlo, non conosco ne' il C ne' il C++ ne' il VB, ne' il Java, PHP, ASP, HTML. Zero, nada.
L'approvazione non serve per scrivere l'algoritmo, ma per fare qualcosa di "ponderato" ai tempi servivano delle medie degli apply degli oggetti per non sparare formule a caso.
Il mio obj_DB e' molto limitato e deriva dagli ident importati sul Manager di Draman. Avessi avuto una porzione ordinata del vero database di oggetti caricato su mud, avrei potuto fare delle medie un pochino piu' "reali" che mi permettano di valutare quanto i risultati di una formula si avvicinino all'effetto voluto. Se io ad esempio mi aspetto un valore medio 10 o reputo che il valore medio debba essere 10, e inserendo i dati mi esce fuori 25 posso agire in 2 modi, provo a campionare i risultati con dati differenti (che non ho) oppure cerco di lavorare sulla formula perche' mi tiri fuori numeri intorno al 10.
Probabilmente parlo senza cognizione di causa, ma quando chiesi alle persone interessate a scrivere tali procedure di calcolo, mi dissero che avrebbero avuto bisogno di dati concreti da cui partire. In modo da avere valori medi, che poi sarebbero serviti per sviluppare ultiori formule e cosi' via..
Ai tempi volevo determinare un corretto PWP, che non fosse la quantita' di sigilli spesi sull'eq, bensi' rispecchiasse la reale capacita' di sopravvivenza o di efficacia/incisivita' contro i mob o ai fini della sopravvivenza del gruppo/singolo player.
Ora come ora non ho intenzione di stare a ritirare fuori tutto il discorso perche' tanto non servirebbe a nulla. Se a qualcuno interessa puo' contattarmi altrimenti amen, continuo a proporre quello che mi viene in mente, ce possa impattare al minimo l'attuale sistema di gioco.
Se poi non sta bene manco quello non so veramente che dire..
se non: http://www.youtube.com/watch?v=WlHI9SYGNi8

[Nis]

ma come, non eri tu il genio incompreso?
non so perche' ho l'impressione tu non sappia nemmeno cosa sia un algoritmo... non so nemmeno su quale base di conoscenze parli, dato che a sentirti sembri un espertone di programmazione:P

ma allora detta in breve quale sarebbe la novita' che proponi? dare il codice a chiunque per fare le nuove procedure e poi testarle e correggerle? ti ha gia risposto Martinus, e non quotare solo la frase che ti piace.

Poi non ho capito ora a che ti serve il DB degli oggetti.
Comunque bellissimo il video:D

[Mizar]

a volte mi domando se parlo cosi' astrusamente..
ho scritto che se qualcuno e' interessato cerco di spiegarmi altrimenti mi limito a postare cose di ( a mio parere) semplice implementazione.
La definizione di wikipedia e': "Intuitivamente, un algoritmo si può definire come un procedimento che consente di ottenere un risultato atteso eseguendo, in un determinato ordine, un insieme di passi semplici corrispondenti ad azioni scelte solitamente da un insieme finito."
Non mi pare di aver cosi' mal interpretato il significato.

Non propongo assolutamente di dare il codice a chiunque, bensi' far costruire separatamente in un linguaggio "compatibile" a quello del codice di TS2 piccoli pezzi di procedure.
Quando per esempio un AB propone un'area cosa succede?
Gli si chiede di farlo sulla carta, poi passarlo su eleutheria/creator, dopo ci sta l'implementazione dei mob, poi il bilanciamento, poi il testing e infine il linkaggio finale. Riporta lo stesso modus operandi sulle procedure di calcolo e hai ottenuto il risultato da me auspicato. "Pezzi di codice su commissione".

Il DB oggetti ora come ora non mi serve. e' passato troppo tempo e la mia idea si e' "acetata" (riferendosi al paragone del vino di qualche post fa). Mi (a me e al coder di supporto) sarebbe servito per fare medie per livello per range di eq in modo da partire a sistemare il pwp per poi riaggiustare tutto il sistema di modificatori per il calcolo del coefficiente di difficolta' dei mob, assegnazione dei giusti drop_rate e via dicendo. Ma e' acqua passata. Il tutto senza nessun obbligo di implementazione ma per fare il tutto avremmoa vuto bisogno del Db oggetti visto che i cap verticali (listino edit, train, funzioni_spell e compagnia cantante)li avevamo gia' (bastava consultare gli help ingame).

Mariotide e' un mito!!

[Nis]

C'e' una bella differenza dal fare un area e poi linkarla e fare una procedura e poi linkarla.
Per fare l'area ti basta l'editor, fai le stanze, mob e oggetti come vuoi, si linka ed e' fatta. Per fare una qualunque procedura devi conoscere il codice, le funzioni, quello che puoi fare e che non puoi fare, e come puoi farlo... cioe' non e' che tu scrivi una procedura per una skill in C, la linki al mud e funziona, ma ovviamente per capire certe cose serve conoscere il codice:P

[Mizar]

vabe' proprio non riesco ad esprimermi in modo anche solo lontanamente comprensibile..
(anche se almeno 1 altra persona ha capito quello che dicevo, e questo mi conforta)

E' ovvio che ci sono variabili e procedure precedentemente definite nel codice del mud.
E' ovvio che non avendole sotto mano si possano fare solo richiami del tipo: procedura_che_nel_mud_fa_questo_ma_non_posso_scriverla_qui_perche'_non_ho_il_codice
oppure
variabile_che_nel_mud_corrisponde_a_xxxx.

Non pretendo mica di mettere una sedia con 4 ruote su un binario e chiamarla treno!!!

Ma, credo, e sottilineo credo, qualcosa si puo' scrivere comunque.
Una bozza di struttura, di funzionamento, di funzione di calcolo, di quellarobachefannoicoder, che aiuti a sgrossare il lavoro di implementazione.
La revisione finale DEVE esserci. Un adattamento ai parametri dell'attuale sistema e' NECESSARIO.
Siccome ora tutto il lavoro grava su 1 persona, ho semplicemente proposto di smembrare il problema in problemi piu' piccoli e magari piu' semplici da "risolvere".
Mica scrivo arabo eh!
Non volete distribuire il codice? AMEN!!!
Volete fare tutto il lavoraccio voi? AMEN!!!
I tempi si allungano? AMEN!!!
Diventeremo tutti vecchi senza possibilita' di praccare age? RIP!!!
Spero almeno di farmi presto sta cavolo di Mastercard..

[Nis]

E' ovvio che ci sono variabili e procedure precedentemente definite nel codice del mud.
E' ovvio che non avendole sotto mano si possano fare solo richiami del tipo: procedura_che_nel_mud_fa_questo_ma_non_posso_scriverla_qui_perche'_non_ho_il_codice
oppure
variabile_che_nel_mud_corrisponde_a_xxxx.

Scusa eh, ma se non conosci il codice chi ti dice che quella procedura che fa questo e quello esista e non e' da implementare? non e' detto che solo perche' nel mud vedi una cosa che fa "questo" allora ci sia una funzione per far fare "questo" ad un'altra cosa. Sto parlando in generale ovviamente.
Scrivere le bozze come dici tu, non ci vuole niente, sapessi quante ne ho io, il problema e' quando poi ti devi arrangiare con quello che il codice permette di fare, oppure scrivere una nuova funzione che ti permette di farlo.

[Martinus]

Rispondo da coder....

E' piu facile prendere un'idea e codarla, che prendere una "bozza" e riadattarla.
Questo non vale solo per il mud... vale per il coding in generale, puoi chiedere nei forum se vuoi
Unica eccezione, i snippet... che sono delle righe di codice che fanno qualcosa di semplice... e anche li c'e' un codice pronto, con le procedure del codice intero dove stava prima... e non una paginetta con le "procedura che fa questo".