Grid 12 Wiki

[delsy]

Justin: Everything helps!

Crunch: I'm not familiar with Github. What does the porting accomplish?

I seem to recall an index of sorts for all the articles on the wiki, but I can't find it now. It tells me there are 46 pages, and I'd like to actually be able to sort through them.

[tarbomb]

Desly: the main rationale behind porting the stuff to github is so we can absorb the functionality of Amit's tank viewer.

Wikis on github are git repos, so they can be edited pretty easily by a script - all that is required for the script to do is to pull, edit the local copy, and push a new version.

On the other hand, wikia's API doesn't seem to support script-based editing in any way. That means that to keep pages up to date we'll have to have users manually copying data from Amit's tank viewer page - not really a good solution.

[delsy]

So the plan is to make Github the new wiki?

[Jufda]

Mar 9, 2014 20:33:42 GMT -5 delsy said:

So the plan is to make Github the new wiki?

It's already becoming the new wiki.
Level 8+ tanks need info.

[amitp]

Mar 9, 2014 20:27:00 GMT -5 tarbomb said:

On the other hand, wikia's API doesn't seem to support script-based editing in any way. That means that to keep pages up to date we'll have to have users manually copying data from Amit's tank viewer page - not really a good solution.

I can make the tank viewer output something that makes the copy and paste easier, if that would help. It's also possible, with some work, to output the tank graphics as static images so that we can link them directly into the wiki instead of having to copy them.

[delsy]

Is there any advantage to wikia over github, aside from not needing an account to edit it?

[trapped]

Mar 10, 2014 14:57:19 GMT -5 delsy said:

Is there any advantage to wikia over github, aside from not needing an account to edit it?

Probably Wikia has some graphical optimization for mobile devices and so.
Though, in terms of styling, we might just extend the Nexus (which is currently hosted on GitHub Pages, for free) to add something for wiki visualization; GitHub doesn't have a wiki API, so we'll have to build it ourselves eventually (a lot of fun).
The advantages of GitHub itself, aside from the wiki, consist in an easy visualization of repo information (commits, users, files, etc.), forking, local clones, pull requests, and other stuff like that.
GitHub's core is git, an open source revision/version control system. git makes working together easy by letting users get a local copy of the remote repository, edit it, then push the changes made to the server, which then merges the files (sometimes a human is required if the merge process is complex).
For example, to pull the latest files from a repo you already have set up on your pc, edit them, and then push the changes, git is this simple:

$ git pull
[git downloads]
[user edits the files]
$ git commit -m "I made some edits to correct typos"
[git caches the changes to the files]
$ git push
[git uploads the changes to the server]It is also possible (and quite easy) to embed a git client into programs, which allows the pull-edit-push process to be automated.

For example, assume rob implemented APIs to get build news/announcements; when a new build is pushed, Rob's server would make a request to the one amitp has, which will parse the data to generate text and images to fit the wiki, then push the changes made to the build history page in the wiki.

You can understand from what I've said about git and GitHub that, since the wiki itself consists in a git repository, it benefits from the same advantages: easy merging and collaboration, tracking of edits and files, et cetera.
Wikia's little advantages, as I said, probably consisting in more "compatibility" (remember that we're talking about a web page), which is unnecessary right now.

[delsy]

Wikia does have some optimization, while Github's wiki seems accessible only through the desktop version. But at least it doesn't have ads.

[delsy]

Some stuff, discuss?

A number of tank pages say "specific stats on the Corsair can be found here" for the gridviewer link. If we change to "Specific base stats here", we'll avoid further copy-paste leftovers. Minor error in any case.

Is it necessary to put hotkey: x after every trigger description?

Is the gridviewer synchronized to updates?
----
I pledge articles up to Wildfire plus Dragon and Scorpion. Beyond that, people who have dem high-falutin' tanks will have to pick it up.

[Crunch]

delsy, you're awesome, so if you think "Specific base stats here" is better/simpler, go with it. Also, I agree that Hotkey: X is redundant and ugly. Axe it if you like

Amit's Viewer is generated by the sql that Rob dumps after a new build. I can't remember if this is done in a *fully* automated capacity (like daily server checks) or if Amit needs to initiate the process after each build. Because the latest build doesn't currently seem to be reflected by the viewer (even though the sql is up to date) I assume that Amit needs to start the update process himself...?

[amitp]

Mar 13, 2014 3:32:17 GMT -5 Crunch said:

Amit's Viewer is generated by the sql that Rob dumps after a new build. I can't remember if this is done in a *fully* automated capacity (like daily server checks) or if Amit needs to initiate the process after each build. Because the latest build doesn't currently seem to be reflected by the viewer (even though the sql is up to date) I assume that Amit needs to start the update process himself...?

I currently trigger the update process manually, because of the way the rest of my web site is set up. Everything else on the site is a static page that gets reviewed before updating, and I haven't put the time into making a separate process for the viewer that doesn't require review. Laziness on my part. I run "update-jetbolt.sh" and it puts static pages up, and then I use my existing review & upload script that I use for the rest of the site.

[trapped]

Mar 13, 2014 10:58:53 GMT -5 amitp said:

I currently trigger the update process manually, because of the way the rest of my web site is set up. Everything else on the site is a static page that gets reviewed before updating, and I haven't put the time into making a separate process for the viewer that doesn't require review. Laziness on my part. I run "update-jetbolt.sh" and it puts static pages up, and then I use my existing review & upload script that I use for the rest of the site.

You could ask Rob to POST or whatever your server automatically after dumping,and automate the process.

[amitp]

Mar 14, 2014 1:52:50 GMT -5 trapped said:

Mar 13, 2014 10:58:53 GMT -5 amitp said:

I currently trigger the update process manually, because of the way the rest of my web site is set up. Everything else on the site is a static page that gets reviewed before updating, and I haven't put the time into making a separate process for the viewer that doesn't require review. Laziness on my part. I run "update-jetbolt.sh" and it puts static pages up, and then I use my existing review & upload script that I use for the rest of the site.

You could ask Rob to POST or whatever your server automatically after dumping,and automate the process.

Right, but that doesn't fit the way my web site is set up. Right now, the public site is static only. There's no POST / CGI / etc. support. And the content is generated on a machine inside the firewall which is inaccessible from the internet. So yes, I could change this setup, but I've been too lazy. :(

[trapped]

Mar 25, 2014 10:02:30 GMT -5 amitp said:

I've been too lazy.

Well, you should probably upgrade to a more extensible setup, it's not that hard.
Imagine all the fun you could have if just more interaction was possible!

[israphial]

Updated a small part of the wiki - Added a note on shards, death, and region resets. Nothing major... Yet.