NextCo V2 Extreamly basic source framework

[go for it]

NextCo V2 is an attempt to increase my programming skills and **** the fear of start on a new source from scratch, this is a basic framework with impulse database classes also was using original trinity as reference

there is nothing fancy, i've worked so hard to get a better design (ex. socket system and the CPacket class which is child of IPacket and parent of the rest of packets classes that you won't need to write every method all over again at every class and still will use all of classes as IPacket object which could be what i've really proud of learning at this project, also the custom queue instead of splitting packets which was mainly mr.pop idea credits goes to him)

more over this wasn't even tested and i won't promise it's 100% right, no syntax errors but maybe there is logical ones, please forgive me as it's my first try EVER to write some big project, im no longer having time to work on it plus i would start it all over again for even better ideas i want to apply

you may use this, rename it, release it, but you may not call it your's or not giving credits

credits for this projects goes to the following people (not in order and it could be direct help or indirect by releasing information)
go for it (AndrewxXx)
Mr.PoP
Korvacs
Impulse
cptsky
Infamousnone
pro4never
shadowman123
bausshacker
fang
Ultimation ^^

and anyone else who ever helped me out and published helpful information for the community

one more thing, i sometimes overused global namespace instead of certain namespaces for sake of simplification but it turns out to be a bit messy and same goes for adding enums at the namespaces and not inside there classes

[Super Aids]

I am on the list *.*

Btw. good job on improving and good luck in the future.

[Smaehtin]

Just commenting on the packet classes for now.

First of all, the naming of your packets are HORRIBLE.

All your packets inherit from CPacket which exposes a set of usable Readxxx methods yet ALL the packets' getter properties are using BitConverter.Toxxx. Why?

Your IPacket interface has a method called ToArray that returns the packet as a byte array. Why the **** are you exposing the byte array as a public member of CPacket then? ("public byte[] Packet;" - Packet.cs line 8)

In your ChatPacket class you're exposing public members and naming them with underscore prefixes - and the "Message" member even has DOUBLE underscores. Why?

There's so much more to comment on, but I'm starting to get sick from looking at this code

[U2_Caparzo]

good job i used impulse's source as base for the first source i wrote too xdd, btw.i don't know why the CO2_CORE_DLL's cripto. implementation is almost never used, in fact, i only saw it in csv3, let's move to a native calls independency ^^

[go for it]

Originally Posted by Smaehtin

Just commenting on the packet classes for now.

First of all, the naming of your packets are HORRIBLE.

All your packets inherit from CPacket which exposes a set of usable Readxxx methods yet ALL the packets' getter properties are using BitConverter.Toxxx. Why?

Your IPacket interface has a method called ToArray that returns the packet as a byte array. Why the fuck are you exposing the byte array as a public member of CPacket then? ("public byte[] Packet;" - Packet.cs line 8)

In your ChatPacket class you're exposing public members and naming them with underscore prefixes - and the "Message" member even has DOUBLE underscores. Why?

There's so much more to comment on, but I'm starting to get sick from looking at this code

im sorry that you are sick and well lets take them a point by point
about the chatpacket class it's copied as it is from trinity not even mine

about the CPacket, the set of readxxx/writexxx was going to be used later which doesn't need instance of the byte[] for sake of fasting the coding of anything
ex. packetinstance.writebyte(byte,offset) instead of using the static version of them ex. writebyte(byte,offset,byte[])
i was going to use the readxxx but i've copied some packet structure and didn't bother converting them from bitconverter to readxxx as i was really in hurry

about the ToArray on the interface, yes you got a point i should have made the packet as private

i would love to get more comments as it will help me on the next time i give it another shoot too from real scratch with nhib. and better design, sorry that you are "sick" but i think it's okay as everyone sucks at their very first

Originally Posted by U2_Caparzo

good job i used impulse's source as base for the first source i wrote too xdd, btw.i don't know why the CO2_CORE_DLL's cripto. implementation is almost never used, in fact, i only saw it in csv3, let's move to a native calls independency ^^

to be honest i've just copied the crypto from some trinity edit to save time, but yes i've seen the cptsky dll and it's really amazing, i would definitely use it if i developed this source anymore thanks buddy

Originally Posted by Super Aids

I am on the list *.*

Btw. good job on improving and good luck in the future.

thanks mate that was motivating ^^

[Spirited]

Good job. You're really improving. I'd really like to see you continue this project if you're still interested in doing so. Btw, check out concurrent dictionary and concurrency / parallel in .NET.

[Ultimation]

im not on list

[U2_Caparzo]

Originally Posted by Ultimation

im not on list

Who are u?

[go for it]

Originally Posted by Ultimation

im not on list

lmao not anymore :P

[Korvacs]

I'll be honest I haven't downloaded it to take a look, but based on a couple of the above comments you should be working on simplifying and consistency. Rewrite your packets to use either one method or the other, it doesn't matter which as long as its the same throughout.

You should not go down the route of complication for the sake of complication otherwise you will end up in a situation where yes it might work but its needlessly complicated to the point of confusion.

In other words, follow Occam's razor when coding.

[go for it]

Originally Posted by Korvacs

I'll be honest I haven't downloaded it to take a look, but based on a couple of the above comments you should be working on simplifying and consistency. Rewrite your packets to use either one method or the other, it doesn't matter which as long as its the same throughout.

You should not go down the route of complication for the sake of complication otherwise you will end up in a situation where yes it might work but its needlessly complicated to the point of confusion.

In other words, follow Occam's razor when coding.

please do, i would love to know my mistakes to avoid them in future
i was planning to use my methods but for sake of decreasing unsafe codes which wasn't even mine i've just gone with the bitconverter instead of other methods i got, it's not a big deal

there is nothing complicated, it's just something i figured out after working my mind instead of just copying with trinity base style
for sake of saving your time here is what we was talking about

public interface IPacket
{
    unsafe void WriteStringWithLength(string arg, int offset);
//rest of writexxx
    unsafe ulong ReadUInt64(int offset);
//rest of readxxx
    byte[] ToArray();
}

    public class CPacket : IPacket
    {
        public byte[] Packet;

        public unsafe void WriteString(string arg, int offset)
        {
            fixed (byte* Buffer = Packet)
            {
                ushort i = 0;
                while (i < arg.Length)
                {
                    *((byte*)(Buffer + offset + i)) = (byte)arg[i];
                    i++;
                }
            }
        }
//rest of write and read were removed just to point out what i mean, feel free to see the source for the rest of methods
        public unsafe ulong ReadUInt64( int offset)
        {
            fixed (byte* Buffer = Packet)
            {
                return *((ulong*)(Buffer + offset));
            }
        }

        public virtual byte[] ToArray()
        {
            return Packet;
        }
    }

and at the rest of packet classes im inheriting CPacket , with maybe 3 ctor

        public DataPacket_10010_()
        {
            Packet = new byte[37 + 8];
            WriteUInt16(37, 0);
            WriteUInt16(10010, 2);
        }
        public DataPacket_10010_(byte[] buffer)
        {
            Packet = buffer;
        }
        public DataPacket_10010_(uint Identifier, uint Value1, ushort Value2, ushort Value3, ushort Type)

so i end up gaining 2 benefits, first can use packets classes as IPacket object also i don't need to write every method at the IPacket on each packet class and finally i'm having the byte[] object at the CPacket class so i can directly use it within the methods of the CPacket class without including it in the statiic usual methods ex. WriteUInt16(37, 0); instead of WriteUInt16(37, 0,Packet);

away from that and the custom queue there is nothing new, maybe the socket system but it's kinda the same as others

[Super Aids]

Why do you put the packet-type in the class name? Wtf.

What if the type changed? And especially for general data. It has changed one time and it may change another time.

[go for it]

Originally Posted by Super Aids

Why do you put the packet-type in the class name? Wtf.

What if the type changed? And especially for general data. It has changed one time and it may change another time.

ill skip the naming part however i was planning on editing the name to be more convenient

whenever the type changes i would simply rename the class and let the visual studio rename it everywhere on the project

i really expected more objective criticism :\

[Super Aids]

Dumb thing to do,it's pointless to do it like that and it looks ugly. Just change the file name to have the packet type and perhaps make an enum or class with constants.

[go for it]

Originally Posted by Super Aids

Dumb thing to do,it's pointless to do it like that and it looks ugly. Just change the file name to have the packet type and perhaps make an enum or class with constants.

ill get everything better if people told me that it's good to be a base and worth time it needs to be usable, what i really want to hear is if there is any fatal errors or wrong logic, something could be better at the design that i should change before i start building more with something i would want to change later on
im planning in the next 4 days to switch to nhib, use concurrent instead of custom thread safe directory, rename the classes due to the special char '[',']' been translated to _ which yes looks ugly
fixing some access modifiers and get some properties inline, remove useless objects at the socket/wrapper class
im willing to work on it more and more but i badly need someone expert to enlighten me and tell me if im on a solid base which is worth it or should i start all over again, that's basically why i even released it