-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
Add categories to GDScript exported variables #10303
Conversation
New keyword |
I seriously consider GDScript would benefit from attributes to avoid so many new keywords. EDIT: For example, if #9469 was merged, it would simply be: @category xyz
export var x = 2
@category xyz/test
export var y = 5 No modifications to the language, you would just check the field attributes. Less complexity. Even |
Closes godotengine#4378 via the 4th proposal, as it is easiest to implement
f1916c5
to
cfe71c0
Compare
@neikeq exactly, that could had been a good use for annotations. @bojidar-bg this is cool, thanks! |
Well we don't have attributes in gdscript, but this pr (ability to create exported var categories) is still cool. |
Needs rebase after #12969, sorry :D |
Please stop adding new keywords to GDScript! |
I think I will not be rebasing this right now, since the community doesn't seem to like having more keywords in GDScript. What might get implemented is the proposal in #10799 (comment), which is to have the script's name instead of "Script Variables", thus splitting variables from extended scripts. You might react with 👍 if this proposal sounds better to you, with 👎 if you think it won't be any better than current master, and with 😕 if you think this proposal is worse than the one currently implemented in this PR (you might want to also write a comment with why you think so). |
Derived scripts being separate is fine and dandy but I often find myself with so many variables in a single script that I need categories within this single script. (Mostly a consequence of the fact that I use tool scripts A LOT) |
I agree, too many keywords, we should have annotation support at this point. |
Afte thinking about it, i would do export_category so only text like export_category "hello" would be good, and that's it. |
also do not accept indentifiers in there, it's really confusing |
I think I will close this PR for now, maybe to be reopened some time after 3.1 starts. Sorry to everyone who needs it now, but, seems like more GDScript enchancements would come later 😃 |
@juan-garcia-m's PR was perfect for this IMO. The only thing I would add to it is to optionally use parenthesis for the parameters, this way the attribute can be in the same line as the declaration. |
@neikeq I did indeed added parenthesis at first, but I removed them as it seem more in the style of GDScript. |
@juan-garcia-m you are implementing java externally? That is interesting. What VM will you use? |
@juan-garcia-m Your commits are still available in #9469 :) |
@neikeq Oh! I see :) @kubecz3k IKVM.NET, abusing the fact that we have official Mono support. You will still need to have Mono installed (and a JDK of course), but even Godot itself will be downloaded by the Gradle plugin I am writing. Having addons as dependencies, automatic typed scenes and Eclipse support is on the way. Hopefully I will publish an Alpha in the coming weeks. |
@bojidar-bg I confirm the ability to create both categories and groups with this method (3.2): Those prefixes are still visible though, not sure how to hide them to make less verbose in the inspector this way. Here's how I do it: func _get_property_list():
var props = []
add_category("Arms", props)
add_group("Left", props)
add_property("left_layer_ofs_1", TYPE_REAL, 1 / 3.0, props)
add_property("left_layer_ofs_2", TYPE_REAL, 2 / 3.0, props)
add_group("Right", props)
add_property("right_layer_ofs_1", TYPE_REAL, 1 / 3.0, props)
add_property("right_layer_ofs_2", TYPE_REAL, 2 / 3.0, props)
return props
func add_group(p_name, r_properties: Array):
r_properties.push_back({
name = p_name,
type = TYPE_NIL,
hint = PROPERTY_HINT_NONE,
usage = PROPERTY_USAGE_GROUP | PROPERTY_USAGE_SCRIPT_VARIABLE,
}
)
func add_category(p_name, r_properties: Array):
r_properties.push_back({
name = p_name,
type = TYPE_NIL,
hint = PROPERTY_HINT_NONE,
usage = PROPERTY_USAGE_CATEGORY | PROPERTY_USAGE_SCRIPT_VARIABLE,
}
)
func add_property(p_name, p_type, p_value, r_properties: Array):
r_properties.push_back({
name = p_name,
type = p_type,
value = p_value
}
) |
@Xrayez In Lines 924 to 931 in 26ecd92
So, something like this will work: func _get_property_list():
…
add_group("Left", "left_", props)
…
add_group("Right", "right_", props)
…
func add_group(p_name, p_prefix, r_properties: Array):
r_properties.push_back({
…
hint_string = p_prefix,
…
}
)
… |
This is lovely, can one of the snippets go somewhere in documentation? At last, my exported variables won't be a total mess in debugger <3 <3 |
Yep, works like a charm! @Zireael07 For instance, those EDIT: this info could likely be added to http://docs.godotengine.org/en/latest/getting_started/scripting/gdscript/gdscript_exports.html |
It would be really nice if inspector groups were not something embedded inside |
@Xrayez This works, but how do you access the variables? |
why hasn't this been merged in 4 years? |
Check mentions above it was implemented differently and is merged and used for GDScript 2.0 |
I had a look at the PR linked from this issue to the GDScript 2.0 docs, and it seems it doesnt mention category annotations anywhere. The 3.x way of doing it was erased with no replacement: https://github.com/godotengine/godot-docs/pull/4247/files |
See godotengine/godot-docs#3623 (comment), perhaps there might be a thing like dynamic annotations? Who knows, there's no GDScript 2.0 specification out there publicly available... 😛
Late to respond but usually dynamically created variables can be accessed with And yeah, you'll have to either:
|
Proposal: godotengine/godot-proposals#1255 |
Closes #4378 via the 4th proposal, as it is easiest to implement
Supports:
Does not yet support:
But, most of all, needs some extra testing, as I might have broken things.