Conquer PServer API (concept)

Ok so I was chatting with dev lastnight and I came up with a little idea... The more I think about it, the more useful I find it and I feel like it could really be an interesting tool to have for conquer development... The reason I'm doubting it is... well...

#1: Conquer dev is dead (everyone essentially is downloading/running a generic source or writing their own from scratch)
#2: Because of this divide, there is virtually zero public development that is feasible

But anyways... here's the concept.


A basic server API which could be plugged into your server. It would still allow your server to function exactly as normal unless you add in plugins. The API could be expanded through plugins as much as you want but in its base version it would simply act as a bridge between your server functions and various plugins.

You would now write plugins which the API would support. These plugins would have a few restrictions which would either allow or dissallow them to work with how you have your API set up. You could code multiple patch versions into the API as well so that it will work with a range of patches by switching based on the API settings.


You could then distribute or purchase these plugins to add fully tested functionality to your server.

The API would handle routing packets from your game server as well as the send functions and limited (customizable) player and map information. Any un-handled packets are routed back to your own handler (therefor by having no plugins currently running, your normal packet management takes over. The api ONLY re-routes packets used by plugins currently enabled.


This means you can EASILY switch between a number of systems including things like NPC systems.

Want to use iron python based npcs? Simply select that plugin and you're good to go.

Want to use TQ binary npcs? Simply load that plugin and full TQ bin npc support is added!


Obviously there would be plenty of issues with such a system but it's sorta intriguing me so I may work on a very small scale prototype sometime later this week.


QUESTION: Would you guys find something like this useful? The reason I thought it would be cool is that it still allows you to write your own custom source, organize it any way you damn well please... but if you want to transfer features between sources, you can simply add the plugin .dll and you're good to go. If the API expanded significantly, it could use a registration type system to handle purchasing and securing of various plugins to allow developers to earn some cash working on larger scale plugins (think: full poker system).

this is just perfect !
but will get load of errors and will need a shit load of work
but in general i like the idea :)

This sounds like a very good idea. I would definitely write some plug-ins for it.

Lots of money in that.XD

On a serious note, you've got my msn if you need any help.

It would also make it 100x easier to implement interserver systems, could make an entire app store just with plugins in .

i already considered this along time ago, the biggest issue is people who are running servers these days generally dont have a clue about programming, therefore plugin development would be difficult, 99% of servers are binaries as you well know, they just write a few sql statements and think they are gods,those who do know programming would probably have the knowledge to build there own server. your general concept is excellent, but i personally dont think it will ever take off.

Quote:

Originally Posted by Ultimation i already considered this along time ago, the biggest issue is people who are running servers these days generally dont have a clue about programming, therefore plugin development would be difficult, 99% of servers are binaries as you well know, they just write a few sql statements and think they are gods,those who do know programming would probably have the knowledge to build there own server. your general concept is excellent, but i personally dont think it will ever take off.

i agree to everything u said , but i think the coders are the one who should create rules over here , which means if this system is done and some servers bought stuff like source upgreat and full poker or w/e plugins by time people will go to this servers and other servers will be forced to buy plugins too and even if it took them to leave there sources and start it all over again with a source which is compatible with this system , the one who code and work should be the one who put the rules

none will ever release anything for free anymore , and by time the cheap servers out there will just die and coders who works on plugins will gain money , and idiots who host without knowing how to debug wont gain easy money anymore , i think it's fair

Quote:

Originally Posted by pro4never Ok so I was chatting with dev lastnight and I came up with a little idea... The more I think about it, the more useful I find it and I feel like it could really be an interesting tool to have for conquer development... The reason I'm doubting it is... well... #1: Conquer dev is dead (everyone essentially is downloading/running a generic source or writing their own from scratch) #2: Because of this divide, there is virtually zero public development that is feasible But anyways... here's the concept. A basic server API which could be plugged into your server. It would still allow your server to function exactly as normal unless you add in plugins. The API could be expanded through plugins as much as you want but in its base version it would simply act as a bridge between your server functions and various plugins. You would now write plugins which the API would support. These plugins would have a few restrictions which would either allow or dissallow them to work with how you have your API set up. You could code multiple patch versions into the API as well so that it will work with a range of patches by switching based on the API settings. You could then distribute or purchase these plugins to add fully tested functionality to your server. The API would handle routing packets from your game server as well as the send functions and limited (customizable) player and map information. Any un-handled packets are routed back to your own handler (therefor by having no plugins currently running, your normal packet management takes over. The api ONLY re-routes packets used by plugins currently enabled. This means you can EASILY switch between a number of systems including things like NPC systems. Want to use iron python based npcs? Simply select that plugin and you're good to go. Want to use TQ binary npcs? Simply load that plugin and full TQ bin npc support is added! Obviously there would be plenty of issues with such a system but it's sorta intriguing me so I may work on a very small scale prototype sometime later this week. QUESTION: Would you guys find something like this useful? The reason I thought it would be cool is that it still allows you to write your own custom source, organize it any way you damn well please... but if you want to transfer features between sources, you can simply add the plugin .dll and you're good to go. If the API expanded significantly, it could use a registration type system to handle purchasing and securing of various plugins to allow developers to earn some cash working on larger scale plugins (think: full poker system).

Yeeeahh.... Here comes one of those Infamous speeches. Haven't done one of these in a while.

Your proposal is quite nice and an excellent schema at face value (NOT STOLEN FROM CONQUERAI AT ALL, just kidding), however there are a couple problems with it.

It's restricted by version due to the packet changes (I mean there are work arounds here, such as you could use compiler-symbols to target specific versions in the built modules which could then allow dynamic packet building as required).

Anyhow, that's not the biggest problem, the biggest problem is something like this is going to have to be developed open source, and it's a fairly huge big project. So unless one persons going to carry a lot of dead-weight on their back, I don't see it going very far.

The problem with the conquer private server community is...

1. It's cut throat
-> You want your server to be the best. Albeit, you don't share your own workings with people until you've abandoned your project or have decided that you can produce something better, so even if you were to release it publicly it wouldn't cause a significant threat in the server and come to bite you back in the ass. This isn't nessecarily a bad thing (though it usually is), it may force an individual to over come hurdles to become the best.
You have to realize that Conquer server development was never about creating an open-source server for the entire community to use. It was about creating your own server that was the very best.

2. There's a lot of talk, but nothing done.
-> I mean yeah, people are like I want to learn how to code! but they don't really have the initiative to do it. Coding isn't something you decide one to do and you're miraculously good at it. It takes time and understanding, it's something you have to enjoy doing or without proper incentive you'll lack motivation. I mean, the one person who I've seen over come this hurdle is Mr. Pop. Like, holy shit, that guy has worked his ass off.

You have nobody to help develop this kind of idea. At very most, you'll have a handful of people who will slow down the project.

I don't mean to be Mr. Negative but while this is a good idea, I can't see it coming to life.

Quote:

Originally Posted by InfamousNoone I don't mean to be Mr. Negative but while this is a good idea, I can't see it coming to life.

I completely agree and that's why I wanted to get a little input and think it over some.

I've never done anything related to API's before so it would be an interesting learning project to see how well I could get a SUPER BASIC version of it up and running.

As for Conquer AI, that's exactly how I thought of it and described it to dev "think conquer AI plugins built for pservers instead of hacks" :P.

We'll see if I bother doing much with it. If nothing else it would provide me some extra knowledge of how to work on these things (aka what all my coding projects have been about).

The main issue I see is how to interface between the API, plugins and user data...

The way I envision it right now, the server would only expose information which the plugins needed access to. This becomes problematic though because you don't want the plugins responsible for saving all your character data (unless it's a database plugin to convert your server to sql or flatfile for example) but at the same time, lots of plugins need access to these variables and methods.

I might just simplify it and say that, in its default format, the API only has access to base character information (uid, x, y, map, send packet and sendtoscreen functionality) and leave any more advanced things down to the individual plugins.

I just see it getting messy if you have 5-10 plugins all running which are adding more and more character variables. To handle that, I'm thinking I'll have each plugin store its own variables and then leave it up to the user how they wish to handle this data.

