Not showing the console on startup

[Baker]

Back on topic .... THE ANSWER

I don't care if there is a secret way to activate the console and the console should be shown on a host error or if running is going on.
But I want the option to NOT display it on startup. Here is the RIGHT way (and this is ALL you need, no other code changes) ...

Draw_Crosshair ();
SCR_DrawRam ();
SCR_DrawNet ();
SCR_DrawTurtle ();
SCR_DrawPause ();
SCR_DrawFPS (); // JPG - draw FPS
SCR_DrawSpeed ();
SCR_CheckDrawCenterString ();
SCR_DrawVolume (); // Baker 3.60 - JoeQuake 0.15
Sbar_Draw ();

if (mod_conhide==false || key_dest == key_console) // Baker: kill my "mod_conhide==false || " unless you bother making a commandline parameter or cvar check
SCR_DrawConsole ();

M_Draw ();
Mat_Update (); // JPG

Now that is from ProQuake in SCR_UpdateScreen in gl_screen.c --- probably eventually will be in cl_screen.c or something because I've made as much of the files renderer neutral as possible.

I made a command line parameter called "-conhide" and if it is true then mod_conhide gets set to true. IF the key destination is NOT the console --- and on startup it isn't --- then the console will not be drawn. Key_dest indicates where the keyboard input goes. If a map is running the destination is the game and if the console is ACTUALLY up and you can type to it, the destination is key_console. But the key_dest isn't key_console on startup and only showing the console WHEN key_dest is key_console does the trick.

[Spike]

Obviously, any console commands should be appropriately sandboxed (much worse is overwriting c:\boot.ini)... but hey.
Thanks to the whole console buffer thing, you can obliterate multiple files with a single svc.

Well, when it comes to console access, changing your fov to, say, 120 would give you a slight advantage over your opponants. Which is pretty common to do, but so rarely found in engine menus.

Stuffcmds suck because by sending a stuffcmd to a client, that client will remember what was sent until the client quits, not just until they disconnect.
Take v_cshift as an example. It changes the palette when you're out in the open. Get disconnected just after being hit by a flashbang or whatever in some mod, and now you can't even see the menu to quit.

Alternatively, allowing the user access to the console allows them to change the v_idlescale cvar. But not only does it allow them to clear that cvar to kill the effect, but it also allows them access to the other cvars that acompany idlescale, and reduce the period/multipliers which affect it (and intermission too), which can give a significant advantage at times.
Okay, so that applies to configs too, not just the console. mneh

sandboxing stuffcmds gets a lot more complicated when you realise that mods can and do stuffcmd alias commands.

With csqc, you could kill the need to stuffcmd (at least to the engine, csqc would be able to interpret it as csqc commands which would hopefully be safe). You can vary stuff per-frame, instead of only every tick, so effects come out smoother.
*really* tempted to make an ext_csqc_simple extension. One that would actually be possible to just plug into an engine in 10 mins.
mneh too lazy. :s
But it would allow you to do anything in the mod without the user needing to interact the console.
If its just sbar rendering, stuffcmd redirection, it should be fine. Possibly add a pre-render function to update cvars per-frame. Would still have init/shutdown to clean out 'broken' cvars, which would be muuuch more friendly than stuffcmds.
:s

[mankrip]

Stuffcmds suck because by sending a stuffcmd to a client, that client will remember what was sent until the client quits, not just until they disconnect.

Good point. Sandboxing the stuffcmd could be a good idea, by storing any values set by them into temporary versions of the cvars, something like cvar.tempcvar.value . Of course, this would overcomplicate the cvar system unless encapsulation is also implemented.

Clean-up of these temporary cvars could be done either when changing maps, or upon disconnection.

[mh]

*really* tempted to make an ext_csqc_simple extension. One that would actually be possible to just plug into an engine in 10 mins.
mneh too lazy. :s

Would beer cure your laziness? I could give you beer.

[frag.machine]

*really* tempted to make an ext_csqc_simple extension. One that would actually be possible to just plug into an engine in 10 mins.
mneh too lazy. :s

Would beer cure your laziness? I could give you beer.

I can send some peanuts by mail.

[Spike]

Baker, not a perfect fix, as that makes the console 'scroll up' instantly, but not down.

mk, actually, FTE 'latches' cvars if they were set by gamecode. When you disconnect or change map, it restores the value the user requested (it does also prevent the user from changing the current value but will remember their request, which is actually kinda annoying, so I'm not sure about keeping that part any more, but it stops users from overriding idlescale, for instance).

mh, 2d rendering is the main issue there. All it would give you is changing cvars, hooking stuffcmds, reading stats, and drawing unscaled uncoloured 2d images/text on the screen.
Which would require unmodified 2d draw_ api, and hooks in the svc_stuffcmd handler, sbar rendering, map loading, and map unloading. There are a few other assumptions, but those would be much less likely to be issues.
I would however still do it with qclib, and thus it would only work (well) on a machine with virtual memory of some kind. Hmm, or I could just add a way to tweek the pool size, which I should do anyway.

[Sajt]

Yes, yes, yes, the only non-arcane solution is to eliminate stuffcmd for all "effects" and use replicated QC fields instead. zoom_in/out is replaced with .viewzoom. v_idlescale is replaced with .idlescale. And so on. These could be done in CSQC or in the engine. It also takes care of the problem of a player connecting or a demo starting after the effect has been started.