-
Notifications
You must be signed in to change notification settings - Fork 27
Revamp variable system #107
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
Conversation
addons/block_code/ui/block_canvas/node_block_canvas/node_block_canvas.gd
Outdated
Show resolved
Hide resolved
After punting on the compatibility, I still have a few questions.
|
Sure, the sound blocks using
Definitely not blocked, only really needed T35536 if we were going to make a migration system, which we will hold off on for now.
I haven't! Will definitely get some feedback and fix the sound blocks. |
Converted to draft for now as I work on fixing the sound blocks, which has brought up more of a problem than I expected. Will continue tomorrow, but push my working but ugly solution now. Also have to rebase. |
9363cee
to
e7af2df
Compare
Ok, after fixing some weird bugs, it seems to be working great. New variables system is working as before. You can now define unique local variables in block statements by suffixing them like Edit: Just added one last fix to remove dictionary that can be replaced by |
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.
Overall, I like this a lot. Thanks for changing the sound blocks in pong, too. That shows the practical implication of this kind of change.
addons/block_code/ui/block_canvas/node_block_canvas/node_block_canvas.gd
Outdated
Show resolved
Hide resolved
Thanks for the review @dbnicholson there's definitely some changes I should make here. |
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'm happy with this. A couple small suggestions for things to tweak. It bothered me that variables
is a property of BlockScriptData instead of part of block_trees, but I see how it would be difficult to do the latter with our current design.
Some UX things which I can understand leaving for a follow-up, but I'll note them here for the moment. In this screenshot…
- Because of the notch at the bottom, the "Set Name to …" block looks like it's closer to "Age" (below it) than to "Name" (above it).
- I'm finding all this white on orange text kind of difficult to parse. Two reasons: shallow colour contrast, and it's just a lot of orange. We definitely need to have a good discussion about block design in general at some point.
- You didn't touch it here, but I'm not sure if that "To String" block is doing anything for us.
VAR_DICT[{name}].set_stream(load({file_path})) | ||
add_child(VAR_DICT[{name}]) | ||
var sound__ = AudioStreamPlayer.new() | ||
sound__.name = {name} |
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.
Can we prefix this name with something to reduce the opportunity for clashes?
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 think that's a good idea even though with the suffixed counter it's unlikely to clash. Still, I think the common convention is that you prefix internal variables with _
or __
. Furthermore, we could add in something semi-unique like bcp
(for Block Code Plugin). So, __bcp_<something>
.
In fact, if this variable isn't going to be exposed to the user, then there's no need to name it like the thing it's for at all. So, you just declare all the internal variables __bcp
. The generator recognizes that (without tricky regex matching or trimming any parts) and suffixes the generated variable with a <counter>
or _<counter>
.
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 think the whole point of generating the script like this is to have it exposed to the user, otherwise we could just have a library function like Lib.play_sound()
that would bypass the need for local variables anyways.
That's also why I implemented a counter, instead of having a unique ID appended to each variable, because it makes the code look a lot nicer. Anyways, a prefix will definitely help here since we can also prevent the user from creating variables with our prefix.
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.
That's fair. I think just _
or __
prefix is good enough to make conflict with a user supplied variable extremely unlikely.
VAR_DICT[{name}].volume_db = {db} | ||
VAR_DICT[{name}].pitch_scale = {pitch} | ||
VAR_DICT[{name}].play() | ||
var sound_node__ = get_node({name}) |
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.
That we're adding a node to the scene and then just getting it like this really does hint at other approaches to blocks like this one (what's stopping us from telling developers to "add an AudioStreamPlayer
in the scene and use a block to call play() on it"). But that's for another day ;)
addons/block_code/ui/picker/categories/variable_category/create_variable_button.gd
Outdated
Show resolved
Hide resolved
addons/block_code/ui/picker/categories/variable_category/create_variable_button.tscn
Outdated
Show resolved
Hide resolved
Instead of accessing variables by VAR_DICT, use GDScript properties. Add a new "variables" property to block script data resource. Add a menu for creating variable of specific type. Validate new variable name and check for conflicts with existing variables.
Allows us to declare local variables in block scripts with unique names. Uses new static functions in InstructionTree to handle this. For example, "var __temp = 0" in a block statement will become "var temp_1 = 0" in the generated code.
Ok, I made a bunch of requested changes. Ready for review!
|
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.
Admittedly I kinda glossed over the last set of changes, but it looks like you addressed the things that I commented on. Time to land this plane!
This removes the old variable system we had with the VAR_DICT, and replaces it with a menu for creating typed variables that you can use as blocks.
Side note: We will need to fix the sound blocks after this is merged, since they use the VAR_DICT. I think it would be good to have some library functions or a singleton our blocks can call on for more behavior like this.
https://phabricator.endlessm.com/T35535