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
Added gamerule command #194
Conversation
Can I get some feedback on this? |
Gamerules are per world, so I think it would make more sense to store them in the world.ini file. The best would be to store them in level.dat, since vanilla does that, but that would probably require some changes in Cuberite itself. |
I noticed that the default gamerules.ini file wasn't pushed, and fixed it. I can move the game rules to the world.ini file. This will add a small amount of overhead, but I think it will be worth it. |
One thing I'm definitely against is having a hardcoded path for the INI file (like you did in commit 2f14d0d). The original version was better; storing them per-world would be the best, of course. Somehow CircleCI won't let me see the error I assume you were fixing with the hardcoded path, it's most likely a bug in the plugin checker. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we simplify by pretending all gamerules are string values and only their interpreter (once implemented) will convert such a value to whatever type it needs? It would simplify a lot of stuff.
Alternatively, use the string handling for all unknown gamerules, and for the known ones, we'll have a table of them and their handlers somewhere, so that table could also specify the type of the parameter.
Info.lua
Outdated
}, | ||
{ | ||
Params = "rule value", | ||
Help = "Sets a game rule value", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably should get a "WorldName" param, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I move the rules to the world ini, I'll change this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The params should be correct from the start, even if not used. Makes migration easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've fixed this
Info.lua
Outdated
Description = "Allows players to set and query game rule values", | ||
RecommendedGroups = "admins", | ||
}, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to have a separate permission for querying, and a separate one for setting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I'll add them to the permissions table.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@madmaxoft Should I have core.gamerule
allow setting and querying,
core.gamerule.query
for querying and listing only, and
core.gamerule.set
for setting only or setting and querying?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nevermind, I just made the description vague
gamerule.lua
Outdated
local grDB | ||
local ini = cIniFile() | ||
local boolean = "boolean" | ||
local number = "number" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These two lines are rather weird, can you change the name of the variables to something more descriptive of what they're used for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They won't be needed when I remove the game rule types
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, removed.
@@ -0,0 +1,75 @@ | |||
;Game Rules | |||
;This file contains all the set game rules | |||
;All values here can be configured using the webadmin interface, if enabled |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any webadmin handlers to support this claim.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't added this yet, but rest assured that it will be added.
It'd be great to have at least one gamerule actually implemented, so that we can see how it integrates with this groundwork. |
The problem with this is that there's no validation when setting game rules, also, some of the interpreters will be called lots of times, mobGriefing for example, and It would be very slow if they had to convert the value each time they were called. Maybe interpreters could register a function for validation? If |
Wow!I changed a bunch of stuff. Here's a summary:
|
To allow setting of world context in the console
@madmaxoft, What do you think of the changes so far? |
Removed duplicate code and made setting values more flexable.
Now the console and in game commands work the same way. |
Note to self: have |
@madmaxoft do you mind looking at my new commits? |
This should probably be implemented as a proper API in the server core. |
/gamerule
will list all game rules, show the value of a game rule, or set a game rule.This does not implement the actual game rules!
Also, there are a few differences between this and the vanilla command.
spawnRadius
tohello
or anything other than a number will fail (try it out in vanilla!)There's a bug that I've found, can reproduce, but can't find a pattern to.
When you try to retrieve a previously set game rule, the plugin cannot recall it in the
GameRules
table, but the rule is visible when you list the game rules. (also, the value is stored)