Ask A Pro Renewal Project (and How You Can Help!)

The forums have grown significantly in the last few months. We've had many new members come through and ask questions, many of them repeats of similar questions that have been asked many times. We also have had many more members posting answers to questions in recent weeks than we have in the past. As it always goes when forums or other online communities grow, it is easy for the Signal to Noise ratio to drop. "Signal to Noise ratio" is a term used to describe the ratio of usable information to useless information, usually in reference to radio communications. Higher is better.

To that end, one change that might be noticed is an increased level of moderation. Posts which do not contribute to the topic or which add incorrect or misleading information will be more likely to be removed or edited, as appropriate. Do not take this personally. The point of Ask a Pro is to provide an environment in which people can ask any question about coding for ComputerCraft, no matter how simple or complex, and receive useful information that answers their question in a relatively timely manner. Answer posts that add false or misleading information are directly counter to that goal. It's all about the quality and correctness of answers here. On-topic discussion about the question or problem presented is always welcome, of course.

Hand in hand with wanting high-quality answers is wanting to provide resources for people to find answers to their own questions quickly. It is demotivating to question answerers to have to answer the same "use == in if statements" or "use parentheses when calling functions" sorts of things all the time. Providing better self-help resources can help filter out the simpler questions if users are able to figure out the answers themselves. I'll be working on a better read-this-first topic that will cover most common errors and simple Lua questions.

A better sticky post can only cover so much information, though. We need a good, high-quality set of tutorials written in a consistent manner and covering topics in a sensible progression of complexity. We have some good tutorials already, but they vary stylistically and in scope, and there is very little in the way of natural progression. I envision a more tree-like structure wherein a user could pick a subject that interests them (such as using a touchscreen monitor) and follow a series of tutorials that would help them learn about the parts of ComputerCraft they will need to know in order to create what they want. The stylistic guidelines I am currently thinking of are as follows (subject to change):

- Do not use Object-Oriented design except if absolutely necessary
- Use best coding practices as far as it does not detract from readability.
- Link to high-quality documentation.
- Link to other tutorials in the series as appropriate.
- Do not comment code heavily, as this detracts from the readability of the code.
- Use code blocks for all code.
- Talk about the intent of code and the general design of the flow in plain English.
- Provide more technical descriptions of what happens in each code example (excepting previously explained code) after each code block.
- Use images if a pictorial explanation is required; avoid ASCII art unless necessary.
- Use in-game images, not emulator images, if terminal images are required.

These stylistic guidelines are open to input from the community. Using these guidelines, here is how I see the rough categorization of the tutorials:

Spoiler

Computer basics - crafting normal/advanced/turtle, command line, Lua prompt, startup, cd, ls - draft
Computer basics - help, programs, label, id, cp, mv, rename, mkdir - draft
Computer basics - crafting disk drives/floppies, use of drives, labeling disks, dying disks - draft

Peripheral basics - isPresent, getType, getMethods, wrap, call - draft
Peripheral intermediate - printer

Monitor basics - peripheral wrapping, manual calls, term redirect.
Monitor intermediate - touches, color-change single button example

Turtle basics - move, turn, refuel, dig, place, attack - draft
Turtle intermediate - suck, drop, getStackSize, detect, compare
Turtle intermediate - compareTo, getSpaceInSlot, transferTo, craft
Turtle intermediate - failproofed mining movements (gravel safe etc.) - draft
Turtle advanced - chest sorter example
Turtle advanced - mining with inventory tracking example
Turtle advanced - gravel to arrows example

Modem basics - range, rednet API
Modem basics - wired modems
Modem intermediate - channels, modem.send, rednet explained/reimplemented example
Modem intermediate - remote peripherals

Redstone basics - getInput, getOutput, setOutput
Redstone intermediate - bundled input & output, colors API, colors.combine & subtract
Redstone advanced - example redset/redpulse type programs to change a single color's state

Term basics - .write, .clear, .setCursorPos, .getCursorPos
Term basics - .getSize, .scroll, .clearLine, .setCursorBlink
Term basics - .isColor, .setTextColor, .setBackgroundColor
Term intermediate - redirect, restore, creating a redirect that writes to part of the screen, issues with using term.* in redirects.
Term intermediate - breakdown/reimplementation of bios write() - draft
Term advanced - using redirects to make a simple "chat" program (no rednet, etc.)

Event basics - key, char, timer, redstone, press any key with timeout example - draft
Event intermediate - mouse_click, drag, scroll, clickable button with dragging for color change (not all users have scroll wheels)
Event advanced - key and click menu example
Event advanced - timed click game

API basics - purpose for using, functions in APIs, simple example API - draft
API intermediate - data in APIs, when appropriate, use and effect of local in APIs - draft
API advanced - datatype APIs, vector API breakdown/reimplementation. - draft

Note that some of the tutorials are rather specific about the order of things and the examples used. If it seems like some of the tutorials don't cover very many topics, be aware that the idea is to go in-depth on each subject contained within. This outline is a rough draft, and community input is both welcomed and desired. If there are existing tutorials that match well with one of the subjects listed above and could be adapted/fleshed out (if necessary) to fit, please link it in this topic. I'll talk to AfterLifeLochie to see if the Wiki will be able to do what I'd ideally like to do with the tutorials.

I quite like the direction you're heading with this. A lot of these points are valid and I agree with the structure of the tutorials. Just three questions though.

Lyqyd, on 31 July 2013 - 02:24 PM said:

- Do not use Object-Oriented design except if absolutely necessary

I'm assuming that if someone has used an OO design, or if the programmatic design largely benefits from an OO design would really be the only times we can use it then?

Lyqyd, on 31 July 2013 - 02:24 PM said:

Using these guidelines, here is how I see the rough categorization of the tutorials:
-snip-

I've noticed that OO design stuff isn't listed… So no tutorials on it?

Lyqyd, on 31 July 2013 - 02:24 PM said:

Term intermediate - redirect, restore, creating a redirect that writes to part of the screen, issues with using term.* in redirects.

I'm assuming that we can also use some metatables examples for redirect objects so that not all functions do not need to be implemented…

So we are going to get a lot more sub forums under Ask a pro? I agree with theoriginalbit. You can PM me if you need some help.

theoriginalbit, on 01 August 2013 - 01:10 AM said:

I quite like the direction you're heading with this. A lot of these points are valid and I agree with the structure of the tutorials. Just three questions though.

Lyqyd, on 31 July 2013 - 02:24 PM said:

- Do not use Object-Oriented design except if absolutely necessary

I'm assuming that if someone has used an OO design, or if the programmatic design largely benefits from an OO design would really be the only times we can use it then?

Lyqyd, on 31 July 2013 - 02:24 PM said:

Using these guidelines, here is how I see the rough categorization of the tutorials:
-snip-

I've noticed that OO design stuff isn't listed… So no tutorials on it?

Lyqyd, on 31 July 2013 - 02:24 PM said:

Term intermediate - redirect, restore, creating a redirect that writes to part of the screen, issues with using term.* in redirects.

I'm assuming that we can also use some metatables examples for redirect objects so that not all functions do not need to be implemented…

The idea behind discouraging/disallowing Object-Oriented designs is that, for the purposes of the tutorials, they generally won't be necessary. OO in Lua adds a layer of confusion for new users, and that wouldn't be helpful for the purposes of a tutorial. I'd prefer if, even for the term example, things were not automatically generated with metatable magics unless not doing so would be more detrimental to the usefulness of the tutorial. As for tutorials for OO, there are many external resources that cover that need adequately. The "data type" example/tutorial under APIs should cover the need for it aside from those resources. If it is found that that does not suffice, we can add content down the road.

Jappards, on 01 August 2013 - 03:57 AM said:

So we are going to get a lot more sub forums under Ask a pro? I agree with theoriginalbit. You can PM me if you need some help.

I'm not sure where you read anything about adding sub forums.

I don't see any Lua tutorials in your list. Will new users learn Lua from PIL, then post here when they can't figure out why the io library doesn't work quite right in CC?

Edit: There should be something about not posting solutions with code that's hard to understand for the asker, e.g. here - "Q: How do I wait for X broadcast messages?" "A: Copy-paste this magic function, then use it like this"

Edit 2: Also answers that are just plain wrong - "os.pullEventRaw = os.pullEvent makes sleep not work"

I like this. The AaP section of the forums has been cluttered with repetitive questions for far too long now.

I do have a question about one of your points however:

Lyqyd said:

- Use in-game images, not emulator images, if terminal images are required

For the majority of my time I am on a computer that cannot handle Minecraft very well, and as such I always use an emulator whenever I'm doing ComputerCraft programming. Is it acceptable in circumstances such as this to use an emulator for screenshots? If not, why? I have never encountered any differences in runtime between MC and an emulator besides performance issues with the former.

immibis, on 01 August 2013 - 07:37 PM said:

I don't see any Lua tutorials in your list. Will new users learn Lua from PIL, then post here when they can't figure out why the io library doesn't work quite right in CC?

Edit: There should be something about not posting solutions with code that's hard to understand for the asker, e.g. here - "Q: How do I wait for X broadcast messages?" "A: Copy-paste this magic function, then use it like this"

Edit 2: Also answers that are just plain wrong - "os.pullEventRaw = os.pullEvent makes sleep not work"

The PIL is a great resource. I agree that we may find that not having any straight Lua tutorials in this set won't work out as well as it might, so I wouldn't be surprised if we have to take a look at adding them down the road. To begin with though, I'd like to mostly concentrate on ComputerCraft specific things, and link to PIL or the Lua Reference Manual as necessary for more details on the actual language constructs being used. I'd imagine that file IO is probably a section that needs to be added, so I'll look at a good structure that might fit in well with the rest of this model.

