Complete QC manual rewrite

[MadGypsy]

I have begun to rewrite (and recode webwise) the entire QC Specs/Manual. Aside from providing a more current interface, I want to expand on the given information.

I am inspired by the online php manual, where a native var or function is explained and then other developers add comments that express how it can be utilized. So, in that sense it becomes a living document with the potential to categorize ?hundreds? of code snippets.

What do you QC guys think about that? I intend to rewrite it regardless, but I would like input. Anything you think may be helpful or necessary to bring the document to the next level and ensure that its "currentness" can be easily maintained.

I have already begun rewriting it but it is still early enough to make adjustments and/or add features.

[Seven]

There are already such things for the interested persons.
Try this for example: click

I can only speak for myself of course, but:
Creating QC-mods for Quake is not only to learn QuakeC.
It is 90% to have ideas how to implement something you want.
It is like learning to read/write:
You will never be able to write a book if you dont have ideas for a story and didnt read other books before.
Or I love to compare it with flying an airplane:
Knowing what the buttons do in the cokpit is one thing, but without practice you will never be able to fly.

That is why I want to repeat myself here (from another thread):
If you want to become a QC-modder, you MUST do tutorials, practice and read and read and read codes from John or other people. This is the only way to know how things are done. Or better say what ways did QC modders implement things.

The single params, fields, floats, vectors is nothing compared to the own ideas you must have to make something real.

That is of course just my opinion, but this is how most god-like coders at inside3d also recommend beginners to start:
Do tutorials, do tutorials and learn how other people/coders did something (How they changed something to make a special thing behave different in-game). That is excactly my opinion as well. From my own experience.
This will bring a high learning curve.

Sorry if this doesnt match to this thread completely, but I wanted to give you this support.
Please read some threads over at inside3d in the help section, to get a better view to this subject.

Anyhow, thank you for your effort on this topic in general!

Kind regards,
Seven

[MadGypsy]

awesome link - it is like 40% of what I intend to do. What's up with all these specs/codes being programmed to look like craigslist? What I intend to do with that alone is worth the effort.

If you want to become a QC-modder, you MUST do tutorials, practice and read and read and read codes from John or other people.

Learn a real language. If you want to be a bad ass programmer, learn how to program first. Learning a real language is going to introduce you to concepts and techniques that are common across all relative languages. People that isolate themself to QC are modders. Those that dive into any language with high comprehension are programmers.

[Spike]

most builtins should be sufficiently described with just their name, arguments, and return value (or would be if qc didn't involve so many globals, grr traceline, grr).
if you know its inputs and outputs a competent person should generally be able to figure out what it does. you can go in to greater detail for weird complex stuff like movetogoal, but the exact behaviour is generally unimportant.
just looking at the function and regurgitating its name+argument names won't help much.
what is important is the big-picture stuff. general concepts, trends, and expectations type stuff. Chuck in a few examples so you can see how the different fields/builtins/etc interact.
And make sure you include some extensions. QC without any extensions is just painful. Especially tracebox.

[MadGypsy]

I was thinking that I would re-document the entire Dpextensions. I have nothing against documenting more, but I am currently working on something heavily revolving around DP and this would compliment it.

I also wanted to start documenting some CSQC possibilities. I'm not trying to rewrite the specs in the sense of just making it look different. I want to expand it greatly. I also want to allow other people to be a part of the expansion. Just like the PHP manual site, where every "comment" is further code/information relevant to the page content.

here is a random page from the manual, look how people comment.

IDK, QC might not be a robust enough language to go that far. I have the power to go that far though. I'm a mini database table and a form away from that functionality.

[Mr.Burns]

I genuinely wish you the very best of luck MG and I for one would be interested to read the results.

For what it is worth, I suspect many potential contributors may take the view that an easy to understand plain english explaination, as you have done with some of your other posts, is definitely the way to go to get more interest in Quake development. Perhaps the easier one makes it, the more accessible the concepts become. Inside3D.com went some way down this route but the quality and depth of tutorials tends to be inconsistant. Just to add to this, rather han follow something "parrot fashion" it's often more interesting and educational to work though relevant examples and learn why you are doing it in a particular way and what each line of code is actually doing.

Just my 2 [pence/cents] worth, good luck

Monty

[MadGypsy]

Thank you, I've been working on it all day.

Turns out that the contents of the link that seven provided were generated by a python module. So, some awesome person made it possible for me to convert my QC to linksville. This takes care of a lot and quite a little all at the same time. I dont have to spend ?days? formatting qc with html, but overall that was just one of many features that I thought up.

I think I'm gonna roll with the contributor feature as well. If it's starts to become unmanageable spam then I will just do it a different way. Currently, my intention is to do it the php.net/manual way.

Things like conditional statements, arrays, loops, comparisons, etc are universal to all script languages, with very little deviation. So a bunch of this stuff can be expanded by replacing it's 1 sentence explanation with something written by a pro writer for a different language, substituting QC for the code examples.

[Mindf!3ldzX]

Thank you, I've been working on it all day.

Turns out that the contents of the link that seven provided were generated by a python module. So, some awesome person made it possible for me to convert my QC to linksville. This takes care of a lot and quite a little all at the same time. I dont have to spend ?days? formatting qc with html, but overall that was just one of many features that I thought up.

I think I'm gonna roll with the contributor feature as well. If it's starts to become unmanageable spam then I will just do it a different way. Currently, my intention is to do it the php.net/manual way.

Things like conditional statements, arrays, loops, comparisons, etc are universal to all script languages, with very little deviation. So a bunch of this stuff can be expanded by replacing it's 1 sentence explanation with something written by a pro writer for a different language, substituting QC for the code examples.

Guess looking like some shitty Craigslist clone had its benifits :F