[Development] Open Neuz Project

[GlaphanKing]

Since spikensbror is doing an open source server files as a community development, I thought I would add my own community development as well. This should go hand in hand with the server files.

I encourage everyone to at least try and contribute something whether its only one line of code to an entire class.

We are going to rewrite the book on MMO development and this community will lead the way. From client to server you will be able to say I helped make it and we made it happen.

I encourage you to help Spikensbror on the server development as well because these two projects can solidify this section in RageZone. Plus it would really stick it to the people who think the server is dead.

I'm still working on an initial shell to be worked on. I have the camera, options, and a few other classes done but nothing too worth while to look at. Unless something goes down, I will have it up at google code and some other places. It will be released under the GNU license or whatever meaning everyone is to be credited and those credits will never change.

I would like to see this project eventually go cross platform into linux and even Mac, (lol), but at any rate it will utilize C# and XNA framework. XNA is the new managed directX wrapper so it makes sense to use it.

I don't care about reverse engineering at all because its so far down the list that someone else can mess with it.

The main things needed to be worked on are as follows:

1. Get models converted to a workable format.
2. Eliminate the need for so many animations.
3. Utilize a new Particle engine. (Mercury Particle Engine is one to think about)
4. Move the database off MsSQL and into MySQL.

open-source-neuz-client - Project Hosting on Google Code

This is the place holder for later tonight wher you can download your copy and start working on it.

A word of caution. As with Spikensbror's project if no one wants to help or decides they want to claim it for their own, I will close development on it and do it myself. I hate to do that but hey it happens all the time.


And don't think about flaming this thread because it will all be deleted and infractions given out, no exceptions.

This will be moved to the dev section once the initial upload to Google Code is done.

Development Forum: http://openneuz.smfforfree.com/index.php

Codeplex: OpenFlyClient

Here is the zip of the project : OpenNeuz.zip

Updates

Spoiler:

• As of 12/16/2010 8:44PM EST I have uploaded the first unbuilable source. It doesn't work yet as I'm still adding the windows as we speak.
• Login Screen, DialogWindow, Title Screen completed. -- Done
• Server Select, Character Select, and Face Change

[MentaL]

[langme2009]

Sounds like one hell of an endeavour! Once I actually learn more about C++/C# (as in, actually learn it), then I'll help out as much as I can. :]

[ryuchao009]

Now THIS looks fun and interesting. I thought Mono only used .net 2.0 and XNA required 3.5 o.o. Anyways, good luck and you've got my support!

Off topic: On the note about converting models to a workable format, what about just writing a new open format altogether? I've been meaning to try rewriting some of the formats myself but with school and all of its last-minute tests before Winter Break I haven't gotten to it.

[GlaphanKing]

Now THIS looks fun and interesting. I thought Mono only used .net 2.0 and XNA required 3.5 o.o. Anyways, good luck and you've got my support!

Off topic: On the note about converting models to a workable format, what about just writing a new open format altogether? I've been meaning to try rewriting some of the formats myself but with school and all of its last-minute tests before Winter Break I haven't gotten to it.

It's on the list to redo the format. The only problem is the content pipeline. I've seen around 2000 models on the screen at the same time. It ran about 13fps on the xbox. I want to utilize the .net 3.5 framework that can be used by a lot of lower end pcs. All you need is a gfx card with a pixel shader of 1.0 or better.

I'd like to write up a milestone list that way everyone knows where the client stands.

[GlaphanKing]

Sorry guys. I uploaded the wrong version. I meant to say its utilizing XNA 4 and the .NET 4.0 framework. Most people have the framework already so install XNA 4 if you are contributing.

4.0 has a lot of more stable features and upgrades that makes it easier to play around with 3D. Not to mention its using DX 11.

I'll upload the 4.0 into another branch in case other people want to work off the 3.5 version.

Again, I apologize.

[ReiDC0Re]

hey i wish you good luck in it just look at our source i make public yesterday there could be many things can help you

http://forum.ragezone.com/f457/flyff...elease-712779/

so good luck and keep it up cause this could be big project and thats often frustrating and the frustration is most often the reason why people stop developement...

[FrostElite]

