The unfinished Guide to codeing!

[ClockWork]

Salutations!

This thread is here to teach others about the grand works and language of coding. Or more specifically, messing around with the spaghetti like programming that is Warzone: 2100. Mostly, this is to help those understand the complexity of how to read just what goes into it all. So to be clear, there are no stupid questions. (By the end of this, I know I’ll have stupid questions of my own.)
First off, allow me to state that I have never messed with the coding or languages of code. However, I want to go step-by-step on lessons, posting pictures of what to do, and how to do them. By doing this, I hope to teach others and myself about how to put together this great game. (If the mods could help out, and point out things that I am doing wrong, it would be greatly appreciated.)

The first question: Where do we start?
First, we want to find the source code of the game if we want to start messing around with things. The hunt begins at the home page of wz2100.net: once there, head over to here

-
Once greeted at the development tab, go ahead and proceed here

-
This is the Compile Guide. I have no idea what any of this is, but that's what we are here for, right? To learn! HAYO! I’m not messing with the guides for now, as I don't know what they are talking about. So why not dip our hands directly into the source code, see what it looks like. Simon says go here: here

gitcompileguide.PNG (6.92 KiB) Viewed 3960 times

-
Not much to gander at, but we are getting closer! Please click once more here
-
Ah, this is where discovery happens. This is what we will call the source code, unless I am mistaken.

Now, what do we want to do? There are tons of bugs that need to be fixed. But what do we want to fix? How do we know what in the game is broken? Luckily, the staff has provided us with a nice bug tracker, which helps to organize everything bug and broken related.
From the development tab we were in earlier, let’s go to the : view tickets tab
-
It is here that you can chose how to view the tickets. Basically, all you would need to do is select a ticket, and see what is wrong. This is where I have to limit myself. Being that I have no idea what half of them are talking about…I simply cannot comply or understand what anything means. Therefore, we will need to learn what all this coding language is trying to tell us. I’m no teacher in that department, but I’m hoping someone here will point us in the right direction.

[dak180]

I would recommend checking out CommitGuidelines first.

[cybersphinx]

Good idea for a thread, it is nice to have this documented by someone else who runs into all the issues we don't even recognize as such.

Github has good general docs on git: http://learn.github.com/p/intro.html

[lav_coyote25]

thankyou - and yes, it is time. when done , it should be an awesome tutorial.

[ClockWork]

So I had a sudden inspiration to do this again, after having a long talk with myself.

So with some help, (thanks guys!) There are some programs that will aid us. One of them is ‘Git.’ It is found in the development tab on the home page. Under this tab, there is another tab, called wiki. There is a link where it allows you do download Git, along with instructions. We’ll go ahead and head on over here:
-

So what is Git anyway? I haven’t a clue. But allow me to boast a few words about what it is.
” So, what is Git in a nutshell? This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar; understanding those differences will help prevent you from becoming confused while using it.”
Now, this link isn’t necessary that I’m about to place, but it will help to understand more about the program. Getting to know Git.

Step one: Download and Install Git.
Now then, let’s go ahead and download Git. The link should look something like this:
-

Going to the download link should show different versions of Git. I chose the first one, since it seems to be the most recent one.

Once you have downloaded the one that you want, it’s time to set it up. Look at the setup page here very carefully; it contains all the steps you need to take to set it up. I cannot explain it better the it does there, so after we are finished, we’ll go to the next step…

Step two: Set Up SSH Keys.
Again, it explains it better on the page. Please follow the instructions.
1) Check for SSH keys.
Once you open Git Bash, simply type this phrase in the box: “cd~/.ssh” (no spaces)

2) ?
^^I skipped this one, since I didn't have an ssh key.

3) Profit! Generate a new SSH key.
After checking for ssh keys, type this into the box: [email protected] (the _ underscores represents spaces. Also, the code is cAsE sEnsItIve) After hitting enter a few times, you should have a finger print of your ssh key now.

4) Add your SSH key to GitHub.
Now we can add this code to the GitHub. It’s going to want us to head over to the web site. The link should be on the top right corner of the instructions page. so let’s go there:
-

…Okay, it got a little more complex. This better be worth it…
Let’s register on GitHub! I trust this will help us a lot in the near future.
…
…now with that minor annoyance out of the way, lets head over to our account settings: <<-- (or just click the links that I’m providing as shortcuts. But it’s recommended to get acquainted with the surroundings.)
-

Find the link called “SSH public Keys.” Click “Add another public key.”

Open the id_rsa.pub file with a text editor (Notepad, TextEdit, or gedit will do just fine). This is your public SSH key. You may need turn on “view hidden files” to find it because the .ssh directory is hidden. It’s important you copy your SSH key exactly as it is written without adding any newlines or whitespace. Now paste it into the “Key” field.

To find the id_rsa.pub file, you will need to find it where it defaulted to saving it too on the computer. It should be in /C:/users/yourname/.ssh/id_rsa.pub.

Once you have copied and pasted it onto the “Key” field, click “Add key.”

5) Test everything out.
On GitBash, simply type the phrase [email protected] (no quotation marks, _underscore is a space.)
Then type “yes” after it’s done.

Step three: set up your info.
1) on the GitBash, type in the following:
git_config_–global_user.name_“insertname” (I think we know the drill. Though while it says to use your name, I honestly don't recommend doing so. They can shuv it up their pipers if they want my name.)
git_config_–global_user.email_“insert email here”

2) Set your GitHub token.
Now then, let’s go to your account settings on GitHub, over here:
-

Now, go click account admin.
On the command line on the Gitbash, you will run the folloing commands:
git_config_--global_github.user_”insert username” (_underscores are spaces, no quotation
marks.)
git_config_--global_github.token_”Insert token number” (the token number is the API token that appears as a long string of letters and numbers.)

Lastly, congradulations!
So what did we just do? …I have no idea. But We will continue expanding on this and learning just what goes into what later.

[cybersphinx]

Some general explanation:

git is a so-called (Distributed) Version Control System. A VCS takes a set of files and records them, and records changes to them, either by saving the new state (what git does), or by saving the differences. It also allows people to get this repository of files onto their systems, and to look through the history of the files to see what changed over time. "Distributed" means that there is no central server (at least by protocol, there can be one by convention), and every user has a full clone of the repository including all history and branches (in SVN for example, you have just a checkout of one specific state of the files (and usually just one branch), and need to connect to the server for most operations). It also means that you can commit changes locally (possibly fixing/changing/dropping them), and then push them to a public server later (unlike SVN, where every commit instantly goes public).

The ssh key mentioned above is needed for authentication when pushing your locally committed changes to the public repository on GitHub. The token seems to be an alternative method of authentication, I've never needed that here.

Using your real name or not is mainly a question of attribution, if you don't want your work connected with your real name, you don't need to give it.

[ClockWork]

That explains it a lot better. *jots down notes* would you say that a little then half the steps I took weren’t really needed? If I can cut this down to size, it would be simpler to follow and easier to go through.

[cybersphinx]

I think you need either the token or the ssh key. As I said, I used the key, and have never needed the token.