For your first edit, I agree completely. Ask a Pro should be about helping someone learn to code things on their own, not simply regurgitating code at them. There are obvious exceptions, such as when the scope of their question is beyond what we can reasonably handle, but even then, it's best to link things as resources and starting points/inspiration rather than simply telling them to go use the existing code.

Thank you for pointing out that post. It has been taken care of. Please feel free to use the report button on any posts containing false information like that one.

Bubba, on 01 August 2013 - 08:54 PM said:

I like this. The AaP section of the forums has been cluttered with repetitive questions for far too long now.

I do have a question about one of your points however (- Use in-game images, not emulator images, if terminal images are required)

For the majority of my time I am on a computer that cannot handle Minecraft very well, and as such I always use an emulator whenever I'm doing ComputerCraft programming. Is it acceptable in circumstances such as this to use an emulator for screenshots?

They would be fine on a temporary basis, but should be replaced with in-game shots as soon as possible. If you are unable to provide in-game screenshots at all, let me know and we may be able to arrange something. I don't consider this a deal-breaker and would not reject good tutorial content because of images taken in an emulator.

Lyqyd, on 01 August 2013 - 09:06 PM said:

They would be fine on a temporary basis, but should be replaced with in-game shots as soon as possible. If you are unable to provide in-game screenshots at all, let me know and we may be able to arrange something. I don't consider this a deal-breaker and would not reject good tutorial content because of images taken in an emulator.

Okay, thank you.

I also have a suggestion for the tutorial portion of this undertaking. I've thought for a long time that the tutorials that many of us write on the forums do not have enough input from other members, and as such suffer from a variety of issues ranging from style, coding habits, unexpected behavior, and more. It would be neat if someone (I would be willing to do it, if given permission) were to make a Google Drive folder that could contain peer edited tutorials. To edit a tutorial, a user could apply via a PM or email (much like the wiki, but probably more restrictive).

I know this sounds a lot like the wiki we currently have, but what I'm thinking of would be held to a very high standard and would read more like the PIL. In other words, it would flow sequentially from one tutorial to the next, and users would not just write them about whatever they felt like.

Thoughts?

I still need to poke AfterLifeLochie about this (as I alluded to in the first post), but I'd like to set up a category or group of pages on the Wiki that would be editable only by a certain subset of the existing editors, but that everyone would be able to edit the talk pages for, so that the high-quality and consistency aspects you mention will be more easily accomplished, while not completely restricting who can submit content to them. I'd also prefer to keep the content within the existing ecosystem of the computercraft.info site, so they will either have to be on the Forum or on the Wiki.

Can we have a rule against not posting code or exact errors?

After having read through the thread something occured to me :
Perhaps we should have a set of guidelines or something along those lines for answering questions?
Things like "Don't create code for them" and "If you say 'you need to do x', then you need to link to 'x' on the wiki"?
I feel like that would be immensely helpful for everyone, especially the people answering questions.
I'd be more than happy to write up a list of guidelines for this if you would like me to, Lyqyd.

~Sora

I really get why there are coming changes to AaP plus a few more tutorials. But the real thing is that most of us dont look things up. I mean really, people come here to ask about coroutines, but if they google 'lua coroutines' they get a pretty good tutorial on coroutines. The thing Im getting at is, people do not often look on the wiki, to look up a function. For example person x needs a function, but that person havent done any resarch because we are humans and most of us are lazy. Of course there are people who are looking it up, excellent, but not too many people who come to ask questions in AaP dont do that often.

When it gets decided that it is going to be a sticky, presumabily not, people still dont look often there. That is just because most of the times people have a question and want an answer, they dont search first. However it is in the guidelines to read a sticky with 'READ ME' or something similair, you should read it. At this point I have seen enough people getting banned because they dont read the rules first. Their choice, of course, but the point is that we as humans go our own way. We do what we want.

However, I have to say that in this community somebody is going to get banned if they dont follow the rules, which I really appreciated. At this point Im rambling :P/>

Sora the Hedgehog, on 02 August 2013 - 02:21 AM said:

After having read through the thread something occured to me :
Perhaps we should have a set of guidelines or something along those lines for answering questions?
Things like "Don't create code for them" and "If you say 'you need to do x', then you need to link to 'x' on the wiki"?
I feel like that would be immensely helpful for everyone, especially the people answering questions.
I'd be more than happy to write up a list of guidelines for this if you would like me to, Lyqyd.

~Sora

I'm not really sure what to think about this.

On one hand, having guidelines is very nice from a moderation aspect and would allow for uniform expectations.
On the other hand, guidelines could put strictures on the teaching methods that some people use with success. For example, not everyone teaches by giving links to learning resources. Some people actually write out the code and then heavily comment it, and sometimes this approach is better depending on the situation.

I'd say that the only guideline should be:
1) Give correct and full information
2) Explain everything
3) Be clear and understandable

If it gets any more restrictive than that, people are going to end up nit-picking the type of response that's given rather than the actual quality of the response.

However, that being said I would like to see what kind of guidelines you have in mind. Just try to keep it as open-ended as possible though so that we don't limit the responses we're getting.

I don't want to sound patronizing or hostile when I say this, but many of the AaP topics asked which can be answered by a link to PIL etc. can also be answered by google. It seems that many of the people asking these questions either didn't think to google their question first or just didn't know what to google.

But it seems there should be a clear post explaining and giving advice one what to google, or what and where to search to answer your own questions. New tutortials and all that are great, but that won't miracurously make all these people suddenly use the tutorial section. It needs to be very obvious that there are other ways of finding out their answer other than just asking it in AaP.

I don't really have any ideas how this second part could be solved, but the first part seems obvious, a detailed and friendly post that explains where and how to find the answers to some of your questions.

billysback, on 02 August 2013 - 06:58 AM said:

I don't want to sound patronizing or hostile when I say this, but many of the AaP topics asked which can be answered by a link to PIL etc. can also be answered by google. It seems that many of the people asking these questions either didn't think to google their question first or just didn't know what to google.

But it seems there should be a clear post explaining and giving advice one what to google, or what and where to search to answer your own questions. New tutortials and all that are great, but that won't miracurously make all these people suddenly use the tutorial section. It needs to be very obvious that there are other ways of finding out their answer other than just asking it in AaP.

I don't really have any ideas how this second part could be solved, but the first part seems obvious, a detailed and friendly post that explains where and how to find the answers to some of your questions.

It looks to me like the Useful Tutorials & Resources topic needs to be updated a little with this in mind (or just in general - it could be a very useful index of quality tutorials). If people would like to help out in this respect, I've made a Google Drive document open to the public. Go ahead and add anything that you think would be useful the doc and I'll see about adding it in. I can't guarantee that it will be added to the topic, but it would be nice to see what people think should be in an introduction to the AaP forum.

I'm very glad to see the level of response and conversation this post has generated. I feel like many of the regular contributors are of a similar mind on this.

immibis, on 02 August 2013 - 12:27 AM said:

Can we have a rule against not posting code or exact errors?

Rules require enforcement, and rules such as these applying to questions would remove legitimate questions about fundamentals and approaches, and give a sour taste to newcomers who didn't have their question post exactly in order the first time. I think this would have the effect of closing off the Ask a Pro section more than it would help. One of the goals of Ask a Pro is being friendly to newcomers, as this is many members' first exposure to the forums as a whole. Ask a Pro needs to be a positive part of the community. Other measures, such as a revamp of the sticky threads, may help cut down on questions about a program that don't contain code, etc.

Sora the Hedgehog, on 02 August 2013 - 02:21 AM said:

After having read through the thread something occured to me :
Perhaps we should have a set of guidelines or something along those lines for answering questions?
Things like "Don't create code for them" and "If you say 'you need to do x', then you need to link to 'x' on the wiki"?
I feel like that would be immensely helpful for everyone, especially the people answering questions.
I'd be more than happy to write up a list of guidelines for this if you would like me to, Lyqyd.

~Sora

Guidelines, perhaps, but certainly not rules. We don't want to get overly prescriptive with answer posts, either. Any answer with good information is useful, though some are more useful than others. Perhaps a "Philosophy of Ask a Pro" for answer-posters would be helpful to guide the style of answers, but flexibility is good, since we cannot foresee all of the innumerable exceptions to a set of rules.

billysback, on 02 August 2013 - 06:58 AM said:

I don't want to sound patronizing or hostile when I say this, but many of the AaP topics asked which can be answered by a link to PIL etc. can also be answered by google. It seems that many of the people asking these questions either didn't think to google their question first or just didn't know what to google.

But it seems there should be a clear post explaining and giving advice one what to google, or what and where to search to answer your own questions. New tutortials and all that are great, but that won't miracurously make all these people suddenly use the tutorial section. It needs to be very obvious that there are other ways of finding out their answer other than just asking it in AaP.

I don't really have any ideas how this second part could be solved, but the first part seems obvious, a detailed and friendly post that explains where and how to find the answers to some of your questions.

Reworking the sticky posts and providing a better set of titles is on my personal agenda. One of them will contain a common list of errors, and show what causes them and what to look for in one's own code. That post will probably also contain an index of links to the entire tutorial series laid out in the original post.

billysback, on 02 August 2013 - 06:58 AM said:

I don't want to sound patronizing or hostile when I say this, but many of the AaP topics asked which can be answered by a link to PIL etc. can also be answered by google. It seems that many of the people asking these questions either didn't think to google their question first or just didn't know what to google.

But it seems there should be a clear post explaining and giving advice one what to google, or what and where to search to answer your own questions. New tutortials and all that are great, but that won't miracurously make all these people suddenly use the tutorial section. It needs to be very obvious that there are other ways of finding out their answer other than just asking it in AaP.

