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.

Would just scaling them with the model scaler in DR help with the long/tall versions? https://wiki.thedarkmod.com/index.php?title=Model_Scaling

Do we have any hard numbers related to bandwidth usage? You're right in that the video files are an issue - you do need LFS for files larger than 100 MB, and then bandwidth is a problem as you say. I don't know how popular this suggestion will be, but what about a limit on video size? If they are under 100 MB (very doable) then this goes away potentially. This post kind of suggests a lot is possible here (although it won't solve the problem with older FMs with large videos mind you). Some of this wording I think can be worked around. TDM and FMs ARE 'software projects'. They just happen to be games. I'm not sure what the issue is here. A lot of the assets are binary, yes, but a lot aren't. Skins, material files, some models, scripts, map files, etc are all text. At the end of the day, we could always just ask Github themselves about it if there is concern. Also calling LFS a hack and dismissing Git as over-complicated I think is unfair. It's very easy to use. I've been using it for years in a professional capacity and I rarely need to do anything except clone, push, pull and create/merge pull requests, and this is usually through either a code editor or UI (Github or Azure DevOps, for example). I pretty much never use Git command line, except for the initial clone and it's a copy/paste one-liner. Also, the bandwidth limitation I think only applies if you are using LFS, so the FM download thing I think would be fine - they wouldn't allow you to attach unlimited 2 GB binary artifacts as releases if they had a problem with this. Regarding Github actions - that was just a suggestion if anything needed to be done for the packaging/release process. I don't think packaging and uploading a file on release would put a burden on their servers once in a while, and I wasn't suggesting using Actions as a CDN.

Here is what an FM looks like in Github (Hare in the Snare, part 1): code: https://github.com/thedarkmodcommunity/hits1 pull requests: https://github.com/thedarkmodcommunity/hits1/pulls project board: https://github.com/thedarkmodcommunity/hits1/projects/1 releases: https://github.com/thedarkmodcommunity/hits1/releases The release artifacts are automatically generated when you create a release. Currently, this is just a .zip/tar of the repo source, but a .pk4 can be manually added as well. However, if all assets are in the repo, then you don't need to manually do anything at all, just download/rename the zip to .pk4). Another advantage of using Github for the FM is it makes collaboration much easier. All you need to do is clone the repo into your darkmod/fms folder. When one person pushes an update, the other person just needs to pull and they will have all the latest changes. They just need to run DMAP or whatever and off they go. No more passing .pk4 files around, etc. EDIT: updated links, as I just moved the repo into the TDM Github org

That kind of sucks though right? Azure blob storage is cheap, but still. What Azure region are you using? You also said Akamai CDN - that won't be free either right? Nothing wrong with that at all. There is nothing in the terms of use to say Github can't be used for this. And there is code in it (scripts, etc). But, this is a silly argument and a non-issue Can I have the read-only link please? I can't find it published anywhere. I do not want write access, and understand why you would want to keep it that way. I'm not up to anything sinister, just curious what it looks like. Dealing with hidden, closed source systems in an environment like this is kind of strange to be honest. That could be an end-state goal, yes. What I would suggest for a start is after someone releases an FM, the FM source gets added to the Github org in its own repository, and the FM .pk4 is also added as a release artifact (and yes, a link to that for the in-game downloader). The source tree and release are synchronized using the usual Git release tagging mechanisms. A huge number of companies and ecosystems rely on Github to host their releases, I don't think there is much risk involved here? When you say 'their own Github repo' and 'central catalogue', these would all be in the TDM github organization so everything is in one place. This is a crucial thing missing from TDM at the moment IMO. I would also suggest you move all your other tools and things to the TDM organization (e.g. DarkRadiant, the Perl I18N script, in-game downloader, modelling plugins, etc). Everything is all over the place right now, and between that and these hidden SVN repositories it's not very community-friendly. If some of this already exists in Github, it can just be moved/added to the org and the maintainer can carry on as usual. Because with a Github organization you can give per-repository permissions, you could give write to the FM author only (and maybe the admin team) so they could maintain it. Others could still contribute by pull request of course, but it would be up to the author (and whoever else, like admins) to ignore or accept such contributions. It's very easy to just protect the master branch from pushes and let others write to branches for their PRs. What if the author knows nothing about Git or Github? Well that's no different from now where most of them probably know nothing about SVN, where the FMs are maintained now. I suppose just an admin takes the FM source and updates the repository themselves somehow.

Would you have to pay for the Azure storage yourself? Re: the Github 'file server' - why is that abuse? Each FM is an open source project, and it can have release artifacts. This ties in with what I am suggesting with the Github organisation for TDM. Each FM can have its own repository in the org with all its source code (i.e the entire FM codebase), with associated release artifacts. By zero-maintenance, I meant that you shouldn't have to maintain mirrors, worry about hosting, etc. Yes, someone will need to create the release, but that's as simple as clicking a button and uploading the .pk4 (or automate using Github actions) Also, where are the FMs in SVN? All I can seem to find is the TDM source itself. Is there a link floating around somewhere? EDIT: "Although it most likely means tying to some particular CDN" - well this is why you would use Github as the source (jsDelivr is just a layer over top). Ultimately that's where the file is stored, and it's not going away any time soon. If Github changed anything in the way they operate, the entire internet would break.

Has anyone considered using a CDN (content delivery network) for this instead? There are free ones for open source. For example, you could publish the FM on Github as a release artifact (yeah, I know, Github...) and then something like jsDeliver can make those files available over their CDN via the client's closest POP (point of presence). All free and zero-maintenance. EDIT: Just noticed that jsdelivr doesn't actually support release assets , but in general, the idea still stands and there might be other, similar solutions available For example, forget CDN and just link to Github release directly. There is no limit on the number of files in a release, and they can be up to 2 GB each: https://docs.github.com/en/github/administering-a-repository/about-releases#storage-and-bandwidth-quotas

Thanks @roygato. Yeah the expert loot goal is probably too high, it might as well just say 'find ALL the loot'. That and... ...are down on the list to fix on a future update. EDIT: Regarding the comment about the building entrances: Most of the buildings don't have usable front doors to encourage vertical exploration. I thought players liked that? Personally I'd rather that than having to pick 10 different front door locks with guards walking by every couple of minutes.

Hi @fraten:

Hi @Geep thanks for that. Well, we can say it definitely doesn't work with uncapped FPS on, so it would be cool if someone added a note here: https://wiki.thedarkmod.com/index.php?title=Console_Useful_Controls#Notes Re: the Wiki - I don't know who all the 'old hands' are, or if they will respond, and the thought of spamming random people with DMs makes me uncomfortable quite frankly. Perhaps that's by design and if so, it's working.

Hi @Gerberox Finding the exit is pretty straightforward - would you like a hint? Also if you didn't finish the mission you'll miss out on the debrief video