This repository has been archived by the owner on Nov 9, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 2
/
releases.txt
9522 lines (7925 loc) · 424 KB
/
releases.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
================================================================================
Rella 115
================================================================================
Rella 114
================================================================================
Rella 113
- Aggiunte le opzioni di config.ini:
dam_plr_vs_plr = 100
dam_plr_vs_mob = 100
dam_plr_vs_item = 100
dam_mob_vs_plr = 100
dam_mob_vs_mob = 100
dam_mob_vs_item = 100
dam_item_vs_plr = 100
dam_item_vs_mob = 100
dam_item_vs_item = 100
Queste opzioni di config sono regolatori in percentuale del danno
attaccante/vittima, quindi si può impostare
dam_plr_vs_mob = 90
per diminuire del 10% il danno degli attacchi dei pg nei confronti dei mob,
mentre se invece si cambia l'opzione
dam_mob_vs_plr = 110
viene aumentato del 10% il danno degli attacchi dei mob nei confronti dei pg.
Tutte opzioni che possono essere utilizzate per contrastare l'attuale
temporaneo e bacoso disequilibrio nel combat.
- Creato un nuovo miml: season
esempio:
Vedi una radura #season is SEASON.WINTER#ricoperta di neve#rigogliosa#.
In inverno produrrà l'output:
Vedi una radura ricoperta di neve.
mentre nelle altre stagioni:
Vedi una radura rigogliosa.
Testato: funziona!
- Sono riuscito a convertire la creazione della pagina elements_list.htm
con tutte le entità html al posto degli accenti non vi dovrebbero quindi
essere discrepanze per la conversione delle codifiche e robe varie.
- Aggiunte le etichette di behaviour
Look:
Listen:
Smell:
Touch:
Taste:
Intuition:
Servono a far inviare i rispettivi comandi senza alcun argomento.
Testato: funziona!
- Ho convertito tutti i trigger relativi ai social in questa maniera:
Tutti i trigger che devono scattare su colui che esegue il social sono
formati come questo esempio:
before_active_smile
after_active_smile
Tutti gli altri trigger relativi ai social sono formati come questo esempio:
before_passive_smile
after_passive_smile
Questi secondi sono i trigger che scattano su coloro che "subiscono" lo
smile, cioè che vedono il social.
Testato su un before_passive_smile, funziona!
- Aggiunta l'etichetta FollowEntityComeMessage alla struttura Walker, funziona
come FollowEntityGoMessage ma con un tag in più a quest'ultima:
%followers che è la lista di uno o più nomi delle entità che stanno
inseguendo entity
Il messaggio è quello che entità guida leggerà dopo aver ricevuto il look
dello spostamento per avere conferma visiva delle entità che la stanno
seguendo.
Da aggiornare quindi il manuale per tutte queste cosette.
L'ho testato e funziona, all'inizio avevo inserito l'etichetta nel Walker
del bidone del caldarrostaio, ma mi sbagliavo, non bisogna inserirla nel
Walker di chi segue, ma del seguito, quindi l'ho inserita in un Walker di me
stesso e mi son fatto seguire da Wisdul; magari indicare questo aspetto
dell'etichetta nel manuale.
- Non so se sia il caso di aggiungere nel manuale che è stato inserito il tag
%material per gli oggetti rip... mh?
A discrezione tua.
Il tutto è descritto meglio qui: http://aarit.wikidot.com/bug:112-distruggi-item
- Bisogna cambiare tutte le etichette Icon in questa maniera:
da
Icon: icon/
a
Icon: icons/
Ovvero cambiare la folder dal singola al plurale.
- Ho aggiunto ai materiali le caratteristiche di stato e di durezza, il tutto
nel file MATERIAL.py, esse serviranno per gestire caratteristiche fisiche
dei materiali
- Ho rifatto il comando destroy in maniera totale, ora funziona più o meno
come il dig, ovvero quando il comando viene inviato mano a mano l'oggetto
viene distrutto e vengono inviati dei messaggi dell'azione in progresso.
Il comando destroy funziona sulle entità del proprio inventario e anche su
tutte le altre al di fuori dell'entità stessa, quindi anche sulle porte!
Se si crea una porta di marzapane chiusa a chiave (senza chiave esistente)
la si può buttare già distruggendola, visto che è fatta di materiale leggero.
Il comando come il dig può essere interrotto digitando un altro comando che
esegue un'azione concreta, come ad esempio il get.
Visto dall'esterno non è che il comando destroy sia cambiato molto, al suo
interno invece è molto differente, non fa alcun riferimento al sistema di
combat tranne che per i messaggi di danno.
Ho fatto un'ulteriore modifica al codice all'ultima ora che permette di
distruggere item con life minore dell'hardness del materiale con cui è formata
in un round solo, quindi subito.
Il comando destroy dà 1 px per ogni oggetto distrutto, poca roba (aumentabile
al limite), ma magari serve ad incentivo come sistema di pulizia di entità
inutili.
Testato.
- Aggiunta, per i soli item, la struttura Destroy, essa è formata dalle seguenti
etichette, tutte opzionali:
Destroy:
Comment: # Commento
StartDestroyEntity: # Messaggio inviato all'entità che sta iniziando a distruggere qualcosa
StartDestroyOthers: # Messaggio inviato a tutti coloro che possono vedere l'azione dell'inizio della rottura
StartDestroyTarget: # Messaggio inviato all'entità su cui si ha iniziato l'azione di distruggere
ContinueDestroyEntity: # Messaggio inviato all'entità mentre sta continuando a distruggere qualcosa
ContinueDestroyOthers: # Messaggio inviato a tutti coloro che vedono l'azione continuativa della rottura
ContinueDestroyTarget: # Messaggio inviato all'entità che sta venendo in continuazione rotta
EndDestroyEntity: # Messaggio inviato all'entità mentre sta continuando a distruggere qualcosa
EndDestroyOthers: # Messaggio inviato a tutti coloro che vedono l'azione continuativa della rottura
EndDestroyTarget: # Messaggio inviato all'entità che sta venendo in continuazione rotta
StopDestroyEntity: # Messaggio inviato all'entità che ha fermato l'atto di distruggere qualcosa
StopDestroyOthers: # Messaggio inviato a tutti coloro che vedono l'entità fermarsi nell'atto di distruggere qualcosa
StopDestroyTarget: # Messaggio inviato all'entità su cui viene fermato l'atto di distruggerla
End
Sono messaggi che vengono visualizzati tramite l'utilizzo del comando Destroy,
in particolare i primi tre vengono visualizzati se uno invia il comando
destroy 3 mela
per dire di distruggere 3 mele, ma nell'inventario ve ne sono solo 2.
Per tutti i messaggi ci sono questi tag speciali:
%verb = rompere/distruggere
%verb_you2 = romperti/distruggerti
%verb_you = rompi/distruggi
%verb_it = rompe/distrugge
Testato
- Tutte le strutture di etichetta dal nome Materials devono essere rinominate
in MaterialPercentages.
- Aggiunta la FLAG.CAN_DAMAGING da aggiungere a tutti quegli oggetti a cui si
vuole dare la possibilità d'utilizzare il comando destroy e il comando kill
(attualmente quest'ultimo non è stato ancora attivato gli oggetti, la cosa
rimarrà in attesa fino alla riscrittura totale del sistema di combattimento,
tuttavia nonostante l'incompletezza è voluto che la flag venga impostata
comunque pensando al futuro).
È una flag pensata per oggetti animati che debbano in qualche modo eseguire
delle azioni di combattimento, magari per delle quest o dei gamescript.
Testato.
- Ora è possibile guadagnare px esplorando
Si guadagna +(livello dell'area * 100) per ogni area nuova scoperta
Si guadagna +(livello dell'area / 2) per ogni stanza nuova scoperta
È quasi ovvio il fatto di tenere lontano dalle aree newbie quelle di 200
livello, oltre al fatto che vi dovrebbero essere mostri impossibili da battere
dai newbie, un player novello che entra in un'area di livello 200 la prima
volta riceve 20000 di esperienza, un bel boost iniziale!
Di certo raggiungere un'area del genere ad inizio livelli è una buona strategia.
Testato.
- Ora è possibile guadagnare px anche leggendo.
La prima volta che si leggerà un book verranno guadagnati
(livello del libro * 10) px, non ho osato dare di più per via del fatto che
sarebbe facilmente abusato prendendo libri di livello altissimo e dati in
pasto ai newbie che guadagnerebbero di botto un massimo di 2000px.
Testato.
- Ora è possibile guadagnare px anche scavando.
La prima volta che si scaverà in una locazione verranno donati un quantitativo
di esperienza pari al livello dell'area.
Testato.
- Inoltre è possibile guadagnare px mangiando, bevendo (comando quest'ultimo
non ancora concluso in attesa degli affect) o possedendo (tramite get o give
ricevuto) per un guadagno di px uguale al livello dell'entità mangiata,
bevuta o avuta nel proprio inventario per la prima volta.
Testato tutto tranne il comando drink data la sua natura incompleta.
- E ancora! Si guadagnano px sulle entità e le stanze che vengono esaminate
la prima volta con un qualsiasi comando sensoriale che non sia il look e
che abbiamo una descrizione (extra e non) sensoriale valida relativa al
comando utilizzato.
+(livello delle entità) per le entità su cui è stato usato un senso per la
prima volta oppure
+(livello dell'area) per le room su cui è stato usato un senso la prima volta
Testato.
- Si guadagna px anche seminando o piantando una entità, la prima volta che
questa verrà piantata verranno guadagnati livello_entità * 10 px
Stessa cosa per i comandi di open, unlock e unbolt, enter, sell, buy ma con
moltiplicatori di px rispettivamente di 10, 50 e 10, 100, 10 e 10
Testati tutti.
- Aggiunta l'opzione di config exp_modifier nella sezione [GAME], serve ad
impostare quanto in percentuale tutti i guadagni positivi di esperienza
andranno modificati, impostato a 100, come di default, i valori donati
rimarranno tali quali.
Testato.
- Ora con gli oggetti layarable c'è un meccanismo maggiormente intelligente
di remove e wear, più ordinato.
Testato.
- Ora i negozianti non dovranno avere del denaro sotto forma di entità reale
per poter comprare gli oggetti da parte dei giocatori.
Siamo peggio della Banca Europea! Unlimited!
Testato.
- Scavando c'è una probabilità del 10% di trovare (se non esiste nulla di
sotterrato) un oggetto qualsiasi dell'area rip, oppure un oggetto con flag
RANDOMIZABLE, oppure una entità ENTITYPE.SEED del database, oppure una
qualsiasi moneta razziale (quelle impostate nel file RACE.py);
per le monete viene anche inserita una quantità inversamente proporzionale
al valore della moneta stessa
da 1 a 1000 monete di rame
da 1 a 100 monete d'argento
da 1 a 10 monete d'oro
1 moneta di mithril
Tengo a sottolineare inoltre che è possibile impostare la flag
FLAG.RANDOMIZABLE
anche sui mob, così da poter far apparire scavando animaletti come serpenti
e topi.
Testato parzialmente, non mi è mai capitato di trovare delle monete.
- Ho osservato che il nome in un file dat è impostato così:
Name: Un [sandybrown]Fradiciume[close]
So che son stato io a dire di fare così, ma mi sa che è meglio convertirlo
in una di queste quattro forme:
Name: un [sandybrown]Fradiciume[close]
Name: un [sandybrown]fradiciume[close]
Name: il [sandybrown]Fradiciume[close]
Name: il [sandybrown]fradiciume[close]
Ovvero per l'etichetta Name utilizzare gli articoli in minuscolo, poi a
volte per nomi così "impersonali" come fradiciume utilizzare il minuscolo,
alternativamente utilizzare al posto degli articoli indeterminativi gli
articoli determinativi
Da aggiornare nel manuale.
- Anche riguardo le Short, ShortNight, Name delle descrizioni ho aggiunto dei
messaggi che avvertono se queste etichette sono iniziate con articoli, o
simili particelle, maiuscole; e inoltre viene avvertito se è stato aggiunto
un punto finale.
Questo sia per le entità che per le room.
Da aggiornare nel manuale queste particolarità se non vengono dette.
- D'ora in poi anche le etichette di Name, Short e ShortNight supportano i
tag di act, quindi la sabbietta di entropy viene visualizzata correttamente.
Da aggiornare il manuale.
Testato.
- Ora entità con short aventi tag html vengono ripulite correttamente durante
la creazione delle parole chiave, altrimenti i tag html rimanevano nella
keyword e l'utente non le poteva utilizzare
Testato, funziona
- La colorazione tramite span html e colori esadecimali (che utilizzano il
carattere #) facevano casino con l'uso dei miml e l'output si incasinava.
Ora tutto a posto.
Testato, funziona
================================================================================
Rella 112
06/08/12
- Ho aggiunto il parametro finale behavioured all'interfacciamento dei seguenti
trigger:
--> tutti i trigger dei canali
--> tutti i trigger di movimento
--> tutti i trigger dei sensi
--> tutti i trigger relativi ai comandi (cioè trigger relativi direttamente
ad un comando in particolare, esempio: before_buy, before_buying,
before_bought)
Per esempio, un trigger qualsiasi:
Da:
def before_emote(entity, argument):
def after_emote(entity, argument):
a:
def before_emote(entity, argument, behavioured):
def after_emote(entity, argument, behavioured):
Il parametro behavioured può essere utilizzato in maniera strategica: può
servire ad attivare il trigger solo se è stato eseguito in maniera
intelligente (player, force di un admin o futuro sistema di scheduler) e
non ripetuta roboticamente come viene fatto dai behaviour.
Poiché il parametro viene inserito un po' dappertutto forse è il caso di
descriverlo una tantum all'inizio nella pagina del manuale apposita.
Bisogna passarsi tutti i trigger dei gamescript ed aggiungere il parametro
behavioured in coda a tutti gli altri.
- Aggiunti i trigger before/after_enter_in_game e before/after_exit_from_game
tutti e due funzionano solo sui player ed hanno questo interfacciamento tipo:
def before_enter_in_game(player):
idem per gli altri 3
Attenzione: sono trigger da usare solo quando esattamente sapete cosa state
facendo, in particolare non giocate con la from_location e to_location in
questi trigger o succedono macelli.
- Per i gamescript una buona notizia, ho aggiunto il metodo
if proto.has_reached_max_global_quantity():
che andrebbe della riga di codice:
if proto.max_global_quantity != 0 and proto.current_global_quantity
>= proto.max_global_quantity:
sarebbero da modificare gli script a riguardo, per avere una migliore
leggibilità del codice
- Mi servirebbero dei test sulla flag di act $i
il cui contenuto sia FLAG.NO_LOOK_LIST e/o con la
FLAG.INTERACTABLE_FROM_OUTSIDE
Ricordo che:
$i
# Ritorna i nomi in elenco delle entità visibili in una locazione.
# Nonostante la $i sia minuscola fa riferimento sempre a target.
Alla stessa maniera mi domando come si comporti la numerazione
1.xxx
2.xxx
3.xxx
con contenuti al cui interno vi sono entità NO_LOOK_LIST o
INTERACTABLE_FROM_OUTSIDE
- Ecco la lista di tutti gli act, ad uso e consumo della pagina web del manuale
da creare:
Il più delle volte i messaggi di act hanno un soggetto: colui che sta facendo
l'azione.
Tutti i tag minuscoli, se non dichiarato altrimenti, sono relativi a colui
che sta compiendo l'azione: il soggetto, nel caso più tipico il giocatore.
Tutti i tag maiuscoli, se non dichiarato altrimenti, sono relativi all'oggetto
relativo all'azione (per esempio il mob relativo ad un comando di
azione di kick)
Di seguito ci sono gli act di tag utilizzati per la gestione
grammaticale delle frasi:
$o e $O: ritorna il carattere grammaticale 'o' oppure 'a' a seconda
del sesso dell'entità.
$lui e $LUI: ritorna lui/lei
$gli e $GLI: ritorna gli/le
Di seguito ci sono gli act di tag utilizzati per descrivere le parti
del corpo delle entità, variano a seconda della razza:
$hands e $HANDS: ritorna la stringa descrivente le mani dell'entità
$hand1 e $HAND1: ritorna la stringa descrivente la mano principale dell'entità
$hand2 e $HAND2: ritorna la stringa descrivente la mano secondaria dell'entità
$hand e $HAND: ritorna la stringa descrivente una generica mano dell'entità
$feet e $FEET: ritorna la stringa descrivente i piedi dell'entità
$foot e $FOOT: ritorna la stringa descrivente un generica piede dell'entità
$skin e $SKIN: ritorna la stringa descrivente la pelle dell'entità
$tongue e $TONGUE: ritorna la stringa descrivente la lingua dell'entità
Di seguito ci sono gli act di tag utilizzati per la traduzione dei comandi:
$t: Traduce l'input scritto di seguito al tag nella lingua preferita
per l'invio dei comandi dell'entità, per esempio:
$tlook
tradurrà 'guarda' per coloro che usano i comandi in italiano, altrimenti look
$T funziona come $T ma non invia il colore di default utilizzato per i
comandi lasciando la possilità di colorare la traduzione come si
vuole.
Di seguito ci sono gli act di tag relativi al calendario gdr del gioco:
$minute: ritorna l'attuale minuto
$hour: ritorna l'attuale ora
$day_week: ritorna l'attuale nome del giorno della settimana
$day: ritorna l'attuale giorno del mese
$month: ritorna l'attuale nome del mese
$season: ritorna il nome dell'attuale stagione
$year: ritorna l'attuale anno
Di seguito ci sono gli act di tag utilizzati per ricavare i nomi delle entità:
$n: ritorna il nome dell'entità che esegue l'azione
$N: ritorna il nome dell'entità che subisce l'azione
$a: ritorna il nome della prima entità ausiliaria del metodo di act
$A: ritorna il nome della seconda entità ausiliaria del metodo di act
Spiego meglio con un esempio il funzionamento del metodo act:
entity.act("Hai dato un calcio a $N mentre $a e $A stavano a
guardare!", TO.ENTITY, vittima, compagno1, compagno2)
entity.act("$n ti ha dato un calcio mentre $a e $A stavano a
guardare!", TO.TARGET, vittima, compagno1, compagno2)
entity.act("$n ha dato un calcio a $N mentre $a e $A stavano a
guardare!", TO.OTHERS, vittima, compagno1, compagno2)
Concettualmente il metodo di act funziona in questo modo:
entità_$n.act("messaggio con i tag di act",
TO.ENTITY|TO.TARGET|TO.OTHERS, entità_$N, entità_$a, entità_$A)
Solitamente $a e $A non vengono utilizzati, nei messaggi di act più
semplici, con un'azione ma senza la vittima che la subisce non vi è
neppure il bisogno di inserire $N e neppure del messaggio a TO.TARGET:
entity.act("Sorridi sornione...", TO.ENTITY)
entity.act("$n sorride sornione...", TO.OTHERS)
C'è da dire inoltre che i tag ausiliari di $a e $A possono passare
anche una stringa descrivente qualche cosa:
entity.act("miagoli verso $a...", TO.ENTITY, None, str(DIR.NORTH))
entity.act("$n miagola verso $a...", TO.OTHERS, None, str(DIR.NORTH))
Altri tag di act sono:
$l e $L: ritorna il nome dell'attuale locazione in cui si trova
rispettivamente l'entità che esegue l'azione e l'entità che la subisce
$p e $P: ritorna il nome della locazione precedente in cui si trovava
rispettivamente l'entità che esegue l'azione e l'entità che la subisce
$k e $K: ritorna la parola chiave relativa rispettivamente all'entità
che esegue l'azione e all'entità che la subisce
Attenzione a questi due tag di act che non funzionano sull'entità che
esegue l'azione ma sull'obiettivo dell'azione
$i: elenca le entità contenute nell'obiettivo della stringa di act
$I: visualizza il nome dell'entità di peso maggiore nell'obiettivo
della stringa di act
- Bisogna sostituire questi tag di act nei data:
$c -> $l
$C -> $L
$w -> $p
$W -> $P
Attenzione che la prima è una elle minuscola.
Fai attenzione durante la sostituzione che ho visto che ci sono parole
che iniziano con $c che non sono però dei tag di act.
- Ho creato il comando use, funziona come "sinonimo generico" di alcuni comandi:
close
drink
eat
enter
open
read
remove
seed
plant (questo è un comando che ho aggiunto poi)
unlock
unbolt
wear
I comandi si attivano controllando la tipologia d'entità e il suo
possibile stato
Il comando use con il read è stato semplificato, ovvero non si può leggere
entità dentro altre entità come invece fa il read, ma solo entità che si trovano
addosso o per terra.
- Anche il comando use, come quasi tutti quanti ormai, ha i suoi bei trigger:
def before_use(entity, target, argument, behavioured):
def after_use(entity, target, argument, behavioured):
def before_used(entity, target, argument, behavioured):
def after_used(entity, target, argument, behavioured):
I primi due si attivano sull'entità che ha eseguito il comando, gli altri due
invece si attivano sull'entità utilizzata.
entity è l'entità che esegue il comando
target è l'entità utilizzata
argument è l'eventuale argomento rimanente del comando
Bisogna aggiornare il manuale a riguardo
- Ho cambiato tutti i trigger di kill, attack e destroy, ora gli unici trigger
che rimangono sono quelli di kill e killed:
before_kill(entity, target, attack, destroy, behavioured)
after_kill(entity, target, attack, destroy, behavioured)
before_killed(entity, target, attack, destroy, behavioured)
after_killed(entity, target, attack, destroy, behavioured)
i primi 2 scattano sull'entità che sta eseguendo o ha eseguito il comando
i secondi 2 scattano sull'entità che lo sta subendo o lo ha subito
entity è colui che sta killando
target è colui che subisce il kill
attack è un valore booleano che indica se si sta killando tramite comando attack
destroy è un valore booleano che indica se si sta killando tramite
comando destroy
behavioured funziona come per tutti gli altri: indica se il comando è
stato inviato tramite qualche tipo di behaviour
Concettualmente tutti questi trigger funzionano come il trigger dell'eat, così
da diminuire il numero di trigger da inserire con la stessa tipologia di codice
da copia e incolla
Bisogna modificare i gamescript ed aggiornare il manuale
- Corretti i trigger di read, che avevano un baco relativamente alla lettura
delle extra, come da punto
http://aarit.wikidot.com/ask:110-trigger-read-extra
ora il loro interfacciamento è:
def before_read(entity, target, output, detail):
in pratica ho invertito l'ordine di output e detail
così anche gli altri relativi al read.
- Riscritti i trigger di wake:
def before_wake(entity, target, behavioured):
def after_wake(entity, target, behavioured):
def before_waked(entity, target, behavioured):
def after_waked(entity, target, behavioured):
I primi due si attivano su chi ha eseguito il comando.
I secondi due si attivano su chi lo sta subendo, non si attivano se il
comando è stato eseguito su se stessi.
entity è colui che esegue il comando.
target colui che lo subisce.
- Ho aggiunto il trigger sul comando date, l'interfacciamento è il seguente:
def before_date(entity, behavioured):
def after_date(entity, behavioured):
entity è colui che ha digitato il comando.
- Ho aggiunto il trigger sul comando equipment, l'interfacciamento è
il seguente:
def before_equipment(entity, target, behavioured):
def after_equipment(entity, target, behavioured):
entity è colui che ha digitato il comando
target è l'entità con l'equipaggiamento da visualizzare, se entity ha digitato
il comando equipment senza argomenti, per vedere il proprio equipaggiamento,
target viene passato a None
- Ho aggiunto i trigger di inventory che hanno lo stesso interfacciamento di
quelli dell'equipment
- I trigger relativi al list erano sbagliati, questi i corretti:
before_list(entity, dealer, behavioured):
after_list(entity, dealer, behavioured):
before_listed(entity, dealer, behavioured):
after_listed(entity, dealer, behavioured):
I primi due si attivano su chi ha eseguito il comando.
I secondi due si attivano sul negoziante.
entity è colui che ha digitato il comando.
dealer è il negoziante.
- Ho aggiunto i trigger sul comando money (mi sembra di averli tolti
nell'ultima release, cough cough, ho una consistenza nelle modifiche
che è allarmante)
def before_money(entity, behavioured):
def after_money(entity, behavioured):
entity è colui che ha digitato il comando
(Sì non è un granché come trigger, ma magari vi viene il pallino di usarlo)
- Ho cambiato nome al parametro di interfacciamento from_where dei trigger di
remove in location
- In tutti i trigger dei sensi, del look (e del read, ma questo l'ho già detto
sopra) ho scambiato l'ordine dei parametri descr e detail.
- Adesso i trigger a livello di area dovrebbero funzionare.
In sostanza basta creare un file py nella cartella relativa ai dati di area,
con lo stesso nome del codice dell'area da triggerare, ed inserirvi i
trigger che si vuol far funzionare a livello di area.
Da aggiungere nel manuale.
- Aggiunta un'etichetta alla struttura Walker:
RunnedVerbIt:
che sarebbe il corrispondente relativo alla corsa di ComeVerbIt
- Ho implementato un sistema che visualizza il personaggio in corsa, invece
che in camminata, capita quando questi stia inviando comandi di movimento
con una certa rapidità l'uno dall'altro.
- Aggiunta l'opzione di config running_step_time nella sezione GAME che deve
essere impostata a 0.5
Indica i secondi o i centesimi di secondo minimi tra un comando di movimento
ed un altro per considerarlo come corsa.
È un valore eventualmente da tarare empiricamente, praticamente fa capo alla
domanda: quando la rapidità dell'invio ripetuto di una direzione si può
considerare corsa nel mud?
- Ho mantenuto cmq il check dell'owner nel comando refresh, è meglio che faccia
meno danni possibile.
Se ne è parlato qui:
http://aarit.wikidot.com/ask:111-command-refresh
- Ho cambiato il nome della FLAG.NO_CORPSE in FLAG.NO_REMAINS
Questo perché anche gli oggetti ora hanno un sistema simile a quello di
creazione dei cadaveri, anche se non sono propriamente cadaveri, quindi
ho preferito cambiarne il nome.
- Ho convertito le etichette Corpse in Remains e CorpseNight in RemainsNight.
Ora tali etichette funzionano anche con gli item con lo stesso meccanismo
dei mob.
Bisogna creare almeno una nuova entità perché il sistema funzioni, tale entità
deve avere codice
rip_item_broken-something
Per diminuire la presenza di questa entità durante la distruzione
degli oggetti
per tutte le tipologie di entità si possono creare altre entità con
questo codice:
rip_item_broken-xxx
dove xxx è il nome del codice di ENTITYPE minuscolo, in pratica suddividere i
"cadaveri" degli oggetti per entitype, appunto è un po' come fa con la razza
per i cadavere dei mob.
C'è da tenere conto di una cosa nella creazione delle short di queste entità:
all'atto di creazione dell'entità distrutta dell'oggetto viene aggiunga alla
short la scritta:
di yyy
dove yyy è il nome del materiale cui era formata l'entità ormai rotta, quindi
c'è da tenere presente questa aggiunta dinamica all'atto creativo
nella stesura
delle long delle entità dell'area rip.
- Aggiunta l'opzione max_output_buffer per la sezione [SERVER]
da impostare a 128000
- Adesso si può utilizzare il comand flee anche per sfuggire dalle persone che
ci stanno seguendo, tale modalità funziona solo se non si sta combattendo,
altrimenti in quel caso funziona come prima
- Ho modificato il nome dell'entichetta di TalentsPoints in Talents
- Creato il sistema di ridistribuzione dei talenti (sarebbero delle
'pratiche estese' per riprendere i nomi dei vecchi mud) sui punti di vita,
mana e vigore.
Da testare adeguatamente visto che è una parte delicata per i pg, ovvero
se c'è un baco in alcuni parti delicate come questa hanno la tendenza ad
alterarsi.
- Ho creato il comando talents per aprire la tab di distribuzione dei talenti
Non intendo inserirlo nel bigino dei comandi, il sistema è già abbastanza
automatico e non necessita di visibilità.
- Aggiungere a tutti i player l'etichetta Practices da impostare con un valore
di 2 * Level
In alternativa se lo script bash è troppo complesso da fare si possono
recupare i comandi già utilizzati nella release r111 e impostare tutti i
livelli a 1, impostare MaxLife, MaxMana e MaxVigour a 100 e azzerare i
Talents e ovviamente inserire la nuova etichetta Practices con valore a 0,
il resto farà Aarit una volta che il giocatore entrerà in gioco.
- Ho modificato la flag RESET.PLANTING in RESET.GROWING.
Da modificare le eventuali occorrenze nei file dat.
- Ho aggiunto il metodo utile anche agli script chiamato
can_carry_target
funziona così:
if entity.can_carry_target(target):
allora lo mette in inventario
else:
lo lascia per terra
can_carry_target fa la stessa cosa di questo pezzo di codice:
if (target.weight * target.quantity) + entity.get_carry_weight() >
entity.can_carry_weight():
allora lo mette in inventario
else:
lo lascia per terra
opzionalmente si può passare la quantità di target che si vuole passare in
inventario, per esempio:
if entity.can_carry_target(target, quantity=3):
allora lo mette in inventario
else:
lo lascia per terra
can_carry_target fa la stessa cosa di questo pezzo di codice:
if (target.weight * 3) + entity.get_carry_weight() > entity.can_carry_weight():
allora lo mette in inventario
else:
lo lascia per terra
- Già che sono in modalità di insegnamento esiste il metodo wait utile per
fermale l'invio interattivo di una entità.
Esempio:
[codice]
interpreter(entity, "kick vittima")
entity.wait(3)
interpreter(entity, "kick vittima")
[resto del codice]
Allora l'entità invierà un calcio alla vittima, aspetterà 3 secondi e poi
ne invierà un altro, attenzione che non è una deferred! il [resto del codice]
viene eseguito subito e non vengono attesi tre secondi, sono solo i comandi
interattivi che vengono messi in coda per entity
Ho pensato che questa conoscenza vi potesse essere utile per ingarbugliare
ulteriormente le cose.
- Ho cambiato i trigger di put e give in questa maniera:
def before_give(entity, target, receiver, direction, behavioured):
e così anche gli altri tre, da modificare il manuale.
Ho cambiato il nome a target e a receiver, ma sono sempre la stessa cosa di
prima; quello che ho aggiunto è, oltre al behavioured come tutti i gamescript,
direction.
Il parametro direction indica la direzione verso la quale una porta, target,
viene inserita sui cardini, in quel caso receiver è a None.
Viceversa quando receiver è valido direction è passata a DIR.NONE.
- Relativamente al sistema di buy e sell ho aggiunto il magazzino concreto.
Esso consiste in varie modifiche:
Ho aggiunto l'etichetta ProtoStorages, che nel manuale va inserita prima
delle ProtoLocations per ordine di importanza.
È facoltativa e se non viene impostata allora ritiene che il magazzino
sia il negoziante stesso.
È possibile impostare una o più codici di prototipo indicante l'entità
da utilizzare come magazzino, dev'essere un'entità direttamente accessibile
dal negoziante stesso:
mob, item o la location medesima.
Ho rimosso la possibilità che una ProtoLocations potesse essere un player,
non ricordo se l'avevo detto esplicitamente per il manuale o se era una
feature fantasma, ora cmq non c'è più.
Ho rimosso il valore relativo allo store dall'etichetta di Buyable, quindi
quest'ultima avrà la precedente sintassi MENO quel particolare valore.
Quello che vi manca sapere ora è che per impostare la mercanzia bisogna
resettare le entità definite in buyables nello storage definito (o nel
negoziante se non definito) la quantità resettata fa da valore di store.
Bisogna testare il ProtoLocations che l'ho cambiato, ma vabbé... c'è da
ritestare tutto il sistema in realtà (a parte il comando offer che non
ho toccato).
- Rimossi i PersonalResets, da modificare il manuale e i data.
- Aggiunta l'opzione di config time_warp nella sezione [DEVELOPMENT]
Da impostare normalmente a False quest'opzione se impostata a True eseguirà
le deferred tutte un secondo dopo la loro definizione, senza attendere il
loro naturale decorso.
Anche i loop di aggressivness, digestion e supply non attenderanno il naturale
decorso ma avranno la tendenza ad attivarsi il prima possibile (dipende dalla
opzione _loop_seconds di ognuno dei loop, per esempio aggressivness_loop
viene attivato ad ogni secondo, mentre gli altri due ogni 60 secondi)
- Rinominata l'opzione di config use_mudscripts in use_gamescripts
- Ora il massimo peso trasportabile si basa logaritmicamente sul vigore e
non più sulla forza.
È una delle regole fondamentali del nuovo sistema di Aarit, serve anche a
dare maggior rilievo ai punti di vigore che, tradizionalmente, sono
maggiormente snobbati rispetto agli altri due.
- Aggiunto il comando plant, ciò comporta un po' di cose:
Prima di tutto le piante ora si manipolano con il comando plant
Mentre i semi tramite il comando seed.
Tali comandi sono uguali, cambia solo la tipologia di entitype.
Difatti ora esiste l'entitype SeedType: che ha stesse etichette e tutto quanto
del PlantType.
Vi sono i relativi trigger per il comando plant, che hanno stesso
interfacciamento di quello di seed (behavioured incluso ovviamente):
def before_plant(entity, target, location, ground, behavioured):
def after_plant(entity, target, location, ground, behavioured):
def before_planted(entity, target, location, ground, behavioured):
def after_planted(entity, target, location, ground, behavioured):
def before_planting_in_location(entity, target, location, ground, behavioured):
def after_planting_in_location(entity, target, location, ground, behavioured):
L'unica cosa che c'è da tenere bene in conto è che, mentre tramite il plant
si possono piantare solo entità con il plant_type, tramite il seed ora
è possibile piantare qualsiasi entità, ovviamente non avverrà nessuna crescita
a livello di pianta ma verrà interrata l'entità. (Have fun!)
Ho notato, riguardando il comando di seed/plant, che per interrare la pianta
o il seme viene creato un container_type all'interno dell'eventuale terreno,
è una cosa da tenere d'occhio, per ora non ho trovato alternativa migliore,
ma la cosa non mi piace moltissimo.
- Modificato il trigger before_gived e after_gived in before_gave e after_gave
Da modificare il manuale e tutte le occorrenze nei gamescripts.
- Ho rimosso l'opzione di config autoreload_loop_seconds
- Rinominata l'opzione di config allow_robots in allow_web_robots
- Rinominata l'opzione di config news_to_send in news_to_show
- Rinominata l'opzione di config log_accent in log_accents
- L'opzione di config text_color è stata spostata nella sezione [SITE]
- Rimossa l'opzione show_square dal file di config
- Rinominata l'opzione max_square_msg_show in max_square_messages
Se tale opzione viene impostata a 0 disattiverà la piazzetta
- In generale ho eseguito molte modifiche relativamente al sistema di gruppo
fisico e attualmente per la maggior parte delle azioni (a parte codice
particolare di gamescript e altre cose di cui non ho tenuto il conto) la
manipolazione sulle entità avviene su quantità singola.
Prima invece a parte i comandi come get, give e put la maggior parte delle
manipolazioni su entità avvenivano sull'eventuale mucchio fisico relativo
all'entità obiettivo.
Ve ne accorgerete presto di che cosa significhi ciò e imparerete altrettanto
presto a usare la sintassi:
drop tutti.seme
Altra particolarità è che anche il look esegue una divisione fisica
momentanea dell'entità da guardare.
- Ho aggiunto l'opzione di config max_execution_time nella sezione [SERVER]
da impostare a 0.04
Ogni qual caso che si cambierà eventualmente server passando ad uno più veloce
si potrebbe voler aggiustare tale valore a 0.03
Tale tempo se superato durante l'esecuzione dei comandi invierà un
messaggio del tipo:
"Il comando %s è stato eseguito in troppo tempo: %f secondi"
Messaggio già incontrato in passato, e normale se durante il comando è
intercorso un crash, brutta cosa invece se tale crash non è avvenuto e
da segnalare (concorrerebbe a problemi relativi ai mucchi fisici)
- Attenzione che ho rimosso tutti i comandi concretly che non erano
autoconsistenti rispetto al sistema del mucchio fisico, d'ora in poi bisogna
fare a meno di quei pochi che erano stati definiti.
Bisognerà invece creare l'argomento stringa in maniera corretta come viene
fatto in molti gamescript (tramite l'utilizzo della get_numbered_keyword
ad esempio)
Ho trovato nei gamescript due occorrenze commentate di command_get_concretly,
se si ha intenzione di utilizzare gli script bisognerà convertirli con
command_get e get_numbered_keyword relativa.
- In uno dei gamescript c'è questo pezzo:
room_weight = 0
for content in to_room.iter_contains():
#print "PESO in LOOP = ", room_weight, content.code
room_weight += content.get_carry_weight()
room_weight += content.weight
#print "PESO ROOM = ", room_weight
da modificare in
room_weight = 0
for content in to_room.iter_contains():
#print "PESO in LOOP = ", room_weight, content.code
room_weight += content.get_total_weight()
#print "PESO ROOM = ", room_weight
Anche questa riga è da modificare:
total_wielded_weight = asciugamano.weight + asciugamano.get_carry_weight()
in
total_wielded_weight = asciugamano.get_total_weight()
- Ho modificato il nome del metodo get_carry_weight in get_carried_weight
ho notato che vi sono delle occorrenze nei gamescript, e quindi vanno
modificate di conseguenza
- Bisogna aggiungere l'opzione
email = [email protected]
nella sezione
[MAIL]
- Creata la pagina support_us.html
Dategli un'occhiata e fatemi avere pareri
- Ho aggiunto il comando comment che funziona come i comandi idea, typo e bug
Inoltre nella cartella data ora c'è una nuova directory: comments
Bisogna poi andare al file config.ini ed aggiungere la seguente riga:
max_account_comments = 1000
nella sezione di config [GAME]
Ho già aggiunto il comando nel bigino.
- Ho creato il sistema di gift, basta collegarsi come amministratore con trust
di implementor e andare nella sezione Manage Players, da lì si può accedere
alla sezione apposita.
- Nela manuale ci sono i trigger
def before_outcoming(entity, from_room, direction, to_room, looker):
def after_outcoming(entity, from_room, direction, to_room, looker):
e quelli
def before_incoming(entity, from_room, direction, to_room, looker):
def after_incoming(entity, from_room, direction, to_room, looker):
inseriti in posizione secondo me errorea, concettualmente sono trigger simili
a quelli di move e di direzione, che si trovano un po' più in alto, magari
inserirli subito sotto
- Aggiunti i a tutti i trigger di move, direzionali, incoming e outcoming
un parametro aggiuntivo da inserire prima del behavioured, quindi al
penultimo posto:
running
Servirà ad indicare allo script se si sta correndo oppure no
Volendo si possono fare dei script ad uopo di una pseudo corsa a premi, o
persone che si stupiscono se uno sta correndo.
Da aggiungere nel manuale e modificare i gamescript
- Non ho finito il sistema di ban/punizioni, quindi la pagina relativa è useless
================================================================================
Rella 111
26/06/12
* Cambiare tutte le occorrenze negli script da
target, counter = entity.find_entity(...
in
target = entity.find_entity(...
* Nei gamescript inoltre bisogna fare questa conversione:
da
dust.find_entity("bruco", ["mobs"], location)
a
dust.find_entity("bruco", location, ["mobs"])
Cioè invertire l'ordine del secondo e terzo parametro
* Rimuovere a tutti i player la flag FLAG.DISTRIBUTE, attenzione che quasi tutti
i player hanno solo tale flag nell'etichetta Flags, e quindi bisogna
rimuovere
Inoltre:
* Modificare il valore di tutte le etichette:
Life, MaxLife, Mana, MaxMana, Vigour e MaxVigour
a 100
* Rinominare tutte le etichette Practices dei player in TalentPoints
e impostarle a 0
* Impostare tutte le etichette Level dei player a 1
Questa tripletta di modifiche potrebbe divenire un classico in futuro,
serve ad azzerare la ridistribuzione dei punti di talento (pratiche) tra i
punteggi vita, mana e movimento (e poi ci sarà in futuro la parte per azzerare
le conoscenze: skill, spell etc etc)
* Da aggiungere l'opzione
persistent_act_seconds = 2
nella sezione [GAME] del file config.ini
* Rinominata l'etichetta EntityResets in PersonalResets relativamente
all'etichetta delle entità, per non confondersela con quella delle aree
Attenzione durante il replace di non sostituire anche quelle delle
aree quindi.
* Bisogna modificare tutte le occorrenze nei gamescript di
show_wear_messages
in
send_wear_messages
* Bisogna modificare tutte le occorrenze nei gamescript di
get_numbered_argument
in
get_numbered_keyword
- Di seguito ci sono dei punti relativi ai gamescript, ovviamente tutto ciò che
ho fatto, anche se non l'ho detto in alcuni punti è da aggiornare nel manuale
alla pagina dei gamescript.
ATTENZIONE: esegui il tutto con l'ordine dei punti senza saltare perché
ci sono modifiche successive e cumulative tra di loro.
- Adesso il trigger on_reset funziona anche all'avvio, se si vuole che non
funzioni durante l'avvio basta un check nel gamescript di questo tipo:
from src.engine import engine
if engine.booting:
return
- Aggiunti i trigger di before_from_location, after_from_location,
before_to_location e after_to_location.
Interfacciamento:
def before_from_location(entity, quantity):
def after_from_location(entity, quantity):
Funzionano concettualmente come la from_location del codice kernel:
entity è l'entità (mob o item) da rimuovere per una quantità voluta
dalla locazione in cui si trovano attualmente.
def before_to_location(entity, location):
def after_to_location(entity, location):
Funzionano concettualmente come la to_location del codice kernel:
entity è l'entità (mob o item) da inserire nella locazione voluta
(room, mob, item o player).
- Elenco per sicurezza tutti i trigger che funzionano in maniera personale:
"on_booting", "on_shutdown", "on_reset", "on_repop", "on_init_after_booting",
"before_inject", "after_inject", "before_extract", "after_extract",
"before_to_location", "after_to_location", "before_from_location",
"after_from_location",
"on_dawn", "on_sunrise", "on_noon", "on_sunset", "on_dusk", "on_midnight"
Da aggiornare quindi nel manuale
- Se si ritiene opportuno, inserire nella pagina di manuale dei gamescript le
funzioni di defer descritte nelle note di release precedente in una sezione
o in una pagina a parte
- Ho rimosso i trigger before_money e after_money
- Aggiunti i trigger posizionali:
def before_stand(entity):
def after_stand(entity):
def before_wake(entity):
def after_wake(entity):
def before_knee(entity):
def after_knee(entity):
def before_rest(entity):
def after_rest(entity):
def before_sit(entity):
def after_sit(entity):
def before_sleep(entity):
def after_sleep(entity):
entity è l'entità (mob, item o player) che effettua l'azione
- Aggiunto il trigger:
def before_emote(entity, argument):
def after_emote(entity, argument):
entity è l'entità (mob, item o player) che sta effettuando esprimendo qualcosa
argument è l'argomento passato per descrivere l'espressione
L'emote è particolarmente adatto per personalizzare una risposta di un'enigma
che richiede una posizione particolare del corpo, come: coprirsi gli
occhi con una mano
emote si copre gli occhi
Il trigger potrebbe attivarsi con la presenza delle parola copre/coprire e occhi
Stesso discorso lo si potrebbe fare con il before_say comunque (come tra l'altro
ho già visto fare nei gamescript già esistenti)
- Modificato il trigger before_look e after_look aggiungendo un
parametro finale:
use_examine, valore booleano che indica se il comando è stato digitato per
eseguire un look oppure per eseguire un examine, quindi il nuovo
interfacciamento
è:
def before_look(entity, target, detail, descr, use_examine):
def after_look(entity, target, detail, descr, use_examine):
differenziandosi così dagli altri sensi, quindi se sembra il caso forse è meglio
separarlo dagli altri e descriverlo a parte.
Bisogna aggiornare gli script che hanno questo trigger aggiungendovi
il parametro
- Modificato il trigger before_close e after_close in maniera tale da carpire
se tale trigger è stato eseguito tramite un comando di shut:
def before_close(entity, target, reverse_target, container_only):
def after_close(entity, target, reverse_target, container_only):
container_only è un valore booleano che indica se il comando cercherà solo tra
i contenitori e non anche sulle porte
- Aggiunti i trigger