I don't really have any ideas how this second part could be solved, but the first part seems obvious, a detailed and friendly post that explains where and how to find the answers to some of your questions.

*cough* shameless plug *cough* How to Google tutorial I made a while back, conveying the same thoughts… link…

I definitely do agree though. Most things can be solved by Google, and most people seem to not think of Googling…

I've written up those answering guide lines, look at them them here : http://www.computercraft.info/forums2/index.php?/topic/14514-people-answering-questions-please-read/

~Sora

Here's a draft of a "common errors" section for the sticky post revamping. I'd like feedback on whether the phrasing of any of these is confusing, and suggestions for any other common error messages that we see a lot, if any.

---

attempt to index ? (a nil value)

This means that you've tried to access a key of a table that doesn't exist. If you're not working directly with tables, check the API call at the line number the error specifies (like `turtle.forward()` and such) to be sure that you haven't misspelled the name of the API. If for instance, you had `trutle.forward()` or `Turtle.forward()`, those would both result in this error.

attempt to call nil

This means that you are trying to use a function that doesn't exist! Check the line number the error specifies to be sure you've spelled the function name correctly, and check through the documentation to make sure that the function you're trying to use exists in your version of ComputerCraft.

'then' expected

Look at the line the error is on and the line above it. This error usually means that your conditional expression for your if statement is malformed (or that you're actually missing your `then`). Make sure you're using the comparison operator (==) instead of the assignment operator (=) if you're checking for equality.

'=' expected

When the interpreter throws this error, it means that it was expecting you to reassign a variable to a new value. Check the line number of the error and the line above it, and look for function calls that are missing their parentheses. Be sure to carefully read the code to ensure that you aren't misspelling keywords (like elesif instead of elseif).

'end' expected

An "end expected" error means that your code has more block-starting statements than end statements. Many statements start blocks (if, for, while, repeat, do, function), and each time you use a block-starting statement, you must end it. Each of those (except repeat, which must be ended by an `until`) should be ended by an `end` statement. Each if statement needs only one end, regardless of how many elseif statements it also contains.

'eof' expected

This error is the opposite of the previous error. Instead of too few block-ending statements, you have too many. The interpreter throws this error when it reaches an `end` (or an `until`) that doesn't close a block you've previously opened. Verify that each of your ends and untils match their opening statements.

too long without yielding

Yield protection is a ComputerCraft-specific issue, due to the nature of the Java side handling of the Lua environment for the computers. This message means that your program has run for ten seconds without yielding, which usually means you have an infinite loop that is constantly running. You can fix this simply by adding a sleep(0), but it's better to determine how often your code actually needs to run and use an os.pullEvent() to wait for the events it needs. For instance, a loop which looks at changes in redstone state could include an os.pullEvent("redstone") to wait for changes in redstone state before iterating through the loop again.

java.lang.ArrayIndexOutOfBoundsException: 256

This is frequently caused by using a function that calls itself to create an infinite loop. You should instead use an actual loop structure. Most commonly, for infinite loops, you would use `while true do` to begin the loop and `end` to end it. To exit the loop, you could use the `break` keyword. If you actually need to use recursive functions, you can use proper tail-calls where possible to avoid overflowing the stack. However, if all you need is an infinite loop, it is preferable to use an actual loop instead. Here is a simplified example of creating an infinite loop with recursion, and the same function with a proper tail-call:

--this function will throw the error
function printMany()
  print("text")
  sleep(0)
  printMany()
end

--this function will not
function printMany()
  print("text")
  sleep(0)
  return printMany()
end

--but you should do this instead, wherever you can.
function printMany()
  while true do
	print("text")
	sleep(0)
  end
end

Multiple points

This error is throw when the Lua interpreter thinks you've tried to create a number with multiple decimal points in it (such as 1.0.0). This error tends to crop up when concatenating numbers into strings. If you need a number with multiple points for some reason (such as version numbering), you'll want to use a string.

---

And here's a draft of advice to users posting questions.

---

When creating a question topic, be sure to fully explain your question. If you're having a problem with a piece of code, you should explain three things about it. Explain what you're trying to do, the big picture goal for the program. You won't need a huge amount of detail for this necessarily, but it helps to know where you intend to take the project. Next, explain what you expect the piece of code that you're having trouble with to do. Finally, explain what the code is actually doing instead of what you want it to do. This will help us get started on answering your question effectively. Be sure to include the latest copy of your code, and the full error message text if you receive an error while running it. It is very important that we see your code and the full error message (if any) so that we can help you diagnose and correct your code as quickly as possible.

If your code isn't too long (around 200 lines or less), it's okay to post it in the forums in code tags. Place [co<b></b>de] before your code and after. Make sure that there is no formatting on the text of the code when you post it, as the code block will format your code for you. If your code is too long, it is suggested that you post it to pastebin and provide a link to the paste in your post. If you cannot copy and paste the code (for instance, it is on a server and you cannot access the files), and you have to copy it out by retyping it, please be extra certain to verify that every character matches exactly in the code. It is very frustrating for both the person seeking help and those trying to help if we are trying to debug code that you're not actually using.

Over the course of your question topic, you may require additional help after your initial problem is solved. Each time you need to ask a further question, please re-post the code into your reply in that topic if it has changed since the last time you posted it. We cannot guess the exact changes you've made, and so it is necessary to see the updated code. You should use a single topic for all of your questions on one piece of code, as it is easiest for the answer posters to see the history of the code all in one place, and it prevents multiple people from providing the same advice in two different topics if they see subsequent problems in your code.

When choosing a topic title, make sure to use something descriptive of your question. For instance, "lua error" is a bad topic title, but '[string "woodcutter"]:13: attempt to index ? (a nil value)' is a good topic title. It is always advisable to use the full text of your error message if you are receiving one (and you cannot solve it by consulting the "common errors" guide). The first one ("lua error") isn't very descriptive. Of course you have a Lua question! The second title is much better, as it gives answer posters an idea of the problem before they even open the topic. If your question is more general, use an appropriately descriptive topic title that gets to the center of your question, like "How do I retrieve data from a broken computer?", or "What do I pass to parallel.waitForAll?"

Some questions, as alluded to above, aren't about a specific piece of code at all, but rather are more general in nature. For these sorts of questions, it's still helpful to give a lot of information about what you're trying to do or why you're needing the information. The more information you give, the better we can answer your question, and point you to additional resources that may help you on your way.

Both drafts look good, but a guideline for the posting advice :
"When you are posting your code, please take a minute to format it (indentation, etc) for readability. This will help us understand your code faster."
Waaay too often do I see code that hasn't been indented. That stuff is so hard to read. You'll probably want to explain what exactly formatting means within this context, maybe in it's very own section even.

Sora the Hedgehog, on 03 August 2013 - 03:31 AM said:

Both drafts look good, but a guideline for the posting advice :
"When you are posting your code, please take a minute to format it (indentation, etc) for readability. This will help us understand your code faster."
Waaay too often do I see code that hasn't been indented. That stuff is so hard to read. You'll probably want to explain what exactly formatting means within this context, maybe in it's very own section even.

However it is very helpfull, there are tools available to automatically indent. I wrote with GravityScore some decent indenter, but it doesnt indent the table. After this shameless self-plug I also want to point out that there is an auto-indenter built in with Sublime Text. There are probably more tools to indent the code.

But I do agree it adds to the helper if the code is already properly formatted etc. The help then comes faster, I just wanted to point out that there are tools available to indent code.

Sure, run it through tool xyz to format it, do it by hand, whatever. Format it somehow.

Here's a draft of a "get help faster" section:

Generally, both in Ask a Pro and elsewhere, the amount of effort people are willing to put in to answer a question is dependent on how much effort it looks like the asker has put in to forming the question. This is for two reasons; people are more willing to help someone who seems to have put in effort trying to find the answer themselves, and it is easier to find a solution to a well-formed question than to find an answer to a poorly-formed question.

One major thing you can do to improve the quality of your question is to ensure that your code is well-formatted. Indentation especially will help, as it makes your code vastly more readable and much easier to follow. It is also easier to spot mismatched code blocks (extra `end` statements, or too few of them) and other problems. Here is an example of how to indent:

Spoiler

We start out with a block of code that has no indentation.

function doThing(stuff)
local returnValue
if stuff == 1 then
returnValue = 2
else
returnValue = 3
end
return returnValue
end

As we read through the code, we add a level of indentation to the lines following the opening of a block, and remove a level of indentation for each line that closes a block. Peer-level statements (like else and elseif) are on the same level of indentation as the statement that opened the block they are in. It sounds more complicated than it is. Here is a break-down of the process.

function doThing(stuff)
	local returnValue
	if stuff == 1 then
returnValue = 2
else
returnValue = 3
end
return returnValue
end

function begins a block, so we indent the lines after it.

function doThing(stuff)
	local returnValue
	if stuff == 1 then
		returnValue = 2
	else
		returnValue = 3
	end
return returnValue
end

if begins a new block, so we add a layer of indentation. else is on the same level as the if that it is part of, so it should be indented only as far as the if statement is. The end statement that closes the if drops us back a level, so it ends up on the same level of indentation as the opening statement of the block.

function doThing(stuff)
	local returnValue
	if stuff == 1 then
		returnValue = 2
	else
		returnValue = 3
	end
	return returnValue
end

We continue indenting and find the closing end of the function, so for this example, we are done. Indenting is an easy way to increase readability and make debugging easier. Indentation is something that is easy to do as you code, and many text editors can help you automatically indent your code as you go, and some even include tools to indent code

In addition to well-formatted code, a description of your program and what it does or is supposed to do can be helpful for figuring out the intent behind the code. A good explanation of what the code currently does is very useful along with a description of what you expected it to do instead, or what you'd like it to do. This information also is very helpful for us to be able to provide you with the best answers we can. Also, see the tips about choosing a good topic title in the previous section.

I would add:

vm error: ArrayIndexOutOfBoundsException
Do not call a function inside itself, directly or indirectly, unless you know what you're doing. This also applied to programs when using shell.run.
There is a maximum depth of function calls. If you have a function that calls a function that calls a function that calls ….. that calls a function that calls a function, and there are more than 256 functions being called, your program will crash with this error.


(Btw, this problem singlehandedly changed my mind about goto - it might be bad practice for writing large complex programs, but for learning purposes it's the simplest control structure to understand, and it's obviously better than using functions as if they were goto.)

immibis, on 03 August 2013 - 08:47 PM said:

I would add:

vm error: ArrayIndexOutOfBoundsException
Do not call a function inside itself, directly or indirectly, unless you know what you're doing. This also applied to programs when using shell.run.
There is a maximum depth of function calls. If you have a function that calls a function that calls a function that calls ….. that calls a function that calls a function, and there are more than 256 functions being called, your program will crash with this error.


(Btw, this problem singlehandedly changed my mind about goto - it might be bad practice for writing large complex programs, but for learning purposes it's the simplest control structure to understand, and it's obviously better than using functions as if they were goto.)

Added. Also added multiple points error.

Changed the phrasing for overflow and multiple points errors to better match the explanation-of-error style used in the others.

While the 'Get Help Faster' segment that you've written looks good already, Lyqyd, I'd also talk about spacing.

Taking code that looks like this :

local e,p1,p2,p3,p4,p5=os.pullEvent();
if e=="event_wanted" then
  -- More code with horrible spacing here
end
moreStuff();

and transforming it into something like this :

local e, p1, p2, p3, p4, p5 = os.pullEvent();

if e == "event_wanted" then
  -- More code with good spacing here
end

moreStuff();

The line breaks being where they are is more of personal preference, but keyword spacing is a must.

Sora the Hedgehog, on 03 August 2013 - 11:04 PM said:

While the 'Get Help Faster' segment that you've written looks good already, Lyqyd, I'd also talk about spacing.

Taking code that looks like this :

local e,p1,p2,p3,p4,p5=os.pullEvent();
if e=="event_wanted" then
  -- More code with horrible spacing here
end
moreStuff();

and transforming it into something like this :

local e, p1, p2, p3, p4, p5 = os.pullEvent();

if e == "event_wanted" then
  -- More code with good spacing here
end

moreStuff();

The line breaks being where they are is more of personal preference, but keyword spacing is a must.

To be honest, I do not find the variable spacing distracting at all. They're really both personal preference and I think that most people are capable of comprehending the code either way.

I think indentation preferences have more in common from person to person than line spacing preferences do, to be honest. It's really more about helping essential readability, and I think that proper indentation is one thing that makes a huge difference depending on whether it is present or not, much more so than line spacing does. I suppose if it becomes a problem, we could add something about it.

I like to think of proper spacing as already having the string tokenized to be read. Sure, one can do this themselves, but I feel like it takes more effort than is necessary to tokenize it yourself. But whatever. I'm not going to try to force my point.

On a side note, I've been watching the 'People Answering Quesions, Please Read' thread, and I noticed it's managed to sink in to the second page. My goal is to have this page stickied, so if there is anything else I need to do to get it 'sticky-quality', please tell me.

I'm not really sure what you mean about "tokenizing the string to be read" in regards to line spacing. :)/>

We don't pin posts where the OP is not at least a moderator, having been burned by giving a normal user edit access to a sticky post before. The content is good, though I'm not sure it's quite precisely what we're looking for. It feels a little prescriptive still, and I think Bubba and I both have writeups in mind to cover the same topic, so we will compare the two or three of them once they're done and come up with a final product that will convey what we want best. Your post was certainly valuable though, so thank you for taking the time to write it up. If you wanted to copy and paste it over to here in a separate post, it would remain easier to find.

Sounds good to me. I understand that you'd rather not sticky the post, and that's fine. What fun is getting stickied when my post isn't the best? :)/>

For posterity :

Spoiler

As part of the Ask a Pro Renewal Project, here are a few guidelines for you gracious people who are taking time to answer questions.

1. Be Polite
A simple reminder to be kind and friendly to the people within the sub-forum, especially the people asking the questions.

2. Don't write complete code for the people asking questions without an explanation
If someone asks a question on "how do to 'x'", don't just spit out a special-tailored function at them and say 'do it like this' without an accompanying explanation of what you've written. This is bad for the person asking the question. Even though you have 'answered' the question, the answer is nothing more than handing them a magical black box that they don't understand. This doesn't help them one bit because they haven't learned anything. Similarly, if someone asks 'could you give me a quick run-down on the xyz API?', give them a quick run-through of the API sprinkled with helpful comments. An example run of the API, coupled with helpful comments, will help them achieve a more complete grasp on the xyz API. If it's possible, break up the code you have written in sections, and explain each section separately. Leave out a few minor details, such as variables, so that the person with the question is forced to read and understand what you've written so that they can proceed to apply it to their own program. But remember, explain your code and what makes it work, otherwise you are just handing them a black box.

3. Be correct and complete in your question answering
If you don't know the answer to the question, don't try to answer it. Incorrect answers only create noise and confuse the people who are asking questions. Also, don't leave the person asking the question hanging by answering with a small 'do x' answer. Supplement your answer with one or more of an explanation of 'x', a code snippet, or a link to a helpful resource for more information.

4. Be clear and understandable
Even if you are being polite, not just handing people black box code, and answering completely and correctly, if the person asking the question can't understand the message you are attempting to get across, then it's all going to go to waste because the person won't be able to use your answer. Don't be vague about anything. Try your best to write an answer with proper capitalization, spelling, and grammar. (Remember, even if it's not perfect, we can tell if you've tried your best to do so!) Enclose any code within tags, as that prevents the forums from doing screwy things with any code you post. Read your post out loud before you post it. Sometimes you'll catch grammatical and flow mistakes that you would not have noticed otherwise.

That's it! Remember to follow these guidelines as best you can so that the person asking the question comes away with as complete of an answer as possible. Happy Answering!

I've gone over your list of tutorial topics in the OP several times, and I wonder if it might not be worthwhile separating the concept of a tutorial and an example.

A tutorial would be primarily text, with code snippets mixed in, but an emphasis on explaining the concepts. A tutorial may or may not result in a final, useful program by itself, but it will always thoroughly explain some concepts, tools, or processes.

Examples would be useful programs, and most tutorials would end with a link to at least one example. They would have some plain-text explanation of how they work, but would simply link the tutorials that thoroughly explain the fundamental concepts they depend on.

Some examples: There would be a tutorial, intermediate if not advanced, on creating custom terminal redirect objects. The tutorial would list as prerequisites the basic tutorial(s) which cover all the standard terminal functions, what they do and how they are used, as well as perhaps tutorials on tables and functions, if we cover lua language features, or simply link to the relevant chapters of the Lua PIL. Taking understanding of those as given, it would focus on demonstrating how to construct a valid redirect object, talk about the pitfalls involved in testing those redirects (errors in redirects can be tricky to debug, as errors may not display and the computer may be left in an unusable state or even force-rebooted), and walk through the creation of a redirect object of some kind - perhaps one that uses an internal buffer and draws to only part of the screen. It would not actually build a proper program using that redirect, though, just the redirect object and enough code to test and demonstrate that the redirect works.

That redirect tutorial could then link to several advanced examples that use redirect buffers - a simple chat program, perhaps a gui system, a program that allows simultaneously redirecting to multiple monitors at the same time. Each of those in turn might list as prerequisites tutorials on other topics besides redirects; the chat program would require the modem/frequencies tutorial, while the multi-monitor redirect would require the monitors tutorial.

The tutorials would be able to focus on specific concepts and features, without having to complicate things by producing a useful program, while example programs will be free to be useful without trying to have a simple, "clean" position within the prerequisite tree of the tutorials. This separation would also make it take less work in putting together the programs; it is far easier to make a well-commented example program than a full step-by-step tutorial, and with a robust and clearly-defined progression of tutorials to reference in those example programs to teach the basic concepts, example programs are freed up to focus on being good examples of useful code rather than on re-teaching the same fundamentals covered in other example programs with similar feature dependencies.

This also, I think, would be beneficial for people learning. Those who want to start from the basics and learn can follow the tutorial tree from branch to branch, learning the concepts in a logical order, building up their knowledge. The more impatient people, or those with a bit more experience, can skip straight to the examples and, if they encounter things they don't understand, easily know exactly which tutorials to read to get a handle on those things.

Tutorials would progress from basic to advanced, largely based on the amount of dependencies they have; basic tutorials would be few, and should have almost no dependencies (though there would likely be a handful of "foundation" tutorials that every tutorial depends on, covering the absolute basics like using the shell, editing programs in or out of game, the basics of the lua language, etc). Regardless of level, though, each tutorial would either explicitly explain, or link to an earlier tutorial that explains, every concept involved in the code snippets they include.

Examples, on the other hand, could have different logic. For an example program to qualify as basic, it would have to use a limited number of different concepts, and would need to be very well commented, clear, and conform to very high standards for code quality, while putting accessibility over optimization. Basic programs should avoid heavy use of non-intuitive things like the lua "A and B or C" pseudo-ternary operator, elaborate metatable and function environment manipulations, and other things that are not obvious to an amateur and could make the programs more difficult for them to understand. Advanced examples, on the other hand, could assume the reader has a good grasp of the basics. Their commenting might be more limited, focused specifically on clarifying some interaction between techniques, and deobfuscating the trickier bits of the program. They would still need to hold to a high quality for the code, but could favor efficiency and optimization over accessibility. To put it more succinctly, basic tutorials would be specially-written to be simple and easy to follow and understand, while almost any well-written, decently-commented program in the programs section could be an advanced example with only the addition of a list of prerequisite tutorials.

tl;dr: tutorials spoon-feed concepts, covering them thoroughly from top to bottom, not necessarily taking the time to deliver useful programs in the process; examples simply link back to relevant tutorials and demonstrate the ways to apply those concepts in practical programs.

I have read through your entire post and agree to a large degree. I'll take a look at re-structuring the tutorial tree to change out some of the primarily-example-based tutorials. It would be great to get a list (or a few lists!) of example pieces, rated as basic, intermediate, or advanced, if anyone is interested in coming up with ideas on that front.

I'm not sure how relevant this is, but I remembered I had written a tutorial on creating look-up tables (as opposed to doing the ever ugly if-elseif-elseif-else method)
Here it is unedited from its original post location. I'm pretty sure it'll need a little bit of TLC before it's usable, but here it is.

Spoiler

Hello, I'm going to talk about look-up tables. Look-up tables are a very useful, space- and time-saving construct that
every programmer should know how to use.

First off, let's talk about their use. A look-up table's primary use is to replace the ugly and time consuming method of if-elseif chains, like this one

if a then
  -- stuff
elseif b then
  -- other stuff
elseif c then
  -- more stuff
elseif d then
  -- even more stuff
elseif e then
  -- too much stuff
else
  -- Something we didn't expect
end

That looks just plain ugly. It also looks hard to write, which it is. So we're going to fix it.

Consider these two functions :

function myFunction()
  print("Hello!");
end

function myOtherFunction()
  print("Goodbye!");
end

I'm collecting input from the user, and I want to run myFunction when the user enters "hi" and run myOtherFunction when the user enters "bye."

In order to do this, we create a table. In this table, the key corresponds to the function I want to run if I receive it.
Let's make a table to do this :

local myLookupTable = {
  ["hi"] = myFunction,
  ["bye"] = myOtherFunction,
};

Notice how when I typed the function names, I did not use parenthesis with them. This is because I am not calling them, but getting the code they point to.

Now, all I have to do to check the user input is this

if myLookupTable[input] then
  myLookupTable[input]();
else
   -- Just in case the user types a word that we don't know about.
   print("Word not found");
end

If you look closely, I put parenthesis after the second myLookupTable[input]. Because the data at myLookupTable[input] is a run-able function, all I have to do to run it is to call it by adding parenthesis.

Now my word asking code looks like this

write("Type a word : ");
local input = read();

if myLookupTable[input] then
  myLookupTable[input]();
else
  print("Word not found");
end

And as TheOriginalBIT has pointed out, you don't necessarily need to have your lookup table made of functions.
Consider BIT's code :

local validSides = {
  ["left"] = true,
  ["right"] = true,
  ["up"] = true,
  ["down"] = true,
}

write("Type a side: ")
local input = read()

if validSides[input] then
  print("Thank you")
else
  print(input.." is not a valid side")
end

I can see how you might think that the lookup table didn't really make our code any less ugly,
and that typing if-elseif-else-end wouldn't be too hard. I'd agree with that statement.
Remember though, that there are times when you can be working with 4+ different expected outputs,
at which point the if-elseif-else-end isn't going to cut it.
Using a lookup table for smaller checks might not be necessary, but for bigger checks it is vital if you want clean, readable code.

That is all. Be sure to make friends with your look-up tables. They will certainly make life easier in bigger programs.

Please post any comments, suggestions, or questions.

~Sora

A lot of this sounds really awesome.

I'd like to contribute something that details the differences between pure Lua 5.1, CC-Lua, and pure Lua 5.2. If possible, I'd also like to write some tutorials on algorithms, efficiency, optimization, and porting other Lua scripts to CC.

I'm also capable of writing tutorials on whatever the community needs at the moment.


Ideas:

1. Convert the "Ask a Pro" section to a ticket/question-based system. (Think GitHub for tickets / StackOverflow for questions.)
2. Integrate some form of "Lua Expert" certification, maybe with different levels and specializations. (Completely independent, but would work well with the above.)

Anyway, those ideas may be completely useless, but (as stated above) I'm willing to help write tutorials :D/>.

AgentE382, on 09 August 2013 - 07:05 PM said:

A lot of this sounds really awesome.

I'd like to contribute something that details the differences between pure Lua 5.1, CC-Lua, and pure Lua 5.2. If possible, I'd also like to write some tutorials on algorithms, efficiency, optimization, and porting other Lua scripts to CC.

I'm also capable of writing tutorials on whatever the community needs at the moment.

Sounds great! We don't have as many advanced Lua/programming tutorials as I would like to have, so more is always awesome.

Convert the "Ask a Pro" section to a ticket/question-based system. (Think GitHub for tickets / StackOverflow for questions.)

Unfortunately, I think this would be rather difficult for a few reasons:
1) The quality of answers may differ from person to person, and having AaP in a forum-type setting is much better at current than assigning different users to answer questions.
2) We are all volunteering limited time rather than as a job, and delay between question and response could and would become an issue.

