Comments (8)
Just to clarify, the current implementation is as follows, failing if the config file doesn't exist?
read in options from file
set option1 = filedata.option1
...
set optionN = filedata.optionN
I think the best way to solve this would be creating the config file and populating it with hard-coded defaults if it doesn't exist already. And, of course, adding it to .gitignore so you stop checking it into git 😛
if (file exists)
read values from file
set option1 = filedata.option1
...
set optionN = filedata.optionN
else
set option1 = defaultvalue1
...
set optionN = defaultvalueN
write default values to file
from open-builder.
Yeah that is pretty much it 😛 It all happens in main.cpp
from open-builder.
Thoughts on using a standard config file format such as JSON or TOML? The config file seems to already be a bit messy as well as the code to read it, with
auto data = getObdData("config.obd");
auto clientData = data[0].data;
auto serverData = data[1].data;
poorly reflecting the structure of the config file.
The only downside would be another library reference and a rework of the current config logic.
from open-builder.
No need, the config file is extremely simple
from open-builder.
I can probably update the obd parser so that it reads like
auto clientData = data["CLIENT_DATA"].data;
auto serverData = data["SERVER_DATA"].data;
from open-builder.
The config file may be simple now, but adopting a standardized markup for it is going to be necessary in the long run. Even now, we're manually parsing some options to integers while leaving others as strings. As the config file gets more options added to it, there are going to be more types to worry about (more work we have to put into a parser), and the structure will get more complex. With a markup language, the config file gets more structure, we gain support for a variety of different types, and we don't have to worry about maintaining our own parser.
Consider the current CLIENT_DATA section
CLIENT_DATA
cap_fps 0
fps_limit 60
fov 90
fullscreen 0
window_width 1600
window_height 900
skin player
texture_pack default
shouldShowInstructions 1
server_ip LOCAL
end
Intuitively, cap_fps
, fullscreen
, and shouldShowInstructions
, read as integers. Without looking at the source code, it's difficult to understand why these are represented as integers and not booleans in the config file. Also, the end
directive is unnecessary if we use an established markup language. Consider an alternative TOML implementation:
[client]
cap_fps = false
fps_limit = 60
fov = 90
...
[server]
world_size = 8
cpptoml seems to be a decent library for interacting with TOML files, and its value_or()
function seems like it would be very useful in reducing repetition when generating default values.
from open-builder.
True but eventually the config will be able to be configured via menus in the game anyways, so adding a 3600 line dependency seems a bit much 😛
I can probably simplify the parser anyways.
Originally it was going to be used for loading block types and such, hence why I have random support for sections like CLIENT_DATA and such.
It can probably be something like
cap_fps 0
fps_limit 60
fov 90
fullscreen 0
window_width 1600
window_height 900
skin player
texture_pack default
shouldShowInstructions 1
server_ip LOCAL
world_size 8
Thinking about it, Lua could be used as the project has support for this anyways
ClientConfig = {
cap_fps = false,
fps_limit = 60,
}
--etc
from open-builder.
That's a good point. I forgot that configuration would be handled by a menu in the future. I'll work on cleaning up the config with the current parser.
from open-builder.
Related Issues (20)
- Discussion: Big client refactor HOT 2
- Cleanup the Cmake
- Document Scripting API
- GUI: Checkbox widget HOT 6
- Allow GitHub actions to recognize std::filesystem, std::optional etc HOT 5
- Doc building on Windows with Visual Studio HOT 1
- Add function to GUI textbox API to limit which characters can be added to it
- Pressing ` or Caps-Lock causes the error screen to pop up HOT 2
- [Feature] Move buttons to the texture_packs/ folder instead of res/
- World generation not working on macOS
- Building HOT 2
- Lag and block error HOT 2
- Something like redstone
- Ability for custom player models, custom block models and custom player animations
- Shader compilation error on Ubuntu 20.04 LTS HOT 9
- Client-side prediction
- Compile error HOT 1
- Big Rewrite HOT 1
- Shader compilation fails depending on drivers HOT 8
- Lower Water Level HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from open-builder.