Sounds good bro, I attempted working on a client far back but it was too complex for me to work on alone. I'll contribute to the best of my ability.

[GlaphanKing]

An early screen of the login client. Some things I should point out. The "glass" look isn't the final version. The system for the window controls has a skin maker that will be distributed so you can make your own skins. Very simple really and it uses 7zip algorithm to create the skin. just add it in to the content folder, set the build to none and copy to only if newer.

I'll include steps to create your own window soon so universally you can make your own unique windows and such.

Once I get all the windows done I will start adding in the socket system and a dummy file to test out some stuff.


And yes.... that is the background to InsanityFlyff. Cred to Hells for the pic.

[Pews]

Sounds nice :D

[Cambons]

K, some suggestions, make window freely sizeable from borders

[GlaphanKing]

Elaborate a little so I can better help your suggestion. You mean the actual game window or the windows like the login window?

[heathj]

will you be re-writing the model and map systems, by this i mean making the client use a more user firendly 3d format like OBJ or similar, not sure about the maps but have you got a map editor planned too if you choose to use a custom map format, as a map editor is basically a stripped down client with editing features

[GlaphanKing]

yea, once I get a solid import system for the models, it shouldn't be that tough to do a map editor.

The landscape files are just heightmap pieces with links around certain edges. Contained therein are the layers, tile ids, and any objects/sfx that fall with in the map piece.

I've been experimenting with a 3d map editor. all I need to do is add in the model support and its a go, but first thing is first.

[Blackbox]

Elaborate a little so I can better help your suggestion. You mean the actual game window or the windows like the login window?

I think some windows such as the inventory/skills window or something like that. I think the fixed game window size should stay. But some of the larger in game windows get kinda big when on lower resolutions.

[GlaphanKing]

Yea, I'm not hard coding the sizes that much. I'm using the size of the viewport to determine the scale of the windows. In the beginning I'm hard coding them just to get them established, then I'll scale them down according to the window.

Thanks for the suggestion though.

Oh, I also would like to ask something of the people. Would you like me to keep the original look and feel of the inventory window or make it look different? If you want it different, you can make a drawing or something. I've already had a suggestion of a diablo style inventory and a wow style inventory. Though I'm sure that most people would like to keep it simple and original. Your call.

[heathj]

Yea, I'm not hard coding the sizes that much. I'm using the size of the viewport to determine the scale of the windows. In the beginning I'm hard coding them just to get them established, then I'll scale them down according to the window.

Thanks for the suggestion though.

Oh, I also would like to ask something of the people. Would you like me to keep the original look and feel of the inventory window or make it look different? If you want it different, you can make a drawing or something. I've already had a suggestion of a diablo style inventory and a wow style inventory. Though I'm sure that most people would like to keep it simple and original. Your call.

i think the old v4 inventory would be cool (the one before the 3d representation of your character in the center i dont have a picture ill edit my post if i can find one)

[Sephern]

Since spikensbror is doing an open source server files as a community development, I thought I would add my own community development as well. This should go hand in hand with the server files.

I encourage everyone to at least try and contribute something whether its only one line of code to an entire class.

We are going to rewrite the book on MMO development and this community will lead the way. From client to server you will be able to say I helped make it and we made it happen.

I encourage you to help Spikensbror on the server development as well because these two projects can solidify this section in RageZone. Plus it would really stick it to the people who think the server is dead.

I'm still working on an initial shell to be worked on. I have the camera, options, and a few other classes done but nothing too worth while to look at. Unless something goes down, I will have it up at google code and some other places. It will be released under the GNU license or whatever meaning everyone is to be credited and those credits will never change.

I would like to see this project eventually go cross platform into linux and even Mac, (lol), but at any rate it will utilize C# and XNA framework. XNA is the new managed directX wrapper so it makes sense to use it.

I don't care about reverse engineering at all because its so far down the list that someone else can mess with it.

The main things needed to be worked on are as follows:

1. Get models converted to a workable format.
2. Eliminate the need for so many animations.
3. Utilize a new Particle engine. (Mercury Particle Engine is one to think about)
4. Move the database off MsSQL and into MySQL.

open-source-neuz-client - Project Hosting on Google Code

