Make hint text more useful if the command key is unbound #1962
Conversation
Additionally - Add ``bool force`` and ``number length`` arguments to GM:AddHint which default to false and 20 respectively. The ``force`` argument when true will cause the hint to display even if one or more of the keys involved are unbound - Add GM:UnprocessHint to allow the hint to be re-shown manually - Use the provided GAMEMODE table in the GM:AddNotify call - Bump up the hint disabling hints from 5, 7 to 10, 12 to reduce cases where they pop-up before the player is fully in
|
I disagree. Displaying the hints is still useful to let the player know that a feature exists at all, and that they may have some actions unbound. |
|
How about putting the command they have unbinded in-place of (went ahead with it) |
robotboy655
added
the
Enhancement
Kefta
changed the title
|
|
||
| CreateClientConVar( "cl_showhints", "1", true, false ) | ||
| -- A list of hints we've already done so we don't repeat ourselves | ||
| GM.ProcessedHints = {} |
There was a problem hiding this comment.
What is the point of exposing an internal table to public?
There was a problem hiding this comment.
This was to introduce the auto-refresh table idiom to the file but I forgot to write the full statement.
|
|
||
| if ( ProcessedHints[ name ] ) then return end | ||
| if ( !engine.IsPlayingDemo() ) then | ||
| timer.Create( "GMOD_HintSystem_" .. name, delay, 1, function() |
There was a problem hiding this comment.
What is the point of adding GMOD_ prefix to the timer's ID? Do we not know what game we are?
There was a problem hiding this comment.
Timer identifiers are global. Hook identifiers are global. ConCommands/ConVars are global. Many other built-in systems (Lua or engine based) share common identifiers - adding the prefix is just a formality to avoid conflict.
| local bufferlen = 1 | ||
| local nextstartpos = 1 | ||
|
|
||
| repeat |
There was a problem hiding this comment.
Why was the while loop replaced with a repeat loop? This new code looks infinitely less readable, while seemingly providing absolutely no benefit.
|
|
||
| end | ||
|
|
||
| function GM:AddHint( name, delay, length, sound ) |
There was a problem hiding this comment.
I am not sure adding sound parameter is a good idea. What's next, custom icons? Custom render function?
This system should be kept self contained.
There was a problem hiding this comment.
There are no future gateways to customizability in this library because the vanilla hint system is already firmly limited; the additional arguments introduced are just extensions of the default impl to allow scripts to use this system without reimplementing/copying all the Hint code to change a hardcoded time/sound.
The hint system here is a barebones notification feature to introduce people to Sandbox, but since it's in the Sandbox gamemode table, why not allow the standard impl to be configured without expanding its scope or breaking anything?
|
|
||
| end | ||
|
|
||
| function GM:UnprocessHint( name ) |
There was a problem hiding this comment.
Is this really needed? At what point would you want a hint to be displayed again?
There was a problem hiding this comment.
If a server wants to allow specific classes/roles/teams/whatever division hints to be displayed every time they switch, then they should be able to use this system freely since it's available in the Sandbox gamemode table. This entire sandbox system sucks but it should be fleshed out into the standard Add + Remove template so it can be utilised as the official "gmod hint system"
|
I will update the code to be more concise and readable this week |
Additionally
number lengthandstring soundarguments toGM:AddHintthat default to20and"ambient/water/drip" .. math.random( 1, 4 ) .. ".wav"respectivelyGM:UnprocessHint( string name )ProcessedHintsa gamemode table var rather than a localcl_showhintsAnnoy#hint times to account for the full-load time discrepancyHintTimer_hook prefix toGMOD_HintTimer_