Forums » Suggestions
TBF: I saying people should learn to program before they express concern (or more hilariously fixes for) potential "hax" which they deem an immanent threat. That is all.
knowing that i could just install a few plugins to help me get back on track...
I seriously disagree with that statement. Your combat level/experience is far beyond the point where a plugin would help you get back on track. I hear your point though, and despite the fact that there are a lot of us who don't think the plugins really make a difference, we're still here and proposing non-detrimental ways to nerf them.
knowing that i could just install a few plugins to help me get back on track...
I seriously disagree with that statement. Your combat level/experience is far beyond the point where a plugin would help you get back on track. I hear your point though, and despite the fact that there are a lot of us who don't think the plugins really make a difference, we're still here and proposing non-detrimental ways to nerf them.
Strat when we fought I had only tried it once using the same settings when I fought Pey. I'm sure if someone actually toys around with combat assist and tweaks it a bit, they could benefit greatly from it. Using it my first time made dodging hell of a lot easier, the only problem was lining up shots. I'm sure if I messed around with it, I could fix that problem.
I don't understand how so many people can lack in the common knowledge department. It's simple, two outcomes will come out of getting rid of these plug-ins that alter flight:
A) Nothing happens because no one really used the plug-ins to begin with.
B) Some players PvP skills go down without the aid of these plug-ins.
The people who are opposed of getting rid of these flight-altering programs are either trolls, or they are worried that their little plug-ins are going to be taken away.
I don't understand how so many people can lack in the common knowledge department. It's simple, two outcomes will come out of getting rid of these plug-ins that alter flight:
A) Nothing happens because no one really used the plug-ins to begin with.
B) Some players PvP skills go down without the aid of these plug-ins.
The people who are opposed of getting rid of these flight-altering programs are either trolls, or they are worried that their little plug-ins are going to be taken away.
I'm not against getting rid of them. I'm just worried about breaking other legitimate useful stuff in the process. I'm sure a good compromise can be reached.
lol ritter. some of us want the devs working on the economy instead of spending their time fixing things which we don't consider a problem.
edit: goddamn it Strat. stop posting RIGHT before I do. :p
edit: goddamn it Strat. stop posting RIGHT before I do. :p
Like I said, your either trying to troll because you have to have the opposing viewpoints of people you dislike, even if they make a valid point, or you use the plug-ins.
Heh. You're creating an argument where there doesn't have to be one, favrewebelieve. We don't mind getting rid of the plugins as long as it doesn't break a bunch of other useful legitimate stuff. The issue is that you're paranoid. A whole bunch of people here are thinking that the aces are using plugins for combat. Only the aces know for sure that they indeed do not use plugins, so they find this entire thing quite amusing.
Ritter... you're going to make me quote MYSELF to show you that your binary is a false one:
despite the fact that there are a lot of us who don't think the plugins really make a difference, we're still here and proposing non-detrimental ways to nerf them
What I dislike is people trying to super-nerf things that would kill legitimate plugins (1000m intervals) or game mechanics (removing HUD info). I also dislike people accusing players they can't beat of using plugins.
I'm not trolling; I'm trying to keep the discussion sane and informed.
despite the fact that there are a lot of us who don't think the plugins really make a difference, we're still here and proposing non-detrimental ways to nerf them
What I dislike is people trying to super-nerf things that would kill legitimate plugins (1000m intervals) or game mechanics (removing HUD info). I also dislike people accusing players they can't beat of using plugins.
I'm not trolling; I'm trying to keep the discussion sane and informed.
that would kill legitimate plugins (1000m intervals)
If it applies (in both LUA and HUD) only to the distance readings on ships (rather than on roids), as I and others proposed, how would it effect any legitimate scripts/plugins? The only potential whine is you have to judge distance by sight and experience rather than a precise, real-time number that's spoon fed to you. In that case, boofuckinghoo.
If it applies (in both LUA and HUD) only to the distance readings on ships (rather than on roids), as I and others proposed, how would it effect any legitimate scripts/plugins? The only potential whine is you have to judge distance by sight and experience rather than a precise, real-time number that's spoon fed to you. In that case, boofuckinghoo.
The people who are paranoid that the good pilots who can beat them are doing so with plugins are more willing to break other stuff to "fix" what they see as a major problem. The good pilots who are fully aware that they don't use combat plugins are less willing to break stuff to fix a problem that they know doesn't really exist, at least not to the extent that some people here think it does.
It's a matter of degree. I'd prefer not to lose the the HUD distance indicator, but adding a slight delay, enough to eliminate any advantage a plugin might have over human response time, maybe 2 seconds, seems somewhat reasonable. Again, I don't use the distance indicator. I judge by eye, but some people use the indicator (like Maalik) and it's very useful when training new players.
It's a matter of degree. I'd prefer not to lose the the HUD distance indicator, but adding a slight delay, enough to eliminate any advantage a plugin might have over human response time, maybe 2 seconds, seems somewhat reasonable. Again, I don't use the distance indicator. I judge by eye, but some people use the indicator (like Maalik) and it's very useful when training new players.
strat will you stop turning this into a personal thing no one in this thread has accused anyone of using said plugins to keep the topic on hand civil. I have been accused of using an aim bot by newbs I have heard other people be accused of using combat assist you would think that having combat assist removed would bring some sort of validation to those who have real skill. So please stop implying that lecter tbf roda myself nahin and others who have voiced objection to this plugin are lesser players suffering from parinoia.
I use the distance indicator, and am very opposed to delaying that data to the HUD (via plugin is cool though, as long as the documentation reflects the fact).
@pey: no one may have accused him directly. but many have indirectly. I can pull the quotes for you if you'd like.
@pey: no one may have accused him directly. but many have indirectly. I can pull the quotes for you if you'd like.
No Dr. Lecter, your solution is not a solution, its creating more problems in order to address one specific problem from the wrong angle. There are a number of combat assist like plugins possible or in existance that use other types of hud information, at least two of which have been previously posted in this thread.
Earlier you raised objection to output side fixes by the incorrect argument that it would break turbo binds. It would only affect infinite turbo binds which are yet another type of combat assist plugin when you think about it. (Combat avoidance in this case)
All of these combat assist type problems, if they are problems, can be addressed simply by filtering the lua plugin api call: gkinterface.GKProcessCommand. No need to restrict or modify hud information.
Earlier you raised objection to output side fixes by the incorrect argument that it would break turbo binds. It would only affect infinite turbo binds which are yet another type of combat assist plugin when you think about it. (Combat avoidance in this case)
All of these combat assist type problems, if they are problems, can be addressed simply by filtering the lua plugin api call: gkinterface.GKProcessCommand. No need to restrict or modify hud information.
I am opposed to decreasing lua's physical dimension resolution because I think there could be valid uses for non combat applications that may depend on this information.
I am opposed to decreasing lua's access to outputs (ship control) or player input because I think lua could be useful to create improved human to flight control interfaces. See discussions on joystick like control behavior from mouse inputs, etc..
I am opposed to using lua to effect responses beyond human capability. That you can make a bot that will shoot, dodge, or turbo for you is not the problem. The problem is when it can react to external events faster than a human can. I have no problem if I run across a scene where automated combats bots are deep in combat... in slow motion. As long as I, as a human, can compete.
I consider a pluging that will allow a valk to always catch any other ship a problem. This is actually difficult to do by hand. Just ask fluufy, who I spent who knows how long trying to tag in ctf. With a plugin, all you have to do is consistently point your ship at the target. A valk with such a plugin will not fail to catch almost any other ship in the game.
I have considered the options presented here. Many options have merit. I have attempted to reduce the problems to the greatest common factor, and my assessment is lua's ability to acquire data at precision accuracy, process that data, and apply outputs faster than a human can, is the fundamental root cause of a majority of problems mentioned in this thread. Since I do not consider slowing lua's processing ability to a stand still a viable solution, and I do not want to limit it's access to outputs, all that remains is to limit it's access to external information. Of the available limits to choose from, a time delay or sample rate limiter strikes me as the least intrusive on other applications, and the most relevant to allowing a human to compete.
I actually suggest doing both a sample rate limit, and a delay, so that for a given ship distance, the game only needs to remember four values. The real value of distance, which the game requires to display the ship onscreen. A sample value recorded over 0.5 seconds ago, a sample value record less than 0.5 seconds ago, and a 0.5 second countdown timer, to tell the game when to record a new value, and shift the samples in the queue. This should help minimize programming for the devs, and reduce processor load for the local computer. Lua would only have access to the sample recorded over 0.5 seconds ago, resulting in an average sample delay of 0.75 seconds, for any random query of said variable, or 0.5+ seconds for systematic polling of said variable.
I am opposed to decreasing lua's access to outputs (ship control) or player input because I think lua could be useful to create improved human to flight control interfaces. See discussions on joystick like control behavior from mouse inputs, etc..
I am opposed to using lua to effect responses beyond human capability. That you can make a bot that will shoot, dodge, or turbo for you is not the problem. The problem is when it can react to external events faster than a human can. I have no problem if I run across a scene where automated combats bots are deep in combat... in slow motion. As long as I, as a human, can compete.
I consider a pluging that will allow a valk to always catch any other ship a problem. This is actually difficult to do by hand. Just ask fluufy, who I spent who knows how long trying to tag in ctf. With a plugin, all you have to do is consistently point your ship at the target. A valk with such a plugin will not fail to catch almost any other ship in the game.
I have considered the options presented here. Many options have merit. I have attempted to reduce the problems to the greatest common factor, and my assessment is lua's ability to acquire data at precision accuracy, process that data, and apply outputs faster than a human can, is the fundamental root cause of a majority of problems mentioned in this thread. Since I do not consider slowing lua's processing ability to a stand still a viable solution, and I do not want to limit it's access to outputs, all that remains is to limit it's access to external information. Of the available limits to choose from, a time delay or sample rate limiter strikes me as the least intrusive on other applications, and the most relevant to allowing a human to compete.
I actually suggest doing both a sample rate limit, and a delay, so that for a given ship distance, the game only needs to remember four values. The real value of distance, which the game requires to display the ship onscreen. A sample value recorded over 0.5 seconds ago, a sample value record less than 0.5 seconds ago, and a 0.5 second countdown timer, to tell the game when to record a new value, and shift the samples in the queue. This should help minimize programming for the devs, and reduce processor load for the local computer. Lua would only have access to the sample recorded over 0.5 seconds ago, resulting in an average sample delay of 0.75 seconds, for any random query of said variable, or 0.5+ seconds for systematic polling of said variable.
Roda accused me, but I don't see where I got defensive about it anywhere. I didn't accuse you specifically of being paranoid, pey, but I can tell you that some people who have posted in this thread indeed believe that people are beating them by using plugins. That belief is increasing the number of things they are willing to break to fix the problem.
I'm curious, what legitimate plugins are there that manipulate the ship's thrusters? I've never seen a plugin that provided an improved flight control interface, or anything like that. Get rid of that ability, make everything closer than 500m show "PROXIMITY WARNING", and be done with it.
It would only affect infinite turbo binds which are yet another type of combat assist plugin when you think about it. (Combat avoidance in this case)
As you have now proved yourself too retarded to live, please cease posting (in broken English) at once and find yourself an overhead beam, a chair, and a length of piano wire. TYIA.
As you have now proved yourself too retarded to live, please cease posting (in broken English) at once and find yourself an overhead beam, a chair, and a length of piano wire. TYIA.
Getting rid of thruster control is reasonable, but people could still write programs to control the ship without the API. You would just be making the plugins more exclusive. The divide between those who can code and those who can't would just be even bigger.
I have yet to see anyone who has a plugin listed on vo-wiki or in the VOUPR to voice how taking combat assists ability to well assist in combat out of game is going to ruin their plugin or other things. So unless VPR has some super secret plugins that depend on this information it is becoming a moot point and a straw man.
I'd prefer not to lose the the HUD distance indicator, but adding a slight delay, enough to eliminate any advantage a plugin might have over human response time, maybe 2 seconds, seems somewhat reasonable.
Strat, if it's enough of a delay to render automatic reliance on the variable ineffective, what makes you think it's somehow a valuable piece of information for the human brain to be processing? Either the distance number is right enough to be helpful, or it's not. If it's not, you're actually fucking over inexperienced players worse than if you just forced them to eyeball it.
Strat, if it's enough of a delay to render automatic reliance on the variable ineffective, what makes you think it's somehow a valuable piece of information for the human brain to be processing? Either the distance number is right enough to be helpful, or it's not. If it's not, you're actually fucking over inexperienced players worse than if you just forced them to eyeball it.
Pey, we're talking about messing with the actual distance indicator on the HUD as a solution.
Lecter, you're right. Again, I wouldn't personally be affected by completely breaking the distance indicator at close distances or whatever, but other people would. Some people here think it's worth it, some don't. That's what the debate is.
Lecter, you're right. Again, I wouldn't personally be affected by completely breaking the distance indicator at close distances or whatever, but other people would. Some people here think it's worth it, some don't. That's what the debate is.