|
Post by MaxED on May 29, 2019 18:18:13 GMT -5
Can't say I've noticed anything particularly broken with the gibs while playing with bots. Instead, I've noticed something different: in some cases when a bot respawns, position of it's corpse is interpolated from bot's current position to corpse position. This doesn't happen every time and seems to happen only when corpse and bot's respawn location are in player's PVS. This happens regardless of cl_async and cl_predict settings.
Here's a short video demonstrating the bug (watching at 0.5 speed makes the bug easier to spot):
|
|
|
Post by MaxED on Jun 4, 2019 20:18:50 GMT -5
In some cases debris/gib models are rendered black on sloped surfaces. More info here.
|
|
|
Post by knightmare on Jun 5, 2019 18:04:35 GMT -5
In some cases debris/gib models are rendered black on sloped surfaces. More info here. I already have a fix for in my merged missionpack source that by adding a small bounding box to all gibs: VectorSet (gib->mins, -4, -4, -4); VectorSet (gib->maxs, 4, 4, 4); gib->solid = SOLID_TRIGGER; // Knightmare- was SOLID_NOT
|
|
|
Post by MaxED on Jun 6, 2019 6:57:26 GMT -5
Changing gibs/debris solidity to SOLID_TRIGGER makes them damageable, which results in gibs/debris being immediately destroyed by explosions. YQ2 fixes that by setting gib/debrees health to 250. Also, looks like SOLID_TRIGGER debris can cause gameplay issues (which I was unable to replicate in KMQ2).
Also, I've added align-to-sloped-surfaces logic, which preserves model yaw to gib_touch.
|
|
|
Post by knightmare on Jun 6, 2019 12:04:53 GMT -5
Or, you could just set their takedamage attribute to DAMAGE_NO.
Also, SOLID_BBOX for debris caused those issues, not SOLID_TRIGGER. I also added a SVF_GIB flag to gibs/debris that makes them not block any movers (see KMQ2's g_phys.c->SV_Push()).
|
|
|
Post by MaxED on Jun 7, 2019 5:40:14 GMT -5
Another issue with gibs/debris: when they start fading, there's a noticeable jump in opacity, which happens because during the first server frame of gib/debris fading, the alpha is interpolated from 0 to 0.95. I fixed that by setting gib/debris alpha in their spawn functions.
|
|
|
Post by knightmare on Jun 7, 2019 12:57:09 GMT -5
Gib/Debris alpha was already set to the starting value in the first gib_fade() function. I just forgot to add a delay before calling the gib_fade2() function, which decrements it.
|
|
|
Post by MaxED on Jun 7, 2019 20:09:33 GMT -5
Out of curiosity, why fog logic was made so complicated? More specifically, what's the reasoning behind storing 3 separate copies of fog-related vars (in refdef_t.foginfo, in r_foginfo and as local vars in r_fog.c)?
|
|
|
Post by knightmare on Jun 7, 2019 23:17:52 GMT -5
The local fog vars in r_fog.c were there first, which were directly set by a servercommand received by the client. I discovered that the fog values were lost on a vid_restart, so I added r_foginfo in the client and the foginfo struct to the refedef for re-initialization. I may look at getting rid of the renderer-local fog vars in the future.
|
|
|
Post by MaxED on Jun 8, 2019 17:18:28 GMT -5
I discovered that the fog values were lost on a vid_restart. But do they even need to be reset? Default values are assigned to all fog vars in r_fog.c and R_InitFogVars() is called only from R_Init(), which makes it redundant. Simply removing R_InitFogVars() seems to fix the issue.
|
|
|
Post by knightmare on Jun 8, 2019 21:26:02 GMT -5
Those default values only exist when the .exe starts up the first time- subsequent vid_restarts don't restore them, as the renderer is integrated into the exe. Quite frankly, they shouldn't be there, and I'll likely remove them in the near future.
As far as the local renderer fog vars themselves, I admit they need to be rethought. The r_foginfo struct in the client will likely take their place for initialization/defaults.
|
|
|
Post by MaxED on Jun 8, 2019 21:58:29 GMT -5
Yes, but WHY do you need to restore them? The fog logic on game.dll side seems to be doing that already when switching maps / loading saves, so what are the cases when this must be done?
|
|
|
Post by MaxED on Jun 9, 2019 18:39:33 GMT -5
|
|
|
Post by MaxED on Jun 9, 2019 19:18:26 GMT -5
Fog is not rendered during the first server frame after loading a save in a map with fog enabled. Changing FogOff() to Fog(ent) in ClientBegin() seems to fix the issue.
|
|
|
Post by MaxED on Jun 10, 2019 5:31:28 GMT -5
Found in CL_ParseConfigString():
if (length >= MAX_PATH) Com_Printf(S_COLOR_YELLOW"CL_ParseConfigString: string %d of length %d exceeds MAX_QPATH.\n", i, (int)length); Is it supposed to be MAX_PATH or MAX_QPATH?
|
|