Forums » Suggestions
Until you can explain how removing distance data as I suggested would harm anything that you're whining about, Inco, perhaps you should focus on improving your English grammar and syntax.
I'm not supporting auto-fight plugins of any sort, regardless of how some of you have interpreted my posts here. I certainly have never used any, although I'm quite flattered, Roda, really. I think some of you are mistaking genuine curiosity for sarcasm. I really am interested to know if someone is out there kicking ass with something like this. Roda's accusation confirmed my suspicion that there's a lot of paranoia here. It's easier to think "that jerk is using a hack and that's why he can beat me" rather than "that jerk is better than me and I need to practice more".
However, it's a good point that even if these plugins can't work against the top pilots in the game, they can still mess up the balance for players at a low to medium skill level. I just read pey's impassioned top post and the numerous "+very large number" replies by some very good pilots and assumed everyone thought someone had perfected this in some way as to be dangerous to aces. That seems to be the fear, but not the case.
Anyway, I suppose Lecter's suggestion seems reasonable. I can't think of any other plugins the suggestion would badly mess up. Reducing the resolution to 50m might also work because it would effectively decrease the reaction time of the plugin at combat distances.
However, it's a good point that even if these plugins can't work against the top pilots in the game, they can still mess up the balance for players at a low to medium skill level. I just read pey's impassioned top post and the numerous "+very large number" replies by some very good pilots and assumed everyone thought someone had perfected this in some way as to be dangerous to aces. That seems to be the fear, but not the case.
Anyway, I suppose Lecter's suggestion seems reasonable. I can't think of any other plugins the suggestion would badly mess up. Reducing the resolution to 50m might also work because it would effectively decrease the reaction time of the plugin at combat distances.
The number one aspect of twitch combat is...well... twitch. If you delay the inputs to lua, then it can't twitch for you. You would have to do your own twitching. Manually. The old fashioned way.
The x second delay would not only work for distance control, but also for this "fire on target lock" thing. Unless you can maintain the target lock for x seconds, in which case, go for it.
The simple solution is just to dramatically decrease the sample rate. If this information would only update every 5 seconds, then lua would be using information that was on average 2.5 seconds old.
Seconds count. In fact, at the typical combat speeds and accelerations we are used to, seconds can equal hundreds of meters. twitches are typically fractions of a second.
I do not think that a miner should be able to mine at twitch speeds, but what miner feels he needs to? A delay should have minimal impact on any and all non twitch applications of lua.
As far as lectors suggestion of having distance lose resolution inside 500m, I think this could go along way towards an effective fix. I would prefer it be expanded to 1000m. To strengthen my argument, consider rails. I would hate a railer that could hold just outside of energy range.
The x second delay would not only work for distance control, but also for this "fire on target lock" thing. Unless you can maintain the target lock for x seconds, in which case, go for it.
The simple solution is just to dramatically decrease the sample rate. If this information would only update every 5 seconds, then lua would be using information that was on average 2.5 seconds old.
Seconds count. In fact, at the typical combat speeds and accelerations we are used to, seconds can equal hundreds of meters. twitches are typically fractions of a second.
I do not think that a miner should be able to mine at twitch speeds, but what miner feels he needs to? A delay should have minimal impact on any and all non twitch applications of lua.
As far as lectors suggestion of having distance lose resolution inside 500m, I think this could go along way towards an effective fix. I would prefer it be expanded to 1000m. To strengthen my argument, consider rails. I would hate a railer that could hold just outside of energy range.
roda. think. nerfing distance resolution to some large increment has precisely the same effect as delaying data, without the whole "wtf. why is my computer so slow?" confusion.
losing resolution inside 500m works as well, but as it is a special-cased solution, it is somewhat less intuitive for those who haven't been around for years (and we all know we need more of that type).
losing resolution inside 500m works as well, but as it is a special-cased solution, it is somewhat less intuitive for those who haven't been around for years (and we all know we need more of that type).
It would not be precisely the same. Non combat applications would be less sensitive to a delay.
A delay only breaks twitch applications.
A permanent loss of resolution over a given range is...permanent.
However, I am prepared to support the reduced resolution inside range x, if you will increase range x to 1000m.
A delay only breaks twitch applications.
A permanent loss of resolution over a given range is...permanent.
However, I am prepared to support the reduced resolution inside range x, if you will increase range x to 1000m.
good point that non-combat applications would be more affected by a loss of resolution. however, unless there is some uber-mining plugin that positions you in some great way next to the roid (at which point I'm somewhat tempted to say: fly your own ship!)... I don't see how a lower-resolution fix would affect non-combat plugins in a significant way.
also, 1000m is a dash insane. > 90% of all combat occurs in < 200m. Chopping that area into 4 (50m) or 2 (100m) blocks would effectively destroy the effectiveness of any combat plugin. If some person wants to argue that a plugin that would start backpedaling as soon as I hit 100m would somehow be useful to anyone (as it wouldn't know when to stop unless they got to 150m away, at which point it'd be useless until I hit 100m again)... then do so, but be forewarned that I -- and probably most of VO -- think that person an idiot.
also, 1000m is a dash insane. > 90% of all combat occurs in < 200m. Chopping that area into 4 (50m) or 2 (100m) blocks would effectively destroy the effectiveness of any combat plugin. If some person wants to argue that a plugin that would start backpedaling as soon as I hit 100m would somehow be useful to anyone (as it wouldn't know when to stop unless they got to 150m away, at which point it'd be useless until I hit 100m again)... then do so, but be forewarned that I -- and probably most of VO -- think that person an idiot.
One problem with the reduced resolution tweaks is that it can become more of a pain in the ass for mining. With most mining beams having a limited range within 100m, not having the distance info can make things a lot harder. The sample case I'm thinking of is mining in a bot sector, where one way of avoiding destruction is to constantly orbit your chosen roid within beam range. That would be much harder with reduced resolution.
However, if a simple time delay was put in, most of those problems would go away. 5 seconds is a long time in combat, but if you're just orbiting a roid 5 seconds isn't too terribly bad. And for more boring mining you can more easily sit just inside range, and not have to kiss the roid to be sure.
In fact, I would make it so the distance updates every 5 seconds, and it updates with information from 5 seconds ago. Completely scotches any DC plugins, but won't really affect non-combat applications that much.
I don't think removing the ability to control your ship via aliases would be feasible, because unless I am wrong that would require some significant rewriting of the interface. There are perfectly acceptable fixes that would hopefully take a lot less time and completely resolve the issue.
Actually, now that I think about it, Lecter's solution would actually be pretty good, if it can be accomplished without too much coding. Just player ship data, within 500m, would definitely solve things. However, if it would be too programmer-intensive, and something else would fix the problem for enough less work, I'd say go with that. :)
However, if a simple time delay was put in, most of those problems would go away. 5 seconds is a long time in combat, but if you're just orbiting a roid 5 seconds isn't too terribly bad. And for more boring mining you can more easily sit just inside range, and not have to kiss the roid to be sure.
In fact, I would make it so the distance updates every 5 seconds, and it updates with information from 5 seconds ago. Completely scotches any DC plugins, but won't really affect non-combat applications that much.
I don't think removing the ability to control your ship via aliases would be feasible, because unless I am wrong that would require some significant rewriting of the interface. There are perfectly acceptable fixes that would hopefully take a lot less time and completely resolve the issue.
Actually, now that I think about it, Lecter's solution would actually be pretty good, if it can be accomplished without too much coding. Just player ship data, within 500m, would definitely solve things. However, if it would be too programmer-intensive, and something else would fix the problem for enough less work, I'd say go with that. :)
You guys are mostly looking at flare dodging and energy face to face combat. You are overlooking an important aspect. Evasion.
A human reflex speeds, a trade ship can sometimes escape a fighter, by creating a significant difference in vector of acceleration. But at lua response speeds, this is not practical. Even reducing resolution to 50m increments, a trade ship will never be able to create sufficient acceleration vector difference to effect an escape. A human can react within a fraction of a second, and this can already be deadly. At the acceleration speeds we deal with in combat, the difference between human response speed, and lua response speed, is significant. A lua delay of even 0.5 seconds would be significant.
I do not know how to program in lua. I can learn. If you force me to learn lua, I will make you regret it.
A human reflex speeds, a trade ship can sometimes escape a fighter, by creating a significant difference in vector of acceleration. But at lua response speeds, this is not practical. Even reducing resolution to 50m increments, a trade ship will never be able to create sufficient acceleration vector difference to effect an escape. A human can react within a fraction of a second, and this can already be deadly. At the acceleration speeds we deal with in combat, the difference between human response speed, and lua response speed, is significant. A lua delay of even 0.5 seconds would be significant.
I do not know how to program in lua. I can learn. If you force me to learn lua, I will make you regret it.
I currently make significant use of the HUD telling me how far away people are. Learning to fly more by sight wouldn't be so bad but I'd rather if anything was changed it was the ability of lua to control your movement. Perhaps this isn't reasonable to implement, though.
A time delay might be more friendly than lowered resolution as with the former you could when training see what exact distances to various ships look like.
A time delay might be more friendly than lowered resolution as with the former you could when training see what exact distances to various ships look like.
Hmm... I judge distance by sight, but I use the distance indicator as a tool when training people. It's helpful for newer players to be able to use the indicator until they get a feel for it. Removing that information from the HUD would be detrimental.
I wish I could agree with Maal/Strat re: distance display for player ships, but I cannot. This is yet another example of how, because of script kiddies, we cannot have nice things. A visual indication of distance to target is a great thing -- not unlike ShipPos. But because of plugin using jackasses, we cannot have such things. If it's in LUA, they'll use it; if you strip the data from LUA, they use other programming to take the data off the displayed pixels. It's an all or nothing game because of assholes. You know who you are, so there's no reason for me to call you out all over again.
As for cutting resolution, I think it would be even more confusing than just seeing "PROX" pop up. Of course, if we can treat distance to Ships (at least PC ships) different from distance to roids, then I don't think there's any argument for cutting resolution anyway.
As for decoupling LUA from flight controls, I already gave one example of how it would be an overinclusive fix: we'd give up the distance flight convenience of turbo lock because some fucktard can't focus on flying his ship rather than making it fly itself better for him than it does for everyone else. A few other examples, less 'legitimate' but no more combat oriented, include scripts and binds for auto-jettison and auto-mining, and Spuck's hilarious bots.
What it really comes down to, though, is this. Automating ship thrusters and even weapons (chain fire) and whatnot isn't really what strikes me as an issue here; I don't see the same value in gutting binds that allow you to fire your weapons in synch with one another without having more fingers than a normal human being that I see in gutting a bind that instantly fires your weapons for you any time you're within X meters of a target and the AA pipper is yellow. It's the automatic linking of those flight controls to combat-useful information that gives problematic advantages. If the computer wants to fire gun 2 .05 seconds after gun 1 fires, meh; if it can "know" a better time to fire those guns relative to where an opponent is, that's a problem. Ditto in distance control; I don't care much if someone wants to have a locked "back" (or any other) thrust key to save their fingers some fatigue. It's the automatic linkage of changing thrust relative to opponent position that is the problem.
As for cutting resolution, I think it would be even more confusing than just seeing "PROX" pop up. Of course, if we can treat distance to Ships (at least PC ships) different from distance to roids, then I don't think there's any argument for cutting resolution anyway.
As for decoupling LUA from flight controls, I already gave one example of how it would be an overinclusive fix: we'd give up the distance flight convenience of turbo lock because some fucktard can't focus on flying his ship rather than making it fly itself better for him than it does for everyone else. A few other examples, less 'legitimate' but no more combat oriented, include scripts and binds for auto-jettison and auto-mining, and Spuck's hilarious bots.
What it really comes down to, though, is this. Automating ship thrusters and even weapons (chain fire) and whatnot isn't really what strikes me as an issue here; I don't see the same value in gutting binds that allow you to fire your weapons in synch with one another without having more fingers than a normal human being that I see in gutting a bind that instantly fires your weapons for you any time you're within X meters of a target and the AA pipper is yellow. It's the automatic linking of those flight controls to combat-useful information that gives problematic advantages. If the computer wants to fire gun 2 .05 seconds after gun 1 fires, meh; if it can "know" a better time to fire those guns relative to where an opponent is, that's a problem. Ditto in distance control; I don't care much if someone wants to have a locked "back" (or any other) thrust key to save their fingers some fatigue. It's the automatic linkage of changing thrust relative to opponent position that is the problem.
they use other programming to take the data off the displayed pixels.
learn to program before you say such stupid things.
such reading off the pixels would require some serious shit taking place outside the VO environment (and I'm not even sure if outside scripts can communicate with scripts running in VO without writing to disk and then reading from it constantly, which would consume way more resources than it's worth). Edit: not only would it consume resources and possibly lag your client (not to mention most assuredly trash your HD far faster), it would also induce a somewhat non-trivial delay due to what is sure to be a shitton of near-constant, non-serial IO.
learn to program before you say such stupid things.
such reading off the pixels would require some serious shit taking place outside the VO environment (and I'm not even sure if outside scripts can communicate with scripts running in VO without writing to disk and then reading from it constantly, which would consume way more resources than it's worth). Edit: not only would it consume resources and possibly lag your client (not to mention most assuredly trash your HD far faster), it would also induce a somewhat non-trivial delay due to what is sure to be a shitton of near-constant, non-serial IO.
Eat a fat one, Atice. I don't need to program to know that one can (and people have) take data off the game's visual display and use it to drive automation of in-game functions. I'm just so very sorry if I didn't phrase the steps for doing so to your liking; but what happens is as I describe. And yes, outside scripts can communicate with both VO interface controls and VO scripts just fine.
So then any game which allows plugins is doomed because people can take visual data from the screen and use it in their plugins. Interesting that there has been no public outcry about this before.
You're not old enough to remember the aim-bots so, like all noobs and other little children, you're forgiven for being a blustering ignorance.
I agree there's no getting rid of it entirely; for example, the AA pipper will always be open to a hack that way, even if the LUA change event is stripped out. But that's a heck of a lot harder to track than is a number displayed in a fixed portion of the HUD.
I agree there's no getting rid of it entirely; for example, the AA pipper will always be open to a hack that way, even if the LUA change event is stripped out. But that's a heck of a lot harder to track than is a number displayed in a fixed portion of the HUD.
The solution is to sandbox shit better (say, only allow reads from files at login or some such), rather than strip the HUD. Again, learn to program.
Making lua response speeds or sample rates slower than a human would not have to over handicap training. They are newbs. They are already moving slow. A 0.5 second delay would be practically unnoticed by them. By the time they start to notice a 0.5 second delay, you know you have trained them well.
Aticephyr: Please learn to program before you advise others to learn how to program. I have created programs that did read pixels from the screen. And yes, you are partially correct in that the simple way would be to use vo's built in screen dump to disk and then use those images. You are, however, overlooking the fact, that I would probably find a way to route those images directly to a ram disk, which would operate at ram speeds. That, or I could just intercept the write commands in Direct-X, or actually just read the pixels strait from the video card. I do know how to program, and while I am not intimately familiar with intel architecture, it is still just a computer.
Aticephyr: Please learn to program before you advise others to learn how to program. I have created programs that did read pixels from the screen. And yes, you are partially correct in that the simple way would be to use vo's built in screen dump to disk and then use those images. You are, however, overlooking the fact, that I would probably find a way to route those images directly to a ram disk, which would operate at ram speeds. That, or I could just intercept the write commands in Direct-X, or actually just read the pixels strait from the video card. I do know how to program, and while I am not intimately familiar with intel architecture, it is still just a computer.
Roda: See my sandboxing comment.
Note: I'm not against something like a 0.5s sampling delay, or even 1s sampling delay for that matter. Also, woots for getting back on topic.
Note: I'm not against something like a 0.5s sampling delay, or even 1s sampling delay for that matter. Also, woots for getting back on topic.
Atice: one should not have to know how to program to play a game, or get the most out of said game. that is stupid. sry!
this is the suggestions forum, not LERN2LUA forum.
if i have to learn LUA to play this game effectively, or get my point across on this forum, i'm sorry, but i will cancel my subscription immediately.
na'mean?
i know of a player that uses a plugin to automatically turn AA on at a certain set distance. i know who exactly who it is, but i am not going to use this thread to publicly "call them out" to better my own standing in this argument. they know who they are, and know that i have always found it to be weak. it's not that hard to bind AA to an easily reachable key.
i, like i said before, use VFR (sight and experience) to tell where my ship is in relation to my target, but i can understand that a lot of people use the customhud or whatever and have the distance displayed right in front of them. that's cool, and it's too bad that some people use that to let a script fly their ship for them, instead of using the data with their own brain, and their brain's ability to react.
i have been pretty terrible in pvp as of late, and you know what? that is my fault, and i accept that, but knowing that i could just install a few plugins to help me get back on track makes my skin crawl - in a game that has always seemed to me to be the antithesis of this.
is it in any way possible to remove ship control from LUA entirely? without massively fucking up the AI? i would prefer that people could continue using the distance meter if that's what they like, but if it can be used to fly your ship (at least in part)for you, i'm sorry, but it's not what this game was intended to be. or at least from my understanding of the dev's "vision" or whatever you want to call it.
i really shouldn't post in threads like this before drinking coffee, i guess...
/me fires up espresso maker
this is the suggestions forum, not LERN2LUA forum.
if i have to learn LUA to play this game effectively, or get my point across on this forum, i'm sorry, but i will cancel my subscription immediately.
na'mean?
i know of a player that uses a plugin to automatically turn AA on at a certain set distance. i know who exactly who it is, but i am not going to use this thread to publicly "call them out" to better my own standing in this argument. they know who they are, and know that i have always found it to be weak. it's not that hard to bind AA to an easily reachable key.
i, like i said before, use VFR (sight and experience) to tell where my ship is in relation to my target, but i can understand that a lot of people use the customhud or whatever and have the distance displayed right in front of them. that's cool, and it's too bad that some people use that to let a script fly their ship for them, instead of using the data with their own brain, and their brain's ability to react.
i have been pretty terrible in pvp as of late, and you know what? that is my fault, and i accept that, but knowing that i could just install a few plugins to help me get back on track makes my skin crawl - in a game that has always seemed to me to be the antithesis of this.
is it in any way possible to remove ship control from LUA entirely? without massively fucking up the AI? i would prefer that people could continue using the distance meter if that's what they like, but if it can be used to fly your ship (at least in part)for you, i'm sorry, but it's not what this game was intended to be. or at least from my understanding of the dev's "vision" or whatever you want to call it.
i really shouldn't post in threads like this before drinking coffee, i guess...
/me fires up espresso maker
TBF, you're better than you give yourself credit for. I don't think any of the current combat plugins would make you better. They would only hurt you. I fought Ritter today while he was using CombatAssist. I was not impressed at all. If anyone is really having trouble beating someone who is using this plugin, I can teach you how to easily overcome it.