Request: features

[zer0Kerbal]

Appreciate this mod! 👏

I often have many changes in one version, especially when adopting. Things I would like to see added to KCL:

• ability to group items together: so

change = PART.CFG changes:
subchange = did this
subchange = did that

— or —

change = part.cfg changes:
SUBCHANGE
{
sub = x
sub = y
}

• "
• optional: "license - xxx" right after modName
• optional: "author - xxx" right after modName
• optional: "versionName = string" after version = xxx
• stretch: would love to be able to include markdown basics (bold,ital,under,strikethroug) and color
• would love to have a simple utility that converts from KCL -> markdown and/or html
  just thoughts

thank you!

[AmberCronin]

This is a great list of features!
Most of them look very easy to implement, so those won't be a problem. The subchanges, however, will take a bit more effort. The way I've decided to have those work is as follows (using my own changelog as an example):

KERBALCHANGELOG
{
	showChangelog = True
	modName = Kerbal Changelog
	license = MIT
	author = Benjamin Cronin
	VERSION
	{
		verison = 1.8
		//versionName = Audacious Apple //This is optional, I am choosing not to include it for this mod
		CHANGE
		{
			change = Add features suggested by zer0Kerbal
			subchange = Add new change nodes
			subchange = Add license field
			subchange = Add author node
			subchange = Add version naming field
		}
		CHANGE
		{
			change = Internal code rewrite to improve maintainability
		}
	}
	VERSION
	{
		version = 1.1.7
		CHANGE
		{
			change = Update for KSP 1.9
		}
		CHANGE
		{
			change = Downgrade to .NET 4.5 for compatibility
		}
	}
}

As you can see, the standard change field has been replaced by the CHANGE node, which will contain both the initial change and the subchanges.
I'm considering whether or not to allow the change fields to exist outside of a CHANGE node, and I'll look to what you think would be easiest for that. However, if change fields do exist outside of a CHANGE node, I will have to choose to read either the fields or the nodes first, so the formatting of the changelog in game may not accurately reflect the order described in the changelog config file.
For example, if several change fields are interspersed with CHANGE nodes, depending on my implementation, either all of the change fields will show up first, followed by the nodes, or the other way around.

I'll see what I can do regarding markdown, but that will probably be a part of a later release. I'd prefer to push out the subchange functionality for you before attempting any kind of custom formatting.

Regarding the conversion utility: I've considered trying to make a seperate utility to automagically convert existing changelog files (in the form of markdown or text documents present in a mod's folders) into KCL config files. A conversion utility from config to HTML or markdown would most likely be separate, but implementing it right into KCL itself would remove the necessity to parse the config files seperately, as that functionality is already provided by KSP.

For now, I'm just working on getting this initial update implementing the subchange feature in before meddling with any kind of conversion or formatting :)

[zer0Kerbal]

looks great.
only concern is possible confusion stemming from CHANGE/change/subchange - maybe just sub or point or bullet?
looking forward to this.

[AmberCronin]

The way KSP works is that without knowledge of the ConfigNode itself, it's impossible to guarantee the order that the changes will show up if they're not grouped together like above. I will maintain backwards compatibility with previous changelog versions (meaning ungrouped change fields will continue to be displayed), but in order to have subchanges, they must be grouped as above.

[AmberCronin]

I've completed my rewrite of KCL to its original form with commit 2405121, and I am beginning the addition of the features discussed above.

[AmberCronin]

Unity's Rich Text GUI style allows for several options that you've requested, with the exception of underlines and strike-throughs. Here is the manual for using Rich Text.
In order to have the text display in your changelog, simply place one or more of the tags described above like so:

change = <b>Add features suggested by <i>zer0Kerbal</i></b>

ONLY basic fields will support Rich Text! (This includes change, subchange, modName, author, license, and versionName, although I have no clue why you'd want the latter ones to have formatting 😝)
This is per commit ac40245, which has not yet been released. If there are any bug fixes needed or requests for changes in the basic formatting, I'll release those at the same time. Otherwise I'll probably release this in a week or two to keep from inundating players with releases.

[yalov]

For example, if several change fields are interspersed with CHANGE nodes, depending on my implementation, either all of the change fields will show up first, followed by the nodes, or the other way around.

Will order of change fields be preserved if there is no CHANGE {} node?