Jump to content

Toinan67

Members
  • Posts

    389
  • Joined

  • Last visited

    Never
  • Donations

    0.00 GBP 

Everything posted by Toinan67

  1. Hi Gotish, Thanks for your participation I saw this doc was already commited in rev. 9406, good job! I don't know at all how C/C++ programmers document their code, I'm just giving my opinion : The general idea would be to follow Doxygen comments structure, as you began to do (@param, @see, @whateveryouwant). I appreciate the idea of making clear sentences, with a . and "easy" words, for those of us who care not english or english-speaker like me For header files, no need to add much things, except for methods directly implemented in .h files. Comments should be where we need it, in .cpp files. More globally, I think a paragraph could be greatly appreciated for each "group" (group "mailing", group "movement", group "items", ...). It could be a sum-up of the whole system, how functions behave together, in what order they are invoked. Example (quite poor I know ) First, we call function 1 to make sure blabla Then, the message is sent to the function2 for ... After that, we teleport the player to ... Finally, we call the last function, function3, to ... It could be some comments on an algorithm or anything else. As I said, a sum-up on the main behaviors inside the file. If people wants to learn more on a specific point, they can go straight to the function they want. That was just my opinion, I'd be glad to see "pros" documenters giving their!
  2. Are you really thinking adding "MAJOR BUG" to your thread will make things go faster? This is not a major bug, this is even not a bug, it's a missing spell.
  3. Sorry, but I can't the scribe ^^ I don't have enough knowledge. I can help as I said, but I don't know a lot of things about MaNGOS. I'm a bit desperate with all your comments...I mean, I know it will take a looong time, but why not begin, at least? Someone should start something alone, then others will join. I can be the "someone"...but you'll make fun of it
  4. It seems that this bug appears ONLY for Mac. The exact situation is : you play on Mac, you are guild leader, you send /gquit. Wow Error!
  5. Mangos Version: 9323 Custom Patches: None SD2 Version: 1570 Database Name and Version : YTDB 0.10.9 R533 I create a guild, then do /gquit, and boum! Wow Error. I'm using a Mac.
  6. I don't really know what choice would be the best here Self-documenting code is the first thing we think about, that's right. On the other hand, why would nearly every big projects have their own doc? I mean, I'll take Qt (one more time) as an example, the doc is just fabulous. Smaller projects have their doc, too. Don't you believe it would be a great advantage compared with "ennemies" projects? I don't know how they deal with this "doc" thing, but many people would find MaNGOS easier with a doc. It would definitely add an "aura" around MaNGOS ^^ The problem is that, for now, the code is not self-documented enough. For "learning" developers, like me, it really takes a long time to find what to change, and where to change it. For experimented devs, or devs who work on MaNGOS for some years, I understand it might be quite easy. But even for them, a doc would bring something. As xeross said, a "structure-documentation" would be the minimum, I think.
  7. "all those who understand parts of the code can contribute until a fully documented source is done by aggregate" That's what I'd like to see! But I don't really want to begin with the Wiki, then being tell "well, the wiki is not very good for a documentation, restart with Doxygen", then "well, Doxygen is not the best for documentation, try to comment to the code in the file themselves", etc... However, I believe the best way to begin is the Wiki as you said, so...let's go?
  8. Well, everyone seem to be interested in Doxygen, so why not including it to the doc/ directory to have a start-point? Do we have to begin a "non-official" documentation first?
  9. FragFrog, I totally agree with what you said =>"I am inclined to believe somewhere far in the past of Mangos development it all went wrong". This "game" directory is quite disgusting at the beginning ^^ You say it wouldn't be great to create a doc, but what would you do instead of it? Let it go like that? Maybe it's too late to start something.... As freghar said, this kind of behavior can cause horribles issues like duplicated functions or things like that. I think we all agree that something must be done, it would be great to hear main actors, which are MaNGOS devs. (I hope Vladimir's not alone! ^^)
  10. I don't really know Doxygen, but I found one documentation of MaNGOS made with this tool there -> http://amki.kicks-ass.org/doxygens/mangos/ From what I see, that's not really a documentation, but it shows the structure of the project. It doesn't really help a lot... It may be a starting point, however. Vladimir, as you said, "properly writen code can be self documented". Do you think MaNGOS has properly written code? I don't know if you guys have already seen the source code from a big big project, for example PHP-forum source code. For a 1000 lines file, there are 200 lines of commentaries... I know that's boring and everything, but I'm sure this could help a lot, and bring some "professionalism" to MaNGOS. That's what we learn first when studying programming : comment your sources, always, even for a 100 lines project. However, I don't know what's the best way to do it, directly in the source code, or externally with a great documentation. I may start a non-official doc next days Greets!
  11. First of all, sorry if this topic has already been discussed, I've made some searches, no answers... MaNGOS is what I would qualify a weird project. When I began to be interested in it, I didn't know very much in C++ and MMO's servers. I looked the sources, woaw, what a messy code, no commentaries, no explanations, nothing. Quite strange for an educational project... I'm better in easier scripting langages such as PHP. And PHP projects (for example) have docs, explanations, commentaries, etc. People can understand what is done, and bring their participation to it, or make some modifications. They seem to be organized MaNGOS does not have any of it, and I still don't know how this project can be alive without it. Today, I can do some stuff on the core, after months of work and experiments. I believe that with a documentation, it would have been wayyy faster. You'll say : nobody wants to make a doc. I'll say : nobody CAN make a doc, except half a dozen of genius Personally, I cannot do it myself. I can help, of course, but there are lots of things I cannot explain. I'm aware that today, most of MaNGOS users create public servers, and try to make money of it... (that's not a secret). Therefore, they don't care at all of how it works. Well, you cant do anything against that, but at least we can help the ones who want to understand how it works! So I propose to create a MaNGOS Doc today. Something which would look like Qt's documentation for those who know it. Explanations for all functions, classes, algorithms... What's more, I'm sure it would help devs to have a global view of the project, to be organized, to work better and faster. As I said before, I do not have the knowledge to do it alone, but I can help ! I profit from this thread to congrat all MaNGOS devs (VladimirMangos is the one I see the most, I don't know how many they are ^^). You really do a great job Have a nice day
  12. Thanks for you help. I cannot compile MaNGOS for now (OpenSSL issues etc). I didn't expect this spell would be in next revision. For the second part (lowering your threat), does someone know how much of your threat must be deleted?
  13. Mangos Version: 9211 Custom Patches: None SD2 Version: 1547 Database Name and Version : YTDB 0.10.9 R529 How it SHOULD work: See there How it DOES work: Doesn't work at all. I don't think this spell is hard to script but I cannot test what I tried for now...
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use