No, I don't remember.... can you remember which file that was? And are you sure it was "CharacterName" and not "Character.name", reading the character's name directly from an attribute rather than using a function like 'GetMyName(Character)'?
Chances are THAT was one of the citizen dialog files then.
Whatever you wish.True, which means there's no point in changing it again.
The other reason I don't want to change it, and why I am not interested in mere formatting changes, is that when the files are changed, so are the dates on them. And that's important when I get round to writing the documentation just before releasing an update. I do a WinMerge comparison between what's currently in my update folder and the last released update, with WinMerge set to sort by date so I can see all the files which have changed, and when. Then I can document them in "fixes.txt". Sometimes I want to check back on the forum, for example to find out who to credit. None of that is going to happen if the file has changed again for the sake of changing that day/night boundary again, or if the file with the important change is lost among a mass of files whose only change is the deletion of a couple of unwanted spaces.
Me, I do so hate horrid formatting.
Clean code is so much easier to handle in the long run.
For the change log, I always go through EVERY file changed since the previous update anyway.
My method is to do a full install of the previous version and then compare it all.
In this process, I both do a final check of all the new changes going in, as well as compile the change log at the same time.
I never worried about listing changes per date; just that they go in "Build Info.txt" under the right version number in a sensible spot.
As for giving credit where it is due, I try to ensure for any code change, I put the right person in the comment for future reference; and for anything else, I like to update the "Build Info.txt" at the same time that I add the update itself, so I don't risk forgetting.
But that's just me.