Nemau - posté le 11/01/2019 à 15:07:16. (52227 messages postés) -
Nanaky > je pense qu'en voulant fixer les dates maintenant tu penses surtout à toi, vu que tu vas venir en avion (je présume).
Citation:
Ca arrange surtout Thanos en fait.
Il a déjà réservé la maison de vacances pour les deux semaines donc il n'y a plus urgence (mais qu'il me dise si je me trompe).
Mais soit, je n'ai rien contre le fait de fixer les dates maintenant. Par contre je pense qu'il vaudrait mieux la faire à cheval sur les deux semaines. Les dates proposées par Nanaky conservent les deux week-ends mais je ne crois pas que quiconque va venir juste pour un week-end, en revanche on risque d'avoir des gens qui peuvent venir seulement la première semaine et d'autres seulement le week-end + la seconde. En plus, ce n'est pas pour chipoter mais d'expérience neuf jours c'est un poil long, on risque de finir par s'ennuyer.
=> Je propose du mercredi 7 août inclus au mercredi 14 août inclus.
Huit jours, c'est encore un poil long mais c'est mieux. Les personnes ne pouvant pas venir durant la seconde semaine peuvent venir cinq jours, et ceux ne pouvant pas venir durant la première peuvent également venir cinq jours (week-end + trois jours).
Nemau - posté le 11/01/2019 à 01:41:00. (52227 messages postés) -
Le créneau du 5 au 18 (validé par Thanos lui-même) ne changera pas. Il faut donc fixer des dates à l'intérieur de ce créneau (ou prendre tout le créneau comme date, mais deux semaines c'est un peu trop je pense). Du coup la question c'est : est-ce que ça arrange une majorité d'IRLeux potentiels que l'on fixe la date maintenant, ou faut-il au contraire attendre encore un peu, que les gens aient une meilleure visibilité concernant leur planning de l'été prochain ?
En attendant, que ceux qui n'ont pas encore rempli ce tableau le fassent, ça ne coûte rien (et vous pourrez demander à modifier votre ligne plus tard, si besoin) :
Nemau - posté le 10/01/2019 à 17:09:15. (52227 messages postés) -
Ta solution est effectivement plus simple mais non réalisable sous RM (2003 du moins), car si par exemple je dis au jeu de faire avancer un event à la fois vers le haut et vers la droite l'event va aller vers le haut ou la droite mais pas vers haut-droite.
Nemau - posté le 10/01/2019 à 16:48:27. (52227 messages postés) -
Citation:
c'était ma première vraie relation
Lors de leur première relation la plupart des gens (en tout cas les adolescents et jeunes adultes) pensent que "c'est sûr il s'agit de the one, ma moitié, l'élu/l'élue, celui/celle avec qui je vais faire passer le reste de ma vie". Ça aussi c'est normal. Mais ça rend la rupture difficile à vivre, certes.
Pour te remonter le moral voici une de mes chansons préférées en rapport avec ton pseudo (non sérieusement j'adore cette chanson xD) :
Par contre l'epicness va en prendre un coup le jour où je vais mettre à Dragon Quest. xD
Nemau - posté le 10/01/2019 à 16:37:05. (52227 messages postés) -
Les ruptures amoureuses, au début on vit ça comme un échec (c'est normal) mais quelques années après on voit une relation passée comme une expérience enrichissante (au sens figuré du terme parce qu'on sait tous qu'une copine ça coûte un bras en cadeaux restaurants etc. =>[]).
Nemau - posté le 10/01/2019 à 02:56:40. (52227 messages postés) -
Emz0 bravo pour tout le travail abattu, par contre je pense qu'il faut que tu évites les gifs animés, ce sont des fichiers particulièrement lourds or tes screens statiques mettent déjà beaucoup de temps (trop) à s'afficher (je pense que ça vient du fait que tu en postes beaucoup mais aussi du serveur personnel que tu utilises). Là j'ai attendu une bonne minute et la plupart des images de la page ne s'affichaient toujours pas, or même si tu proposes des choses intéressantes je pense que personne ne va avoir le courage d'attendre davantage pour voir les screens. De plus c'est pénible car au fur et mesure que les images se chargent ça agrandit la page, du coup on ne peut pas admirer un screen déjà chargé sans devoir rescroller vers ce screen toutes les quelques secondes.
Nemau - posté le 09/01/2019 à 21:02:36. (52227 messages postés) -
Citation:
Si les défenseurs de TP parlent d'objectivité c'est parce que par rapport à OoT il se limite souvent à ajouter de la quantité: ça se compte, ça s'additionne, c'est objectif. Malheureusement, quand il est question de feel/fun une quantité plus grande mal utilisée peut facilement rendre une expérience inférieure.
This. Par exemple, si tu veux faire TP à 100%, tu te tapes à pêcher pas mal de poissons (sauf erreur de ma part) dans un mini jeu chiant est crispant. Dans OoT le jeu de la pêche est tout aussi chiant et frustrant, mais au moins tu n'as qu'un seul poisson à pêcher.
Citation:
le laboratoire du lac (quart de coeur)
Sauf erreur de ma part plonger avec les bottes ne marche pas, le type nous donne le quart de cœur qu'en plongeant avec l'écaille d'or. Bien vu pour les autres endroits sinon.
Nemau - posté le 09/01/2019 à 20:50:31. (52227 messages postés) -
J'ai un concept pour un jeu d'Action-Aventure : au fur et à mesure qu'on avance dans le jeu, le personnage jouable se met à faire les actions de manière de plus en plus badass. Les actions restent les mêmes (par exemple le coup d'épée basique n'a pas plus de portée ni ne fait plus de dégaut) mais visuellement le héros les fait de façon de plus en plus stylée. Niveau role-play ça s'expliquerait par le fait que le héros gagne en expérience.
Je crois que l'idée m'est venue en pensant à Link qui fait parfois des saltos lors des sauts avant dans Majora's Mask alors que pour ces derniers il ne faisait que des sauts normaux dans Ocarina of Time.
Un truc cool serait de faire que cette évolution ne se fasse pas en fonction de l'avancée dans le jeu, mais plutôt en fonction de temps de jeu passé, avec genre du coup des bonus pour les joueurs cumulant beaucoup d'heures de jeu.
Nemau - posté le 09/01/2019 à 20:35:29. (52227 messages postés) -
Merki !
[edit tl;dr :
première image : ça vérifie si la Lune est au bord de la map et d'où elle vient, pour déterminer ensuite s'il faut la faire changer de direction, et vers quelle direction
deuxième image : même système avec en plus affichage en picture (dont le numéro est une variable qui fait +1 à chaque fois) d'une Lune semi-transparente aux coordonées de la Lune principale]
Pour la Lune principale (première image) :
- l'event de la Lune est un simple chara, l'event est vierge autrement (aucune commande)
- je règle la vitesse de la Lune dans la partie "Movement Speed" de l'event dont je viens de parler
- un deuxième event, automatique car de démarrage, règle les variables "moon_from" et "moon_direction" chacunes à 1 (c'est utile pour plus tard)
- cet event de démarrage passe ensuite à sa seconde page (via un interrupteur), cette fois en processus parallèle, et qui enregistre en temps réel dans une variable la coordonnée x de l'event de la Lune et dans une autre variable sa coordonnée y
- un troisième event possède quatre pages, l'une ou l'autre s'activant en fonction de la valeur de la variable "moon_direction" (1 à 4), et toutes sont en processus parallèle, chacune demandant à l'event de la Lune de faire un pas en diagonale (quatre pages pour quatre directions possibles), le pas se répétant du fait du processus parallèle
- un quatrième event, en processus parallèle, vérifie si l'event de la Lune est sur un des bords de l'écran (x0, x19, y0 ou y14), si c'est le cas il vérifie ensuite de quel bord l'event de la Lune vient (au moyen de la variable "moon_from"), puis à partir de ces deux données il change la variable "moon_direction" pour changer la direction de la Lune (exemple : la Lune est sur le bord haut (y0) et elle vient du bord droit (x19), elle doit donc dorénavant aller en diagonale bas-gauche, ce qui correspond dans mon système à la valeur "2" de la variable "moon_direction")
- juste après avoir changé la direction de la Lune ("moon_direction") ce quatrième event change la valeur de "moon_from", la Lune ayant atteint un nouveau bord
Ça pourrait s'arrêter là si la map était carrée, mais les dimensions de cette dernière font que parfois la Lune touche le bord haut en ayant touché auparavant non pas le bord gauche ou droite mais le bord bas, et inversement (bord bas en ayant touché juste avant le bord haut). Et là il ne me suffit plus de savoir que la Lune à d'abord toucher le bord haut/bas, vu que dans ces circonstances cette information ne m'aide plus à pouvoir déterminer si la Lune doit repatir du côté gauche ou du côté droit (et je ne peux pas utiliser comme indication de quel côté est tournée la Lune vu que dans mon système RM la fait toujours tournée vers le haut ou vers le bas). Du coup :
- un cinquième event, en processus parallèle, utilise la coordonnée x de la Lune pour enregistrer dans une nouvelle variable (nommée "special_y") si la Lune touche le bord gauche ou droit (en donnant à la variable "special_y" la valeur 1 ou 2)
- à la fin de mon quatrième event, je rajoute quatre nouvelles possibilités de changement de direction, par exemple la suivante : "si l'event de la Lune touche le bord haut de la map, et que juste avant elle a touché le bord bas, et que le dernier bord latéral qu'elle a touché était le gauche (special_y = 1), alors modifier la valeur de moon_direction pour que la Lune aille désormais en diagonale bas-droite"
Concernant ce qu'il se passe quand la Lune touche un coin, je n'en ai aucune idée. x) Je suppose que RM établit un ordre parmi les possibilités demandés simultanément, en fait ça importe peu qu'il considère que la Lune a touché tel bord avant l'autre vu que la conséquence des deux est un rebond vers l'autre et que dans les deux cas ce second rebond demande la même direction que si ça avait été l'autre (bon ce n'est pas très bien formulé mais je pense être clair ^^).
Pour la Lune qui laisse une trainée (seconde image) :
Bin là c'est très simple, c'est le système précédent avec en plus un event en processus parallèle qui tous les 1/10èmes de seconde affiche une picture de la Lune en semi-transparent et aux coordonnées de la Lune principale (ça demande de faire quelques opérations avec les variables vu que les coordonnées des pictures sont en pixels et non en carreaux, mais c'est très simple). Le numéro de la picture est une variable qui augmente de 1 après chaque nouvelle Lune. J'ai dû rajouter un "attendre 0.0 s" (qui correspond en réalité à... je sais plus, 1/60ème de seconde je crois ?) sinon ça affichait parfois des Lunes doublées dès le premier passage (et je ne pouvais pas changer mon "attendre 1/10ème de seconde" en "2/10èmes de seconde" car ça générait des trous dans la trainée).
La limite de ce système (en plus du fait que ça plante au bout de 1000 Lunes) c'est que ça ne peut afficher les pictures que de façon alignée sur les carreaux, du fait que ça se base sur les coordonnées x et y en carreaux de la Lune principale.
Nemau - posté le 09/01/2019 à 18:28:14. (52227 messages postés) -
• Ne cherchez plus ailleurs que dans le cimetière les jeux ne proposant plus un lien de téléchargement fonctionnel (jusque-là ils figuraient encore dans les catégories par supports).
• La liste des partenaires d'Oniromancie à été mise à jour (vous pouvez retrouver cette liste à tout moment en cliquant sur le lien Nos autres partenaires situé dans la colonne à gauche). Les conditions pour rester dans cette liste sont d'avoir un site/forum toujours uploadé, qu'un lien vers Oniromancie (sous forme de texte ou via notre petite bannière) y figure quelque part, et que son activité (dernière news, dernier post sur le forum...) remonte à trois ou quatre ans maximum.
Chat
mais je vous souhaite quand même le meilleur. ^^
)