That is broken as fuck allowing that command outside cheats. I brought it to the attention of the devs and matso made a bug report.
EDIT: well now actually testing it it doesn't completely do what i thought it did. It doesn't reveal anything to commander. It only helps to players on the field.
Its more does nav_debug really even provide that much information? Its important to note that nav_debug is an engine level command (not lua). Its only really even notably abusive for a commander. Originally when it was added this problem didn't exist. You can find the same information out using a waypoint. It can also actually produce false positives, so its not foolproof.
Sure any commands that can be used to grant an clear and abuseable advantage should be blocked (like net_lag, and probably nav_debug). However at a certain point you need to realize that the small advantage which a command could grant is outweighed by the advantages is offers for use in debugging client gameplay. Should the devs restrict the maxfps command because it can be used to increase rof? Should certain render commands be disabled because they can improve FPS/allow you to see better?
Its hardly the kind of issue people are making it out to be...
That you are even coming down on the other side of these issues is severely off putting.
I am not.
You really need to read my posts more thoroughly and stop putting words in my mouth. I don't know why you keep putting up a strawman..
To be crystal clear once again : I support and would love for ALL methods of location exploits to be fixed. But knowing that this is a goal that has been attempted across years now with a full NS2 dev team.. and hasn't been reached, I really don't get the big noise and fuss about this one single command all of a sudden?? Granted, it is more end user friendly than others.. but fixing it will not stop locational exploits.
I really wish to drive this point home, because some championing this change just don't seem to be absorbing this fact:
As @xdragon and myself have been saying there are many more methods, and all have attempted to have been fixed - many actually have been... only to come back later. With developer resources for NS2 being at an all time low, it is not probable that all of a sudden we can now magically permanently fix the plethora of means to determine structure locations once and for all.
Does this mean that nav mesh shouldn't be behind a cheat command? No.
Does this mean that once this is done, the ability to use an exploit to determine structure location will be impossible? No.
Do we have the resource and means to remove all forms of location exploits? No.
Can all forms of location exploits be put behind a cheat command? No.
So does the nav_Debug deserve the tone and fuss being currently made about it? No.
@IronHorse
This thread is so utterly frustrating. I want to step back from the particulars and talk about the meta that I find frustrating.
To begin with, on the "whack-a-mole" issue. I agree that's a pretty appropriate way to describe what has happened with regard to these bugs. To me, it suggests a systemic failure to either take ownership of bugs or to test bugfixes and probably some communication problems which add up to what we might term "QA maturity". I'm not trying to place blame, only to bring about improvements. Consider how much time UWE has spent trying to fix some of these bugs, and now it seems all for naught. This is should be a case study for UWE to improve their processes for Subnautica. I know you're probably not the right guy to talk to about this but you're kind of defending the lack of action here and imho it's only to the detriment of NS2 as a product and UWE as a studio.
Next, paying attention to the community being divided on this is silly. The community's goals are not UWE's goals. I see a lot of parallels between this thread and the problem that lead to the introduction of ghost structures. Using armouries to block exits and kill Onos was intensely divisive to the community. Some people could see that it was excessively harsh on the player who happened to be the Onos while others looked at the game on the whole and said armoury blocking was a 'valid strategy'. Ultimately, if armoury blocking was necessary for game balance that points to some bigger problems. Alternatively, if it was necessary for strategic depth that is another broader problem. Where I see parallels is that they are both caused by emergent gameplay. Emergent gameplay is liked because it enriches the game, while others might like or dislike the particular outcomes. Therefore you get mixed feedback. The *real* problem is that the developer hasn't factored the emergent gameplay outcomes in to the design or balance and the results can have compound effects on other parts of the game design and balance (eg: level designers making doorways relative to the size of armouries). The best way forward is to take ownership of the emergent gameplay and reintroduce it as a balanced feature. In the case of armoury blocking, giving the marines access to something like bonewall would be comparable. The cost/timing etc can be balanced in isolation and the Onos player doesn't feel cheated. In the case of hive detection, we already have scan.
Another point is that NS2 is riddled with tricks which make those in the know more effective at the game. Of course they will want those features to stay. And of course that makes the game have a more difficult learning curve for new players. Where do you draw the line? Well, I think its a pretty clear sign when some of those tricks seem less like intended game design and more like hacks and exploits.
Lastly, this is pretty minor but when you talk about hive location being a known quantity in the first 10 seconds of the game, you're using information already polluted by these bugs. Aliens don't try to hide their starting hive because it's so easy to overcome. Nobody has ever evaluated the benefit of keeping their starting hive secret because there has never been an opportunity. Are there some strategies involving shade hive first that could be of use? Just occasionally I play a pub game where marines don't seem to figure out where the starting hive is for perhaps 2 or 3 minutes and that's enough to make me wonder. Is that overcome by scan anyway? Well sure, but that's in response to choices made by the commanders. Others discount the value in hiding hive location because most maps have fixed/relative hive locations. That's also kind of short sighted because it prepositions homogenous games. "Because hive locations are rarely secret, there's no merit in having hive locations be occasionally secret". My arguments here are kind of weak, but they're the counterpoint to the respective arguments which are also quite weak.
As clearly stated already: Because its not the only means or method, there's a plethora of these exploits/tricks and despite attempts to fix them they continue to return for over the course of years. Most are reported already in our system.
So okay, sure.. we make nav mesh cheats only (which I am not opposed to obviously)... now what about the 5 other means, hmm?
Just to be clear, are you saying you want the community to come up with solutions to the bugs or was this rhetorical?
Edit: I can see from your last post I'm somewhat preaching to the choir and that it's a matter of resources. I get it. Perhaps you weren't so much 'defending UWE's lack of action' as 'being realistic and open to the community'.
MouseThe Lighter Side of PessimismJoin Date: 2002-03-02Member: 263Members, NS1 Playtester, Forum Moderators, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow
edited February 2014
@IronHorse I believe elodea's main point of concern is less that nav_debug can be used as an exploit, but more that as a command that has no reasonable use outside of a development environment, it should be put behind dev 1. The fact that nav_debug can be used as an exploit only serves to underline his concern. A similar argument can be made about other only-useful-in-a-development-environment commands that aren't behind dev 1, irrespective of their potential use as exploits.
(on a side note, I'm aware of at least two other only-useful-in-a-development-environment commands that aren't behind dev 1 that could be used as means to exploitation)
That you are even coming down on the other side of these issues is severely off putting.
I am not.
You really need to read my posts more thoroughly and stop putting words in my mouth. I don't know why you keep putting up a strawman..
To be crystal clear once again : I support and would love for ALL methods of location exploits to be fixed. But knowing that this is a goal that has been attempted across years now with a full NS2 dev team.. and hasn't been reached, I really don't get the big noise and fuss about this one single command all of a sudden?? Granted, it is more end user friendly than others.. but fixing it will not stop locational exploits.
I really wish to drive this point home, because some championing this change just don't seem to be absorbing this fact:
As @xdragon and myself have been saying there are many more methods, and all have attempted to have been fixed - many actually have been... only to come back later. With developer resources for NS2 being at an all time low, it is not probable that all of a sudden we can now magically permanently fix the plethora of means to determine structure locations once and for all.
Does this mean that nav mesh shouldn't be behind a cheat command? No.
Does this mean that once this is done, the ability to use an exploit to determine structure location will be impossible? No.
Do we have the resource and means to remove all forms of location exploits? No.
Can all forms of location exploits be put behind a cheat command? No.
So does the nav_Debug deserve the tone and fuss being currently made about it? No.
... /facepalm
please let me try and put this as simply as humanly possible so you don't get anymore lost
I couldn't care less about actual bug fixes at this point in the discussion. Put the developer commands behind dev 1 where they belong. Having other means of doing location exploits is not the excuse a rational or sane person gives for lack of action regarding nav_debug. wow. And this goes likewise for all other commands that are not behind dev/cheats 1.
If you really were seeing this point, I shouldn't be seeing as many words from you as I am.
Only commands that provide non-exploitative feedback specifically for the user during the normal course of a game should stay out of cheats/dev. r_stats, net_stats, debugspeed, and whatever else that i missed.
If you would read more thoroughly, you would have seen that I already posted why i think trying to fix starting location exploit in particular is largely irrelevant. This is really now about console commands not being where they should be.
After three very clearly defined posts repeating the exact same thing, if you still don't follow why this thread issue needed to be seperated into different sub-components and treated differently, then I can only leave it in God's hands
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
edited February 2014
I know your last sentence communicated that you understand a lot of what is going on.. But i still feel obligated to chime in on some things for clarification's sake.
To me, it suggests a systemic failure to either take ownership of bugs or to test bugfixes and probably some communication problems which add up to what we might term "QA maturity". I'm not trying to place blame, only to bring about improvements. Consider how much time UWE has spent trying to fix some of these bugs, and now it seems all for naught.
Let's take the Rifle jam bug as an example here..
The developers spent an un godly amount of time attempting to fix this bug. I believe over 5 developers have now had a crack at it. That speaks volumes for the reality of bug squashing in general considering the talent at hand on their staff. Some features like onos stomp almost were cut entirely as a result of this bug. It's gotten better, sure, but it is the oldest and most stubborn bug and it still exists today. At one point when I inquired about it after release, Brian said something to the effect "I cannot work on that bug anymore for the sake of my own mental health."
In instances like these, would you say there is a systemic failure occurring in our QA process? Because I would not.
I cannot see what else could be done. These location exploits are very similar to this situation. They have not gone unnoticed, they have been worked on, many have been fixed and quite a few have returned.. And some have been given up on.
Just one example was the tech point showing up as "damaged" to any commander from a hive dropping - it was a huge one that was fixed numerous times after much effort.
when you talk about hive location being a known quantity in the first 10 seconds of the game, you're using information already polluted by these bugs.
Actually I am not. ;-)
Try it yourself - even in the largest of maps I can walljump far enough to justify rine contact in time, (or deduce from no contact) and if there is at least one other skulk doing their job on my team, on the other side of the map, then we've narrowed down their start. Conversely if you're a marine you should be able to deduce alien start based on your first contact. Being used to the timings helps assessing this obviously.
@mouse
Sure and this is why I agree with it.. It has minimal impact to make this change. (despite the times it's come in use for me during pub games to determine why AI was stuck or why I couldn't place a GT) so go for it if it makes people happy.
But getting up in arms about it and arguing for it to be placed behind the cheats command *as if it's going to suddenly stop locational exploiting* is what I had a problem with.
Even if those other exploitable commands you know were to be restricted to cheats only, there's still multiple other methods which cannot be stopped in such a manner due to their very nature (they are not commands) and have been attempted to be fixed and failed in the past.
Lastly, thank you khyron for realizing I am just trying to explain things in a practical and informative matter to everyone, instead of blindly defending an exploit..
There's just sooo many things that are difficult to understand and even explain until you get to witness and experience the process of development. Almost every PT I know that's joined gets their eyes opened and then typically extends their level of patience and understanding as a result. Trying to convey to anyone who hasn't experienced this, why bug X isn't fixed yet, becomes quite the challenge as they aren't going to be easily convinced. I once even wrote a blog about this phenomenon in order to give a viewpoint from this side of the fence (so to speak) but ended up scrapping it because in the end I realized it was the personal interactive experience and effort that really drives the point home.. Not someone else's words.
Ok after skimming quickly through this thread I can see where the issue is... If we allow the debug_nav option outside of cheats why not let all cheats outside of cheats? I mean, am I the only person who has wished they could go "god mode" (Darwin Mode) at the sight of an onos charging you, or up the damage so that it only takes 1 bullet to kill the hive? Obviously to make everyone happy and eliminate the exploit of dropping med packs on top of hives to find the start we should instead be allowed to drop CC's and Hives outside of the map so that no one can find it. This would solve all problems in my opinion. Also I would like to be able to place phase gates and gorge tunnels inside of the ready room so that people can join the game quickly regardless of team balance.
This is really now about console commands not being where they should be.
*reads title of thread *
*reads OP mentioning other forms of exploit like medpacks*
No, it is not.
If you wish to hijack it or limit your responses to just that category that's your choice, but I don't have to follow suit. I responded to everything at hand. Which i consider to be highly relevant. (and so did the OP I guess)
Having other means of doing location exploits is not the excuse a rational or sane person gives for lack of action regarding nav_debug
Point me to where I support lack of action on this issue, please. Give *some* modicum of evidence of your straw man in one of your posts at least..
Else, you're arguing with yourself elodea.
The only thing I have defended is the importance that has been placed on this singular command. This is because fixing this one does not fix the issue..
This is something worth mentioning because the entire reason behind suggesting a fix in such a loud/important manner was supposedly due to its potential for exploit, not because it was a benign command.
If this command made your screen go black and that was the end of it, you @Elodea would not be advocating so thoroughly to hide the command behind cheats.
So can we end this (nav_debug specific) discussion now already?
MouseThe Lighter Side of PessimismJoin Date: 2002-03-02Member: 263Members, NS1 Playtester, Forum Moderators, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow
As noted, this thread is veering outside of it's initial focus. If you wish to discuss the issue of certain develpment-related console commands being unnecessarily available outside of development mode, you're welcome to start a new thread on the topic.
The OP is pretty much all about nav_debug with medpacks only mentioned a few times. Lets not pretend this line of discussion is a derail.
Also @IronHorse - if the nav_debug command is so unimportant that it doesn't matter where it is (whether behind cheat mode or not), and you don't necessarily support a lack of action on the issue, then why have you personally contributed so much discussion towards it - all of which stonewalling the discussion to put it in cheat mode?
This is really now about console commands not being where they should be.
If you wish to hijack it or limit your responses to just that category that's your choice, but I don't have to follow suit. I responded to everything at hand. Which i consider to be highly relevant. (and so did the OP I guess)
Um, yea you kinda do have to follow suit if you're specifically replying to the content of someone elses post.
"Do you like this hair cut?",
"Yea, those socks look great on you!"
Having other means of doing location exploits is not the excuse a rational or sane person gives for lack of action regarding nav_debug
Point me to where I support lack of action on this issue, please. Give *some* modicum of evidence of your straw man in one of your posts at least..
Else, you're arguing with yourself elodea.
@Ironhorse, setting the medpack/ammo concern aside, you're thinking it advisable at this point to level the playing field by inviting the masses to include nav_debug in normal, daily play (should they so choose)? My first reaction upon reading that is to assume I've somehow misunderstood you (as if, perhaps, you were commenting only on the med/ammo "exploit"), or that I perhaps misunderstand nav_debug's place.
I don't think it should be invited to normal play such as a tool tip, per se, due to its natural intended debug use it's not very user friendly... but for "pro tips"... yea i think it should be.
...Besides nav_debug being useful in determining WHY your stupid arc or drifter just got stuck or why your gorge tunnel won't drop precisely right there...
It's also not the only Tres/Pres free means of determining enemy positions.. sooo I have a hard time advocating for any change considering the large array of options...
So kinda like the old alien infesation where you could see everything. That was OP and removed. Not sure why something like this is available to everyone without cheats on.
The question i'd like to ask is why is it being defended as needing to be outside cheats 1?
As clearly stated already: Because its not the only means or method, there's a plethora of these exploits/tricks and despite attempts to fix them they continue to return for over the course of years. Most are reported already in our system.
So okay, sure.. we make nav mesh cheats only (which I am not opposed to obviously)... now what about the 5 other means, hmm?
The only thing I have defended is the importance that has been placed on this singular command. This is because fixing this one does not fix the issue..
This is something worth mentioning because the entire reason behind suggesting a fix in such a loud/important manner was supposedly due to its potential for exploit, not because it was a benign command.
So can we end this (nav_debug specific) discussion now already?
How do you still not get this - baby steps come before running.
Nav_debug came up in this thread and there are several angles you need to attack when dealing with it. When deciding if a banana is nice to eat, you do not only look at it's size. You also look at it's colour and smell.
You say nav_debug is potentially one (though insignificant) of a plethora of 'unfixable' location exploits, whatever that statement is even intended to accomplish. I say it shouldn't even be discussed to begin with. Put that shit behind dev 1 and stop writing so many meaningless words.
If this command made your screen go black and that was the end of it, you @Elodea would not be advocating so thoroughly to hide the command behind cheats.
What is this.
If a command made your screen go black, it should be simply removed instead. By nature, that kinda makes it NOT a developer command. Unless the devs wanted it for some reason, then it should be behind dev 1 as they see fit. Wow.
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
edited February 2014
Good lord. Are you fucking kidding me?
1) I was responding to the OP and the subject, not just your limited category you decided you wanted to go on about. I know you want to keep ignoring the entirety of the topic because you don't want to acknowledge how relevant it is, but you sticking your head in the sand won't stop me from reminding you.
2) So saying that "if the problem is going to exist no matter what, you may as well share the knowledge" constitutes as me supporting a lack of action??? .. Wow.. Lol.. Did you honestly try to reach that far?
I also like how you left out the end of that post where I clearly state : "Would i like all of these issues to be fixed once and for all? Sure "
Way to edit things so they work in your favor.
You are reaching so hard it looks desperate.
You also are still not comprehending what's occurring. There is no" baby steps". This change (which is already patched for the future) changes *nothing*.. Read what I wrote previously ffs : it couldn't be fixed with a fully staffed team over the course of years. But go ahead.. Keep plugging your ears and making this one thing sound important, you need more agrees from others who aren't absorbing this.
You clearly have no idea what you're talking about (well that was actually clear from the beginning, based on the importance you drew) and are reaching so hard to find someone to oppose you just so you can feel vindicated in your outburst.
I've said all that needs to be said on this subject and am very much done with it.
@d0ped0g
You question is answered if you actually read my posts..
Comments
EDIT: well now actually testing it it doesn't completely do what i thought it did. It doesn't reveal anything to commander. It only helps to players on the field.
Sure any commands that can be used to grant an clear and abuseable advantage should be blocked (like net_lag, and probably nav_debug). However at a certain point you need to realize that the small advantage which a command could grant is outweighed by the advantages is offers for use in debugging client gameplay. Should the devs restrict the maxfps command because it can be used to increase rof? Should certain render commands be disabled because they can improve FPS/allow you to see better?
Its hardly the kind of issue people are making it out to be...
You really need to read my posts more thoroughly and stop putting words in my mouth. I don't know why you keep putting up a strawman..
To be crystal clear once again : I support and would love for ALL methods of location exploits to be fixed. But knowing that this is a goal that has been attempted across years now with a full NS2 dev team.. and hasn't been reached, I really don't get the big noise and fuss about this one single command all of a sudden?? Granted, it is more end user friendly than others.. but fixing it will not stop locational exploits.
I really wish to drive this point home, because some championing this change just don't seem to be absorbing this fact:
As @xdragon and myself have been saying there are many more methods, and all have attempted to have been fixed - many actually have been... only to come back later. With developer resources for NS2 being at an all time low, it is not probable that all of a sudden we can now magically permanently fix the plethora of means to determine structure locations once and for all.
Does this mean that nav mesh shouldn't be behind a cheat command? No.
Does this mean that once this is done, the ability to use an exploit to determine structure location will be impossible? No.
Do we have the resource and means to remove all forms of location exploits? No.
Can all forms of location exploits be put behind a cheat command? No.
So does the nav_Debug deserve the tone and fuss being currently made about it? No.
This thread is so utterly frustrating. I want to step back from the particulars and talk about the meta that I find frustrating.
To begin with, on the "whack-a-mole" issue. I agree that's a pretty appropriate way to describe what has happened with regard to these bugs. To me, it suggests a systemic failure to either take ownership of bugs or to test bugfixes and probably some communication problems which add up to what we might term "QA maturity". I'm not trying to place blame, only to bring about improvements. Consider how much time UWE has spent trying to fix some of these bugs, and now it seems all for naught. This is should be a case study for UWE to improve their processes for Subnautica. I know you're probably not the right guy to talk to about this but you're kind of defending the lack of action here and imho it's only to the detriment of NS2 as a product and UWE as a studio.
Next, paying attention to the community being divided on this is silly. The community's goals are not UWE's goals. I see a lot of parallels between this thread and the problem that lead to the introduction of ghost structures. Using armouries to block exits and kill Onos was intensely divisive to the community. Some people could see that it was excessively harsh on the player who happened to be the Onos while others looked at the game on the whole and said armoury blocking was a 'valid strategy'. Ultimately, if armoury blocking was necessary for game balance that points to some bigger problems. Alternatively, if it was necessary for strategic depth that is another broader problem. Where I see parallels is that they are both caused by emergent gameplay. Emergent gameplay is liked because it enriches the game, while others might like or dislike the particular outcomes. Therefore you get mixed feedback. The *real* problem is that the developer hasn't factored the emergent gameplay outcomes in to the design or balance and the results can have compound effects on other parts of the game design and balance (eg: level designers making doorways relative to the size of armouries). The best way forward is to take ownership of the emergent gameplay and reintroduce it as a balanced feature. In the case of armoury blocking, giving the marines access to something like bonewall would be comparable. The cost/timing etc can be balanced in isolation and the Onos player doesn't feel cheated. In the case of hive detection, we already have scan.
Another point is that NS2 is riddled with tricks which make those in the know more effective at the game. Of course they will want those features to stay. And of course that makes the game have a more difficult learning curve for new players. Where do you draw the line? Well, I think its a pretty clear sign when some of those tricks seem less like intended game design and more like hacks and exploits.
Lastly, this is pretty minor but when you talk about hive location being a known quantity in the first 10 seconds of the game, you're using information already polluted by these bugs. Aliens don't try to hide their starting hive because it's so easy to overcome. Nobody has ever evaluated the benefit of keeping their starting hive secret because there has never been an opportunity. Are there some strategies involving shade hive first that could be of use? Just occasionally I play a pub game where marines don't seem to figure out where the starting hive is for perhaps 2 or 3 minutes and that's enough to make me wonder. Is that overcome by scan anyway? Well sure, but that's in response to choices made by the commanders. Others discount the value in hiding hive location because most maps have fixed/relative hive locations. That's also kind of short sighted because it prepositions homogenous games. "Because hive locations are rarely secret, there's no merit in having hive locations be occasionally secret". My arguments here are kind of weak, but they're the counterpoint to the respective arguments which are also quite weak.
Just to be clear, are you saying you want the community to come up with solutions to the bugs or was this rhetorical?
Edit: I can see from your last post I'm somewhat preaching to the choir and that it's a matter of resources. I get it. Perhaps you weren't so much 'defending UWE's lack of action' as 'being realistic and open to the community'.
(on a side note, I'm aware of at least two other only-useful-in-a-development-environment commands that aren't behind dev 1 that could be used as means to exploitation)
please let me try and put this as simply as humanly possible so you don't get anymore lost
I couldn't care less about actual bug fixes at this point in the discussion. Put the developer commands behind dev 1 where they belong. Having other means of doing location exploits is not the excuse a rational or sane person gives for lack of action regarding nav_debug. wow. And this goes likewise for all other commands that are not behind dev/cheats 1.
If you really were seeing this point, I shouldn't be seeing as many words from you as I am.
Only commands that provide non-exploitative feedback specifically for the user during the normal course of a game should stay out of cheats/dev. r_stats, net_stats, debugspeed, and whatever else that i missed.
If you would read more thoroughly, you would have seen that I already posted why i think trying to fix starting location exploit in particular is largely irrelevant. This is really now about console commands not being where they should be.
After three very clearly defined posts repeating the exact same thing, if you still don't follow why this thread issue needed to be seperated into different sub-components and treated differently, then I can only leave it in God's hands
The developers spent an un godly amount of time attempting to fix this bug. I believe over 5 developers have now had a crack at it. That speaks volumes for the reality of bug squashing in general considering the talent at hand on their staff. Some features like onos stomp almost were cut entirely as a result of this bug. It's gotten better, sure, but it is the oldest and most stubborn bug and it still exists today. At one point when I inquired about it after release, Brian said something to the effect "I cannot work on that bug anymore for the sake of my own mental health."
In instances like these, would you say there is a systemic failure occurring in our QA process? Because I would not.
I cannot see what else could be done. These location exploits are very similar to this situation. They have not gone unnoticed, they have been worked on, many have been fixed and quite a few have returned.. And some have been given up on.
Just one example was the tech point showing up as "damaged" to any commander from a hive dropping - it was a huge one that was fixed numerous times after much effort.
Actually I am not. ;-)
Try it yourself - even in the largest of maps I can walljump far enough to justify rine contact in time, (or deduce from no contact) and if there is at least one other skulk doing their job on my team, on the other side of the map, then we've narrowed down their start. Conversely if you're a marine you should be able to deduce alien start based on your first contact. Being used to the timings helps assessing this obviously.
@mouse
Sure and this is why I agree with it.. It has minimal impact to make this change. (despite the times it's come in use for me during pub games to determine why AI was stuck or why I couldn't place a GT) so go for it if it makes people happy.
But getting up in arms about it and arguing for it to be placed behind the cheats command *as if it's going to suddenly stop locational exploiting* is what I had a problem with.
Even if those other exploitable commands you know were to be restricted to cheats only, there's still multiple other methods which cannot be stopped in such a manner due to their very nature (they are not commands) and have been attempted to be fixed and failed in the past.
Lastly, thank you khyron for realizing I am just trying to explain things in a practical and informative matter to everyone, instead of blindly defending an exploit..
There's just sooo many things that are difficult to understand and even explain until you get to witness and experience the process of development. Almost every PT I know that's joined gets their eyes opened and then typically extends their level of patience and understanding as a result. Trying to convey to anyone who hasn't experienced this, why bug X isn't fixed yet, becomes quite the challenge as they aren't going to be easily convinced. I once even wrote a blog about this phenomenon in order to give a viewpoint from this side of the fence (so to speak) but ended up scrapping it because in the end I realized it was the personal interactive experience and effort that really drives the point home.. Not someone else's words.
Ok after skimming quickly through this thread I can see where the issue is... If we allow the debug_nav option outside of cheats why not let all cheats outside of cheats? I mean, am I the only person who has wished they could go "god mode" (Darwin Mode) at the sight of an onos charging you, or up the damage so that it only takes 1 bullet to kill the hive? Obviously to make everyone happy and eliminate the exploit of dropping med packs on top of hives to find the start we should instead be allowed to drop CC's and Hives outside of the map so that no one can find it. This would solve all problems in my opinion. Also I would like to be able to place phase gates and gorge tunnels inside of the ready room so that people can join the game quickly regardless of team balance.
*reads OP mentioning other forms of exploit like medpacks*
No, it is not.
If you wish to hijack it or limit your responses to just that category that's your choice, but I don't have to follow suit. I responded to everything at hand. Which i consider to be highly relevant. (and so did the OP I guess) Point me to where I support lack of action on this issue, please. Give *some* modicum of evidence of your straw man in one of your posts at least..
Else, you're arguing with yourself elodea.
The only thing I have defended is the importance that has been placed on this singular command. This is because fixing this one does not fix the issue..
This is something worth mentioning because the entire reason behind suggesting a fix in such a loud/important manner was supposedly due to its potential for exploit, not because it was a benign command.
If this command made your screen go black and that was the end of it, you @Elodea would not be advocating so thoroughly to hide the command behind cheats.
So can we end this (nav_debug specific) discussion now already?
Also @IronHorse - if the nav_debug command is so unimportant that it doesn't matter where it is (whether behind cheat mode or not), and you don't necessarily support a lack of action on the issue, then why have you personally contributed so much discussion towards it - all of which stonewalling the discussion to put it in cheat mode?
"Do you like this hair cut?",
"Yea, those socks look great on you!"
*some* modicum of evidence... *chuckle*
Nav_debug came up in this thread and there are several angles you need to attack when dealing with it. When deciding if a banana is nice to eat, you do not only look at it's size. You also look at it's colour and smell.
You say nav_debug is potentially one (though insignificant) of a plethora of 'unfixable' location exploits, whatever that statement is even intended to accomplish. I say it shouldn't even be discussed to begin with. Put that shit behind dev 1 and stop writing so many meaningless words.
What is this.
If a command made your screen go black, it should be simply removed instead. By nature, that kinda makes it NOT a developer command. Unless the devs wanted it for some reason, then it should be behind dev 1 as they see fit. Wow.
Glad to. Trying to explain simple things to you without any sign of dawning realisation is starting to become tiresome.
1) I was responding to the OP and the subject, not just your limited category you decided you wanted to go on about. I know you want to keep ignoring the entirety of the topic because you don't want to acknowledge how relevant it is, but you sticking your head in the sand won't stop me from reminding you.
2) So saying that "if the problem is going to exist no matter what, you may as well share the knowledge" constitutes as me supporting a lack of action??? .. Wow.. Lol.. Did you honestly try to reach that far?
I also like how you left out the end of that post where I clearly state :
"Would i like all of these issues to be fixed once and for all? Sure "
Way to edit things so they work in your favor.
You are reaching so hard it looks desperate.
You also are still not comprehending what's occurring. There is no" baby steps". This change (which is already patched for the future) changes *nothing*.. Read what I wrote previously ffs : it couldn't be fixed with a fully staffed team over the course of years. But go ahead.. Keep plugging your ears and making this one thing sound important, you need more agrees from others who aren't absorbing this.
You clearly have no idea what you're talking about (well that was actually clear from the beginning, based on the importance you drew) and are reaching so hard to find someone to oppose you just so you can feel vindicated in your outburst.
I've said all that needs to be said on this subject and am very much done with it.
@d0ped0g
You question is answered if you actually read my posts..
*LOCKED*