Hey thanks for the reply, forgive if I sound stupid but I'm not sure i fully understand what you're talking about... could you show me a code example? if that wouldn't be too much to ask?
I don't know what source you're using, so I won't be able to help specifically, but maybe I can help point you in the right direction as well as providing you with generic code
examples. RuneScape, as well as it's private server counterparts, uses a tick system to handle packets of information. I believe that delay of information is 600 milliseconds. Whatever source you're using more than likely uses a thread system in order to pull many different tasks from many different sources in order to perform this tick asynchronously and with concurrency. For example, one of these threads could look something like this:
Code:
private final ThreadGroup group;
private final String namePrefix;
private final AtomicInteger threadNumber = new AtomicInteger(1);
public Thread newThread(Runnable r) {
Thread t = new Thread(group, r, namePrefix
+ threadNumber.getAndIncrement(), 0);
if (t.isDaemon())
t.setDaemon(false);
if (t.getPriority() != Thread.MAX_PRIORITY - 1)
t.setPriority(Thread.MAX_PRIORITY - 1);
return t;
}
Now to find where they are and when they are called shouldn't be too much of a challenge. Each tick will need to handle information of restoring energy, for example, so if you can find that, you'll eventually be able to find the code that handles updating the tick. I would assume whatever class handles the world information, such as player count, would handle restoring energy. Once you find the class that handles player count, you can then search for the method that handles restoring a player's run energy. This, I imagine, is where we will be able to find the parent code. Whichever class is being used to handle these fast-based tasks, like restoring run energy, is likely to be directly tied with the server tick. Lets call this task handling class the TaskHandler, and lets just say that energy restores every 3 server ticks. Again, these are examples. The energy restoration code might look something like this:
Code:
private static void addRestoreEnergyTask() {
TaskHandler.addFastTask.schedule(new TimerTask() {
[MENTION=381607]Override[/MENTION]
public void run() {
try {
for (Player player : getPlayers()) {
if (player == null || player.isDead() || !player.isRunning())
continue;
player.restoreRunEnergy();
}
} catch (Throwable e) {
Logger.handle(e);
}
}
}, 0, 1800);
}
This TaskHandler class, which you can see is called at the top of the method, is likely pooling tasks directly to the tick's queue. Heading to the TaskHandler class you will probably see similar code in the init() method:
Code:
addFastTask = new Timer("Fast Task");
addSlowTask = availableProcessors >= 6 ? Executors
.newScheduledThreadPool(availableProcessors >= 12 ? 4 : 2,
new SlowThreadFactory()) : Executors
.newSingleThreadScheduledExecutor(new SlowThreadFactory());
Towards the bottom of this method, you'll probably see some variable initiating it's start method ('
serverThread.start()' for example). Go to the class that is initiating it's start method - in my example I used the variable serverThread. So, whichever class serverThread is calling, head there. You will likely find rows of code that look similar to this:
Code:
if (taskInformation.continueCount > 0) {
taskInformation.continueCount--;
continue;
}
Or maybe it's lots of for loops that look like this:
Code:
for (NPC npc : World.getNPCs()) {
if (npc == null || npc.hasFinished())
continue;
npc.processEntity();
}
Either way, if you can find whichever thread that handles where local players and entities are updated, you will be able to save your player's previous tile at the start of the tick. This information is probably already saved in a method somewhere in the Player class. Lets call that method processInformation. In that init() method, where you found the thread, you can add something like this to save your player's information at the start of the tick:
Code:
for (Player player : World.getPlayers()) {
if (player == null)
continue;
player.processInformation();
}
This way, your player's information should be stored at the start of each tick, and you could enjoy dancing with others.
Please be aware that the above may be wildly inaccurate for the source you're using, and that it is difficult to provide you with direct code examples without having any information to rely on. What I provided is simply very generic examples of where you may update this information, and how you may find it. Also be aware that you may also need to remove whatever code saves your player's information currently if you do intend on trying to add this.
And as I was writing this reply, the thought occurred that you may want to check the method that handles your player following. It could be that the players are not going to the player's last tile and facing the target, but instead it may be pathfinding to the target, +/- their x/y coordinates based off of clipping restrictions.
Hope this helps!