Messages

Fantastique !

J'ai tout lu et avec un petit schéma pour comprendre la 1ère formule de départ (le calcul de l'angle sous lequel est vue Jupiter, soit son diamètre apparent) et un petit rappel de la formule de base de l'arctan (arctan = côté opposé/côté adjacent), j'ai tout compris.

Il retourne de tout cela que en l'état, sous réserve que l'étoile du système stellaire soit très massive, et que Samayun soit une géante gazeuse (=jovienne) de la taille de Jupiter mais moins lourde que Jupiter, le visuel de Samayun dans le ciel de jour, ça ferait 3x la taille de la Lune en conditions "normales".

J'ai plusieurs questions :

• Pourquoi se limiter à des positions situées aux Points de Lagrange de Samayun ? Si la planète du Khanat est un satellite de Samayun, rien ne la force à avoir une orbite circulaire (ou quasi-circulaire) la contraignant à rester à la même distance de Samayun. Si au contraire son orbite est extraordinairement elliptique, alors elle s'éloignera et se rapprochera périodiquement de Samayun, dont l'observation continue sera alors un grossissement et un rapprochement alternatif. Suivant cette hypothèse, resterait à déterminer une période de rotation orbitale autour de Samayun.
• Peut-on jouer avec l'illusion d'optique causant l'impression de grosseur typique survenant lors de l'observation d'une éclipse de Lune (souvent en cas de Lune Rousse) lorsque celle-ci est proche de l'horizon ? J'en doute car Samayun étant par définition une planète géante, il me semble impossible qu'elle puisse être éclipsée par la planète du Khanat.
• TGCM

Coi et bienvenue !

En ce qui me concerne, je suis assez loin des choses de l'écriture (plus par manque de temps que par manque d'envie, qui sait, un jour peut-être...) et me suis plutôt centré sur des sujets un peu techniques.
Au plaisir d'échanger avec toi

Alors en vrac, les quelques idées que j'apprécie dans le peu de journaux de quêtes que j'ai pu utiliser par le passé.

Éléments indispensables (pour moi):