This is the place holder for later tonight wher you can download your copy and start working on it.

A word of caution. As with Spikensbror's project if no one wants to help or decides they want to claim it for their own, I will close development on it and do it myself. I hate to do that but hey it happens all the time.


And don't think about flaming this thread because it will all be deleted and infractions given out, no exceptions.

This will be moved to the dev section once the initial upload to Google Code is done.

As of 12/16/2010 8:44PM EST I have uploaded the first unbuilable source. It doesn't work yet as I'm still adding the windows as we speak.

Codeplex: OpenFlyClient

Here is the zip of the project : OpenNeuz.zip

First of all, a comment on your choice of language. You state that one of your goals is to make the client cross-platform. If this is the case, then why choose C#, or .net at all? Its a scary concept to be writing code which is intended to be 'cross-platform' when it can only run cleanly on one OS. This is also a consideration with the server project - Linux server certainly have the advantage of being more scalable due to cost, and also a bit more stable and such. Does C# really have any particular advantage against any other language? I understand why you might wish to choose managed code over unmanaged, due to development speed, the ease of learning managed languages over things like C++, and general convenience, but why not choose another language with similar features, and another graphics API which will enable you to be more cross-platform. For example, Java coupled with OpenGL.

Secondly, why would you consider changing the database engine for the client? Its my understanding that it's the server that handles database queries, and that the client merely communicates with it through the socket connections. Therefore, whether the database is mysql or mssql is within the scope of the server, not the client.

I don't see a point in emulating the client, and then making a server. Why don't you just make your own mmo, with your own packet structure, and all the other shit u want. From what you have stated, you are changing everything except the networking. I really don't see a purpose in doing this.

Another thing is that MySQL is for websites, not for mmo's. It crashes after a specified connection count, which can be easily achieved. It is unstable and "only good for non-commercial websites".

I also don't believe that you will get anybody to contribute in this excuse for a mmo section.

The reason the development is towards FlyFF is because this is a FlyFF development forum. People do this for entertainment, education and various other reasons. Open source projects, especially those in managed languages, can create a range of cleaner solutions which are easier for people to modify. I haven't personally bothered with FlyFF's source, but from what I here it uses outdating libraries, and is generally not in the best of conditions. Having a set of files using later technologies, having people updating/modifying them regularly, and the support of the development community can be very important. It's not like you can just ask Aeonsoft if you get stuck on something. If Glaphan wants to take the project, and modify it to add new features, etc then that's his prerogative.

