Entertainer Archive
Thread: Should AFK entertaining really be a top five issue?
AFK macroing has really put a dent in the way that I play. When I first started playing I spent so much time in the cantina I got so sick of it, that I almost Mastered Droid Engineering, just to get out of the Cantina. Then after my break I came back to the cantina and no one was there. Started asking around and everyone says they are going to Theed to get healing. Some of the smaller Cantinas are deserted and the ones that have entertainers are AFK most of the time.
I would love to see something happen to clear out AFKers. I would love to have people start asking my DE to come to the cantina and play, but that does not seem like it will happen, because there will soon only be the player city cantinas running and everyone will be there.
Oh well will have to see if any guilds are looking for a Musician to play their cantina? 
We need both. They need to crack down on exploits programatically, which they already do, AND they need to make it clear the behavior will not be tolerated and police it.
Of course, since Sony has already stated they see no issue with AFK entertaining, the very first step is to convince them how damaging it really is and that we want it gone.
The way we do that is to keep it in the top 5.
- J
Okay, barring a barrage of input to the contrary, y'all are convincing me to keep working on this as a top 5 issue.
Now I need an answer to the second part of the question - What should be done about it?
Keep in mind that it's the "/ui action " command that allows the looping and that there are legitimate uses for this command. An easy example from our sister profession - Dancers will often put all of their clothes on hotkeys. They then make a macro activates a smoke bomb and follows up with a bunch of /ui actions assigned to certain coordinated outfits. The result is that they can press a button and do a "quick change" of their entire clothing ensemble under cover of the smoke bomb. It's a nifty effect that a lot of dancers would be unhappy about losing.
Message Edited by SlickRiptide on 11-26-2003 06:55 AM
There are other ways of handling the scenario. They range from the tame to the severe.
Personally, my preference is for them to continue to enhance player-run cantinas over NPC-run cantinas. I do not believe they've gone far enough to actually drive people out of Coronet or Theed. They're fighting inertia, and unless they provide some real incentive to take the shuttle trip to a player city and enter a player-run cantina, things will remain the same.
I personally would like to see them do one of two things. One, remove all experience gain for entertainers above novice musician/dancer from NPC cantinas. Let beginner entertainers have those places to train in, but advanced entertainers should find a player-run cantina and entertain there. Once it becomes known the best entertainers are in the player-run cantinas, people will flock there.
Two, change healing rates for NPC cantinas to a fraction of what they are now. Leave player-run cantinas, camps and houses intact. This too will strongly encourage those with lots of wounds and battle fatigue to go to a player-run cantina in favor of an NPC one.
Keep in mind that with player-run cantinas in the game, these are NOT nerfs. There will be even MORE cantinas for people to use on every planet than there are now. All this is doing is encouraging peope to shift to those player venues.
- J
More content to keep interest in the musician dancer profession = less afk
This has become my #2 issue for musician because people won't shut up about it. I long for the day when AFK is not listed in 60% of the post subjects on the entertainer boards.
Let entertainers leave the cantina and do there work at camps and such so they can have a taste of adventure. (from what I've read today this may be in the works) When I am building rifle experience, I get to travel around, go on missions, see the world, when I was building musician experience all of the worlds I saw was what people told me. I saw the same glum walls and metal floor of that Tyrena cantina. I moved to different cantinas to break the boredom. I enjoy playing music, I really do. I know more songs and such are in the works, but for those who DON'T enjoy playin music but do it anyway to become a jedi, I cannot imagine a worse fate.
I suggest that the ONLY way to stop the AFK player is to make the experience of playing or dancing live more interesting. You must cure the cause of the problem, not the symptom. A positive motivator is worth much more than a negative one. Players will always seek ways to make a game more fun. Any change that is made in an attempt to stop afk players should make the game more fun, not less fun.
No. It should NOT be a top 5 issue. Because if it is... it will always be on the top 5... It will NEVER go away. Anything done to fix it will effect ATK gameplay more then AFKers. If a macro fix is put in it will effect everyone in the game... All so that those that wish to still do it... can still do it, With Ease.
1. The rules say you can't do it...
Not really true. They clearly say you can't use outside programs to bot. But with SOE putting the large macro system into the game.(aliases,hotkeys the menus all more or less use the ingame macro system) SOE CAN'T enforce this unless they do find someone using 3rd party programs(which is highly unlikely that they can even find those people).
2. People are Rude(take the good spots in the front or stand on top of you )and spam(crap or ask for tips)...
And what kind of freakin AFK fix do you think is going to stop this ?
We have ignore... use it. Kick AFK people from the groups(after stopping them from playing if you wish to grief them some, although not as easy to grief them when they are dancing..).
I really would like to see some way of moving the AFKgood spot takers tothe back rooms or side rooms .
3. It makes people not want to tip....
So if someone is watching you... and your entertaining them... and healing them... They don't want to tip because some other toon in the same area is spamming and they can't figure out how to /ignore that person ? Riiiiiiight.......
4. It's boring with all these AFK people... no one to talk too... just sitting there staring at the walls....
You have a spatial for a reason. There are chat rooms. You can tell people and talk...
This once again not something a NERF can fix. I gets a little boring after a while of being in cantinas no matter how entertaining the people there are. So I know of many entertainers that have then headed out to see other sites... It happens. but Nerfs won't fix this... instead added content will help. And it needs to be content in many different forms so that those that are bored with the view in the cantina can get out and yet still do entertainer things.
I strongly believe that the DEV's can not provide an anti-afk fix that will not negatively effect not only entertainers but ALL players.
I also strongly believe that positive additions to the game can help with alot of the reasons behind AFKing(for those that love entertaining and socalizing). And that maybe one change (the ability to move AFKers to side rooms in a cantina) would do a world of good. We already have /ignore. We can kick people from groups..
But the things we need help with in relation to AFKing is; being able to move AFK toons to the side and giving us content/more reasons to be ATK.
And moving the afk toons is not something I would expect the DEVs to really honestly put any thought into coding in.
So to recap..
No I do not believe AFKing should be a top 5 issue. I am an entertainer and AFKers affect me so little directly(and anything indirectly is not something you can prove at all so it's total theory), while I sit there day after day staring at the inside of a cantina. Slowly gaining healing xp having a great time talking and interacting but also wishing that there was just a little more to it then that...So that if I felt the need for a change of pace or a different view... I could do it with ease.
p.s.
Yes I know my spelling sucks.
SlickRiptide wrote:Now I need an answer to the second part of the question - What should be done about it?
Keep in mind that it's the "/ui action " command that allows the looping and that there are legitimate uses for this command. An easy example from our sister profession - Dancers will often put all of their clothes on hotkeys. They then make a macro activates a smoke bomb and follows up with a bunch of /ui actions assigned to certain coordinated outfits. The result is that they can press a button and do a "quick change" of their entire clothing ensemble under cover of the smoke bomb. It's a nifty effect that a lot of dancers would be unhappy about losing.
PennMUSH, one of the older MUSH engines, has had a way to prevent "runaway" or exploit code looping for at least 10 years. They should just borrow from that.
In PennMUSH, ANY player is allowed to use the in-MUSH scripting commands. That's right, anyone. It allows even more power and control over scripting stuff than macros do. The problem is that people can create endless loops that cause a load on the system. So the Penn designers had to find a way to prevent that.
The solution is the "code bit." Upon character creation, everyone gets a certain number of "code bits." 150 is the default though whoever runs the MUSH can change it. Then, each new login DAY (not login... only if you login on a new day from the previous login) you get a few more "code bits"... the default is 25.
Each "process" you call with a scripted command uses a variable number of "code bits" from 1/64th of a bit to 1 full bit, depending on how "expensive" the command is to execute. Thus simple commands like a scripted way to change your @describe variable (the textual description people see when they "look" at you) would take 1/64th of a bit, and you could do this 150x64 times before running out of your initial code bits. Doing something more complex like an @search through the database, would be more expensive and might take a full bit. Now the typical player doesn't execute many commands via scripting, and as a result, the typical player accumulates "code bits." One of mine had over a million at one point. But if someone is doing heavy scripting, he could run out if he is not careful. Most particularly if you fire off an endless loop, you are GOING to run out of code bits and that will halt the loop.
It seems to me all SWG has to do is institute almost exactly this system. Have each macro call cost a code bit (or whatever), as well as each alias. You get a certain number of "code bits" a day that corresponds to the amount a "normal" at-keyboard player would use during normal at-keyboard play. Or perhaps refresh them a little bit for each keyboard-input command, so that if you are typing chat while macro dancing your code bits would even out. Either way, someone AFK macroing will eventually run out of code bits -- this should be long before you ever get anywhere near master -- and then they have to either wait a long time while logging in every day to build them back up, or start playing at keyboard. The point is this will slow it down to the extent that they can't get master any faster than an at-keyboard person and preferably it would be slower than at-keyboard play. If at-keyboard play were the fastest way to get to master, then nobody would bother with AFK.
C
SlickRiptide wrote:Okay, barring a barrage of input to the contrary, y'all are convincing me to keep working on this as a top 5 issue.
Now I need an answer to the second part of the question - What should be done about it?
Keep in mind that it's the "/ui action " command that allows the looping and that there are legitimate uses for this command. An easy example from our sister profession - Dancers will often put all of their clothes on hotkeys. They then make a macro activates a smoke bomb and follows up with a bunch of /ui actions assigned to certain coordinated outfits. The result is that they can press a button and do a "quick change" of their entire clothing ensemble under cover of the smoke bomb. It's a nifty effect that a lot of dancers would be unhappy about losing.
Message Edited by SlickRiptide on 11-26-2003 06:55 AM
It's a hard question.
Most of the answers I can think result in sub-optimal situations (ie, AFK performing persisting).
A loop counter that allows x ammount of '/ui action' commands in a given timeframe is bypassable if you simply make the base of the macro long enough to surpass that limit. However, you can get around this by limiting macros to a given number of commands, which would make it difficult for a performer (specifically dancer since they get the most 'time' per command used in this instance) to fit within that time frame.
Hypothetical explanation:
If you're allowed x /ui actions per y minutes, you would need to limit the command length of a macro by y/x minutes * 6 - 1.
6 comes from 60 seconds per minute / 10 seconds (time frame for dancer flourishes). Subtracted one so that you're not at the 'perfect' time frame repetition to maintain your macro.
Real trouble with that, is it's a bit of work (and tracking). Also it would impede dancers from doing outfit changes more often than y minutes, notably x would also need be to equal to one 'outfit switch' at minimum (also 2*'one outfit switch' would be better). Further, y would adjudicate how long you can reasonably 'go afk' and be ok (5 to 15 minutes seems good to me, but I'm not a dev
). This still seriously hurts crafter macros (I think anyway), and honestly almost no way around that except by checking to see if the toolbarSlot command is calling a macro or not.Hmm, that is a thought though, if /ui action toolbarSlot is called and the 'Slot' is pointing to a macro, maybe just /cancelmacro instead? It's only one look ahead, which isn't 'too bad'. It doesn't really hinder the crafter macros, nor does it hinder the dancer outfit change. However, without a macro command limit (if there is one, I'm going to feel stupid), extended unattended gameplay is still possible. However, it would still allow 5 to 15 minute afk 'performance' breaks, and that can still be perserved with a macro command limit (that would be unfair to muscians, half the time for dancers).
Anycase, I don't think looping is the 'only' problem with AFK performers, as I do remember folks who were running on 5 or 8 hour macros near launch (before realizing how to loop I suppose).
I dont think it should be an issue because no matter what is done by SOE the people who actually use macros as an exploit will always find a way to continue to do so.... its very easy to use 3rd party software to do this and its not as hard as somepeople may thing.. I use the same types of software at work to automate reports and it could very easily be used to afk marco.. and actually work even better since you would never go "AFK" in game.
It would be nice to never see an afk entertainer, but lets notstart making so much noise about it that we have them nerf /ui action commands.. I use them all the time to unequip and equip armor after and before a fight, there are countless legit uses for them, and they are how ppl are currently AFK entertaining..
btw.. I'm not an entertainer.. just noticed how few posts there were on the board and figured I would pop in.
>>Now I need an answer to the second part of the question - What should be done about it?
>>Assume there is one single guy checking one server per day... that's probably not even noticable in SOEs budget. It won't prevent cheating. But it will prevent groups of 20 people cheating in a set place every day. Now imagine what would happen if you employ double the workforce ( two people *gasp* ). Or even a team ? One person per server. Create a /reportAfkAbuse [target] command so the poor guy doesn't even have to look for cheaters. It doesn't get easier than that.
nvoigt wrote:
>>Now I need an answer to the second part of the question - What should be done about it?
>>Assume there is one single guy checking one server per day... that's probably not even noticable in SOEs budget. It won't prevent cheating. But it will prevent groups of 20 people cheating in a set place every day. Now imagine what would happen if you employ double the workforce ( two people *gasp* ). Or even a team ? One person per server. Create a /reportAfkAbuse [target] command so the poor guy doesn't even have to look for cheaters. It doesn't get easier than that.
It's not a reportable offense. The EULA is specifically talking about third-party macros. You can easily verify this by doing a search of the forums for postings by Jeassa with the word 'macro' in them. I've asked on the correspondent forum and gotten the same answer: In-game macros are legal even if they allow unattended play.
The devs might mess with the game mechanics like they did with sampling but they're not going to outright ban someone for using the tools in the game.
Limiting the length of a macro won't do anything as long as there's a way to loop it. In beta, people used recursive aliases to do their looping. The devs responded by first shortening aliases, then making it so an alias couldn't call anothe alias. The player response was to use the /load command to load a long alias, bypassing the length check, then to start using the /ui action command to restart the macro. At that point, they were near launch and had more important things on their plate to worry about.
I suspect that the macro facility was built on top of the low level software that records keystrokes from the client. It may well be that the server CAN'T detect the difference between someone pressing F1 on their keyboard and someone calling /ui action toolbarSlot00 in a macro. If that's the case then there's no way to prevent looping at this point.
The best solution may be something along llines of the "macro allowance" that was proposed, where a player is given a certain number of macros per session. With no knowledge of the underlying software, it's difficult to say how this would work out. As I've alluded to previously, a hotkey is for all intents and purposes a one-line macro. Putting in a lot of code to 1) detect macros, 2) differentiate aliases from built-in slash-commands and 3) imposesome kind of limit on the macros might be impractical from a performance standpoint. The game has considerable lag at times as it is. If shutting down AFKers means degrading performance from the game then I think most of us would rather just live with the AFKers.
Keep the ideas coming at any rate. I'm going to point the devs at this thread so they can see what we're coming up with.