Author
Topic: Help file... here we go again. (Read 15692 times)

First, about the index, I don't know and would need to research. For this to work, one time links have to be recognized as toc tree (need to use bullets in markdown) and references like See Also must not be recognized as toc tree.

In the new Scripting Language section, are these valid topics? I really don't know how to teach programming.

Scripting Basics

First Time Scripting- .asc and .ash extensions- How to edit- Hello World- How to build and run- Building error- Runtime error- Script ordering

Arithmetic and Strings in AGS Script- Initializing Variables- Arithmetic expressions- Order of Operations (should have a see also link-to-big-list-of-operators)- String - Constants with Enum and #define

First, about the index, I don't know and would need to research. For this to work, one time links have to be recognized as toc tree (need to use bullets in markdown) and references like See Also must not be recognized as toc tree.

I do not think it is links what define index, that sounds more like reverse-engineering an index table. Only if there's no other way, perhaps...In Latex index keywords are assigned to articles using dedicated command. If Markdown itself does not have such feature, maybe there are special tags recognized solely by Sphynx, or maybe there is a way to assign these differently, like have a separate table of index? Personally I have no idea how this works for Sphynx, just throwing in some thoughts what I'd try to look for.

I think I found a way, it is the following, I would create a page like theindex.rst and create a toctree with maxdepth 4 and place only one element named index (the renamed Home.md), and then Sphinx would create an index like thing. The alternative I have is manually creating an index. This is because it's relatively hard to findout the hierarchy of a bunch of markdown files thrown in a flat folder.

I've also switched the the line breaks from \ to double spaces, which makes it format correctly in "unflavoured" Markdown editors, but the Sphinx build still doesn't seen to pick it up. I guess there might be an option to pickup the double space, if not I'll look at converting these lines into lists.

Also, on the Travis-CI, it's being triggered by the agshelp repository instead of the agshelp.wiki repository. I don't know if I can trigger by changes on the wiki, but will check it out if it's possible!

I've created the 3 missing pages, so the build gets deployed again. I also changed the build to work with a symlink for the index page, so now all the config and template options can stay in the other repository. This was mainly to get the build date onto the page, which isn't part of the alabasta theme for some reason, so now you can actually see that deployed HTML has actually been changed.

Slight issue, in that the link checker is now checking links in the symlink (so errors in Home.md are shown twice), so I'll have a think about how to fix that.

I had to redo the tables manually as the original Markdown had no table support, and the lack of conversion just gave rows of dashes which are valid Markdown. I'll see if I can search for any I've missed and redo them. They are pretty easy to make using the GitHub Markdown variant. I tried to post an example, but unfortunately it contains 3 dashes.

I think I've found all the tables and have finished fiddling with the checkout script. It'll now work on Windows with the BASH shell you get from the Git installer, the Windows Subsystem for Linux (TM), or the standard Bourne shell. It didn't work previously on Windows as I hadn't realised that Git on Windows disables the use of symlinks by default. Perhaps there is a better way to build without modifying the source, which doesn't use a symlink...

I need to take a break and work on something else for a while, but I'll check back in to see what happens with the recruitment thread.

The other one still works, and for the time being, I will port any modification manually from one to the other, but once TravisCI is working and building correctly on the new one, it should be the correct one to develop for!

I just realized what bothers me most about editing wiki instead of having manual pages in repository: it's impossible to distinct between versions. How are we going to tell which version of the page belongs to which version of the AGS?How that would be possible to build manual for the older version if we need to release a patch?

yes! So... I've been thinking... The original idea of the wiki was to have more contributions, since we needed the manual entry for the Editor stuff (how to use the room editor, place an object, it's properties on the editor, edit a GUI, create inventory items, ...).

I think it's better if we use the wiki to generate the manual for AGS 3.5.0 an then on store the pages on the own repo and use the normal PR+issues for contributions on the manual pages. (since the wiki isn't exactly a king in popularity)

I like the idea of just using a branch per ags version and all.

Also, later, the html generated pages should have a downloadable .zip on the release page, and then we can create a task that unzips the releases on separate folders on gh-pages... This is for The Future ™ .??:

Edit: CW, do you know what is needed for f1 to work with the generated .chm inside AGS ?

When I checked recently, I think there was an extra file present which looked like it had some extra index data in it. It does work at the moment when the script keyword matches an index name, so any issues could be just the lack of indexing, or the missing of the extra file.