Integrate some form of "Lua Expert" certification, maybe with different levels and specializations. (Completely independent, but would work well with the above.)

This actually was almost done towards the beginning of the forums, however the idea was dropped (there was a post about it somewhere, but I can't be bothered to find it). IIRC, it was due to the fact that we don't want good answers to be ignored simply because the person who answers has a low post count. The forum software could also have had something to do with it, though I'm not sure on that count.

Anyway, thanks for the input and I'm looking forward to your tutorials!

I'm of the mindset that having some sort of certification would be a good idea, but how would we determine who got it?
The problem is that the easiest method of 'just counting posts' assumes that people that have 250+ whatever posts have a clue, and that people 100- don't, which isn't a reasonable assumption, at least for thinking sub-100 doesn't have a clue. The other option I can think of is 'moderator-approved' but that would quickly bog the moderators down… Why can't this be easy? :P/>

I'm also game for writing Intermediate+ tutorials. (as I don't take care enough to make my code 'super easy') I'm just not sure what to write about, so a list of things that would be helpful to have tutorials on would be helpful to me. :)/>

The "Lua Pro" thing was done before, but was dropped due to the lack of useful objective measures for determining who is and is not deserving of the title.

For those wanting to write tutorials, there is a list of desired tutorials in a spoiler earlier in the topic, perhaps even the first post. Working drafts on any of those would be great, and it would probably be easiest to start with the most basic tutorials. The idea there is to have a set of high-quality tutorials to cover all of the basic elements of ComputerCraft, and later tutorials to put it all together and give practical examples of its use. Also read Gopher's post a few posts up if you're leaning toward writing one of the "example" or "reimplementation" tutorials.

I actually made a tutorial with the goal of this in thoughts. It probably isnt perfect, but hey, its something :)/>
http://www.computercraft.info/forums2/index.php?/topic/14683-event-basics/

Wrote the 'Modem intermediate - remote peripherals' tutorial : http://www.computerc...te-peripherals/

(And on an off-topic note : what is possessing people to do recursive function calls to loop? I didn't even think of it when I was learning how to program…)

Honestly, it's a result of people NOT learning recursion or loops properly. I think it started with some youtubers who were using recursion improperly and from them it's spread virally, noob to noob.

Sora the Hedgehog, on 26 August 2013 - 02:08 PM said:

Wrote the 'Modem intermediate - remote peripherals' tutorial : http://www.computerc...te-peripherals/

(And on an off-topic note : what is possessing people to do recursive function calls to loop? I didn't even think of it when I was learning how to program…)

Thanks! I've left some critique on the topic for possible improvements that would steer it toward the quality we are looking for. :)/>

Sora the Hedgehog, on 26 August 2013 - 02:08 PM said:

(And on an off-topic note : what is possessing people to do recursive function calls to loop? I didn't even think of it when I was learning how to program…)

Perhaps the lack of goto?

("How do you make it go to a specific line?" "Well, you can use functions, but that-" "I'll take 20!")

Shoving another wanna-be tutorial onto the top of the pile: The Term Api - Controlling The Terminal

immibis, on 29 August 2013 - 05:52 AM said:

Sora the Hedgehog, on 26 August 2013 - 02:08 PM said:

(And on an off-topic note : what is possessing people to do recursive function calls to loop? I didn't even think of it when I was learning how to program…)

Perhaps the lack of goto?

ugh. Trust me, the presence of goto in lua would just make this worse, with people putting labels inside loops, trying to goto labels in other functions, skipping over variable declarations, skipping to before variable declarations and re-initializing them and clobbering their values…

I know that people generally view goto as a bad thing, but what about jmp? I know that it's effectively a unconditional goto… whatever.
We should get back on topic. Sorry for the thread-jack, Lyqyd. ^.^ v

Here is the first tutorial in the series, Computer Basics I: http://www.computercraft.info/forums2/index.php?/topic/15033-computer-basics-i/

Feedback would be appreciated!

Lyqyd, on 01 September 2013 - 04:45 PM said:

Here is the first tutorial in the series, Computer Basics I: http://www.computerc...puter-basics-i/
Feedback would be appreciated!

Very, very, good… Simplistic and uses lots of images which would very much help out the new user… Only 3 minor things I would suggest:

1. Maybe snip the crafting grid screenshot so it is bigger and there is less Minecraft window and more recipe.
2. Specify that the edit program, the program you want to edit is specified with the command line argument, just like with the list command. And state how lots of programs (cc and user made) quite often make use of runtime arguments.
3. Might fall out of scope of the tutorial, but I think its the best one to be in… Show and tell about the "programs" program, so they can see the CC programs?

Other than that, like I said, very good.

Your first point is a good one; I'll adjust the image accordingly. As to the second point, I could probably clarify that better. I'll look at revising that piece of the text. The third point is indeed out of the scope of this tutorial, as it is covered (both help and programs) in the second tutorial in the Computer Basics group, which I'm sitting down to work on now.

Thanks!

Lyqyd, on 01 September 2013 - 05:05 PM said:

The third point is indeed out of the scope of this tutorial, as it is covered (both help and programs) in the second tutorial in the Computer Basics group, which I'm sitting down to work on now.

Thanks!

Oh I didn't even see programs in the list, haha. I think I was reading it wrong maybe.

No problems :)/>

Computer Basics 2 is up. I'm about to go back and look at the edit section of Basics 1 as suggested. Feedback on both of these would be appreciated! These should sort of set the example for what we're looking for in a tutorial. One that takes time to walk through things step by step, and explain at least a little bit about what's going on, as well as give the user the opportunity to play around with things a little bit. Obviously, some of those points are going to be a little less practical in other tutorials, but that's the sort of general feel we're going for here.

Edit: And I've updated Basics I. Let me know if that covers your suggestion, or if you still think it's insufficient.

Lyqyd, on 01 September 2013 - 06:49 PM said:

Edit: And I've updated Basics I. Let me know if that covers your suggestion, or if you still think it's insufficient.

Much better for the `edit` program. Did you change the size of the first image? It doesn't look much different to me.

EDIT 1:

Lyqyd, on 01 September 2013 - 06:49 PM said:

Computer Basics 2 is up.

As most of these programs output quite a lot of data to the screen, could it be worth clearing the screen before running the program? Just to make the screenshots look a little less cluttered.

EDIT 2:
Also I know it's not ideal, but would it be worth having a pinned topic with links out to the AaP Renewal tutorials, so they don't get lost in the sea of tutorials?

EDIT 3:

When a computer has a label, you can pick up the block by breaking it, and it will retain its ID and all of the programs that you've created on it.

Worth mentioning that turtles also keep their fuel level? or is that something that should be referenced back in the turtle tutorial?

And lastly…
Is it worth saying that with the rename, move, cd, copy, etc, we can use specify an absolute path to be able to move to a completely different location? For example running say `tutorial> mv bar /tutorial2/bar/foo`.

I didn't resize the first image, but I did crop out the extra stuff. If it doesn't appear different, try clearing your cache and refreshing the page. It's now just the crafting grid and results box.

Clearing the screen is a possibility, though the tutorials are meant to be walked through with a computer, so at this point, they display exactly what the player would see on his screen if he followed the tutorial exactly. If it is found to be too distracting, they could be re-shot with a cleared screen for each shot.

The pinned topic already exists, it just hasn't been made visible yet. Since these tutorials are starting to get written, I may make it visible soon.

Just noticed your signature the other day, by the way. I like the first line of it. ;)/>

Lyqyd, on 01 September 2013 - 07:49 PM said:

I didn't resize the first image, but I did crop out the extra stuff. If it doesn't appear different, try clearing your cache and refreshing the page. It's now just the crafting grid and results box.

Ahh I'll try clearing, 'cause it looks exactly the same to me atm.

Lyqyd, on 01 September 2013 - 07:49 PM said:

The pinned topic already exists, it just hasn't been made visible yet. Since these tutorials are starting to get written, I may make it visible soon.

Haha ok. Great minds……. o.O :P/>

Lyqyd, on 01 September 2013 - 07:49 PM said:

Just noticed your signature the other day, by the way. I like the first line of it. ;)/>

I liked it too, and hole-heartedly agreed so put it in… I tried to get a "— Lyqyd" in there, but apparently I've hit my maximum of 3 lines of text (and that's even after I've shortened the urls) so I couldn't do it.

Made the topic visible–it's now Read This Before Asking Questions or something to that effect. A couple of stickies that it supercedes will be removed now.

Edit: I'll go through some of the other tutorials written for this in the next couple of days and ensure that they meet quality standards and then link them in. We do need the basic tutorials written before the intermediate ones get linked, though.

Lyqyd, on 01 September 2013 - 07:55 PM said:

Edit: I'll go through some of the other tutorials written for this in the next couple of days and ensure that they meet quality standards and then link them in. We do need the basic tutorials written before the intermediate ones get linked, though.

I'm assuming that we'll be avoiding duplicates, so perhaps in OP strikethrough the ones that are already done?

EDIT: Also should `peripheral.getNames` be covered in the Peripheral Basics tutorial, or not since it's really more of the remote peripherals tutorial job?

That's likely to happen, though I want everyone to bear in mind that we are going for a wiki-like approach. The initial document has to be written at some point, but then anyone with sufficient knowledge of Lua and ComputerCraft can suggest improvements and provide rewritten passages for approval and acceptance. At some point, the tutorial series will be migrated off of the forums and on to either the Wiki or another cc.info-controlled content management platform so that all approved tutorial editors can work on improving them. Depending on how long that takes, we may have some temporary forum-based system to allow similar things. On either system, we'd likely have an arrangement wherein suggested edits are posted and given a chance to be commented on before being edited into the tutorial itself. Essentially, I'm looking to get a community-created set of tutorials rather than many tutorials whose content is controlled by their original author.

Lyqyd, on 02 September 2013 - 04:47 PM said:

-snip-

Sounds good :)/>

