ToME: the Tales of Maj'Eyal

I was thinking that this would be a good point to start a new t-engine wiki for strictly code documentation, HowTos for extending the t-engine, and module making. Only developers would have write access to keep away the spam and general mess of the current wiki. Wiki suggestions could come through the forums.

What do you think?

This would also enable new starters on the project to look at things and give them an idea of what is involved.

It might also include module makers stuff as well.

_________________
Regards

Jon.

My only beef with that is I hate how the wiki is set up. Couldn't we provide the same info for people while still staying with the boards here?

_________________
And it was such a good idea...

I don't mind where the resource is as long as we have it. I would prefer a WIki, but we run into the problem of who would host it.

If we can't find a volunteer to host it, then perhaps a developers board would be a good place to start. The proviso here being that only the developers and mods could post there, but it would be readable by everyone.

Eric, it is your proposal, do you know of anyone able to host a wiki?

_________________
Regards

Jon.

I currently host the bug tracker and several various wikis. Hosting another shouldn't be much trouble.

Sounds good, though perhaps hosting doxygen (or something else for lua?) docs and officially supporting it in the code might be nice?

The C code (haven't looked at the lua much recently) seems to have a lot of extremely long-winded descriptions in at the moment. Would these simply be copied to the wiki?

The current wiki really isn't too bad (simply requiring registration to post would eliminate most of the spam, I think?)

I fully agree with supporting doxy/luadocs code docs. I think this should be a requirement for all future activity.

One option would be to not post any code documentation for the public until all the code has been documented, then post those doxy/luadocs along side the wiki information. Another option would be to post the code docs in chunks as they are completed.

Luadocs (http://luadoc.luaforge.net/) works very well and has a very similar style for creating the comments in code as doxygen does.

My thoughts were that the new wiki would be used for describing the t-engine internals (map generation, SDL UI, item generation, AI, etc), how to code using the C/Lua interface, how to write modules for ToME using the modified Lua system (I'd love to change that too, btw), how to debug a module, etc. All wiki talking points would be on the forum.

I'd leave the current wiki be. I'd think that locking out users from being able to add to it would not go over well. It's a poor-man's forum, so to speak. Starting fresh has a nice feel to it.

Luadocs certainly looks nice. I assume it won't mind the weird ToME version of lua?

Once upon a time there was this: http://ty2.berlios.de/tome_lua_api_docs/api_index.html
Which I guess is from the .pkg files, but I don't know what was used to generate it.

But a set of wiki how-tos and descriptions sounds good.

The new developer wiki is now online at http://www.tomedev.net/tome/wiki.

If you are a T-Engine developer and would like write access, leave a request on this thread, or send me a PM.

Also, the Alpha 19 docs are up at http://www.tomedev.net/tome/docs. Currently this is for the C portion of the engine; the Lua portion needs more testing with the modified version of Lua that we're using.

Thank you for cleaning up the 3 guides I've posted so far estevens. I should be able to get back to writing the remaining ones in a couple weeks, though they'll also likely take longer than the first 3 did.

FACM, happy to help; I enjoyed reading it. I'd like to see some sort of standard code notation for this wiki to keep things consistent. This was a good exercise for that. I tried using a method I developed for Mediawiki at my work, but Dokuwiki just doesn't have the power to do what I want. Things are a bit harder with Dokuwiki.

I'm thinking about splitting up guide 2 due to its size, possibly breaking out the different new_* types into separate pages. I have a few other things I want to get done first though.

Eric