You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently working on the Github Game Off jam game I started, which includes several enemies that use state machines to handle both the physics of moving, and the physics of taking damage (as separate states stored in the same machine). https://github.com/WolfgangSenff/GameOffJam2020
Describe the problem or limitation you are having in your project
I've noticed whenever I have to reference one of the state machines I mentioned above - as well as the states themselves (and any nodes within those) - if the enemies is defeated and queue-freed, if anything with in a yield state or anything like that, when it comes back it's still causing a ton of issues. Not only that, but it can still call to the state machine to handle damage/physics (especially physics in this case, since that's in the _physics_process method). is_instance_valid is necessary for this case (and sometimes I have to check for nullity as well), but I call it for multiple objects at times and it is really clunky, especially combined with a null check, even if that null check is just if variant. Combine that with the fact that if multi-threading is turned on, it seems like if you have an is_instance_valid in an if, the code in the if is not called as a single operation, and so could become unsafe to use even after calling is_instance_valid. Note: I do not know this for a fact, I'm just inferring it from how other languages work; please correct me if I'm wrong (mostly because I typically do not turn on multi-threading for Godot and I'd genuinely like to know).
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Essentially, it would cut down on highly error-prone code and code that already, in and of itself, feels sort of hacky since you wouldn't expect it to be running in the first place (since the object was in my examples/games queue-freed already). Not only this, it significantly cuts down on the number of lines of code, which for most code-bases for any sufficiently complex game would be extremely helpful.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
The main proposal is simply having this as an example:
It's unclear to me at this point if the expanded code can effectively be forced into a single operation similar to how it's done in other languages, but it wouldn't strictly be necessary...just, in theory, much better for multi-threading. (Again, this is just my inference from other languages.)
If this enhancement will not be used often, can it be worked around with a few lines of script?
Technically, this is just meant to be a way to significantly shorten code that comes up a lot in GDScript when working with things which run during _process or _physics_process, so while it definitely can be "worked around", the whole point is to not have to work around it - to make the code simpler to read by many factors while removing error-prone code.
Is there a reason why this should be core and not an add-on in the asset library?
I don't believe it can be an add-on - at the least, it feels like a very core piece of functionality to the language. Let me put it this way: I do not see any way it can be an add-on.
The text was updated successfully, but these errors were encountered:
Describe the project you are working on
Currently working on the Github Game Off jam game I started, which includes several enemies that use state machines to handle both the physics of moving, and the physics of taking damage (as separate states stored in the same machine). https://github.com/WolfgangSenff/GameOffJam2020
Describe the problem or limitation you are having in your project
I've noticed whenever I have to reference one of the state machines I mentioned above - as well as the states themselves (and any nodes within those) - if the enemies is defeated and queue-freed, if anything with in a yield state or anything like that, when it comes back it's still causing a ton of issues. Not only that, but it can still call to the state machine to handle damage/physics (especially physics in this case, since that's in the _physics_process method). is_instance_valid is necessary for this case (and sometimes I have to check for nullity as well), but I call it for multiple objects at times and it is really clunky, especially combined with a null check, even if that null check is just
if variant
. Combine that with the fact that if multi-threading is turned on, it seems like if you have an is_instance_valid in an if, the code in the if is not called as a single operation, and so could become unsafe to use even after calling is_instance_valid. Note: I do not know this for a fact, I'm just inferring it from how other languages work; please correct me if I'm wrong (mostly because I typically do not turn on multi-threading for Godot and I'd genuinely like to know).Describe the feature / enhancement and how it helps to overcome the problem or limitation
https://en.wikipedia.org/wiki/Safe_navigation_operator
Essentially, it would cut down on highly error-prone code and code that already, in and of itself, feels sort of hacky since you wouldn't expect it to be running in the first place (since the object was in my examples/games queue-freed already). Not only this, it significantly cuts down on the number of lines of code, which for most code-bases for any sufficiently complex game would be extremely helpful.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
The main proposal is simply having this as an example:
This would equate to the following expanded code:
It's unclear to me at this point if the expanded code can effectively be forced into a single operation similar to how it's done in other languages, but it wouldn't strictly be necessary...just, in theory, much better for multi-threading. (Again, this is just my inference from other languages.)
If this enhancement will not be used often, can it be worked around with a few lines of script?
Technically, this is just meant to be a way to significantly shorten code that comes up a lot in GDScript when working with things which run during _process or _physics_process, so while it definitely can be "worked around", the whole point is to not have to work around it - to make the code simpler to read by many factors while removing error-prone code.
Is there a reason why this should be core and not an add-on in the asset library?
I don't believe it can be an add-on - at the least, it feels like a very core piece of functionality to the language. Let me put it this way: I do not see any way it can be an add-on.
The text was updated successfully, but these errors were encountered: