Add ability to get list of Project Settings changed, similar to Editor Settings functionality #110748

MauriceButler · 2025-09-21T13:54:13Z

Introduces new functions get_changed_settings and check_changed_settings_in_group. This brings Project Settings to parity with the Editor Settings functionality.

This allows much more fine-grained responses to setting changes.

This approach is non-breaking.

func _enter_tree() -> void:
	ProjectSettings.settings_changed.connect(_on_project_settings_changed)
	
func _on_project_settings_changed() -> void:
	print("_on_project_settings_changed")
	
	if !ProjectSettings.check_changed_settings_in_group('my_settings'):
		return

	var changed_settings = ProjectSettings.get_changed_settings()

As part of this, the settings_changed is now only emitted when a settings value is set to a different value.

Fixes: #110747
Closes godotengine/godot-proposals#13244

rsubtil · 2025-09-21T14:22:22Z

I'm not too keen with this solution of having two very similar signal names for the same concept. In my opinion it makes more sense to introduce the (name, old_value, new_value) args to the existing signal instead.

Thing is, I believe that would cause a breaking change for existing code, even though we are only adding arguments, since there would be a mismatch of argument count between the signal and existing connected functions. So I'm not sure how problematic this would be.

MauriceButler · 2025-09-21T14:40:14Z

I agree, I originally changed the existing signal, but I was trying to avoid a breaking change.

I am happy to make the breaking change if that's the approach deemed correct.

I could fix the broken code in the engine, but any userland code would still be affected.

I'm not sure how widely used this signal is outside of addons, but anyone using this signal would benefit from the usability improvements, being able to filter on specific settings, and reducing processing, at the cost of a minor change to the signature.

lawnjelly · 2025-09-23T06:05:45Z

Needs a proposal:
https://github.com/godotengine/godot-proposals

AThousandShips · 2025-09-23T07:53:41Z

This will only emit for exactly one setting, which would be confusing IMO, it should at least be mentioned in the documentation that changing a second setting in the same frame will not trigger this specific signal

MauriceButler · 2025-09-23T07:59:00Z

This will only emit for exactly one setting, which would be confusing IMO, it should at least be mentioned in the documentation that changing a second setting in the same frame will not trigger this specific signal

That was not the intended behavior, I must not have tested that as well as I thought.

My aim is that each setting change would trigger this signal.

I won't update this yet I'll wait on the proposal approval before spending more time on it.

AThousandShips · 2025-09-23T08:16:09Z

Based on how I read the code it queues one change notification per frame, for the first changed case, after that it skips any changes of any setting, as it sets is_changed = true and then any call to _queue_changed is skipped

AThousandShips · 2025-09-23T12:32:51Z

core/config/project_settings.cpp

+	signal.name = p_name;
+	signal.old_value = p_old_value;
+	signal.new_value = p_new_value;
+	pending_signals.push_back(signal);


Looks better, note though that this will fire for duplicates, but that would be desirable I'd say, though if you do change the setting twice in a frame it will call with the two changed values in order

I agree, multiple changes to the same settings for different values is correct to fire for each change.

Multiple changes to the same setting of the same value do not.

I can add an explicit test for that to make it clear.

MauriceButler · 2025-09-28T03:31:49Z

I have reworked this to mimic the way Editor Settings work.
No new signals, non-breaking and aligns Editor and Project settings fnctionality.

KoBeWi · 2025-10-26T11:25:20Z

doc/classes/ProjectSettings.xml

 				Clears the whole configuration (not recommended, may break things).
 			</description>
 		</method>
+		<method name="clear_changed_settings">


What is this for?

Leftover from a test method, cleanup and removed.

KoBeWi · 2025-10-26T11:26:35Z

