Dancer Archive
Thread: TH Statement on how Recursive Macros might be handled
Tiaga wrote:
SmedleyLlama wrote:
Drygo wrote:
That would be wonderful. The time limit thing would make it even more difficult for buffbots, but make it easier for people to use their macros.
From the stand point of Buff Bot elimination, this is really bad news. It means the Buff Bot owner can load 144 ten minute macros (assuming the limit is 10 minutes), put one in each toolbar slot, have each end by calling the next and run unattended for 24 hours. Since it wouldn't be an infinite loop and the macro time was limited, the Buff Bot owner would only have to restart the cycle once every 24 hours. Basically cascading macros rather than recursive.
If he's right and this is how they are doing it, I think it will be a useless gesture.
Time limits don't have to be per macro. It can be overall (An idea mentioned a lot; dumping all macros after a period of inactivity) or even per macro chain.. Such that one macro would inherit the remaining limit of the macro that called it. So in your example, the second macro would have 10 minutes less in it's limit than the first. That means it would pretty much be killed before even getting in a single command if the limit is also 10 minutes.
Possibly.. Although since the game regards each "click" of a toolbar slot to be an action from the player (whether by macro or actual mouse click) I'm not sure that can be done. That's why people do not get booted after being inactive right now, with a macro running. Since they are trying to solve the problem by removing the macros rather than simply booting inactive people, I would think there is a problem with that solution.
I suppose we'll have to wait and see.
The thing with programming is nearly anything can be done. It's just a matter of effort.
In this case, I've done something very similar in the past, for different reasons. It was in a game where players could write short scripts. One of the things they could do was force a player or object to issue a command. The server didn't distinguish this as coming from a real player or coming from a script. This created a problem if a player managed to find a way to force a priveleged character to do something. The specific case involved forcing the all powerful character to do some things that only that character is supposed to be able to do. The trouble is, other players appointed to help run things had as a power the ability to force anyone to do a command. As such, they could get that player to do anything they wanted.
Since the server didn't distinguish forced commands vs regular commands, it's a lot like the problem here, except here it's client side scripts. The implementation turned out to be very easy, and I was able to add in a check that tracked who really started the command and if it was a forced command. Something similar could be done in the SWG client to track when a command was really started vs when the current macro was started, which may be more recent if it was the result of a macro call.
Of course, without any knowledge of how the client actually works, I can't say for sure the implementation would be as easy, but such a thing is definately possible.
Tiaga wrote:
The server doesn't know anything about toolbar clicks. It just knows commands. That is why macros prevent you from being logged out, not because of the toolbar click. The toolbar click doesn't prevent auto-AFK from triggering either, because the client can differentiate them.
The thing with programming is nearly anything can be done. It's just a matter of effort.
Sorry.. Maybe clicks was the wrong word, that's why I put it in quotes. Since each click is actually sending a command to the server, you still get what I'm talking about.
So, youdon'tthink that ,if they could simply base all of this off of an inactivity timer, they wouldn't just boot players that were inactive for any period of time? Rather than going through this firestorm over recursive macros?
Who knows.. Maybe I've just lost my faith in the Devs reallyproviding the effortto do things right.
Tiaga wrote:
Is there really any difference between disconnecting inactive players and killing the macros of inactive players? The latter merely gives them an extra 15 or so minutes before they are logged out.
No and that's my point.
Why bother with the fuss from the players opposed to the idea, and design a new system to track macro length and infinite loops, when the system already exists to boot an inactive player offline. Unless that system has a flaw caused by the macro system. A flaw that would have to be fixed before they could track the length of multiple macros, and that would render the need to doso unnecessary.
EDIT - Typo fix
Message Edited by SmedleyLlama on 08-10-2004 06:14 PM
Whatever is done should be purely client side. It COULD be done server side, but that would increase bandwidth usage. While it's true "the client is in the hands of the enemy" and so can not be trusted... If someone is going to try and find a way around it, they are going to use 3rd party programs, not hack the client to disable the timer.
Drygo wrote:
That would be wonderful. The time limitthing would make it even more difficult for buffbots, but make it easier for people to use their macros.
From the stand point of Buff Bot elimination, this is really bad news. It means the Buff Bot owner can load 144 ten minute macros (assuming the limit is 10 minutes), put one in each toolbar slot, have each end by calling the next and run unattended for 24 hours. Since it wouldn't be an infinite loop and the macro time was limited, the Buff Bot owner would only have to restart the cycle once every 24 hours. Basically cascading macros rather than recursive.
If he's right and this is how they are doing it, I think it will be a useless gesture.
SmedleyLlama wrote:
From the stand point of Buff Bot elimination, this is really bad news. It means the Buff Bot owner can load 144 ten minute macros (assuming the limit is 10 minutes), put one in each toolbar slot, have each end by calling the next and run unattended for 24 hours. Since it wouldn't be an infinite loop and the macro time was limited, the Buff Bot owner would only have to restart the cycle once every 24 hours. Basically cascading macros rather than recursive.
If he's right and this is how they are doing it, I think it will be a useless gesture.
SmedleyLlama wrote:
Drygo wrote:That would be wonderful. The time limit thing would make it even more difficult for buffbots, but make it easier for people to use their macros.From the stand point of Buff Bot elimination, this is really bad news. It means the Buff Bot owner can load 144 ten minute macros (assuming the limit is 10 minutes), put one in each toolbar slot, have each end by calling the next and run unattended for 24 hours. Since it wouldn't be an infinite loop and the macro time was limited, the Buff Bot owner would only have to restart the cycle once every 24 hours. Basically cascading macros rather than recursive.
If he's right and this is how they are doing it, I think it will be a useless gesture.
Time limits don't have to be per macro. It can be overall (An idea mentioned a lot; dumping all macros after a period of inactivity) or even per macro chain.. Such that one macro would inherit the remaining limit of the macro that called it. So in your example, the second macro would have 10 minutes less in it's limit than the first. That means it would pretty much be killed before even getting in a single command if the limit is also 10 minutes.