View previous topic :: View next topic |
Author |
Message |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Tue Jun 08, 2010 5:57 pm Post subject: |
|
|
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) ...
Quote: |
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. _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Tue Jun 08, 2010 6:02 pm Post subject: |
|
|
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 _________________ What's a signature? |
|
Back to top |
|
 |
mk

Joined: 04 Jul 2008 Posts: 94
|
Posted: Tue Jun 08, 2010 6:43 pm Post subject: |
|
|
Spike wrote: | 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. _________________ Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Tue Jun 08, 2010 6:56 pm Post subject: |
|
|
Spike wrote: | *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.  _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Tue Jun 08, 2010 7:04 pm Post subject: |
|
|
mh wrote: | Spike wrote: | *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.  _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Tue Jun 08, 2010 7:17 pm Post subject: |
|
|
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. _________________ What's a signature? |
|
Back to top |
|
 |
Sajt
Joined: 16 Oct 2004 Posts: 1026
|
Posted: Wed Jun 09, 2010 12:59 am Post subject: |
|
|
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. _________________ F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe. |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2004 phpBB Group
|