Jump to content
The Dark Mod Forums

Dragofer

Development Role
  • Posts

    2626
  • Joined

  • Last visited

  • Days Won

    157

Everything posted by Dragofer

  1. The way Id do it is sys.VecToAngles( point2 - point1 ); That gets you a set of angles from 0 to 360 - if you need their overall magnitude you could use sys.vecLength( angles ); Alternatively you can convert them with sys.angToForward( angles ); if you only need the angle on the horizontal plane. You can also use anglemod180( angles ); to convert angles to the range -180 to +180. I believe that function only lets you do 1 angle at a time. @thebighwere you able to get persistantargs to work? @MirceaKitsuneI think you'd be better off respawning an AI with the desired properties. I highly doubt TDM allows you to alter an AI to that extent.
  2. Secrets only get shown in the stats screen if the FM uses the official system. Before that was introduced a lot of FMs used a selfmade system.
  3. Yes, overwriting individual core entities with custom .def files in an FM archive is now uncomplicated after the overwrite rules were changed in a recent TDM version. The FM will be isolated from any future changes to the player entity, however - even if they may be rare.
  4. You can always add it via script, but itll be too late because the spawn frame code events have already happened. i.e. the lantern won't be part of the weapon index. This is a generic def file for player-related entities. If you overwrite a core def file you have to include everything, otherwise those entities will be missing from the game.
  5. Adding that def_weapon spawnarg is indeed the only change made for this lantern. In fact the file is outdated because it doesnt have the bobbing spawnargs that were added in a recent TDM version. It doesnt look like there's a way to replace this via script, currently. Player.cpp does various stuff with the def_weapon spawnargs in the spawn frame, including setting up a weapon index. There's also stuff that seems to be called after map start like idPlayer::UpdateWeapon which reads out def_weapon spawnargs, so any dynamic approach should include appending a def_weapon spawnarg for the lantern to the player entity. All in all, adding custom weapons is quite limited. Besides the requirement of the above core file overwrite, we only have 2 extra hotkey slots for custom weapons with no way to set them via the menu. In a previous dev discussion it was decided that we already have too many hotkeys so some alternative approach should be tried i.e. a weapon wheel like in Dishonored.
  6. This is true, but the fact is that the viewmodel only consists of a bare arm (animated model), with something bound to it (static model). The depth hack only applies to the arm model itself. If you want to stop the lantern clipping through walls you have to make a new version of the animated arm model that has the lantern integrated into it.
  7. Thanks for asking, Ive figured it out in SLL for making those self-fading readable items. I think it was a matter of setting the colours in the GUI stages in a certain way.
  8. Are you sure that's the materials' names? Usually materials that use textures from the props folder dont have paths in their names. You can look them up in the DR media browser or in the model chooser for that model.
  9. I think setSpawnArg is intended for setting spawnargs on entities that you're going to spawn. You can use it on sys followed by sys.spawn()
  10. The most likely cause imo is that the objects are further from the map origin, the larger coordinates leading to minor rounding errors.
  11. The family portraits were generated using AI by Wellingtoncrab, using ingame screenshots of the characters as a starting point. It took a lot of iteration to get the appearance shown in the portraits.
  12. 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.
  13. 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?
  14. 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.
  15. 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.
  16. 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.
  17. 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
  18. 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
  19. Its still available, but you have to be logged in to download forum attachments.
  20. The AMA is to take place on https://www.reddit.com/r/pcgaming/
  21. 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.
  22. 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.
  23. 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.
  24. 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.
×
×
  • Create New...