Boards and overlays

[geezer09]

What is the design decision (if any) for storing boards and overlays in two formats. From what I understand, all boards are kept in the repo in both the zipped and unzipped format. Everytime changes are made to a board, the zipped file must be uploaded, the unzipped files updated and a change to boards/v5boardVersions.xml made. This is a bit messy and error prone.

Is there any reason we can't only keep one version (probably the unzipped version as it is easier to work with) to facilitate changes and improvements?

[zgrose]

GitHub is serving two roles:
1- The source repository
2- CDN for downloading into VASL on the client

Everytime changes are made to a board, the zipped file must be uploaded,

Unless someone has some very wonky workflow, this doesn't seem like much of a problem. One has to test their changes, after all, and you can't do that with just the source files.

[derimmer]

This definitely does not apply to all boards. AFAIK, only los-enabled boards have their source files stored in the repo. For other boards, only the board archive zip file is stored.

New boards can be added by unloading the zipped file and an updated v5BoardVersions.xml file. For los-enabled boards, our practice has been to upload the unzipped board files to the repo as well. But this is a practice and not a requirement.

The v5BoardVersions.xml is currently necessary to enable auto-syncing of boards. If there is another/better way to trigger the auto-updating, I am happy to have it implemented.

[geezer09]

I think ideally, v5BoardVersions.xml would be automatically generated instead of having to be manually updated. However I think that is acceptable the way it is.

What I don’t like is the zipped files. Maybe i’m missing an extension or some configuration, but it is impossible for me to work on these inside my IDE. I have to download them and then unzip the files to look at their contents, then i need to zip them up before uploading it back to the repo. I find that process annoying and would prefer to see only the unzipped files in the repo.

Any reason not to make that change?

[derimmer]

To be clear, we understand that bd01 is a zipped file? With the file suffix removed.

bd01.zip is not a valid VASL file and won't work.

In your local repo you will find a boards/bdFiles directory and a boards/src directory. The board/bdFiles directory contains the zipped bdXX files which you need if you want to run vasl within your ide. The board/src files contain the source files. I don't know of any way to get these files to work in the IDE as boards. They can be useful for all sorts of things while coding but they are not used at runtime, afaik.

If you temporarily rename a file from boards/bdFiles by adding a .zip extension you can look at its extension, inside your ide or outside of it. Just as you can for a .vmod or a .vmdx (extension) file. Just rename them to .zip and they will work as a .zip file normally works.

Based on the above, I don't see how we can remove the zipped boards from the repo. What am I missing?

[geezer09]

So basically what I am saying is that it is more difficult to work on zipped files. A lot of the advantages of source control is not applicable to zipped files, you cannot see the history of changes that are made to a it and you cannot see the contents of those folders in your IDE.

It is just generally not good practice to have zipped folders in your repo unless these very rarely change.

I think we should get rid of the compressed files and only keep the uncompressed version of the boards and overlays. This would make updating these boards easier and keeping track of these changes more transparent. If I did more work on the map boards, I would be more insistent on making these changes, however, it seems like people are used to this akward workflow for making updates and so if you guys think it is fine the way it is or there are other reasons I am unaware of why it should stay this way, fine by me.

[derimmer]

We need the zipped board archive files, such as bd24, to be in an accessible repo somewhere in the known universe so that VASL/VASSAL can go and get the files when players click on the board names in boardpicker.

At present that "somewhere" is hardcoded in the buildFile entry for <VASL.build.module.map.BoardVersionChecker> as boardRepositoryURL="https://raw.githubusercontent.com/vasl-developers/vasl/develop/boards/bdFiles".

This could be changed to anywhere but (a) it needs to be in one place and (b) we still need to create the bdXX files to populate it.

If there is a better way to create and store these zipped files, we should explore that.

Until then, if we "get rid of the compressed files and only keep the uncompressed version of the boards and overlays", how does a VASL user get a new board?

[zgrose]

@geezer09
that folder of the repo is acting as a CDN for downloading boards into VASL on the client

This seems to be the salient point you are missing. Everything else you mention is correct.

[geezer09]

I understand the part about the repo being used for downloading mapboards, what would prevent those files from being downloaded if they were not compressed? Given their small size, this would have minimal effect on download times.

[uckelman]

You'd need to check the HTTP headers for board downloads to be sure, but it's possible that Content-Encoding is being set and the downloads are being compressed anyway.

[zgrose]

It's not the compression that is important for the bdXX files, it's the packaging. Could VASL download all the bits of a board and package them up on the client? Sure, but why bother. The maven file should already be doing all the board packing, IIRC.