KSP 0.25

[KERBAL 21]

de mon coté j'espère vraiment qu'ils améliore la version X64.

parce que la ok ces de l'expérimental je veux bien, mais faut pas que sa reste a ce stade la pendant 6 mois nomplus...

et ce qui me fait peur ces qu'ils n'en parle absolument pas, mais bon vue je garde espoir!!!

[Spacex]

Si le jeu avance, mais c'est ce qu'on appelle du Back-end donc c'est pas visible, et le tout en bien poussé et moddable, mais la plupart des joueurs ne le voient pas

Si tu ne le vois pas, tu ne le sais pas toi non plus s'il avance ou pas. Ils avancent en back-end depuis 1 an ?
Ok ...

[Nemecle]

de mon coté j'espère vraiment qu'ils améliore la version X64.

parce que la ok ces de l'expérimental je veux bien, mais faut pas que sa reste a ce stade la pendant 6 mois nomplus...

et ce qui me fait peur ces qu'ils n'en parle absolument pas, mais bon vue je garde espoir!!!

En même temps c'est pas pour rien qu'ils refusaient de faire le 64bits, ils savaient que c'étaient instable, ils l'ont mis parce qu'un joueur (un français qui traine sur ce forum d'ailleurs ) a fait un excellent hack qui faisait le taf, et qui a fait croire/comprendre à Squad que les joueurs le voulaient absolument mais qui évidemment ne passe pas du tout en tant que feature 'officielle'

Si le jeu avance, mais c'est ce qu'on appelle du Back-end donc c'est pas visible, et le tout en bien poussé et moddable, mais la plupart des joueurs ne le voient pas

Si tu ne le vois pas, tu ne le sais pas toi non plus s'il avance ou pas. Ils avancent en back-end depuis 1 an ?
Ok ...

Bah typiquement les contrats tout le monde a gueulé comme quoi Squad se jetait des fleurs, mais personne n'a regardé les fichiers configs : les agences ont des traits de caractères qui définissent la gueule des contrats qu'ils donnent, il y a des liens entre elles (du background quoi) et la possibilité de créer sa propre agence et ses propres contrats : pour les moddeurs c'est du pain béni et pour les mises à jour où ça va passer en 'front-end' ça va être monstreux

[Eptios]

Perso j'ai dit qu'ils se jetaient des fleurs car ils arrêtaient pas de dire que leurs contrats étaient géniaux, alors que non pas vraiment.

Maintenant qu'ils ont bossé sur la mécanique, un peu de "visible" serait appréciable ! C'est ce qui se présente à l'horizon avec le super mod SP+ et le bâtiment d'administration. On a plus d'info en 1 mois que en 5 pour la 0.24. Donc tant mieux je n'ai rien à dire, si ce n'est "vivement !"

[Balthyx]

Donc tant mieux je n'ai rien à dire, si ce n'est "vivement !"

*Se re-noie dans son café*
Eptios qui ne rage pas sur les dev's ? Décidément on aura tout vus.

[Eptios]

J'ai été très fâché de la 0.24, communication nulle, temps de dev long et résultat pas à la hauteur. Je n'ai jamais vraiment râlé avant cette maj, la seule chose que je demande c'est des infos concrètes. Cette fois on les a, ça a l'air d'avancer donc je suis content

[DrDam]

J'ai été très fâché de la 0.24, communication nulle, temps de dev long et résultat pas à la hauteur. Je n'ai jamais vraiment râlé avant cette maj, la seule chose que je demande c'est des infos concrètes. Cette fois on les a, ça a l'air d'avancé donc je suis content

C'est sur que le message de Romfarer sur la dernière dev note est "concret" ...

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER:

Partie 2 : J’avais besoin d’un slider incrémental pour une partie de la nouvelle interface de l’Administration building. Le framework (EzGUI) que nous utilisons ne peut pas gérer ça donc j’ai du habilement ruser pour tout faire fonctionner. Basiquement l’implémentation existante peut seulement bouger le slider de haut en bas ou de gauche à droite, mais il ne s’activait pas pour certains incréments. Ajouter un appel ‘ValueChanged’ pour le slider ne marcherait pas non plus car un slider cranté ne change évidemment pas de valeur avant le ‘tic’ suivant, donc c’est un peu le problème de l’œuf et de la poule. Ainsi j’ai crée deux sliders l’un au dessus de l’autre, celui du dessus étant transparent mais activant les collisions. Le slider invisible bouge en fait avec un incrément de 0, et chaque fois qu’il est « à la moitié de la distance de l’incrément suivant » il envoie une update au slider en dessous pour avoir un mouvement sec vers l’incrément suivant. Quand le slider est lâché les deux sliders se réunissent pour être alignés pour le mouvement suivant.

