API tools faq
paste
Eiyeron

Résumé de la discussion sur l'API Minecraft

Eiyeron
Jul 2nd, 2012
1,570
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 17.21 KB | None | 0 0
raw download clone embed print report
  1. DISCLAIMER: Même si mon niveau en anglais me permet de lire ce log sans problèmes, je risque malgré tout de louper des infos. Je vais surtout prendre ce qui va interesser les devs', donc il y aura beaucoup de contenu relativement pointu (tout le monde ne sait pas forcément ce qu'est github, par exemple). les infos seront à prendre avec des pincettes, autant pour mon log, que pour le leur.
  2. Réalisé pour wtcraft.
  3.  
  4. L.405 : Jun 30 19:48:00 <EvilSeph> please bear in mind, everything said here today is not set in stone, but these are the goals and ideas we're hoping to realise eventually :)
  5. -> Ce qu'ils ont eu comme idées ne seront pas forcément définitives!
  6.  
  7. -------------------------------
  8. L.91 : Jun 30 19:17:35 <Grum> The idea is to make the API some form of 'public source'; this will depend on what Mojang's lawyers will say about it. I think the minimal required shall be to give up rights on contributions to it.
  9. -> Idée de source publiques. Il faudra voir avec les avocats de Mojang, masi il y a l'idée de rendre des sources publiques.
  10.  
  11. L.118 : Jun 30 19:21:05 <Risugami> I think github can provide a decent changelog just from commits
  12. L.143 : Jun 30 19:24:03 <EvilSeph> everything is spread apart so far: GitHub for pull requests and API development, a wiki for documentation, forums for discussion?
  13. -> Utiliser un github pour gérer les versions de l'api, ainsi que son évolution. UN wiki pour une documentation, et un forum pour discussion?
  14.  
  15. L.128 : Jun 30 19:22:31 <Grum> The client should become a true client, without any influence bar giving input to the server
  16. -> Rendre le client plus léger, ne plus dépendre de lui intégralement pour les ressources. Devenir un "vrai client"
  17.  
  18. L.148 : Jun 30 19:24:35 <medsouz> Making it easier to get mods without injecting into the client is a good idea.
  19. -> Séparer une bonne fois pour toutes le client des mods.
  20.  
  21. L.149 : Jun 30 19:24:39 <Grum> Another thing is that we currently are removing SSP as it exist right now
  22. L.151 : Jun 30 19:24:49 <Grum> SSP will become Local Multiplayer
  23. -> Le solo n'existera plus, tel qu'on l'aura pendant longtemps, il deviendra le Local Multiplayer tel qu'on a déjà vu dans les derniers snapshots (intégration du réseau local).
  24.  
  25. L.187 : Jun 30 19:28:20 <Grum> people have already requested doing '3rd party repos' -- what we do with this is undecided sofar
  26. L.196 : Jun 30 19:29:12 <TkTech> Grum: A simple "This download is untrusted, are you sure you want to…?" would suffice.
  27. -> Il ont l'idée de supporter non suelement des sites de mods de Mojang, mais aussi des sites indépendats (un peu comme les serveurs privés sur WOW), mais toujours avec l'idée que les mods chez Mojang seront vérifiés.
  28.  
  29. L.202 : Jun 30 19:30:11 <Grum> On malicious things, the idea is to sandbox the plugins on client/server so you cannot 'do bad stuff'; optionally giving out 'rights to break out' if the user accepts
  30. L.216 : Jun 30 19:31:48 <Searge> all you need to ensure - no way for server admins to steal client credentials
  31. -> Idée de sécurité des plugins à la Avast: le mettre en "sandbox" afin qu'il évite de toucher à des contenus importants.
  32.  
  33. L.214 : Jun 30 19:31:29 <EvilSeph> we want to change Minecraft so that we stop trusting user input so much
  34. L.215 : Jun 30 19:31:41 <Grum> that should fix all the current exploits except xray
  35. L.217 : Jun 30 19:31:48 <Searge> all you need to ensure - no way for server admins to steal client credentials
  36. L.220 : Jun 30 19:31:57 <Grum> so no more floating, breaking blocks behind you, breaking 100 blocks in a second god knows what :P
  37.  
  38. -> Ils en ont marre de voir les serveurs dépendre trop des clients. Ils veuleent un changement radical dans les serveurs afin que le client soit moins maître. Ca permettra d'éviter pas mal de "hacks", sauf XRay, qui visiblement, dépend réellement du client.
  39.  
  40. L.223 : Jun 30 19:32:20 <Grum> this is however a MASSIVE change
  41. -> Grosses mises à jour, et gros changements en vue...
  42.  
  43. L.230 : Jun 30 19:33:00 <TkTech> Kulttuuri: Actually, the bandwidth usage will continue to be similar.
  44. -> En vue, pas de changement au niveau bande passante. Modems 56k, passez votre chemin :-°
  45.  
  46. L.246 : Jun 30 19:34:25 <medsouz> Will it be like Source where the server sends you the files you need when you join it?
  47. L.247 : Jun 30 19:34:32 <EvilSeph> medsouz, yes
  48. L.250 : Jun 30 19:34:55 <EvilSeph> we already started exploring that idea with texture packs
  49. L.258 : Jun 30 19:35:26 <Kulttuuri> well, sounds pretty nice if you can just join & server sends you all the blocks, items & textures. Is this where you are heading into?
  50. L.261 : Jun 30 19:35:37 <EvilSeph> Kulttuuri, that's the idea, yes
  51. -> Le client devra télécharger ce qu'il faut durant la connexion au serveur, comme pour les texture packs.
  52.  
  53. L.286 : Jun 30 19:37:59 <Grum> items have to be 'server wide' and blocks should be per world
  54. L.291 : Jun 30 19:38:26 <Grum> Searge: yes so the server stores which id's are stored for whick 'identifier' in some way
  55. L.296 : Jun 30 19:38:48 <medsouz> So every save will have "Stone" but what id is given to it can be different
  56. L.320 : Jun 30 19:40:37 <Searge> a completely dynamic ID assignment would also allow modders to disable parts of existing game mechanics, everyone talks about adding features - i have at least 5 mod ideas that basically just remove/disable mc features
  57. -> On risque d'avoir un gros changment niveau ID de blocks et items: ils ne pourraient ne plus être fixes. Cela permettrait une meilleure gestions des mécanismes de MC.
  58.  
  59. L.334 : Jun 30 19:41:40 <Jarvix> So what has to be in this API?
  60. L.335 : Jun 30 19:41:42 <EvilSeph> Searge, the dream is to make Minecraft completely modular
  61. -> Minecraft entièrment modulable, un rêve pour les daives! ^^ Pouvoir quasiment tout gérer. IMO MC, à ce moment encore plus un sandbox game qu'auparavant, car même le coeur du jeu pourrait être modifiable.
  62.  
  63. L.338 : Jun 30 19:41:49 <Searge> xie, technical would be "I want void removeBlock(int id)", basic concepts is "I want to disable features" :p
  64. L.339 : Jun 30 19:41:53 <EvilSeph> Hate creepers? Yank the Creeper plugin out
  65. L.340 : Jun 30 19:42:03 <Xie> Searge: fair point
  66. L.341 : Jun 30 19:42:04 <Grum> Searge: would be by string but yes
  67. -> Resultat: on pourrait choisir à son gré les blocks/entitées/items que l'on veut. Plus de creepers! Yay!
  68.  
  69. L.363 : Jun 30 19:44:30 <Grum> Ok, so just to make 1 thing clear; the idea is to *NEVER* need to break open the jarfile anymore
  70. L.372 : Jun 30 19:45:36 <EvilSeph> FlowerChild, the goal is to make mods no longer necessary
  71. L.373 : Jun 30 19:45:37 <Grum> FlowerChild: hacking open the jar you can always do
  72. L.382 : Jun 30 19:46:17 <LexManos> Mods will continue to exist due to that 5% that the API will never be able to cover.
  73. -> UN joueur n'aura plus à modifier les .jars! Mais 5% du jeu ne sera pas inclus dans l'API
  74.  
  75. L.444 : Jun 30 19:51:08 <medsouz> OptiFine for example
  76. L.445 : Jun 30 19:51:12 <Cojo> overriding the entity renderer
  77. L.446 : Jun 30 19:51:13 <Grum> optifine which way? shaders?
  78. L.447 : Jun 30 19:51:20 <Grum> Cojo: overriding it to do *what*
  79. L.448 : Jun 30 19:51:20 <medsouz> editing the rendering code
  80. L.449 : Jun 30 19:51:27 <Grum> edit it to do what?
  81. L.450 : Jun 30 19:51:31 <DV8FromTheWorld> run better
  82. L.451 : Jun 30 19:51:31 <Cojo> a whooooole lot
  83. L.454 : Jun 30 19:51:40 <UltraMoogleMan> Cojo: Why would you want to override the EntityRenderer?
  84. L.455 : Jun 30 19:51:44 <medsouz> be more efficient, work a bit differently, etc
  85. L.456 : Jun 30 19:51:44 <DV8FromTheWorld> bloody awesome
  86. -> Optifine dans Minecraft, voilà une bonne idée!
  87.  
  88. L.460 : Jun 30 19:51:53 <DV8FromTheWorld> my 15 FPS praises you
  89. -> LOL
  90.  
  91. L.471 : Jun 30 19:52:56 <TkTech> Then the ideal solution is not to allow overriding the entity render, but make it flexible enough to support these modifications with the API.
  92. L.472 : Jun 30 19:53:02 <Grum> UltraMoogleMan: yeah or of the skybox
  93. L.473 : Jun 30 19:53:09 <UltraMoogleMan> Grum: The block has a material that sets the fog uniform in the fragment shader
  94. L.474 : Jun 30 19:53:14 <Grum> TkTech: yes that is the idea
  95. -> Je vois parler de fragment shader. je sais que ça fait partie du rendu OpenG@h@L. Pourrions-npus avoir une gestion des shaders? GLSL?
  96.  
  97. L.522 : Jun 30 19:58:23 <ShaRose> which could be nice for mods
  98. L.523 : Jun 30 19:58:25 <Cojo> cows with guns mounted on their heads
  99. L.524 : Jun 30 19:58:28 <Cojo> that sounds awesome
  100. L.525 : Jun 30 19:58:29 <Grum> Searge: the server would tell the client that it needs the cow/gun assets and it would find them on the repo
  101. L.526 : Jun 30 19:58:31 <UltraMoogleMan> Searge: "I want to make custom cows with guns mounted to their heads" is really quite trivial, any modified models are sent in binary form to the client on connect
  102. -> Exemple avec un mod imaginaire: Si on accède à un serveur qui a des mods, il demandera au client de télécharger tel ou tel mod, et de l'integrer. Vive les vaches avec des pistolets sur leurs têtes!
  103.  
  104. L.533 : Jun 30 19:59:02 <Grum> another thing; we intend to change the models to *NOT* be code anymore
  105. L.534 : Jun 30 19:59:08 <ShaRose> thank god for that
  106. L.535 : Jun 30 19:59:12 <TkTech> Searge: That would be resolved by a more flexible model system.
  107. L.536 : Jun 30 19:59:14 <Searge> ok, so basically models are moved from hardcoded to some kind of model format
  108. -> On sépare les modèles 3D du code source du jeu. Enfin un système flexible de gestion des modèles 3D.
  109.  
  110. L.552 : Jun 30 20:01:14 <Snowl> Maybe a certain part of minecraft.net (dev.minecraft.net) for these resources?
  111. -> dev.minecraft.com pour contenir le ressources des mods?
  112.  
  113. L.593 : Jun 30 20:05:01 <ShaRose> http://pastebin.com/LSPFXS6F buttloads of questions that may or may not have been answered ahead etc
  114. -> Faudra y jeter un coup d'oeil, je l'ai pas fait.
  115.  
  116. L.657 : Jun 30 20:12:22 <DV8FromTheWorld> have you looked at the modbridge project?
  117. L.660 : Jun 30 20:12:36 <DV8FromTheWorld> you can add/enable/disable mods on the fly
  118. L.670 : Jun 30 20:13:48 <ShaRose> DV8FromTheWorld there's no magical support for enabling / disabling mods runtime, and afaik mojang wants to be able to do that anyways to disable mods the server doesn't want
  119. -> On ne pourra pas activer/désactiver à la volée des features.
  120.  
  121. L.721 : Jun 30 20:19:09 <Searge> that's another huge topic - future compatibility in the api ..?
  122. L.722 : Jun 30 20:19:24 <Grum> well ideally we do not do backwards incompatible changes
  123. -> Ils cherchent à avoir une compatibilité avec les anciens mods.
  124.  
  125. L.751 : Jun 30 20:22:29 <Xie> Or you can just use SpoutCraft? :P
  126. L.752 : Jun 30 20:22:33 <DV8FromTheWorld> :o
  127. L.753 : Jun 30 20:22:51 <ShaRose> actually, that's a fair point
  128. L.754 : Jun 30 20:22:53 <RoyAwesome> we are phasing out spoutcraft for our new engine
  129. -> Là, je ne sais pas si ils veulent se baser sur SproutCraft, ou les devancer.
  130.  
  131. L.820 : Jun 30 20:29:00 <medsouz> <GenuineSounds> Access modifiers: A flag saying "This mod uses this feature" would allow ANY mod using that feature to be disabled by default, That way you don't have to blacklist specific plugins if you don't want to. <GenuineSounds> Aka, perworld restriction of features, like plugins that add entities.
  132. -> Gestion intelligente des conflits de mods en vue. Eviter les crashs car deux mods par exemple modifient le même bloc.
  133.  
  134. L.915 : Jun 30 20:37:10 <Xie> Wouldn't your mod still have a website? The repo is for dev, and a host for the client to download it
  135. L.916 : Jun 30 20:37:11 <medsouz> Maybe sell server ads?
  136. L.917 : Jun 30 20:37:13 <sk89q> hosting hasn't really been a problem
  137. L.918 : Jun 30 20:37:19 <Corosus> i like that idea Searge
  138. L.919 : Jun 30 20:37:22 <medsouz> Like advertisement for Minecraft servers
  139. -> Iée de pubs pour les serveurs.
  140.  
  141. L.1002 : Jun 30 20:44:26 <EvilSeph> Obviously this discussion isn't really suited for covering specific topics about API design in detail - we'll use some other tool for that, like the issue tracker
  142. L.1003 : Jun 30 20:44:31 <TkTech> Grum: Bare with me, this is going to be a long message. This is my suggestion for the actual container for plugins. As previously suggested, the container is a ZIP (which is all a JAR is). Contained in the ZIP is three folders, which are: "Client", "Server", "Shared". Within each of the three folders is also a folder called "Assets". The contents of this folder is all the image, sound and general assets required by their res
  143. L.1004 : Jun 30 20:44:31 <TkTech> target. As for the API, these folders are exposed to the API by a VFS (Virtual file system) interface. Think vfs_open("client/images/background.png"). The root of this VFS is automatically the correct folder.
  144. L.1009 : Jun 30 20:45:01 <Grum> TkTech: yes; but some of the assets are really small; like models/blockmeshes etc
  145. L.1010 : Jun 30 20:45:11 <Grum> TkTech: so perhaps we do not have to have the extra seperation
  146. L.1011 : Jun 30 20:45:12 <TkTech> Grum: The Client folder can contain classes which are streamed to the client, who will execute them based on a permissions manifest and a client-side SecurityManager with a restrictive security polic.
  147. -> Idée de séparer les ressources du plugin en client/serveur. Cette idée reste un peu controversée, mais l'idée reste pas mauvaise: il ne s'agit que d'envoyer au client que ce qu'il a besoin.
  148.  
  149. L.1023 : Jun 30 20:46:06 <DV8FromTheWorld> yea, thats what i said. We need something to actually make the plugins use
  150. L.1023 : Jun 30 20:46:08 <Grum> furnace is not dynamic
  151. L.1023 : Jun 30 20:46:08 <RoyAwesome> furnace is static
  152. L.1023 : Jun 30 20:46:13 <Grum> its actually two blocks
  153. L.1023 : Jun 30 20:46:17 <DV8FromTheWorld> we can talk about how they are contained and distributed later
  154. L.1035 : Jun 30 20:47:02 <RoyAwesome> iirc, static data is going to be batched into the chunk, dynamic stuff (with animations) will be done in a seperate batch
  155. -> Ils veulent gérer un système d'animations propres aux blocs dynamiques: par exemple le furnace prend deux ids (éteint et allumé), ils veulent changer ce système pour qu'un seul id suffise pour plusieurs animations.
  156.  
  157. L.1077 : Jun 30 20:50:11 <Cojo> Corosus, getters and setters for ALL THE THINGS
  158. -> DEV JOKE: GET/SET ALL THE THINGS! \o/ (Le Java est langage objet, un objet est censé cacher ses variables, et donc implémenter des fonctions afin d'obtenir ou modifier ces valeurs. C'est par principe: on ne modifie pas directement les données d'un fichier par exemple, mon clavier va être en quelque sorte la fonction set, et l'écran la fonction get.)
  159.  
  160. L.1098 : Jun 30 20:51:22 <DV8FromTheWorld> *cough* native HD support *couigh*
  161. L.1172 : Jun 30 20:57:34 <Grum> AND mixed/matched mode; so if you have 64x64 textures and a mode adds a block but only has a 16x16 .. well, just handle it somehow
  162. L.1173 : Jun 30 20:57:35 <TkTech> *native support for arbitrary power-of-two texture packs
  163. L.1187 : Jun 30 20:58:39 <Searge-DP> well, using a modern shader based renderer will also easily allow to bind several textures and let the shader decide which one to use for each element redered, so you have multiple textures and still only need one render call
  164. -> Textures packs au dessus de 16*16 gérées? L'idée de shaders revient encore. Je rajoute qu'il me semble que le calcul dans les shaders est gére par la carte graphique... Le cpu en pourrait être allégé de ces calculs.
  165.  
  166. L.1188 : Jun 30 20:58:55 <Grum> Searge-DP: for 1.x we need to make an atlas
  167. -> Il me semblent qu'ils parlent de la version de OpenG@h@L.
  168. L.1201 : Jun 30 20:59:45 <UltraMoogleMan> RoyAwesome: As grum found when he profiled clients for about 30 minutes' worth of logins, only 5-10% of people don't support GL 2.x
  169. L.1217 : Jun 30 21:00:56 <Eloraam> using 3.3 has been a flat-out 10x speed boost http://i.imgur.com/n1MRD.png
  170. -> Un reconversion de MC en OpenGL 2.x serit en vue? Ou 3.3?
  171.  
  172. L.1226 : Jun 30 21:02:06 <Eloraam> http://i.imgur.com/xYup4.png my new game engine hehe.
  173. -> Avoue que ça fait rêver! :p EN même temps, il me semble que Notch avait déjà rajouté un système de lightning coloré
  174. L.1618 : Jun 30 21:34:10 <TkTech> Grum: Okay, now do "Create <N> new %s"
  175. -> (j'ai un peu zappé le début, mais l'idée est là) Rendre le système de langues automatiquement traduit, via un système à la Qt: Les traductions seraient basées sur la forme, et pas une simple base de données.
  176.  
  177. L.1849 : Jun 30 21:54:42 <Amaranth> protocol optimization is fun!
  178. L.1912 : Jun 30 22:00:47 <Searge> bundle packet every tick and send
  179. L.1913 : Jun 30 22:00:51 <Grum> yeah
  180. L.1914 : Jun 30 22:00:55 <Grum> or bundle certain types
  181. -> Optimiser les transferts serveurs/clients?
  182.  
  183. L.1930 : Jun 30 22:03:59 <EvilSeph> I just want to make it clear: this meeting is just the beginning. If you have any further input after the meeting, please feel free to bring it to our attention
  184. -> Avant tout: ce meeting ne sera que le début. On attend beaucoup de l'API, qui apportera en plus énormement de changement si ce qui s'est dit ici s'applique. D'autres mmetings seront peut-être organisés.
  185.  
  186. L.1963 : Jun 30 22:09:08 <EvilSeph> I just want to say thanks for everything you guys have done for the community and thanks for taking the time out of your day to be here today :)
  187. -> Fin du meeting. Merci d'avoir lu ce petit pavé. J'ai volontairmeent zappé par exemple une grande partie concernant les modèles 3D, car ce 'était que du blabla, mais les idées principales, telles que je les vois restent ici.
  188.  
  189. Eiyeron Fulmicendii.
Advertisement
Add Comment
Please, Sign In to add comment
Public Pastes
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!