Quake-Like Console, Part 2 Question submitted by (19 January 2000) | Return to The Archives

| I've followed your example and made a simple test-console who quite works. I've also added variables ( witch I call them cvars, in the spirit of Quake ! ) by using void pointers and explicit casting like this : *(int *)ptr->address = atoi(...) r *(float *)ptr->address = atof(...). One problem is that when I try using string type cvars : *(char *)ptr->address = *some_string_pointer ( or something like that ) it doesn't work. If you know what's wrong or maybe you have a better solution please tell me.
The other problem is about functions with different numbers ( and types ) of parameters. Your approach suggested that the type cheching and parameter passing would have to be done right in the function. It is simple and clean but not very flexible : all the functions the engine is using have to be rewritten and my idea was to make the engine functions available to the console just by adding them to the list. Is it possible to add to the command list functions like : set_name(char *PlayerName), sky(char *skyImage, float angleX, float angleY, float angleZ), attack() (with no arguments), or the_impossible_and_I_have_no_idea_how_to_do_it" Quake-bind , a command that has for arguments other commands. Just kidding about that last one or maybe...;)?

| For the strings, try this: *(char *)(ptr->address) = *string_pointer; This is assuming you want the string_pointer to be stored in the value of 'address' and not 'ptr'. This is also the case for the ints and floats, so you might have something really strange going on here.
I don't understand why it's not very flexible. Yes, the functions need to have some extra code added to them to do the parameter parsing. With some clever helper functions, this should be easy (for example, a function that parses out a floating point value as well as doing some range-checking to make sure that the value is valid, or maybe set a default if the parameter is missing.)
You can't think of these as C functions. They are commands with parameters. C-functions are flexibility-limited in that they have to be hard-coded to accept only a very specific set of parameters. Commands are different in that these parameters are whatever the user types, given a usage criteria.
In our last discussion on this topic, I created a list that looked like:

    stuct   console commandList[] =
    {
            {"showFrameRate",           showFrameRate},
            {"showStats",               showStats},
            {"enableFog",               enableFog},
            {"killerLeemursOnTheLoose", killerLeemursOnTheLoose},
            {NULL, NULL} // list termination
    };

You can add to this, whatever you want. I would start by adding some help information to this list:

    stuct   console commandList[] =
    {
            {"showFrameRate", "showFrameRate [fps|ms]",   showFrameRate},
            {"showStats",     "showStats [all|renderer]", showStats},
            {"enableFog",     "enaleFog [linear|log]",    enableFog},
            {NULL, NULL, NULL} // list termination
    };

If they get the function parameters wrong, then the function can spit out its little usage string. You can also create a help function that can get usage on any specific command, or one that spits out the entire table of command usages.
You'll probably need to add a few more elements to each structure entry as you want more functionality.
Response provided by Paul Nettle

This article was originally an entry in flipCode's Fountain of Knowledge, an open Question and Answer column that no longer exists.

Copyright 1999-2008 (C) FLIPCODE.COM and/or the original content author(s). All rights reserved.
Please read our Terms, Conditions, and Privacy information.