Calcul de la vitesse des armes (& application aux craft) - Français

#16 Added by Lopyrech 8 years ago [fr]

@Ulu
Merci pour la réponse ^^
Tant que je te tiens, ça serait possible que le serveur envoie l'ID unique des objet (celui qu'il génère lorsqu'un objet est créé que tu peux voir dans le pdr d'un personnage) au client dans le TItemPropId ? Actuellement la seule manière d'avoir un ID (relativement) unique pour un objet c'est de faire un hash avec ces propriétés + les propriétés complètes de l'objet (stats de craft), et pour avoir les propriétés complètes il faut envoyer un ITEM_INFO:GET, ce qui est long (ça fait un A/R serveur quoi).

Et j'aurai besoin d'un ID unique facilement accessible pour pouvoir créer des sets d'objet (armure, bijoux etc) déplaçable / équipable en un clic, sans ça c'est malheureusement trop bancal à faire :(

---

#17 Added by MoonDev 8 years ago [fr]

{translate}

Lopyrech

@Ulu
Merci pour la réponse ^^
Tant que je te tiens, ça serait possible que le serveur envoie l'ID unique des objet (celui qu'il génère lorsqu'un objet est créé que tu peux voir dans le pdr d'un personnage) au client dans le TItemPropId ? Actuellement la seule manière d'avoir un ID (relativement) unique pour un objet c'est de faire un hash avec ces propriétés + les propriétés complètes de l'objet (stats de craft), et pour avoir les propriétés complètes il faut envoyer un ITEM_INFO:GET, ce qui est long (ça fait un A/R serveur quoi).

Et j'aurai besoin d'un ID unique facilement accessible pour pouvoir créer des sets d'objet (armure, bijoux etc) déplaçable / équipable en un clic, sans ça c'est malheureusement trop bancal à faire :(

J'avais pas fini de lire ton post que je savais déjà pourquoi tu voulais l'ID :D

J'ai été bloquer pareil pour faire les sets d'items à l'époque. Et comme avant faire un patch client était supra-méga-ultra compliqué de la mort... forcement ça n'as pas avancé du tout.

Je pensais l'envoyer dans la DB directement, du coup accessible même en lua avec un db("SERVER:XXX") comme pour le slot.

Du coup, ça implique que les client qui n'auront pas la mise à jour ne pourront plus se co, mais bon, si on veux garder une retro-compatiilité à chaque fois on avance pas...

#18 Added by Yubina 8 years ago [en]

{translate}

@Lopyrech, I was not aware this fix is your work. It's great, thank you for it!

@Placio, good you found out by yourself, it's a bad idea to correct this client side. ;)

@RT. Any ETA? Please? (I want to continue level dagger fighting ;P)

#19 Added by Lopyrech 8 years ago [fr]

{translate}

Moondev

Lopyrech
@Ulu
Merci pour la réponse ^^
Tant que je te tiens, ça serait possible que le serveur envoie l'ID unique des objet (celui qu'il génère lorsqu'un objet est créé que tu peux voir dans le pdr d'un personnage) au client dans le TItemPropId ? Actuellement la seule manière d'avoir un ID (relativement) unique pour un objet c'est de faire un hash avec ces propriétés + les propriétés complètes de l'objet (stats de craft), et pour avoir les propriétés complètes il faut envoyer un ITEM_INFO:GET, ce qui est long (ça fait un A/R serveur quoi).

