problems in q3bsp

[Nahuel]

hello forum, I have a problem in Darkplaces. When I use q3bsp sometimes if the player touches a corner of the map (or a wall and the floor at once) he simply falls a bit and is jammed on the floor with the bobing viewmodel. I can not jump or move .if i use noclip i can see how the player mysteriously was teleported undert the ground to stagnate stuck in it. I tried to use playermovement.qc (from dpmod or xonotic) but this doesn fix the problem. How can i fix this several problem? In q1bsp i never see this strange bug. Thanks in advance.

[LordHavoc]

Is the floor a mesh (dpmeshcollisions) or a misc_model with the spawnflags that make it solid (q3map2 converting the triangles to brushes)?

sv_gameplayfix_nudgeoutofsolid 1 may help but this sounds worse than anything I've observed in the past.

[Max_Salivan]

I noticed that too

in darkplaces 2012 all good

[Nahuel]

Hello LH, sv_gameplayfix_nudgeoutofsolid 1 doesnt work properly (the player can not walk up some stairs ) I tried to use xonotic engine (the last release i think 0.7) with the same result. Also i tested the map ( a simple 6 brushes room ) in xonotic and i do not have this problem. I think is a qc problem, or a config problem. I am using qc 1.06. nevertheless I will test with the last stable release version of darkplaces.

I have another question for you, with the latest versions of Darkplaces coronas are visible through models and are only covered by the brushes. Is there any way to change this to back to the old renderings of the coronas? If that were possible only by changing the code; which files should I modify from source? any suggestions?
Thanks in advance.

[Seven]

[Nahuel]

Thank you seven!! THANK YOU VERY MATCH! I am still searching the solution for the problem!! i will look for in the xonotic config (you know is a very large ammount of cfg data)

[Cobalt]

[LordHavoc]

[Cobalt]

[Cobalt]

Ok I tried sv_gameplayfix_slidemoveprojectiles 1 and now my nails touch code is responding ALOT better, but not quite there yet.



Thanks LH, and thanks again for supporting the DP engine above and beyond the "Call of duty" - no pun intended.

EDIT / UPDATE: My local WIn environment running the newest DP build (4-2014) has that CVAR off. However the same build Lunix version labeled as "dedicated" has it set to 1 by default.

sv_gameplayfix_slidemoveprojectiles is actually not a really bad idea regarding what it does with grenades. The grenades in id1 tend to bounce an awful lot. Most people are just use to it, but with this set, the velocity falls off alot faster, and the grenade tends to be in the general spot you aimed at in the first place. It really does what bouncefactor would do for a movetype_bounce when set to a more extreme value. Grenades are different projectiles than nails for example, they are more like cylinders / capsules, and I think this cvar also broke my QC where I was detecting for no velocity with trace_plane_x meeting an onground condiiton, then matching the ground planes angles to that of the grenade, so its flat like it normally would be. I also emailed you about "movetype_roll" a whle ago, and thats what I was thinking, the capsule would possibly roll, and not bounce depending pn physics. I am not sure ODE resolves all of this, but its quite interesting.

[jim]

I noticed player got more stuck in sloped floors, non-orthogonal walls and when swimming & touching the floor. Getting pushed around by damage helped in becoming stuck as well.

Playing a q3bsp level with the Quake progs.dat resulted in less stuckiness, but eventually even the Quakeguy got stuck. If the original Quake levels were converted into q3bsp, I think player might get stuck maybe 1-2 times per episode during a full playthrough of the game. It required quite serious wall humping to get stuck...

In my progs.dat I had included sv_user.qc and modified it. I'm thinking the increased stuckiness may have come from code that "disabled" strafe running/hovering? Although that makes player move slower (also I had decreased the movement speed).. shouldn't slower movement be more safe?

[Spike]

1: angled surfaces will result in lower precision.
2: lower speeds can make it easier to 'find' the seams between brushes, where you're inside neither brush and impacts simply return the start position without being in a solid.
3: make sure you don't break .oldorigin
4: if all else fails, if tracebox(self.origin, self.mins, self.maxs, self.origin, 0, self) reports trace_startsolid, try scanning around the player by 1/8th qu in a few different directions until you're no longer in a solid.

[Cobalt]

Thats odd because I was told that Q3BSP has a tree that makes collision possible beyond the normal point, player and shambler limitations that Q1BSP was limited with. What if you sized the player a couple of units bigger in each direction, still happen?

[Spike]

yeah, sorry, 2 only applies when the mins+maxs is the same as the gap between brushes (which is generally only a problem when your mins+maxs is '0 0 0', but could happen with other sorts of geometry).

[Cobalt]