Jump to content
The Dark Mod Forums

greebo

Root
  • Posts

    16435
  • Joined

  • Days Won

    23

Everything posted by greebo

  1. Yes. One has to be logged into Github to see the download links, but there's a portable package for each pushed set of changes. E.g. https://github.com/codereader/DarkRadiant/actions/runs/1218642341
  2. It's not the wrong area, this forum is fine for this, I'd say. In source means in the DR source code, it's been committed to Git. The next release will have the fix included, and if this is too long too wait, there are snapshot builds available on Github too.
  3. Seems you are talking about this one: https://bugs.thedarkmod.com/view.php?id=5702 It's already fixed in source.
  4. Yes, tracking all the things you work on into online forms is a tedious task that nobody likes, if not outright hates, myself included. Feels like needless bureaucracy invented by control freaks, and as such it feels like my natural enemy... but the only thing more tedious is to skim through dozens or hundreds of git commit messages to gather everything that's been changed in between releases, that's why I do it. And it's admittedly a nice feeling when you get to scratch something off a list when you're done.
  5. 2.13 was released in August, so I think yes.
  6. Status can't get more epic than that

  7. Seeing that nobody actually changed their status in the past 48 hours, it might as well be broken - I haven't tested it myself to be honest
  8. This just seemed to be deactivated. Not sure if it's a good feature, but there you go ==>
  9. I've confirmed two of them right away, feel free to have a go at them! Not so sure about the Ctrl+S one - I can confirm that this is not intended behaviour, but I'm not sure if there's an easy non-hacky fix for that.
  10. I've disabled the ranks feature for the moment being. If more people disapprove I'll consider re-enabling it again, I don't have a strong opinion on that one.
  11. That's already fixed, at least I'd like to believe that: https://bugs.thedarkmod.com/view.php?id=5706 But I appreciate your readiness to look into it, helping hands are always welcome.
  12. That's what effectively the solution and its configuration represents. It defines what projects should be built, like shown in the screenie above. DR doesn't do this, but one can define more configurations than just "Debug" and "Release", and specify which projects should be built and which should be skipped. IIRC, the TDM solution is using Configurations, to skip the compilation of the MayaImport DLL by default (which needs the SDK installed to compile and link successfully). It's a bit like specifying all these ./configure switches --enable-darkmod-plugins, just not as freely combinable.
  13. Yeah, I've seen a few of those mega-solutions, they are rarely nice to handle. They also tend to cause problems with plugins like ReSharper, which severly slow down your VS installation. I can set the DarkRadiant (UI) project to rely on the DarkRadiantCore project, but I deliberately chose not to do that since I want the builds to work in parallel - and technically it wouldn't be true, the UI project really doesn't need the core project to compile and link. Setting the dependency would make the solution wait for the largest core project to have finished before it starts building the second-largest project - waste of time. I always hit Ctrl-Shift-B to build the solution, and I figured everybody would do the same - but I might be wrong on that assumption!
  14. When you hit Build Solution, everything should be compiled automatically, including the Download of windows dependencies. That's also what happens on the build server too, something must be different in your working copy. This is the same for every configuration: The DarkRadiantCore module is what was missing, but I can't see why it shouldn't build when you hit Build Solution. Did you just hit F5 to run the UI binary? That might perhaps do it.
  15. This problematic situation was there right from the start, I think Fidcal solved in Thief's Den by adding trickery to the chest lid, like triggering the contents to make them frobable as soon as the chest is opened. Something similar could be applied to the situation of the secret lever that is frob-highlighted unintentionally: The thing that is obscuring the lever might need to be moved away first to reveal the lever and make it frobable at the same time.
  16. If I recall correctly, the code is not just relying on a single trace, but performs a small bounds expansion at the point of impact to find things that have been closely missed by the trace, which could be the reason behind things lighting up near or behind the trace end point. I might be remembering wrongly though since I haven't looked at that code for a very long time.
  17. A few months ago I changed a few things to the simpler and the last registration, calling EventManager.addCommand with twice the same argument should not be necessary anymore, since the events automatically find the correct command when they are connected to controls. A whole lot of things are possible through the console, and while you don't have to expose the game connection commands to the console, it doesn't hurt at all. You get that console access for free anyway, since creating a command is necessary for the UI to connect to, and creating a command automatically makes it accessible through the console entry box. No events. But Python scripts can at the very least run console commands like "TexShift '0.3 0.4'". But most core modules have a "proper" Python interface and you can work with those natively. There's a huge wiki page describing the interface, and there are example scripts in install/scripts/ A command is the thing that is registered as callable function, like "TexShift" or "SnapToGrid". A statement can be more complex, calling one or more commands in a row, with and without arguments, like: "TexShift '0.1 0.2'; TexRotate '0.12'; ConvertSelectedToFuncStatic; UnselectSelection". It's more like a macro, similar to the "bind" command in TDM. You can also create those statements and assign shortcuts to them, they are persisted between sessions.
  18. The TransientWindows are usually just hidden when clicking on the X on their corner. They stay alive in the background and are toggled, like the SurfaceInspector or the Texture Tool. There are methods to override to run code right before the window is shown and after it's hidden, in case the controls need to be updated or listeners have to be unhooked. In DR, keyboard shortcuts are assignable to all "commands" that don't require arguments to work. Commands are registered in the GlobalCommandSystem, if you do a text search for that you should find many examples. There is some support for UI stuff like toggling a checkbox and binding toggle shortcuts to registry keys, iirc this is handled the GlobalEventManager in the UI module, but I have to check to be sure.
  19. What I would do to achieve the shown example is to create a longer, upright beam, fit/adjust the texture it as long as the brush is still upright, then rotate it with texture lock enabled, and finally cut the extending parts off with the clipper. I know that's not as convenient, but as OrbWeaver described it's just not possible for the texture to follow along the shear operation. Rotating would be different (otherwise the texture lock wouldn't be working), but in this example it's the shearing that makes it very hard to sense what should be adjusted.
  20. I'm ok with introducing such an option. For me it's important to know what "applying" actually means, since there are so many options to do it. Am I assuming right that you're referring to a) assigning a texture by clicking a tile in the texture browser and b) assigning it by the Browse button in the Surface Inspector?
  21. I figured most materials in TDM maps will be lit by sources that have a flame-like colour, so this resembles the final appearance best. But of course it doesn't offer a neutral view on the material which might be desirable too. I think remembering the value would be best, please feel free to open a tracker entry for that.
  22. If it's reproducible, off to the tracker it goes!
  23. Well, we (speaking as TDM team members who are unfortunately forum mods too) could easily have pulled the trigger on the ban and lock buttons on several occasions already, but usually we prefer to handle this like adults (as you put it) and we talk it over, that's really the only reason this thread is still alive. Though we all can remember people being banned in the past (it must have been two members over the past 16 years, if I recall correctly), it will happen if people are really asking for it. I personally am pretty tired of seeing threads being bombed with that kind of bullshit. What hurts me the most is that this kind of thing is directly subtracted from the team's productivity. Devs as the only mods here have to deal with forum bullshit instead of developing source code or entityDefs. So I'd really, really appreciate if everybody pulled themselves together and make this a nice place to be around, discuss and work on TDM stealth gameplay.
  24. "I had to do it, they didn't admit they were wrong!" ++numberOfKilledThreads;
  25. No thread locking, let's just wait a little bit longer. There's still a chance that this might be the first time in the history of the internet for someone to change another person's mind merely by posting on a discussion forum. I can feel it.
×
×
  • Create New...