Script fields hold values after renaming

Unity Engine
1

After renaming script fields, old values of fields (which had been set in editor) should be transferred to the new ones.

There are frequent small renames, e.g., making first letter uppercase, and these renames needlessly reset values (and also script import setting values).

2

This is actually already a feature, though I’m not really keen on how it’s implemented.

You can use the [FormerlySerializedAs] attribute to contain the old name of a field before renaming it, and then once Unity recompiles with the new name, it will keep the value/reference it had. You can then delete the attribute afterwards.

2 Likes
3

The issue with this from a conceptual standpoint is that Unity has no context for the circumstances under which fields may change on a class. You know that the field change you made was a name change and not a different field, but how does Unity know that? All it’s looking at are files. In one version there’s one field, in the next there’s a different one. It would take human intuition to reason that this is a rename and not a new field – even then you might be fooled in certain cases.

Unity doesn’t have human intuition. The best you’ve got is the [FormerlySerializedAs] attribute as mentioned above, which disambiguates the situation for Unity.

1 Like
4

You go like this:

  1. gather all fields that were deleted
  2. gather all fields that were added
  3. if number of chagned fields match, and value types match, and default values match, then assign old values, in order.

there could be even console log stating that old values were re-assigned, I think that assigning old value to new field that would do different thing would be nonexistent

5

This creates a lot of assumptions about the changes.

Simple example, say the script starts like this:

public int MaxLives = 5;;
public float TimeBetweenJumps = 2f;

And then I redesign the script to have unlimited lives, and no longer use time to limit jumps, but I add a couple new fields which were unrelated to the old ones:

//public int MaxLives = 5;
//public float TimeBetweenJumps = 2f;
public int EnemiesDefeated = 0;
public float RunSpeed = 0.2f;

Now my new fields pick up the previously serialized values for the old fields when I wouldn’t want them to. After I go through all my instances of this script and fix this mess, I go “well at least maybe I can use this new irritating feature”, and rename a field but also add a new field for another unrelated feature:

//public int MaxLives = 5;
//public float TimeBetweenJumps = 2f;
public int EnemiesDefeated = 0;
public string PlayerName;
public float RunSpeedMultiplier = 0.2f;

Oh dang! I thought Unity supported renaming fields while preserving values, but now I again have to go through all instances to fix the values.

I think you’ll get a lot of complaints about this feature acting unpredictably, when it is very predictable as long as you do exactly what the feature requires you to do and no more. But I think people will often get caught up unexpectedly.

1 Like
6

You have a point.

How about a button field asking user if editor should write old-assigned value based on guess

with tooltip something like “set 6 based on old field value”

3 Likes
7

That could be nice. Maybe a context-menu option when you right-click a field in the inspector to toggle a “Mark for name change” flag, which internally applies the FormerlySerializedAs attribute logic to the field using its current name.
Then once Unity recompiles the script, the flag is automatically set back to false.

2 Likes
8

Both of these ideas sound a lot better.