Skip to content

Change the marker cvars delimiter char#1968

Open
Rainyan wants to merge 3 commits into
NeotokyoRebuild:masterfrom
Rainyan:bug/delimiter-compat
Open

Change the marker cvars delimiter char#1968
Rainyan wants to merge 3 commits into
NeotokyoRebuild:masterfrom
Rainyan:bug/delimiter-compat

Conversation

@Rainyan
Copy link
Copy Markdown
Member

@Rainyan Rainyan commented May 20, 2026

Description

Change the cl_neo_...marker cvars' delimiter character from ';' to ',', because the engine tokenizer uses the semicolon as a command-level delimiter, and there is no escape character available. This causes issues for nested semicolons in config file binds etc, where the inner semicolon of the marker syntax is incorrectly interpreted as the end-of-command token.

I'm taking the easy route of simply changing our marker delimiter character to something better supported, because we don't have source code access to the lexer internals, so else we'd have to detour or shim the engine interface which gets ugly.

This has the one-time side effect of mauling people's marker configs for the next patch (causing those marker values to reset to defaults), but that shouldn't be too much of an issue since the config is trivially fixable for anyone with custom settings.

I'm limiting the scope of this PR to simply fixing the marker cvars, but we should probably also revisit the crosshair code syntax (and any other such serializations: CH_XH_SEGEND), and also change their delimiter characters to ',' or some other agreed upon character that has no conflicts.

Steps to test

  • Load into a map with bots
  • Join spectator
  • Bind for example:
bind o "cl_neo_spectator_xray_marker 4,0,0,0,0.50,1,0,1,1,32,";
bind p "cl_neo_spectator_xray_marker 4,0,0,1,0.50,1,0,1,1,32,";
  • Use the bound keys to toggle the squad icon state.

Previously, with the ; delimiter, this kind of a bind would fail. Likewise attempting to nest " quotes as a workaround to escape the semicolons would not work (but nested/escaped tokens or any kind of changes to the lexer in general are out of scope for this PR).

Toolchain

  • Windows MSVC VS2022

Linked Issues

Rainyan added 3 commits May 20, 2026 06:07
Change the "cl_neo_...marker" cvars' delimiter character from ';' to
',', because the engine tokenizer uses the semicolon as a command-level
delimiter, and there is no escape character available. This causes
issues for nested semicolons in config file binds etc, where the inner
semicolon of the marker syntax is incorrectly intepreted as the
end-of-command token.

I'm taking the easy route of simply changing our marker delimiter
character to something better supported, because we don't have source
code access to the lexer internals, so else we'd have to detour or shim
the engine interface which gets ugly.

This has the one-time side effect of mauling people's marker configs for
the next patch, but that shouldn't be too much of an issue since the
config is trivially fixable for anyone with custom settings.

We might also want to revisit the crosshair code delimiters and any
other such serialized data in the future, and perhaps transfer them over
to a more suitable delimiter character as well.
@AdamTadeusz
Copy link
Copy Markdown
Contributor

It would be cool if people couldn't change their crosshairs with the click of a key bind, since networked crosshairs are a thing

@Rainyan
Copy link
Copy Markdown
Member Author

Rainyan commented May 21, 2026

It would be cool if people couldn't change their crosshairs with the click of a key bind, since networked crosshairs are a thing

I agree that we should prevent spam/abuse (both visual annoyance but also networked traffic spam), but maybe this could be via rate limiting, or by only networking the player's initial crosshair upon their server join (AFAIK this is what CS does to address the issue). Or perhaps something like networking once per round start could be a middle ground, where if someone changes their crosshair mid-round it's still somewhat synced.

But I think for the power users who want multiple crosshairs for whatever reason it would be nice to accommodate that use case (regardless of whether/when it's synced across clients).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants