Forums » Bugs
bot countermeasures + radar commands
re: radar breaking functionality for idlers
under normal circumstances, sensor log no longer gives information, radar breaks and you cant target anything.. even a roid. but if you group with a capship: sensor log remains off.. radar returns, all targets become hostile/red, and you can target again.
so despite there being no sensor log, you can technically radarprevnearestenemy and parse the target data. which brings me to the next/prev targeting, which i understand should be a post of its own BUT..
it doesnt seem to work intuitively, or is broken.. for example, RadarNextNearestEnemy will remain only with the nearest target.. where its Prev variation will cycle all targets as expected.
..and some of the targeting functions behave differently depending on how you use them. so for example, directly from the commandline or bound they will behave in one way, then executed via code using gkexecutecommand() they will behave differently yet again..
an example would be RadarNextNearestPowerup, when bound it will cycle through drops, but when executed it hangs on the first item. its Prev variant however has no such limitation, it behaves as expected when executed.
in short, all prev and next commands i would think should cycle through all available targets.. regardless of which you use or how they are initiated.
under normal circumstances, sensor log no longer gives information, radar breaks and you cant target anything.. even a roid. but if you group with a capship: sensor log remains off.. radar returns, all targets become hostile/red, and you can target again.
so despite there being no sensor log, you can technically radarprevnearestenemy and parse the target data. which brings me to the next/prev targeting, which i understand should be a post of its own BUT..
it doesnt seem to work intuitively, or is broken.. for example, RadarNextNearestEnemy will remain only with the nearest target.. where its Prev variation will cycle all targets as expected.
..and some of the targeting functions behave differently depending on how you use them. so for example, directly from the commandline or bound they will behave in one way, then executed via code using gkexecutecommand() they will behave differently yet again..
an example would be RadarNextNearestPowerup, when bound it will cycle through drops, but when executed it hangs on the first item. its Prev variant however has no such limitation, it behaves as expected when executed.
in short, all prev and next commands i would think should cycle through all available targets.. regardless of which you use or how they are initiated.
in short, all prev and next commands i would think should cycle through all available targets.. regardless of which you use or how they are initiated.
So, I don't remember the specifics of when everything was changed, but if I recall, this was adjusted because newbies were hitting "x" more than once and then getting progressively further away, and no longer able to easily select the hostile that was nearest to them.
So, basically, it used to work as you described, and then it was hacked at some point because of a user experience problem.
Which, essentially, gets into the contention between an advanced user and a new user:
- An advanced player will say "Well, just go the other way with Prev".
- But, the new user doesn't know how, and is just trying to figure out how to "target stuff".
I'm not saying this was an ideal solution, but it is "functioning as intended" and not exactly a Bug. I'm not against changing it, or having some alternative set of functions, but I'm probably not going to change the default behaviour of "x".
In terms of commands behaving differently whether they're bound or executed as a function, I can't speak to that, it doesn't make much sense to me.
So, I don't remember the specifics of when everything was changed, but if I recall, this was adjusted because newbies were hitting "x" more than once and then getting progressively further away, and no longer able to easily select the hostile that was nearest to them.
So, basically, it used to work as you described, and then it was hacked at some point because of a user experience problem.
Which, essentially, gets into the contention between an advanced user and a new user:
- An advanced player will say "Well, just go the other way with Prev".
- But, the new user doesn't know how, and is just trying to figure out how to "target stuff".
I'm not saying this was an ideal solution, but it is "functioning as intended" and not exactly a Bug. I'm not against changing it, or having some alternative set of functions, but I'm probably not going to change the default behaviour of "x".
In terms of commands behaving differently whether they're bound or executed as a function, I can't speak to that, it doesn't make much sense to me.
cool if it works it works, its fine as is i just thought something might be acting funny.