Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won

  • Feedback


Patrick last won the day on June 13 2019

Patrick had the most liked content!

Community Reputation

5 Neutral

About Patrick

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. We're still going on strong! Just posted a massive update come join us in the discord! https://discord.gg/EKxXpbH
  2. LoyaltyScape is an economy server dual loading 634 and OSRS data with 530 maps. We’ve been under live development for 18 months and I believe we now have a quality server that players will enjoy. Content ➤ Player Owned Shops ➤ 40+ Bosses | 25 skills | 13 minigames ➤ Over 400 Treasure Trail rewards from OSRS and RS2 ➤ Full OSRS Zulrah ➤ Bank placeholders ➤ 4 different Ironman modes ➤ Full OSRS Vorkath ➤ Keybinding/Customizable F keys ➤ Fashion scape shops with hundreds of cosmetic items ➤ Customizable client settings ➤ Over 50 pets including Skilling pets, Boss pets, and more ➤ Searchable drop table ➤ Custom last man standing, Free For All, and Prisoners minigames ➤ Animated rank icons ➤ Discord rich presence with Skilling and Combat integration ➤ Pet fighting ➤ Custom Bosses with custom mechanics ➤ Numerous experience boosting items Bugs and Development ➤ Fixed patchy cache-loads 634 and osrs ➤ Access to all osrs maps, objects, anims, items, and npcs ➤ Over 200 player suggestions implemented ➤ Over 1000 bugs fixed (don’t use ruse) ➤ View full list on our discord in #server-updates Media Non Profit? Credits
  3. I spent a decent amount of time looking at the client code to figure out how projectiles work precisely so I know how to manipulate them with the parameters better. I thought I might as well share what I learned to help others. This is from Major's refactored 317 client (https://github.com/zg/317-client). I'd guess that projectiles are handled in most revisions in the same way, but I only looked at 317. if (opcode == 117) { int positionOffset = buffer.readUByte(); int sourceX = localX + (positionOffset >> 4 & 7); int sourceY = localY + (positionOffset & 7); int destinationX = sourceX + buffer.readByte(); int destinationY = sourceY + buffer.readByte(); int target = buffer.readShort(); int graphic = buffer.readUShort(); int sourceElevationOffset = buffer.readUByte() * 4; int destinationElevation = buffer.readUByte() * 4; int ticksToEnd = buffer.readUShort(); int ticksToStart = buffer.readUShort(); int elevationPitch = buffer.readUByte(); int leapScale = buffer.readUByte(); if (sourceX >= 0 && sourceY >= 0 && sourceX < 104 && sourceY < 104 && destinationX >= 0 && destinationY >= 0 && destinationX < 104 && destinationY < 104 && graphic != 65535) { sourceX = sourceX * 128 + 64; sourceY = sourceY * 128 + 64; destinationX = destinationX * 128 + 64; destinationY = destinationY * 128 + 64; Projectile projectile = new Projectile(sourceX, sourceY, method42(sourceX, sourceY, plane) - sourceElevationOffset, destinationElevation, elevationPitch, ticksToStart + tick, ticksToEnd + tick, leapScale, plane, target, graphic); projectile.target(destinationX, destinationY, method42(destinationX, destinationY, plane) - destinationElevation, ticksToEnd + tick); projectiles.pushBack(projectile); } } For those more interested, the rest of the code referred to is in Projectile.java. Firstly, the start position of the projectile is sent in packet 85 and stored in localX and localY just before this packet is sent. positionOffset (incorrectly called angle sometimes in server) is often always sent as 0. This allows you to offset the projectile from the start and end position by a small amount. The positionOffset is an unsigned byte with the first 4 bits representing the x offset and the last 4 bits representing the y offset, so these should give you a scope of 0-15 squares to vary from the starting position for x and y (requires some simple tweaks to get full range and positive/negative offsets, default 317 just has 0-7 offset for x and y in the right and up direction because of the >> 4 & 7 and & 7). The next two bytes sent are for offsets to add onto the starting position (with positionOffset applied) to get the destination position stored as destinationX and destinationY. target is important (sometimes called lockon) and it takes a signed short. A value of 0 represents no tracking and is used for a position to position projectile. Otherwise it will track an npc or player. To track an npc you send the npc's index + 1 and to track a player you send the player's index as (-1 - index). The +1 and -1 are just to compensate for 0 not being an option since that represents no tracking and entity indexes also have 0 as valid player/npc indexes. graphic is just the id of the graphic/spotanim that is the projectile to send/ sourceElevationOffset and destinationElevation are used for the start and end height of the projectile, I didn't look into this much but might edit the post if somebody in the comments has useful information or I look into this myself. I probably will look into this to see what the feasible max and min values are for this parameter. The sourceElevationOffset adds onto the floor height that is at the start position and destinationElevation adds on to the floor height at the end position as you'd expect. ticksToStart and ticksToEnd are how you control the duration and delay of the projectile. They are measured in client frames and the client should run at 50 fps so this is 20ms or 0.02 seconds. The ticksToStart value represents the number of client frames to wait before starting the projectile. The duration of the projectile is ticksToEnd - ticksToStart. So sending ticksToStart as 30 would be a 1 tick delay. This would be much better to use rather than tasks or delays server sided before sending projectiles which quite a few poorly written servers do. Server sided it would probably be a good idea to change the parameters to specify the ticksToStart as delay and make a duration parameter. Then send the client delay for ticksToStart and delay + duration for ticksToEnd. This makes it so changing one doesn't affect the start doesn't require modifying the other parameter to preserve duration. elevationPitch is the main reason I looked into this in the first place. On my server this was hard coded as 16 when sent and wasn't even modifiable (ruse). This controls the arc that the projectile follows. It gets used in the target method which is basically the initialization code for the projectile: Math.tan(elevationPitch * 0.02454369D) The Math.tan function takes in the angle as radians and the multiplication by the 0.02454369 makes things interesting. The tan function peaks out to infinity at 90 degrees or pi/2 radians. With this scale it peaks out at exactly elevationPitch=64. As to why it's like this, I would only be pulling out of my ass rather than my brain. (Fits nicely into 6 bits though). As for getting meaning out of this value you can modify it to get the exact angle of projection you want for the projectile. Say we want 30 degrees. Then we would send elevationPitch as Math.toRadians(30) / 0.02454369D. As you increase the elevationPitch from 0 to 64, be aware that the speed of the projectile increases to keep the time of flight constant. So if you change an existing projectile's elevationPitch from 30 to 60, its speed would be much faster. If for whatever reason you want the projectile to go downwards and curve upwards (inverted rainbow) you can do so with elevationPitch in the range of (64, 128] where 128 is perfectly flat and closer to 64 is more curved. elevationPitch = 105 leapScale (sometimes called radius) I'll be honest I don't really know what this is entirely and it was also hardcoded as 64 for all the projectiles on ruse server sided. This specifies at which point along the arc the projectile should start. If you pass 0 it will start exactly on the starting position (which would look weird usually). The higher you make it, the further along the arc your projectile will appear when it starts. There is a point where it will go past the end point of the projectile and will start even further out than the end point and travel backwards to the end point (might be interesting for somebody doing some wacky custom content idk). This won't likely happen though when restricted to a single byte, I only found this when I was modifying the value client sided for fun and I put it pretty high. Calculating the parameters for halfway or quarterway etc of the arc with leapScale can be done, but I will probably do that at a later date since it's a bit more math and there's enough stuff here as it is. leapScale = 400 All of this information came from my deductions from reading the client code for projectiles which may be incorrect. Hope people find this useful
  4. Yeah, I mean I barely have the time to finish the thread as it is. And compared to the effort I've put in myself (2000+ hours), there's not really that many people to thank. The original base was a mess and practically everything that was added from the base it took over from had problems and got removed, rewritten, or still needs to be redone. I will add credits closer to the end when the ratio of my work to theirs is more balanced in what content I'm showing. Anybody who I'd credit I'd probably also flame out because the code they had was terrible lmao. But the people I mentioned in the above post had useful stuff there that saved me a little time. If I knew ahead of time how bad the base was I would have used something else, but it's been fun so it is what it is.
  5. Yes, I coded the Santa hat maybe like 5 months back. All of my added content is done by myself. Only things I've ripped I remember and they were more things that are data rather than code: Rune pouch interface from runity, Chaos tunnel teleports coords off a rune-server snippet, Jewelry crafting interface and data from rune-server, enchanting jewelry data from Necrotic (ended up not using any of their enchant code itself cause it was done poorly), ground item highlight from Necrotic (that was only sizable thing that I ripped from anywhere, but again I made it more efficient and added some tweaks). There's so much that has been done, I just really prefer adding more content / fixing things than putting it here all nice and neat. As for the gifs the quality isn't there, in the last gif you can't even see the Death symbol on the Death altar for example.
  6. Currently trying to find a way to get better quality gifs :'c I realized the last ones didn't turn out so well. Need to fix my sharex settings of get something else sigh.
  7. I've spent the last year developing and it's long past time that I showcase some of the content to come. Launch data: unknown. There isn't enough space to put the full content and changes that we've done over the last year, so I'm only going to add the new stuff and occasionally add our previous work. Media More to be added overtime, we have thousands of hours of bug fixes and content additions! Stay tuned
  • Create New...

Important Information

By using our forums or services as a guest you agree to our Terms of Service: Terms of Use Privacy Policy: Privacy Policy and Guidelines