Welcome, guest! Please login or register.

    * Shoutbox

    RefreshHistory
    • stCky: Palidinho is your OpenGL (was it OpenGL?) stuff open source anywhere?
      August 16, 2017, 09:07:22 PM
    • Travas:BUILD THE WALL
      August 15, 2017, 09:28:49 PM
    • Travas: i have ass cancer
      August 15, 2017, 09:23:29 PM
    • stCky: what are the fudge are you tryna ask?
      August 15, 2017, 08:21:35 PM
    • bader: what are the rsps community alive ?
      August 15, 2017, 05:46:16 PM
    • bader: yo guys
      August 15, 2017, 05:46:08 PM
    • Spacehost:[link] Updated our thread :)
      August 15, 2017, 09:40:34 AM
    • Adaro: The client is in Download section at Homepage
      August 15, 2017, 01:09:20 AM
    • FaTe_Of_GoDs: where do i get the client?????????????
      August 14, 2017, 05:23:14 PM
    • stCky: can anyone help me? I cant login to the shoutbox
      August 13, 2017, 05:45:15 PM
    • drubrkletern: appeal denied
      August 13, 2017, 02:35:27 PM
    • King_Trout:[link]
      August 13, 2017, 11:17:12 AM
    • Cole1497: no sorry
      August 13, 2017, 10:27:14 AM
    • ayz: yo can anyone explain something to me
      August 13, 2017, 08:08:51 AM
    • coolking12: Hi
      August 13, 2017, 04:16:06 AM
    • stCky: n+1
      August 11, 2017, 06:09:24 PM
    • PalidinoDH: How many more pages are going to show errors before this dude gets on and fixes shit
      August 11, 2017, 04:57:00 PM
    • stCky: it is made by the wonderful people at jetbrains
      August 10, 2017, 10:00:06 PM
    • Zoravon: what's the difference between that and eclipse?
      August 10, 2017, 05:59:52 PM
    • stCky: use an IDE like IntelliJ or shitclipse
      August 10, 2017, 05:33:01 PM

    Author Topic: Apollo, one step forward and two steps back  (Read 8751 times)

    0 Members and 1 Guest are viewing this topic.

    Offlinesini

    • Member
    • ****
    • *
    • *
    • Posts: 5,785
    • Thanks: +0/-0
      • View Profile
    Apollo, one step forward and two steps back
    « on: August 08, 2015, 12:40:16 AM »
    Topics I didn't touch:

    - Ruby, pretty icky unless done right
    - The woes of over-designing
    - The woes of over-optimizing

    Want me to write about these? Just ask. This was getting pretty long I could have gone on much longer.

    Topics I find moot:

    - But the community doesn't understand Ruby so therefore that's why nobody used Apollo?

    I'd say this is true for newer users, and given the premise of my topic I'd argue that it was a bad move to use Ruby for plugins but there are a very limited amount of scripting languages that are suitable for things such as this. However though, I think people would adjust to the skill floor if they saw that it was worth it. It just wasn't worth it for people to do so. Even more advanced developers struggled with the design vision, myself included.



    Apollo, regarded as one of the greatest pieces of Runescape emulation software, was created by Graham Edgecombe in 2011 and insistently since it's release has been pushed onto the community as the source to use. Even if this is the case, given the current environment you are able to conclude that most public RS emulator sources do not use Apollo as their go-to platform to start a project. As popular opinion may voice, this seems to be a contradiction to what one may consider to be an attribute for one of the greatest pieces of Runescape emulation software to possess.


    I'm here today to present to you an opinionated piece from my own perspective backed by logical reasoning of why I regard Apollo as a failed project, that with restructuring, could find a niche into actually being a good piece of Runescape emulation software. Personally of which I DO NOT regard it as such.


    The premise of this argument I'm presenting takes into account that because Apollo is regarded as one of the greatest pieces of Runescape emulation software to use, and is commonly recommended to people for use must mean that it is a good piece of software for the public domain to use.


    Let's look at Apollo's, out of the box, strengths. The referenced repository can be found here. This repository is considered the official Apollo source by Major and Graham. What I would consider a strength is a well thought out solution to a parameter of design that has to be implemented in coordination with other solutions to fundamentally solve the main problem which of course is in this case emulating a Runescape server.

    - Strong and easy to understand design from a engineering perspective.
    - Excellent use of concurrency when encoding Player and NPC synchronization packets.
    - Well organized.


    Now, I will state that the extent to which you correctly emulate a Runescape server is the main determining factor for how successful a piece of software will be. Let's see what they consider the strengths of Apollo and compare with my evaluation, I refer to this since it is headlined under 'What Apollo does different' which could be reworded as 'What Apollo does better':

    - Packet encoding/decoding has been split from the representations of the packets themselves. This allows the potential for encoding/decoding to go on in parallel and also allows multiple revisions to be supported. Currently 317 and 377 are both completely supported.
    - Update server support (JAGGRAB, ondemand and HTTP).
    - Packet handler chaining: this allows multiple plugins to be able to intercept a single packet and deal with it appropriately. For example, a quest plugin could intercept searching a bookshelf for instance, if the behaviour needed to change in certain cases.
    - Parallel execution of player updating for multi-core machines.

    One out of the four given 'prominent core features' I would consider to be key or strong features. Why?

    1). Given the nature of the Runescape protocol with the delay between frames of time also known as ticks all data from messages received from clients have to be handled in an asynchronous manner to assure that no race conditions occur in the provided application because of how messages mutate models on a consistent basis. Asynchronously decoding and encoding messages isn't even responsible in the same context because even in this applied design a netty worker loop thread will asynchronously decode and encode messages when they are flushed to the socket channel. This is a pretty moot point, it's expected behavior and it's worded in a deceiving manner to make it seem like this is the responsibility of the emulation itself when rather the actual behavior is not in the manner it was described.


    Yes, the famed 'multirevision' holy grail. As a personal note I have always up until the past year considered this to be a strong selling point with a piece of emulation software. My opinion on this changed when my philosophies of design changed. Designing features that detract, or even add too much complexity, to a problem that could be simply solved in a manner where the easiest efficient solution is implemented wastes time efficiency and leads to over designing. With the implemented design, I do not deny that it would be possibly for multiple revisions to be supported because the message layer is often revision to revision agnostic.

    A majority of the packets in a RuneTek 2 (200-400) client are found in a RuneTek 3, 4, and even 5 client. This is because Jagex had no reason to really change their server architecture. If it isn't broken, don't fix it. I don't think it's commonly understood that Jagex was very cost oriented, a lot of their protocols are VERY bandwidth efficient. So to change a protocol that has worked for them in an optimal manner would cost money for no prospective gain. That's just common business sense.


    However, lets take a peak at how the design for this is set up.

    The way that the Apollo multi-revision support is set up is by registering message decoders and encoders which are responsible for decoding a message in a specific manner. The reason for this is because in order to inhibit packet bots, such as Aryan, Jagex randomized packet opcodes and streams so that the data between the client and server would be difficult to decipher. This is fine, except for the fact that behind the madness of this implementation you have to consider that you will have to create a single abstraction to decode and encode a message. If each abstraction is confined to a single class then you are writing up to two-hundred and fifty-six classes just for this purpose and these classes will have to be modified for every revision.

    This causes a lot of boilerplate, boilerplate is seemingly repetitive code that shows up in various occurrences that seems like it could be confined into a smaller simpler manner. I would consider this to be one of Apollos major flaws, and frankly it's hard to engineer around this efficiently and I do owe this to the fault of Graham or the Apollo developers at all.

    Under modern circumstances, we know today that there is a common protocol between various client revisions where incoming packets under certain circumstances are transcribed to their actual packet id and have the streams normalized. This data is present in RuneTek 2 clients in the packet constants, between revisions the packet ids are consistent and structured in a manner that logically makes sense.

    Graham and his team could possibly not have known this at the time, but for future considerations especially in more serious development projects I'd consider the issue of packet decoding somewhat a priority to implement in an efficient manner as to help stifle cheating programs that may have the intention of harming your server. It's a very difficult engineering task, and even though we have this modern information it's hard to guess how these numbers are generated, by what method, and if this piece is reversible. I'm willing to wager it isn't.


    2). Under my definition of the extent of how well a server is emulated I argue that in order to properly emulate Runescape and be a proper piece of emulation software this isn't anything that is extraneous under any circumstance so is a moot point. Serving assets also recently has been found to be distributed across ALL Runescape nodes because the cache for Runescape holds server sided configurations used in their implementation. This should be taken into consideration but is fairly moot under the premise that it isn't required to properly emulate the Runescape game however it sheds light on a method to solve solutions that you will come across when trying to organize assets.


    3). This piece includes a critical flaw of design that is repeated across Apollo and bridges fundamentally into what I consider to be a major philosophical issue. I will touch up more on this below because I think it needs its own explanation and section.


    These are issues I'd consider behind the scenes which may not be obvious to people except for more conditioned developers. Now the diction of this is important. Behind the systems in Apollo, under the definition presented above there is a conflict of interest for a target audience where the software released seems to cater seemingly to no public domain. These systems are not well explained and not obvious to people who may want to use this source for a project although they are marketed to being the essential features that put Apollo apart from any other source.

    Well, what features are important to people? For this question I turn to what I observe to be great sources for public domain use. And personally I begrudgingly mean; PI, Matrix, and Delta. Honorable mention to Arios, I do feel as if their team deserves a great amount of credit for pushing the boundaries of what people have been able to emulate. These sources are popular and widely used across a popular spectrum of public Runescape servers is because they have either a strong way for people to construct content, or contain a lot of content. Now you may be turned off from the thought of me saying that a PI, Matrix, or Delta source have strong ways for people to implement content but they really do. Each have the tools to implement a wide array of functionality that best suites the server developer's interest, and some do it in a way that basic programmers can understand. Apollo does quite the opposite, but I think it's important to bring up history of Grahams developments, the internal client systems in place for this, and how this relates to game programming in general.

    Graham, and I state this as a fact, has never publicly released a properly engineered content system. The definition of proper is loose, and I state this as fact because beyond Hyperion, even under the condition of well thought out design, no single server has been extensively used under the definition of the premise I found this argument on. None of his releases, besides his early ones, are widely used under public domain. If the content system was properly engineered, then there would be a wider sample of people using Apollo or his other releases beyond Hyperion as a platform for their project. This isn't the case.

    The reasons for this are limited functionality. Tying in with the earlier topic of misdirected design, all releases beyond Hyperion that were originally written by Graham don't have a wide array of use. They have the limit basics, but not all of the basics. His Apollo release had core emulation features (player and npc updating, asset serving, walking, inventories, and banking) and that was it. Given that Apollo was recommended for public domain, and under the assertion that newer users may consist public domain it's impossible to expect for those users to implement the rest of the core functionality. And given the amount of recommendation, does it make sense to expect people to do this?

    You may notice a missing note about the scripting system.

    Well, lets transition into discussing why I consider the scripting system a moot system. This may be a sensitive subject with people and I have a lot of personal experience with developing systems such as this that I will incorporate with my analysis. This topic will also include, what I think to be, the worst critical design flaw of Apollo.

    Apollo uses JRuby plugins to implement various functionality, each plugin is responsible for a specific content feature such as banking, mining, or woodcutting. The main purpose of this system was to move people out of developing content in Java and give people the ability to import plugins from various authors to create a custom emulation platform. The exposed functions to the scripting environment were extensions of methods in Java used for registering handlers to message pipes, or changing various parameters.

    Aside - I'm laughing writing this because man, this was a flop.

    The amount of snippets that are Apollo plugins, with the included consideration of the lack of popularity, is <1%. Each plugin that was released to the public suffered from a lack of consistency because of the lack of tools given to developers to do simple tasks. This defeated the entire purpose of giving the people the ability to import plugins from various authors and was a large oversight from Graham in his vision.

    Dependencies for plugins were managed by the plugin loader, which helped give people the ability to write utility plugins or use common plugins to write in functionality for their plugin such as using the banking plugin during a quest line. The implementation of this idea was a disaster and another major oversight.

    Apollo's design, as stated in their opening introduction, has a built in chain of command for propagating messages and handling them in turn responsibly. In turn this is noted to be a feature that sets Apollo aside. The design pattern for this is a chain of handlers or form of pipe. Coupled with this was a passed context which is responsible for optionally stopping the propagation of a message down the pipe. A logical layer is responsible for registering handlers to the chain, or pipe, with the partial knowledge of knowing how the messages are processed. I say partial because there are multiple layers that are responsible for registering handlers to the chain, none of which are assumed to communicate with each other or understand what the current state of the chain may be since there was no way to query this information. It would have been extraneous to give this functionality, and counter intuitive to the simplistic nature of this implementation. There in this lays the critical design flaw.

    The design of content was implemented in such a way that people can add or remove plugins from the emulation platform. Plugin functionality is expected to be isolated by design, with of course dependent plugins being apart of inline functionality. Therefore, since plugins are expected to be isolated by design and in this design the nature of how messaging handling is implemented it's impossible for plugins to understand what responsibility of functionality they encompass. Certain plugins may consume messages before they are propagated to an awaiting message handler in another plugin by the nature of isolation. This leads to issues of functionality of design where with this system you put the developer in a black box where in order to fully understand the system they have to understand all of the implemented plugins. This goes against the vision of design, and therefore is illogical.

    As a programmer, I know since that point in time was four years ago, this is unacceptable. And expecting the public domain to develop under these conditions or even suggesting this was a valid solution is illogical.

    The lack of functionality, although enough to turn most of the public domain away from using Apollo, isn't entirely present in most sources. It wasn't until recently that people concluded that the player 'configs' were actually the players game state. Method confided this in multiple people at a much earlier date but it hasn't been even considered to be an Incorporated system in any source. Technically there is a very limited amount of data structures that describe the player save state; those being the skills, inventories, and variables. I use the word variable to define a key entry styled data structure which maps a unique integer, the id, to an integer value. This structure encompasses data for quests, object states, item states, and configurations. Variables are used with the player, npc, and even item model. We can confirm this from Runescript leaks. An synonym for this is meta data. Although the structure is very primitive.

    All of these structures can be appended to models in such a way where in an extensible manner you can append or remove them without changing fields by assigning them unique identifiers that are registered in the context of the game environment. This is critical for scalable development, however it wouldn't be minimally required for emulation development.

    Under the intention of giving developers the power to have a wide array of functionality with plugins however, in Apollo I'd consider this a critical priority. I however did not think Graham had much of a game development background where he could implement these features in a logical manner. It's possibly he didn't consider it important. However it doesn't make sense to implement this vision, the vision of easily deployable plugins, and not see through through with it.

    As a game programmer I think the perspective of priorities change especially when you have more insight to trying to implement systems that scale to fit the needs of what you may need to implement. If you limit yourself to certain nuances or do not give yourself enough options to where you can efficiently, in the terms of a raw coefficient of efficiency, then you are hindering your development and not being logical.

    Grahams Apollo, and essentially his other releases, were very limited and were just essentially in the very essence of the word: frameworks. You cannot compromise on advertising how certain design visions are better than how other designs are implemented, and then suggest that people should use the source or even call it anywhere close to be one of the greatest pieces of emulation software.

    tl;dr

    Guys, keep using PI, Delta, and Runesource. THINK like a game developer.
    « Last Edit: August 08, 2015, 12:58:23 AM by sini »


    OfflineCanownueasy

    • Member
    • **
    • Posts: 10
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #1 on: August 08, 2015, 12:54:11 AM »
    I agree. We all should have respect for the work that Graham put into Apollo but it might not be the absolute best thing out there. He did help us get to where we are by introducing a lot of the notions that we use to develop RSPS. Nice thread.


    Offlinesini

    • Member
    • ****
    • *
    • *
    • Posts: 5,785
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #2 on: August 08, 2015, 12:55:14 AM »
    I don't think more credit than exactly that is given.

    Offlinesini

    • Member
    • ****
    • *
    • *
    • Posts: 5,785
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #3 on: August 08, 2015, 02:01:13 AM »

    OfflineRuneAgent

    • wololo
    • Member
    • ****
    • *
    • *
    • Posts: 7,516
    • Thanks: +0/-0
      • View Profile
      • MITB FORUMS
    Re: Apollo, one step forward and two steps back
    « Reply #4 on: August 08, 2015, 05:27:32 AM »
    stop writing shit like this and work on the official server.

    Offlinedrubrkletern

    • Absolute Legend
    • Member
    • ****
    • Posts: 9,373
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #5 on: August 08, 2015, 05:33:39 AM »
    stop writing shit like this and work on the official server.
    rip
    Quote
    "Moparscape is the oldest Runescape private server community. We have been active since 2007.

    - Mitb, Founder"
    ez   infraction king

    Offlinedoom_j

    • i like the company of men
    • Member
    • ****
    • *
    • Posts: 7,202
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #6 on: August 08, 2015, 09:42:25 AM »
    stop writing shit like this and work on the official server.

    Looks like another year before we get into beta...
    [12:18:14 21:04:45]<<Tom>>i dont care about your rights
    [12:18:14 21:04:49] <<Tom>> you have NO RIGHTS

    OfflineWelliton_inc

    • Member
    • ****
    • Posts: 635
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #7 on: August 08, 2015, 01:01:16 PM »
    Only got up to the first paragraph then gave up.

    But thanks tom hanks! I will continue using Delta!
    Quote from: sk8rdude461
    It's not unique. You wanna know why there's no server out there like it?
    That Logic doe....

    Offlinelare69

    • Member
    • ****
    • *
    • Posts: 5,321
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #8 on: August 08, 2015, 03:01:31 PM »
    good read, but I mean if Apollo isn't the solution then what is? PI, Delta, and Runesource have all proven time and time again to be unreliable in production environments. they don't scale well enough
    hi. check out luna:)

    Offlinesini

    • Member
    • ****
    • *
    • *
    • Posts: 5,785
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #9 on: August 08, 2015, 03:11:14 PM »
    There really isn't a good solution. I don't think it's unreasonable to have the features I listed. PI, Delta, and maybe even some Runesource derivatives just do it better.  I don't begrudge people using any of these, it makes sense as to why they would. Maybe the modern generation could improve from this, but who knows.

    OfflineMajorr

    • Member
    • **
    • Posts: 20
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #10 on: August 08, 2015, 04:14:19 PM »
    Tl;dr Major banned me on rune-server and I'm a whiny c????unt


    Anyone who listens to someone as prejudiced and incompetent as you can use whatever they like - apollo is recommended by programmers far better than you, and for good reason.

    Offlinesini

    • Member
    • ****
    • *
    • *
    • Posts: 5,785
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #11 on: August 08, 2015, 04:19:51 PM »
    All of the listed reasons are valid, if you have an alternative option then you can post why or try and prove me wrong. I disagree entirely. You should really work harder on it :( Maybe you'll get it to a point where its used more frequently. But today? Well, obviously not today.

    Quote
    The design of content was implemented in such a way that people can add or remove plugins from the emulation platform. Plugin functionality is expected to be isolated by design, with of course dependent plugins being apart of inline functionality. Therefore, since plugins are expected to be isolated by design and in this design the nature of how messaging handling is implemented it's impossible for plugins to understand what responsibility of functionality they encompass. Certain plugins may consume messages before they are propagated to an awaiting message handler in another plugin by the nature of isolation. This leads to issues of functionality of design where with this system you put the developer in a black box where in order to fully understand the system they have to understand all of the implemented plugins. This goes against the vision of design, and therefore is illogical.
    « Last Edit: August 08, 2015, 04:23:59 PM by sini »

    Offlinejustaguy

    • Member
    • ****
    • *
    • Posts: 707
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #12 on: August 08, 2015, 04:21:36 PM »
    Tl;dr Major banned me on rune-server and I'm a whiny c????unt


    Anyone who listens to someone as prejudiced and incompetent as you can use whatever they like - apollo is recommended by programmers far better than you, and for good reason.

    Tbh you're the one who sounds mad. Refute his points if he's wrong instead of bitching?
    RIP

    Offlinecasey.

    • Member
    • ****
    • Posts: 8,757
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #13 on: August 08, 2015, 04:34:33 PM »
    Tl;dr Major banned me on rune-server and I'm a whiny c????unt


    Anyone who listens to someone as prejudiced and incompetent as you can use whatever they like - apollo is recommended by programmers far better than you, and for good reason.
    lol kid get off this site. im familar with ddos so if u dont want r--s to go down for good i would log out NOW and not come back
    Server Developer

    OfflineD3i7y

    • Member
    • ***
    • Posts: 174
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #14 on: August 08, 2015, 04:44:19 PM »
    From what i understand from previous things by graham have always been top notch. But even for moderate level programmers people are lazy and want to do things the easy way and that isn't usually the best way to do things. I haven't released anything major nor do i ever intend to learn how.  But its just my thoughts i have been working on a deltscape server for over 2 years and have not done anything but make different skills and separate classes to handle them.

    So take what you want from what i have wrote it's just what i think.
    once very lonely and broken two souls pulled together to fix our broken hearts. Erica&Allen :)

    OfflineMajorr

    • Member
    • **
    • Posts: 20
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #15 on: August 08, 2015, 05:28:34 PM »
    Tl;dr Major banned me on rune-server and I'm a whiny c????unt


    Anyone who listens to someone as prejudiced and incompetent as you can use whatever they like - apollo is recommended by programmers far better than you, and for good reason.

    Tbh you're the one who sounds mad. Refute his points if he's wrong instead of bitching?

    Sigh

    Alright I did actually read all of it because even though sinisoul is a complete idiot I would say the same thing you said if it wasn't sinisoul posting it. I wrote at least half of what's in the current apollo repo, and I won't deny that parts of apollo could definitely be improved (and incidentally graham said the exact same thing when he first posted it), but the OP is still full of bullshit

    Topics I didn't touch:

    - Ruby, pretty icky unless done right
    - The woes of over-designing
    - The woes of over-optimizing

    This is just trying to immediately cast apollo as poor without backing up what you're saying - provide evidence or don't mention it at all. I disagree with all of what you've said, and I can't refute the last two because I don't know what you're referring to (and the first one is both opinionated and stupid - every language is gross unless it's "done right").


    - But the community doesn't understand Ruby so therefore that's why nobody used Apollo?

    This is one of the reasons; it's also because there's little content (which is self-fulfilling - nobody uses it because there's no content, so nobody writes content for it, which means nobody uses it, ...), although with the release i pushed a couple of days ago this is less true; it's also because lots of the core was missing (again until a couple of days ago), and finally because the standard of code is considerably higher than the rest of the code that is public - the vast majority of active people are crap programmers, and are not in the target audience of apollo.

    Also, for the record, neither Graham nor I particular care if apollo is the Next Big Thing, or even widely used - it was written to be an improvement over the rest of the stuff that is available, which it is.

    Apollo, regarded as one of the greatest pieces of Runescape emulation software, was created by Graham Edgecombe in 2011 and insistently since it's release has been pushed onto the community as the source to use.

    Not pushed by either myself or Graham, fwiw - people who parade it as the greatest piece of software ever written are just as incorrect as you are.

    As popular opinion may voice, this seems to be a contradiction to what one may consider to be an attribute for one of the greatest pieces of Runescape emulation software to possess.

    Except it's only a contradiction if it's on equal footing to whatever else is available. Apollo is more difficult to set up (but not unreasonably so - you need to generate RSA keys and put the cache in the appropriate directory, and that's it), and also to write code for, which makes it less attractive to people who aren't reasonably competent at programming (almost everyone in the rsps community).

    The premise of this argument I'm presenting takes into account that because Apollo is regarded as one of the greatest pieces of Runescape emulation software to use, and is commonly recommended to people for use must mean that it is a good piece of software for the public domain to use.

    People who I often see recommending it have always acknowledged that it's difficult to use and that it's not suitable for people who don't want to learn. If this ever changes then I think it's a complete failure - I'm not interested in writing something for people who aren't interested in putting any effort into what they do with it. If you disagree then that's a fundamental difference between us and not one I think is relevant to this debate - apollo has a target audience, and that audience is not "everyone".

    What I would consider a strength is a well thought out solution to a parameter of design that has to be implemented in coordination with other solutions to fundamentally solve the main problem which of course is in this case emulating a Runescape server.

    This is literally just buzzwords with no actual substance behind it.

    - Strong and easy to understand design from a engineering perspective.

    Any competent programmer will be able to easily understand apollo. There's no dependency magic, OSGi, only about 10 lines of reflection (which is hidden from the user and easy to understand if people look at it). It's split into well-defined modules and packages, and the class hierarchy is clear and reasonable. Please point out actual code that you think does not fulfill this criteria.

    - Excellent use of concurrency when encoding Player and NPC synchronization packets.

    it does this

    - Well organized.

    See above

    Now, I will state that the extent to which you correctly emulate a Runescape server is the main determining factor for how successful a piece of software will be. Let's see what they consider the strengths of Apollo and compare with my evaluation, I refer to this since it is headlined under 'What Apollo does different' which could be reworded as 'What Apollo does better':

    I don't agree that you can reword that as "What apollo does better" - if it was supposed to say that, that's what I would have written. Please don't mislead people like that.

    Also fwiw I never bother updating that and there should really be more there (will link to stuff I think is cool at the end of this post), but obviously you wouldn't have known that so I accept that that in itself is not a flaw in what you are saying.

    - Packet encoding/decoding has been split from the representations of the packets themselves. This allows the potential for encoding/decoding to go on in parallel and also allows multiple revisions to be supported. Currently 317 and 377 are both completely supported.
    - Update server support (JAGGRAB, ondemand and HTTP).
    - Packet handler chaining: this allows multiple plugins to be able to intercept a single packet and deal with it appropriately. For example, a quest plugin could intercept searching a bookshelf for instance, if the behaviour needed to change in certain cases.
    - Parallel execution of player updating for multi-core machines.

    I think all of the things you have struck out are definitely doing stuff better; packet codec stuff could definitely be done better (I proposed a method to improve this using dynamic codec generation on r-s, which I'm pretty sure you've seen), but I never got round to it. I don't plan on doing much more with apollo, but if that changes then improving the packet codec stuff is definitly on the todo list.

    1). Given the nature of the Runescape protocol with the delay between frames of time also known as ticks all data from messages received from clients have to be handled in an asynchronous manner to assure that no race conditions occur in the provided application because of how messages mutate models on a consistent basis. Asynchronously decoding and encoding messages isn't even responsible in the same context because even in this applied design a netty worker loop thread will asynchronously decode and encode messages when they are flushed to the socket channel. This is a pretty moot point, it's expected behavior and it's worded in a deceiving manner to make it seem like this is the responsibility of the emulation itself when rather the actual behavior is not in the manner it was described.

    Several people like super_ have described ways of processing frames in parallel without race conditions (although I think this is too difficult to be worth it, and super_ thought the same when I last spoke to him). Note that it just says "potential" rather than saying that it is implemented, so the rest of what you've said can be ignored because it's not misleading at all.

    That's there because it allows multi-revision support anyway, the comment about potentially processing frames in parallel is just an secondary point.

    Yes, the famed 'multirevision' holy grail. As a personal note I have always up until the past year considered this to be a strong selling point with a piece of emulation software. My opinion on this changed when my philosophies of design changed. Designing features that detract, or even add too much complexity, to a problem that could be simply solved in a manner where the easiest efficient solution is implemented wastes time efficiency and leads to over designing.

    You think writing a completely new server is more efficient that just adding another release package? Even if you reuse an existing one you still have two servers for what is just opcode and data transformation changes.

    The way that the Apollo multi-revision support is set up is by registering message decoders and encoders which are responsible for decoding a message in a specific manner. The reason for this is because in order to inhibit packet bots, such as Aryan, Jagex randomized packet opcodes and streams so that the data between the client and server would be difficult to decipher. This is fine, except for the fact that behind the madness of this implementation you have to consider that you will have to create a single abstraction to decode and encode a message. If each abstraction is confined to a single class then you are writing up to two-hundred and fifty-six classes just for this purpose and these classes will have to be modified for every revision.

    Not every frame is used but yeah see above about how this could be improved. Note that this is true for anything: even if you merge the en/decoding with the message class you still have the same amount of code, it's just in the same class.

    I reached the max char limit and this shitty forum doesn't allow double posts so I can't post the rest of my reply until someone else posts here
    « Last Edit: August 08, 2015, 05:32:06 PM by Majorr »

    Offlinecube_

    • Member
    • **
    • Posts: 8
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #16 on: August 08, 2015, 05:34:46 PM »
    butchering scapeemu doesnt help much either

    OfflineMajorr

    • Member
    • **
    • Posts: 20
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #17 on: August 08, 2015, 05:35:25 PM »
    Under modern circumstances, we know today that there is a common protocol between various client revisions where incoming packets under certain circumstances are transcribed to their actual packet id and have the streams normalized. This data is present in RuneTek 2 clients in the packet constants, between revisions the packet ids are consistent and structured in a manner that logically makes sense.

    Runetek 3 but yeah you're just describing the improvement I posted about on r-s and have mentioned above repeatedly.

    Graham and his team could possibly not have known this at the time, but for future considerations especially in more serious development projects I'd consider the issue of packet decoding somewhat a priority to implement in an efficient manner as to help stifle cheating programs that may have the intention of harming your server.

    How is efficient frame decoding relevant to preventing cheating? Apollo verifies frames (which is quick and also eliminates cheating), so I have no idea what you're trying to say here.

    2). Under my definition of the extent of how well a server is emulated I argue that in order to properly emulate Runescape and be a proper piece of emulation software this isn't anything that is extraneous under any circumstance so is a moot point. Serving assets also recently has been found to be distributed across ALL Runescape nodes because the cache for Runescape holds server sided configurations used in their implementation. This should be taken into consideration but is fairly moot under the premise that it isn't required to properly emulate the Runescape game however it sheds light on a method to solve solutions that you will come across when trying to organize assets.

    Yeah except the phrase is "what apollo does different" and an update/jaggrab server is definitely different to all the other servers. It doesn't matter what your definition of server emulation is when you're actually trying to argue against the phrase "what apollo does different" (which you then misrepesented as "what apollo does better" - even with this misrepresented form, it's still true that this is better than the other servers).

    These are issues I'd consider behind the scenes which may not be obvious to people except for more conditioned developers. Now the diction of this is important. Behind the systems in Apollo, under the definition presented above there is a conflict of interest for a target audience where the software released seems to cater seemingly to no public domain. These systems are not well explained and not obvious to people who may want to use this source for a project although they are marketed to being the essential features that put Apollo apart from any other source.

    TL;DR apollo needs content tutorials. I agree.

    These sources are popular and widely used across a popular spectrum of public Runescape servers is because they have either a strong way for people to construct content, or contain a lot of content. Now you may be turned off from the thought of me saying that a PI, Matrix, or Delta source have strong ways for people to implement content but they really do. Each have the tools to implement a wide array of functionality that best suites the server developer's interest, and some do it in a way that basic programmers can understand. Apollo does quite the opposite, but I think it's important to bring up history of Grahams developments, the internal client systems in place for this, and how this relates to game programming in general.

    Yeah this is just trying to spin "PI, Matrix, Delta code is shit which means people who suck at programming can use it and copy and paste tutorials" as a good thing. It's not a good thing, it's terrible, and apollo isn't designed to make this possible. I don't care if you think that it should be possible to do with apollo - I'm not interested in rune-server (or this site) being plastered with shitty apollo code, and I doubt Graham is either.

    Graham, and I state this as a fact, has never publicly released a properly engineered content system.

    If by content system you mean "an API for writing content" then this isn't true; graham's original release of apollo has tasks, actions, and ruby bootstrap stuff for content (and it works well - I would know), and the current repo has more stuff to make this nicer. I think what you are actually complaining about is that none of graham's servers contain considerable amounts of content, which isn't surprising; content is a lot of effort, often repetitive, and there is a huge amount to recreate. Servers like delta have had 8 years of people writing (shitty) content for it which has all compounded.

    The reasons for this are limited functionality. Tying in with the earlier topic of misdirected design, all releases beyond Hyperion that were originally written by Graham don't have a wide array of use. They have the limit basics, but not all of the basics. His Apollo release had core emulation features (player and npc updating, asset serving, walking, inventories, and banking) and that was it. Given that Apollo was recommended for public domain, and under the assertion that newer users may consist public domain it's impossible to expect for those users to implement the rest of the core functionality. And given the amount of recommendation, does it make sense to expect people to do this?

    I've mentioned above how people typically say "only use apollo if ur willing to put the effort in blah blah" so I don't think there's anything else to respond here, but your incorrect use of the term "public domain" is getting annoying - public domain refers to an uncopyrighted work (either because the author has discarded all of their rights or because its expired). You just want to say "widely recommended to the public".

    Aside - I'm laughing writing this because man, this was a flop.

    Aside - like the fudgein moparscape server lol!

    The amount of snippets that are Apollo plugins, with the included consideration of the lack of popularity, is <1%. Each plugin that was released to the public suffered from a lack of consistency because of the lack of tools given to developers to do simple tasks. This defeated the entire purpose of giving the people the ability to import plugins from various authors and was a large oversight from Graham in his vision.

    No it wasn't; you don't write subpar systems to get people to use them, you write good systems and encourage competent people to use them. Your methodology is one of the reasons why almost all rsps code is total shit.

    Dependencies for plugins were managed by the plugin loader, which helped give people the ability to write utility plugins or use common plugins to write in functionality for their plugin such as using the banking plugin during a quest line. The implementation of this idea was a disaster and another major oversight.

    You didn't actually say why the plugin loader is apparently crap, and given that it's like 30 lines of code i'm not really sure how you can describe it as such a disaster.

    The design of content was implemented in such a way that people can add or remove plugins from the emulation platform. Plugin functionality is expected to be isolated by design, with of course dependent plugins being apart of inline functionality. Therefore, since plugins are expected to be isolated by design and in this design the nature of how messaging handling is implemented it's impossible for plugins to understand what responsibility of functionality they encompass. Certain plugins may consume messages before they are propagated to an awaiting message handler in another plugin by the nature of isolation. This leads to issues of functionality of design where with this system you put the developer in a black box where in order to fully understand the system they have to understand all of the implemented plugins. This goes against the vision of design, and therefore is illogical.

    Yeah no; the point of breaking the plugin chain is because you are sure that other listeners should not receive the message. This is used for e.g. fletching when creating anything, cooking to cook food, blah blah. You've fundamentally misunderstood why this exists and so this is a paragraph of shit. If two listeners actually both need to respond to the same message, then a custom event can be fired by one listener, and the other listener(s) can listen to that custom event. Don't bother replying to this unless you can think of a reasonable use case where two listeners do actually need to hear the same message though.

    As a programmer, I know since that point in time was four years ago, this is unacceptable. And expecting the public domain to develop under these conditions or even suggesting this was a valid solution is illogical.

    Nothing of substance here, don't bother saying it

    Under the intention of giving developers the power to have a wide array of functionality with plugins however, in Apollo I'd consider this a critical priority. I however did not think Graham had much of a game development background where he could implement these features in a logical manner. It's possibly he didn't consider it important. However it doesn't make sense to implement this vision, the vision of easily deployable plugins, and not see through through with it.

    fudge off with your "graham didnt have a game development background" bullshit

    As a game programmer I think the perspective of priorities change especially when you have more insight to trying to implement systems that scale to fit the needs of what you may need to implement.

    Yes this is very well known - you will note that apollo was (and still is) described as incomplete when released, so this is irrelevant

    Grahams Apollo, and essentially his other releases, were very limited and were just essentially in the very essence of the word: frameworks. You cannot compromise on advertising how certain design visions are better than how other designs are implemented, and then suggest that people should use the source or even call it anywhere close to be one of the greatest pieces of emulation software.

    Apollo is incomplete. It's still better than every other 317 server - get over it.

    tl;dr

    Guys, keep using PI, Delta, and Runesource. THINK like a game developer.

    tl;dr the stupidity in that sentence is very representative of the rest of the post, nice job

    Offlinecube_

    • Member
    • **
    • Posts: 8
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #18 on: August 08, 2015, 05:40:30 PM »
    Tl;dr Major banned me on rune-server and I'm a whiny c????unt


    Anyone who listens to someone as prejudiced and incompetent as you can use whatever they like - apollo is recommended by programmers far better than you, and for good reason.
    lol kid get off this site. im familar with ddos so if u dont want r--s to go down for good i would log out NOW and not come back

    arent u a cool kid

    OfflinePure_

    • Member
    • ****
    • *
    • Posts: 4,687
    • Thanks: +0/-0
      • View Profile
    Re: Apollo, one step forward and two steps back
    « Reply #19 on: August 08, 2015, 05:50:34 PM »
    - But the community doesn't understand Ruby so therefore that's why nobody used Apollo?
    why are you using lua in your server then???????????????????
    /thread op is hypocritical
    i won the forum

     

    Copyright © 2017 MoparScape. All rights reserved.
    Powered by SMFPacks SEO Pro Mod |
    SimplePortal 2.3.5 © 2008-2012, SimplePortal