Pour être dans le développement ( et Nemecle sera d'accord avec moi) ... c'est dégueulasse comme solution... si tout le jeu est codé comme ça , ça m'inquièterai

[Balthyx]

Il à du bricoler pour cette fois pour pas avoir à utiliser un nouveau framework. c'est plutôt un compromis.

[Dragoon1010]

J'ai été très fâché de la 0.24, communication nulle, temps de dev long et résultat pas à la hauteur. Je n'ai jamais vraiment râlé avant cette maj, la seule chose que je demande c'est des infos concrètes. Cette fois on les a, ça a l'air d'avancé donc je suis content

C'est sur que le message de Romfarer sur la dernière dev note est "concret" ...

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER:

Partie 2 : J’avais besoin d’un slider incrémental pour une partie de la nouvelle interface de l’Administration building. Le framework (EzGUI) que nous utilisons ne peut pas gérer ça donc j’ai du habilement ruser pour tout faire fonctionner. Basiquement l’implémentation existante peut seulement bouger le slider de haut en bas ou de gauche à droite, mais il ne s’activait pas pour certains incréments. Ajouter un appel ‘ValueChanged’ pour le slider ne marcherait pas non plus car un slider cranté ne change évidemment pas de valeur avant le ‘tic’ suivant, donc c’est un peu le problème de l’œuf et de la poule. Ainsi j’ai crée deux sliders l’un au dessus de l’autre, celui du dessus étant transparent mais activant les collisions. Le slider invisible bouge en fait avec un incrément de 0, et chaque fois qu’il est « à la moitié de la distance de l’incrément suivant » il envoie une update au slider en dessous pour avoir un mouvement sec vers l’incrément suivant. Quand le slider est lâché les deux sliders se réunissent pour être alignés pour le mouvement suivant.

Pour être dans le développement ( et Nemecle sera d'accord avec moi) ... c'est dégueulasse comme solution... si tout le jeu est codé comme ça , ça m'inquièterai

Je manipule Unity presque tout les jours maintenant, et je comprend tout à fait son compromis. C'est surement un problème lié au moteur lui même. Il arrive parfois que l'on est besoin de bidouiller une fonctionnalité pour qu'elle fonctionne, cela n'est surement pas représentatif du reste du travail.

Une construction ne peux tenir avec simplement des bricolage, il faut une structure solide et si besoin est avoir quelques bricolages par ci par là.

[DrDam]

J'ai été très fâché de la 0.24, communication nulle, temps de dev long et résultat pas à la hauteur. Je n'ai jamais vraiment râlé avant cette maj, la seule chose que je demande c'est des infos concrètes. Cette fois on les a, ça a l'air d'avancé donc je suis content

C'est sur que le message de Romfarer sur la dernière dev note est "concret" ...

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER:

Partie 2 : J’avais besoin d’un slider incrémental pour une partie de la nouvelle interface de l’Administration building. Le framework (EzGUI) que nous utilisons ne peut pas gérer ça donc j’ai du habilement ruser pour tout faire fonctionner. Basiquement l’implémentation existante peut seulement bouger le slider de haut en bas ou de gauche à droite, mais il ne s’activait pas pour certains incréments. Ajouter un appel ‘ValueChanged’ pour le slider ne marcherait pas non plus car un slider cranté ne change évidemment pas de valeur avant le ‘tic’ suivant, donc c’est un peu le problème de l’œuf et de la poule. Ainsi j’ai crée deux sliders l’un au dessus de l’autre, celui du dessus étant transparent mais activant les collisions. Le slider invisible bouge en fait avec un incrément de 0, et chaque fois qu’il est « à la moitié de la distance de l’incrément suivant » il envoie une update au slider en dessous pour avoir un mouvement sec vers l’incrément suivant. Quand le slider est lâché les deux sliders se réunissent pour être alignés pour le mouvement suivant.

Pour être dans le développement ( et Nemecle sera d'accord avec moi) ... c'est dégueulasse comme solution... si tout le jeu est codé comme ça , ça m'inquièterai

Je manipule Unity presque tout les jours maintenant, et je comprend tout à fait son compromis. C'est surement un problème lié au moteur lui même. Il arrive parfois que l'on est besoin de bidouiller une fonctionnalité pour qu'elle fonctionne, cela n'est surement pas représentatif du reste du travail.

Une construction ne peux tenir avec simplement des bricolage, il faut une structure solide et si besoin est avoir quelques bricolages par ci par là.

Je voulais mettre en avant que cela n'a "aucun intérêt" quand à l'information de "qu'est ce qu'ils ajoutent au jeu'