Entertainer Archive

Tiaga, you have more expertise than I do on this, so in general I defer to which method you think is best. But I still don't understand how it hurts at least to start by removing the basic tools of recursion. Won't that deter the great majority of people? I know you've uncovered macro'ing possibilities far in advance of other players. Is it possible you're overestimating the majority of the game's AFKers?

---

Tiaga wrote:

...The timer I'm suggesting is client side....

---

---

JohnMarble wrote:

---

Tiaga wrote:

...The timer I'm suggesting is client side....

---

"The client is in the hands of the enemy."

---

If someoneone's going to want to circumvent the timer they'll just use a 3rd party macro, which you can't do anything about except enforce the rules.

---

NewJedi wrote:
Tiaga, you have more expertise than I do on this, so in general I defer to which method you think is best. But I still don't understand how it hurts at least to start by removing the basic tools of recursion. Won't that deter the great majority of people? I know you've uncovered macro'ing possibilities far in advance of other players. Is it possible you're overestimating the majority of the game's AFKers?

---

NewJedi, if he were to imply that every player out there could figure out how to create whatever complex ideas may be involved, then yes, he'd be overestimating some people. However, it only takes one person to figure out the idea, who's willing to share it.
Player Joe may not have the coding knowledge to figure out how to make a macro, but he probably knows how to copy and paste what Player Bob tells him.
BTW, Tiaga, I think a time limit on macros would be wonderful, with or without the removal of recursion. Keep fighting for it.

Message Edited by Aleyo on 08-06-2004 01:19 AM

---

Zilod wrote:

can you make me a real example of how the time limit will work?

---

up

*bangs gead against a wall*

I give up.

---

PistolDance wrote:

---

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

---

Yup, I agree with you Tiaga, I just am adding my 2 credits on to the discussion and my reasoning why their outlined plan as it stands scares me.

I would rather have something along your suggested lines than an intrusive stomp on the source code... plus I had to include my sarcastic prod at the fact that they are going to break SOMETHING when they do this, but a minimal change would hopefully mean a minimal break instead of a major one.

My apologies. I missed the humor in the last part of your post until the 4th or 5th time I re-read it. Just getting a little tired of reading over and over again people stating as fact that there is only one possible way that recursive macros could be stopped. Your post started to read like that. It wasn't far off though. Truthfully, I could think of probably a dozen ways to try and stop recursion without taking out commands or functionality directly.

The second idea I mentioned, limiting the run-time of a single macro instead of a dump after inactivity, is a variation of something I have actually implemented in the past in a code base that, while smaller, was probably over a decade old at the time and had the cruft to show for it. In the implementation I did, it wasn't a timer but a recursion guard of sorts. That worked for the code I was working on because it only needed to stop a specific type of recursion, and the reason was security related, not related to what could be done with recursion. However, just because it was only aimed at a single type didn't make it any easier. Every other type of recursion needed to remember the state, and there were far more than SWG has. Despite the cruftiness of the code, the implementation of the recursion guard was fairly simple and straight-forward. That's why it bugs me whenever people say that there's only one way to do things. Even saying there's only one easy way isn't entirely true.

Now if you'd said that they'd likely only break bards, I probably would have gotten it. (Old EQ joke. Nearly every big patch broke bards somehow.)

Message Edited by Tiaga on 08-05-2004 12:30 PM

---

Tiaga wrote:
My apologies. I missed the humor in the last part of your post until the 4th or 5th time I re-read it. Just getting a little tired of reading over and over again people stating as fact that there is only one possible way that recursive macros could be stopped. Your post started to read like that. It wasn't far off though. Truthfully, I could think of probably a dozen ways to try and stop recursion without taking out commands or functionality directly.

The second idea I mentioned, limiting the run-time of a single macro instead of a dump after inactivity, is a variation of something I have actually implemented in the past in a code base that, while smaller, was probably over a decade old at the time and had the cruft to show for it. In the implementation I did, it wasn't a timer but a recursion guard of sorts. That worked for the code I was working on because it only needed to stop a specific type of recursion, and the reason was security related, not related to what could be done with recursion. However, just because it was only aimed at a single type didn't make it any easier. Every other type of recursion needed to remember the state, and there were far more than SWG has. Despite the cruftiness of the code, the implementation of the recursion guard was fairly simple and straight-forward. That's why it bugs me whenever people say that there's only one way to do things. Even saying there's only one easy way isn't entirely true.

