Nighty Build not compatible

MagicLord

Hi there,

I tried to run my metroid like game with Godot Nighty Build. When the project is loading there is many broken dependencies about textures while on previous Godot version it works. Trying to run the game it shows many errors and it is unable to play the game.

Does Godot nighty builds break scene format compatibility ? Will we have to rework the whole game for each new version ? :#

Schuster

Yes, I confirmed this...,the project edited/created in 3.1 nightly builds will not open in the 3.0.6 version anymore.....I also encountered a mipmap problem/bug? ("black shading" when displaying a textured landscape mesh) when the mipmap for the texture turns off so it disappears.

MagicLord

We should have been informed previous version 3D projects are not compatible with 3.1 nighty builds.

TwistedTwigleg

I have not tried the latest nightly builds, but when I opened the FPS tutorial a month or two ago with a nightly build (to fix something) and then tried opening it in Godot 3.0 it would not open.

Changing a single line in the project.godot file made it where I could open the project (change config_version = 4 to config_version = 3) but unfortunately all of the input bindings were lost. Everything else worked though, including scripts (after removing Godot 3.1 specific code), so I’m guess the input bindings are dropped due to a change in the nightly/master version...

You may be able to change versions by changing the project.godot file, but I would highly recommend making a backup before changing as switching back to Godot 3.0 could break things.

Ace_Dragon

It could be related to a major regression in texture loading (caused by the commit that introduced 3D texture formats). The issue has already been reported. https://github.com/godotengine/godot/issues/20904

MagicLord

Perhaps Godot needs an automated migration feature (migrating a project as best as possible). In Unity when you try to run a project on a new version, it asks you to back up the project and ask you to confirm if you wish to migrate the project. It re import all textures and models and makes the other changes for you.

Ace_Dragon

@MagicLord said: Perhaps Godot needs an automated migration feature (migrating a project as best as possible). In Unity when you try to run a project on a new version, it asks you to back up the project and ask you to confirm if you wish to migrate the project. It re import all textures and models and makes the other changes for you.

Or it could just be a regression. An intentional break of backwards compatibility (as seen with 2.x > 3.x) would likely be made clear through an article on the main website. The report just caught the attention of project manager Akien and Reduz is now tasked with fixing it.

MagicLord

@Ace Dragon said:

@MagicLord said: Perhaps Godot needs an automated migration feature (migrating a project as best as possible). In Unity when you try to run a project on a new version, it asks you to back up the project and ask you to confirm if you wish to migrate the project. It re import all textures and models and makes the other changes for you.

Or it could just be a regression. An intentional break of backwards compatibility (as seen with 2.x > 3.x) would likely be made clear through an article on the main website. The report just caught the attention of project manager Akien and Reduz is now tasked with fixing it.

I don't mind if some compatibility must be broken for Godot to become better (this happens with many releases in UE4). It just need to be mentioned or Godot needs some automated migration process like Unity and UE4.

Maujoe

Maybe a migration/backup dialog feature is a good idea (for stable builds) but in general I wouldn't expect from nightly builds that it works without flaws because it's still a dev version for testing and bug reports even a automatic migration could be broken at this state.

Ace_Dragon

Okay guys, Reduz has identified this issue as a bug and has pushed a fix. https://github.com/godotengine/godot/commit/c627f3a707b9dc052e6665f1a5b1268862a90642

He's not fully sure if it will work, so please test. If that doesn't do anything, try deleting the .import folder and let Godot create a new one.

aaronfranke

Seems to be fixed by https://github.com/godotengine/godot/commit/c627f3a707b9dc052e6665f1a5b1268862a90642

MagicLord

I tried the last build and my level and textures loaded correctly

But i have an error message on the console playing the game :

Node not found AnimationPlayer Nothing to read or no such file.

The editor also shows and error aboutthis line of code animation.play("IDLE")

And display an error : attemp to play "call" function in base null instance on a null instance

Does something has changed and i no more compatible about characters and animations ? * I noticed Godot does not try to reimport tscn files using a new version. When i click on Playerfps.tscn, it doesn't succeed. Perhaps this is what makes the bugs ? Should Godot try re import automatically "tscn" files ?

Calinou

@MagicLord said: We should have been informed previous version 3D projects are not compatible with 3.1 nighty builds.

That reminded me to add a warning about project compatibility on my builds website. Thanks :)

Ace_Dragon

Your script error could be explained by the fact that Godot has tightened the screws a bit when it comes to what class the script extends (to avoid abuse of the system through using functions that "should not work" in that situation).

For instance, the script must now extend the class that shares the name with the node, you can no longer just place extends Node at the top of every piece of logic and call it a day.

Do note though, you can still tell any other node what to do from a centralized location (just make sure you do it through a variable that got its value from the get_node() function).

MagicLord

@Ace Dragon said: Your script error could be explained by the fact that Godot has tightened the screws a bit when it comes to what class the script extends (to avoid abuse of the system through using functions that "should not work" in that situation).

For instance, the script must now extend the class that shares the name with the node, you can no longer just place extends Node at the top of every piece of logic and call it a day.

Do note though, you can still tell any other node what to do from a centralized location (just make sure you do it through a variable that got its value from the get_node() function).

Where did you seen "extends Node" if i didn't shared my scripts ? :o

Most gameplay elements uses physics so my scripts always start with something like "extends KinematicBody" for example. The script is correct and working on previous version, the issue is not with scripts.

Note that you can use $ + "node name" instead of using get_node in GDScript.

MagicLord

I don't know how but there is no more issues trying again with the same build :D Godot can open tscn files without errors, and launch the game ( keeping config_version = 4 ).

@Calinou said:

@MagicLord said: We should have been informed previous version 3D projects are not compatible with 3.1 nighty builds.

That reminded me to add a warning about project compatibility on my builds website. Thanks :)

Some versions should be compatible, for example my project is 3.05 stable and it works with a nighty build i downloaded very recently.

Ace_Dragon

Where did you seen "extends Node" if i didn't shared my scripts ?

It was just an example of what you can do in Godot 3.0.5 stable and have everything work, even though it is technically incorrect. The nightlies have that fixed, so if the extends keyword does not contain the same name as the node type the script is attached to, then you could get errors. I'm not saying specifically that you have "extends Node" everywhere, but errors can now come even in cases where if you have a script attached to a spatial node and it was extending rigidBody (as an example). The devs. considered it an urgent issue because the oversight was being abused.

Yes, I know of the $node_name shortcut, but it does not work when certain symbols and/or spaces are used in the name (even though it is completely valid in terms of scripting in Godot). I also do not know if it works at all if you need to walk back through one of more parents to get a node elsewhere in the tree.

MagicLord

@Ace Dragon said: Yes, I know of the $node_name shortcut, but it does not work when certain symbols and/or spaces are used in the name (even though it is completely valid in terms of scripting in Godot). I also do not know if it works at all if you need to walk back through one of more parents to get a node elsewhere in the tree.

I never got any issue using it a lot ;)

BinaryOrange

This is definitely a good lesson in making backups of your project before testing a new version of any engine (though I 100% agree that Godot does need some sort of migration feature in the vein of UE4/Unity). I always do, because you just never know if something is going to be broken that you depend on, and chances are it is. :p

I have learned this lesson not once, not twice, but three times!

... Once in Unity, once in Unreal, and once in Godot. :neutral:

Schuster

yeah...config_version = 3 save this for now :) ....but the mipmaps problem remains... or is resolved?