doc/classes/ProjectSettings.xml

 				Returns the localized path (starting with [code]res://[/code]) corresponding to the absolute, native OS [param path]. See also [method globalize_path].
 			</description>
 		</method>
+		<method name="mark_setting_changed">


I know EditorSettings also have this method, but I wonder why 🤔 Changing a setting will automatically mark it as modified.

Honestly I dont know either.
I copied it to to match EditorSettings but I dont know how a setting could get in another way.
I have removed it.

KoBeWi · 2025-10-26T11:29:09Z

core/config/project_settings.cpp

+	// Capture old value before making changes
+	Variant old_value;
+	if (props.has(p_name)) {
+		old_value = props[p_name].variant;


If you are checking anyway whether the value changed, maybe the method could return early if it didn't change?

Good call I have added an early return check.

AThousandShips · 2025-11-03T11:50:42Z

core/config/project_settings.h

 	uint32_t _version = 1;

+	// Track changed settings for get_changed_settings functionality
+	HashSet<String> changed_settings;


The method to queue changes uses StringName and in _set it checks for has, so I'd say that using StringName here would be best and then just casting it to String when you need a String. It's not expensive but it will improve the checking operations and the insertion as StringName already has its hash and the comparison is faster

You'd just need to change the const String &setting : changed_settings to const String setting : changed_settings

StringName has a tiny overhead in storage but I'd say that's not critical compared with the better performance when inserting and querying

OK I can make that change.

Do you think I should I change EditorSettings while I am at it to keep them in sync?

Or do that as a seperate performance improvement PR?

I'd say to keep that as is, or leave it in both cases

Added the change for ProjectSettings

MauriceButler requested review from a team as code owners September 21, 2025 13:54

AThousandShips added enhancement discussion topic:core labels Sep 22, 2025

AThousandShips added this to the 4.x milestone Sep 22, 2025

MauriceButler force-pushed the project-setting-changed-signal branch from dcfeebf to 053f96d Compare September 23, 2025 04:51

MauriceButler requested a review from a team as a code owner September 23, 2025 04:51

MauriceButler mentioned this pull request Sep 23, 2025

Added ability to get list of Project Settings changed, similar to Editor Settings functionality godotengine/godot-proposals#13244

Open

MauriceButler force-pushed the project-setting-changed-signal branch from 053f96d to e7dd3f8 Compare September 23, 2025 12:23

AThousandShips reviewed Sep 23, 2025

View reviewed changes

MauriceButler force-pushed the project-setting-changed-signal branch 2 times, most recently from b2d82e6 to b5582da Compare September 28, 2025 03:25

MauriceButler changed the title ~~Add signal for individual project setting change~~ Added ability to get list of Project Settings changed, similar to Editor Settings functionality Sep 28, 2025

MauriceButler force-pushed the project-setting-changed-signal branch from b5582da to 482864c Compare September 28, 2025 22:51

AThousandShips changed the title ~~Added ability to get list of Project Settings changed, similar to Editor Settings functionality~~ Add ability to get list of Project Settings changed, similar to Editor Settings functionality Oct 7, 2025

KoBeWi reviewed Oct 26, 2025

View reviewed changes

MauriceButler force-pushed the project-setting-changed-signal branch from 482864c to 07b8725 Compare November 3, 2025 11:31

AThousandShips reviewed Nov 3, 2025

View reviewed changes

Added ability to get a list of project settings changed.

e451640

MauriceButler force-pushed the project-setting-changed-signal branch from 07b8725 to e451640 Compare November 3, 2025 13:32

Uh oh!

Add ability to get list of Project Settings changed, similar to Editor Settings functionality #110748

Are you sure you want to change the base?

Add ability to get list of Project Settings changed, similar to Editor Settings functionality #110748

Conversation

MauriceButler commented Sep 21, 2025 • edited by KoBeWi Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rsubtil commented Sep 21, 2025

Uh oh!

MauriceButler commented Sep 21, 2025

Uh oh!

lawnjelly commented Sep 23, 2025

Uh oh!

AThousandShips commented Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MauriceButler commented Sep 23, 2025

Uh oh!

AThousandShips commented Sep 23, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MauriceButler commented Sep 28, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

MauriceButler commented Sep 21, 2025 •

edited by KoBeWi

Loading

AThousandShips commented Sep 23, 2025 •

edited

Loading