godot

godot copied to clipboard

Closes https://github.com/godotengine/godot-proposals/issues/373

Added a dialog under "Project -> Tools -> Custom Feature Tags..." that allows to specify custom feature tags when running the project. The are read during Project Settings initialization (passed via __GODOT_EDITOR_CUSTOM_FEATURES__ environment variable), so they also affect project setting feature overrides.

https://user-images.githubusercontent.com/2223172/181235993-7e50fb39-02dd-4707-80f3-0b99ae62807b.mp4

EDIT: Maybe this should be in Debug menu 🤔

I think this kind of feature would be nice to have exposed together with the dialog I propose here to configure run options and number of instances: https://github.com/godotengine/godot-proposals/issues/522#issuecomment-1047873419

There could be an additional text field for each instance to configure custom feature tags (so you can also test e.g. how demo and full clients could play together in a multiplayer game, or test steam and eos variants at once, etc.).

Would this also work when exporting projects through the command line for CI environments? Something like this? __EDITOR_CUSTOM_FEATURES__=feature1,feature2 godot --export ...

Would this also work when exporting projects through the command line for CI environments? Something like this? __EDITOR_CUSTOM_FEATURES__=feature1,feature2 godot --export ...

It should work, but that reminds me…

The environment variable's naming should be changed to match Godot conventions. Specifically, all environment variables should be prefixed with GODOT_ to avoid conflicts with other programs: GODOT_EDITOR_CUSTOM_FEATURES

Would this also work when exporting projects through the command line for CI environments?

No, it only works when running the project. It does not affect the export.

EDIT:

I think this kind of feature would be nice to have exposed together with the dialog I propose here to configure run options and number of instances

I can change this after #65753 is merged

I would put this dialog inside the editor settings, as a simple entry. I don't feel it needs to have a new menu entry.

I would put this dialog inside the editor settings, as a simple entry. I don't feel it needs to have a new menu entry.

Setting feature tags for testing is specific to a project, rather than something you enable for all projects in your editor instance.

Maybe we should merge this dialog together with the one that lets you customize command line arguments for each instance?

I think this kind of feature would be nice to have exposed together with the dialog I propose here to configure run options and number of instances

I can change this after #65753 is merged

This can be worked on now. Feel free to involve other folks in the UI concept if you're unsure about how to feature everything in that dialog.

I'm reworking it right now. Here's my idea for the unified instance list:

I'm wondering if this wouldn't work better with a table like we have for Autoloads, etc.

Instance	Launch Arguments	Override Main Run Args	Feature Tags	Override Main Tags
1	--yolo	[x]	blue, red, green	[ ]
2		[ ]	demo	[x]
3	"res://my_test_scene.tscn" --verbose	[x]		[ ]

The main challenge may be for the "Override ..." columns not to take too much space so there's still enough for the actually args and feature tags. Maybe the column names can be wrapped on two lines.

Edit: Seems possible to wrap long column names for columns meant to be small, we do it for Autoloads "Global Variable":

Edit 2: And possibly it could use the same kind of widget we have in the inspector to add/remove elements to arrays/dictionaries... but I guess those are completely different types of controls so it might requirement significant rework which is maybe not worth it.

Ok pushed the design I showed above, I'll try to change it to table.

EDIT: Still not changed, I was just fixing CI.

Here's the dialog with table: It's more compact (at least vertically), but it lost tooltips for overrides.

Should I push this version?

It's more compact (at least vertically), but it lost tooltips for overrides.

It looks pretty good :slightly_smiling_face:

I'm wondering if this table could have alternating row colors, by the way. This would help improve readability of long rows, but I don't remember if we have support for that in Tree.

Should I push this version?

Yes – if in doubt, push it as a separate commit and squash it later.

That looks pretty good to me!

Pushed the new design. Old code is in https://github.com/godotengine/godot/commit/5dd6941b9b13e55c594d9ecdc7594bd7426bfe94

Tested briefly, it seems to work well!

The original minsize seems to be too small to fit the table initially, it would need some more space:

---

Bunch of ideas for future improvements, but let's maybe wait and see what users request:

• Some users might want to preserve their config for multiple instances while reducing the amount of instances they're testing now. Currently reducing the count will lose the config for the last instances in the list. There could be a checkbox to enable/disable a specific instance while keeping its config saved.
• We still don't have a simple way to query all enabled custom feature tags aside from checking each manually with OS.has_feature()?
• Multiple instances could use a way to be identified visually. We could change the window title (as suggested in #68054, but this should be redone based on this new dialog, and ideally not affect the single-instance use case), or add another kind of identifier that could be queried from code. We could also envision an editor hotkey (or checkbox in this dialog) that toggles displaying the instance number on each instance. Or many other options, some which may best be explored via plugins until we figure out what makes most sense.

We still don't have a simple way to query all enabled custom feature tags aside from checking each manually with OS.has_feature()?

Some features are defined using #ifdef, so they can be only queried.

Multiple instances could use a way to be identified visually.

#34528 would be one idea, but not sure how it would work.

The original minsize seems to be too small to fit the table initially, it would need some more space:

Should I change it now?

The original minsize seems to be too small to fit the table initially, it would need some more space:

Should I change it now?

Yeah that would be good if you know what to change. For the record I'm on a 2K screen with 150% system scaling (and the same configured for Godot scaling).

It's this line:

set_min_size(Size2i(1200, 500) * EDSCALE);

Though not sure what value I should use. I didn't observe this problem on my side.

Increased height to 600. I also changed how dialog size is determined (it's set during popup instead of minimum size, so you can shrink it now).

Thanks!