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
This is applicable to any project where the developers want to update the engine to take advantage of the newest features/enhancements/bugfixes.
Describe the problem or limitation you are having in your project
Our team started a new project in Godot 3.4 recently. However, one of our developers forgot that we had updated, so he made changes to the project using Godot 3.3.4 and then pushed those changes to GitHub. This caused numerous issues related to 3.4 features that weren't implemented in the older version. Luckily, only one file was affected, and we were able to restore an old version, but this could be a huge headache for teams with larger, more complex games that are further into development.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Before a project begins opening from the Project Manager, the editor would check if the project has been edited in a more recent version of Godot than is currently running -- for example, if the project was edited in Godot 3.4 but the user is trying to open it in Godot 3.3.4.
If this were the case, then before opening the project, the editor would display a warning that would say something to the effect of: "You are trying to open a project that was modified in Godot 3.4, but you are currently using Godot 3.3.4. Some of your project's functionality may be permanently broken or removed. Continue anyway?" The user would then have the option to cancel or to proceed, which is good to avoid projects being artificially "locked" into a specific version when they are at least somewhat backwards-compatible.
(The second sentence is a bit harshly worded, but I feel it is necessary to emphasize that Godot's cleanup work directly modifies the original files without confirmation.)
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
One way to implement this (which is probably the simplest) would be to add a new property to project.godot that would simply keep track of the newest editor version the project has ever been opened with. This would probably be updated while the project editor is loaded. This property would then be a factor in the check that would occur before the project begins opening from the Project Manager.
A small side benefit of this approach is that a team manager could easily "enforce" a newer Godot version for a project without installing the new version by simply editing the version in project.godot.
If this enhancement will not be used often, can it be worked around with a few lines of script?
We did attempt to give everyone a couple days of advance notice before starting the project, but humans are humans, which means that we forget and/or procrastinate sometimes.
Is there a reason why this should be core and not an add-on in the asset library?
As far as I know, editor plugins and add-ons aren't capable of modifying the Project Manager. While the feature could theoretically be implemented in the editor, at that point, it wouldn't be able to do anything except provide an apologetic notice, as the editor would have already done automatic cleanup. This would also lose the benefits of out-of-the-box convenience for a situation that applies to a wide range of groups. (It would arguably be even more vital to solo developers who may not be using a version control system.)
The text was updated successfully, but these errors were encountered:
Describe the project you are working on
This is applicable to any project where the developers want to update the engine to take advantage of the newest features/enhancements/bugfixes.
Describe the problem or limitation you are having in your project
Our team started a new project in Godot 3.4 recently. However, one of our developers forgot that we had updated, so he made changes to the project using Godot 3.3.4 and then pushed those changes to GitHub. This caused numerous issues related to 3.4 features that weren't implemented in the older version. Luckily, only one file was affected, and we were able to restore an old version, but this could be a huge headache for teams with larger, more complex games that are further into development.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Before a project begins opening from the Project Manager, the editor would check if the project has been edited in a more recent version of Godot than is currently running -- for example, if the project was edited in Godot 3.4 but the user is trying to open it in Godot 3.3.4.
If this were the case, then before opening the project, the editor would display a warning that would say something to the effect of: "You are trying to open a project that was modified in Godot 3.4, but you are currently using Godot 3.3.4. Some of your project's functionality may be permanently broken or removed. Continue anyway?" The user would then have the option to cancel or to proceed, which is good to avoid projects being artificially "locked" into a specific version when they are at least somewhat backwards-compatible.
(The second sentence is a bit harshly worded, but I feel it is necessary to emphasize that Godot's cleanup work directly modifies the original files without confirmation.)
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
One way to implement this (which is probably the simplest) would be to add a new property to
project.godot
that would simply keep track of the newest editor version the project has ever been opened with. This would probably be updated while the project editor is loaded. This property would then be a factor in the check that would occur before the project begins opening from the Project Manager.A small side benefit of this approach is that a team manager could easily "enforce" a newer Godot version for a project without installing the new version by simply editing the version in
project.godot
.If this enhancement will not be used often, can it be worked around with a few lines of script?
We did attempt to give everyone a couple days of advance notice before starting the project, but humans are humans, which means that we forget and/or procrastinate sometimes.
Is there a reason why this should be core and not an add-on in the asset library?
As far as I know, editor plugins and add-ons aren't capable of modifying the Project Manager. While the feature could theoretically be implemented in the editor, at that point, it wouldn't be able to do anything except provide an apologetic notice, as the editor would have already done automatic cleanup. This would also lose the benefits of out-of-the-box convenience for a situation that applies to a wide range of groups. (It would arguably be even more vital to solo developers who may not be using a version control system.)
The text was updated successfully, but these errors were encountered: