Changed visual properties of triggers to make them be shown on the clientside #37
Conversation
|
Can you check if we can use something like iuser4 instead of checking for the IIRC In the client |
SmileyAG
force-pushed
the
show_triggers
branch
from
6d40160
to
4ee0271
Compare
|
Rebased to latest After a long time, I decided to remember this request and want to note that Only the first 21 values from
And besides, I think |
SmileyAG
force-pushed
the
show_triggers
branch
from
8e763fc
to
0b10d94
Compare
…lues here (since that are constants that are used now for detecting on client-side)
|
Thanks man, will try to test tomorrow, but i don't know if i will be doing those PRs myself |
You mean the PRs for the different clients as OpenAG and BugfixedHL-Rebased to support it? If so, you can leave that task to me, I'm already done the request for OpenAG repo (they are not yet merged, since it waits for your approval to be it merged and used on HLKZ servers) |
|
I tested and i'm not able to see all of the triggers that are supposed to become visible. Looks like a similar issue to the You can test on the French server (# 9) on AG. When i load dyd_axn_plant i cannot see the trigger_push at the start, but i'm able to see the trigger_multiple entities at the healthbooster. Then i load hl1_bhop_uc1_beta5 and i'm not able to see the trigger_multiple requirements (crowbar and glock pickup volumes/cuboids), nor the start/end trigger_multiples Do you have any idea of what may be going on? i put a console line both in the plugin where you set the color for the trigger_push and in the client where you set the renderamt with the alpha cvar, and it looks like that specific trigger_push that i can't see in dyd_axn_plant goes correctly through both code flows and i see the lines in the console |
That because modern map compiles is stripping unused planes, so despite that triggers is still transmitted from server to client, in fact they aren't draw So, today I implemented TriAPI drawing of triggers as cuboid based on their absmin/absmax on client-side, so, that issue is solved now Showcase: YaLTeR/OpenAG#183 (comment) Also, I decided right now to join on # 9 .fr server as you asked and for some reason only ( |
|
That's awesome. Now i have the same problem as you, i can't see the triggers in the server, neither with the latest version nor with the old one, and i swear i could see the ones at the healthbooster in dyd_axn_plant yesterday, but now i'm only able to see them locally. The plugin had no changes, it was a clean pull + compilation. I did it again just to be sure and restarted the server, loaded the maps several times and still cant see them :/ The server has the |
|
Hello, I have found time to test and I can definitely say that this is a issue either on the plugin or server-side, but definitely not on the client-side But here's what's interesting: the plugin still passes I want to ask you one more question: you didn't replace If it's not, then it’s difficult for me to imagine what it cause that issue then, if that wouldn't resolve then I could make a request to the AG 6.7 repository with identical changes instead (but this time it would be done in the trigger init, and not at
You can even test this yourself by checking if brush entity with specific model name is passed to client in few steps:
#include "com_model.h" // Because it is not included in the file, otherwise the compiler will complain for ent->model->name
if (ent && ent->model)
{
const char *model_debug = "*45";
if (gHUD.debug_test->value > 0 (!strcmp(ent->model->name, model_debug)))
gEngfuncs.Con_Printf("entity with %s model passed to client\n", model_debug);
}
Also, I fixed the crash in code of triggers request for OpenAG, so update the DLL again by downloading it from GitHub Actions |
|
The plugin in the server is just a git pull + local compile of this branch. No code changes compared to this branch. Now i have put a print of the classname inside the I don't have the time to properly trace the path of these entities from the server all the way to the client, i'm not sure why they're not received in //// New global ////
new g_RenderizableTrigger[MAX_ENTITIES]; // triggers that we may allow the client to see
//// After creating the cvar in plugin_init, to subscribe to changes on the cvar ////
hook_cvar_change(pcvar_kz_show_triggers_disable, "ShowTriggersChange");
//// Around the end of plugin_cfg ////
AdjustTriggersVisibility();
//// New function to be called whenever kz_show_triggers_disable changes ////
public ShowTriggersChange(pcvar, const old_value[], const new_value[])
{
AdjustTriggersVisibility();
}
//// New function to go through all the entities and cache the rendering status... ////
AdjustTriggersVisibility()
{
new ent, entCount;
new disableTriggers = get_pcvar_num(pcvar_kz_show_triggers_disable);
for (ent = g_MaxPlayers + 1; ent < global_get(glb_maxEntities); ent++)
{
if (!pev_valid(ent))
continue;
new className[32];
pev(ent, pev_classname, className, charsmax(className));
if (equali(className, "trigger_", 8) || equali(className, "func_ladder"))
{
if (!disableTriggers)
{
g_RenderizableTrigger[ent] = true;
set_pev(ent, pev_effects, pev(ent, pev_effects) & ~EF_NODRAW);
entCount++;
}
else
{
g_RenderizableTrigger[ent] = false;
// This is left here commented out as a reminder that this does not work as intended
//set_pev(ent, pev_effects, pev(ent, pev_effects) | EF_NODRAW);
}
}
else
g_RenderizableTrigger[ent] = false;
}
server_print("[%s] The current map has %d triggers that can now be turned visible", PLUGIN_TAG, entCount);
}
//// Part of Fw_FmAddToFullPackPost that i changed ////
public Fw_FmAddToFullPackPost(es, e, ent, host, hostflags, player, pSet)
{
if (!IsConnected(host))
return FMRES_IGNORED;
if (!player)
{
if (pev_valid(ent))
{
static className[32];
pev(ent, pev_classname, className, charsmax(className));
if (equali(className, "trigger_", 8) || equali(className, "func_ladder"))
{
if (!g_RenderizableTrigger[ent])
{
//server_print("invisibilizing %s %d", className, ent);
set_es(es, ES_Effects, get_es(es, ES_Effects) | EF_NODRAW);
return FMRES_IGNORED;
}
//else
// server_print("rendering %s %d", className, ent);
// Don’t even dare to think about changing that values for render* variables under any circumstances here, everyone understand me clearly?
// These are now constants, if you need to change them - sure, you can do it on the client side, BUT IN NO CASE ON THE SERVER OR PLUGIN SIDE!
//set_es(es, ES_Effects, get_es(es, ES_Effects) & ~EF_NODRAW); // That doesn't work! Use set_pev instead!
//set_pev(ent, pev_effects, pev(ent, pev_effects) & ~EF_NODRAW); // This is now done during plugin_cfg --> AdjustTriggersVisibility
set_es(es, ES_RenderAmt, 0); // We will set the renderamt value on the clientside at HUD_AddEntity function
set_es(es, ES_RenderMode, kRenderTransColor);
set_es(es, ES_RenderFx, 241); // That's how we gonna detect if entity is trigger, since there is no way to get classname straight on clientside AFAIK
// Assign a separate color to each trigger class so that we can optionally turn off or change their color on the client (e.g. to not showing the single-player triggers as _transition or _changelevel)
if (equali(className, "func_ladder"))
set_es(es, ES_RenderColor, { 102, 178, 255 } ); // Sky
else if (equali(className, "trigger_autosave"))
set_es(es, ES_RenderColor, { 128, 128, 128 } ); // Grey
else if (equali(className, "trigger_cdaudio"))
set_es(es, ES_RenderColor, { 128, 128, 0 } ); // Olive
else if (equali(className, "trigger_changelevel"))
set_es(es, ES_RenderColor, { 79, 255, 10 } ); // Bright green
else if (equali(className, "trigger_endsection"))
set_es(es, ES_RenderColor, { 150, 75, 0 } ); // Brown
else if (equali(className, "trigger_gravity"))
set_es(es, ES_RenderColor, { 70, 130, 180 } ); // Steel blue
else if (equali(className, "trigger_hurt"))
set_es(es, ES_RenderColor, { 255, 0, 0 } ); // Red
else if (equali(className, "trigger_monsterjump"))
set_es(es, ES_RenderColor, { 238, 154, 77 } ); // Brown Sand
else if (equali(className, "trigger_multiple"))
set_es(es, ES_RenderColor, { 0, 0, 255 } ); // Blue
else if (equali(className, "trigger_once"))
set_es(es, ES_RenderColor, { 0, 255, 255 } ); // Cyan
else if (equali(className, "trigger_push"))
set_es(es, ES_RenderColor, { 255, 255, 0 } ); // Bright yellow
else if (equali(className, "trigger_teleport"))
set_es(es, ES_RenderColor, { 81, 147, 49 } ); // Dull green
else if (equali(className, "trigger_transition"))
set_es(es, ES_RenderColor, { 203, 103, 212 } ); // Magenta
else
set_es(es, ES_RenderColor, { 255, 255, 255 } ); // White
}
}
if (get_bit(g_bit_waterinvis, host) && g_HideableEntity[ent])
{
set_es(es, ES_Effects, get_es(es, ES_Effects) | EF_NODRAW);
}
return FMRES_IGNORED;
}
//// More code here that i haven't touched... ////
}Now this looks a bit overcomplicated and it can surely be simplified. And one thing i don't really like is that it now all these entities go through Fw_FmAddToFullPackPost, probably because i set them during plugin_cfg to get drawn. So if they weren't doing this before and now they do, that's more load on the server every tick, which i don't know to what extent it matters. I tested different combinations of changing the serverside and clientside cvars to see that the rendering stops and continues correctly, and also starting the map with the serverside cvar disabled and then enabling it later, just in case this is a thing that only works if set during the plugin configuration, but all the cases worked fine. I tried to set the pev_effects and ES_Effects effects at different places and moments and this is what i found it works so far, maybe you can find a better solution because mine is a bit confusing :) |
|
Oh sorry for delay, but I don’t think I’ll be refactoring triggers on the plugin-side in near time, so for now we can get with that solution :) But as soon as you approve it, don’t forget to leave a related comment here or better in an OpenAG request to give the go-ahead for YaLTeR to the merge, and at the same time I’ll also would make a corresponding request for client-side of BugfixedHL-Rebased |
(CONTENTS_LADDER from skin variable)
|
Sorry for the e7cdc1f commit, this is the context for why this happened: I decided to double-check the triggers initialization code and found that
And for some reason I did think that if we set But I decided to add a debug message to the client-side TLDR: Ignore the previous commit and also we waiting for merge changes from |
Image explanation
trigger_autosave -> trigger_cdaudio -> trigger_changelevel -> trigger_endsection -> trigger_gravity -> trigger_hurt -> trigger_monsterjump -> trigger_multiple -> trigger_once -> trigger_push -> trigger_teleport -> trigger_transition -> func_ladder -> others
How to draw triggers on client-side
HUD_AddEntityfunction (entity.cpp file)if (ent->curstate.renderfx == 241)ent->curstate.rendercolorto avoid of draw triggers that related to single-player (_changelevel, _transition, _monsterjump, _endsection, _autosave)ent->curstate.renderamtdepends of the cvar value (default value should be 120 imo)cc @fireblizzard
UPD: as soon as this request is accepted, someone needs to make the pull requests up to OpenAG and BugfixedHL-Rebased repos