Now if you'd said that they'd likely only break bards, I probably would have gotten it. (Old EQ joke. Nearly every big patch broke bards somehow.)

Message Edited by Tiaga on 08-05-2004 12:30 PM

---

never played EQ so I wouldn't have figured the right reference to use

I know there are many ways to deal with it.. personally I would prolly go for a simple recursion / subroutine counter that gets incremented by one for every macro it drops into.. and after a certain level of recursion just abort.

But I put that knowledge with how they keep breaking factory crates, they broke scout traps and grenades being tossed from backpack instead of main inventory (when they didn't do anything with either grenades or traps according to their notes), they make schematics for stuff using resources that dont exist in any significant amount (wookiee armor using "horn" which is looted (rarely) in 1 unit stacks), they dont make checks for people exploiting things that they KNOW will be exploited because they make a first check and then never again during the process (the smuggle p/up slice exploit).

They dont know how things really work in the game as far as I am concerned, and have their own preconceived notions of how it is supposed to be ... and that view isn't what reality is.. they continually make mistakes that shouldn't be made with proper code vetting and peer review and so on and so on.. it all scares me when they start working with systems that are integrated into a lot of areas..


In their defense, when they DO get things right, they get them VERY right and very nice... the upgrades to Chef for example... the better interface for ID (ignoring the timer issue), the holo-emotes that are pretty cool effects to play with, etc.. so they -can- do good work.. but is that a risk I want to take? no.. so I am fighting for a "reasonable and minor" change instead..

---

Tiaga wrote:
*bangs gead against a wall*

I give up.

---

---

Kershakk wrote:

---

OckVofad wrote:

Maybe you know the answer to this. What is the goal of this change? Is it to stop or reduce AFK play or is it to eliminate buffbots and spambots?

As you mentioned all this can be achieved without recursive macros. The only way I can see this being achieved is if they make certain commands unusable by a macro such as: /say, /shout, or /join.

Doing this would at least get rid of bots with minimal damage to other profs (except squad leader which is going to be revamped soon right/).

---

People, this is the correct approach in my opinion, but this idea has been overlooked and/or ignored by followup posts!

Please look a little harder. I know I've seen at least 2 posts in response to this idea on the entertainer forums. In the interest of making your life easier, I will reply now to the idea here.

First, identify what the this change is targetting.

Then, you can look at how to go about it.

Rather than coming up with elaborate timers or purges, simply make /say, /shout, and any emotes unable to be used in a macro, and remove /join altogether.

The problem with removing speech from macros is that there are events that require a lot of coordination in which many parts of conversation are prepared and put into macros. Take an ingame wedding for example. If you have many guests, you could probably expect a lot of chatter in /tells and group chat, guild chat if in a guild. But you want to be able to say your vows without messing up. Heck, even without tell-hell, vows are probably something you'd like to prepare and spell/grammar-check beforehand so that it goes as gracefully as possible.
Take a large pvp event, for example, such as the recent "Show of Force" event on Shadowfire. There were tons of groups involved in heavy, and coordinated, pvp. I can't imagine that each group had its own squad leader, yet they needed the effective leader to tell them what to do. I can imagine it'd be very useful to prepare various commands to coordinate your group, such as a simple "/shout Ok soldiers, attack %TT". Rather than type this entire sentence out repeatedly, it's nice to macro it to get it at the touch of a button.
And to go to the simplest of examples (and to steal from someone else who replied to this issue), entertainers sometimes like to greet their customers using a macro, such as "/warm Welcome to the cantina, %TT, please come in and make yourself comfortable."
As for removing /join, the argument I've seen is that people with wrist problems prefer to be able to just type out /join rather than hurt their wrists by having to reach over to the mouse to access the radial.
*snip*

---

My comments above in yellow