Oh also, vanilla CC peripheral crafting (other than disk drives), which tutorial does that make it into? Computer Basics 3?

We may do a recipes spoiler in Basics 1, but the other peripherals can have recipes shown where they are introduced. Peripheral intermediate deals with printers, modem series for modems, monitor basics for monitors, etc. I think between the various other tutorial series, we introduce every peripheral in ComputerCraft. I think just about the only thing we don't have a reason to introduce is the advanced turtle, so perhaps that one will end up only being shown in the recipe list in Computer Basics 1.

Good question!

Lyqyd, on 02 September 2013 - 05:03 PM said:

-snip-

Ok cool, just thought I'd check. Also

should `peripheral.getNames` be covered in the Peripheral Basics tutorial, or not since it's really more of the remote peripherals tutorial job?

I've glanced through it and will post some feedback when I have time to sit down and read it in depth. I'll also have some feedback soon for the Term Intermediate tutorial.

Thanks for your contributions so far, everyone! I'm glad to see this getting a good start. :)/>

Lyqyd, on 03 September 2013 - 01:43 AM said:

I've glanced through it and will post some feedback when I have time to sit down and read it in depth.

Cool thanks. Also just wondering, what is the maximum count of images we can have in a thread? I feel like I was very close to hitting it with that tutorial.

I'm not really sure that there is one. There is a maximum of eight emoticons per post, but I'm not sure about a maximum of embedded images.

I know there is a maximum, I hit it in my programs thread. That is why I went external (GitHub wiki) for screenshots.

I've added a bit more feedback.

One thing it looks like we're going to need is a style guide. Similar to the way the wiki works, this would dictate formatting for the various aspects of the tutorials. I want these to be as cohesive, coherent and consistent as possible. I like the use of monospace font I've seen in a couple of them. Is anyone willing to draft up some style guidelines for formatting? Essentially just detailing how to format various things that will be present in the tutorials, such as program names, lines to execute in shell or lua, etc. If there's no interest in writing the first draft of this, I'll throw something together and put it up in the next couple of days. And it's perfectly fine to write up a draft even if someone already has. The more to discuss, the better.

I think it would be good to mention in a related tutorial that it is possible to use an external editor.

I just completed a tutorial Turtle Basics

Feedback would be appreciated while I work on Turtle Intermediate 1. :)/>

I have completed another tutorial Turtle Intermediate 3

I had this sitting there waiting for me to finish off Tutorial Intermediate 1, but I just decided to post it anyway, remove it from my text editor :)/>

Feedback would be appreciated :)/>

Lyqyd, would it be at all possible if you could strikeout the tutorials on your list that have at least one draft of them, so that is it easier to visualize what still needs to be done?

I will try to remember to update the list with links to drafts tonight.

Sora the Hedgehog, on 13 October 2013 - 08:06 PM said:

Lyqyd, would it be at all possible if you could strikeout the tutorials on your list that have at least one draft of them, so that is it easier to visualize what still needs to be done?

Lyqyd, on 15 October 2013 - 12:45 PM said:

I will try to remember to update the list with links to drafts tonight.

Or better yet, change them to links to the relevant topic?

Lyqyd, on 15 October 2013 - 12:45 PM said:

I will try to remember to update the list with links to drafts tonight.

#notification

Thanks. Was out most of the night last night at a movie. Will try to get to it tonight, hopefully.

Okay, I think I got all of them linked. Please let me know if I missed any! I'll try to work on some finer style guidelines so we can get consistent content between them. I'm hoping to get Computer Basics 3 written up this weekend. I appreciate all the effort so far!

Engineer, on 11 August 2013 - 01:54 AM said:

I actually made a tutorial with the goal of this in thoughts. It probably isnt perfect, but hey, its something :)/>
http://www.computerc...3-event-basics/

Since this didnt get added to the main post, I really would like some feedback on it why it isnt good enough. Thanks!

Engineer, on 17 October 2013 - 11:14 AM said:

Engineer, on 11 August 2013 - 01:54 AM said:

I actually made a tutorial with the goal of this in thoughts. It probably isnt perfect, but hey, its something :)/>
http://www.computerc...3-event-basics/

Since this didnt get added to the main post, I really would like some feedback on it why it isnt good enough. Thanks!

Lyqyd probably just missed it. It's a pain going through all the tutorials to find the properly formatted ones. The tutorial seems quite nice so I've gone ahead and added the link.

LBPHacker, on 29 August 2013 - 06:59 AM said:

Shoving another wanna-be tutorial onto the top of the pile: The Term Api - Controlling The Terminal

