EQEmulator Forums - EqEmu UML Diagram??

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Archive::Development (https://www.eqemulator.org/forums/forumdisplay.php?f=621)

- - EqEmu UML Diagram?? (https://www.eqemulator.org/forums/showthread.php?t=15850)

EqEmu UML Diagram??

Does anyone have a UML diagram of the EquEmu project?

Is there some sort of block diagram that gives an overview of how the server works?

The reason i ask is, looking at each of the classes without a diagram is like trying to read a map with a magnifying glass. Hard to see the whole picture :P

I realize that code documentation is low priority compared to implementing server functionality. Just curious.

Because i am bored at work :) I am going to poprt the code over to c#. Then ill do some documentation.

That....actually sounds like a very good idea.

Let me start with off with saying that software engineering is my favorite thing in the whole world. I started to do thisone day... then I realized that it was completely in veign...

theres really not very many classes... only one thing (entities) which really do much inheritance... and most classes have a shit ton of members... like client has well over 500 methods, and who knows how many member variables.

Basically, the diagram would be crazy messy, and would not make a lot of sense... even if you excluded most of the methods, some of them are related to every other class.

"some day" I want to rework a TON of code to take advantage of a better OO design (and piss off custom server admins (:), but who knows if/when that will ever happen.

I have also looked at making a schema diagram, so people can understand the DB.. that is more reasonable, as long as you dont put the columns in the diagram, because items has like 100+ columns, character has a ton, and so does npc_types.

The fact that such UML diagram is a challenge both for making and using, reveals that EQEMu software is much like a piece of junk

It's very hard to rework engine in depth, and has led to poor AI (what was the next step imo once the EMu proved stable, what it is now).

i do NOT pretend EQEMu code could be better (due to dev history), nor that i could even design something close to it (and working), but prolly there's need for an EQEMu 2, not to emu EQ2, but to have a comprehensive, workable, and efficient EMU.

GL FNW

Not true i had no problem jumping into the code, yes there is alot of it but think about it, Its a huge program, what do you expect? With many people writeing the code and many people contributeing to the project nothign will be as organized as you wish. Just my looking at the code for a couple days i found out how to work the majority of it. Its very confuseing at times but for me thats what makes it interesting. I like trying to solve problems.

A lot of the problem with EQEmu is that it wasn't designed to be clean. It was designed in pieces very quickly. It seems to me that it's always been a priority to add functionality, not implement it properly. A redesign would be nice, but it'll suffer from these same issues as we'll still have to fight the clock to get a release out before EQ is patched again.

That said, the devs on EQEmu produce great code even on such a strict schedule. Keep up the good work guys :)

you're right aabout the silly things hurry and pressure makes us do, daeken.

Do you suggest EQEQmu needs it's own client ? :p

Hey! That's a fan-fucking-tastic idea! Oh, wait ;)

I dunno... I think having a seperate client will help things a lot, as well as give newbie developers a chance to add new features without lots of reverse-engineering experience.

I agree that it's a pretty amazing program. To properly design an OO program takes time. And as you stated, the race to beat the next patch does effect things.
Now with that said, i have started porting over the code from EQEmuSharedMem to C#. Mostly converting packet structs to C# structs. It's a great way to learn the innerds of the program.
C# struct have some limitations that can be overcome with interop.

Example:

C++

Code:

struct NameApproval

{

        char name[64];

        int32 race;

        int32 class_;

        int32 deity;

};

Code:

[StructLayout( LayoutKind.Sequential )]

        public struct NameApproval

        {                        

                [MarshalAs(UnmanagedType.ByValArray, SizeConst=64)]

                public char[]        name;        

                public int                race;

                public int                class_;

                public int                diety;

        }

Unions
C++

Code:

struct Color_Struct

{

        union

        {

                struct

                {

                        int8        blue;

                        int8        green;

                        int8        red;

                        uint8        use_tint;        // if there's a tint this is FF

                } rgb;

                uint32 color;

        };

};

Code:

   /// &lt;summary>

        /// RGB_Struct

        /// Size: 4 Bytes

        /// **Used internally in Color_Struct**

        /// &lt;/summary>

        [StructLayout( LayoutKind.Sequential )]

        public struct RGB_Struct

        {

                public sbyte        blue;

                public sbyte        green;

                public sbyte        red;

                public byte        use_tint;

        }

        /// &lt;summary>

        /// Color_Struct (Union)

        /// Size: 4 bytes

        /// Used for convenience

        /// Note: Orginal source used an anonymous union (rgb).

        /// &lt;/summary>

        [StructLayout( LayoutKind.Explicit, Size=4, CharSet=CharSet.Unicode, Pack=1)]

        public struct Color_Struct

        {

                [FieldOffset( 0 )]

                public RGB_Struct        rgb;

                [FieldOffset( 0 )]

                public uint                color;

        }

Also C# does not natively support bitfields. But i found a working bitfield class (i didn't write) for that.

I am not writing this because i think it will be superior to C++ release. I am writing it so i can get a deeper understanding of the code. Once i do this, I will analyze the structure and try to implement proper OO design.

Regardless of patches,The fact is some things that do not change. Players still run, cast spells, Meditate, interact with mobs, chat, ect. How those actions get implemented should be done at a lower layer.

I think redesign is a great idea. But i do understand the limited time and resources peope have so i won' t hold my breath
:lol:

Time to throw in my 2cp yet again.

If a redesign were to be done, I think that it should be done in C++ and be made modular. True, there are many things that don't change, but there are also many things that do. That said, I've been unsuccessful at figuring out how to modularize something like EQEmu as of yet. It's possible, it just will be far from easy to impliment. But if it ever gets done, it'd simplify development greatly, in theory...

I think it could help, but it's definitely just the tip of the iceberg as for what needs to change.

Happy Hacking,
Lord Daeken M. BlackBlade
(Cody Brocious)