Thread: RSPS extensibility & plugins

Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 39
  1. #11  
    Registered Member
    Tyluur's Avatar
    Join Date
    Jun 2010
    Age
    26
    Posts
    5,103
    Thanks given
    1,818
    Thanks received
    1,767
    Rep Power
    2438
    Quote Originally Posted by Graham View Post
    Revision-independent servers are also something I mostly think is a bad idea now. It only really worked in Apollo because 317 and 377 are so similar, and even then I think it was starting to cause problems with content. But trying to do 3xx and 5xx in the same server would be tricky. (I know people have done it, but I'm not convinced it is worth the trade-offs.)
    Perhaps maintaining the same infrastructure/architecture would be the best call.

    Quote Originally Posted by Bartvh View Post
    The fact that we don't already have something like this is because of multiple reasons:
    1. The developer manpower is spread over multiple revisions.
    2. The community is small, the amount of developers that can actually contribute and write a server is even smaller.
    3. This doesn't only happen in RSPS but people jus rather start new projects than contribute to existing ones (for whatever reason).
    Why don't we make the most of having fewer developers and work towards a common src? Or even a common network, database system, or something? It seems counterproductive to continue on this path of individual emulation of the same engine.
    Quote Originally Posted by blakeman8192 View Post
    Keep trying. Quitting is the only true failure.
    Spoiler for skrrrrr:

    Attached image
    Reply With Quote  
     

  2. #12  
    Extreme Donator

    JayArrowz's Avatar
    Join Date
    Sep 2008
    Posts
    104
    Thanks given
    99
    Thanks received
    107
    Rep Power
    810
    Quote Originally Posted by Tyluur View Post
    Perhaps maintaining the same infrastructure/architecture would be the best call.



    Why don't we make the most of having fewer developers and work towards a common src? Or even a common network, database system, or something? It seems counterproductive to continue on this path of individual emulation of the same engine.
    This is what i was thinking about too, generally servers these days are tied to a single revision implementation. If someone wanted to switch over to a diff revision the rsps servers created these days wouldn't have the capability to preserve revision agnostic code. Instead someone would re-write or switch to a different base
    Reply With Quote  
     

  3. #13  
    Programmer, Contributor, RM and Veteran




    Join Date
    Mar 2007
    Posts
    5,147
    Thanks given
    2,656
    Thanks received
    3,731
    Rep Power
    5000
    Quote Originally Posted by JayArrowz View Post
    I agree that combining the revisions all in one is not a good idea for a server (.e.g. allowing login to one server from a 508 client and 317 client & supporting both protocols at once), but what if the server was 1 revision and modules made up the protocol/content.

    .e.g.
    I could pick Apollo with 508 Login Protocol module, 508 Message Encoders & Decoders, 508 updating module, 508 fishing.

    Or

    I could pick Apollo with 317 Login protocol module, 317 Message Encoders & Decoders, 317 updating module, 317 fishing.

    Basically allowing the user to create a server using the modules limited on what revision the user selects. I think this may be a okay way to do stuff.
    I think the amount of code you could share would be fairly limited - the cache and update protocol work in completely different ways across 317 and 508, for example. I expect you'd either end up with lots of duplication, or, if you tried to share code, lots of special cases.

    I think it'd get even more complicated as people tried to add more revisions as well, given many changes were made gradually throughout the game's lifetime, and all the small differences will add up.
    .
    Reply With Quote  
     

  4. Thankful user:


  5. #14  
    Renown Programmer
    Greg's Avatar
    Join Date
    Jun 2010
    Posts
    1,179
    Thanks given
    260
    Thanks received
    1,012
    Rep Power
    2003
    Quote Originally Posted by JayArrowz View Post
    I agree that combining the revisions all in one is not a good idea for a server (.e.g. allowing login to one server from a 508 client and 317 client & supporting both protocols at once), but what if the server was 1 revision and modules made up the protocol/content.

    .e.g.
    I could pick Apollo with 508 Login Protocol module, 508 Message Encoders & Decoders, 508 updating module, 508 fishing.

    Or

    I could pick Apollo with 317 Login protocol module, 317 Message Encoders & Decoders, 317 updating module, 317 fishing.

    Basically allowing the user to create a server using the modules limited on what revision the user selects. I think this may be a okay way to do stuff.
    This is what i plan to do on NetScape with nuget packages. Have all the modules on Nuget and make them revision specific, essentially someone could build a 317, 667, OSRS server by just installing modules.
    Attached image




    I think this could be because people require coding knowledge to host a RSPS and extend/add content to it.
    You'd probably be best off using the highest rs2 revision possible and emulating the lower revisions with custom graphics settings and gameframes & interfaces.

    That way you don't have to change any protocols or implement multiple revisions, your just switching cache content.

    It's one of the worst points from the "players prefer 317" argument, if you take a 667 and slap all the graphics settings to low, it's indistingishable from a 317 loading 667 (except performance ).
    Attached imageAttached image
    Reply With Quote  
     

  6. Thankful user:


  7. #15  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Quote Originally Posted by Greg View Post
    You'd probably be best off using the highest rs2 revision possible and emulating the lower revisions with custom graphics settings and gameframes & interfaces.

    That way you don't have to change any protocols or implement multiple revisions, your just switching cache content.

    It's one of the worst points from the "players prefer 317" argument, if you take a 667 and slap all the graphics settings to low, it's indistingishable from a 317 loading 667 (except performance ).
    I'm doing the reverse lol, since the 317 client is a lot simpler and lacks some of the more annoying issues like xtea. I'm hoping to basically add a server side parameter which allows the user to toggle on and off later content like HD, so you can pick and choose which extensions to add.
    Reply With Quote  
     

  8. #16  
    Registered Member
    Tyluur's Avatar
    Join Date
    Jun 2010
    Age
    26
    Posts
    5,103
    Thanks given
    1,818
    Thanks received
    1,767
    Rep Power
    2438
    Quote Originally Posted by Greg View Post
    You'd probably be best off using the highest rs2 revision possible and emulating the lower revisions with custom graphics settings and gameframes & interfaces.

    That way you don't have to change any protocols or implement multiple revisions, your just switching cache content.

    It's one of the worst points from the "players prefer 317" argument, if you take a 667 and slap all the graphics settings to low, it's indistingishable from a 317 loading 667 (except performance ).
    That's what some people who aren't in this community have been working on behind the scenes. The nalore project also has this same thought process (i thin).

    Quote Originally Posted by Fire Cape View Post
    I'm doing the reverse lol, since the 317 client is a lot simpler and lacks some of the more annoying issues like xtea. I'm hoping to basically add a server side parameter which allows the user to toggle on and off later content like HD, so you can pick and choose which extensions to add.
    I don't think that's the best route; there were lots of changes that happened after 317 that you'll have to emulate - whereas you can use a high revision client that already supports all of the additions you're going to make.
    The downside is that there's no well refactored high revision client, besides leanbow's 550, afaik.
    Quote Originally Posted by blakeman8192 View Post
    Keep trying. Quitting is the only true failure.
    Spoiler for skrrrrr:

    Attached image
    Reply With Quote  
     

  9. #17  
    Renown Programmer
    Greg's Avatar
    Join Date
    Jun 2010
    Posts
    1,179
    Thanks given
    260
    Thanks received
    1,012
    Rep Power
    2003
    Quote Originally Posted by Fire Cape View Post
    I'm doing the reverse lol, since the 317 client is a lot simpler and lacks some of the more annoying issues like xtea. I'm hoping to basically add a server side parameter which allows the user to toggle on and off later content like HD, so you can pick and choose which extensions to add.
    Yeah lots of 317's have done it in the past but it comes at a performance cost, unless you convert to open-gl and utilise gpu rendering, more expensive tasks like z-buffering and anti-aliasing (which are required for high rev content) you just can't do, the jaggrab isn't practical, remaking the interfaces is more time consuming, loading interfaces/sprites/definitions/particles all adds more overhead.
    The high revision (and similarly osrs) client has all those issues solved out of the box, but it's eaiser to spend years rebuilding all those solutions from scratch than spend a few weeks to learn xteas, gpi & cs2, I know because I did it too! Once you understand high revision clients "317 client is a lot simpler" is funny because it's just not true, you'll always hear excuses like "high revision client's aren't as refactored, understood or documented" when actually it's just they don't understand that there's no need to write hardcode in the client as nearly everything is a cache edit.
    Attached imageAttached image
    Reply With Quote  
     

  10. Thankful users:


  11. #18  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Quote Originally Posted by Greg View Post
    Yeah lots of 317's have done it in the past but it comes at a performance cost, unless you convert to open-gl and utilise gpu rendering, more expensive tasks like z-buffering and anti-aliasing (which are required for high rev content) you just can't do, the jaggrab isn't practical, remaking the interfaces is more time consuming, loading interfaces/sprites/definitions/particles all adds more overhead.
    The high revision (and similarly osrs) client has all those issues solved out of the box, but it's eaiser to spend years rebuilding all those solutions from scratch than spend a few weeks to learn xteas, gpi & cs2, I know because I did it too! Once you understand high revision clients "317 client is a lot simpler" is funny because it's just not true, you'll always hear excuses like "high revision client's aren't as refactored, understood or documented" when actually it's just they don't understand that there's no need to write hardcode in the client as nearly everything is a cache edit.
    I don't see the performance issue with modern hardware tbh.

    Jaggrab can be deprecated or replaced (and do we even need it? the update server made sense when download speeds were dial up and these days you can bundle the cache easily enough with an msi).

    Afaik around 500 rev use JOGL which was last updated in 2015, i'm looking at a possible conversion of the old codebase to jfx (not sure how good OpenGL support is yet though so will have to experiment).

    I'll rip any genuine improvements.
    Reply With Quote  
     

  12. #19  
    Programmer, Contributor, RM and Veteran




    Join Date
    Mar 2007
    Posts
    5,147
    Thanks given
    2,656
    Thanks received
    3,731
    Rep Power
    5000
    Quote Originally Posted by Fire Cape View Post
    Jaggrab can be deprecated or replaced (and do we even need it? the update server made sense when download speeds were dial up and these days you can bundle the cache easily enough with an msi).
    JAGGRAB was still used in newer revisions like 550 btw, though only by the loader.

    I think it would've been completely phased out when they moved the native libraries to the cache. I don't know which revision that was done in.

    It wasn't the only part of the old 3xx update mechanism though, the ondemand protocol was used too. (That was phased out much earlier than JAGGRAB, and replaced by js5.)

    For what it's worth, I think correctly implementing JAGGRAB/ondemand or js5 is still important for a modern RSPS, as you get incremental updates. Even with a relatively fast connection, incremental updates will still help - and bandwidth isn't free for the operator of an RSPS. Another aspect is mobile connections as well I guess, especially if you do a mobile client.

    Quote Originally Posted by Fire Cape View Post
    Afaik around 500 rev use JOGL which was last updated in 2015, i'm looking at a possible conversion of the old codebase to jfx (not sure how good OpenGL support is yet though so will have to experiment).
    The OpenGL bindings changed quite significantly through 5xx. Early 5xx clients did use JOGL. By 550, Jagex had written their own bindings (jaggl) which the client used through a JOGL shim. Eventually, they switched the client to using jaggl directly. And unrelated to OpenGL, but at some point they added DirectX and the native software renderer too (in addition to the Java software renderer).
    .
    Reply With Quote  
     

  13. #20  
    Extreme Donator

    JayArrowz's Avatar
    Join Date
    Sep 2008
    Posts
    104
    Thanks given
    99
    Thanks received
    107
    Rep Power
    810
    Quote Originally Posted by Fire Cape View Post
    I don't see the performance issue with modern hardware tbh.

    Jaggrab can be deprecated or replaced (and do we even need it? the update server made sense when download speeds were dial up and these days you can bundle the cache easily enough with an msi).

    Afaik around 500 rev use JOGL which was last updated in 2015, i'm looking at a possible conversion of the old codebase to jfx (not sure how good OpenGL support is yet though so will have to experiment).

    I'll rip any genuine improvements.
    When you start trying to render depth, fog etc on the 317 client you can see quite a big performance hit unless you have a powerful single core. This is the main reason why i didn't want to stay on the 317 rev with new data. Instead switching revisions allows you to use a more updated client with better rendering capabilities.
    Reply With Quote  
     

  14. Thankful user:


Page 2 of 4 FirstFirst 1234 LastLast

Thread Information
Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


User Tag List

Similar Threads

  1. RS Scripts | Wordpress Plugins for RSPS
    By TommoLadd in forum Website Development
    Replies: 6
    Last Post: 01-06-2021, 05:21 AM
  2. RSPS Market - Websites - Forum themes - Plugins
    By apachenick in forum Selling
    Replies: 14
    Last Post: 03-14-2019, 06:03 PM
  3. Replies: 12
    Last Post: 08-14-2016, 04:45 AM
  4. Replies: 46
    Last Post: 08-08-2014, 02:49 AM
  5. Replies: 0
    Last Post: 03-23-2014, 01:09 PM
Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •