{"action":"created","issue":{"url":"https://api.github.com/repos/godotengine/godot/issues/13116","repository_url":"https://api.github.com/repos/godotengine/godot","labels_url":"https://api.github.com/repos/godotengine/godot/issues/13116/labels{/name}","comments_url":"https://api.github.com/repos/godotengine/godot/issues/13116/comments","events_url":"https://api.github.com/repos/godotengine/godot/issues/13116/events","html_url":"https://github.com/godotengine/godot/pull/13116","id":275519388,"number":13116,"title":"Script hierarchies for Inspector","user":{"login":"willnationsdev","id":16217563,"avatar_url":"https://avatars1.githubusercontent.com/u/16217563?v=4","gravatar_id":"","url":"https://api.github.com/users/willnationsdev","html_url":"https://github.com/willnationsdev","followers_url":"https://api.github.com/users/willnationsdev/followers","following_url":"https://api.github.com/users/willnationsdev/following{/other_user}","gists_url":"https://api.github.com/users/willnationsdev/gists{/gist_id}","starred_url":"https://api.github.com/users/willnationsdev/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/willnationsdev/subscriptions","organizations_url":"https://api.github.com/users/willnationsdev/orgs","repos_url":"https://api.github.com/users/willnationsdev/repos","events_url":"https://api.github.com/users/willnationsdev/events{/privacy}","received_events_url":"https://api.github.com/users/willnationsdev/received_events","type":"User","site_admin":false},"labels":[{"id":73330066,"url":"https://api.github.com/repos/godotengine/godot/labels/enhancement","name":"enhancement","color":"44bbff","default":true},{"id":279097966,"url":"https://api.github.com/repos/godotengine/godot/labels/topic:core","name":"topic:core","color":"ffdd44","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/godotengine/godot/milestones/7","html_url":"https://github.com/godotengine/godot/milestone/7","labels_url":"https://api.github.com/repos/godotengine/godot/milestones/7/labels","id":2529217,"number":7,"title":"3.1","description":"","creator":{"login":"akien-mga","id":4701338,"avatar_url":"https://avatars0.githubusercontent.com/u/4701338?v=4","gravatar_id":"","url":"https://api.github.com/users/akien-mga","html_url":"https://github.com/akien-mga","followers_url":"https://api.github.com/users/akien-mga/followers","following_url":"https://api.github.com/users/akien-mga/following{/other_user}","gists_url":"https://api.github.com/users/akien-mga/gists{/gist_id}","starred_url":"https://api.github.com/users/akien-mga/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/akien-mga/subscriptions","organizations_url":"https://api.github.com/users/akien-mga/orgs","repos_url":"https://api.github.com/users/akien-mga/repos","events_url":"https://api.github.com/users/akien-mga/events{/privacy}","received_events_url":"https://api.github.com/users/akien-mga/received_events","type":"User","site_admin":false},"open_issues":953,"closed_issues":1500,"state":"open","created_at":"2017-05-18T13:33:56Z","updated_at":"2018-05-29T10:05:21Z","due_on":null,"closed_at":null},"comments":27,"created_at":"2017-11-20T22:22:15Z","updated_at":"2018-05-29T14:50:23Z","closed_at":null,"author_association":"CONTRIBUTOR","pull_request":{"url":"https://api.github.com/repos/godotengine/godot/pulls/13116","html_url":"https://github.com/godotengine/godot/pull/13116","diff_url":"https://github.com/godotengine/godot/pull/13116.diff","patch_url":"https://github.com/godotengine/godot/pull/13116.patch"},"body":"Fixes #10799 \r\n\r\nDemonstration:\r\n\r\nHere are some various screenshots. These are from an environment in which I have the following structure:\r\n\r\n    # class_c.gd\r\n    extends \"res://class_b.gd\"\r\n    export(bool) var c = true\r\n    export(bool) var c2 = false\r\n    \r\n    # class_b.gd\r\n    extends \"res://class_a.gd\"\r\n    var b = true\r\n    \r\n    # class_a.gd\r\n    extends \"res://class_2.gd\"\r\n    export var a = \"a\"\r\n    export var a2 = \"a2\"\r\n    \r\n    # class_2.gd\r\n    extends \"res://class_1.gd\"\r\n    export var three = 3\r\n    export var four = 4\r\n    \r\n    # class_1.gd\r\n    extends Node\r\n    export var one = 1\r\n    export var two = 2\r\n\r\nThe only variable/class we should NOT see show up is `class_b.gd` with the single, un-exported `b` property with value `true`.\r\n\r\nIf I attach `class_c.gd` to a Node, I see this before/after:\r\n\r\n![class_c_before](https://user-images.githubusercontent.com/16217563/34071983-f3f6c350-e244-11e7-803c-85046580828a.PNG)\r\n![class_c_after](https://user-images.githubusercontent.com/16217563/34071939-464641cc-e244-11e7-808c-4bc14bff6155.PNG)\r\n\r\nIf I have a builtin script with exported `builtin1` and non-exported `builtin2`, then I get this before/after (`script_test.tscn` is the name of the scene and the built-in script extends a `Node` type):\r\n\r\n![builtin_script_before](https://user-images.githubusercontent.com/16217563/34071953-5a8c3182-e244-11e7-9194-b969c4976b17.PNG)\r\n![builtin_script_after](https://user-images.githubusercontent.com/16217563/34071955-60a4e1fe-e244-11e7-8c16-cfe749116b81.PNG)\r\n\r\nIf I have `class_c` open, and I change it to extend from `class_2` instead of `class_b`, but I HAVEN'T saved it yet, then I will see this before/after (looks the same as the saved version, which was the goal):\r\n\r\n![derive_2_not_b_unsaved_c_before](https://user-images.githubusercontent.com/16217563/34071961-7f72b336-e244-11e7-9e45-b2f5a74a13a7.PNG)\r\n![derive_2_not_b_unsaved_c_after](https://user-images.githubusercontent.com/16217563/34071963-83ce9044-e244-11e7-93df-885e61020f3d.PNG)\r\n\r\n~~In the course of doing this, I did find another small bug for the unsaved scripts (going from less derived to more derived base class in an unsaved script. In this case, I went from `class_1` to `class_a`, so `class_2` and `class_a's variables are showing up under `class_1`'s), so it seems it still needs some more work.~~\r\n\r\nEdit: Oh wait! No, that's a purposeful \"bug\". If you ADD scripts and properties to the inheritance hierarchy, but the script hasn't been saved, the `p_list` ends up with all of these extra properties and doesn't yet know about the new scripts, so it just bundles them all underneath the most relevant script it can find. It gets revised when you actually save the script.\r\n\r\n![derive_a_not_1_unsaved_c_after](https://user-images.githubusercontent.com/16217563/34072091-d5a3f3d0-e246-11e7-96e0-07fefc8d23c0.PNG)\r\n(after saving:)\r\n![class_c_after](https://user-images.githubusercontent.com/16217563/34072148-8ede8266-e247-11e7-9a86-cd2fa65a506b.PNG)\r\n\r\nIncidentally, if you add a script to a node that has nothing else in the script hierarchy, and the script is not yet saved (so it doesn't have a name yet), AND if it has export variables that show up in the Inspector, then it starts autonaming the category blocks with \"Class 0\", \"Class 1\", etc. for every script that isn't yet saved. If anywhere in the script hierarchy there is a saved script, then all of the unsaved scripts' properties are assumed to belong to the saved script, until those other scripts are saved. This is why we see the \"buggy\" behavior above. Here's what this algorithm results in for the objects with no saved scripts:\r\n\r\n![unsaved_new_script_export](https://user-images.githubusercontent.com/16217563/34072268-c8464fd2-e249-11e7-8569-1ecf3283d0ad.PNG)\r\n\r\nRegardless of whether this ends up as part of the 3.0 release or not, I might actually start extending this out into a full on overhaul of custom types in general, targeting a 3.1 release. This would be a critical change to have for a full custom type simulation across the engine.\r\n\r\nEdit:\r\n\r\nHere are some various screenshots. These are from an environment in which I have the following structure:\r\n\r\n    # class_c.gd\r\n    extends \"res://class_b.gd\"\r\n    export(bool) var c = true\r\n    export(bool) var c2 = false\r\n    \r\n    # class_b.gd\r\n    extends \"res://class_a.gd\"\r\n    var b = true\r\n    \r\n    # class_a.gd\r\n    extends \"res://class_2.gd\"\r\n    export var a = \"a\"\r\n    export var a2 = \"a2\"\r\n    \r\n    # class_2.gd\r\n    extends \"res://class_1.gd\"\r\n    export var three = 3\r\n    export var four = 4\r\n    \r\n    # class_1.gd\r\n    extends Node\r\n    export var one = 1\r\n    export var two = 2\r\n\r\nThe only variable/class we should NOT see show up is `class_b.gd` with the single, un-exported `b` property with value `true`.\r\n\r\nIf I attach `class_c.gd` to a Node, I see this before/after:\r\n\r\n![class_c_before](https://user-images.githubusercontent.com/16217563/34071983-f3f6c350-e244-11e7-803c-85046580828a.PNG)\r\n![class_c_after](https://user-images.githubusercontent.com/16217563/34071939-464641cc-e244-11e7-808c-4bc14bff6155.PNG)\r\n\r\nIf I have a builtin script with exported `builtin1` and non-exported `builtin2`, then I get this before/after (`script_test.tscn` is the name of the scene and the built-in script extends a `Node` type):\r\n\r\n![builtin_script_before](https://user-images.githubusercontent.com/16217563/34071953-5a8c3182-e244-11e7-9194-b969c4976b17.PNG)\r\n![builtin_script_after](https://user-images.githubusercontent.com/16217563/34071955-60a4e1fe-e244-11e7-8c16-cfe749116b81.PNG)\r\n\r\nIf I have `class_c` open, and I change it to extend from `class_2` instead of `class_b`, but I HAVEN'T saved it yet, then I will see this before/after (looks the same as the saved version, which was the goal):\r\n\r\n![derive_2_not_b_unsaved_c_before](https://user-images.githubusercontent.com/16217563/34071961-7f72b336-e244-11e7-9e45-b2f5a74a13a7.PNG)\r\n![derive_2_not_b_unsaved_c_after](https://user-images.githubusercontent.com/16217563/34071963-83ce9044-e244-11e7-93df-885e61020f3d.PNG)\r\n\r\n~~In the course of doing this, I did find another small bug for the unsaved scripts (going from less derived to more derived base class in an unsaved script. In this case, I went from `class_1` to `class_a`, so `class_2` and `class_a's variables are showing up under `class_1`'s), so it seems it still needs some more work.~~\r\n\r\nEdit: Oh wait! No, that's a purposeful \"bug\". If you ADD scripts and properties to the inheritance hierarchy, but the script hasn't been saved, the `p_list` ends up with all of these extra properties and doesn't yet know about the new scripts, so it just bundles them all underneath the most relevant script it can find. It gets revised when you actually save the script.\r\n\r\n![derive_a_not_1_unsaved_c_after](https://user-images.githubusercontent.com/16217563/34072091-d5a3f3d0-e246-11e7-96e0-07fefc8d23c0.PNG)\r\n(after saving:)\r\n![class_c_after](https://user-images.githubusercontent.com/16217563/34072148-8ede8266-e247-11e7-9a86-cd2fa65a506b.PNG)\r\n\r\nIncidentally, if you add a script to a node that has nothing else in the script hierarchy, and the script is not yet saved (so it doesn't have a name yet), AND if it has export variables that show up in the Inspector, then it starts autonaming the category blocks with \"Class 0\", \"Class 1\", etc. for every script that isn't yet saved. If anywhere in the script hierarchy there is a saved script, then all of the unsaved scripts' properties are assumed to belong to the saved script, until those other scripts are saved. This is why we see the \"buggy\" behavior above. Here's what this algorithm results in for the objects with no saved scripts:\r\n\r\n![unsaved_new_script_export](https://user-images.githubusercontent.com/16217563/34072268-c8464fd2-e249-11e7-8569-1ecf3283d0ad.PNG)\r\n\r\nRegardless of whether this ends up as part of the 3.0 release or not, I might actually start extending this out into a full on overhaul of custom types in general, targeting a 3.1 release. This would be a critical change to have for a full custom type simulation across the engine.\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/godotengine/godot/issues/comments/392805190","html_url":"https://github.com/godotengine/godot/pull/13116#issuecomment-392805190","issue_url":"https://api.github.com/repos/godotengine/godot/issues/13116","id":392805190,"user":{"login":"willnationsdev","id":16217563,"avatar_url":"https://avatars1.githubusercontent.com/u/16217563?v=4","gravatar_id":"","url":"https://api.github.com/users/willnationsdev","html_url":"https://github.com/willnationsdev","followers_url":"https://api.github.com/users/willnationsdev/followers","following_url":"https://api.github.com/users/willnationsdev/following{/other_user}","gists_url":"https://api.github.com/users/willnationsdev/gists{/gist_id}","starred_url":"https://api.github.com/users/willnationsdev/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/willnationsdev/subscriptions","organizations_url":"https://api.github.com/users/willnationsdev/orgs","repos_url":"https://api.github.com/users/willnationsdev/repos","events_url":"https://api.github.com/users/willnationsdev/events{/privacy}","received_events_url":"https://api.github.com/users/willnationsdev/received_events","type":"User","site_admin":false},"created_at":"2018-05-29T14:50:23Z","updated_at":"2018-05-29T14:50:23Z","author_association":"CONTRIBUTOR","body":"@toger5 \r\n\r\n> maybe a second function for parsing doc information to DocData could be created which parses it directly from the script file itself. with custom comments which than represent the documentation for a fucniton/member. how feasible do you think this would be?\r\n\r\nYou are probably looking for the annotations feature that has been discussed somewhere (I can't seem to find the related Issue(s)?). At one point, we were throwing around the idea of adding @-based annotations in GDScript so that you could add metadata about class content for documentation and autocompletion features. So, something like...\r\n\r\n@param p_a: variant, The first parameter.\r\n@param p_b: variant, The second parameter.\r\n@return variant, The sum.\r\nfunc add(p_a, p_b):\r\n----return p_a + p_b"}}
{"actor":{"display_login":"willnationsdev"}}