come inside for more info :D

[BBim]

especially rhisis, one thread per player woooot! my god.

lol keep yourself update :P
Rhisis is changing its base because of that and other bad things from the old source. It still wont be the best but Im looking around the internet on better ways to handle things and everything, so its not true that we are focus on features and not stability. Same apply to osA(from what I know :P) because adidishen asked me how we handle somethings to see what would be the better way.

[adidishen]

Word up !


Well, that was just my feelings by looking at sources of rhisis and osa, its your right to focus on features but once you have all of them, you will end up with a playable emu which is definitly a good thing in case you are not a afraid of handling less than 100 players with randoms lag / crashs. I strongly pregonize to implement a solid framework before implementing features, It's take time yep, but once you have done that, developpement will go faster, safer.
I think I read somewhere you were using lua as scripting language. Well lua.net is slow so if you want to learn, write your own scripting engine :p
Another note if you want to increase performance, rewrite your network implementation lol :P
Use SocketAsyncEventArgs http://msdn.microsoft.com/fr-fr/libr...eventargs.aspx, it's extremly high performance ;]
Add async query for your database, not hard to implement on C# ;) but most of all I would suggest you to use design patterns such as ObjectPooling :] Trust me your emu will beat every emu there, especially rhisis, one thread per player woooot! my god.

Actually the new world server I'm writing atm does not crash w/ 100 players online; I've tested it using selfmade bots program which spams chat packets (not a big deal, but between us - this could really crash a weak computer)
The networking is also different than the world server you see now.
Other than this, I have nothing else to say.

[GlaphanKing]

PG is utilizing the power of the dedi processors to use multiple processing power the way it was meant. Meaning, most dedis are dual core so it would be one processor for the main threads and the other processor for the actual functions and processes.

What Adolf said can work but it really isn't the best way to approach it. One thread is a must though but you can get away with 2 or three with out a slow down.

However, if you have 8 threads and 800 players, no wonder it will crash. I commend all the developers for seeing this fatal error and working around it. I'm anxious to see what all of us will come up with.

Sounds like a battle plan to me.

3 cheers for thinking outside the box people.

[adidishen]

20 threads for receiving, and 1 thread for each map should be the solution o_O

[GlaphanKing]

Hmm. Perhaps you might be on to something. :D

[theunreal]

Lol at Osa and Rhisis. First of all, Rhisis is closed source now and as it is now, with 2 people on the server it crashes just about every 3minutes. Oh and Osa works great for a pserver too. Kill an aibatt and you crash xDD. I actually am looking forward to when Osa flyff will surpass caali files, but that won't be for a long time. No sources right now are CLOSE to caali rev1.

Maybe if we stopped making so many projects and focused on one common language we would get somewhere. Visualbasic flyff...can't even get in game and is in BASIC coding, which will make processing very imprecise/laggy with many people online.

Oh, then we have autoit flyff lawlz let's not even start with that.

Glaphan's project is interesting and I would like to work on it or use it when it is stable, but this is his third incomplete project. I support flyff source development but this is going no where fast.

Oh and I almost forgot about how "incomplete" these caali files are. They are incomplete but a shit load more complete than anything else out there.

Ill add you on MSN to talk about multi servers.

Exactly what I think :O
Many project started.. JAVA, VB , VB.NET and C++.
If all of these peoples could work on one verious language, We could use the best server files ever ;D
Don't?

[[HDx]Adolf]

20 threads for receiving, and 1 thread for each map should be the solution o_O

1 thread per map sound like the solution and moreover why not implementing ThreadMessages, It's will require a wrapper for Thread class I belive but It's imo the best solution so far. I mean when a player move from a map to another, just send a msg to the corresponding thread, no deadlocks this way ;d, thats an implementation I will experience soon in my projects.

Anyways I do agree with mootie, having that much emulator projects and more over in differents programming language is not a good solution at all. Thats just a pure division of people and flyff emulation get a terrible slowdown because of that which is not normal.

[adidishen]

20 threads for receiving should do good handling lots of clients.
For crossthreading operations I use readerwriterlockslim.
Also, to move from a map to map, I have a maporganizer thread that moves players from one instance to another, after looping through all the players connected.

Also I agree with the too many emulators stuff. not saying that people should stop creating emulators, but it really does slow us as we kinda depend on each other, so if one doesn't progress, another can slow down, etc.

[Blackbox]

Exactly what I think :O
Many project started.. JAVA, VB , VB.NET and C++.
If all of these peoples could work on one verious language, We could use the best server files ever ;D
Don't?

Not everyone knows the same language to be able to work on 1 single emulator project.

[Registe]

Its possible im doing it whit OsaFlyff now :p i dont have two computer i have one the first is Non PK the other is pk its diffrent rates and diffrents Npc :x:p

[Johnatan28]

hey the osaflyff emulator

what is the requeriments to full work?

because i have dual core 1.8ghz
1 gb ram DDR2

[BobbyMr]

guys ^^ we have totally went off topic on this
thread..an i think that is not..good?..supported?...