• Liste des quêtes terminées : @Zatalyz dans ta liste je vois la liste des quêtes et missions abandonnées et en cours, pas celles qui ont été effectuées. Les avoir à disposition sert généralement quand on recherche des informations (par exemple sur les wikis de jeux) sur une quête après l'avoir effectuée. C'est assez fréquent de nos jours comme "mode de consommation", qu'on parle de RPG solo ou multi.
• Prise de notes : ce genre de fonctionnalité m'aurait bien été utile dans Morrowind, dont le Journal est souvent mentionné comme étant particulièrement mal fait à l'époque, même s'il s'est largement amélioré avec les add-ons Tribunal et Bloodmoon. La prise de notes m'aurait peut être évité d'avoir des feuilles volantes partout sur mon bureau. Et avoir cette fonctionnalité liée à chaque quête ou mission est plus utile qu'une grosse zone de texte globale.
• En parlant de Morrowind, ces améliorations ont notamment consisté en un index alphabétique des quêtes, et un autre index alphabétique pour les PNJ rencontrés (affichant pour le coup les discussions passées avec ce PNJ et les quêtes qu'il a données au joueur)

Concernant Kingdoms of Amalur que tu cites @Zatalyz, je ne connais pas mais voici une capture du journal en question pour illustration :

Tel quel, non.
Je pense cependant qu'il doit être assez facile de le porter en GDScript grâce à la classe HTTPClient (voir cet exemple : http://docs.godotengine.org/en/3.0/tutorials/networking/http_client_class.html?highlight=httprequest).

Je précise que j'ai testé et que pour l'instant ce n'est pas possible, on attend la prochaine version.
Le résumé de mes aventures → https://pastebin.com/cekse4CS

Alors pour la prochaine version, il n'y a toujours pas de demande officielle pour l'ajout des bindings SHA-512 pour Godot 3.1. Je crée un ticket tout de suite, en espérant ne pas raconter n'importe quoi car je n'y connais pas grand chose en cryptographie.

edit : en fait un ticket similaire existe déjà. J'ai ajouté la demande à la fin : https://github.com/godotengine/godot/issues/1969

D'accord, je l'ai testé il marche nickel. J'ai fait une modif pour qu'il fonctionne sous windows aussi. C'est un module python, donc il est assez facile de l'importer. Mais du coup, on va pas pouvoir le faire avec Godot Sans l'extension Python si ?

Tel quel, non.
Je pense cependant qu'il doit être assez facile de le porter en GDScript grâce à la classe HTTPClient (voir cet exemple : http://docs.godotengine.org/en/3.0/tutorials/networking/http_client_class.html?highlight=httprequest).

Ce qui serait vraiment bien ce serait d'avoir la map du serveur dans un format supporté par Godot. Ca vous permettrait de gagner pas mal de temps pour vous concentrer sur les textures, et les props (végétation, objets du monde).

Concrètement on a effectivement besoin des modèles uniquement. Si j'ai appris une chose en 3D, c'est qu'on peut avoir des modèles très peu détaillés et pour peu que les textures et les shaders fassent le boulot, on se retrouve avec un résultat plus qu'honorable. Par contre c'est clair que le texturing, c'est pas la partie la plus rigolote du travail de modeleur 3D

Je ne dis pas que c'est vraiment la bonne solution, il faut étudier la faisabilité car je n'ai pas utilisé GDNative moi-même pour l'instant. Par contre, ça peut être intéressant de partir sur un POC totalement en python d'abord, mais ça ne sera qu'à des fins de prototypage.

Quand tu dis python du parles du GDScript ?

GDNative à l'air d'avoir du potentiel, et pourrait rendre les choses bien plus faciles. Godot ne charge pas les DLL (dylib) si ?

Je parlais du script Python de Tycho qui sert apparemment à gérer le login actuellement. Je n'ai pas regardé ce script, du coup je ne sais pas trop comment on peu communiquer avec lui.

Si si, Godot charge les DLL directement, voir cette partie de la doc officielle : http://docs.godotengine.org/en/3.0/tutorials/plugins/gdnative/gdnative-cpp-example.html#using-your-gdnative-module

En gros l'idée serait de créer un node custom (genre "ServerCommunicator") à ajouter comme enfant de la scène "player". Ce node aurait pour comportement de communiquer les informations nécessaires au serveur. On peut réfléchir à créer plusieurs nodes différents pour communiquer avec chaque composant de serveur spécifique, afin de spécialiser chaque node.

A noter qu'il est parfaitement faisable et facile de faire ce type de node "custom" directement en GDScript, sous la forme d'un addon (voir http://docs.godotengine.org/en/3.0/tutorials/plugins/editor/making_plugins.html#a-custom-node) pour prototyper ça avant de s'amuser à le faire en GDNative.

[Le client solo :]

Je réponds avec un peu de retard, mais mieux vaut tard que jamais

J'avais eu l'occasion de donner les différents objectifs à atteindre sur Jabber, les voici à nouveau. Pour chacun de ces objectifs, on peut former quelques sous-tâches, j'en donnerai quelques exemples.

• Le client solo : ça rejoint un peu ce que vous disiez tous. Il est clair qu'avoir ce client sans le serveur peut paraître étrange pour un MMORPG, mais c'est un passage obligatoire, et là je suis d'accord avec Zatalyz, pour le moral.
  
  La priorité à ce niveau, c'est vraiment les assets, car finalement on peut tout à fait mocker la scène de départ avec des cubes, c'est relativement facile, ça a déjà été fait. Mais avoir une scène de départ jolie et représentative du résultat final souhaité et un plus en termes de moral et surtout de communication. Là-dessus, les compétences requises sont plutôt situées sur la modélisation 3D.
  
  Je préconise de lister tous les assets nécessaires dans cette scène pour partager le travail dans un post séparé (une solution plus économique consiste à exporter les assets du client actuel dans un format standard). Egalement, je propose de ne pas se soucier des environnements intérieurs dans un premier temps.
  


• Le login depuis une scène Godot : c'est surtout pour avoir une sorte de "bonjour le monde" au niveau du réseau. Etre en mesure se présenter au serveur et qu'il nous réponde "bonjour, je te reconnais" serait un bon départ. Je parle ici uniquement du premier login du client.
  


• Réfléchir au moyen de communication entre le client Godot et le(s) serveur(s).
  
  Tel que j'imagine la chose, ça peut être intéressant d'envisager ça sous la forme de composants GDNative. Je m'explique.
  
  Je suis totalement d'accord avec l'idée d'un ensemble de librairies pour discuter avec les différents serveurs. L'avantage de GDNative, c'est que c'est pensé pour permettre de scripter les scènes Godot en C++, donc avec la possibilité d'inclure des morceaux de code spécifiques au serveur actuel, par exemple la définition du protocole. Plus précisément, l'idée est de créer 1 librairie GDNative par composant du serveur pour que tout soit bien séparé, tout en fournissant à Godot (côté GDScript, le Python-like) des fonctions pour discuter avec le serveur.
  
  Le désavantage, c'est qu'il faut compiler ces librairies pour chaque OS. Par contre, comme c'est compilé ça sera efficace en termes de performances. D'autre part, une fois développés, ces composants bougent peu.
  
  Je ne dis pas que c'est vraiment la bonne solution, il faut étudier la faisabilité car je n'ai pas utilisé GDNative moi-même pour l'instant. Par contre, ça peut être intéressant de partir sur un POC totalement en python d'abord, mais ça ne sera qu'à des fins de prototypage.