Official Wiki

[dulux-oz]

Is it wise to link in the Wiki to six years old and obsolete documents, like Foen's anatomy of a ruleset? And any other resources or document that's not at least 95% up to date (if not 100%) for FG 3.0.3?

Actually, I've been thinking that myself. We all would like to acknowledge the past endeavours of our fellow devs, etc, but even Microsoft doesn't keep things available forever (I know, WinXP has been around for 14+ years, but even its going now).

How about an Archive Page, where the "older" items (and I have no idea how "older" is defined, maybe anything from 5+ years ago?) can be kept for historical purposes but taken out of the main pages so as not to cause any confusion?

On the other hand, there may be some "stuff" which is "old" but still relevant. To use an example, I can't see my "Pointers Toolkit" becoming irrelevant no matter how "old" it is - not until Moon changes the actual code dealing with Pointers (something I can't see happening).

Just my $0.02 worth.

Cheers

[Blacky]

Old isn't the issue, the content is

As for how, maybe a namespace for each major old version. That way not up to date article don't show up in regular search, but it's still easily accessible.

That's the way the Dwarf Fortress wiki works.

[Bidmaron]

It is all that's available, so it should be somewhere. There is always a hue and cry for material telling how to do rulesets, but this debate shows why it doesn't exist. No one who knows enough to produce the material can afford the time to produce it, and even if they do, it is obsolete within a couple of years. Much of the material in that file is still valid. The problem is it's hard to know which parts are still valid.

[Blacky]

I strongly disagree. If something can in any way “un-help” someone who tries to learn about FG, it shouldn't be in the wiki in the first place (or in a dedicated namespace with plenty of warning).

Putting bad things in the manual does not compensate for no said manual

[Bidmaron]

If that was the case, nothing would ever get published because everything has tiny errors that "un-help" people, but I suppose we will just agree to disagree. I respect your view and certainly all you've done four our community, Blacky.

[dulux-oz]

Old isn't the issue, the content is

I don't disagree, but I would put it to you that there is a very strong correlation between the age of the material and the value/relevance it has

Both Birmaron and Blacky have valid points - when there is no material then outdated material is better than nothing BUT if you are unaware that it is "out of date" than it can lead you down the wrong path.

Let me give you an example: The 1st Ed AD&D Players Handbook & Dungeon Masters Guide have some information that is still relevant to role-playing in general and D&D in particular, but if you were to attempt to use them to roll-up a 3rd or 4th Ed Character the result would be "sub-optimal". However, if you knew these manuals were for an earlier version of the game you could still get a lot of good "foundational" material out of them - the trick is to either know what's relevant or to treat the information as "guidelines" until you can discover what is relevant to the new versions and what is not.

As far as a "Ruleset Creation How To", my experience is that people ask for one because they genuinely have no idea how to go about things or they are trying to find a shortcut and avoid the need to learn all the basics (ie XML, LUA, etc) - not a bad thing in and of itself, but anything as complex as a computer program designed to handle multiply different RPG mechanics must be a comlex beast and therefore is going to take some time to learn.

I come across this in my professional life all the time - its called "End-User Computing" and is where you get people who don't know the basic theories behind, say, good database design, creating a desktop, single-user app that everyone in the office likes and so everyone starts using but which hasn't taken into account the requirements for multiple users accessing it at the same time from multiple different PCs, let alone having given any thought to security, scalability (already mentioned), reliability, etc.

To do a decent Ruleset How To that is going to stand the test of time/version changes requires it to be:

1. Not small
2. Not quick
3. And cover the fundamentals first (ie XMl, LUA, Programing Principles, etc)

to name but a few requirements.

I'm actually working on such a How To (making notes, jotting down ideas, etc) as I produce each of my Tutorial Videos and Extensions, but it's going to take a while

Just my $0.02 worth

Cheers

[Blacky]

Both Birmaron and Blacky have valid points - when there is no material then outdated material is better than nothing BUT if you are unaware that it is "out of date" than it can lead you down the wrong path.

I disagree with the first part. Bad is worse than nothing.

