I’ve created 3 vassal mods so far. One thing I was wondering: How do you all practice version control?
By that I mean: do you have a good way to ‘undo’ something if you realize you’ve messed it up after hitting ‘save’?
In my previous efforts I generally started a new work session by saving a new version (If I last worked on v0.1.5 then I’ll open that up and save it as v0.1.6 before I begin). This way at the very least if I messed something up and didn’t notice before hitting save, I’d never lose more than an hour’s worth of work. The major downside is that now vassal has a new file in the menu that I have to remember to remove.
Is there a better way? Something that keeps separate versions every time you hit the ‘save’ key?
1 Like
Use git, and use something to construct the module from the files in your git repo.
Here’s a simple example:
The non-code files are in dist/. Maven builds the custom code and packages everything up using ./mvnw package.
I keep my development modules on DropBox. As long as I am within capacity and internet connection is up, any saves are then available for recovery via the file history. Other cloud services have similar, except (in my experience) iCloud, which I think assumes that you are relying on Time Machine (ie local backups).
Dropbox has helped me recover from many a mess up, such as you describe.
Hi,
I would recommend Git - probably with some cloud store such as GitLab or GitHub.
Since I use a combination of LaTeX (with my package wargame) and Python (with my module pywargame) to build VASSAL modules, I can utilise things like GitLab’s Continuous Integration (CI) to automatically rebuild a module when I have made sufficient changes.
By using Python, I can express the module code in terms of functions and constraints, which makes it far easier to implement functionality in a module and a deeper knowledge of the game mechanics into the module. I hope something like this will be more integrated into VASSAL version 4.
Essentially, I will have code like
from vassal import *
with VMod('MyGame.vmod','w') as vmod:
buildFile = BuildFile
game = buildFile.addGame(name='MyGame',verison=0.1)
and then add stuff to game, files to vmod, and so on.
Unlike cloud services like DropBox, iCloud, Google Drive, a proper version control system like Git allows you to roll back to any point in your development history, branch off - and easily reintegrate that branch - early developments, and many other things. What’s more, with Git you have a local copy of your repository which means you are not tied to a net connection, and any local changes you do, or is done elsewhere, can easily be integrated both remotely and locally.
Anyway, my two ¢
Yours,
Christian
Personally, I don’t see the usefulness of a source version control like Git for VMOD development, unless your module employs custom Java code for vassal extensions, or if you are editing the buildfile. Those utilities shine at managing line-level changes to source code, supporting the viewing and merging of change sets.
I use a simpler method for my VMOD development. I create an initial working version of the module by appending the letter “a” to the starting version number and begin making my changes to that version. For example, if I am making changes to a module with ModuleVersion = 2.1, then I create my first working version with ModuleVersion = 2.1a.
I simultaneously maintain a text document summarizing the changes that I make, with a focus on listing the module traits or other elements which I have changed (but not necessarily the changes that I made to them, which can be seen by editing both versions of the module simultaneously). I periodically save the working version of my module while testing (e.g. - as Module_v2_1a.vmod) , and if I decide that my changes since my last save were going in the wrong direction, I close without saving, then re-open the last saved version and resume.
When I have accumulated and tested enough changes to justify a"checkpoint", or the next set of changes are tricky and prone to error, I make a final save of the current working version, then increment its ModuleVersion (e.g. - from 2.1a to 2.1b), save it with the corresponding new file name (e.g. - Module_v2_1b.vmod), and continue with my changes using the new working version.
This is quite similar to what the OP is using, but there are two differences:
-
By maintaining a summary of my changes, I can go back and identify them by opening the old working version in which they were introduced. This is useful if later testing uncovers a bug with those changes, which need to be identified, then debugged or even backed out.
-
By using temporary version strings which append a letter to the starting version, I don’t consume any future version numbers. By basing those temporary version strings on the starting version, I leave my options open as to what the final released version number would be. For example, if my hypothetical changes to Module_v2.1 ended up being solely bug fixes, I might release it as version 2.2, but if I decided to add a new feature, I might release it as version 3.0.
None of the above is rocket science, and I don’t claim it’s the best method of VMOD development, but I thought I’d add it to the discussion.
Cheers,
Jim Hunter
(Currently working on TPStalingrad_v1_0y.vmod and hoping to avoid using double-letter version suffixes).
1 Like
I agree with all the replies encouraging use of git, but I’ll go ahead and throw in my $0.02 via a link to one of my Vassal module repos (the only public one so far):
rummelsworth/vassal-module-kassala: A Vassal module for “Kassala”, a wargame. (github.com)
The build/unbuild scripts for the vmod file are particularly valuable, probably the cornerstones of my module authoring experience. I’ve used this repo as a template for several other repos, tackling some bug-fixes and feature-adds in modules authored by others. So far, it’s worked very well.
Anyway, good luck! Having a smooth experience while authoring modules is almost as fun as playing a good game 
1 Like