Entertainer Archive
Thread: Stopping recursive macros is not the answer!
But it's not just a gimmick to grab attention. I really mean it. I have also told TH as such, and sent a proposed alternative. Here is a brief overview of what I sent.
Many methods have been suggested or assumed to stop recursion, ranging from the simple to the elaborate. Every single one of them suffers the same flaw. Anything that can be done with a looping macro can be done without a looping macro. I'm willing to prove this. As a result, any attempt to stop macros from looping is doomed to failure, as it will not stop anything.
The only solution to stop unattended game-play while keeping the macro system is something time based. The simplest method, which has been suggested often, is to setup a timer that kills any running commands after a period of inactivity. The biggest problem with this method is that it can be circumvented with a shoe box vibrator or drinky-drinky bird. A more complex solution to deal with that would be limiting the time within which commands from a macro invocation are allowed to run.
That is a very high level overview. What I sent to TH went into a little more detail. Some people may see a few flaws there, but those are really implementation specific and I addressed them in the more detailed overview.
For a straight timer, disabling auto-AFK would make no difference. Programmers have the capibility of creating more than one timer just as easily as they can create one. It doesn't even nevessarily need to be a timer. Unlike auto-AFK, there is no event to trigger. Just that any command after the period of inactivity would be aborted instead of run.
The other method on the surface you may think is flawed because it doesn't stop you from calling another macro and resetting the time. One of the keys of the proposal, however, is that any method of calling another macro would inherit the same time limit. Only starting something directly from the keyboard or mouse would be able to start a fresh timer.
This solves unattended gameplay without touching recursive macros or affecting ATK gameplay in any way. In either case, eventually you would be logged out of the server due to inactivity. Disabling auto-AFK would hasten this, as auto-AFK is seen by the server as activity.
Tiaga wrote:
Hey, the subject worked in the corr forum to get people's attention, I figure it should work here too.
But it's not just a gimmick to grab attention. I really mean it. I have also told TH as such, and sent a proposed alternative.
Unless they do a major revamp of the macro code removing /macro calls in a macro, running checks on all uses of /ui action ToolbarslotXX or removing the /ui action call, modify the keymap set up to prevent mapping macros to keys, AND changing the alias system they are not going to prevent people from dealing with looping alternatives to do the same exact thing...
Unless they do a serious and complex change of all these systems it wont solve the issue... and if they DO that major change I do not feel confident that they are not going to mess up unrelated or marginally related items. They do not have a good track record of keeping things clean in their changes..
Some of the pitfalls I see with their actions would be them removing the /ui action command entirely instead of doing it right by parsing for it running macros in the toolbar slot. and if they remove it entirely it will have rather extensive effects in a lot of peoples setups.
I use macros to switch weapons in a fight, to handle crafting, to handle buffing, to make sure I dont lose bivoli WHILE buffing, to cure states in combat, to heal in combat, to heal wounds of people in a fast and effective manner.
All of these would be damaged if they stomp willy nilly on the codebase, and I am pretty sure that quite a few others would have the same (or similar) issues.
The change in and of itself as stated.. to remove looping isnt that bad for me, -inconvenient- but not horrible.
But the unintended consequences of their hamhanded methods at fixing what they perceive as a problem scares the you know what out of me.... and THAT is why I am opposed to them just "nerfing looping"
So I like your proposal, its a minor enough change that they will likely only break 2 professions and a 4 crafting schematics instead of the massive issues I expect them to have if they go ahead.
If they just try and stop looping I am going to be there immediately to shoot it down. That means, indirectly, pretty much everything people are afraid of I will do everything I can to prevent happening.
Message Edited by Tiaga on 08-05-2004 10:57 AM
Tiaga wrote:
Did you even read the rest of the post beyond the first line? All these options people are afraid of wouldn't even fix anything. Heck, re-read the subject.
If they just try and stop looping I am going to be there immediately to shoot it down. That means, indirectly, pretty much everything people are afraid of I will do everything I can to prevent happening.
He did, I dont think you read the rest of his though ![]()
Ariven wrote:
So I like your proposal, its a minor enough change that they will likely only break 2 professions and a 4 crafting schematics instead of the massive issues I expect them to have if they go ahead.
Message Edited by PistolDance on 08-05-2004 11:37 AM
It's like all the people that go to the CM forum to say "nerf CM" in some way or another... Think that's traffic worth keeping?
When this hits test-center I'll be testing it, and reporting any way I find around whatever they do. I can be very creative. If it's a simple recursion check, I've already got a couple presently unused methods of looping ready to try, and will look for more. The results will be posted full disclosure... Meaning I'm going to report on everything I find in public view. Hopefully having a circumvention method before it even hits live will either get them to fix it or pull it, because nobody wants another half-assed attempt.
Depending on what they do in the end, I may push to get previous half-assed attempts pulled.. Such as the alias recursion guard.
Tiaga wrote:
When this hits test-center I'll be testing it, and reporting any way I find around whatever they do.
hawkbatleader1 wrote:
I would like to see an hourly purge of the starport and cantina areas of the 2 major cities...coronet and theed. (bestine might be nice too)
every hour, on the hour, players are given a 3 minute warning. they must clear the area, or be logged.
This will prevent afk macro'rs from surviving for more than one hourly purge...
Im sorry, I cant agree with this
Not only will the little box disrupt my play (at times it can get very hectice) but a lot of times when I log in I go afk while I get a drink, make food, answer the phone use the restroom.All of which can take over 3 minutes ![]()
Just doing any of these at the wrong time could easily take me out of game and make me lose my buffs or have to log in all over again ![]()
hawkbatleader1 wrote:Something a bit simpler than a high level timer function, that would tie up insane resources, individually tracking (server side) the entire player base, would be a directed strike at the worst 2 locations that afkrs and buff bots reside.
It's not such a huge amount of resources. Each server in the clusters is designed to handle around 200 players from what I've heard. Even my simple old-ish cell phone and the original palm pilot could handle more than 200 reminders without a problem.
The server, as it were, already has a timer to track inactivity. Try sitting there doing nothing with AFK up and no macro running. Eventually you get disconnected. Somewhere between 15 and 30 minutes, I've never bothered to test it.
The timer I'm suggesting is client side.
It's not just entertainers they are going after with this. It is all unattended play. They would need to get all the spawns around Coronet and Tyrena, all the cantinas, the borgle bat caves, anywhere there is a good resource concentration, med centers, PA halls, .... you get the idea. Not really anywhere left to go. If it were just for entertainer there are simpler ways they could do it.
Message Edited by Tiaga on 08-05-2004 02:21 PM
The trouble with stopping looping is they have tried that. Aliases have a recursion guard. See how much good it did? I've already thought of 2 ways to loop macros that I've never seen anyone suggest.