Et j'aurai besoin d'un ID unique facilement accessible pour pouvoir créer des sets d'objet (armure, bijoux etc) déplaçable / équipable en un clic, sans ça c'est malheureusement trop bancal à faire :(

J'avais pas fini de lire ton post que je savais déjà pourquoi tu voulais l'ID :D

J'ai été bloquer pareil pour faire les sets d'items à l'époque. Et comme avant faire un patch client était supra-méga-ultra compliqué de la mort... forcement ça n'as pas avancé du tout.

Je pensais l'envoyer dans la DB directement, du coup accessible même en lua avec un db("SERVER:XXX") comme pour le slot.

Du coup, ça implique que les client qui n'auront pas la mise à jour ne pourront plus se co, mais bon, si on veux garder une retro-compatiilité à chaque fois on avance pas...

Ça devrait marcher comme ça
Tu peux toujours faire un petit patch sur (par exemple CONNECTION:SELECT_CHAR, mais tu pourrais carrément recréer un message). Le client normal envoie juste le uint8 du perso choisi ; le client modifié envoie un uint8 du perso + un booléen. Le serveur essaie de décoder le message, s'il arrive à lire le booléen supplémentaire alors il envoie la nouvelle version des infos au client. S'il y arrive pas, c'est un ancien client et on envoie la version qui fait pas crash. (tu peux aussi intégrer le booléen directement au n° du perso choisi, vu que le n° va entre 0 et 4 tu peux par ex mettre le bit de poids fort à 1 sur le client modif). Mais c'est clairement pas super pratique, faut garder 2 versions du CItemSlot ...

Le plus simple reste de casser la compatibilité :P

---

#20 Added by Placio 8 years ago [en]

{translate}

@Yubina, I don't think anyone said or gave reason why it would be a bad idea to correct this problem on the client-side, other than Lopyrech saying it was confusing. I can give a couple reason why it might actually be better to just correct the in game display of speed instead.

1) Completely correcting the error will result in significantly better melee performance in game, I have several melee masters, so it does not sound completely bad- but does WG want to boost the power of melee after all these years?

2) Changing the server is bound to be more complicated and require more time and testing than just changing how the client displays the hpm. WG/Ryzom Team would have to decide IF they want to change it, HOW it will be changed, etc- Where if Kervala has time available, the display of hpm could be changed on the client and testing started rather quickly, without possible harm to the server... I agree, Lopy, that it could be confusing, but it would be an honest display of what is actually the performance of the weapons- the speeds are determinate numbers based on server ticks, as opposed to an infinite set of speeds between min and max hpm.

I would really like the weapons to function as described in game. It would be really nice if the 2 tick delay was removed, or included in the calculation of the server ticks ((600/hpm)-2), but again it would actually change how the game has functioned for years...

I wonder if mob melee attacks are calculated the same way as homins'? If so correcting the bug could result in mobs becoming more powerful!

Edited 2 times | Last edited by Placio (8 years ago)

#21 Added by Yubina 8 years ago [en]

{translate}

Placio

Yes, the numbers get very sad once you include the 2 tick delay- even a rubbarn boosted dagger will not get 55 hits per minute on the server :O
I only suggested changing the in-game display to match the server stats because it seemed more likely to happen, but obviously if it functioned as it shows us in game that would be even better!

Placio

I don't think anyone said or gave reason why it would be a bad idea to correct this problem on the client-side, other than Lopyrech saying it was confusing. I can give a couple reason why it might actually be better to just correct the in game display of speed instead.

Sorry, I’m confused now, maybe a language/translation thing o.O

Placio

WG/Ryzom Team would have to decide IF they want to change it, HOW it will be changed, etc- Where if Kervala has time available...

At least Kervala approved this as far as I understand (and I still understand nearly no french without Google translate ;) )
https://bitbucket.org/ryzom/ryzomcore/issues/295/displayed-speed- on-item-tooltip-is

Just leave the correction this way if it is ok and compatible to current (or future) live server, why not?

#22 Added by Placio 8 years ago [en]

{translate}

ok, maybe I should just clarify then. I would LOVE to have the full speed of my melee weapons work! However, there is the reality of what can be done or is most likely to happen. And I am really curious if speeding up homin weapons would speed up creatures' melee attacks also... And I realize that making any changes to the server side are a significant change to the game- it is not like a dagger ever had the real speed of 60 hpm, so the speed did not break at some point, we were just always shown the wrong speed.

#23 Added by Yubina 8 years ago [en]

{translate}

As I understand this 'bug' is a lot worse on high speed weapon mostly Daggers and not so bad on other weapons like 2h Axe and Mace, right?
Daggers are weaker and get more from the fix (ca 20%?) and the already strong 2h Axe gets noticeably less (ca 10%?).
I would guess weapons would feel more balanced.

Will the speed of mobs change by this? (interesting idea)

Last edited by Yubina (8 years ago)

#24 Added by Lopyrech 8 years ago [en]

{translate}

Yes, the speed of mobs will change, it's the same part of the code that manages this.

---

#25 Added by Lopyrech 8 years ago [fr]

{translate}

Pour info, les bug identifié dans le post ont été corrigés avec le dernier patch, il faudra mettre à jour vos recettes pour ceux qui les utilisaient :p

The bug listed in the first post has been corrected with last patch, you should update your recipes if you used them :p

---