Thread: [637] Rewrite from Scratch - Solo.

Originally Posted by arham 4

Open-source pls

Well I've actually uploaded the source on the main post already so go check it out

Eugh, having real trouble with the OpenRS cache library, anyone used it for streaming the cache to the client before, or know an open source project that uses the library to do so?

Update:
- Server now makes client play (CORRECT) music in nearly all areas
- Added Module system for loading not "core" features
- Added OpenRS cache system instead of Dementhium's
- Moved a bunch of code into libraries
- Rudimentry skill API
- Action Queue API
- Added extra XTEA keys (2280)
- Revamped MapXTEA handling
- Cheat logging for players
- Configurable view distance
- A dozen packet handlers
- Player saving/serialization

On a side note, since not all XTEA keys are known, is it possible that I could rip maps from other revisions?

Eg I cannot decrypt all 639 maps, I don't have all 639 XTEA keys.

But what if I were to decrypt a missing map from (say) revision 504, encrypt it with my own custom XTEA key, save that key to my list of keys, and then pack it into my 639 cache? If the format (post-decryption) remains the same, then I would effectively be able to get (nearly) every map in existance!

Originally Posted by netherfoam

On a side note, since not all XTEA keys are known, is it possible that I could rip maps from other revisions?

Eg I cannot decrypt all 639 maps, I don't have all 639 XTEA keys.

But what if I were to decrypt a missing map from (say) revision 504, encrypt it with my own custom XTEA key, save that key to my list of keys, and then pack it into my 639 cache? If the format (post-decryption) remains the same, then I would effectively be able to get (nearly) every map in existance!

About 2 years ago what I did was change the cache's map file with the 640 one and loaded ziotics xteas with some more released by some guy. I made a tutorial but I no longer have the files.

[Only registered and activated users can see links. ]

Originally Posted by orell

About 2 years ago what I did was change the cache's map file with the 640 one and loaded ziotics xteas with some more released by some guy. I made a tutorial but I no longer have the files.

[Only registered and activated users can see links. ]

Awesome! Great to hear it. I can't seem to find a program that'll let me pull the maps out or pack them into another cache. I guess I'll have to do it programatically. Thank god I invested in OpenRS haha.

Originally Posted by Alva

If not the best, this is one of the highest quality projects in this section. I can see that you are a great programmer.

Cheers, there are a lot of other project I've seen that are better though! A lot of Graham and Method's libraries are pretty intense.

Forethought: Is it still a necro thread if I'm the one resurrecting it?

Finished Uni for the semester, glad to have third year over. Made some pretty neat changes so far. I've decided to take it in a direction of foolproof and understanding what (clearly) nobody else bothered to understand. Not necessarily 'nanny', but to save the heartache of sending packets when you only vaguely know what they do.

ClientScripts:
The cache has client scripts, java-interpreted bytecode that controls things like interface animations. I've decoded them on the server (About 3% of them don't decode correctly for some reason. Does 637 have CS1 formatted scripts, or are they all CS2?) and now when the server asks the client to invoke a client script, the number of arguments & types is validated on the server. This means you can't crash the client with a number/type for client script arguments.

Access Masks "AMasks":
There's now an interface API allowing me to eg extend PrimaryInterface to implement a BankInterface. Now BankInterface can call super.setAccessMask() without needing to specify parent and child. Instead, it just needs to specify the mask and components. On the same note, I stole an InterfaceSettingsBuilder class. After fixing it (Conceptually it was there, logic was flawed though) I can now use an API to toggle right/left click options on interfaces. Eg, I can disable 'Activate' on the prayer interface.

Actions:
There's a new ActionQueue system (v2 for me) which allows queuing of tasks. Say you want to enter combat (also implemented) with someone. First, you must reach them. Add a follow action like Follow f = new Follow(me, target, preferredDistance, breakDistance); me.getActions().queue(f);. Some actions may allow yielding to the next action if they're not necessarily DONE, but they must wait a turn without doing anything. This is great for combat, where a follow will call yield(), allowing combat to be performed. If the target moves away, Follow does not yield, and combat never gets run.

This also allows for things like queueing fletching 28 bows. I haven't tested it yet, but theoretically you could add a 'Follow Player' and 'Fletch 28 bows', so that when you catch up to the player, you begin fletching, and start following them again if they move. Not in the real version of RS, I know, but it's a cool concept.

PlayerOptions:
A simple runnable way of sending players the right click option for other players- Eg "Attack, "Challenge", "Inspect", "Ban". A runnable is stored, and when the option is clicked the runnable is run. None of this bullshit dementhium had where you have to write the send request in one position, while you write the receive handler in another position, and assume the indexes line up still.

Cache:
I've got my own cache parsing now. OpenRS was flawed when reading archives (Misordered files). Mine doesn't write yet, but does read.

Combat:
Basic combat is now implemented. Just one attack is implemented (Just Melee) but the concept of 'health', 'hits', 'death', 'respawning', 'combat stats' are all implemented ready for magic, range, prayer and special attacks to come in. It's actually pretty close to the real version. Also implemented are inventory and equipment, as well as items and their stats.

Some media:



Update#1: Spent the day implementing NPC's, ironed out a few kinks with the update system. Happened a lot quicker than I anticipated, since I've made everything really simple and generic! Only problem I'm having now is I'm not sure how to handle NPC options, there could be 100's of unique options players could click. What's a nice way of storing that? Using a scripting style? Writing it all in a single java class is awful.

Update#2: Created a massive botwar in Lumbridge. Around 100-200 players caused the Client to drop the connection (Overflowing a buffer maybe?). Server handled 2000 players, though not well. Server ticks were fine after it dropped to around 1500 players. Bear in mind that all of these players were being simulated in a 10x10 area around Lumbridge spawn, searching the server for a target player and attempting to kill them. (Lots of pathfinding to start with, consistently large amount of combat hits). Personally, I'd call having 1500 active entities without lag a success. (Protocol updates is being done on a separate thread). I would like to reach 2000 though.