[Help Wanted] SmileBASIC Documentation Project

just make a poll with 2048 options Also big sprites are good because they're easier to see _{P.S. no anime sprites allowed xddd}

What about the SB logo? (1474 or 4095)

Considered that, don't like it because it's giant and also bad. Although, it would be good for attribute demonstration? Also, I GOD DANG FORGOT WANG-PAKU AND DUMMY. They would've been good inclusions, as Wang-PAKU is an energetic naughty boy and Dummy would be a good dummy (sometimes used as a synonym for placeholder) sprite.

What about the other sb characters?

just make a poll with 2048 options

There's a poll size limit although you were probably joking P.S

P.S. no anime sprites allowed xddd

Why not?

Hakase is the only obvious choice for this

Hakase is the only obvious choice for this

Red fish would be better tho lol

Making a sprite: Use strawberry, then demonstrate Hakase exists. Rotating a sprite, setting home, scaling, etc: Use Hakase SPANIM: I guess it could make Hakase cry? I'm sorry Sprite attributes: SmileBASIC logo because it demonstrates how Rot90 affects the home coord

The dragon's tail end is obviously the best example sprite

The dragon's tail end is obviously the best example sprite

The dragon's head is obviously better

I have so many questions and comments about this, that is isn't even funny. I apologize in advance this runs long. Where do I start, how about, what is wrong with the official SmileBasic command reference? Either in in-app form or from http://www.smilebasic.com/en/reference (you can even download a handy pdf) I can see wanting more detail or perhaps sample code for each instruction, but I haven't noticed anything actually wrong or misleading. If you don't want repeats of the parts that are lacking in the official documentation, please give some examples of where it falls short of expectations. Unfortunately this looks like the major thrust of the project, but it seems redundant to me. It also seems like something that will be need to be revisited as soon as SmileBasic Switch comes out. Instead maybe just focus tutorials on more fundamental building blocks like declaring a variable, what is an array, if/then/else, for/next, while/wend, print, functions, the read eval print loop and the like. From what I have seen most of the people on this site need to concentrate on the basics. Speaking of tutorials, isn't there already a spot on the site for tutorials. Specifically, I am thinking of Randomous' excellent How to Program series (http://www.smilebasicsource.com/page?pid=402), so why not just put out a call for tutorials on the site and be done with it? Which leads me to the next question. Why is this on GitHub instead of SmileBasicSource.com? Or is it going to be on SmileBasicSource.com eventually? GitHub itself brings up even more questions. - Don't you have to be at least 13 years old to open a GitHub account. Considering our project coordinator says she is under 10 on the how old are you thread aren't you not supposed to have a github account yet? Shouldn't a fair chunk of the site users not have a github account yet and be unable to contribute? - For a group of people who fight tooth and nail when I tell them they shouldn't use GOTO, isn't GitHub asking too much? Version control is a topic that comes in significantly after learning to write a while or for loop. - If you are asking for people to help through GitHub, it may not be a bad idea to write some short how-tos on things like: what is version control, how to make a github account, what is a repository, what is a branch, what is a merge, what is a clone/fork, then maybe move on to things like how you want pull requests for this project (are we merging into one central repository, or do we have to merge from a fork) and what branch you want for the source/target, and maybe state who is in charge of merges. - Is it too much to ask what problems you are encountering with GitHub? What your intended new host is? Or what your new markup setup is all about? You are asking for help from the community remember. Keep us fully informed, there shouldn't be parts of the plan we don't know. - If you are going for a collaborative edited document knowledge base, shouldn't this really just be a wiki? Can't randomous just install a wiki package on the site? That dodges a lot of problems with github (and gives you hopefully a smaller set of wiki ones like say syncronizing accounts) I am getting tired of making paragraph transitions, so lets get to my personal sticking point. That is the public domain requirement. Personally I am uncomfortable with putting things in the public domain without good reason. I may be willing to put in something with a Wikipedia style CC-BY SA type license but public domain is off-putting to me. Any chance of licensing requirements changing? Right now you have people rewriting instruction descriptions and arguing about which sprite to use and it worries me. Still if you are willing to accept something other than public domain maybe I could contribute an article on recursion or something similar. Sorry this is so long and good luck on the project.

what is wrong with the official SmileBasic command reference?

I don't want to go over or know all of the flaws in it, but I hope a quick screenshot will summarize a theme I've seen repeated frequently in chat and the early days of the forums: (the FORMAT ones are " [manual] FORMAT$ %F length documentation is wrong" and "[manual] FORMAT$ space padding documentation is incorrect," respectively) SmileBoom has not kept the ENGLISH reference updated (at least the web version) and does not provide translated versions of the BIG or PiStarter or Pasocom Mini references.

Speaking of tutorials, isn't there already a spot on the site for tutorials.

