Jump to content
The Dark Mod Forums


Active Developer
  • Posts

  • Joined

  • Last visited

  • Days Won


Obsttorte last won the day on September 7

Obsttorte had the most liked content!


1715 Deity


Profile Information

  • Gender
  • Location
    In a very tight spot, without a chance to noclip.
  • Interests
    Observing you. :D

Recent Profile Visitors

9559 profile views
  1. Because it is an alternative branch so to speak. That's why it is called custom manifest!
  2. Note that only missions with at least 4 ratings are listed there, so you might miss some.
  3. That's funny (and a bug, of course). I may take a look. No, the ai does not have to know the direction or where north is, nor do they have a concept of front. Both issues are not connected in any way. (My comment wasn't aimed at any of that, it was about how to handly the eye-patch special case). In regards to vision, there is a direction of the head model that is defined as forward, and the code checks whether the player is within a cone centered around that direction (in addition to some other conditions). Pathfinding is done via an abstraction of the level geometry. It's basically a table that contains information on what the shortest route between different areas is, and which areas need to be traversed in what order to get from one point to another. What appears to be a movement like in real life is basically a sliding into a specific direction, that the model was previously turned towards, and an animation played (a bit like when you move a chess figure, only animated).
  4. The DarkRadiant scripts are written with python iirc. So if you have some good ideas of what could be useful to mappers, this might be worth a start. (I am not sure whether there is any thread with script wishes, though). Also, programmers are always welcome. If you are experienced in python you will probably be able to dig yourself into C++. The bugtracker is full of stuff that needs fixing.
  5. Regarding the script function I would assume that having one function only that returns -1 if the item is not stackable as you proposed makes the most sense. I never thought of having different custom guis for different inventory items. I am not even sure what this could be useful for. I for one would be way to lazy to write several guis But in that case overwriting the existing gui file is indeed not going to work well.
  6. I can add this script function either way as I am messing around with the code currently. But maybe the workaround makes this unnecessary.
  7. Ah, now I see what you mean. My approach always was to override existing files, so I never came to the idea of doing it like that. But if the game allows items to tell the engine to use a different gui, then it should either provide the informations independent from the gui used or an alternative access (like a script function). From what I've seen in the code it seems indeed to be the case that the desired behaviour is not done by the sdk, probably as said one can't know which gui variables exist and which not. The question is whether under that circumstances it is the best way to use the stackable entity type in combination with a custom gui (the fact it is stackable is more an abstract concept, the player doesn't really have several instances of an item)? Maybe I can figure out something.
  8. The amount of the currently selected, stackable inventory item is stored in the gui variable "gui::Inventory_ItemCount". You don't have to set this manually, the sdk handles this for you. The only thing a scriptobject for such an item has to do is to perform the desired action on use and reduce the count by one. I would suggest that you take a look at the scriptobject of stackable items and the hud gui to see how it is setup.
  9. The Dark Mod subforum is probably more fitting, as it isn't related to TDM editing. Thanks.
  10. @Oktokolo There is no point in "anticipating behaviour" if it is completely random and leads to players quicksaving before approaching ai, just to quickload again on failure and repeat the exact same pattern that works this time just because a different random animation got played. And of course you can try to knockout any ai before it detects you, but that more or less neglects the whole purpose of pickpocketing. The player needs to have a chance to anticipate, some information that helps him to decide upon. When a guard is going to relight a light, it will significantly move apart a typical route, and the light won't shine immediately, but an animation is played accompanied by spark particles and sound. If it is an electric light you can see the ai approaching a switch. So there it is clear what will happen and so you can anticipate. A change of direction is normally within the shapes of the surrounding level geometry, so it makes sense and can be expected. A stationary guard that sometimes turns around will (if properly setup) do so often enough that the player is aware of that behaviour before getting close enough, so he can adjust his tactic. The issue here is a completely different one and, what is also important, not intented! This happens only with one animation for a specific class of ai. So it can easely happen that even a long time player doesn't even notice this behaviour. How do you expect someone to anticipate that under such circumstances?! The problem is that in the future every modeler making an animation would have to made aware of this, which is not likely to happen. So on the long run we would be going to run into this issue over and over again.
  11. I've filed a bugtracker for the issue. The view angle depending blind spot works basically. The only thing I couldn't get to work is to take the orientation into account, as with the eye-patch carrying ai. The issue is that the unrotated fov isn't always pointing forward for all ai (whoever thought that would be clever ). It does so for humans, but it points downwards for spiders for example. I've tried to figure out a way to get the required info from the data available, but thus far no luck. I am not sure whether it is a real issue though, as the only usecase is the eye-patch gui. If those have a symmetrical blind spot the world would probably not stop turning. The 30 degree cone one get by standard ai is actually big enough. It easely allows you to get close up to 40 doom units to the ai, if not closer (blackjacking distance is 56, pickpocketing is 40).
  12. Just tested myself, same build, same mission. No problems on my end.
  13. Maybe you should hammers this time. We all know what those dudes do secretely in the confessional.
  14. My initial idea was that, if I assume that ai can turn their head by 90° in both directions, the area in which the ai can never see is what is left if you extrude the forward pointing viewcone by 90° in both directions and take the complement. The problem is that the default horizontal fov is 150°, so this would lead to a very narrow cone in the back (doubling the angle or similar might work better). (#) Such an approach would cause ai with 180°+ fov to not have a blind spot (although I just checked and spiders, zombies, fire elementals et al. have the same viewcone as human ai). (#) If one assume that even a non-restricted ai cannot see what's behind it, then restricted ai might not need extra threatment. During this I have only taken human-like ai into account thus far, to be honest, as those are the ones with the respective head animations that cause the issue. Using a dedicated spawnarg to specify the blocked off area might also be a good approach here, as it would also be easy to modify the defs accordingly as only the base definitions need change. But from what I've seen thus far I am not sure this is necessary.
  15. Well, to be honest we had discussions about physic based puzzles since I am a member of this forum (and most likely earlier on), but the restrictions of the physics engine always made such things a cumbersome undertaking. So while we may not need the ability to mess around with houndreds of moveables at the same time, a more reliably system is always welcome. And as @stgatilovmentioned, especially the lack of proper transitivity handling is really worth a look. Personally I think puzzles (and therefore some useful physics) fit the Thief games pretty well, as they are pretty close to action adventure games. I mean, if you would have asked someone back in 1998 what game is closest to Thief, Tomb Raider would probably be on the table
  • Create New...