107 lines
4.6 KiB
Text
107 lines
4.6 KiB
Text
|
//
|
|||
|
|
Ecrire dans la database pour tout les swap (m<>me quand rien ne change) => pouvoir forcer l'update
|
|||
|
|
Voir avec Olivier le pb d'init d'interfaces qui envoit un message reseau alors que la couche reseau n'est pas initialis<69>e.
|
|||
|
|
|
|||
|
|
|
|||
|
|
Les sources sont balis<69>es avec des TODO_GAMEDEV pour indiquer les endroits <20> modifier ou checker par le gamedev
|
|||
|
|
|
|||
|
|
// Done: Il faudra revenir sur le checksum et le remplacer par un compteur d'action
|
|||
|
|
* database.xml: SERVER:BUILDING_SENTENCE:BRICKS supprim<69>.
|
|||
|
|
Plus de communication server vers client pour la construction de la sentence courante.
|
|||
|
|
Le client envoie toujours les messages SENTENCE:ADDBRICK etc... mais seulement pour que le serveur:
|
|||
|
|
- se mette <20> jour
|
|||
|
|
- renplisse VALID, COST, STRING, comme avant
|
|||
|
|
- remplisse CHECKSUM qui est calcul<75> avec
|
|||
|
|
CDBCheckSum.add(RootSheetId)
|
|||
|
|
CDBCheckSum.addVector(MandatorySheetId) Taille du tableau en accord avec la RootBrick
|
|||
|
|
CDBCheckSum.addVector(OptionalSheetId) Taille du tableau en accord avec la RootBrick
|
|||
|
|
NB: sheetId en sint32. Si une brique optionnelle n'est pas voulu, 0 est ajout<75> au checksum.
|
|||
|
|
|
|||
|
|
Ainsi le client ne peut valider la sentence que si CHECKSUM et VALID sont bons.
|
|||
|
|
|
|||
|
|
Le CHECKSUM sert pour <20>viter que le client, apr<70>s VALID=1 du serveur, change une brique, puis clique OK tout de suite (avant possible invalidation)
|
|||
|
|
|
|||
|
|
// Done: Ne pas oublier de mettre <20> jour la database avec la quand un perso monte de niveau ou acquiere un nouveau metier
|
|||
|
|
* database.xml: SERVER:CHARACTER_INFO:CAREER modifi<66>e.
|
|||
|
|
- LEVEL indique le level de la carriere (0,carriere non entreprise) (1-25,carriere valide)
|
|||
|
|
- JOB0 <20> JOB7 correcpondent a tout les metier d'une carriere
|
|||
|
|
- LEVEL pareil que pour la carriere mais pour le metier
|
|||
|
|
- PROGRESS est l'indice de progression du metier (pour les progress bar des skills ?)
|
|||
|
|
|
|||
|
|
// Done
|
|||
|
|
* message ITEM:SWAP doit marcher pas seulement de main <20> autre mais de n'importe quel inventory a nimporte quel autre
|
|||
|
|
|
|||
|
|
// Done
|
|||
|
|
* message SENTENCE:MEMORIZE
|
|||
|
|
|
|||
|
|
Il faut maintenant rajouter un num<75>ro de slot pour la m<>morisation des sorts (car fait par un glisser/deplacer now):
|
|||
|
|
|
|||
|
|
|
|||
|
|
/ Ok
|
|||
|
|
* Note: sentences.name a chang<6E> de format... (c deja cod<6F>)
|
|||
|
|
|
|||
|
|
|
|||
|
|
* FABER: changements:
|
|||
|
|
- le joueur ne peut choisir que le meme nombre de MP requis par la formule.
|
|||
|
|
|
|||
|
|
par consequent le message SENTENCE:CLEAR doit le remettre <20> 0
|
|||
|
|
|
|||
|
|
- De la meme facon qu'avec la magie,
|
|||
|
|
SERVER:BUILDING_SENTENCE:TOOL et
|
|||
|
|
SERVER:BUILDING_SENTENCE:MPS
|
|||
|
|
|
|||
|
|
sont supprim<69>s, car la gestion est faite sur le client. VALID, STRING et COST (cout en stamina) sont remplis de la meme facon
|
|||
|
|
|
|||
|
|
CHECKSUM est calcul<75> selon:
|
|||
|
|
CDBCheckSum.add(OptionalSheetId) (sint32) Taille du tableau en accord avec la RootBrick. 0 si brique optionnelle non voulue
|
|||
|
|
CDBCheckSum.addVector(Mps-Quality) (sint32) Taille du tableau en accord avec la RootBrick
|
|||
|
|
CDBCheckSum.add(OBJECT:SHEET) (sint32) sheetId de l'obet <20> cr<63>er
|
|||
|
|
CDBCheckSum.add(OBJECT:QUANTITY) (sint32) quantit<69>s de l'obet <20> cr<63>er (objets stackables)
|
|||
|
|
|
|||
|
|
Ainsi le client ne peut valider que si le client et le serveurs sont raccords et que la sentence est valide.
|
|||
|
|
|
|||
|
|
- FABER:ADD_MP et FABER:REMOVE_MP sont remplac<61>s par
|
|||
|
|
|
|||
|
|
FABER:SET_MP_QUALITY
|
|||
|
|
format="u16 u8" => "Quality MpSlot"
|
|||
|
|
|
|||
|
|
Ainsi le serveur doit verifier que le client a ce qu'il faut dans son inventaire pour selectionner le MP.
|
|||
|
|
L'execution de la sentence devra enlever "au mieux" les MPs, si necessaire en supprimant plusieurs slots
|
|||
|
|
|
|||
|
|
- Pour les items stackable (fleches etc...) on peut en cr<63>er plusieurs d'un coup (Les MPs sont multipli<6C>s)
|
|||
|
|
Le message FABER:SET_NUM_ITEM (format="u8") permet de changer le nombre voulu d'items.
|
|||
|
|
il devra aussi surement changer tout ce qui est cout en stamina etc...
|
|||
|
|
Le message SENTENCE:CLEAR reset le nombre d'items du Faber <20> 1
|
|||
|
|
|
|||
|
|
|
|||
|
|
- Ya pas de briques racines de FABER! Pour la cr<63>ation, <20> la place de l'ADD_BRICK du root,
|
|||
|
|
avant le message FABER:EXECUTE, un message est envoy<6F>:
|
|||
|
|
|
|||
|
|
FABER:START_CREATE
|
|||
|
|
format="u32" => "SheetId"
|
|||
|
|
|
|||
|
|
- pour la r<>paration et le rafinage, l'objet n'est pas enlev<65> de l'inventaire. A la place de l'ADD_BRICK du root, et
|
|||
|
|
avant le message FABER:EXECUTE, un message est envoy<6F>:
|
|||
|
|
|
|||
|
|
FABER:START_REPAIR
|
|||
|
|
format="u16 u16" => "InventoryId SlotId"
|
|||
|
|
|
|||
|
|
ou
|
|||
|
|
FABER:START_REFINE
|
|||
|
|
format="u16 u16" => "InventoryId SlotId"
|
|||
|
|
|
|||
|
|
|
|||
|
|
L'objet est alors locked (fait par le serveur)
|
|||
|
|
(<28> voir pour plus tard quand les swap_items se feront sur le client, c'est le client qui devra locker)
|
|||
|
|
L'objet doit etre delock<63> sur un SENTENCE:CLEAR
|
|||
|
|
|
|||
|
|
- INFO: Pour La selection du tool je scan les sheaths et le bag (dans l'ordre)
|
|||
|
|
- INFO: Pour La selection des MP, je scan seulement les bag
|
|||
|
|
|
|||
|
|
NOTE: msg.xml n'est pas modifi<66>!
|
|||
|
|
|
|||
|
|
|
|||
|
|
* A voir : pour les cheveux il n'y a pas de difference dans le character summary entre tete et cheveux
|
|||
|
|
|
|||
|
|
|