The idea of tutorials in this project is in order to tie instructions together or demonstrate the bigger picture in some cases. More extensive tutorials should probably be kept separate, I just don't reject the idea of having non-command documentation here

Why is this on GitHub instead of SmileBasicSource.com?

Because I don't feel comfortable writing a version control and editing system from scratch. Eventually it [should] be migrated to a section on smilebasic source.

isn't GitHub asking too much? Version control is a topic that comes in significantly after learning to write a while or for loop.

Huh? I think you're assuming that everyone on the site can, should, or is expected to contribute, which is not the case. Even under the system randomous and I discussed at an earlier date, we planned to restrict editing to an approved power user group--this isn't to be exclusive, just that there is a level of trust needed for someone to contribute to a document like this in a way where destructive editing is possible (this isn't an issue on github, but only because third-party commits have to be approved anyway).

If you are asking for people to help through GitHub, it may not be a bad idea to write some short how-tos

I did provide two guides for getting started: https://github.com/y-ack/puchikon-no-hata/blob/master/git-help.org and https://github.com/y-ack/puchikon-no-hata/blob/master/org-help.org Everything else has been covered dozens of times over my individuals more competent than I and it would be silly to restate them. I'm not going to say that expanding this information is a bad idea, but so far there has been no reason to complicate the process.

Is it too much to ask what problems you are encountering with GitHub?

No, not at all. But I'm also too tired to explain it right now, so hopefully 12Me can fill you in.

If you are going for a collaborative edited document knowledge base, shouldn't this really just be a wiki?

This sounds like a good idea except that all software sucks and mediawiki or whatever is a huge package and aargh I mean as an alternative to editing on github, yeah absolutely. But also randomous hasn't been um... around for a few days. so... that makes things a little harder.

the public domain requirement

I'm almost surprised it took this long for someone to complain about it. Here's my reasoning: For something like this, I think it's fair to say that the copyright shouldn't belong to any one entity. Not me or another individual, and not even to "SmileBASIC Source" as a group, because then when that 'group' makes relevant decisions you still run into issues where it's really an individual or group of individuals making the decision. Letting contributors maintain intellectual rights to their contributions means individuals can do damage later (which I'm not as worried about) or if someone disappears and loses contact with the group makes further licensing/other decisions really annoying: https://github.com/pwaller/pyfiglet/issues/58 (which I am worried about: I watched that issue take months waiting on one person to reply). Leaving a project like this at all to the fickleness of humans seems silly. Most licenses are for either 1) financial control or 2) political control I think the first is irrelevant and pointless in this situation and I'm not interested in enacting the second for this particular circumstance. This information is of use to a very niche group and we don't have the power or money to do anything more than make angry noises at anyone that does, say, try to sell the material. Putting it into the public domain isn't saying that anyone's contributions are worth any less or that they shouldn't be proud of them, it's just saying that copyright isn't worth worrying about here. If there is something I fail to realize about this I'm not necessarily against applying a license, but I don't see any practicality in share-alike and attribution is unenforceable and messier.

I don't think there is a single page of the official documentation that doesn't have some missing/outdated/wrong information. They also never explain important core features, such as how OUT functions work (FUNCTION OUT X and X=FUNCTION() can be used interchangeably), or the fact that strings are mutable and pass-by-reference unlike many other languages.

I don't think there is a single page of the official documentation that doesn't have some missing/outdated/wrong information. They also never explain important core features, such as how OUT functions work (FUNCTION OUT X and X=FUNCTION() can be used interchangeably), or the fact that strings are mutable and pass-by-reference unlike many other languages.

What about CHKMML's page? I didn't see anything wrong with it.

I don't think there is a single page of the official documentation that doesn't have some missing/outdated/wrong information. They also never explain important core features, such as how OUT functions work (FUNCTION OUT X and X=FUNCTION() can be used interchangeably), or the fact that strings are mutable and pass-by-reference unlike many other languages.

What about CHKMML's page? I didn't see anything wrong with it.

OUT/()

If nobody else is doing the sprite transform examples, I can try to do them. I'll start working on the examples after I finish my exams.

If nobody else is doing the sprite transform examples, I can try to do them. I'll start working on the examples after I finish my exams.

No one else has started on sprite instructions yet, so please do!

I don't know how to code with BASIC, so I don't know how to help. @3@

I don't know how to code with BASIC, so I don't know how to help. @3@

If you can sprite, you can help with sprite documentation. The same with sound

I don't know how to code with BASIC, so I don't know how to help. @3@

If you can sprite, you can help with sprite documentation. The same with sound

I don't know how to program, and I need to learn how to program.

I don't know how to code with BASIC, so I don't know how to help. @3@

If you can sprite, you can help with sprite documentation. The same with sound

I don't know how to program, and I need to learn how to program.

I said "help with" not "do". If it was do knowledge of how to use the sprite comnands would be required