[xiaoyueyoqwq]

Problem

Opening the WASD menu still let the pawn move.

The old hold wrote VelocityModifier on the human PlayerPawn during OnTick. That is too late: bot takeover applies the occupant's usercmd to the occupied body before OnTick, so a possessed bot kept walking around the map. Humans got a smaller version of the same thing — a visible lurch forward, then a snap back.

The overlay also painted six rows plus a footer. CS2's center HTML clips through that last line, so the key hints were cut in half.

Leaving the menu open also pinned origin every think. That overwrite covered the engine spawn teleport, so a player who kept the menu open through round end stayed off team spawn.

Change

Hold the pawn that is actually being driven (the bot body while possessing, otherwise the player):

• OnServerPreEntityThink sets MOVETYPE_NONE and pins origin
• look angles are not overwritten, so the player can still look around
• OnTick reads W/S/E/A/R first, then strips movement wish

Close the menu on round_prestart (everyone) and player_spawn Pre (that player), so the origin pin is lifted before spawn teleport.

The menu itself is unchanged in what it does (skins, rarity colors, equipped marks, stickers, charms, Default rows). The chrome is cleaner: ►[ ]◄ on the selected row, A to go back, R to close, and five visible rows so the footer stays fully on screen. The menu can be opened while possessing a bot.

Rebased onto current main (1.2.0 / #17). Version bump is 1.2.2.

Scope

• Menu freeze, input, overlay, and close-on-spawn only
• Stickers, charms, Default rows, and module switches from main are kept
• No database or schema changes
• Skin apply, music kits, and ApplyPlayerCosmeticsOnBotTakeover are unchanged

Validation

• dotnet build -c Release: 0 warnings, 0 errors
• Field-tested on a live server after the rebase: humans and possessed bots stay put with look still free; W/S/E/A/R work; the footer is fully visible; Default rows and sticker/charm menus still open
• Field-tested with the menu held open through round end: the player returns to team spawn and the menu is closed

[xiaoyueyoqwq]

Wait a sec, I forget to sync the branch :/

[xiaoyueyoqwq]

Rebased onto current main (1.2.0 / #17) to clear the merge conflict. Menu freeze and WASD chrome are unchanged; stickers, charms, Default rows, and module switches stay as on main. Field-tested on a live server after the rebase.

[Ayrton09]

Thanks for the work, but I can't take this one as it is. It bundles a new freeze, a new input model, a key remap, an overlay restyle, the menu during bot takeover and a version bump, and a few parts are a step back:

• MOVETYPE_NONE plus an origin pin every think lets a player open the menu mid-fall, hang in the air and land with no fall damage, and makes them immune to pushes. The current VelocityModifier hold has neither problem. The round-end issue you close the menu for is caused by that pin, not by main.
• Input now reacts to any change in the full button state and checks which flags are down, W first, so holding W and tapping E (or firing) moves the cursor instead of selecting. main only acts on the button pressed that frame. It also allocates a string per player per tick for the comparison.
• The debounce is hard-coded to 120 ms, which leaves Menu.CooldownMilliseconds dead while still validated and documented, and astra.menu_while_bot is left unused in the seven language files.
• Restoring the saved move type overwrites whatever another plugin set while the menu was open.
• The menu is blocked during bot takeover on purpose, so a possessed bot walking with the menu open is not a case main has. Version numbers are set at release time here (and the next one would be 1.2.1).

If you can show the forward lurch or the clipped footer on main (a clip and your resolution help), open an issue or a small PR for just that and I will look at it.

[xiaoyueyoqwq]

Thanks for the work, but I can't take this one as it is. It bundles a new freeze, a new input model, a key remap, an overlay restyle, the menu during bot takeover and a version bump, and a few parts are a step back:

• MOVETYPE_NONE plus an origin pin every think lets a player open the menu mid-fall, hang in the air and land with no fall damage, and makes them immune to pushes. The current VelocityModifier hold has neither problem. The round-end issue you close the menu for is caused by that pin, not by main.
• Input now reacts to any change in the full button state and checks which flags are down, W first, so holding W and tapping E (or firing) moves the cursor instead of selecting. main only acts on the button pressed that frame. It also allocates a string per player per tick for the comparison.
• The debounce is hard-coded to 120 ms, which leaves Menu.CooldownMilliseconds dead while still validated and documented, and astra.menu_while_bot is left unused in the seven language files.
• Restoring the saved move type overwrites whatever another plugin set while the menu was open.
• The menu is blocked during bot takeover on purpose, so a possessed bot walking with the menu open is not a case main has. Version numbers are set at release time here (and the next one would be 1.2.1).

If you can show the forward lurch or the clipped footer on main (a clip and your resolution help), open an issue or a small PR for just that and I will look at it.

Got it. I’ll answer the remaining questions later.

Regarding your question about why the menu automatically closes after a round ends, there are actually two separate reasons that became mixed together during my testing.

Originally, I was trying to fix a menu issue where a player controlling a bot could still move the pawn with W/S while navigating the menu. Because of "FakePlayer", the normal "isBot" check did not work for the pawn I was dealing with, which led me to add the detection/freezing logic.

However, you are correct that AstraSkin already has its own bot detection and prevents players from opening the menu while controlling a bot. I apparently overlooked that during testing and conflated this with the menu-freezing issue. I’ll revert that part of the change.

While testing, though, I found a separate problem: if the menu remained open across a round transition, the excessive frame freezing could leave the player in a strange state where the normal round-end teleport back to spawn did not take effect correctly.

That is why I added the automatic menu close at the end of each round.

Interestingly, this also fixed several HUD lifecycle issues. For example, if the menu HUD was left open, it could continue flashing near the bottom-center of the screen during the team display phase, or overlap/flash together with the “Start Action” indicator after the round ended.

So the current plan is to remove the unnecessary bot-control changes, but keep the round-end auto-close, since that behavior addresses a separate lifecycle issue and also prevents several HUD conflicts.

[xiaoyueyoqwq]

Withdrawing this PR.

The freeze, input path, key remap, overlay restyle, menu-during-takeover, and version bump are not going upstream. Those mixed a BotManager case (menu while possessing) into Astra, which already blocks that with astra.menu_while_bot.

Round-end close is a separate HUD lifecycle change (team intro / freeze-end prompt). Opened as #19