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]

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.

Hello Nahuel,

I think you told me once that you are using a quite old DP build (2011 or ealier ?) for your game/mod you are working on at the moment.
Older DP builds have this cvar enabled:
r_coronas_occlusionquery
While newer DP builds have this disabled on default.
Please try to enable it again. I think your described issue can be solved with it... hopefully

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.

Since the last "stable" release 2013-03 all sv_gameplayfix_ fixes have been disabled.
I encountered some gameplay issues as well, based on these cvars when using newer builds.
Just like Max_Salivan mentioned it in his post too.

I then made a small list, which sv_gameplayfix_ cvars specifically had been disabled (which had been enabled before the last "stable" march 2013 release).
Please try to enable/disable them, maybe one of them is causing or helping with your described issue.
This is the list, maybe it helps you somehow:

// Darkplaces engine related cvars
// These sv_gameplayfix_ have been disabled since 20130301 build:
sv_gameplayfix_blowupfallenzombies "1"
sv_gameplayfix_delayprojectiles "1"
sv_gameplayfix_downtracesupportsongroundflag "1"
sv_gameplayfix_droptofloorstartsolid "1"
sv_gameplayfix_droptofloorstartsolid_nudgetocorrect "1"
sv_gameplayfix_easierwaterjump "1"
sv_gameplayfix_findradiusdistancetobox "1"
sv_gameplayfix_grenadebouncedownslopes "1"
sv_gameplayfix_multiplethinksperframe "1"
sv_gameplayfix_noairborncorpse "1"
sv_gameplayfix_noairborncorpse_allowsuspendeditems "1"
sv_gameplayfix_q1bsptracelinereportstexture "1"
sv_gameplayfix_setmodelrealbox "1"
sv_gameplayfix_slidemoveprojectiles "1"
sv_gameplayfix_stepwhilejumping "1"
sv_gameplayfix_swiminbmodels "1"
sv_gameplayfix_upwardvelocityclearsongroundflag "1"

You have to put them into autoexec.cfg to permanently change them.

Best of luck, and looking forward to your game/mod

[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]

Ditto for 2012 versions, I too am seeing very odd things. I have emailed LH who has sugguested looking at the same vcars Seven mentions, but they have not solved any issues.

The issue Nahuel is seeing with a stuck player is similar to what I see happening in newer DP versions than 2012....but I am seeing differences in the Linux environment vs the Windows Environment. In the WIn environment, there seems to be a collision issue the engine is overriding .touches for my new nails code completely, whereas the same QC in 2012 versions works perfectly as intended. (comparing same build dates of course) However , the same QC in a Linux environment works as intended. I cant find any differences in the CVARS unless they are randomly selected in either environment. LH did say he has "caved" to numerous requests to keep the default cvars within "legacy" type quake paramaters, because he is hearing lots of complaints it breaks older mods. Well, join the club. I spent months porting my mod to work as I intended with DP, and I thought I had a stable environment until these changes crept in. It was not said in exact words, but LH seems to have indicated that other collabarators may put things in to the builds that effect major physics such as the collisions. Im not 100% sure if I read that right, but I have also seen an issue where light is being added to certain pickups and other spots on the ID bsp maps where there is some normal shadow. Again, this is with 2013 versions and up, and it tends to co-incide with what seven says, and I have a hunch someone was trying to fix this issue:

http://forums.inside3d.com/viewtopic.php?f=3&t=5111

and forgot to make it an option or make a note that there is a cvar to add light to items and parts of the maps now. But I could be wrong and its all cvar related...hard to tell.

I noticed that too

in darkplaces 2012 all good

[LordHavoc]

Ditto for 2012 versions, I too am seeing very odd things. I have emailed LH who has sugguested looking at the same vcars Seven mentions, but they have not solved any issues.

Documented test cases are needed, you are both poor at explaining these issues and have not demonstrated them to me either, I really get tired of the whining when there is insufficient information for me to act upon.

Useful demonstrations come in the form of save games (preferably for less exotic mods, id1 ideally) and a description of observed behavior vs expected behavior, videos of such behavior breakage can also work but for physics I need save games to do bisecting of darkplaces svn revisions and find the start of a problem, which leads to a resolution a lot quicker than speculation based upon a video, screenshot or description.

Bisecting in case you aren't familiar with it, is the process where I repeat the actions to reproduce a bug (preferably from a savegame as it saves a lot of time and has more reliable results) on the latest darkplaces svn revision, then on a previous one that is expected to work, then halfway between and if the halfway revision is bugged/not-bugged I refine my search by taking halfway of the lower or higher revision range. This is a tedious process and anything at all that can accelerate it is VERY desirable.

Physics and collision bugs almost always are found only by bisecting.

I know you wanted me to test on your server but that isn't an option when bisecting as it is the server that is bugged.

Regarding the sv_gameplayfix_ cvars being changed to match id1 behavior, this was a necessary change that I had been putting off for years, the change was planned but I was lazy about it.

Here are some examples of why these cvars were changed:
sv_gameplayfix_blowupfallenzombies - this made zombies able to be blown up in id1 (a desired behavior on my part, but it is incorrect for me as an engine author to change gameplay), it also broke the hipnotic Horn of Conjuring (the pet fiend would continuously growl at itself), the Zerstorer sanguine powerup was also bugged with it,
sv_gameplayfix_findradiusdistancetobox - this made rockets have a larger blast radius in id1, also affecting all quake mods that did not explicitly clamp their falloff math, this also meant it was easier to activate certain secret doors with explosions (which was the actual intent, but again an incorrect choice on my part).
sv_gameplayfix_grenadesbouncedownslopes - this made grenades not stick on slopes but instead bounce correctly - objectively this is a bugfix, but it changes gameplay in a potent way, and speed runners in particular made use of the old behavior, as do rocket arena players.
sv_gameplayfix_setmodelrealbox - this had no real effect on id1 (because it lacked any bugs where setmodel was called without a following setsize), but it broke a large number of mods such as TargetQuake, X-Men: Ravages of Apocalypse, and others, I do not recall if Shrak and Malice were affected but I expect they were in some way.
sv_gameplayfix_slidemoveprojectiles - this means that a grenade can hit a wall, and bounce a certain distance away in the same frame, whereas in id1 it would end the frame at the wall, and start moving again on the next frame, in terms of conservation of energy (a physics engine term) this would be a good thing, but it broke proximity mines in hipnotic as their sticking logic no longer worked properly, and the laser rifle also did not bounce correctly if I recall correctly.

There are others but those are some of the easier to explain examples.

[Cobalt]

Im the first one to always admit I could be wrong:

As I said in my post - "Im not 100% sure if I read that right,"

I did not start this thread, there are more people than myself encountering issues. With all the QC stuff I do on a weekly basis, certainly I can make a mistake. BUT , if Im right and there is a pretty critical problem we are onto, its not because we are whining. Its because we admire this engine a great deal.

Documented test cases are needed, you are both poor at explaining these issues and have not demonstrated them to me either, I really get tired of the whining when there is insufficient information for me to act upon.

[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.

[SusanMDK]

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]

Yep. Also, oldorigin I always wondered about. Is the engine using it or is it QC exclusive? I could only find references in QC to it in the doors code and such via id progs. I think ctf progs and others started using it as a marker for the last spot the player died in but not 100% sure. DP is using it for freeing up possible stuck players with the cvar I believe. Some items like the flags in ctf are using it.

3: make sure you don't break .oldorigin