Hey there,
using GDscript for a good amount of time, I had used Boolean so often, but when I use logical Conditions/Statements on it sometimes i had to create a Second Boolean variable as a FLAG to check that the condition only should be active once and soo froth. Instead of create 2 Boolean if there were 3 data values for Boolean like some coding Language I haired “true” , “false” and “maybe“. it must be greate.
Best Regards…
You should use an enum for this, rather than a boolean:
Will this solve a problem(not a grate one) -
1. I have to recreate it again and again and use EnumName.Value
I’m surprised you’d recreate the same enum often, you should try to make the enum values more relevant to the actual representation, more than YES/NO/MAYBE (unless you are making a 20 questions game). Giving more information about your project and actual issue may help.
If using a class_name you can avoid the global.
Where did you get the 4 vs 1 byte figure? If you are worried about 3 bytes wasted you should check out GDExtensions otherwise you will not be able to optimize memory layout in such a way.
yeah that 1 and 4 byte figure was from c++. i searched how to get enum memory size but no code was working for me.. according to gemini for godot for a enum it’s 8 byte. now thats the problem.
i will check how can i use class_name.
enum newBool = {
True,
False,
Maybe
};
#code i don't want
var condition : newBool = newBool.Maybe;
#code i want
var condition2 : newBool = Maybe;
#what i am asking for
var condition3 : bool = maybe;
i am not making a quiz game, but sometimes i feel like i need something like progress boolean thing.
sure i can use a float and int :
var condition : float = 0.0 # false
var condition2 : float = 0.5 # maybe
var condition3 : float = 1 # true
is this ideal to do or use.
Creating third value for boolean will give us more combination and control over them isn’t it
oh i get it there will be some limitation as godot is built on language like c++ and not in assembly creating something like that might be impossible
Care to elaborate on why you consider this to be a problem?
Your alternatives using int/float, while perhaps workable, are strange and not to many people in their right mind would do this.
The solution you are looking for is, as has already been mentioned, enum.
Also, maybe look up the definition of boolean, the tri-state type you are suggesting is, by definition, not a boolean.
Edit: Actually, using an int here is pretty normal, plenty of people would to that; the float seems bizarre, but if you modelling ‘progress’ of something, a normalised float (0.0 → 1.0) would be perfectly sensible…. context is everything.
enum is great for progression, an actual use case could be quest progression where you wouldn’t use “true/false/maybe” but the states of the quest “unknown/accepted/completed” and any other in between.
There are no programming languages that have three values for a boolean. You may have heard of SQL (Structured Query Language) which technically allows an “unknown” null value as a third option. You can do this with a boolean value in GDScript. Test for null before testing for true/false in a boolean. If it isn’t set, it will be null. You have to do this separately though, because a boolean set to null evaluates to false if tested for true/false.
Yup. Or…
If you’re only wanting something to happen once, store the value on disk. Get the value from disk, and if it’s null, it hasn’t happened yet. If it’s not null, then it has happened, and you can test separately what actually happened.
In what universe? 1980? Modern processors are 32-bit and 64-bit processors (4 bytes and 8 bytes respectively). That means that something that is only 1-byte actually is accessed slower - so processors (and the languages that use them) pad the 1-byte value with extra bits. So if you are running on a modern computer with a 64-bit processor (i.e. you bought your computer in the last 12 years for sure, but potentially in the last 20 years), you are running a 64-bit processor. Which means a boolean value, which only takes up one bit, actually consumes 8-bytes of memory to be processed as quickly as possible.
But wait, it gets better! A bool value in Godot is actually a Variant under the hood, and takes up 20 bytes. Meanwhile, an enum is an int under the hood, and takes up 8 bytes. Which means using a bool in Godot is less memory efficient than an enum!
You are trying to optimize something that does not need to be optimized. Modern compilers and interpreters (Godot is the latter) are optimized under the hood to actually take whatever you write and make it more efficient than you can on your own using the language. There is not a game in the world you could make where enum values is going to be the memory or processing speed bottleneck over your graphics.
So, instead of trying to solve this optimization non-problem, focus on writing your code so that it is easy for you to read and debug.
P.S. This should not be a forum feedback post.
thanks dragonforge-dev, using a null value for a boolean is great idea and it is my solution i didn’t thought about it.
and i can’t find out that language which is having 3 data types
edit : i am not begin able assign null to a bool after it is created;
godot already offers a wide range of tricks
LEAVE it, there are many way that i can solve a problem without having three value boolean; it’s just a dumb question
You might want to use C# instead of GDscript if you really need that feature. In C# you can simply have nullable bools:
bool? isAlive = null;
Love it, sadly i am more friendly with gdscript, i will think to shift to c#,
Thanks man
Once you learn C# you’ll never want to use another language (I started learning it in 2017 and never looked back).
Have you used GDScript? Because I started using C# professionally about 20 years ago and loved it. It’s great for what it is. I really enjoyed it over C++ because I no longer had to do memory management. I used it for many years. But I have used both GDScript and C# with Godot and you couldn’t pay me to use C# over GDScript for Godot. (Literally - I’ve turned down paying jobs.)
Iteration speed in development is SO much faster in GDScript, because you don’t have to compile - which takes a long time in C# compared to just starting the game with GDScript. It literally takes more than twice as long just to open my C# game as it does any comparably-sized GDScript game. You can make changes to the code while your game is running and see the differences in real time. And GDScript’s performance has been improved so much over the past few nears that it not only matches C# in most places, it actually exceeds in it some cases now. Also, while hopefully you will able to do web exports again soon in C#, you can do them now with GDScript.
I said it would work for that one scenario. I did not say it was nullable.
You could also just use an int and use -1, 0, and 1 if you don’t want to use long enum names. It’s the smallest sized variable you’re going to get.
So untrue. I learnt it in the naughties, and have used modern versions occasionally since, I sincerely look forward to never using it ever again.
“Pure OO” garbage.
Off topic: I wouldn’t get that far. I started using C# when it still was 1.0 and used various times in the past 20 years. It is rather surprising that it got a foot hold into game development. On the other hand there was nothing else to compete with C# in certain niches.
With Godot I really love GDScript. It what makes it unique and very pleasant to learn. I will never go back to C# for game dev.
I was about to jokingly suggest opening a proposal to add Trooleans to Godot, but then I thought “there’s no way somebody didn’t think of this before”. Lo and behold, somebody did: GitHub - RobTillaart/Troolean: Arduino Library for a three state logic datatype supporting {True False Unknown}
C++ and MIT licensed, just yoink it and call it a day, lmao.
The Troolean evaluates very oddly:
true && unknown ==> unknown
false && unknown ==> false
true || unknown ==> true
false || unknown ==> unknown
!unknown ==> unknown
It’s logical, but odd. This sounds like a communication nightmare. Seeing this in code is like seeing a ternary operator. It’s clever, but not nearly as readable as the alternatives.
Things like ternary operators were created in the 60s to hack the processing speed and memory requirements of compilers. It was adopted by C in the 70s. At the time, it actually made a difference in how fast the compiler processed the code. They no longer do have that effect. Compilers and interpreters are optimized way more than we can do when writing our code in high-level languages. Now, these things are just clever ways to reduce the number of lines of code for coding challenges or to frustrate the person who has to come after you and read your code. (In my experience that person is usually future you, who is not impressed with past you.)
As I’ve thought about this problem, I think that if this is for tracking quests for example, you should just create a Quest object, probably a Resource to track it. And under the hood store an int or use an Enum, but make it easy to see what it does so you can utilize it without ever having to look at the implementation code.
A new problem with overly clever Godot code these days is that if you post it here for help, and it’s full of things like weirdly used binaries, one-letter variable names, and overly-complex math, it looks like LLM-generated code. And the consensus seems to be for most users in this forum to just ignore posts that look like that.
looks like a challenge to me 