Small Patch

[SJuliez]

Hi guys, small patch attached. It cleans up drawHex() in boardview1 a little (readability and removes variables no longer used and the zoom factor of 3 that - I think - I accidentally left in there a few months ago). Also, it adds the boardview tooltip to the lobby (minus the heat and movement of course but plus the quirks that were already shown there). Well. This website doesn't like .patch files, so I added a .txt to it.

git.patch.txt

[arlith]

If you're familiar with git, you can use pull requests on GitHub for making contributions. It works pretty slick in my opinion, but it does require being familiar with git, which can take some time to learn. I could probably give you a hand learning git, if you're interested.

[pheonixstorm]

Having your own fork makes things a lot easier.

[arlith]

Alright, I applied this diff in 16db69b.

The only thing I didn't apply is this change:

         ITerrain basement = hex.getTerrain(Terrains.BLDG_BASEMENT_TYPE);
-        if (basement != null) {
-            depth = 0;
+        if (basement != null) depth = 0;

-        }

I get what you're doing, but as a stylistic preference, we want to keep the braces.

[SJuliez]

Hi Arlith (not sure how to directly respond to your post),

thanks! I was away for the weekend, thus no reponse. I'm not familiar with github (nor was I with sourceforge). But anyway, if you want me to use "pull requests" I'll try to see what this is/how to use. As last year with the tooltips/firing arcs, I'd like to contribute small things mostly UI-related as time allows.

As to the fork mentioned by phoenixstorm, Im not sure what this is about either. I can keep my own changed copy of MM on my PC anyway though Im pretty certain Im not going to paste in my own changes again with every new MM release. I'd rather have MM evolve. If some change isnt wanted, than thats alright with me.

[arlith]

I don't think you can reply directly to a message like in SF. In GitHub, you just reply on the issue, and it's all one linear conversation (not threaded).

Anyways, how familiar are you with git? The difference between git and svn is that git uses a "distributed" model. Each time you clone a git repository, you create a new complete copy of the remote repository (unlike in SVN, where your local copy is not the same as the server copy). This means that you can make local commits to your own repository that may not get pushed to the remote repository.

To achieve this, git uses SHA-1 to create a hash for each commit, and this hash will remain the same regardless of which machine hashes the commit. This allows git to resolve commits regardless of where they come from.

What this leads to is this fork/pull request model in GitHub. On the upper right of the MegaMek github page, there's a Forks button. This can allow you to create a "fork" of our repository. Basically, it's your own clone of our repository, that you can maintain. You can then clone this repository on your machine and make commits to it.

Then, once you've made a change to your repository, you can go to the MM page and request a pull request. Basically, it's requesting that we pull a commit from your repository and add it to ours.

The advantage of this is that it's use mechanisms within git to resolve the code changes, and the pulled commits will actually contain you as an author (helping with attribution in the project).

After saying all of that, in the end it really comes down to how comfortable you are with git, and how much you want to learn how to use git...

(I typed this all off the top of my head, so there may be minor inconsistencies/issues)

[SJuliez]

@arlith Hi again, thanks for your time! I have a few questions before I cause some github ammo explosion. I looked into forking by pressing "fork" and had a fork faster than I had planned. So I downloaded it and played around in it. I guess I could now "commit" or "push" changes and they would hopefully arrive in my own fork. The only git repository eclipse is showing me is linked to https://github.com/SJuliez/megamek.git. Sounds right, but it still makes me uneasy. Therefore: 1) Can I accidentally overwrite stuff in the megamek master? 2) Can I safely delete branches in my own fork? It feels as if I should install my own branches to play around with different stuff so it all doesnt get mixed up too much, right? 3) Something else: Do you know why some things are implemented and pushed around as interfaces, e.g. IBoard and IHex. I keep expecting to see some class other than Hex wanting to implement the same behavior, but what class would that ever be? Does this have advantages?

Thanks! S

[arlith]

1) No. At the very least, you don't have permissions to push changes to the MegaMek repositories. But, when you fork a repository, it creates your own separate (but linked) repository. You can make commits, branches, etc to this repository, and it doesn't affect MM at all, unless you make a pull request.

2) I guess I answered this above

3) I was not involved in this process. I think Netzilla has made some changes to "interface-out" some of the classes, but I don't believe he did them all. I honestly don't see a purpose to most of the interfaces we have (such as IHex, IGame, IBoard and the like), but I assume whoever did it had a reason, so I haven't ever changed it. I could see the purpose with some of the UI classes (such as IBoardView), where you could technically have multiple implementing classes, but thigns like Hex, Board, and Game are basically always going to be the same, so, I don't really see the point in an interface.

[arlith]

I may be telling you something you already know, but since you quoted "commit" and "push" I wanted to point out the difference between the two: commit will take a bunch of changes that you have stagged (via things like git add) and "commit" them to your repository (make a commit, which is identified by a SHA-1 hash, and save that with it's commit message into your repository). You can make commits to keep version information locally. At some point, you will want to update a remote repository with the commits you have made locally; that's what push if for. Push allows you to "push" all of your local repository changes to another repository. You have "remotes" which keep track of the different repositories you know about. By default, you'll have the "origin" remote, which is the server you cloned from. Git status can tell you information about the differences between your current local branch and the remote version. Like, if you make a commit locally, and run git status, it might say something like "branch master is X commits ahead of 'remote/master`". You also, at some point may need to update your local repository with changes from the remote. You do this with git pull and git fetch. Pull will fetch remote changes, and merge them in. Fetch just gets remote information, but doesn't merge.

[SJuliez]

Thanks! I didn't know any of this. I'm not a professional programmer at all and haven't been programming much besides some Word macros at work for the past 12 years. Back in the nineties sourceforge wasn't such a big deal... Now that the kids arent so small anymore I can spend a little time with something like this. BT & programming = good combo.

[arlith]

Yea, I'm not exactly a software engineer either, but I've got a lot of experience with git, so I'm happy to help. There are also a lot of freely available tutorials and books on git.