What about this? It covers most of the parts of the term API which hasn't been covered yet.

I'll have to take another look at it, but it doesn't seem to fit the outline. I'll have to read through it more carefully, but at a glance, my concern would be that it tried to cover too much ground with too little depth.

Okay. It'll remain in the Tutorials section anyway so anybody can find it. I think it's good enough for an overview.

Although I might just take that advice and make a bunch of tutorials about the term API which cover "less ground with more depth".

Yeah, that's actually one of the main goals of this project. We want a quality set of tutorials that take a relatively small but sensibly interrelated chunk of a topic and provide a good depth of information on it, especially the what-it-does and why-it-works and how-it-works parts. Then we can tie them together into a sensible progression to introduce people to new aspects of the mod with clear, correct, well-written and up to date information.

Unfortunately, I didn't sit down and spend the time to write out Computer Basics 3 this weekend. Hopefully, I'll get to that this week and then move on to some other topics.

I would like to tackle a few of these tutorials, as they cover areas that I have recently worked through and somewhat mastered. However, I haven't figured out how to post screen shots as you have in your first tutorial, nor have I figured out how to create anchors (clicking HERE will take you to some other tutorial or resource, where the world HERE is displayed, but it is an a href to another page). I also couldn't find resources on how to take full advantage of the forum editor. Can you point me to a resource to figure this out?

I have posted three new tutorials for this project.

There are two Lua Basics tutorials to discuss entry-level Lua programming concepts, which are not on the project list but I felt would be useful to supply:

• Lua Basics -- Variable Scope, Code Blocks and Control Structures
• Lua Basics -- Using "break" to Exit Loops

The first tutorial is a fairly broad kickstart to the language, and when taken with the Computer Basics 1 and Computer Basics 2 would get the average beginning programmer up and operational in Lua. I see a need for additional Lua Basics (or Lua Intermediate) tutorials treated in a similar manner for functions, tables, files, and list iteration offered under the category Lua Basics or Lua Intermediate. If there are community tutorials already in existence which cover the topics in the detail requested by the Ask-a-Pro Project Renewal specifications, perhaps they could be reclassified under either Lua Basics or Lua Intermediate for easier access.

The third tutorial I wrote is directly on the project list, satisfying the first of the Redstone Basics tutorials:

• Redstone Basics 1 -- getInput, getOutput and setOutput which is directly in response to the project request.

Comments, suggestions and corrections are of course welcome.

[member="awsmazinggenius"],[member="ingie"] and I noticed an uptick on "how do I create a touch screen" questions. After having dealt with several of these, we discussed creating a comprehensive tutorial on the subject. I have been writing the tutorials so far, and [member="awsmazinggenius"] and [member="ingie"] have been making suggestions, edits and helping with testing.

The Complete Monitor Buttons and Control Tutorial, as it is called, is in four parts. Two Three of the four parts are now posted under tutorials:

• Part I: Monitor Basics which covers attaching monitors, obtaining a monitor handle, getting size, setting scale, setting color and checking isColor, positioning text, writing text and clearing the screen. It is fairly comprehensive, although it does not cover term.redirect() – as that has little to do with buttons and touch screens (we can add a spoiler to another tutorial to cover that quickly).
• Part II -- Monitor Buttons is a step-by-step and very thorough treatment of creating and displaying buttons, from simple buttons all the way through creating a complete Button() closure with values and enclosed draw functionality.
• [url='http://www.computercraft.info/forums2/index.php?/topic/17133-the-complete-monitor-buttons-and-control-tutorial-part-iii/]Part III – Monitor Touch and Other Events[/url] covers using monitor_touch events to change button states and control basic redstone output to control creations, introducing also the usage of key events for program control.
[/list] [s]Part III will deal with monitor_touch, mouse_click and key events to read button presses, and simple rednet operations and events to control creations based on button states[/s]. Part IV will tie everything together into a sample Monitor Touchscreen Door Control program which will be created using the code developed in Parts I-III. The four parts of the tutorial are designed not only to cover the subject matter, but also to help take the programmer through code development strategies and teach by example better coding practices. A coder will become familiar with basic coding techniques and progress well into advanced areas (tables, functions within tables and beginning objects). The thought behind the tutorial project was to answer the question in a way where the programmer who takes the time to complete the series will become one who not only asks good questions, but is able to answer questions as well. Please add the tutorials to the ask-a-pro renewal project. If you feel inclined, please direct feedback, error reports or editorial thoughts to [member="surferpup"]

Just added [url='http://www.computercraft.info/forums2/index.php?/topic/17133-the-complete-monitor-buttons-and-control-tutorial-part-iii/]Part III – Monitor Touch and Other Events[/url] of the Complete Monitor Buttons and Control Tutorial.

I don't mean to break the wonderful flow of tutorials that is originating from this thread, but going back to the original issue of signal-to-noise ratio, I noticed that some posters on the forum make very poor use of the quoting facility. Specifically, they quote whole messages when a snippet would be enough or they nest quotes within quotes within quotes when it is maybe unnecessary. Perhaps it'd be worth to mention -somewhere- and enforce through moderation a couple of guidelines: 1) quote the least you can - a good rule of thumb is: quoted text should be no more than 30% of your post 2) avoid nesting quotes when possible.

On a separate subject, I'm noticing the link to tutorials posted in this thread often (always?) link to another post here in the forum. As somebody who have relied heavily on MediaWiki in the past I find this strange. Wouldn't the wiki the most appropriate place for tutorials, their associated discussion pages the best place where to suggest improvements and refinements to each tutorial?

manu3d, on 06 March 2014 - 08:15 PM said:

I don't mean to break the wonderful flow of tutorials that is originating from this thread, but going back to the original issue of signal-to-noise ratio, I noticed that some posters on the forum make very poor use of the quoting facility. Specifically, they quote whole messages when a snippet would be enough or they nest quotes within quotes within quotes when it is maybe unnecessary. Perhaps it'd be worth to mention -somewhere- and enforce through moderation a couple of guidelines: 1) quote the least you can - a good rule of thumb is: quoted text should be no more than 30% of your post 2) avoid nesting quotes when possible.

Most posters in this section stick around long enough to have their problem solved, and that's about it. Such a rule would be ignored.

It can be enforced via a forum setting, but personally I find it annoying to have my quotes automatically pruned on those occasions where I want them nested.

manu3d, on 06 March 2014 - 08:15 PM said:

On a separate subject, I'm noticing the link to tutorials posted in this thread often (always?) link to another post here in the forum. As somebody who have relied heavily on MediaWiki in the past I find this strange. Wouldn't the wiki the most appropriate place for tutorials, their associated discussion pages the best place where to suggest improvements and refinements to each tutorial?

I've been wondering about this somewhat myself.

manu3d, on 06 March 2014 - 08:15 PM said:

I don't mean to break the wonderful flow of tutorials that is originating from this thread, but going back to the original issue of signal-to-noise ratio, I noticed that some posters on the forum make very poor use of the quoting facility. Specifically, they quote whole messages when a snippet would be enough or they nest quotes within quotes within quotes when it is maybe unnecessary. Perhaps it'd be worth to mention -somewhere- and enforce through moderation a couple of guidelines: 1) quote the least you can - a good rule of thumb is: quoted text should be no more than 30% of your post 2) avoid nesting quotes when possible.

In my experience, people are either kind/intelligent enough to do this on their own, or they ignore any and all rules when making their posts. It would be great if they would do this though.

On a separate subject, I'm noticing the link to tutorials posted in this thread often (always?) link to another post here in the forum. As somebody who have relied heavily on MediaWiki in the past I find this strange. Wouldn't the wiki the most appropriate place for tutorials, their associated discussion pages the best place where to suggest improvements and refinements to each tutorial?

I love wikis. They're great for collaboration, they seem more official, they're more versatile… The list goes on.

That being said, people may be avoiding the wiki for several reasons:

• It's more time consuming. In order to make a tutorial on MediaWiki, one needs to know how to use wiki syntax and how to write a well formatted tutorial. It's not something that takes a ton of time to learn, but why go to the effort when we have a handy forum on hand?
• Making a forum post is convenient. In order to edit the ComputerCraft wiki, you need to make a request for permission. And though it's sadly necessary that we restrict the wiki in this manner, it will still deter those who don't necessarily feel like taking the time to sign up.
• Forum posts are more visible, and the credit/upvotes go to the original creator. People like having their hard work admired, and as such making a post in the tutorials section will be more appealing than writing up a tutorial on a wiki, which hides the contributor(s) unless the reader actively searches for them.

So, unless we have somebody willing to transfer content over to the wiki, the way tutorials work is probably going to stay like that for the foreseeable future.

The above is all true, but not the complete picture.

I had hoped originally to get the tutorial series up on the wiki, and have a group of motivated and experienced members of the community be given edit permissions for the pages themselves (a Tutorial Editors group, if you will), while allowing all wiki contributors to edit the talk pages. This is apparently not well supported by the wiki software we have and/or the way in which we have it configured, and AfterLifeLochie was the only one at the time who was active and had access to and experience with the configuration stuff necessary to set that sort of thing up. I would still eventually like to get that sort of system set up, but it may have to be a subsection on the Tutorials section or some such. I'd eventually like to have the tutorial series be a community project, more focused on collectively creating the best/most effective tutorials we can, rather than focusing on individual contributions to the project. For now, I'm simply glad to have received the great contributions we have so far.

Thanks Bubba and Lyqyd for your replies. I can only reply: fair enough! :)/>

Lyqyd, on 31 July 2013 - 02:24 PM said:

Turtle basics - move, turn, refuel, dig, place, attack - draft
Turtle intermediate - suck, drop, getStackSize, detect, compare
Turtle intermediate - compareTo, getSpaceInSlot, transferTo, craft

