Frost_Salamander

@peter_spy I have to say, that is probably the most discouraging thing that anyone has said to me in recent memory. @stgatilov I have taken your advice and replaced the rebase with merge (for pulling in collaborator changes). Thanks for that suggestion, I think you're right in that rebase is probably unnecessary to introduce at this point.

OK last comment about Git usage on this thread (we can open a new one for other feedback if anyone tries the tutorial). A 3rd reason to protect the branch is against accidental pushes. Very easy to do if you are not paying attention to your current branch. I wanted to enforce code review in my use case - does that make me a 'nobody'? I'm pretty sure you don't mean any offence (and none taken), but the way it's phrased makes it sound like you are speaking for everyone. Are you just talking about your own particular use case?

Okay, so at this point in time I guess the only option now is to reopen the map file? Having DR offer something like "The map file on disk has changed, do you want to load that instead? You will lose all current changes" would be good. The bit about losing your current changes wouldn't be an issue (but the warning would be necessary) because I would have committed/pushed/merged that previous work anyways.

@greebo apologies, we have derailed the thread somewhat. One thing that comes to mind - I was never quite sure what happens in DR when I switch the underlying branch that contains the .map file. I eventually got in the habit of closing DR before merging and then reopening it, because sometimes after merging I would have local changes in my branch still. It might have been a VS Code thing as well. Anyways - if it just detects changes and reloads the map that's fine - if not maybe something around that?

Does TortoiseSVN work with Git? I know there is also a TortoiseGit client, but never used it. This is certainly an option. I just use VS Code because it is also an editor so I used it for scripts, materials files, skins files, etc. Either way, this is why I included the 'other tools' section: https://wiki.thedarkmod.com/index.php?title=Git_and_Github_for_Mappers#Other_Tools In the entire lifecycle of Hare in the Snare part 1, we didn't get a single merge conflict. As I mentioned before though, we had a clear separation of duties, and used the pull requests to make sure only the proper files were modified. And we also didn't need to lock any files. Just not a requirement at all. I get that you're probably thinking of larger scale using than just two people, but there is no reason that won't work in Git. Again, just use pull requests - if someone modified a model file that I am also working on all I would need to do is not approve the PR, or comment that I am also working on it so it might be overwritten later, etc. Again, we're not talking about a professional studio here with 20 devs working on the same map - it's like a few people who are probably in constant communication and are aware of what's going on.

It isn't complicated. It may look like a lot, but this is a tutorial so it's quite verbose. See this section, as I anticipated that response: https://wiki.thedarkmod.com/index.php?title=Git_and_Github_for_Mappers#Implications. In reality the entire process is very quick, and when Kerry000 and I use it I usually just merge the PR as an administrator as described here: https://wiki.thedarkmod.com/index.php?title=Git_and_Github_for_Mappers#Merging_your_work:_quick_and_dirty_version I suggest using pull requests for one very simple reason: the main branch is protected so you can't directly merge to it. This is a Git best practice when working in teams. Do you have to do this? Absolutely not. But if I was working with a couple of other people who aren't familiar with Git, I would sure as hell do this this. Here's an example: on Hare in the Snare Part 1, Kerry000 and I had one simple rule: he was not to touch the .map file (because he wasn't mapping, and also I didn't want merge conflicts). I used the pull request review to ensure the .map file wasn't modified. If it wasn't, I would just approve the PR. If you are working by yourself, just push to main. Nothing fancy needed there. But I would caution a little bit. Say you want to just try something out, like rework an entire section by deleting it first. You'd want to use a branch for this in case you messed up or ended up discarding the work. I'm sure you wouldn't want to accidentally push it to main right? Again, totally up to the user how they want to do this. The other thing with pull requests is if you raise one, the Github UI will tell you if there is going to be merge conflicts. If you don't feel like dealing with that, you can just abandon it and fix it in the branch first. Agree that you don't review .map file changes. But there are lots of other things in a FM that aren't .map file changes. Sometimes it's useful to just look at changes before they're merged (e.g. for awareness, or check for typos in an xdata file, to make sure file structure is correct, etc). Not sure why you are fixating on just the map changes? The rebase thing: There is much debate on rebase vs. merge, and the truth is I've just always used rebase to get the linear history correct, and never lost any data. If a merge is better/preferable, then people are certainly welcome to use that, just need a 3rd option in that Wiki section on what to do.

Okay, got a good chunk of the Wiki article done: https://wiki.thedarkmod.com/index.php?title=Git_and_Github_for_Mappers All feedback, corrections and contributions welcome. I haven't really scoured it for typos and spelling mistakes, but I'll chip away at that, and there are more sections I am planning as well. Also it would be cool if someone who hasn't used Git/Github before went through the tutorial to see how it works for them (and provide feedback if they have issues).