Also, MySQL isn't just used for websites at all. There's also various advantages to using MySQL over MsSQL (and disadvantages too!) which make it more suited to this project, in terms of its cross-platform aim and the fact that its open source and free (om none-enterprise, which many servers won't need).

You make me laugh.

Yea? I Don't care. I'll do what I want, how I want, and if all you want to do is flame me, which you always do, then enjoy another ban.

Honestly, kids today. What have you ever contributed to this section? What skills you think you possess that says you are better than anyone around here?

Oh, and the reason there is over 100k lines of code is because about 25% is redundant, commented, or outdated.

Regardless of what he may have done in the past, he was merely expressing an opinion. He may have been critical of you, but it doesn't mean its not a valid point. Its completely fair to expect someone to do some work before announcing a project. It's great that you have the idea to do this, and the motivation to make the section better but you can't start a project without some code already. Why not code 5-10% of the client, before announcing the project when you can realistically have multiple people working on it? At the moment, if you got 50 people working on the project they'd all inevitably do the same thing to get the basic framework of the client working. It's a huge waste of manpower. Why not instead create said framework, then show the forums what you've done and get assistance, and point people in the direction of things which need to be done? How can you expect anyone else to contribute when they haven't seen a large contribution by yourself, anyway? (and yes, I know that you're probably constantly developing it, but it doesn't forgive the lack of an initial codebase).

Despite your history with Mootie, is it really necessary to infract him for raising a valid criticism/concern of your project? It wasn't even really flaming, since it's not like it was completely injust insulting.

Oh, I also would like to ask something of the people. Would you like me to keep the original look and feel of the inventory window or make it look different? If you want it different, you can make a drawing or something. I've already had a suggestion of a diablo style inventory and a wow style inventory. Though I'm sure that most people would like to keep it simple and original. Your call.

In my opinion everything should be kept the same, a 100% emulation of the current client in terms of visuals and performance. That way, it offers no significant change to gameplay experience, but if servers, or individuals, want to modify their clients to offer unique features, or a unique gameplay experience then they're welcome to do so. An inventory you think is amazing, others might hate - at least we all tolerate the FlyFF one as it is at the moment. People can change it if they find it necessary, and release their work.

[GlaphanKing]

First of all, a comment on your choice of language. You state that one of your goals is to make the client cross-platform. If this is the case, then why choose C#, or .net at all? Its a scary concept to be writing code which is intended to be 'cross-platform' when it can only run cleanly on one OS. This is also a consideration with the server project - Linux server certainly have the advantage of being more scalable due to cost, and also a bit more stable and such. Does C# really have any particular advantage against any other language? I understand why you might wish to choose managed code over unmanaged, due to development speed, the ease of learning managed languages over things like C++, and general convenience, but why not choose another language with similar features, and another graphics API which will enable you to be more cross-platform. For example, Java coupled with OpenGL.

This is an educational approach to creating a flyff client. C++ is not for the faint of heart. I've been programming in low levels for such a long time that I don't have the time to raise the learning curve to the younger audience. C# is the fastest growing programming language due to the coupling of XNA and XBOX 360. It is the new DirectX development as far as managed DirectX goes. People will look at the client and port it how they see fit. They've done that with the duke nukem and wolfenstein source codes as well as the doom sources. They're availble in almost any programming language nowadays. Java is inferior to C++ in the way of execution. OpenGL is on my list, trust me. But for now, I'm focusing on getting everyone on the same page as far as what it takes to code a client and connect it into a server. Not many people can use the source and NO ONE will help anyone that needs it except for a few people who actually care to see something being done with it.

Secondly, why would you consider changing the database engine for the client? Its my understanding that it's the server that handles database queries, and that the client merely communicates with it through the socket connections. Therefore, whether the database is mysql or mssql is within the scope of the server, not the client.

Again, the people know MySQL way more than MsSQL. Its not a bias approach, merely a learning approach. Most people look at the database files and scratch their head. At least with MySQL, they have an easier time running the database. And for the record, its very stable and can handle upwards of 10k connections (very true) or whatever the server can handle which is a lot nowadays. It doesn't matter which language the database is in because they both act the same. MsSQL stores in a proprietary format whereas ISAM (however you spell) is open source and can be tweaked how anyone sees fit.

The reason the development is towards FlyFF is because this is a FlyFF development forum. People do this for entertainment, education and various other reasons. Open source projects, especially those in managed languages, can create a range of cleaner solutions which are easier for people to modify. I haven't personally bothered with FlyFF's source, but from what I here it uses outdating libraries, and is generally not in the best of conditions. Having a set of files using later technologies, having people updating/modifying them regularly, and the support of the development community can be very important. It's not like you can just ask Aeonsoft if you get stuck on something. If Glaphan wants to take the project, and modify it to add new features, etc then that's his prerogative.

Also, MySQL isn't just used for websites at all. There's also various advantages to using MySQL over MsSQL (and disadvantages too!) which make it more suited to this project, in terms of its cross-platform aim and the fact that its open source and free (om none-enterprise, which many servers won't need).

Thanks for understanding what I've been trying to say.

Regardless of what he may have done in the past, he was merely expressing an opinion. He may have been critical of you, but it doesn't mean its not a valid point. Its completely fair to expect someone to do some work before announcing a project. It's great that you have the idea to do this, and the motivation to make the section better but you can't start a project without some code already. Why not code 5-10% of the client, before announcing the project when you can realistically have multiple people working on it? At the moment, if you got 50 people working on the project they'd all inevitably do the same thing to get the basic framework of the client working. It's a huge waste of manpower. Why not instead create said framework, then show the forums what you've done and get assistance, and point people in the direction of things which need to be done? How can you expect anyone else to contribute when they haven't seen a large contribution by yourself, anyway? (and yes, I know that you're probably constantly developing it, but it doesn't forgive the lack of an initial codebase).

Despite your history with Mootie, is it really necessary to infract him for raising a valid criticism/concern of your project? It wasn't even really flaming, since it's not like it was completely injust insulting.

The point is moot (pun? maybe.) His reputation makes him less likely to be taken seriously. I don't want to speak on it anymore because it has no place here. Whether or not he was criticising is beyond the point. His goal in life is to make me look bad at every turn.

In my opinion everything should be kept the same, a 100% emulation of the current client in terms of visuals and performance. That way, it offers no significant change to gameplay experience, but if servers, or individuals, want to modify their clients to offer unique features, or a unique gameplay experience then they're welcome to do so. An inventory you think is amazing, others might hate - at least we all tolerate the FlyFF one as it is at the moment. People can change it if they find it necessary, and release their work.

I will most likely keep it as natural as possible but I will be offering ways to change it.

Thanks for your detailed comments. They were both enlightening and professional.

[Cambons]

Like, drag and size from sides of window? I dunno how to explain

[GlaphanKing]

oh, i get you. You want to be able to resize the windows like in the official.

No problem. It really just a simple bool flag.

should be something like

window.Resizable = false;

You should set some limits to how far to resize them though. That way people don't get crazy looking windows all over the place.

[Sephern]

This is an educational approach to creating a flyff client. C++ is not for the faint of heart. I've been programming in low levels for such a long time that I don't have the time to raise the learning curve to the younger audience. C# is the fastest growing programming language due to the coupling of XNA and XBOX 360. It is the new DirectX development as far as managed DirectX goes. People will look at the client and port it how they see fit. They've done that with the duke nukem and wolfenstein source codes as well as the doom sources. They're availble in almost any programming language nowadays. Java is inferior to C++ in the way of execution. OpenGL is on my list, trust me. But for now, I'm focusing on getting everyone on the same page as far as what it takes to code a client and connect it into a server. Not many people can use the source and NO ONE will help anyone that needs it except for a few people who actually care to see something being done with it.

My point wasn't that it should be coded in C++. I understand completely the argument between managed and unmanaged, and why this project would be better handled in an easier language to C++. Therefore, the decision isn't really between C++ and any other given language because C++ could already be eliminated.
Java is probably not that inferior to C#. They both have advantages and disadvantages. However, for what you're looking at (good socket libraries, easy to learn, quick development cycle, good graphics libraries) they're pretty much even, with C# maybe getting a slight advantage due to DirectX. However, would the extra work with OpenGL be worth it for cross-compatibility? If you state one of your goals to be it working on Linux, then certainly. Then, you need to look at why you want it running on Linux and mac. Yeah, it'd be cool, but how many people would use that, and is it really worth the development time? Honestly, there's a lot more benefit in the server than in the client.

Again, the people know MySQL way more than MsSQL. Its not a bias approach, merely a learning approach. Most people look at the database files and scratch their head. At least with MySQL, they have an easier time running the database. And for the record, its very stable and can handle upwards of 10k connections (very true) or whatever the server can handle which is a lot nowadays. It doesn't matter which language the database is in because they both act the same. MsSQL stores in a proprietary format whereas ISAM (however you spell) is open source and can be tweaked how anyone sees fit.

Again, you missed my point a bit :p
I don't question MySQL is a better decision for this project, for several reasons. My question was, why are you even considering the database? This is a client development project, and my understanding is that the database is within the scope of the server. It doesn't matter to the client whether you're using mysql, mssql, postgre, db2 or any other engine, provided it gets all the right network communication from the server. Therefore, those comments would surely be more applicable in the server development thread, as opposed to the client which is a completely different application and project?

The point is moot (pun? maybe.) His reputation makes him less likely to be taken seriously. I don't want to speak on it anymore because it has no place here. Whether or not he was criticising is beyond the point. His goal in life is to make me look bad at every turn.

The point isn't moot at all. As his last post in this thread has illustrated, he is capable of assisting and making valid points in the thread, and things others might not have noticed. I highly doubt that his 'goal in life' is to make you look bad, and I certainly don't think its worth losing a member/contributor to the forum through such an assumption. You don't know what the future will bring, whether this project will benefit DemonFlyFF to the extent he'll assist development, etc. Regardless, you shouldn't be warning him just based on the assumption he's trying to make you look bad. I doubt you would have warned others for that post, and its unfair to consider his past in such matters. People do change, occasionally. Benefit of the doubt is a great quality to have.

I will most likely keep it as natural as possible but I will be offering ways to change it.

Thanks for your detailed comments. They were both enlightening and professional.

Easy methods of customisation is always good (for example, image editing to make skins and such), but I think if people want to change the functionality of the client, the onus should be on them to develop it. If you create a standard client, of higher performance and more modern technologies than the official one thats easy to modify, then you can always just make the changes you want after (in regards to the invent, etc) and release it as an improved client upon the old base, or a series of source changes. Similarly, when people want to modify the client to do specific things, they can do.

[Sephern]

Thank you, and I would like to see a full emulator of the client, but is it realistic or even possible? I doubt it. Also, we already have source code to the C++ client...which is very good and well documented code(even if dated). I don't think you understand the source, if you look closely, the actual code and practices are good. The reason they seem bad is because they rely on a clientsided antihack(so they may not be very secure).

Why not start a project to update/improve the performance and compatibility of the client instead of a C# emulator? I've noticed the threading practices in the source are pretty dated compared to more recent games(Runes of Magic, Iris Online, etc). This leads to the biggest flaw in the client's source, which Deadly discovered. The client doesn't use mutexes or any other form of multi-threaded resource access limiting. Why do you think the client crashes when people teleport to darkon or other crowded areas? One thread accesses a non-threadsafe object which is being accessed by another thread. This causes a race condition, which results in a crash. If you could fix this issue(would take a lot of code, but less than 1/10th of the code an emulator would take), that would certainly be a big achievement and very useful fix.

Editing the official C++ source seems much more useful and realistic than creating a new C# emulator with less efficient/stable libraries and engines.

I still haven't even looked at the source, it's not a matter of not understanding it ;)
By outdated coding, I meant the DirectX libraries and such used, not the practices, par se. Libraries date much quicker than practices.

The reason that an emulation in a different language would be beneficial is for several reasons. To start with, C++ is hardly the easiest language to learn. Especially if you're just getting your feet wet with programming. Taking away the considerations of garbage collection, etc not only dramatically increases development speed (meaning new features can be added comparatively very quickly), but also increases the amount of developers who can work on it well. Its much easier to be a good C# programmer than C++, and if you're a bad programmer you're much less likely to fuck something major up in a managed language.

Besides, it's all intended as a learning exercise. Even if it doesn't get used more than the official client, a lot will still have been learned by the developers of the project, which is all that will probably matter to them. People are never always going to work on the same project because different things interest them, and alternatives are good. If the project was completed, an Open Source C# client would definitely be advantageous. Especially if it solves the underlying issues like Race Conditions. Personally, I'd like to see a server implemented in a completely none-blocking language that uses limited threads, like node.js.

[divinepunition]

Hi Glaphan, i'd like to help you, i don't have a lot of time since i have a new job, but i will download the actual source and try to see what i can do. Have you any private forum for speaking about the development ?

About XNA, tell me if i'm wrong but for what i have understood, it need to load all models into memory and can't load them just when you need it no ? (it's certainly a misunderstanding)

[Sephern]

Hi Glaphan, i'd like to help you, i don't have a lot of time since i have a new job, but i will download the actual source and try to see what i can do. Have you any private forum for speaking about the development ?

About XNA, tell me if i'm wrong but for what i have understood, it need to load all models into memory and can't load them just when you need it no ? (it's certainly a misunderstanding)

The ContentManager class handles content loading/unloading, and you can do it 'on-the-fly' or so to speak. However, the downside of this is that you can't unload an individual asset from within the ContentManager, since it holds all references to its created assets, and disposes of them when the ContentManager itself is unloaded. This means that you can't dispose of assets manually, because it'll try to dispose of it twice, and cause an exception.

The way forward is probably to have several ContentManagers with all of them containing models/objects that have a similar timeframe, and dispose of them all at once by just unloading the ContentManager.

[divinepunition]

thanks for those infos ;)