So I've been looking into finishing Intermediate 1 &amp; 2 now that uni has completed. But I also thought I should update Basics 1 to ComputerCraft 1.63 and was wondering your thoughts Lyqyd. Would equipLeft and equipRight go in Basics 1 since in order to do dig a tool is needed. How about getFuelLevel and getFuelLimit? Oh and slot selection, I feel would probably need to be in Intermediate 1, yes?

Turtle Basics should probably talk about the built-in refuel program with a note that the functions it uses internally will be covered in a later tutorial, with a link. I think tool adding can be covered with just crafting (end up with a mining turtle when explaining the crafting recipes), with a similar note about the functions and their caveats being explained in later tutorials. I think it is somewhat important to start the tutorials out such that they are easy to understand, which occasionally means glossing over details that will need further explanation later. Obviously, in those cases, we want to link to the further information so that it is not assumed to be the full explanation or cause any misconceptions.

Slot selection would definitely go in turtle intermediate 1. With the extra functions added, we will have to look at how much ends up in the turtle intermediate tutorials and possible re-split them into different groupings.

Alrighty, that makes logical sense :)/> I'm hoping that the Intermediate ones won't end too large, but I'll follow a similar format to the basics tutorial, so we shall see how it goes :)/>

I've added the Computer Basics III tutorial. For reference, I've been using this sort of format as the header for my tutorials:

This is a tutorial in the Ask a Pro Renewal Project series.

Prerequisite tutorial:
Computer Basics I

Next suggested tutorial:
Computer Basics III

In this tutorial, we will learn about several programs included with ComputerCraft: help, programs, label, id, copy, move, rename, mkdir.

This example is taken directly from the Computer Basics II tutorial. As you can see, the first line is a statement that the tutorial is part of this series of tutorials. The next two parts list any prerequisite tutorials that the reader should complete to set themselves up for this tutorial and any following tutorials that come after the current tutorial. Note that you should only list direct descendants of the tutorial, which are always going to be in the same category as the current tutorial (a Computer subject tutorial wouldn't list a Redstone section tutorial as a following tutorial). The final line briefly summarizes the concepts that the tutorial will cover.

I also have been including a line at the very end of the tutorial that summarizes again what the tutorial has gone over, usually somewhat expanded from the version of the summary at the top.

Lyqyd, on 06 November 2014 - 05:28 AM said:

Note that you should only list direct descendants of the tutorial, which are always going to be in the same category as the current tutorial (a Computer subject tutorial wouldn't list a Redstone section tutorial as a following tutorial).

I don't completely agree with that bolded statement

Peripheral Basics said:

Leads onto:
— Peripheral Intermediate
— Modem Intermediate
— Monitor basics

Hmmm. Are those following tutorials, or tutorials which could be linked to from inside the tutorial content as a way of expanding on concepts that you touch briefly on in that tutorial? I'm not extremely attached to the only-from-same-category thing, but I don't want to have to try to list all of the tutorials that list, for example, Computer Basics I as a prerequisite as following tutorials.

it's basically anything that I believe should list that tutorial as a prerequisite, thus making them something it leads onto

just a overall question..

what about making a pinned / locked forum post in the tutorial section, that lists all the different tutorials,
and contains the link and maybe a 1-3 line description of the tutorial.

One thing i really like about the Computer basics tutorials, is the last 3 lines.
they do explain what the tutorial just went through, and it is a description like that, that could be with each link


a post like that, would make the tutorial section easier to look through, and search through aswell.

just my thoughts on that :)/>
merry Christmas to you all

Are you asking us to produce tutorials from the list included? If so I would be happy to help but I wonder where I should post such tutorials.

Perhaps in the Tutorials Forum.

KingofGamesYami, on 08 January 2015 - 04:56 PM said:

Perhaps in the Tutorials Forum.

Well, don't I feel stupid…

I've pinned the "Computer Basics I" tutorial post over in the Tutorials section, as a post by ElvishJerricco pointed out that we didn't have a stickied starting-off point for players new to the mod. I still need to add links to CB3 to other AaPRP tutorials to look at following on from it.

I'm interested in thoughts. Anybody have any strong feelings either way on having that specific tutorial pinned?

I think its a good idea, but probably just more of a wiki thing, in my opinion.

I feel like new users ignore the tutorials section - and stickies in particular. The friend who introduced me to the mod taught me how to label a computer and fuel a turtle - the two main aspects of the mods that really aren't intuitive, and are likely most often taught by word of mouth (eg YouTube videos) - and the rest was easy enough to figure out from there, simply by searching for the Lua equivalent of programming constructs and commands I was already familiar with from other languages (and by consuming all the info in the wiki's APIs category, of course - a resource that should be highlighted!). Most guides on this site (including the "computer basics" ones) I've not read before now, and the only tutorial I've read in the hopes of actually learning something is this one.

But of course, I realise different newcomers have different needs. For what it's worth, I do read stickies. ;)/>

Obviously having a sticky is better than not having a sticky; though a "table of contents" might be more suitable than an actual guide (providing an index of links to the "better" guides out there, along with a suggested reading order). And before it comes up, I'd rather not see a "democratic" approach taken with the selection process, as this would only lead to people who don't know any better decrying perfectly good guides and promoting those which're frankly rubbish. Even if only one person (eg Lyqyd) has the final say on what's in the index, that's fine by me - the less the better.

In the absence of such an "index", I can't think of any better guide to sticky than Computer Basics I. But, while we're talking about that particular guide, I do have a couple of suggested alterations for it:

I feel that knowing about the computer labelling system in ComputerCraft is much more important than knowing how to edit and save scripts. Leaving that bit of info out until after (until the next guide, in fact!) feels like it could be taken as a bad joke when someone loses their work (or turtle's fuel reserve) because they weren't aware - and indeed, people who are already familiar with command line interfaces (and Unix commands in particular) are likely to skim or entirely skip over CB II anyway. Really I consider this labelling information to be so important that I'd be sticking it (or at least a link leading to it) up the top of the aforementioned "tutorial index" thread, were it to exist - perhaps under a "getting started" heading or something like that.

Second, although a relatively minor point, maybe stick a link to the next guide at the bottom of each CB post. I feel people are otherwise likely to forget that there is a next guide by the time they get down there. CB III would do well to lead on to some guides regarding eg turtles.

You've made several excellent points! I will work on creation of an index of worthy tutorials at some point and sticky it instead of CB1. In the meantime, the point about labeling is an excellent one, so I'll try to add a quick mention stressing the importance of doing so to the tutorial, with a link to the further explanation in CB2. Links at the bottom are a good idea as well.

I think the best thing for the Ask a Pro section is more questions. Honestly today I have been refreshing and seeing nothing. I want to help too! :(/>

Don't be afraid to post in this fourm, that should be exagerated. If it is a minimal problem we will help with no grumbles!
At the same time do give us the information we need.

Also mark solved posts no matter how old, I am going through and see really old posts with new replies, which confuse me becuase they appear at the top. And some of these don't include a final solution so it is hard to determine if it has been fixed yet. Just my 2-Sense

I really wish this forum software had support for marking questions as solved, and a certain post as the 'answer'
If you've got a simple problem, these two things can help you quickly find an existing answer.

Of course, this isn't possible in the current version, so just editing the title to add " [solved] " would be helpful.

TYKUHN2, on 24 September 2015 - 03:16 AM said:

I think the best thing for the Ask a Pro section is more questions. Honestly today I have been refreshing and seeing nothing. I want to help too! :(/>

It might just be that very few people have questions right now. School is starting for a lot of us :P/>

HPWebcamAble, on 25 September 2015 - 12:18 AM said:

-snip-

It might just be that very few people have questions right now. School is starting for a lot of us :P/>

Screw school! I can still Ask a Pro while in school! Infact I am!

Also, maybe the forum software is a different version, but I noticed (and I know it is a sin to say this name on this forum) OpenComputer's IP.Board supports the [Solved] tag as a small green icon.

TYKUHN2, on 25 September 2015 - 02:52 AM said:

(and I know it is a sin to say this name on this forum)

Never has been, doubt it ever will be.

Honestly in ways I prefer ComputerCraft, and not for it's simplicity either. I like the challenge of OpenComputers, but I am not a fan of certain things of it. The Navigation upgrade used to annoy me but it was fixed, but the biggest annoyance is the Network Card. You can be 100% sure your communicating with who you think it is.

But in all seriousness I am noticing a distinct lack of questions on both forums (OC being newer though) which means I am sitting here watching youtube trying to find something to do.

If you've got the knack for writing high-quality tutorials, the first post of this topic has several tutorial topics that have no drafts written for them yet.

Correct me if I heard you wrong, but am I not allowed to answer questions with a OO-design or asking questions with a OO-design?

Sewbacca, on 13 August 2016 - 08:24 PM said:

Correct me if I heard you wrong, but am I not allowed to answer questions with a OO-design or asking questions with a OO-design?

It's more of, you should provide the simple solution when possible and expect varying and limited answers when using tables as objects (partly due to the vast number of ways of implementing objects in Lua)

Lupus590, on 13 August 2016 - 10:30 PM said:

Sewbacca, on 13 August 2016 - 08:24 PM said:

Correct me if I heard you wrong, but am I not allowed to answer questions with a OO-design or asking questions with a OO-design?

It's more of, you should provide the simple solution when possible and expect varying and limited answers when using tables as objects (partly due to the vast number of ways of implementing objects in Lua)

And what is with questions, I asked? Often am I wanting OO-soloutins and more often OO-soloutions allow easier maintenance and easier development!

The style guidelines in the first post are for AaPRP series tutorials, they don't have anything to do with question and answer topics in Ask a Pro itself.