Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Frost_Salamander

  1. I tried the Github integration again. When I try to 'Sync/Integrate server changes' I get this: Git Exception: too many redirects or authentication replays
  2. OK I figured out the problem. I found the commit which broke it, and looking at the diff I had the 'model' property set on a brush which obviously shouldn't have been there: // entity 0 { "classname" "worldspawn" "model" "models/map_specific/scaled/square_base_stone01_scaled1.ase" // primitive 0
  3. Yeah it's on Github so I can try previous commits.
  4. I tried 'dmap_compatibility 208' and it made no difference. Still get the warning and performance issues. When you say 'split the map into halves' do you mean make a copy and literally remove half the map? Might be a lot of work to do that, or is there some other way to do this?
  5. After taking a few weeks break from mapping, I've upgraded to TDM 2.10 and went to work on my current WIP map. For some reason, the performance on my map is terrible, and I'm not sure what it is. The FPS counter is all over the place and movement is really janky. It was fine before I upgraded (and regrettably, I didn't keep my old darkmod.cfg file). Other maps seem to work fine though, so I think it's something to do with my map and TDM 2.10. While playing, the following warning is spammed continuously in the console: WARNING: idClipModel::Handle: clip model 0 on 'world (fffe) is not a collision or trace model I'm wondering if this is cause? Anyone know what this means? I don't remember seeing it before the upgrade. Also there are no errors or warnings with DMAP.
  6. I stumbled onto this video: https://youtu.be/-oTfH90psC4. I'm a huge fan of SWAT 4, and was greatly looking forward to its spiritual successor, Ready or Not: https://voidinteractive.net/. Anyways, the video is really good,it points out all the details, which we all know really makes the difference when mapping!
  7. Yes I'm doing this as well in HITS2 and my 'other' map. My main gripe is the lack of options for interiors (wallpaper and plaster), so it would be nice to have a few more options there. I read your other post, and indeed it sounds pretty complicated - I was hoping it wouldn't be
  8. Would someone be able to help me create a new texture? I had a look at this page, but a) it's very old and b) it seems to be written as if I am taking my own photographs, which I'm not doing. Also I lost the plot when it said to use the texturize plugin and I couldn't figure out how to install it . I installed in the plugins directory and as far as I could tell it did nothing - and also the article didn't say how to use the plugin. Also I have no idea if that plugin still works with Gimp, and all other tutorials around creating textures seem to be about 15 years old. I'm an ultra-n00b when it comes to this stuff. What I want to be able to do is: start with a royalty-free, no-strings-attached image downloaded from somewhere like Pixabay make a texture out of it (e.g. a wallpaper) That's it - nothing fancy. But I need some very prescriptive instructions, as I don't understand about 95% of any of this stuff. I plan to use Gimp (is this is the best option? I don't want to buy Photoshop or anything). So need to know about image sizes, pixels, plugins and whatever else that currently all seems like mumbo-jumbo to me at the moment. I would be more than happy to write a new tutorial that covers this if someone can sum up how to do this in a few sentences, as long as they don't mind me asking lots of dumb questions.
  9. For some reason, DR (v2.14.0 on Windows 10) now crashes on startup for me. I don't even get as far as being able to open up my .map file. Things I've tried: uninstalling/reinstalling installing an older version (2.13.0) - this crashes as well. installing to a different location I'm a bit stumped - it was working totally fine up until a couple of hours ago. Could someone please help - my holidays have just started and I planned to do a lot of work on my map over the next couple of weeks I've uploaded a crash dump here: https://drive.protonmail.com/urls/E48HXR3P5M#QRHycXMjP8cG NOTE: The other day I created a bug report for a crash while using the source control feature, but this (I think) unrelated as like I mentioned I don't even get to open the map file. I'm happy to open a bug report, but as it seems very strange I think it would be impossible to reproduce for anyone so will hold off for now unless someone tells me otherwise. UPDATE: I think I've got it working again. I had to get DR into a state where I could edit the preferences (basically by deleting everything in '\AppData\Roaming\DarkRadiant'), and turning off 'Enable Auto-Fetch' seemed to do the trick. So I guess it was something to do with the version control. After playing around a bit, it looks like it is because I had changed the visibility of my Github project to 'private' a few minutes before it crashed for the first time. Turning it back to public makes the problem go away. I think once DR starts and if the current FM path includes a Git repository it will attempt a fetch immediately, hence the startup crash (if the repo is private). I will raise a bug report.
  10. Yes that sounds right. I think if the new XY view was dockable that would be better, as it would then 'snap' into place and you don't have to fiddle around trying to position it. Kind of like most code editors or terminal emulators these days where you can 'split' the window into multiple panes and they all fit/line up perfectly, and you can resize them by just dragging the dividing line between them. I guess for a 3rd XY view it would need to be floating? Or could it be a choice? If you had a huge or widescreen monitor you could maybe get another XY view in the main window, but for traditional displays it would need to be floating to go onto another display. I was also thinking, is there a way with the floating windows to make them snap to position (like Snap Assist in Windows 10)? Positioning and re-sizing the floating windows is obviously nice and flexible, but I always wish I could press some hotkey and they would snap to the right or left and not go off the screen and stuff like when I do it manually.
  11. First of all thanks to @OrbWeaver and @greebo for all your hard work! A couple of comments on 2.14 that I noticed right away (and sorry I wasn't involved in the testing, I just returned to TDM after a long break): I understand why you removed the floating layout, but I liked it. I guess my only complaint is that I can no longer split the main window into 2 different XY views. I was used to being able to do that, plus have a 3rd XY layout (so all views were covered) on my 2nd display along with various other widgets. It would be good if the XY view could be split in the main window (or is this already possible?). For some reason the following settings are not being saved (I'm using the 'dockable' layout now): The multi-monitor settings - no matter what I select DR always starts on monitor 0 (I have 0, 1, 2). New XY views aren't saved. I have to add them every time I start DR. This wasn't an issue with the floating layout. The camera and other widgets however are being saved (along with their positioning) Minor gripes admittedly, but look forward to checking out the other new features
  12. A couple of things, and apologies if these options exist and I haven't managed to find them: It looks like the VCS integration doesn't support SSH? If not, would that be possible to add? I used to prefer the Maya/Max/Lightwave emulation colour theme, but found I kept 'losing' the white mouse pointer against the white background. I have 3 monitors and a really fast mouse pointer speed so dumb as it sounds it happens quite easily. Anyways, an option to change the mouse pointer colour would be good. I've switched to Super Mal which has sorted me out and may just keep that, but thought I'd mention it anyways. An option to be able to set the degrees on the rotation commands. I know you can use arbitrary transformation, but on a map with a lot of say, 45 degree surfaces it's a pain. For example, if I press 'Z-axis rotate' it will rotate 45 degrees instead of 90. Maybe a global setting? When you have applied a search filter to the 'choose model' dialogue, it doesn't get automatically cleared. This is a bit annoying when you go to use it subsequently, especially if you have a model selected and click 'choose model' from the Entity tab because you want to change the model to a similar one that is adjacent to the current one in the list. The model dialogue opens up and because the filter is active, you need to clear it first, then either search again for the current model or close/re-open the model chooser. TLDR: if the search filter got automatically cleared when you closed the dialogue that would be nice.
  13. @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.
  14. 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?
  15. 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.
  16. @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?
  17. 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.
  18. 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.
  19. 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).
  20. 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?)
  21. Thanks Greebo. Before I start writing anything, is there a way with this Wiki to write and save articles as drafts before publishing anything?
  22. 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.
  23. 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?
  • Create New...