-
-
Notifications
You must be signed in to change notification settings - Fork 97
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
Improve usability of bitflag fields in GDScript #923
Comments
Marginally related but I used those bit flag enums in GDScript by bit shifting: godotengine/godot#23843, this feature got regressed in 3.2 but then fixed in 4.0... So I guess I'd find this proposal useful, I'm not sure whether this is relevant with GDScript 2.0. |
godotengine/godot#62374 should improve the documentation side of this already. That said, since enums remain integers in GDScript (and can't have methods attached to them), adding bitfield helper methods could probably only be done by adding global scope methods. |
4.0 already exposes bitfields, but there is no way to define them in GDScript. I suppose adding a |
@Calinou If we added #2816, then the engine could actually define a built-in struct You could then end up with something like this maybe? @bitfield # as you suggest, would just automate 2^n bit-flag initialization of the enum values
enum AttackType {
ATTACK_PHYSICAL,
ATTACK_FIRE,
ATTACK_COLD,
ATTACK_ACID,
}
func _ready():
var my_attack = Enum(AttackType)
my_attack = my_attack.set(ATTACK_PHYSICAL)
my_attack = my_attack.clear(ATTACK_FIRE)
my_attack = my_attack.toggle(ATTACK_ACID)
var is_frosty = my_attack.has(ATTACK_COLD)
var actual_int_value = my_attack.value |
Been thinking about this one after it was requested again on Reddit and since it seems to have a fair amount of support! :) I'm having a hard time seeing something like Here's a sketch of an alternative proposal:
I don't immediately know that we can do proper type checking with a globalscope |
See also godotengine/godot#71234. |
@sp3llwe4ver was the person who mentioned this on Reddit, actually! :) Just pinged them there as well. Will edit the above proposal to address the editor concerns as well, which I totally forgot. I think generally this proposal would mostly make |
|
If we add a separate syntax for flags, then it also makes sense to add a |
Reproduction of godotengine/godot#17708
Describe the project you are working on:
RPG gameplay systems that involve defining bit flag enum values.
Describe the problem or limitation you are having in your project:
While it is efficient and useful to work with bit flag enums, inexperienced programmers (and even me sometimes) can find it difficult to parse code that uses bitwise operations to modify and/or evaluate the state of those enums.
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
There should be a more human-readable API for working with bit flag enums in GDScript:
(This interface is courtesy of @romlok who commented on the original issue)
The
.set()
,.clear()
,.toggle()
, and.has()
methods would all bevararg
operations that accept a comma-separated list of potential things to mutate/check.Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
GDNativeClass
(perhapsGDBitFlag
?), that has an alternative API, but which evaluates as an int when prompted.Of course, these would only exist within GDScript code, so if you exported one of these, it would be exactly like if you'd exported a regular enum with the
FLAGS
hint.If this enhancement will not be used often, can it be worked around with a few lines of script?:
I would use it regularly, as I'm sure others would too. It can be worked around with a few lines of script (since you can resort to bitwise operations for all of this), but the usability and readability would suffer which is exactly the problem this proposal wants to resolve.
Is there a reason why this should be core and not an add-on in the asset library?:
It would be possible for you to simply create a BitFlag Resource script that has most of these features, and then have exporting it generate an interface similar to that of the existing enum flag export. It's just that, the whole point is to improve the usability of GDScript as a language. And the entire selling point of GDScript is its usability, so to leave this idea as an addon rather than a built-in feature kind of defeats the point.
The text was updated successfully, but these errors were encountered: