Difference between revisions of "Talk:Programming"
m (→Moving Forward) |
|||
(3 intermediate revisions by 2 users not shown) | |||
Line 19: | Line 19: | ||
While a bit more work up front, this would allow for far less manual page creation (at least, I assume, Textor, that you've been doing it manually, if the history of [[Sandbox.ModAPI.Ingame.IMyAssembler]] is any indication). With this out of the way, we could focus on writing more human-critical articles and leave the machine's work to the machines. Thoughts? [[User:Ketura|Ketura]] ([[User talk:Ketura|talk]]) 16:06, 12 January 2015 (UTC) | While a bit more work up front, this would allow for far less manual page creation (at least, I assume, Textor, that you've been doing it manually, if the history of [[Sandbox.ModAPI.Ingame.IMyAssembler]] is any indication). With this out of the way, we could focus on writing more human-critical articles and leave the machine's work to the machines. Thoughts? [[User:Ketura|Ketura]] ([[User talk:Ketura|talk]]) 16:06, 12 January 2015 (UTC) | ||
::Templates would be immensely helpful. I've been pecking away at the base classes-- once all the base classes are done, converting them into a template to allow each block to display its parent's members (those base classes I mentioned) will cut down 90% of the work. Most block interfaces only have a couple of unique properties and methods, and several have no unique properties or methods.[[User:Textor|Textor]] ([[User talk:Textor|talk]]) 16:21, 12 January 2015 (UTC) | ::Templates would be immensely helpful. I've been pecking away at the base classes-- once all the base classes are done, converting them into a template to allow each block to display its parent's members (those base classes I mentioned) will cut down 90% of the work. Most block interfaces only have a couple of unique properties and methods, and several have no unique properties or methods.[[User:Textor|Textor]] ([[User talk:Textor|talk]]) 16:21, 12 January 2015 (UTC) | ||
+ | :::I would prefer all API related pages be created in the API namespace. --[[User:Draygo|Draygo]] ([[User talk:Draygo|talk]]) 05:13, 13 January 2015 (UTC) | ||
+ | ::::I've created several base block templates and constructed [[Sandbox.ModAPI.Ingame.IMyBeacon|IMyBeacon]] out of it. Take a look and let me know what you think-- using the templates, it will allow us to type only the unique properties and methods into the page. As for your API namespace point, I'll start migrating the pages into that for you, Draygo.[[User:Textor|--Textor]] ([[User talk:Textor|talk]]) 06:08, 13 January 2015 (UTC) | ||
== Steam Group == | == Steam Group == | ||
Line 27: | Line 29: | ||
==API Categories/Name Format== | ==API Categories/Name Format== | ||
I've noticed that we've got a few API categories and name formats that are basically, Sandbox/ModAPI/Ingame etc. I propose we change all of these to Sandbox.ModAPI.Ingame instead, since it matches how programmers (modders and in-game) would normally access namespaces, so it comes more naturally to search with . instead of / when looking for something in particular.[[User:Textor|Textor]] ([[User talk:Textor|talk]]) 04:53, 13 January 2015 (UTC) | I've noticed that we've got a few API categories and name formats that are basically, Sandbox/ModAPI/Ingame etc. I propose we change all of these to Sandbox.ModAPI.Ingame instead, since it matches how programmers (modders and in-game) would normally access namespaces, so it comes more naturally to search with . instead of / when looking for something in particular.[[User:Textor|Textor]] ([[User talk:Textor|talk]]) 04:53, 13 January 2015 (UTC) | ||
+ | :It's because webpages are delineated by /'s. Ill have to rework some templates but it should be fine to do this. --[[User:Draygo|Draygo]] ([[User talk:Draygo|talk]]) 05:12, 13 January 2015 (UTC) |
Latest revision as of 06:08, 13 January 2015
I'm thinking that for organizational and readability purposes we should split this off into smaller documents, like the API docs for modding. At the moment, this page is pretty overwhelming to look at. We should also make a new category: Programmable Block (or similar) so we can tag overlaps in the API documentation and not reinvent the API wheel for every interface.Textor (talk) 07:09, 9 January 2015 (UTC)
- Agreed. In the official Modding Guide, Keen mentions that they eventually want 3 different types of customization, all of which technically exist now but still need to be completely fleshed out. These three are in-game Scripting (which we just got), workshop-friendly API Modding, and then *.dll modding, roughly in this order from least to most impactful/difficult. At the very least we need things to be divided along those three lines. I'm thinking further divisions could also exist for Mechanics, Guides, and Documentation, which would explain, respectively, What This Is And How to Use It, Changing Things 101, and References, roughly targeting most players, new modders, and experienced modders. This makes about 9 different base articles, with perhaps some satellite in-depth ones as well. Thoughts? Ketura (talk) 09:09, 9 January 2015 (UTC)
- Sounds good. I think tutorials should also get difficulty tags, so we may want to make three tutorial categories: beginner, intermediate, and advanced so that the difficulty of the concepts can be more easily classified and filtered. If each interface was given its own page (which I think they started doing on the API side) we can also have a section for notes, in case any interesting facts or quirks are discovered that are significant enough to justify noting on the wiki page for that entry. I think we can contain everything about an interface on the interface's page, however-- I don't see the need to divide the interface into individual properties, methods, and events. Each one would have little individual information and would be better suited to the main interface article.Textor (talk) 12:00, 9 January 2015 (UTC)
- Agreed on all points. I think first order of business is to get a couple top-level API pages up, something that's got more red links than...something with a lot of red links. Pages like this make it simpler to see what needs to yet be created. Also a page listing the sort of information we can expect to have, that acts as a sort of table of contents. I also have a list of URLs at http://www.spaceengineerswiki.com/Talk:Programmable_Block that can be referenced to see the sort of stuff we'd like to go over.
- Sounds good. I think tutorials should also get difficulty tags, so we may want to make three tutorial categories: beginner, intermediate, and advanced so that the difficulty of the concepts can be more easily classified and filtered. If each interface was given its own page (which I think they started doing on the API side) we can also have a section for notes, in case any interesting facts or quirks are discovered that are significant enough to justify noting on the wiki page for that entry. I think we can contain everything about an interface on the interface's page, however-- I don't see the need to divide the interface into individual properties, methods, and events. Each one would have little individual information and would be better suited to the main interface article.Textor (talk) 12:00, 9 January 2015 (UTC)
- There really needs to be like a wiki IRC or something. Ketura (talk) 07:13, 11 January 2015 (UTC)
- Like steam chat? We had a group of people working on importing and creating API documentation but then they just dropped the project suddenly. --Draygo (talk) 12:02, 11 January 2015 (UTC)
- Steam chat could work. Is there a steam group already set up for wiki editors? That sort of thing could work nicely for more than one thing.
- Like steam chat? We had a group of people working on importing and creating API documentation but then they just dropped the project suddenly. --Draygo (talk) 12:02, 11 January 2015 (UTC)
- There really needs to be like a wiki IRC or something. Ketura (talk) 07:13, 11 January 2015 (UTC)
- At any rate, I keep getting sidetracked when trying to get work done on this. Tomorrow I'm going to try and come up with a list of things that need made to at least act as a rough starting point. Ketura (talk) 14:25, 11 January 2015 (UTC)
- [1] - My profile on steam. --Draygo (talk) 01:02, 12 January 2015 (UTC)
Moving Forward
I've created a page at Scripting_API_Documentation which probably shouldn't stay there, but it works for now. It mirrors my attempt at API_Documentation (which I stopped working on when I couldn't get the docs to compile fully for the Modding API like Cuber did). As you can see, all of four pages in those gigantic tables have been made (thanks to Textor). This essentially just acts as a to-do list to facilitate which pages need made.
Now, as for how these pages should be built, I think that someone who's more familiar with the way Semantic works should help us get some templates together. I have seen how powerful generated pages can be while working on Blocks and some other pages, but while I can hack things together where I have examples to work from I don't know how to design them from scratch. It seems that's where the previous team that worked on the API attempted to start at, at any rate. I assume this would mean we would have to create raw *.xml files or something that would contain a definition of the class or whatever, and use #ask to produce the actual pages (a rudimentary version of this can be seen at this page here).
While a bit more work up front, this would allow for far less manual page creation (at least, I assume, Textor, that you've been doing it manually, if the history of Sandbox.ModAPI.Ingame.IMyAssembler is any indication). With this out of the way, we could focus on writing more human-critical articles and leave the machine's work to the machines. Thoughts? Ketura (talk) 16:06, 12 January 2015 (UTC)
- Templates would be immensely helpful. I've been pecking away at the base classes-- once all the base classes are done, converting them into a template to allow each block to display its parent's members (those base classes I mentioned) will cut down 90% of the work. Most block interfaces only have a couple of unique properties and methods, and several have no unique properties or methods.Textor (talk) 16:21, 12 January 2015 (UTC)
- I would prefer all API related pages be created in the API namespace. --Draygo (talk) 05:13, 13 January 2015 (UTC)
- I've created several base block templates and constructed IMyBeacon out of it. Take a look and let me know what you think-- using the templates, it will allow us to type only the unique properties and methods into the page. As for your API namespace point, I'll start migrating the pages into that for you, Draygo.--Textor (talk) 06:08, 13 January 2015 (UTC)
- I would prefer all API related pages be created in the API namespace. --Draygo (talk) 05:13, 13 January 2015 (UTC)
- Templates would be immensely helpful. I've been pecking away at the base classes-- once all the base classes are done, converting them into a template to allow each block to display its parent's members (those base classes I mentioned) will cut down 90% of the work. Most block interfaces only have a couple of unique properties and methods, and several have no unique properties or methods.Textor (talk) 16:21, 12 January 2015 (UTC)
Steam Group
I've created a Steam group at http://steamcommunity.com/groups/SE-Wiki . It's public. I don't know what I'm doing. Should probably put up an article that's linked on the main page that talks about it. Ketura (talk) 16:07, 12 January 2015 (UTC)
API Categories/Name Format
I've noticed that we've got a few API categories and name formats that are basically, Sandbox/ModAPI/Ingame etc. I propose we change all of these to Sandbox.ModAPI.Ingame instead, since it matches how programmers (modders and in-game) would normally access namespaces, so it comes more naturally to search with . instead of / when looking for something in particular.Textor (talk) 04:53, 13 January 2015 (UTC)