|
On April 25 2013 17:23 fengshaun wrote:
how about a simple script that updates your copy?
initialize:
$ git clone <github_repo> ~/thecore
update:
$ git pull
$ cp thecore/path/to/preferred/layout.SC2Hotkeys ~/My\ Documents/Starcraft\ II/path/to/profile/hotkeys/layout.SC2Hotkeys
save it as thecore.bat and double-click. Done!
I think you must have git installed for this to work
|
![[image loading]](http://i.imgur.com/s0lmOL4.jpg)
That is an example of what the XML MIGHT look like. I may make some changes. In fact I would already add an attribute to one of the parent nodes that states the name of the layout rather than the node itself being the name of the layout.
Yes, TheCore would probably have to switch to MINOR and MAJOR versioning, or they can just go major. It is really up to them.
I think the XML speaks for itself on how I would parse through it. But if it doesn't I will make another post.
Anyways, to make it easier and more stable, TheCore layout files will have to have consistent names. So the Alpha ZRM 1.0.SC2HOTKEYS file will always be = Alpha ZRM.SC2HOTKEYS. And that means the file path should remain the same too.
Anyways, I have to get ready for school. I will keep an eye on this thread throughout the day though and post more details if need be.
|
On April 25 2013 21:41 DarkOwnage wrote:That is an example of what the XML MIGHT look like. I may make some changes. In fact I would already add an attribute to one of the parent nodes that states the name of the layout rather than the node itself being the name of the layout. Yes, TheCore would probably have to switch to MINOR and MAJOR versioning, or they can just go major. It is really up to them. I think the XML speaks for itself on how I would parse through it. But if it doesn't I will make another post. Anyways, to make it easier and more stable, TheCore layout files will have to have consistent names. So the Alpha ZRM 1.0.SC2HOTKEYS file will always be = Alpha ZRM.SC2HOTKEYS. And that means the file path should remain the same too. Anyways, I have to get ready for school. I will keep an eye on this thread throughout the day though and post more details if need be.
ok I did not realize that the xml document contains the entire history
|
On April 25 2013 21:52 Hancho wrote:Show nested quote +On April 25 2013 21:41 DarkOwnage wrote:That is an example of what the XML MIGHT look like. I may make some changes. In fact I would already add an attribute to one of the parent nodes that states the name of the layout rather than the node itself being the name of the layout. Yes, TheCore would probably have to switch to MINOR and MAJOR versioning, or they can just go major. It is really up to them. I think the XML speaks for itself on how I would parse through it. But if it doesn't I will make another post. Anyways, to make it easier and more stable, TheCore layout files will have to have consistent names. So the Alpha ZRM 1.0.SC2HOTKEYS file will always be = Alpha ZRM.SC2HOTKEYS. And that means the file path should remain the same too. Anyways, I have to get ready for school. I will keep an eye on this thread throughout the day though and post more details if need be. ok I did not realize that the xml document contains the entire history
I really don't see how/why there should be an xml document. You could instead:
Download the latest version of MapDefinitions.ini from the GitHub. This has "prefix" and "suffix" variables that define what the file names for the individual files are (prefix + " " + <layout name> + " " + suffix). Then you could download the latest version of the layout from the GitHub.
If you want to have a changelog, you could diff the latest version with the version they currently have. Otherwise just copy the latest version into their hotkeys folder, and you're good to go.
|
On April 25 2013 22:59 JDub wrote:Show nested quote +On April 25 2013 21:52 Hancho wrote:On April 25 2013 21:41 DarkOwnage wrote:That is an example of what the XML MIGHT look like. I may make some changes. In fact I would already add an attribute to one of the parent nodes that states the name of the layout rather than the node itself being the name of the layout. Yes, TheCore would probably have to switch to MINOR and MAJOR versioning, or they can just go major. It is really up to them. I think the XML speaks for itself on how I would parse through it. But if it doesn't I will make another post. Anyways, to make it easier and more stable, TheCore layout files will have to have consistent names. So the Alpha ZRM 1.0.SC2HOTKEYS file will always be = Alpha ZRM.SC2HOTKEYS. And that means the file path should remain the same too. Anyways, I have to get ready for school. I will keep an eye on this thread throughout the day though and post more details if need be. ok I did not realize that the xml document contains the entire history I really don't see how/why there should be an xml document. You could instead: Download the latest version of MapDefinitions.ini from the GitHub. This has "prefix" and "suffix" variables that define what the file names for the individual files are (prefix + " " + <layout name> + " " + suffix). Then you could download the latest version of the layout from the GitHub. If you want to have a changelog, you could diff the latest version with the version they currently have. Otherwise just copy the latest version into their hotkeys folder, and you're good to go.
How exactly would you suggest I check if they have the latest version? Do I download the MapDefinitions.ini and store it locally and when they "update" I download the latest layout PLUS copy down that new MapDefinitions.ini. And I check if they have the latest version by doing a comparison on the MapDefinitions.ini file?
Cause I cannot compare their current SC2HOTKEYS file because that would assume the user would never change a single keybind. If they do, bam they don't have the latest version. Right?
And comparing the MapDefinitions.ini file is possible but not reliable. It could make a wrong comparison and bam, new version!
Thus, an XML document that literally spells it out.
|
On April 25 2013 23:31 DarkOwnage wrote:Show nested quote +On April 25 2013 22:59 JDub wrote:On April 25 2013 21:52 Hancho wrote:On April 25 2013 21:41 DarkOwnage wrote:That is an example of what the XML MIGHT look like. I may make some changes. In fact I would already add an attribute to one of the parent nodes that states the name of the layout rather than the node itself being the name of the layout. Yes, TheCore would probably have to switch to MINOR and MAJOR versioning, or they can just go major. It is really up to them. I think the XML speaks for itself on how I would parse through it. But if it doesn't I will make another post. Anyways, to make it easier and more stable, TheCore layout files will have to have consistent names. So the Alpha ZRM 1.0.SC2HOTKEYS file will always be = Alpha ZRM.SC2HOTKEYS. And that means the file path should remain the same too. Anyways, I have to get ready for school. I will keep an eye on this thread throughout the day though and post more details if need be. ok I did not realize that the xml document contains the entire history I really don't see how/why there should be an xml document. You could instead: Download the latest version of MapDefinitions.ini from the GitHub. This has "prefix" and "suffix" variables that define what the file names for the individual files are (prefix + " " + <layout name> + " " + suffix). Then you could download the latest version of the layout from the GitHub. If you want to have a changelog, you could diff the latest version with the version they currently have. Otherwise just copy the latest version into their hotkeys folder, and you're good to go. How exactly would you suggest I check if they have the latest version? Do I download the MapDefinitions.ini and store it locally and when they "update" I download the latest layout PLUS copy down that new MapDefinitions.ini. And I check if they have the latest version by doing a comparison on the MapDefinitions.ini file? Cause I cannot compare their current SC2HOTKEYS file because that would assume the user would never change a single keybind. If they do, bam they don't have the latest version. Right? And comparing the MapDefinitions.ini file is possible but not reliable. It could make a wrong comparison and bam, new version! Thus, an XML document that literally spells it out.
How about this then:
Store a checksum of the vanilla version of TheCore layout that they use locally (or the entire file), and compare that to a checksum of the latest version of their layout on the GitHub. If they are different, they don't have the latest version.
Edit: The reason I'm having this debate is just b/c all of the information that you need is already there, and while the XML document thing could work, that would just be adding extra work to generate a redundant document.
|
On April 26 2013 00:12 JDub wrote:Show nested quote +On April 25 2013 23:31 DarkOwnage wrote:On April 25 2013 22:59 JDub wrote:On April 25 2013 21:52 Hancho wrote:On April 25 2013 21:41 DarkOwnage wrote:That is an example of what the XML MIGHT look like. I may make some changes. In fact I would already add an attribute to one of the parent nodes that states the name of the layout rather than the node itself being the name of the layout. Yes, TheCore would probably have to switch to MINOR and MAJOR versioning, or they can just go major. It is really up to them. I think the XML speaks for itself on how I would parse through it. But if it doesn't I will make another post. Anyways, to make it easier and more stable, TheCore layout files will have to have consistent names. So the Alpha ZRM 1.0.SC2HOTKEYS file will always be = Alpha ZRM.SC2HOTKEYS. And that means the file path should remain the same too. Anyways, I have to get ready for school. I will keep an eye on this thread throughout the day though and post more details if need be. ok I did not realize that the xml document contains the entire history I really don't see how/why there should be an xml document. You could instead: Download the latest version of MapDefinitions.ini from the GitHub. This has "prefix" and "suffix" variables that define what the file names for the individual files are (prefix + " " + <layout name> + " " + suffix). Then you could download the latest version of the layout from the GitHub. If you want to have a changelog, you could diff the latest version with the version they currently have. Otherwise just copy the latest version into their hotkeys folder, and you're good to go. How exactly would you suggest I check if they have the latest version? Do I download the MapDefinitions.ini and store it locally and when they "update" I download the latest layout PLUS copy down that new MapDefinitions.ini. And I check if they have the latest version by doing a comparison on the MapDefinitions.ini file? Cause I cannot compare their current SC2HOTKEYS file because that would assume the user would never change a single keybind. If they do, bam they don't have the latest version. Right? And comparing the MapDefinitions.ini file is possible but not reliable. It could make a wrong comparison and bam, new version! Thus, an XML document that literally spells it out. How about this then: Store a checksum of the vanilla version of TheCore layout that they use locally (or the entire file), and compare that to a checksum of the latest version of their layout on the GitHub. If they are different, they don't have the latest version. Edit: The reason I'm having this debate is just b/c all of the information that you need is already there, and while the XML document thing could work, that would just be adding extra work to generate a redundant document.
That would work except for the fact that I would have to download the layout file from here and run a checksum on it. I was hoping to avoid downloading more than what is really necessary.
I guess what you and I are both saying is that this can be accomplished in many ways. It really depends how the TheCore team wants me to approach it since it will either require them to maintain a new file (XML document) or if they want nothing to do with this at all. And both will either require me to do more work or less work, more stability and reliability or less stability and reliability.
So I would have to consistently download the layout file, run a checksum. If it differs, download the release notes and display it. While if I just download an extremely small XML document that literally states all of the information that is needed. The date of release (is it later than what is in the locally stored XML? New version) and the release notes. All of which are in a consistent structure and layout.And if there is a new version, THAN download the layout.
The only benefit with checksum is if a change is made but was undocumented. It would detect if there was a change.
EDIT: I am not saying it wouldn't work because it is definitely a viable option. And honestly I wouldn't mind going this route since the layout files aren't substantial in size anyways so the download would be fast along with the checksum calculations. I would still need a consistent file name download along with a consistent releasenotes file updated upon each change in order for notes that gets displayed to make sense.
|
On April 26 2013 00:33 DarkOwnage wrote:Show nested quote +On April 26 2013 00:12 JDub wrote:On April 25 2013 23:31 DarkOwnage wrote:On April 25 2013 22:59 JDub wrote:On April 25 2013 21:52 Hancho wrote:On April 25 2013 21:41 DarkOwnage wrote:That is an example of what the XML MIGHT look like. I may make some changes. In fact I would already add an attribute to one of the parent nodes that states the name of the layout rather than the node itself being the name of the layout. Yes, TheCore would probably have to switch to MINOR and MAJOR versioning, or they can just go major. It is really up to them. I think the XML speaks for itself on how I would parse through it. But if it doesn't I will make another post. Anyways, to make it easier and more stable, TheCore layout files will have to have consistent names. So the Alpha ZRM 1.0.SC2HOTKEYS file will always be = Alpha ZRM.SC2HOTKEYS. And that means the file path should remain the same too. Anyways, I have to get ready for school. I will keep an eye on this thread throughout the day though and post more details if need be. ok I did not realize that the xml document contains the entire history I really don't see how/why there should be an xml document. You could instead: Download the latest version of MapDefinitions.ini from the GitHub. This has "prefix" and "suffix" variables that define what the file names for the individual files are (prefix + " " + <layout name> + " " + suffix). Then you could download the latest version of the layout from the GitHub. If you want to have a changelog, you could diff the latest version with the version they currently have. Otherwise just copy the latest version into their hotkeys folder, and you're good to go. How exactly would you suggest I check if they have the latest version? Do I download the MapDefinitions.ini and store it locally and when they "update" I download the latest layout PLUS copy down that new MapDefinitions.ini. And I check if they have the latest version by doing a comparison on the MapDefinitions.ini file? Cause I cannot compare their current SC2HOTKEYS file because that would assume the user would never change a single keybind. If they do, bam they don't have the latest version. Right? And comparing the MapDefinitions.ini file is possible but not reliable. It could make a wrong comparison and bam, new version! Thus, an XML document that literally spells it out. How about this then: Store a checksum of the vanilla version of TheCore layout that they use locally (or the entire file), and compare that to a checksum of the latest version of their layout on the GitHub. If they are different, they don't have the latest version. Edit: The reason I'm having this debate is just b/c all of the information that you need is already there, and while the XML document thing could work, that would just be adding extra work to generate a redundant document. That would work except for the fact that I would have to download the layout file from here and run a checksum on it. I was hoping to avoid downloading more than what is really necessary. So I would have to consistently download the layout file, run a checksum. If it differs, download the release notes and display it. While if I just download an extremely small XML document that literally states all of the information that is needed. The date of release (is it later than what is in the locally stored XML? New version) and the release notes. All of which are in a consistent structure and layout.And if there is a new version, THAN download the layout. The only benefit with checksum is if a change is made but was undocumented. It would detect if there was a change. EDIT: I am not saying it wouldn't work because it is definitely a viable option. And honestly I wouldn't mind going this route since the layout files aren't substantial in size anyways so the download would be fast along with the checksum calculations. I would still need a consistent file name download along with a consistent releasenotes file updated upon each change in order for notes that gets displayed to make sense.
Honestly an XML document containing a list of all the changes for all the versions would be much larger than a single layout file (which is 800 short lines of text, about ~23 KB, so it is simply not a performance concern).
A release notes file of some kind is definitely in order. As for the consistent file names, I believe we are going to be taking the version number out of the file names. So it will just be "TheCore *** Beta.SC2Hotkeys", and when we move to an official release, it will be "TheCore ***.SC2Hotkeys". Then we can use Git version tagging to distinguish between the versions so people can see/download the old versions if they want to on GitHub.
|
On April 26 2013 01:00 JDub wrote:Show nested quote +On April 26 2013 00:33 DarkOwnage wrote:On April 26 2013 00:12 JDub wrote:On April 25 2013 23:31 DarkOwnage wrote:On April 25 2013 22:59 JDub wrote:On April 25 2013 21:52 Hancho wrote:On April 25 2013 21:41 DarkOwnage wrote:That is an example of what the XML MIGHT look like. I may make some changes. In fact I would already add an attribute to one of the parent nodes that states the name of the layout rather than the node itself being the name of the layout. Yes, TheCore would probably have to switch to MINOR and MAJOR versioning, or they can just go major. It is really up to them. I think the XML speaks for itself on how I would parse through it. But if it doesn't I will make another post. Anyways, to make it easier and more stable, TheCore layout files will have to have consistent names. So the Alpha ZRM 1.0.SC2HOTKEYS file will always be = Alpha ZRM.SC2HOTKEYS. And that means the file path should remain the same too. Anyways, I have to get ready for school. I will keep an eye on this thread throughout the day though and post more details if need be. ok I did not realize that the xml document contains the entire history I really don't see how/why there should be an xml document. You could instead: Download the latest version of MapDefinitions.ini from the GitHub. This has "prefix" and "suffix" variables that define what the file names for the individual files are (prefix + " " + <layout name> + " " + suffix). Then you could download the latest version of the layout from the GitHub. If you want to have a changelog, you could diff the latest version with the version they currently have. Otherwise just copy the latest version into their hotkeys folder, and you're good to go. How exactly would you suggest I check if they have the latest version? Do I download the MapDefinitions.ini and store it locally and when they "update" I download the latest layout PLUS copy down that new MapDefinitions.ini. And I check if they have the latest version by doing a comparison on the MapDefinitions.ini file? Cause I cannot compare their current SC2HOTKEYS file because that would assume the user would never change a single keybind. If they do, bam they don't have the latest version. Right? And comparing the MapDefinitions.ini file is possible but not reliable. It could make a wrong comparison and bam, new version! Thus, an XML document that literally spells it out. How about this then: Store a checksum of the vanilla version of TheCore layout that they use locally (or the entire file), and compare that to a checksum of the latest version of their layout on the GitHub. If they are different, they don't have the latest version. Edit: The reason I'm having this debate is just b/c all of the information that you need is already there, and while the XML document thing could work, that would just be adding extra work to generate a redundant document. That would work except for the fact that I would have to download the layout file from here and run a checksum on it. I was hoping to avoid downloading more than what is really necessary. So I would have to consistently download the layout file, run a checksum. If it differs, download the release notes and display it. While if I just download an extremely small XML document that literally states all of the information that is needed. The date of release (is it later than what is in the locally stored XML? New version) and the release notes. All of which are in a consistent structure and layout.And if there is a new version, THAN download the layout. The only benefit with checksum is if a change is made but was undocumented. It would detect if there was a change. EDIT: I am not saying it wouldn't work because it is definitely a viable option. And honestly I wouldn't mind going this route since the layout files aren't substantial in size anyways so the download would be fast along with the checksum calculations. I would still need a consistent file name download along with a consistent releasenotes file updated upon each change in order for notes that gets displayed to make sense. Honestly an XML document containing a list of all the changes for all the versions would be much larger than a single layout file (which is 800 short lines of text, about ~23 KB, so it is simply not a performance concern). A release notes file of some kind is definitely in order. As for the consistent file names, I believe we are going to be taking the version number out of the file names. So it will just be "TheCore *** Beta.SC2Hotkeys", and when we move to an official release, it will be "TheCore ***.SC2Hotkeys". Then we can use Git version tagging to distinguish between the versions so people can see/download the old versions if they want to on GitHub.
And you're definitely correct. The XML document would grow in size and eventually become bigger than the layout.
Also, I didn't realize you are on TheCore team, so I apologize. If you want I can easily store a vanilla file locally that would do a checksum on the latest file, do a comparison, and write the differences in a legible manner. However, this wouldn't be as chronological versioning, if that makes sense  .
Or
You can keep a version history in a seperate file that I can just download after I verified there is a new version.
So basically, I will download the latest layout file, checksum comparison against a locally vanilla file OR the checksum of the last downloaded layoutfile (which would be stored in the users settings). If there is a newer version, ask if they wish to overwrite their file, and download the release notes and display them.
Also, does this mean you would like to me to start on this?
|
On April 26 2013 01:10 DarkOwnage wrote:Show nested quote +On April 26 2013 01:00 JDub wrote:On April 26 2013 00:33 DarkOwnage wrote:On April 26 2013 00:12 JDub wrote:On April 25 2013 23:31 DarkOwnage wrote:On April 25 2013 22:59 JDub wrote:On April 25 2013 21:52 Hancho wrote:On April 25 2013 21:41 DarkOwnage wrote:That is an example of what the XML MIGHT look like. I may make some changes. In fact I would already add an attribute to one of the parent nodes that states the name of the layout rather than the node itself being the name of the layout. Yes, TheCore would probably have to switch to MINOR and MAJOR versioning, or they can just go major. It is really up to them. I think the XML speaks for itself on how I would parse through it. But if it doesn't I will make another post. Anyways, to make it easier and more stable, TheCore layout files will have to have consistent names. So the Alpha ZRM 1.0.SC2HOTKEYS file will always be = Alpha ZRM.SC2HOTKEYS. And that means the file path should remain the same too. Anyways, I have to get ready for school. I will keep an eye on this thread throughout the day though and post more details if need be. ok I did not realize that the xml document contains the entire history I really don't see how/why there should be an xml document. You could instead: Download the latest version of MapDefinitions.ini from the GitHub. This has "prefix" and "suffix" variables that define what the file names for the individual files are (prefix + " " + <layout name> + " " + suffix). Then you could download the latest version of the layout from the GitHub. If you want to have a changelog, you could diff the latest version with the version they currently have. Otherwise just copy the latest version into their hotkeys folder, and you're good to go. How exactly would you suggest I check if they have the latest version? Do I download the MapDefinitions.ini and store it locally and when they "update" I download the latest layout PLUS copy down that new MapDefinitions.ini. And I check if they have the latest version by doing a comparison on the MapDefinitions.ini file? Cause I cannot compare their current SC2HOTKEYS file because that would assume the user would never change a single keybind. If they do, bam they don't have the latest version. Right? And comparing the MapDefinitions.ini file is possible but not reliable. It could make a wrong comparison and bam, new version! Thus, an XML document that literally spells it out. How about this then: Store a checksum of the vanilla version of TheCore layout that they use locally (or the entire file), and compare that to a checksum of the latest version of their layout on the GitHub. If they are different, they don't have the latest version. Edit: The reason I'm having this debate is just b/c all of the information that you need is already there, and while the XML document thing could work, that would just be adding extra work to generate a redundant document. That would work except for the fact that I would have to download the layout file from here and run a checksum on it. I was hoping to avoid downloading more than what is really necessary. So I would have to consistently download the layout file, run a checksum. If it differs, download the release notes and display it. While if I just download an extremely small XML document that literally states all of the information that is needed. The date of release (is it later than what is in the locally stored XML? New version) and the release notes. All of which are in a consistent structure and layout.And if there is a new version, THAN download the layout. The only benefit with checksum is if a change is made but was undocumented. It would detect if there was a change. EDIT: I am not saying it wouldn't work because it is definitely a viable option. And honestly I wouldn't mind going this route since the layout files aren't substantial in size anyways so the download would be fast along with the checksum calculations. I would still need a consistent file name download along with a consistent releasenotes file updated upon each change in order for notes that gets displayed to make sense. Honestly an XML document containing a list of all the changes for all the versions would be much larger than a single layout file (which is 800 short lines of text, about ~23 KB, so it is simply not a performance concern). A release notes file of some kind is definitely in order. As for the consistent file names, I believe we are going to be taking the version number out of the file names. So it will just be "TheCore *** Beta.SC2Hotkeys", and when we move to an official release, it will be "TheCore ***.SC2Hotkeys". Then we can use Git version tagging to distinguish between the versions so people can see/download the old versions if they want to on GitHub. And you're definitely correct. The XML document would grow in size and eventually become bigger than the layout. Also, I didn't realize you are on TheCore team, so I apologize. If you want I can easily store a vanilla file locally that would do a checksum on the latest file, do a comparison, and write the differences in a legible manner. However, this wouldn't be as chronological versioning, if that makes sense . Or You can keep a version history in a seperate file that I can just download after I verified there is a new version. So basically, I will download the latest layout file, checksum comparison against a locally vanilla file OR the checksum of the last downloaded layoutfile (which would be stored in the users settings). If there is a newer version, ask if they wish to overwrite their file, and download the release notes and display them. Also, does this mean you would like to me to start on this?
I would like to see what Jak thinks of the idea first. He wants to have an easy way to download the latest version from his website (coming soon), so an installer would definitely be a possibility.
|
On April 26 2013 01:27 JDub wrote:Show nested quote +On April 26 2013 01:10 DarkOwnage wrote:On April 26 2013 01:00 JDub wrote:On April 26 2013 00:33 DarkOwnage wrote:On April 26 2013 00:12 JDub wrote:On April 25 2013 23:31 DarkOwnage wrote:On April 25 2013 22:59 JDub wrote:On April 25 2013 21:52 Hancho wrote:On April 25 2013 21:41 DarkOwnage wrote:That is an example of what the XML MIGHT look like. I may make some changes. In fact I would already add an attribute to one of the parent nodes that states the name of the layout rather than the node itself being the name of the layout. Yes, TheCore would probably have to switch to MINOR and MAJOR versioning, or they can just go major. It is really up to them. I think the XML speaks for itself on how I would parse through it. But if it doesn't I will make another post. Anyways, to make it easier and more stable, TheCore layout files will have to have consistent names. So the Alpha ZRM 1.0.SC2HOTKEYS file will always be = Alpha ZRM.SC2HOTKEYS. And that means the file path should remain the same too. Anyways, I have to get ready for school. I will keep an eye on this thread throughout the day though and post more details if need be. ok I did not realize that the xml document contains the entire history I really don't see how/why there should be an xml document. You could instead: Download the latest version of MapDefinitions.ini from the GitHub. This has "prefix" and "suffix" variables that define what the file names for the individual files are (prefix + " " + <layout name> + " " + suffix). Then you could download the latest version of the layout from the GitHub. If you want to have a changelog, you could diff the latest version with the version they currently have. Otherwise just copy the latest version into their hotkeys folder, and you're good to go. How exactly would you suggest I check if they have the latest version? Do I download the MapDefinitions.ini and store it locally and when they "update" I download the latest layout PLUS copy down that new MapDefinitions.ini. And I check if they have the latest version by doing a comparison on the MapDefinitions.ini file? Cause I cannot compare their current SC2HOTKEYS file because that would assume the user would never change a single keybind. If they do, bam they don't have the latest version. Right? And comparing the MapDefinitions.ini file is possible but not reliable. It could make a wrong comparison and bam, new version! Thus, an XML document that literally spells it out. How about this then: Store a checksum of the vanilla version of TheCore layout that they use locally (or the entire file), and compare that to a checksum of the latest version of their layout on the GitHub. If they are different, they don't have the latest version. Edit: The reason I'm having this debate is just b/c all of the information that you need is already there, and while the XML document thing could work, that would just be adding extra work to generate a redundant document. That would work except for the fact that I would have to download the layout file from here and run a checksum on it. I was hoping to avoid downloading more than what is really necessary. So I would have to consistently download the layout file, run a checksum. If it differs, download the release notes and display it. While if I just download an extremely small XML document that literally states all of the information that is needed. The date of release (is it later than what is in the locally stored XML? New version) and the release notes. All of which are in a consistent structure and layout.And if there is a new version, THAN download the layout. The only benefit with checksum is if a change is made but was undocumented. It would detect if there was a change. EDIT: I am not saying it wouldn't work because it is definitely a viable option. And honestly I wouldn't mind going this route since the layout files aren't substantial in size anyways so the download would be fast along with the checksum calculations. I would still need a consistent file name download along with a consistent releasenotes file updated upon each change in order for notes that gets displayed to make sense. Honestly an XML document containing a list of all the changes for all the versions would be much larger than a single layout file (which is 800 short lines of text, about ~23 KB, so it is simply not a performance concern). A release notes file of some kind is definitely in order. As for the consistent file names, I believe we are going to be taking the version number out of the file names. So it will just be "TheCore *** Beta.SC2Hotkeys", and when we move to an official release, it will be "TheCore ***.SC2Hotkeys". Then we can use Git version tagging to distinguish between the versions so people can see/download the old versions if they want to on GitHub. And you're definitely correct. The XML document would grow in size and eventually become bigger than the layout. Also, I didn't realize you are on TheCore team, so I apologize. If you want I can easily store a vanilla file locally that would do a checksum on the latest file, do a comparison, and write the differences in a legible manner. However, this wouldn't be as chronological versioning, if that makes sense . Or You can keep a version history in a seperate file that I can just download after I verified there is a new version. So basically, I will download the latest layout file, checksum comparison against a locally vanilla file OR the checksum of the last downloaded layoutfile (which would be stored in the users settings). If there is a newer version, ask if they wish to overwrite their file, and download the release notes and display them. Also, does this mean you would like to me to start on this? I would like to see what Jak thinks of the idea first. He wants to have an easy way to download the latest version from his website (coming soon), so an installer would definitely be a possibility.
If he gets a website up than this definitely opens up even more options. That is a discussion for a later time though  .
Just send me a PM once you guys have discussed this. I can start on it by the end of next week.
|
On April 25 2013 17:45 Hancho wrote:Show nested quote +On April 25 2013 17:23 fengshaun wrote:
how about a simple script that updates your copy?
initialize:
$ git clone <github_repo> ~/thecore
update:
$ git pull
$ cp thecore/path/to/preferred/layout.SC2Hotkeys ~/My\ Documents/Starcraft\ II/path/to/profile/hotkeys/layout.SC2Hotkeys
save it as thecore.bat and double-click. Done! I think you must have git installed for this to work
Good point! Git is not necessary. You can just download the raw file from github itself! For example, for Dvorak ZRM this would be (one line, or its equivalent in any programming language that has any sort of networking support):
$ wget https://raw.github.com/jonnyhweiss/TheCoreConverter/master/USDvorak/TheCore ZRM Beta.SC2Hotkeys ~/My\ Documents/Starcraft\ II/path/to/Hotkeys/TheCore\ ZRM\ Beta.SC2Hotkeys
Done! Simple and easy! wget just downloads network content, so translate that to any language!
Edit: And in case of multiple profiles, a loop will do!
|
TBH (which I always am), I don't really understand the logistics of all this. The website is in limbo because we've lost our web developer and haven't found a replacement (its all volunteer, we can't afford to pay anyone yet). I'll let you all discuss and try to follow along the best I can. This is what I think would be best:
-A program(installer?) that walks the player through the process of choosing their layout.
-A user-friendly automated changelog (so I don't have to do it manually, which is what I'm working on for 0.6.3->0.7 right now)
-The most simple, straight-forward, intuitive user process possible. Seriously, simplicity is the most important. I want my grandma to be able to dl TheCore and play Sc2 with it (because my GM is a GM, just sayin)
I understand not everything is possible, but I always start with ideal and see how close I can get.
Anyone willing to commit to getting this website out send me an email@ thejakatak@gmail.com Its very close to being done, but I need someone to help me put the finishing touches on.
EDIT: In other news, we have officially moved to TheCore Beta version 0.7 (same file as Alpha 1.0). We're done with the alpha now. The latest updates will always be on the github and I'll update the skydrive whenever a new version/fix comes out. This version has been tagged in github and will be forever available for those interested in it. (we will continue to tag major versions from this point forward). Just some polish left, then we go to TheCore 1.0.
|
Are there any plans in keeping a version of the core that doesn't require mouse buttons? If not, I'm going to have to stick with 0.6(which I'm happy with, but I'd like to see support for a version that does not require mouse buttons)
|
@Jose
TheCore 0.7 supports the use of side mouse buttons, or not. Its completely up to you.
|
On April 26 2013 02:32 JaKaTaK wrote:
TBH (which I always am), I don't really understand the logistics of all this. The website is in limbo because we've lost our web developer and haven't found a replacement (its all volunteer, we can't afford to pay anyone yet). I'll let you all discuss and try to follow along the best I can. This is what I think would be best:
-A program(installer?) that walks the player through the process of choosing their layout.
-A user-friendly automated changelog (so I don't have to do it manually, which is what I'm working on for 0.6.3->0.7 right now)
-The most simple, straight-forward, intuitive user process possible. Seriously, simplicity is the most important. I want my grandma to be able to dl TheCore and play Sc2 with it (because my GM is a GM, just sayin)
I understand not everything is possible, but I always start with ideal and see how close I can get.
Anyone willing to commit to getting this website out send me an email@ thejakatak@gmail.com Its very close to being done, but I need someone to help me put the finishing touches on.
EDIT: In other news, we have officially moved to TheCore Beta version 0.7 (same file as Alpha 1.0). We're done with the alpha now. The latest updates will always be on the github and I'll update the skydrive whenever a new version/fix comes out. This version has been tagged in github and will be forever available for those interested in it. (we will continue to tag major versions from this point forward). Just some polish left, then we go to TheCore 1.0.
Alright, I can create a seperate program just for the automate changelog. It will do a comparison between the original layout and the modified layout, and generate a log file of the changes. I can make it put time stamps along with a user inputted version.
I am not exactly sure what you mean by walks the player through choosing their layout? What I had in mind was there is a "Settings" form that will store the users settings. This form will also allow the user to select the layout they are wanting to use. That way it only synchronizes with that layout and doesn't care about changes made to other layouts. I was thinking of making it so the user can select multiple layouts they want to be synchronizing. Is this sufficient?
And yes, this will be very simple. Basically there will be one button called "Check Latest". It will do all the work . This all depends upon the user setting up their settings (which I will check).
|
On April 26 2013 03:10 JaKaTaK wrote:
@Jose
TheCore 0.7 supports the use of side mouse buttons, or not. Its completely up to you.
I'm a little confused then. I downloaded RRS 0.7, and to cycle through subgroups requires the mouse buttons. There's no alternate hotkey for them either. Do I just have to remap this hotkey to something? If so, what do you recommend?
EDIT: The forward and back mouse buttons are required for those. My mouse doesn't have those either-it's just a plain ol' mouse.
|
@Jose
Yes! I suggest Enter, \ or Backspace. I'll be making a video shortly as this has been brought up many times
|
On April 25 2013 12:11 thayneq wrote: Jak is consolidating the versions so there is no longer an "mouse buttons" vs "no mouse buttons" version.
I've tried asking this before and I'll try again, why?
|
Simplicity.
This cuts the number of files we have in half. It makes selecting a layout easier to understand. It also, allows each user to customize TheCore in the exact way that they want (which they're likely to do a bit of anyway). We are not going to account for each users individual preferences to where they want the following keys:
Select All Army
Rotate Camera Left
Rotate Camera Right
Next Subgroup
Previous Subgroup
Control Group 9
Control Group 10
For non mouse buttons 2 of these functions will be cut out. I'd rather let each person decide which functions they want where rather than providing individual downloads for each set of variables.
|
|
|
|
|
|
EPT