Example again.. lets say I write an arena plugin. My arena plugin will contain a UserArenaStat object. The user can decide in their source how they want to handle this object for saving to database. The plugin would also have its own Save method which would only be active if the API currently had a loaded database system (of any kind).

I think basically taking things into plugins more so then the source itself allows things to become less convoluted as you expand and add more things. I'd have to actually sit down and write out some test modules though to really get a feel for how to organize things efficiently though.

Quote:

Originally Posted by _DreadNought_ Lots of money in that.XD On a serious note, you've got my msn if you need any help. It would also make it 100x easier to implement interserver systems, could make an entire app store just with plugins in .

I hadn't thought of the interserver concept but you're right, it could allow for full scale interserver contact including cross patch pvp. Simply have the plugin control what patch ranges are allowed to connect and some simple conversions between each supported patch's packets. Then some logic to handle how to overwrite missing content. For example, if someone is playing on current client with monk items, display them as wearing a dress on a 5017 client. Then allow a number of pvp options (vanilla skills only, fb/ss only, include ninjas and include monk). Very do-able in a modular way which could just be dropped into any server supporting the api.

It's not the first time a project like that is proposed. I really like the API idea and each time, I offer my help if needed... After all, my CO2_CORE_DLL was a kind of API offering networking, cryptography, safe random, and I was thinking to implement mathematics used in CO, but as nobody seems to be really interested :rolleyes:

But, as Hybrid said, we'll probably never see it. All his points are just the reality. I never saw a big open-source project, or just a little open-source project working in this section. The only way I see the project becoming reality, is if all «real» coders implement their parts of the API (as everyone is better for some things and really bad for others), but they would have something to get at the end.

Anyway, I like the idea. And you may search for a C/C++ API. That was worked a bit, but failed.


PS. The plugins need a common interface that allow for extension depending of the version. The information may be stored in a plugin used by all the others. All APIs require base that are common in all plugins. I would store the character information in the base API and allow for extension.

Quote:

Originally Posted by CptSky It's not the first time a project like that is proposed. I really like the API idea and each time, I offer my help if needed... After all, my CO2_CORE_DLL was a kind of API offering networking, cryptography, safe random, and I was thinking to implement mathematics used in CO, but as nobody seems to be really interested :rolleyes: But, as Hybrid said, we'll probably never see it. All his points are just the reality. I never saw a big open-source project, or just a little open-source project working in this section. The only way I see the project becoming reality, is if all «real» coders implement their parts of the API (as everyone is better for some things and really bad for others), but they would have something to get at the end. Anyway, I like the idea. And you may search for a C/C++ API. That was worked a bit, but failed. PS. The plugins need a common interface that allow for extension depending of the version. The information may be stored in a plugin used by all the others. All APIs require base that are common in all plugins. I would store the character information in the base API and allow for extension.

I personally thought your CO2_CORE project was pretty darn awesome (though I might not have ever voiced that publicly until now). It was a huge contribution to the community that was kind of just swept under the carpet.

The attitude "What's in it for me" has just become the norm' (and I'm not one to talk)... hence why I can't see much contribution. I for see that even if an API like this was developed not very much would become public besides the API itself (i.e. none of the plugins).

Its a nice idea, but i think even with this tool the community is going to be as closed as ever when it comes to releases..It would certainly make for a great platform though.

You could do version specific things such as packets, it just wouldnt be that elegant, unless you did it at compile time, which would most likely make it too complex....

only if this was started earlier :S, im pretty sure it would of gotten further than it will now tbh

This isnt the first time that a private server api of this scale was conceived, the previous one died of death with a lack of development and to be honest i suspect this one will go down the same route. The problem being that at the end of the day you'll get a handful of people willing to contribute and then hundreds wanting to just download the finished product. Theres no reward at the end as those handful of developers can already do everything that the api will deliver so theres no real drive to complete it.

I thought about making an IDE essential for Conquer, but right when I was gonna start I stopped as literally nobody would be interested in it.

The idea is good itself, but something like this would take much of effort/time. That's enough to take down this.