Skip to content
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

godot_node_type and/or res_path are not loaded from property types file. #26

Closed
al0fdf opened this issue Oct 23, 2023 · 12 comments
Closed

Comments

@al0fdf
Copy link

al0fdf commented Oct 23, 2023

Describe the bug
godot_node_type and/or res_path are not loaded from property types file, as a result, any objects with the relevant properties set, do not get instanced:

To Reproduce
Steps to reproduce the behavior:

  1. Create a new class in Tiled's 'Custom Type Editor' with res_path and godot_node_type='instance' properties.
  2. Inside a map file, create an object with class property set to above class.
  3. Import map in game
  4. Objects stay as static bodies instead of becoming scene instances

To work around
Double-click the res_path and godot_node_type for every object in the map, change them to non-default values, then change them to their default values, so they become un-greyed.

Expected behavior
Objects with godot_node_type='instance' and res_path set to a .tscn file should be instanced in-game.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • OS: Linux
  • Version: 1.6.0, gdscript release
  • Godot Version 4.1.2 stable
  • Tiled Version 1.10.2

Examle map (zipped)
A zip file containing a small but complete example to reproduce the issue.
This could accelerate resolving it.

Additional context
Add any other context about the problem here.

@Kiamo2
Copy link
Owner

Kiamo2 commented Oct 23, 2023

Can't reproduce this, it works in my tests.
Could you please zip and append a mini example?

PS had an idea:
Is your (relative) res_path maybe from viewpoint of the project file different to the res_path from viewpoint of the .tmx?
That could be a problem.

@erniel
Copy link

erniel commented Oct 23, 2023

@al0fdf try exporting the tmx file instead of just saving it

@Kiamo2
Copy link
Owner

Kiamo2 commented Oct 23, 2023

@al0fdf : I've tested now different relative paths and that worked too.
So currently without an example of yours I've no clue.
Yet I've only Windows available and not sure what's happening on Linux...

@al0fdf
Copy link
Author

al0fdf commented Oct 24, 2023

@Kiamo2 Here's my reproduction project.

There is a test_object class created in the custom types editor, with the instance and res_path properties set:
image

In the tiled/map.tmx level, there are two test_objects. The properties of the right object, I edited to make sure they are part of the tmx file. The left object's properties I left as is; they're implied:

Left object(edited properties):
image
Right object(implied properties):
image

When running in-game, note that only the left object is correctly instanced, the right remains a static body.
Screenshot:
image

The remote tree view:
image

Here is the zip for the reproduction case:
yati_instacing_repro_project.zip

With the following folder structure:

└── yati_repro_project
    ├── addons
    │   └── YATI
    │       ├── CustomTypes.gd
    │       ├── DictionaryBuilder.gd
    │       ├── DictionaryFromXml.gd
    │       ├── Importer.gd
    │       ├── plugin.cfg
    │       ├── PostProcessing.gd
    │       ├── TiledImport.gd
    │       ├── TilemapCreator.gd
    │       ├── TilesetCreator.gd
    │       └── XmlParserCtrl.gd
    ├── icon.svg
    ├── icon.svg.import
    ├── main.gd
    ├── main.tscn
    ├── project.godot
    ├── test_object.tscn
    └── tiled
        ├── map.tmx
        ├── map.tmx.import
        ├── propertytypes.json
        ├── repro.tiled-project
        └── tileset.tsx

@Kiamo2
Copy link
Owner

Kiamo2 commented Oct 24, 2023

Now it's going to be mysterious.
After setting the project file in the import options for map.tmx (was missing there), everything worked well on my side.

Maybe it's indeed Linux behaving different...?
If so it's going to be a bit difficult for me,
-> I'll try to examine the path building and look for potential weaknesses here.

@Kiamo2
Copy link
Owner

Kiamo2 commented Oct 24, 2023

Can't find anything and as the res_path entries in 'map_working.tmx' and 'repro.tiled-project' are identical it's no big surprise that it's working.
But - as you've written "When running in-game...", are you talking about the runtime version?

@al0fdf
Copy link
Author

al0fdf commented Oct 24, 2023

Can't find anything and as the res_path entries in 'map_working.tmx' and 'repro.tiled-project' are identical it's no big surprise that it's working. But - as you've written "When running in-game...", are you talking about the runtime version?

I'm talking about running the godot project from the editor.

@Kiamo2
Copy link
Owner

Kiamo2 commented Oct 25, 2023

Aah, you've changed the example zip.
OK, I've tested with the changed example and it also works as soon as I specified the project file in the Project File option and reimported.

screenshot

Could it be that you simply missed to specify the project file???

Please note, that for Custom Types to be supported the project file is neccessary!
(TBD: Point that out more precise in the docu)
The reason is that Tiled stores its Custom Types in the project file, NOT in the .tmx.
The .tmx only contains the class name.
Unless you overwrite a custom property (not grayed out in Tiled), then it's contained in the .tmx thus the left icon works without project file.

@al0fdf
Copy link
Author

al0fdf commented Oct 25, 2023

@Kiamo2 I have set the project file in the import defaults:

image

However when creating a new inherited scene based on map.tmx in the editor, I get:

Import file 'res://tiled/map.tmx'
 -- Unknown class 'test_object'. -> Assuming Default
Import finished with 1 warning.

When finding that line(around line 652 in TilemapCreator.gd), and debug-printing the _ct variable, I find that it is null, which could explain why the test_object class is unknown at that time.

	if _ct != null:
		_ct.merge_custom_properties(obj, "object")
+	print(_ct)
	
	...
	
	if godot_type == _godot_type.UNKNOWN:
		if not _add_class_as_metadata and class_string != "" and not godot_node_type_prop_found:
			print_rich("[color=" + WARNING_COLOR +"] -- Unknown class '" + class_string + "'. -> Assuming Default[/color]")
			_warning_count += 1
		
		...

Godot's console output of the above code:

Import file 'res://tiled/map.tmx'
<null>
 -- Unknown class 'test_object'. -> Assuming Default
<null>
Import finished with 1 warning.

@Kiamo2
Copy link
Owner

Kiamo2 commented Oct 25, 2023

_ct being null is indicating that no project file has been loaded.

You may have set it in the importer defaults, but after I loaded your example, the actual Tiled Project File option for map.tmx was empty.
I had explicitly to set it.
Please check if it is set by looking at the import options when the file 'map.tmx' is selected in the file system window on the left.
Like above in the screenshot.
(Godot pecularity: If the Import option tab is blank, select another file and then select 'map.tmx' again)

Maybe the importer defaults have no effect on the currently actually used import options.

@al0fdf
Copy link
Author

al0fdf commented Oct 26, 2023

@Kiamo2 That seems to be the issue. The importer tab does not use the project's default import options. After re-importing the .tmx with the project file set in map.tmx's import options, both scenes were correctly instanced!

@Kiamo2
Copy link
Owner

Kiamo2 commented Oct 26, 2023

I took a closer look and found out:

  • The importer defaults only come into play if no (previous) import has been done for a .tmx, i.e. - no .tmx.import file exists parallel to the .tmx yet.
  • After an import, the import options used are saved in the .tmx.import file and then have priority over any changed importer defaults.

I think, this explains the behavior and I consider the issue as resolved.

@Kiamo2 Kiamo2 closed this as completed Oct 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants