Jump to content

The server has been released!

Sign in to follow this  

Update log 06/06/2018 - Raids & other updates from the past two months!

Recommended Posts

Apologies for not posting any update logs for over two months. I took a break after the last update log; after the break I thought I'd finish up raids - figured there wasn't much left - and after that, post another update log. Finishing raids took longer than expected however, as I quickly lost motivation to continue it and took up a lot of other things. Well anyways.. Here are the updates by me from the past ~two months.



  • Updated our server-side data(definitions), reparsed from wikia.
    • Item definitions recompiled, includes all of the newer items.
    • NPC combat definitions recompiled, containing all the newer NPCs as well as fixes for many of the older ones.
  • Added requirements to wield items.
  • Changed special attacks around so the energy amount required is now pulled from within the cache, as opposed to being hardcoded and prune to being invalid upon changes by OSRS.
  • Item tradability is now being loaded from within the definitions in cache, as the variable "can be searched on grand exchange" - most items will match w/ the grand exchange search box; however if we wish to override that, we can easily do so by defining tradability through server-side definitions.
  • NPCs death delays are now calculated from the duration of their death emote, so they don't freeze up remaining invisible for too long, nor disappear too soon.
  • Tasks system has been changed to a functional interface, rather than an abstract class as it was before. This allows us to schedule tasks while having to write much less boiler-plate code.
  • Implemented a bunch of dismantleable items, such as armadyl godsword w/ the ornament kit etc. Wrote a generic system for them.
  • Re-spoofed all of the examines from OSRS - meaning they're exactly the same as in OSRS, not dumped from wikia which provides incorrect ones.
    • Item examines.
    • NPC examines.
    • Object examines.
  • Modified Zulrah's melee attack to strike from the correct side of the NPC, as opposed to always striking from one and the same side.
  • Removed all Math#random references, replaced them w/ server-side respective method to prevent recreating the Random object.
  • Modified object handler packet to handle the clicked object as the one that's displayed, not as the one that was requested by the server. The two can differ under the effects of varbits. Previously we only obtained the option that was clicked from the displayed object, now we also obtain the name, as our scripts system uses names.
  • Implemented model loading from within our source; fully renamed.
  • Rewrote wilderness ditch methods as a lot of the code was boilerplate and vulnerable.
  • Rewrote interface handler into a bi-directional map as opposed to previous regular map. We referenced methods such as isVisible(interfaceId) very often, and since containsValue() is o(n) within hashmaps, it was better to switch to bimap.
  • Converted the project to use gradle.
  • Implemented 2-factor authenticator; fully supported, including misc features such as "remember for 30 days" and whatever else.
  • Modified our regions to hold actual player/npc objects, as opposed to indexes of these entities. TL;DR: Less processing for the server. Additionally added support for lambdas-type looping for both NPCs and Players, as opposed to old version which contained a lot of boilerplate code.
  • Additional memory optimizations.
    • Changed a lot of existing collections to use FastUtils library, mainly to prevent autoboxing and unboxing.
    • Modified the location class to only contain position hash, as opposed to three integers(x, y, z). Location objects are constructed quite often and it consumed a fair bit of memory altogether.
    • Modified object class the same way as I did with location; as opposed to having 6 integers(3 from location) and a long, it now only contains 2 integers (1 from location hash).
    • Modified our definition classes to use arrays as opposed to concurrent maps; with that being said, definitions are all now being loaded on server launch; previously they were loaded from multiple threads on-demand.
    • Many other concurrent collections have now been switched out for the non-concurrent versions, as most of our game thread logic is single threaded, eliminating the need for concurrency protection.
  • Implemented the orb of oculus and all its functionality.
  • Began writing the inferno.
    • Defined all the spawn locations within inferno.
    • Wrote the instance system for inferno.
    • Wrote all the dialogues for inferno.
  • Wrote the shortcuts base, based off of the regular obstacles. Made adjustments to obstacles.
  • Implemented all the configurations behind achievement diary interfaces. The system itself is yet to be written however though.
  • Implemented the royal seed pod.
  • Implemented the ability to delay object clicks for a tick after reaching them; this is to prevent interacting with them from "afar"(technically, as far as server is concerned you'd be standing right next to the object, however since some animations block movement, you could be interacting with the objects from as far as two tiles away. This is no longer a thing though, and it is delayed just as in OSRS).
  • Implemented entity interactions as they are in OSRS - once you start interacting with a NPC, they will face you and keep facing you(unless someone else comes along) until you either finish talking to them(close dialogue) or if you leave their presence. This is capped at one minute though, to prevent people from being able to freeze NPCs to stand on one spot and pickpocket - or perform any other actions - indefinitely.
  • Added support for "check materials" in the construction skill guide interface - clicking on a constructable object will now inform the player what they need to build the object.
  • Access masks system rewritten.
    • Defined the remaining access masks.
    • Converted every single access mask packet reference to use access mask objects themselves, as opposed to magic bitpacked values. This allows me to better understand how a component behaves simply by looking at what information we transmit to the client; because of this change I've been able to implement many "new" features which I wasn't aware of before, as I didn't know what the magic value represented.
  • Implemented a bunch of basic dialogues for NPCs across lumbridge - Thanks to our beta tester Phippzy for writing them for me.
  • Patched up NPC directions(and spawn directions). When a NPC is being added to your viewport now, it will face the same exact direction as it would for players who've had the NPC in their viewport for longer periods of time; meaning there's no desynchronization between these. Small QoL optimization most won't ever even notice.
  • Rewrote movement mask the way OSRS has intended. Previously we flagged the movement mask every single step the player took. This obviously isn't optimal, and meant we wouldn't ever need to use the other movement mask. I've changed this to function the way intended, thus greatly reducing bandwidth usage(not only does it not have to flag movement mask as often now, but because of that, it won't have to send any mask data at all because there's nothing that's 100% sent now as it was previously - meaning this one small change actually changed much more than that.
  • Patched up an issue with being able to spam click dialogues and occasionally glitch out and close them mid-way through by doing so.
  • Rewrote our container system.
    • The new container system is much more efficient and less prone to bugs as the old one.
    • Container will automatically get its maximum size from within the cache.
    • Contains a treeset of free slots, therefore meaning to locate the first empty slot available - which was referenced very often - we no longer have to loop over all of the items within the container.
    • Container system uses an Int2ObjectLinkedOpenHashMap as opposed to being backed by an array; The reason I chose a map is because of our character saving method - we use json, and saving an array of nulls(such as bank - 816 slots of nulls) would greatly - unnecessarily - impact character sizes. Additionally, since it's linked, looping over it will be very quick, although at a cost of memory which I've calculated out to be still worth it.
    • The container supports three different containment types - never stack, normal(stack if stackable) and always stack; all of these are already used in the game as well, despite seeming unnecessary. Properly supports item attributes as well - 'always stack' will not stack items with attributes, as that'd cause loss of information - this is never needed in the first place to begin with anyways.
    • Container updating is now much easier than before - we do not have to manually track the slots that were changed or anything like that; the container system will automatically flag the slots that have been changed, and at the end of that tick - if update is requested - it will update all of those slots(or the whole container if the amount of modified slots exceeds 75% of the entire container size, since that's approximately when it becomes less efficient to use partial update packet - because it has to first write the id of the slot to update.
    • The container system contains new methods for withdrawing and depositing from one container to another - all done internally. To move an item from inventory to bank would only require us to write one line of code, as the rest would automatically be handled by the methods themselves.
    • Added support for 'result' object in containers - every action, such as add, remove, deposit, withdraw etc will return a result object which contains information about the transaction - what was requested, the type of the transaction, how many succeeded etc. Additionally supports a lambdas expression for failure, to handle the remaining amount of items; so for instance we can simply do player.getInventory().addItem(new Item(11802)).onFailure(item -> World.spawnFloorItem(player, item));
  • Implemented Rune Date system, the same exact system RS uses for to keep track of daily events etc. Thanks to @Polar for sharing.
  • Wrote item on npc plugin system.
  • Added the click option string to interface plugins, so we can now identify a lot of components simply by checking the string; meaning it's less likely the interfaces will break when components shift.
  • Implemented a polygon system, as well as an area system.
    • Able to define any shape of area, even circular shapes w/ center cut out etc using the polygon system.
    • Very fast and efficient - to my surprise actually. I expected polygons to be quite slow due to the structure of them, but they're very efficient for their nature.
    • Due to the areas system, I no longer have to write controllers so often; the areas also support processing, which means I can implement area-effects, such as desert heat within the areas themselves, meaning less-scattered code.
    • Areas also support dynamic regions - therefore I'm able to duplicate the static area of - for instance corporeal beast - the entire lair into where the dynamic region of that area is.
  • Rewrote bank for the last time.
    • Uses my new container system.
    • Overall, a lot more efficient than the previous version of the bank.
    • Supports proper item switching once again; able to insert items(from one tab to another, from within tabs), able to rearrange items however you wish. And something I didn't know of before, nor did I have implemented - able to rearrange the tabs themselves; you can actually just drag a tab and reposition it as you wish.
    • Tab creation, collapsing etc fully functional.
    • Placeholders functioning perfectly.
    • Item incinerating functions exactly as in OSRS.
    • Bank fillers properly functional - these were out of date since OSRS modified the fillers some months ago - after I initially wrote bank. This was another reason for the long awaited bank rework.
    • Whatever else is in bank, is fully functional. I had numerous people test bank very thoroughly, some issues were found which have now been patched. No new issues have since then popped up.
  • Dialogues code will now check if the given dialogue interface is even open before continuing with it - this was potentially harmful for the server. Unsure how I missed this one, as I have prevented all of the other similar cases.
  • Changed hitpoints and prayer points to be read as normal skill levels, as opposed to unique variables. Unaware as to why we separated these in the first place - the way they are currently is actually much easier to process.
  • Rewrote all input dialogues. Previous code was very verbose and potentially vulnerable in places. Additionally implemented a lot of safety precautions for input dialogues - if any interface is closed while input dialogue is open, the input closes as well. Input also closes when dragging items etc, fairly safe from issues now.
  • Implemented the name-tag mask for players. I was previously unaware of the true reason behind this mask - I knew it was only used in games room before. However now I've found out that it's used to display icons next to players' names, for instance ironman icons, deadman mode keys # etc, admin rank etc.
  • Rewrote all our spells to pull information from within the cache.
    • The spell level and the runes required will be pulled from within the cache.
    • The spells are located based off of the name associated to each component(component id is what's sent from the client to the server when working with spells). Our spell scripts all have identical names to the spells in the cache, therefore it's very easy for us to format the name of the classes and pull them from a map.
    • The above point basically means we no longer have to worry about OSRS adding new spells and completely messing up all of the other spells(as spells always get shifted when they add new ones - esp. like surge spells, since it shifted 3 spellbooks once it was added - had to manually fix all of the component ids).
  • Slightly rewrote our music system. The previous formula I used for associating songs to the slot ids clicked was actually completely wrong to my surprise. I've patched that now and optimized the music system further since it allows me to do so now. Instead of saving a list of all of the music tracks that the player has unlocked, I now just save varp values - therefore just 20 ints, as opposed to potentially hundreds. The 'hint' option on tracks will also inform the player about where the track will be unlocked.
  • Tom & I changed our cache library to OpenRS; all cache definitions since then are now rewritten.
  • Rewrote price checker completely; also changed the container to use my new container system.
  • Split the login sequence into two chunks - things sent immediately on login, and things sent after the lobby has closed. This actually patched several graphical issues.
  • Defined numerous areas, regardless of whether they may actually be needed or not as of right now. Potentially going to write a custom system using these areas in the near future; additionally, the more areas we define, the less the server has to process upon player movement - weird how it works, isn't it?
  • Rewrote doors code from some autistic 317-like bullshit code we had before. Overall length of the code lowered from roughly 150 lines down to just ~10. Supports diagonal doors etc. Also associated open doors to closed ones, so doors will now actually change the right click option depending on their state.
  • Implemented global item spawns. As of right now, we have roughly 400 global items spawns. Special thanks to all of our beta testers who participated in collecting these spawns for us!
  • Slightly rewrote barrows to function on-top of an area system, as opposed to controller system which was quite vulnerable, especially when dealing with administrators. Barrows system will now initiate regardless of how you enter the area, unlike before where it only functioned if the player entered it the correct way - from the very top.
  • Rewrote our combat system, as it has long been needing a completely cleanup due to messy and unoptimized code.
    • Ranged
      • Separated all of the unique combat methods for ranged in their respective classes, to prevent cluttering the main class.
      • Fixed problems with ammunition dropping; old methods were quite unstable and messy.
      • Added a ton of missing special bows/weapons.
    • Magic
      • Separated fire spells, built-in staff spells and god spells from the generic spells code, to prevent cluttering the main class.
      • Code in general is now much more efficient than it was before - magic was the most unoptimized class out of all.
      • Patched an issue with player running instead of walking when only needing to move 1 tile closer to the target.
    • Melee
      • Separated barrows sets, granite maul and dinh's bulwark from the main class, since they all required some special code, it was cluttering the main class.
    • Player will no longer always run to the south-eastern corner of the NPC when trying to attack a NPC while being under them. The location to which the player moves is now calculated, and the player will move to the location which is the closest to them, from which they may resume combat.
    • In general, all of the combat classes are much more efficient and easier to understand now.
    • In NPC combat, I also fixed the same issue as explained above regarding being under the target. Large NPCs will no longer walk back and forth when trying to attack you, while you stand under them. They will find the closest possible exit and walk there, after which they resume combat. This issue in general has been on every server I've seen so far, therefore I'm quite happy that I've got it patched. It was also the last issue I knew of we had in our combat. If you go into populated areas such as godwars, you'll notice no walking back and forth or anything similar, NPCs fight eachother properly, exactly as they should.
  • Since some of our block animations with certain items were quite glitched, I've now written an anti-system for it. If the animation that's about to be played off as block animation by the player doesn't match the player's skeleton, the animation played will be replaced with the default unarmed block animation. This prevents characters glitching up, as they did so quite often with unique weaponry.
  • Rewrote projectiles for the last time.
    • I've finally figured out exactly how the projectiles work, therefore I've been able to patch a fairly big issue all servers - including Zenyte - have. Projectile delay until impact. This issue consisted of two parts; With the help of client, I've managed to figure out the exact formula behind calculating projectile duration. We're now using that formula - old one was off by quite a lot; wasn't as visible with normal-distance projectiles though.
    • The second part of the impact delays was tick lag. Since projectile duration is defined in client cycles(frames), which are 20 milliseconds each, it was very possible for us to send projectiles with for instance 3.5 ticks duration. This would mean that - since the game engine itself runs on a tick-based system - there would be either a delay in the hit(before it lands), or it landed too soon - by half a tick. It was quite a small issue in general, but it bugged the hell out of me, as I was so close to perfect projectiles. Therefore I looked into the packet and figured out how to readjust the projectile so it finishes in synchronization with the tick system, as well as our getTime() method which returns the duration of the projectile in ticks. I've never seen this smooth projectiles on a RSPS before.
    • Besides the changes above, I also looked into the offset variable and figured that one out as well. Turns out my previous methods - made to calculate the start position of the projectile based on the direction and size of the entity were completely unnecessary. After properly implementing the offset variable, the projectiles system will now automatically calculate the offset position of the projectile, without having to actually go through complex calculations or manually defining it, although the latter is still an option for those special projectiles.
  • Since we do not have all ladders currently defined, I wrote an anti-method that prevents the player from being able to use an undefined ladder - which would've otherwise taken them to either an unwalkable location, or walkable "second level" of for instance dungeons - which shouldn't be accessible, which also would've allowed them to walk anywhere they wanted.
  • Rewrote all of our tick variables to use a queue, instead of manually defining all of the variables. The new queue system is much easier to use, and requires the game to actually do less processing than before, as the queue would only process the variables that have a value, as opposed to processing all of them as before.

Chambers of Xeric
Since I'm practically done with the chambers of Xeric, I've decided to make a conclusive update log on these. I wanted to do it after I finished the entire thing 100%, however I've lost motivation to work on it again and I'd rather not push the post off for some more weeks. Going to explain here everything that our raids contain, in depth. I'll mark features unfinished as red or yellow, depending on their state. The rest of the features will be kept green, as they're complete.

  • Map generation
    • Uses the same patterns for boss formation as OSRS.
    • Uses the same layout for rooms as OSRS, including the exceptions provided here.
    • Challenge mode contains every single room provided in raids, in the same exact formations as OSRS; additionally, challenge mode consists of 3 floors of 8, as opposed to 2 floors of 7/8 as in normal raids.
    • With the exception of challenge mode which contains fixed-format maps to keep everything fair(since it has a scoreboard), the flow of the map is completely random and generated by our algorithms. The map can flow in any of the four directions from the start - usually on other servers the map only flows x++ -> or y++ ->, not vice versa. 
    • 100% success rate for calculating maps. Tested this by generating thousands of random maps, with fail-safes all across the code. Initially it occasionally collided or glitched up, however that has since then been fixed and is no longer a possibility. Additionally, if by any miracle something were to go wrong in map generation, the given map would just be discarded and a new one would be generated in place of that map, until a successful map is created.
    • The empty chunks all across the floors are wrapped with what I call 'wrapper chunks', which prevent players from being able to see the bottom floors, which would otherwise be possible.
  • Skills
    • Farming
      • Rake-able patches can be raked for up to 5 seeds per "raking session" - to prevent AFKing. These patches never deplete, and give random seed out of the three possible options.
      • Soil patches are public farming patches in which everyone can patch to -and harvest from at the same time.
      • Takes 30 seconds for each stage; all patches have four stages. Therefore it only takes two minutes for the plants to fully grow.
      • Miscellaneous activities - such as clearing the patch, inspecting it etc have properly also been implemented.
    • Fishing
      • Players will automatically catch the best fish they can catch with their fishing level. 
      • Occasionally, a sea snake will pop out of the fishing spot, striking the player for some damage. The reason for this is because the fishing spots are objects - they never deplete.
      • Requires cave worms - which can be found by killing scavengers - to catch the fish.
    • Herblore
      • Players will be able to brew the strongest type potions for their level. All potions are available.
      • All three herbs can be cleaned.
      • The potions will carry attributes regarding the creator of the potion. This is used in the point system, to grant extra points for the brewer of the potion, if the person drinking their potions is someone else, other than the brewer themself.
    • Woodcutting
      • Players can chop saplings found within raids for kindling, which can then be lit to make a fire.

  • Storage units
    • Shared storage unit
      • Can be accessed only within raids itself. All players can access shared storage, adds items into it, take from it - completely public. The sizes of storages are 250, 500 & 1000 - depending on which unit was built.
      • Players get a warning message upon opening the shared storage for the very first time, informing them about its functionality.
      • Players can only deposit roughly 140 items into the shared storage, most of which are just items found within raids, but there are also some exceptions such as tools.
    • Private storage unit
      • Can be accessed inside and outside of raids, however items cannot be deposited inside the storage while outside of raids, only withdrawn.
      • This type of storage is per-player only. No one else within the raid can access this type of storage.
      • Players can deposit any items, including the ones found within raids.
      • Items found within raids, if deposited in the storage will be removed from it when leaving the raid.
      • If the player leaves the raid without picking their rewards at the end of the raid, the items will be deposited within the private storage if it has any space in it, or sent to bank otherwise - if both containers are full, the items are lost.

  • Books
    • All of the books can be read and contain the same information as in OSRS.
    • A total of 7 books from raids have been implemented - which as of right now, is all of them.
  • Rooms
    • Crab puzzle room
      • Contains four crabs, four crystals and one light focus.
      • Objective is to let the light focus bounce against the crabs, after which the light focus turns into that specific colour; the second part of the objective is to get the light focus to move towards the respective crystal. After all four crystals have been transformed w/ the respective colour focus, the puzzle is considered complete.
      • Players standing in the way of the focus will be hit for quite a lot of damage. The focus is constantly moving; explodes if it hits a wall; turns to another direction if it hits a crab.
      • Players can freeze the crabs by using the "Smash" option on them, which requires the player to have a hammer(warhammers function as well). The crab will remain on that specific spot for up to 20 seconds.
      • After all four crystals have been solved, the crystal blocking the exit to the next room will be shattered, allowing players to move foward.
    • Creature keeper(AKA corrupted scavenger) room
      • Contains a large number of thievable chests, along with a hungry corrupted scavenger, blocking the exit.
      • Objective is to feed the scavenger, so it will move out of the way and fall asleep, allowing the players to pass.
      • All of the chests will have the same thieving level to thieve from them; the level is determined based off of the party, therefore not everyone can participate in this room.
      • Players have to feed the scavenger consistently. If the scavenger has been fed some grubs, and the food trough becomes empty - the scavenger will over time become hungry again, slowly resetting the progress.
      • While thieving, the players can get hit by snakes rarely popping out of the chests. Additionally, the players may come across some edible bats, to heal themselves.
    • Dark altar(AKA mystic mages) room
      • Contains a random number of skeletal mystics; amount of them depends on the size of the party.
      • Objective is to kill all of the mystic mages, after which the mark of power - blocking the exit - is dispelled.
    • Deathly(AKA agility) room
      • Contains two rangers and two magers.
      • Objective is to retrieve the keystone crystal which is found at the other end of the tightrope, which is being guarded by the magers and rangers.
      • By default, the archers and magers are non-aggressive. However if anyone attempts to walk across the tightrope, they will all bombard that specific person, hitting very hard and accurately.
      • The crystal is used to dispel a magical barrier blocking the exit to the next room.
    • Guardians room
      • Contains two guardians - crafted from ancient rocks - who block the exit to the next room.
      • Objective is to kill these guardians - however to do so, players will need to smash them with pickaxes, as any other weapon renders useless against them.
      • Attempting to pass through to the next room will result in the guardians pushing the said player backwards, dealing them some damage.
    • Ice demon room
      • Contains an ice demon, and up to four icefiends.
      • Objective is to defreeze the ice demon - as it's blocking the exit - and kill it afterwards, since you still can't exist after it defreezes due to an ongoing ice-storm infront of the exit.
      • Players have to light kindling in the braziers found infront of the demon; keeping them lit for long enough results in the ice demon defreezing. If the braziers all extinguish before the demon becomes unfrozen, the demon will start freezing up again.
      • The demon attacks players according to what they're praying
    • Scavenger rooms
      • Two different scavenger rooms - large beasts, and small runts; large ones drop 3 drops at a time, small ones 2.
      • Scavengers respawn almost immediately, drop a large variety of supplies needed for the chambers. This room is optional, only used to get supplies.
    • Lizardman shaman room
      • Contains a fixed number of lizardman shamans, depending on the size of the party.
      • Objective is to defeat the lizardmen, after which the spawns blocking the exit will explode.
      • Lizardmen have their full combat script - including jumping, purple spawns etc, all functional just as should be.
    • Muttadile room
      • Contains two muttadiles - a small and a large one(large is by default under water), and a meat tree.
      • Objective is to defeat both of the muttadiles, after which the crystal blocking the exit vanishes.
      • Muttadiles will occasionally try to go to the meat tree to eat some meat, healing them in the process. This can be prevented by freezing the muttadiles, or creating a barricade of players infront of the meat tree - NPCs cannot walk on tiles occupied by players, therefore blocking the muttadile from being able to eat.
      • The large muttadile comes out of the water after the small one dies. Before that, the large one will send fire waves to all players within the room.
      • Both muttadiles are extremely powerful close-up, therefore it's suggested to avoid making melee-contact with them, as it can result in being 1-hit even in small teams. The muttadiles will occasionally move towards their target, so players have to beware and move out of the way every now and again.
    • Tekton room
      • Contains just one NPC - Tekton.
      • Objective is to defeat tekton, after which the crystal blocking the exit vanishes.
      • Tekton will be using his massive anvil throughout the fight.
      • When players first approach tekton, he will be smithing at his anvil. Once the players enter the required proximity, Tekton will retreat from the anvil, pick a target and fight against them.
      • Once tekton takes in his fight stance, he will slowly start fighting the players. Players can avoid tekton's attacks by running away from infront of them.
      • If there are no players in melee proximity of tekton when he lands a hit, tekton will retreat back to the anvil.
      • While smithing at the anvil, sparks will fly from across the room towards tekton, dealing massive damage if hit.
      • Tekton will enter enraged form after retreating from the anvil, which means his stats will be higher during that brief time, and it will be harder to hit him.
    • Vanguard room
      • Contains three vanguards - of each combat style.
      • Objective is to defeat all vanguards, after which the crystal blocking the exit vanishes.
      • Vanguards will move in synchronization across the room every 20 seconds, shifting their positions.
      • Players must keep all vanguards' health at approximately same levels, since if the vanguards health difference is more than 33%(of full health), vanguards will reset their health when they shift positions the next time.
    • Vasa Nistirio room
      • Contains the boss itself - Vasa Nistirio, and four crystals(which appear as objects).
      • Objective is to defeat Vasa Nistirio, after which the two small crystals blocking the exit vanish.
      • Vasa will move from one crystal to another, charging an attack at the crystals after reaching them. If the crystal isn't defeated before Vasa finishes charging the attack, the whole team will be punished when Vasa moves to the center of the room, as all players are teleported, and half of them will be hit for high damage.
    • Vespula room
      • Contains Vespula, four lux grubs and a portal at the center of the room.
      • Objective is to defeat the portal at the center of the room, after which the boils blocking the exit vanish.
      • Players must feed the lux grubs to prevent them from transforming into vespine soldiers - after which both the portal and vespula heal to full as well.
      • The portal can only be attacked properly for brief periods after vespula stops flying - which occurs when vespula's health drops down to 20% - after the period ends, vespula will heal back to full, as Vespula cannot be defeated before the portal.
      • Attacking the portal while vespula is flying will result in Vespula entering enrage mode, during which all players within melee distance of Vespula will receive heavy damage.
    • Great olm room
      • Contains the great olm.
      • Objective is to defeat the olm, however to do so, players will first have to go through many phases of it and take care of its hands.
      • Olm will face the players whenever they change position, during this position-changing time, it skips an attack.
      • Olm's left hand will display different signs before an attack occurs, showing what type the next attack will be.
      • During the first phases, olm's head cannot be damaged as he re-heals every few ticks. Instead, the phase is considered finishes after both its arms die.
      • During the final phase, both hands must be defeated within a 30-second window, otherwise olm will regain control of his hands and heal back to full.
      • After the death of Great Olm, the crystal blocking the exit vanishes, and rewards are generated for the players still in the raid.
      • Olm has 14 different unique attack styles.
        • Acid drip attack: Olm smothers one randomly picked player in acid; after being done so, the player will be covered in acid and will drip of acid - the tiles the player stands - or moves - on will be filled with acid. Standing ontop of which, the player will be dealt constant poison damage. The dripping effect lasts for 12.5 seconds, the pools remain on the ground for 30 seconds.
        • Acid spray attack: Similar to the drip attack, however instead of targeting one player, Olm shoots a bunch of poison-pools at random tiles in the room. These pools will remain on the ground for 30 seconds, just like the ones above, and act exactly the same way.
        • Crystal bomb attack: Olm shoots two - or three, depending on size - crystal bombs on the ground. These bombs will deal heavy damage if they hit any of the players. They explode after 5-6 seconds of being planted.
        • Crystal burst attack: Olm shoots small crystals under all players in the chambers. After a short period of time, these crystals will burst into large crystals, damaging anyone standing ontop of these crystals.
        • Deep burn attack: Olm will pick a random target in theh room, and attack that player with a burning attack. The said player will then be dealt constant damage over five cycles. If any players are found standing next to the infected player while they get burnt, the cycles will reset, starting from 0 again, and the other player will also be infected. This will carry on until the attack has successfully finished 5 cycles without infecting anyone else during this time.
        • Specific falling crystal attack: Olm will pick a random target out of the players in the room, and start dropping crystals ontop of the targeted player. The said player will then have to move out of the way of the crystal, or otherwise get hit for a fair bit of damage, as well as frozen on spot, after which they're guaranteed to get a few more consecutive hits.
        • Fire wall attack: Olm picks a random player in the room, and shoots from lines of fire around that player. The players caught in the fire will then have to escape the attack by extinguishing a fire - creating a small escape window - or otherwise be damaged for a lot. Players can extinguish any of the fires by shooting a water spell at it.
        • Life siphon attack: Olm sends two projectiles at random tiles in the room. These projectiles will create blue pools on the ground for a brief period of time. Any players not standing on the tiles will be hit when it disappears, and the Olm will be healed by however much the players were hit for.
        • Lightning attack: Olm sends lightning spirals across the room; any players caught in them will be electrocuted for some damage, and frozen on-spot. Their overhead prayers will also be disabled.
        • Sphere attack: This attack has three elements - melee, magic and ranged. Olm will shoot a random orb at random players in the room, which slowly fly towards the said players. On impact, if the player isn't protecting against the given type, they will be hit for heavy damage.
        • Swap attack: Olm pairs up up to four players in the room; after awhile, if the paired players aren't both standing on the same tile, their positions will be swapped, and they will receive damage, depending on their distance.
        • Falling crystals during phase transition: Olm will cause the ceiling of the room to collapse and shoot down loads of crystals; any players caught in them will be damaged.
        • Ranged attack: Olm shoots a ranged orb at random players in the area its head is turned to at the given moment. This is the default, regular attack.
        • Magic attack: Olm shoots a magic orb at random players in the area its head is turned to at the given moment. This is the default, regular attack.

  • Party system
    • The clan chat owner posesses the ability to create a raiding party.
    • Able to configure the party requirements; means you can set the levels required, maximum party size etc.
    • The owner of the clan - and any players eligible for kicking others - can kick other players from the party at any given time.
    • Players can advertise their raiding parties, after which it appears on the raiding board - anyone can then view the party, and of course - join it.
    • When a player eligible for kicking leaves the party - the party system will check for if there are any players eligible to kick remaining in the party. If none can be found, the party dissolved, since no one is eligible for kicking.
    • Players can log out and back in and appear in the same raid, as long as the raid isn't finished.
  • Scoreboard
    • Contains results of challenge mode raids - different party sizes categorized in there.
  • Challenge mode
    • Players can select the challenge mode when creating a raiding party.
    • Challenge mode consists of 3 floors, as opposed to 2.
    • Players have a time limit for challenge mode raids - if this is exceeded, they will not be eligible for challenge mode rewards.
    • The structure of the floors within challenge mode never changes.
  • Rewards
    • After the Great olm falls, players will be eligible for rewards. The more points the players have, the more likely they are to receive a rare drop. If no rare drop is received, the player receives supplies instead, the amount of those is dependant on their points.
    • The rare reward roll chance is capped at 80% - if the team has more points than the cap suggests, the team will get an additional roll w/ the remainder percentage at a rare drop. Up to three rare drop rolls are given per raid, if the team achieves high enough points count.
    • Current rewards formula is exact OSRS replica, with the exact same weights attached to the rewards. This may or may not change in the future, depending on feedback from players.



Bank gifs - Since I redid the whole system, I thought I'd show how flawlessly it functions. It contains some new features that weren't seen/available on old bank.

Music player changes:

Combat system patches: 
Note: These gifs are all demonstrational, as it's difficult to actually make a legit gif displaying these new features/bugfixes as well as demonstrational could.

In this gif, I modified the code real-time. Previously, as the gif initially shows, in certain circumstances, such as provided there, the monsters would just walk non-stop back and forth. However as you can see after awhile, the NPC will move to the closest exit point and resume combat. TL;DR: This is no longer an issue.

In this gif, I demonstrate how entering combat with a large npc that's standing ontop of you functions now and before. The part where I use magic shortbow is the new version. As seen, the player will now move to the closest exit point from which they can resume combat. With the old crystal bow, this was not the deal, and the player generally always ran to the south-eastern tile.

In this gif, I demonstrate how the player no longer runs 2 tiles when it's not necessary for the player to run 2 tiles towards the target. If the player is just 1 tile out of reach from combat, they will only walk one tile closer to the NPC. Previously, granted run was enabled, the player would run two tiles closer, despite only needing to move one.

Orb of oculus & Raid floor overview:

Raids - conclusive gifs. Some of the features can be seen on older gifs of course, however I thought I'd make some more gifs, since people love media. Contains some new features, is still missing certain rooms though as I couldn't be bothered to make that many gifs; all of these gifs added up already consume half a gigabyte.


  • Like 7

Share this post

Link to post
Share on other sites

Wow... That is a lot of work. 

Love the updates, keep it up.

Share this post

Link to post
Share on other sites

Nice to see an update log on the forums, thanks for all the hard work you guys are putting in and especially the attention to detail.

Share this post

Link to post
Share on other sites

For someone who "doesn't like or care for paragraphical texts or aload of writing" I love how detailed this is seeing as you didnt really seem to be overly keen on using words in enlongated ways.

never let us down with your performance and professionalism regarding your work and overall brilliancy with your's and the teams work thus far.:x 

Share this post

Link to post
Share on other sites

Saw this on the r-s post and read it all, awesome update post! Keep up the great work! <3

Share this post

Link to post
Share on other sites
This topic is now closed to further replies.
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...