Let's say I bought FG yesterday. I fiddle with it for several hours, read some forum post, do a lot of Google search (to no avail), then because I have serious programming skills I start writing a ThisGame™ ruleset for my ThisGame™ campaign. I read around, and follow the official website to a document that says (it's just an example): take the D&D ruleset, strip everything you don't want, and then edit on top of it your ruleset. Fine. So either I'm throwing the whole lot by the window after 10 hours because the D&D ruleset has a lot missing, either I manage to do it and after 90+ hours of work I discover than nonono I could have imported the CoreRPG ruleset in two lines of code, and now either I enter maintainability hell or I just start from scratch.

Yeah, if I'm this person, I'll start looking at making pipe bombs for the SmiteWorks office suite ^^

For beginners, maybe most people, "nothing" is better than something bad. That doesn't mean something needs to be perfect to be published (actually I made the opposite point when I argued–and lost–that the wiki should be open), as long as it's either good self contained (a good small advice is better than a big bad advice) or there is clear warning label on it.

Saying on the wiki that the max size of a bitmap frame is 2048² is incredibly small, doesn't cover anything else in the frame department, but it's still very useful. Giving code example on the wiki that doesn't use string files will lead to confusion and infuriate both the coder and the users (to take another simple example).

It has the secondary advantage of showing the true state of FG documentation, and maybe help convince people to do something about it

As far as a "Ruleset Creation How To", my experience is that people ask for one because they genuinely have no idea how to go about things or they are trying to find a shortcut and avoid the need to learn all the basics (ie XML, LUA, etc) - not a bad thing in and of itself, but anything as complex as a computer program designed to handle multiply different RPG mechanics must be a comlex beast and therefore is going to take some time to learn.

This is a different debate, one quite chronic and one we had a few weeks ago only. I won't feed that here, but the current fact about the state of FG is that you are expected to parse through thousands of uncommented code lines written in a specific über niched framework to try understand things. In any other environment or software, even professional software engineers will answer to that with a cricket bat. And on top of that, the reference doc is both incomplete and false (not a lot, but enough). And that's a fact just from reading the answer given on the forum, there's bound to be thousands of people who don't bother asking on the forums.

Now it's a choice, and SmiteWorks have very small resources so it's very fast a question about pushing all features one, two or maybe three months back and planning ten or twenty percent less features in the future years, or keeping the status quo of saying that if one doesn't play D&Dish or 4-5 other games one either has no reason to use FG or doesn't use FG at more than 5% of its capability while enduring mysterious inscrutable issues.

But in any case, no relevance to my initial inquiry which wasn't about specific content, but about obsolescence general policy and at least not making things harder for users.

[dulux-oz]

I disagree with the first part. Bad is worse than nothing.

Then I'm afraid we're just going to have to agree to disagree.

This is a different debate, one quite chronic and one we had a few weeks ago only.

Yes, it keeps coming up - and it does so for a number of reasons, including those you've listed.

...is that you are expected to parse through thousands of uncommented code lines written in a specific über niched framework to try understand things. In any other environment or software, even professional software engineers will answer to that with a cricket bat. And on top of that, the reference doc is both incomplete and false (not a lot, but enough).

Again, I don't disagree with you - a possible solution is for you (or someone else with the inclination) to do something about it eg write some doco.

But in any case, no relevance to my initial inquiry which wasn't about specific content, but about obsolescence general policy and at least not making things harder for users.

Maybe not relevant to your initial inquiry, but as the conversation went in that direction... and actually, you did mention specific content, but, hey, what the hey.

[Bidmaron]

The community and JPG answer every question asked about coding, so I think the documentation is quite useful. Slightly incomplete and occasionally even wrong, but, as we've been arguing, better than nothing.

Anyone who is going to take on something as complex as a ruleset is going to have to delve heavily into existing examples. It is just not for the light-hearted, as Dulux has elegantly stated. There is such a huge burden to making and keeping documentation, that I just don't think it's worth it for the size of company that SmiteWorks is. I just appreciate that we have the documentation that we do have.

[AstaSyneri]

Having been through some of that I absolutely agree with Blacky.

I'd love to have a Wiki that shows me what I can do, rather than what maybe I could have done 2 years ago but won't work right now (without telling me).

Bad documentation is worse than no documentation.