New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Quake's console variables approach for all customizable settings #1071

Closed
Hiradur opened this Issue Jul 12, 2016 · 3 comments

Comments

Projects
None yet
2 participants
@Hiradur
Contributor

Hiradur commented Jul 12, 2016

Quake 3 and some other games use console variables (cvars) to store their settings. This allows to change every single value from an ingame console and tweak the game to a degree which is almost impossible to provide with a GUI-only implementation.

Here is an example of a Quake 3/OpenArena configuration file: https://gist.github.com/Hiradur/9c396b54ea4213d0de62
Notice how from key bindings to graphics to the position of UI elements everything is stored in this single config file.

@only-a-ptr already mentioned something similar before and I also think this would be nice to have in RoR. Implementing this would require a lot of monkey typing though, I assume.

Advantages:

  • easy access to every single setting at runtime -> encouraging experiments with different values, possibly leading to the discovery of "better" settings (e.g. more FPS, better graphics...) such as #988
  • RoRConfig, ingame settings menu, ingame console and manual config file editing would all use the same approach to change settings, reducing redundancy in the codebase
  • key mappings could be made implemention-independet, making it easier to ditch OIS in the future
@only-a-ptr

This comment has been minimized.

Show comment
Hide comment
@only-a-ptr

only-a-ptr Jul 12, 2016

Member

I don't recall suggesting anything similar, however, it's VERY tempting. I've seen this type of configuration in many respectable engines, using it would improve our image. And I do like the technical side of it.

As a matter of fact, RoR internally works halfway this way. Our "RoR.cfg" is parsed into a hashmap and it's values are accesse by our *SETTING() macros from anywhere. However, AFAIK there's no console integration and due to the simplistic implementation (everything's stored as string in std::hash and parsed when requested), it's unusable in runtime because of performance.

Using the Quake approach would mean to ditch our std::hash<std::string, std::string> based config, and instead define a struct with respective fields (and their string/datatype mappings for console manipulation). The typing part doesn't really bother me, it's worth it. However, I need to study OpenArena's code first - what exactly is "seta"? If feels like "set-alphanumeric", but why would they store everything as string and parse on runtime? Is the parsing driven by cvar type? Or is there some proxy which buffers the string and updates internal structs when ready?

Anyway, I like the idea.

EDIT: Hmmm....
https://github.com/undeadzy/ioquake3_mirror/blob/master/code/qcommon/cvar.c#L1298
https://github.com/undeadzy/ioquake3_mirror/blob/master/code/qcommon/cvar.c#L848
Allright, so "seta" means set with ARCHIVE flag.

Member

only-a-ptr commented Jul 12, 2016

I don't recall suggesting anything similar, however, it's VERY tempting. I've seen this type of configuration in many respectable engines, using it would improve our image. And I do like the technical side of it.

As a matter of fact, RoR internally works halfway this way. Our "RoR.cfg" is parsed into a hashmap and it's values are accesse by our *SETTING() macros from anywhere. However, AFAIK there's no console integration and due to the simplistic implementation (everything's stored as string in std::hash and parsed when requested), it's unusable in runtime because of performance.

Using the Quake approach would mean to ditch our std::hash<std::string, std::string> based config, and instead define a struct with respective fields (and their string/datatype mappings for console manipulation). The typing part doesn't really bother me, it's worth it. However, I need to study OpenArena's code first - what exactly is "seta"? If feels like "set-alphanumeric", but why would they store everything as string and parse on runtime? Is the parsing driven by cvar type? Or is there some proxy which buffers the string and updates internal structs when ready?

Anyway, I like the idea.

EDIT: Hmmm....
https://github.com/undeadzy/ioquake3_mirror/blob/master/code/qcommon/cvar.c#L1298
https://github.com/undeadzy/ioquake3_mirror/blob/master/code/qcommon/cvar.c#L848
Allright, so "seta" means set with ARCHIVE flag.

@Hiradur

This comment has been minimized.

Show comment
Hide comment
@Hiradur

Hiradur Jul 12, 2016

Contributor

I don't recall suggesting anything similar,

I recall you talking about making the ingame settings more accessible for experimentation, but maybe you had something completely different in mind.

Allright, so "seta" means set with ARCHIVE flag.

seta means 'store the value' so it's available after a restart of the application. set (run from the ingame console) would only set the value for the current session.

Contributor

Hiradur commented Jul 12, 2016

I don't recall suggesting anything similar,

I recall you talking about making the ingame settings more accessible for experimentation, but maybe you had something completely different in mind.

Allright, so "seta" means set with ARCHIVE flag.

seta means 'store the value' so it's available after a restart of the application. set (run from the ingame console) would only set the value for the current session.

@only-a-ptr

This comment has been minimized.

Show comment
Hide comment
@only-a-ptr

only-a-ptr Sep 19, 2016

Member

It has begun: #1113

Thanks for the inspiration!

Member

only-a-ptr commented Sep 19, 2016

It has begun: #1113

Thanks for the inspiration!

@only-a-ptr only-a-ptr closed this Sep 19, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment