Jump to content
Forum Login Changes ×
The Dark Mod Forums


  • Posts

  • Joined

  • Last visited

  • Days Won


Ishtvan last won the day on February 2 2010

Ishtvan had the most liked content!


17 Neutral

1 Follower

Profile Information

  • Gender

Recent Profile Visitors

5926 profile views
  1. Question: is that part about being less visible through a crack actually true with our AI visibility calculation? I know we do multiple traces from AI eyes to different parts of the player's body, but I thought that if any of the traces hit, the player was "visible" as opposed to "not." You certainly could do all the traces and then factor in a "concealment" factor based on what fraction of the traces hit. But I thought we were worried about the performance of that and just stopped testing on the first trace to hit, calling the player visible, not allowing for a concealment calculation? Multiple long traces from AI to player body points can be computationally expensive. Maybe that changed since I was active, don't know. If it's still the old way, it might be worth testing the "do all the traces and calculate concealment" way and seeing if semi-modern hardware can deal with it.
  2. That was me. I believe it was "kind of sort of" working. The hard, not working, part was to detect when the door had fully shut or just opened under fine manipulation. So it ended up in some bad states when you left off frobbing it, like able to rotate past its original limits upon the next frobbing, shut but door mover thinking it's still a crack open, etc. [EDIT: I also don't remember if that implementation actually checked for physical collisions and stopped; you might still be able to open it through things.] I can't remember if I was using hold frob + mouse wheel (not really analog), or hold frob + move mouse up and down. But it was something like that.
  3. You can try making the hollow object an articulated figure (idAFEntity). Essentially a ragdoll but you'd edit the ragdoll file to set fixed constraints between its parts (the parts being the bottom and the some approximation of the sides). I think we made or at least talked about making a boat that floats on water that the player can also enter using this system, but the floating physics weren't stable enough at the time to release it.
  4. That's on my list of things to finish if I ever set up my desktop again (objective 1: find a desk). I finished the player interface for laying the wires/anchors and connecting them up to mines. I think a lot of that made it to SVN, but some might still be on my local HD. I still had to do the actual physics of setting off the tripwire. It would be easy with static entity collision models, but I was hoping to do the more complicated moveable tripwire CM case, so that it would still work if someone did something weird/creative like put tripwires on an elevator/moving platform, or between two crates that could move.
  5. You probably also want to test blackjacking from the front to make sure that that's not possible when we don't want it to be. That's the other danger of increasing the height of the AI's head KO bounding box, you can hit the back of the head from the front and still be counted in the cone. And vice versa, if you're too close behind you'd get some erroneous hits on the front, I think. A lot of this comes from the fact that the player anim always swings their arm in the same robotic way. A real person would adjust their swing to be tighter if they were closer, but that requires some arm animation IK that's probably not worth doing. Better to do what you're doing and tweak the blackjack and KO collision boxes. Just make sure they don't let in any undesired KOs from the front on helmeted and altert guards.
  6. That is cool. It's probably a first iteration. I would have minorly tweaked the cross fading code to be a little smother, i.e., keep the green on and fade to red, then turn the green off, rather than letting it get so black. @Biker: I don't think there's a photodiode or other light sensor involved, I think he's reading the actual lightgem value and then sending it to the microcontroller that the LEDs are plugged into.
  7. Some interesting statistics in here. Not all of the infographics are a great way to display them. Also, my browser wouldn't zoom in all the way on this vertical scrolling monstrosity, I had to save it as an image and open it in an image viewer. Interesting nonetheless. Apparently SFX and music people are the hardest to come by, and correspondingly this is the most commonly "outsourced" task (i.e., indie game devs pay people to do it for them). http://www.zidasstudios.com/wp-content/uploads/2014/04/Indie-Game-Developers-1.png
  8. Regarding the blackjack hitting the ceiling sometimes and failing, I've always wanted a sideways swing option on the blackjack just for situations like this. This would be initiated just like the sideways sword swing. Would take an extra player animation and a bit of physics tweaking, though.
  9. Apologies if this has been posted here before (a quick search didn't turn it up). This is a fly-through of 17th century London done up in the Crytek engine. I would totally play this TDM FM! Video: (starts with concept art then gets to fly-through around 0:30) More information and concept art: http://puddinglanedmuga.blogspot.co.uk/
  10. Ishtvan

    TDM Combat

    I looked into adding it to the training mission before but it would require a lot of re-scripting, then we'd have to push out an official update of that map, etc. It's easier for now to do it as a separate map. It's not the same as the training that's currently there, there's a lot more to it.
  11. Ishtvan

    TDM Combat

    Yeah, not to foster discontent, but I think losing the old clear vertical telegraphing attack animation really broke the combat for anyone using the manual parry method. The newer animations are too hard to distinguish from a (your) left to (your) right slash. On an unrelated topic, do any FM authors want to help put some AI melee trainers ingame? I scripted a bunch of them 2 years ago or so, but need a map to put them in (either put them all in different rooms or have scripts to spawn them and a way for the player to choose which ones they want to spawn).
  12. Thinking about the visible hands and suck-in animations: they could have done it without any suck-in if they had perfect hand and arm IK (to put the hand and arm wherever they should go, based on your current position). HOWEVER, due to perspective distortion due to the compressed FOV, things look closer than they really are. So it looks like you should be able to touch something, but you're actually too far to touch it with realistic-length arms if the camera were where your eye is. When we tried setting frob distance to a realistic arm length, it felt way too short, like you had to be right up on things. So if they're using a realistically proportioned model with the camera at the eyes, I guess they need the suck-in to go this extra little distance? Either that or their arm IK isn't that good? But wouldn't the same perspective distortion apply to the arms, so couldn't you just display unrealistically long first person arms reaching unrealistically far, and distortion would make both the arms and the thing they're reaching look closer? I'm confused. Oculus Rift would solve all of these issues.
  13. At least someone can mod it into Sherlock- wait, no modding.
  14. This looks and sounds pretty dismal. The thing about the hands in front of the camera is: your monitor offers you way less field of view than your real life human eyes do. If we all had perfect virtual reality glasses, then seeing the hands wouldn't be a problem . But seeing them in this limited FOV corresponds to the character putting them up in front of their face all the time, as people have pointed out. The "context action" run/jump thing sounds sort of like a first-person free-running button from Assassin's Creed. That is the opposite of Thief "DNA." Occasionally, it would be nice to auto-run over a bunch of small, separate platforms (like a bunch of boards sticking off the side of a building) because it's very hard to do that with the traditional "player is a rectangular prism that lands only in one tiny spot and can never reach for things with their legs" method of jumping. But there has to be some sort of happy medium where you can jump when and where you want, and maybe hold jump to auto-hop the player's legs over a bunch of separate small platforms, or something. Then to extend this button to "swooping" between bits of darkness is straight-up ridiculous. Someone wanted to make something like Blink from dishonored, I guess. EDIT: Also, they've responded to the "frobbing without seeing your hands looks weird" issue by having suck-in animations for absolutely everything.
  15. Thanks! I'm getting a handle on it now, fortunately. If anyone needs help exporting Blender animations in the future, they can ask me, and I'll have a slightly better than zero chance of knowing the answer.
  • Create New...