Getting slightly off-topic here, but when @stgatilov and I were discussing the whole SVN/Git/binaries thing I did some digging around to see how 'real' game companies deal with this. From what I could gather, it's: SVN for small projects/indie studios Perforce for large studios, or for when SVN will no longer cut it And that's it. I also stumbled across this, which looks promising: https://www.plasticscm.com/ They have a free cloud version for projects up to 5 GB (although not sure that would cut it for TDM or not?)

Thanks Greebo. Before I start writing anything, is there a way with this Wiki to write and save articles as drafts before publishing anything?

Couldn't disagree with this more, except for this part: "If you wrap the whole git into simple commands, then it has some chance.", and that's exactly what modern IDEs (e.g. VS Code, Github Desktop) and the Github/Gitlab UI do for us. Using something like Github on top of Git makes things a lot more n00b-friendly and it's important to note that. If a mapper can learn DarkRadiant and TDM, then learning the basics of Git should be a piece of cake. I would also suggest if people understand the problems it solves they would be a lot more open to it, but perhaps most mappers don't really see an issue because they are working alone and Google Drive/Dropbox does the trick for them? Anyways, working alone or not, I wouldn't be caught dead not using a VCS. I think @greebo and @OrbWeaver are right in that a tutorial would be a great help in showing what it can do and how to use it. I would be happy to do that if someone could give me a Wiki account. If I did it, it would be for Git/Github and not SVN however. I have wanted to do a tutorial anyways, and the reason I haven't is because every time I mention Git I get one or more of the following responses: crickets it's not good for binaries it's overkill I suspect 1) is due to either 'preaching to the choir' (those who use it already understand the benefits) or something around what @stgatilov is saying in that people might think it's too complex, or don't see the benefits. 2) Just not true, except if you have very large files (and a lot of them), so doesn't really apply to maps. Large videos are an issue if over 100 MB (with Github anyways). Yes, you can't 'merge' or diff binaries, but frankly who cares? I'll just take the latest version, please. You committed it by mistake? Just re-add the old version after you rescue it from your history. 3) Learning about few basic features (not even about Git, but VCS in general) and the benefits it provides make it a worthwhile investment. Nobody needs to become a 'Git Ninja' (I am certainly not one). Regarding using Git for mapping: As others have mentioned, it's great and I love it, but yes, what to do about the map-editing problem. I don't know what to suggest here because I haven't delved into how how DR and doom maps work. Without even trying it, I would guess that one issue would be with entity/primitive naming? For example if I was working on the 'main' branch, and and someone else created a new branch off that and we both added a new (but different) entity, it would have the same entity number in both maps (and merge conflict?). What are the other potential issues? As I said, I've just avoid the entire scenario because I guessed it would be problematic. We've just been using the following workflow: Protect 'main' branch in Github so no direct pushes can be done against it I will work on the map on my own branch. I can/will modify any file in the FM. Merge stuff into main periodically via pull-request (because main is protected). Kerry000 would periodically pull the latest from main, then create his own branch (I haven't bothered to show him about 'rebase' - maybe later ) Kerry000 would work on his branch and edit anything except the map file (xdata, textures, models, etc), and raise a PR when finished merge Kerry000's branch into main. We had a pretty clear separation of duties on Hare in the Snare part 1, so that made it pretty easy. However for part 2 he's getting into mapping a bit, so we will need to go down the 'import prefab' route I think going forward.

I think all he's saying is instead of taking 5 small hedges (each with say 9000 polys) and lining them up side by side, you just take one and stretch it out. But does scaling it like this increase the polys, or just stretch them? I don't know what it would look like either?

That has now been raised: https://bugs.thedarkmod.com/view.php?id=5616

Hi @datiswousthanks for this. I did end up sorting it out, but by redoing the lid. I missed the underlying cause so thanks for pointing that out. Is this is sort of thing that should go in the bug tracker? Happy to add it if so...

that's what I thought as well, but it all seems to be set up correctly according to this, and also comparing it to one of the footlockers that works. I'll play around with it some more, but either way it seems to be a bug in the assets. I tried to use the same prefab for Hare in the Snare part 1 but gave up on it then.

I'd like to use the containers/openable/MerryChest1.pfb prefab in TDM prefabs. However, for some reason the lid doesn't open. I've tried various things to try and fix it, but I can't figure out what's wrong with it. I even tried re-creating the lid (revert to worldspawn, then convert back to a mover_door and re-adding the properties), but same issue. Has anyone else tried using it? I realize the other 'footlocker' prefabs work fine, but I like the look of this one as it looks a bit more like a travel trunk, which is what it's supposed to be in the map.