Prevent Monster From Running Off High Edge
#13015 posted by deqer on 2013/06/16 03:53:58
I have a thin and narrow platform (shaped as a square) that monster_ogres run around. It's over 256 units high from the ground, supported by 4 pillar/beams.
When monster_ogre sees the player, they run off the edge, dropping down to the floor below.
I was surprised to see this. I thought monsters don't do this.
I can't seem to find any information on this in google or quakewiki.
Figured It Out
#13016 posted by deqer on 2013/06/16 06:16:54
The problem is the UI bounding box for the entity (in TrenchBroom) is misleading/inaccurate. I made my platform as wide(or narrow) as the entity's box, so the entity falls off the edge.
To prove this, I surrounded my platform with walls, and the entity was stuck.
Same issue with the monster_dog box. I put a monster_dog in the corner, and it's stuck. I had to move it 8units away from both walls (of the corner) for it to work.
Pretty annoying.
#13017 posted by necros on 2013/06/16 07:09:01
the engine checks for collision in a >= way (as opposed to > ) so monsters have to be at least 1 unit away from walls to avoid getting stuck and have to be on platforms at least 2 units wider to avoid falling off.
note also that narrow pathways will be very difficult for monsters to move into because the checks for movement are done in discreet steps.
Thanks
#13018 posted by deqer on 2013/06/16 07:43:08
I added your information to http://quakewiki.org/wiki/Entity_guide
Feel free to adjust, or find better place for it in quakewiki.
Max Leafs Visible
#13019 posted by deqer on 2013/06/16 17:12:42
"max leafs visible: 416 near (-832 -2824 576)"
Although this doesn't appear to be a warning or error message, I still see it as one. I wasn't getting it before, and now I am; and I have no idea what it means.
I've googled it a number of ways, and getting no good results.
What does it mean, and how do I troubleshoot it?
Does it mean too many polys for a certain area of the map from point to point?
Nah It's Not An Error Message
#13020 posted by RickyT33 on 2013/06/16 18:15:16
It's just a report
It tells you that of all of the places in the map, the one with the most leaves visible to it (as in when the player is stood there) has 416 visible to it. You can go WAAAYYY higher than 416. The other three numbers are the coordinates of this position.
How Do I Use Quoth Content In My Quake Levels?
#13021 posted by hakkarin on 2013/06/16 19:12:21
So I heard about this awesome content pack called Quoth that adds a lot of stuff (monsters, weapons etc) into the game for modders to use in their levels. However, I have no idea how to make any of this stuff show up in NetRadiant (the level editor I use) or appear in-game. How do I load these custom resources into the editor and use them?
Quoth In Radiant
#13022 posted by deqer on 2013/06/16 19:34:09
Alright, Ricky. Added to quakewiki.
hakkarin,
This page: http://spawnhost.wordpress.com/tutorials/quake-1-radiant-tutorial/ talks about Radiant, and mentions Quoth
Avoid Jumping
#13023 posted by Cocerello on 2013/06/20 12:26:16
What is the maximum distance that can be jumped by strafe jumping and bunny-hopping? I need to know that distance for a map and i don't want to use fences or clip brushes and i want to make the chasm as smaller as possible.
Trying it by myself is no valid option as i can't get the hang of it.
As far as i know, with normal jumping the player can get across a chasm of about 180-200 units.
Bunny Hop
#13024 posted by Mandel on 2013/06/20 15:22:24
I don't know that there is a limit, other than a product of the maximal speed (2000?) and the air time of a regular jump, really.
if there are no slopes, grenades, rockets, or monsters, then you can protect against shortcuts by making the opposing edge slightly higher than standard jump height, so that it can't be jumped regardless of speed.
Quake Units
#13025 posted by madfox on 2013/06/21 02:29:34
Not sure how strafe jumping and bunnyhopping fits in,
but regular mapping subscribes:
Max distance player can jump foreward => 225
Max distance player can jump upwards => 42.5
Max distance player can fall not injured=> 275
Min gap in floor before fall through => 35
Max step player walks before jumping => 17
#13026 posted by gb on 2013/06/21 12:13:29
With a rocket-boosted bunny hop sequence or something like that, a player can reach *insane* speeds which translates to insane jumps. I don't think there is any protection against that sort of thing really, apart from something like a midair teleporter or trigger_push, which is a bit cheesy.
(With the grappling hook in RMQ, just as anecdotal evidence, it was possible to reach horizontal speeds upwards of 1000 units per second - I've seen speedrunners go above 600 by other methods.)
Skill should be rewarded. But for 99% of players, 300 units or so should be uncrossable if there is no boost possibility nearby (including slopes and any source of damage) and they have no explosives.
I think. ^^
The slime pool in e1m1 is rather uncrossable (for mere mortals that is) without extending the bridge, so take that as a rule.
#13027 posted by gb on 2013/06/21 12:16:23
The above goes for *Netquake* servers. Some popular engines are not quite Netquake.
Madfox
#13028 posted by negke on 2013/06/21 14:03:44
Those values are all wrong.
So Negke,
#13029 posted by mfx on 2013/06/21 15:32:48
what are actually the right values?
Correct Values
#13030 posted by negke on 2013/06/21 16:46:02
Max distance player can jump foreward = 244
Max distance player can jump upwards = 43
Max distance player can fall not injured = 256
Min gap in floor before fall through = 33
Max step player walks before jumping = 18
#13031 posted by negke on 2013/06/21 16:54:31
And yes, those are for Netquake, id1, vanilla, etc.
Also note that, I believe, there's a slight difference between old SW Quake and source ports concerning the out-of-water height (29).
#13032 posted by gb on 2013/06/21 16:59:10
yeah, the out-of-water height is a bit sensitive. Not everyone can get out of water when the ledge is 32 units high! Make it 16 to be safe.
Great
#13033 posted by mfx on 2013/06/21 18:10:11
thanks negke!
Following What Gb Said...
#13034 posted by metlslime on 2013/06/21 21:14:29
in general try not to build anything to the exact maximum, if you want the player to succeed. Because physics is framerate dependent, some players might not be able to make a jump that is theoretically possible.
Also geometry built near the threshold between "can" and "can't" is ambiguous to the player and makes the environment harder to read. For example you want gaps that are obviously "jumpable" or "unjumpable" when a player looks at them. (exception may be in DM maps where expert players are supposed to be challenged to learn the quirks of the map.)
For example, 16 units is a good max step height. 32 is a good minimum non-step height. 40 units is a good max jumpable height, 48 is a good minimum for un-jumpable height.
Interesting
#13035 posted by Cocerello on 2013/06/21 23:23:46
MadFox and Negke: thanks for the info, it's going to be very useful.
Gb: at the situation i am right now. i have to penalize the skill, as i want to put something very important on the other side. The problem is that if i penalize skill, i have to make that it SEEMS obvious that it isn't possible to go to the other way. I'll probably mix more height and width, as i cannot make the chasm too big (244 is a lot for that part (right now it has 160) and i do need to take into account strafe jumping too), but i still cannot forget about the options of fences, something hanging on the middle of the chasm or adding gravity. I'll test all of them and decide later.
Metlslime: thx for the advices, they are usually obvious, but that's something that can tend to be forgotten.
I'll explain my idea: What i want to do is put a very important key-part of the map on the other side, so it can be seen easily and makes the player want to get there but hiding the path a lot so it is rewarding and makes the player realize how important is or how good the reward is, so i was thinking of ways to prevent the player to get to it by shortcuts, aside from those that we talked before; even ways of countering cheat codes.
The only one that i thought till now that not involve coding or hacking and can be valid even for countering ''noclip'' is killtargeting the object with a box surrounding it made of a trigger_once with a message. This box is killtargeted by another trigger put blocking the way i want the player to follow. Of course i plan to put the box so that only can be touched if the player cheat, or maybe putting also some kind of force field around the box so it is more obvious that it cannont be reached, but it seeems kind of cheap and it won't stop cheaters of trying to get there. I even though of using the box to target all the lights, as the most effective way to prevent people to noclip through doors and secrets triggered by that key-part, even if there is a cvar that adds lighting, only a few ones would know of it, so it will block most cheaters.
I'm conscious to the fact that being so zealous against cheaters can give me problems but i think that if done well it can add a lot to the map.
Truth Is Too...
#13036 posted by Cocerello on 2013/06/21 23:35:02
... that if this part is giving me so much problems maybe i should forget about it entirely if i don't get a decent way to solve it quickly, as it can lead to have a dead weight in the map.
I'll go ask the pillow too. Good night.
#13037 posted by gb on 2013/06/22 01:03:51
If you put up a barrier, make it appear logical. If it's a tech style map, yeah, a forcefield might work. A door stuck halfway also works. Anything that's in the theme of the map.
Cheaters
#13038 posted by quaketree on 2013/06/22 01:47:37
Why worry about them? I mean the only person that they are cheating is themselves out of playing a game the way it was intended to be played and missing out on the experience.
Neg!ke
#13039 posted by madfox on 2013/06/22 01:47:55
Thanks for the right values.
I just quoted Virtus DeathMatchMaker's manual,
but glad to see opposite.
|