RuneScape 2 Development > Server and Client Development Showoff

RSPS Library

<<< (2/6) >>>

wildskiller:
Alright, so certain things have been revised.

So, explaining the Module System:

Modules are jarred projects loaded by the ModuleLoader class. They are to separate certain features from the core project so we do not implement classes that will be unwanted or changed in the future. They are not meant for specific creation of certain things. Modules are literally just class files loaded into the VM from a jar and are not Scripts.

For example, if I implement a combat system inside of the core project, I will most likely write around the core project's files, which I don't want. If I separate the system to a Module, then it will not effect the core and I can disconnect it from the module loader if I wish to remove or change the combat system to something entirely new.

This is aside from a script or content system, but can definitely help with it.
Also, it has nothing to do with the Event System (@lare69). I had just noticed you were referring to that. Basically, we can program on multiple different projects using the core project as a referenced library, package all of those separate projects into multiple jars, and load them into the server if need be. If we had a collection of modules that are meant purely for a pk server and we wanted a pure pk server, then we would package all of the pk modules inside of the modules folder, remove all of the previous modules, and wallah! We have a pk server, but we still have our previous economy server modules waiting if we want to use them later.

I have removed the Action system and I will write a synchronized system. I have re-written the Tickable system only slightly and it's not on the 600ms timing because I don't necessarily believe we have to emulate that part.

lare69:

--- Quote from: wildskiller on March 20, 2016, 07:44:48 PM ---Alright, so certain things have been revised.

So, explaining the Module System:

Modules are jarred projects loaded by the ModuleLoader class. They are to separate certain features from the core project so we do not implement classes that will be unwanted or changed in the future. They are not meant for specific creation of certain things. Modules are literally just class files loaded into the VM from a jar and are not Scripts.

For example, if I implement a combat system inside of the core project, I will most likely write around the core project's files, which I don't want. If I separate the system to a Module, then it will not effect the core and I can disconnect it from the module loader if I wish to remove or change the combat system to something entirely new.

This is aside from a script or content system, but can definitely help with it.
Also, it has nothing to do with the Event System (@lare69). I had just noticed you were referring to that. Basically, we can program on multiple different projects using the core project as a referenced library, package all of those separate projects into multiple jars, and load them into the server if need be. If we had a collection of modules that are meant purely for a pk server and we wanted a pure pk server, then we would package all of the pk modules inside of the modules folder, remove all of the previous modules, and wallah! We have a pk server, but we still have our previous economy server modules waiting if we want to use them later.

--- End quote ---
that makes a lot more sense. i was under the impression otherwise because of the documentation (in it, you refer to the modules as plugins) so you should probably rewrite it to make it a bit easier to understand

wildskiller:

--- Quote from: lare69 on March 23, 2016, 03:51:18 PM ---
--- Quote from: wildskiller on March 20, 2016, 07:44:48 PM ---Alright, so certain things have been revised.

So, explaining the Module System:

Modules are jarred projects loaded by the ModuleLoader class. They are to separate certain features from the core project so we do not implement classes that will be unwanted or changed in the future. They are not meant for specific creation of certain things. Modules are literally just class files loaded into the VM from a jar and are not Scripts.

For example, if I implement a combat system inside of the core project, I will most likely write around the core project's files, which I don't want. If I separate the system to a Module, then it will not effect the core and I can disconnect it from the module loader if I wish to remove or change the combat system to something entirely new.

This is aside from a script or content system, but can definitely help with it.
Also, it has nothing to do with the Event System (@lare69). I had just noticed you were referring to that. Basically, we can program on multiple different projects using the core project as a referenced library, package all of those separate projects into multiple jars, and load them into the server if need be. If we had a collection of modules that are meant purely for a pk server and we wanted a pure pk server, then we would package all of the pk modules inside of the modules folder, remove all of the previous modules, and wallah! We have a pk server, but we still have our previous economy server modules waiting if we want to use them later.

--- End quote ---
that makes a lot more sense. i was under the impression otherwise because of the documentation (in it, you refer to the modules as plugins) so you should probably rewrite it to make it a bit easier to understand

--- End quote ---
Every once in a while I'm going to scan through the source and document every undocumented piece of code. I'm really glad you took the time to give me opinion over things by the way :)

LordDerik:
Wow! Really amazing. But, as I'm a newbie on RSPS development, sorry for this questions.

Can we use this like a API?
Can we full compile into a single .jar and use it on my IDE?
Once running, this representates a server that a client uses to work?
Looking for your library we able to start creating scripts of a skill, for example?
For the scripts tests can we use any compatible* client? *If yes, what's the version expected to this code?

Currently I'm getting some knowledge about these concepts. Thank for support in advance! :)

Cres:
Some parts are too verbose for what they are/do.

I had a similar idea a while back but realized there were 2 problems

1) people won't use it because..

2) the microsystems of an rsps are usually based on one another. developpers cant swap one part of their code out without it undermining all the rest of the system.
this means they have to pick between your content framework or their own. I have yet to see people use an external lib for an rsps other than for networking and parsing data to/from files

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version
Powered by SMFPacks SEO Pro Mod |