Jump to content
The Dark Mod Forums


Development Role
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Dragofer

  1. The lantern has seen some improvements by myself, Amadeus and Goldwell. If I shared that file on Discord its probably the version that has those improvements.
  2. The volume comparison checks that the "lid" mover is actually smaller than the "body" froblock, which is probably true for almost all containers and probably only for some non-container setups. So its an additional indicator. RemoveFrobPeer seems redundant because setFrobable(0) is already being used to completely remove all frobability. Unless some other script reenables frobability of the body?
  3. I believe my version also used spawnclasses (froblock + frobdoor) to identify frobable containers, but the volume comparison is new and may help improve accuracy in edge cases. The removeFrobPeer function is also new, but since the body is already being set to non-frobable I'm not sure of the added benefit of this function.
  4. I had to pseudo-bind those clasps to the safe door by letting them translate to an absolute world position depending on their own and the safe door's rotation, via the scriptobject. Looks like a bug that this falls apart when the whole safe is rotated.
  5. I believe you can set a custom use_action_script spawnarg that gets called every time you use a lockpick-class item on the door.
  6. You can either spawn the entity with a target spawnarg pointing to the parent entity, or set it later via the addTarget event. https://wiki.thedarkmod.com/index.php?title=A_to_Z_Scripting:_Special_methods#Spawning_entities
  7. Has anyone figured out how to change the font colour in a readable? The font images have a recolour-friendly white base colour, but the GUIs always seem to set them to pure black regardless of matcolor setting
  8. Its still available, but you have to be logged in to download forum attachments.
  9. The AMA is to take place on https://www.reddit.com/r/pcgaming/
  10. I think the reason the dev forums exist is to provide a place where the implementation of features can be discussed without getting mixed up with other debates when someone believes what the devs are doing is wrong. We often post public discussion threads for features with subjective elements like the frob outline, because community feedback is very important. But there will always be vocal defenders with strong views for or against certain features, or how exactly it should be implemented in their opinion. At some point a decision has to be made and be carried through, which is what the dev forums are for. Almost all of the threads are very technical, basically explaining and discussing recent or potential code changes with other devs. Its hard to say. Its a hobby the devs do in their spare time, so people come and go when they're in the mood and when they have the time. The team page is mostly accurate except for some relatively newer additions like myself.
  11. My own take on the beta process is that devs on one side commit to adding and improving features, but also to ensuring that the new releases are, as far as reasonably achievable, free of bugs and that the new features aren't broken on release. To balance that we have a general policy to freeze the code when the beta starts, where code changes should primarily be fixes to issues detected in the beta. Exceptions are made on a semi-regular basis for changes that go further if they can be justified. That's mainly the case when there's still enough time left in the beta to get the changes properly tested and reviewed, or the risk of breakage is low i.e. because you're adding, but not changing things. For example, I worked extensively on assets this release cycle and didn't manage to get all the work done before the beta, so I was still busy until about the middle of the beta phase. However, I prioritised my work so that asset changes were ready ahead of the beta, while asset additions (which won't break anything) were made during the beta. I also treaded particularly carefully when adding the new assets to compensate for their shorter beta testing time. I might not have been around as much lately, but I only heard of Daft Mugi's slew of patches when we were discussing whether the next beta build should be the release candidate, which gets released as-is if no significant issues are reported. At that point any changes will either prolong the beta testing phase, or carry the risk of not working as intended. The plan was to reach this point at the end of january (if this was not prominently communicated somewhere it was a mistake). Personally I definitely see the value in trying to accommodate as many of these changes as possible because they make TDM more attractive to Thief players, Daft Mugi is even standing ready to introduce them to the TTLG community, and it looks like they're fairly simple changes. However, prolonging the beta comes with its own drawbacks. One is that players and mappers are delayed in getting access to all the other new features. Another is that the beta phase is a relatively draining part of the release cycle for the devs because new projects are mostly on hold while the focus is on getting to a stable build. One of the ideas behind dev builds was to shorten the beta phase by spreading out the testing. Ultimately, we've designated Stgatilov as the project lead so it's his task to call the shots on how to balance these demands.
  12. Its been quite a busy time, and another author has hopped in and is doing some marvellous stuff with the unique segment of this FM. Waiting for that to complete before betatesting continues.
  13. It would be interesting to see how the FPS is when you use func_static versions of the grass instead. This way we would know how much of this drop is caused by (A) lots of transparent textures and (B) lots of animated models. If the problem is more the latter, then it could be remedied by using larger merged models, and maybe there are some low-hanging fruit for optimising the animation code. The former would require simplification of the mesh, to the detriment of the visual quality.
  14. That doesn't work for worldspawn geometry, since it all counts as a single entity so they share spawnargs.
  15. No, I dont have time to fix them at the moment, and I think a lot of FMs that use custom briefing GUIs are affected by numerous new warnings, too.
  16. DR has a relatively new map merge feature. It should allow multiple people to work on the same map and periodically merge their map versions together. It probably works best if mappers work on separate regions of the map.
  17. Stgatilov recently improved GUI console warnings, so a lot of mistakes in various GUIs have been exposed. I think it's mainly unused remnants from GUIs that these GUIs were copied/inherited from, as I suppose people would've noticed if they tried to use those broken components of the GUIs.
  18. I believe I altered map_of.tga or a GUI reference to it as it was throwing console warnings. I'm surprised any FM actually tries to use map_of.tga as it is in core since it looks to me like a highly specific placeholder.
  19. One of them is the subtitles/readables overflow?
  20. Do you mean because of difficulties aligning the grass with the floor? That wasnt easy for me either, at least with the large grass models.
  21. I could whip up a custom script that does this by comparing the player origin with the bounds of grass models and then applies a lightgem modifier. No idea about a "proper" in-engine solution - maybe it'd be something similar.
  22. I've tried using SEED to automatically clone and distribute a model across a large terrain patch, but the performance was single-digits, probably a lot worse than if the same number of models had been hand placed. It also didnt seem to respect the spawnarg to floor the models along the patch and created too many models, but that might be inexperience in handling it. Regarding the close-ups of the grass, I think Arcturus' map just had a much higher density of alpha cards. Mappers might be able to achieve that look by closely overlapping each grass model.
  23. The old videos don't really apply because kingsal had to create new animations and rigs due to modelling app incompatibilities and a lack of source files. Not to mention he also added more variety in shape and appearance. (My previous comment was also a nudge-nudge-wink-wink kind of thing to FM authors with suitable WIPs).
  • Create New...