How hard is mangos with c++

[rusfighter]

Hey ,

I wonder how hard mangos is with c++ , i know basic of C++ but when i look into mangos src i can understand what there stands but al those variables(uint32) are hard to know , so how can i get them so i know what to use

[Le Froid]

What are you talking about?? If you want to learn c++ you will have to pick up a lot of books research a lot. If you mean you want documentation for MaNGOS I don't think there is any

[Patman128]

Compared to a lot of other projects I've seen, mangos is easy.

The variables are pretty easy to understand. uint32 is an unsigned, 32-bit integer, uint8 is an unsigned, 8-bit integer, etc.

[rusfighter]

No i dont want to learn C++ , i already know a bit of it(ofcourse want to be better) only example i want to fix a spell and dont even know where to write the script , spell.cpp or spell spellAura.cpp or SpellEffects.cpp

[hunuza]

I think understanding the spell system is at least partly independent of MaNGOS code. You should try to understand Spell.dbc structure first, then you can take a look at how we implement spell effects etc...

The file names are pretty much self-explaining or? SpellAuras.cpp is related to Auras (again, to understand what Auras are you need to understand the spell system of WoW, not really MaNGOS code...). SpellEffects.cpp contains the spell effect implementations and the common functions (like targeting, casting etc) are implemented in Spell.cpp...

[FragFrog]

Not for one thing or another, but those classes are huge. Spells alone require ~ 17.000 lines of code. Imagine being new to a project and having that amount of sourcecode to sift through to find the problem with a spell (because sadly, it's not always clear whether a problem originates in a spell's aura, it's effect or the basic implementation - at least not when you're new to the project).

I have said it before and I'll say it again: Mangos sourcecode in its current form is very hard to comprehend for new developers. I don't expect this to change anytime soon either, not unless some major refactoring takes place (which of course isn't going to happen). Just work with it a lot, hopefully after a while your patches will stop being rejected

[Patman128]

I think they actually did a pretty good job at keeping it organized, at least compared to other C++ projects I've seen. Your gripe seems to be that the spell system is too big, but I don't really see how you could make it much smaller. Of course a new developer isn't going to be able to understand it right away, but they aren't going to understand any large project right away either.

If you want to dumb down mangos source code to appeal to the lowest common denominator of "developers", be my guest.

[FragFrog]

I disagree - take a look at the sourcecode for ScriptDev2 for example. It's neatly organized, structured (in such a way that newbies can understand it) and anyone new to the project is still able to script bosses in a few hours without trouble. It is smaller than Mangos, true, but not 'small' as such - combine all the scripts and you still get a lot of code, yet they manage to make it easily accesable to newbies. Of course, the application lends itself a lot better for factorization, but to stay with the example, I could think of at least four ways to refactor the spell system more (by class, type, effect, cause, etc) - would clear up some of those huge switches for example. Or Spell:checkCast, another good one - there is an if loop of over a 150 lines just to handle the case where there is a target, another where there is no target, put those each in a seperate method and you've lowered the size of that method by a third. Which leads me to another point - a single method being over a thousand lines long? This really looks like a very typical example of code smell to me.

Of course, I am no experienced C/C++ programmer - my professional area of expertise lies with PHP (which, if anything, has thaught me the importance of very closely guarding your sourcecode - making a steaming pile of spaghetti-code is incredibly easy in a weak-typed language) and to a smaller extend JAVA. It might well be that what looks like code smell to me is the normal accepted practice in C/C++, but it seems I am not the only newbie to the project to find the code largely incomprehensible, definitely at first glance

On a sidenote: yes, I fully realise there are advantages to the current model. It is faster, requires less resources (to a certain extent anyway, depending on how well your compiler can optimize) and 'it works', more or less. Individual parts of the code seem well written to me, structured, and comments are pretty frequent. Only when you try to understand the big picture does it become troublesome, which might be in no small part due to the big picture being very, very big indeed

[Patman128]

I disagree - take a look at the sourcecode for ScriptDev2 for example. It's neatly organized, structured (in such a way that newbies can understand it) and anyone new to the project is still able to script bosses in a few hours without trouble. It is smaller than Mangos, true, but not 'small' as such - combine all the scripts and you still get a lot of code, yet they manage to make it easily accesable to newbies.

This would probably be because ScriptDev2 is an inherently simple and easily broken up thing. It simply relies on mangos to give it all it's functions and funcitonality. Very few functions called by scripts are actually implemented in ScriptDev2. Mangos, on the other hand, implements nearly all the functions and classes used in it.

Of course, the application lends itself a lot better for factorization, but to stay with the example, I could think of at least four ways to refactor the spell system more (by class, type, effect, cause, etc) - would clear up some of those huge switches for example. Or Spell:checkCast, another good one - there is an if loop of over a 150 lines just to handle the case where there is a target, another where there is no target, put those each in a seperate method and you've lowered the size of that method by a third. Which leads me to another point - a single method being over a thousand lines long? This really looks like a very typical example of code smell to me.

What you are describing is a one-use function. Some parts could be simplified maybe, yes, but taking a giant chunk and putting it into a new function and using it only once makes no sense to me. It's just having 2 functions instead of 1 for the sake of having 2 functions instead of 1.

Of course, I am no experienced C/C++ programmer - my professional area of expertise lies with PHP (which, if anything, has thaught me the importance of very closely guarding your sourcecode - making a steaming pile of spaghetti-code is incredibly easy in a weak-typed language) and to a smaller extend JAVA. It might well be that what looks like code smell to me is the normal accepted practice in C/C++, but it seems I am not the only newbie to the project to find the code largely incomprehensible, definitely at first glance

Experience has shown me that large C++ projects always looks like spaghetti code. Fortunately, there are lots of examples within mangos about how things work. For example, if you want to figure out how to add an item to a player in a script, you can check the add item command to see an example of how it can be implemented.

On a sidenote: yes, I fully realise there are advantages to the current model. It is faster, requires less resources (to a certain extent anyway, depending on how well your compiler can optimize) and 'it works', more or less. Individual parts of the code seem well written to me, structured, and comments are pretty frequent. Only when you try to understand the big picture does it become troublesome, which might be in no small part due to the big picture being very, very big indeed

You don't need to understand all of mangos to work with it. You can write scripts perfectly fine without knowing the details of ObjectAccessor. You can implement spell effects without knowing how the chat system works. That's the beauty of a large project like mangos.

[hunuza]

Of course, the application lends itself a lot better for factorization, but to stay with the example, I could think of at least four ways to refactor the spell system more (by class, type, effect, cause, etc) - would clear up some of those huge switches for example.

If you have good suggestions how to refactor MaNGOS source why don't you simply make a patch and provide them to the community? If they really improve code quality, I am sure they will be accepted.

[FragFrog]

Because quite frankly, I don't know the code well enough - exactly because we're talking about thousand-line functions here could it very well be that parts rely on variable manipulations earlier on, the chance of breaking something is quite big unless you know exactly what you're doing - I'll be the first to admit that I don't. And even if this were not the case, the codebase is simply too large to make any real difference I fear - I'd be submitting patches for the next year or so, and I'm sure you have better things to do than going over them all the time.

Not to mention the general impression I get from most active developers is that they're quite happy with the code as it is anyway