Jump to content

RequestListener


Recommended Posts

Posted (edited)

Ok so i can't really figure out a better logic for this but what i am trying to do here is when a player trades me, it'll accept.

What this code does is once it has finished trading it'll keep trading the same character for a while until requestListener == null

 

my code; 

		if (getTrade().isCurrentlyTrading()) {
			if (getTrade().isFirstInterfaceOpen()) {
				if (getTrade().acceptTrade()) {
					new ConditionalSleep(1000) {
						@Override
						public boolean condition() throws InterruptedException {
							return getTrade().isSecondInterfaceOpen();
						}
					}.sleep();
				}
			} else {
				if (getTrade().isSecondInterfaceOpen()) {
					if (getTrade().acceptTrade()) {
						new ConditionalSleep(1000) {
							@Override
							public boolean condition() throws InterruptedException {
								return !getTrade().isCurrentlyTrading();
							}
						}.sleep();
					}
				}
			}
		} else {
			if (getTrade().getLastRequestingPlayer() != null) {
				if (getTrade().getLastRequestingPlayer().getName().equals("")) {
					if (getTrade().getLastRequestingPlayer().interact("Trade with")) {
						new ConditionalSleep(1000) {
							@Override
							public boolean condition() throws InterruptedException {
								return getTrade().isCurrentlyTrading();
							}
						}.sleep();
					}
				}
			}
		}

How am i supposed to make it so that once it has finished trading it won't trade the same character again ?

 

EDIT:/ First trade finished it won't interact with the character .. but once i go into second trade, finish it then it'll keep trading the character for a while until getLastRequestingPlayer() == null

Edited by Ayylmao420
Posted (edited)
1 minute ago, Ayylmao420 said:

Sure but that won't stop the interaction spam because getLastRequestingPlayer() will return != null for a while.

If you are worried about that then you can check if you initiated the trade already and if you have then if the trade is closed and the items you are expecting to be gone are gone or gained then you can set it to stop trading otherwise re-trade because the trade closed unexpectedly.

Edited by House
Posted

I'm not exactly sure what it has to do with the title of the thread, but the notion of "listener" generally denotes something whose whole purpose is to signal a thread group when something happens (achieved in java through the notify method and thread interruption if required). If you manage to write a sound implementation of a trade request listener then this sends a signal every time you receive a trade and is consumed by everyone who receives it, same as an input listener, you will not be able to respond more than once to the same event.

Posted (edited)
2 minutes ago, Token said:

I'm not exactly sure what it has to do with the title of the thread, but the notion of "listener" generally denotes something whose whole purpose is to signal a thread group when something happens (achieved in java through the notify method and thread interruption if required). If you manage to write a sound implementation of a trade request listener then this sends a signal every time you receive a trade and is consumed by everyone who receives it, same as an input listener, you will not be able to respond more than once to the same event.

what i am saying is that getTrade().getLastRequestingPlayer() returns != null for a while even though the character haven't received any more trades after the trade.

Edited by Ayylmao420
Posted
Just now, Ayylmao420 said:

what i am saying is that getTrade().getLastRequestingPlayer() returns != null for a while even though the character haven't received any more trades after.

I have no idea what that is supposed to return but by the name of it, the result should be last player who sent you a trade offer (maybe what you need is getLastRequestingPlayerNotAccepted()). My logic may be flawed but I don't see any reason for that to return null if you completed a trade with that player, unless he logs out or leaves the local region (or you leave it) because if I were to implement that, it would be just a filter on players.getAll() which would return null if the player can't be located.

Posted
20 minutes ago, Token said:

I have no idea what that is supposed to return but by the name of it, the result should be last player who sent you a trade offer (maybe what you need is getLastRequestingPlayerNotAccepted()). My logic may be flawed but I don't see any reason for that to return null if you completed a trade with that player, unless he logs out or leaves the local region (or you leave it) because if I were to implement that, it would be just a filter on players.getAll() which would return null if the player can't be located.

Well, sometimes after trade, getLastRequestingPlayer() returns == null like it is supposed to ? But most of the times it'll return != null for like 10 seconds ?

Posted
11 minutes ago, Ayylmao420 said:

Well, sometimes after trade, getLastRequestingPlayer() returns == null like it is supposed to ? But most of the times it'll return != null for like 10 seconds ?

What I just said is there is no logical reason for the method to return null after a trade is completed and you should not write your code around that. If that was the case then the naming of the method would be wrong. But if you still don't believe me when I explained what the method should do, here is this code

N5zi0p2.png

35 minutes ago, Token said:

just a filter on players.getAll() which would return null if the player can't be located.

But there is additional code in getRequests() which removes these after exactly 15 seconds have passed. The fact that requests are removed after 15 seconds does not matter because "GET LAST REQUESTING PLAYER" doesn't contain anything related to whether a trade was done with that player, that is done either by using chat messages or caching the trade status and checking the progress. The implementation of getRequests() is entirely based on a MessageListener which adds chat messages to a linked list and removes them after 15 seconds have passed (this is for the sake of memory management and you should not rely on it).

Posted (edited)
17 hours ago, Token said:

What I just said is there is no logical reason for the method to return null after a trade is completed and you should not write your code around that. If that was the case then the naming of the method would be wrong. But if you still don't believe me when I explained what the method should do, here is this code

N5zi0p2.png

But there is additional code in getRequests() which removes these after exactly 15 seconds have passed. The fact that requests are removed after 15 seconds does not matter because "GET LAST REQUESTING PLAYER" doesn't contain anything related to whether a trade was done with that player, that is done either by using chat messages or caching the trade status and checking the progress. The implementation of getRequests() is entirely based on a MessageListener which adds chat messages to a linked list and removes them after 15 seconds have passed (this is for the sake of memory management and you should not rely on it).

Well, right now i ended up using messagelistener and hashmap, made it so that it'll clean the list every 1 second, it'll be enough to execute interaction event.

Not sure if the smartest way but meh, works.

Edited by Ayylmao420

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...