Ishtvan

Is there a way to make checkboxes get checked off in realtime by an external script? I would like to have a list of melee combat drills that the player has completed successfully. It doesn't have to be a frobable readable, it can just be a large GUI that the player can read from afar, like a board on the wall. I just want it to display GUI text and a check box that gets checked off. I know we can have a menu gui with boxes that get checked off, but how hard is it to do with an ingame GUI with an external script telling it when to check off the boxes? Is there any guide I can read to learn how to set this up? We had that one experiment with an ingame objectives list... I can't remember if that was checked off in real time or not?

Weird. Did you change the gravity setting on anything and forget to change it back?

Cool. Greebo & angua know better than me, but I think the AI pathing system uses the visportals to break areas into manageable chunks as well. So it makes sense that visportal weirdness could cause AI weirdness. Hopefully we can figure out how to fix the visportal without removing it, though, because we still want them in there in general.

That's interesting. We didn't model lift force or higher-order drag, just a very simple Stokes' drag, F = -gamma*v (actually this was already standard in D3, just had to put in a value for gamma). The high velocity drag equation would probably have been more accurate. The downward rotation of the arrow ingame is actually all fake, not real physics. It's probably not the most accurate flight model in the world, but we wanted something fast to calculate and simple to maintain in the code. I'm glad it feels right to you, because at this point, we've been released for a few months and everyone's gotten used to the arrow trajectories, so we probably don't want to change it.

You could almost run the mod on a Mac, but one or two platform-dependent things we added haven't been ported over to Mac yet, mainly because we never got enough Mac programmers/testers to make it happen.

The air drag could still be a bit off. Doom3 only applies a drag force equal to a constant times current velocity, whereas I remember reading that arrows need higher-order terms to be modeled accurately. That might explain why it appears to you to drop wrong near the end of its trajectory. We don't have any plans to tweak it more at this point, though.

Switching the lit/unlit skins sounds like something we should build into the light entity/entities itself, like we do with our flame-based lights. Then it could hopefully work without having to set it up by hand every time.

@STiFU: There exists beer for all?

Yes, the mantle key (not jump mantle) can sometimes work to get you out of places you're otherwise stuck. Those places should still be fixed with nonsolid items and playerclip brushes though, because you shouldn't get stuck in the first place. I normally use only jump-mantle. So this is the only time I end up using the mantle key, as a last resort before using noclip to get unstuck. Sometimes even the mantle key doesn't work if you are stuck and there's nothing you could mantle from that position.

Woah, then I could play them through the IR viewer at work. Sweet!

After playing for a while I could eventually save again without being booted out. Weird. Great mission! I really liked sneaking around the outside looking for a way in, then inside was very interesting as well. Issues: Hilarious moments: Secret spoilers:

For some reason, with the current SVN build, I can't save in this mission. Neither quick save or normal save work right. It generates a save file, then hangs forever, not resuming the game. Guess I'll be playing ironman style. EDIT: Weird, I can restore the savefiles it creates without a problem, but every time I try to save it hangs. It's like some weird Oddity-inspired punishment for saving, you have to wait a minute to load up again before you can continue. Guess I'll look at what the logfile says later.

I agree with Tels that the hard part is probably optimizing when the tests are done. The tests themselves aren't that hard, and it could be done with scripting, but you probably don't want them running on every candle in the map, all the time. One might make to make a subclass of idMoveable in the SDK just for candles, that does these tests only when it is "active" (moving), and not when it's at rest.

It would be harder if the arrow were slower because the guard would be more likely to randomly change directions before the time it would take the arrow to reach the spot you anticipated his face/eye would be.

The argument was that it's harder to lead a moving target with a slower-moving arrow (like Thief 2 arrows). Especially when the target can randomly zig and zag while searching. This is true, but we offset the ease that comes with faster arrows by using accurate armor detection to reduce the size of the target you have to hit.

But as far as I know, those anims aren't actually being used for 3rd person right now. I don't think anything happens when you swing a blackjack in front of a mirror. The animation files in the 3rd person directory are just copies of those in the 1st person directory, pretty sure they're supposed to be different, since the coordinates of the zero point are different, right?

Regarding the arrow velocity, it is fairly accurate. I set it based on this site ( http://www.kmtargets.com/kmtargets_physics.aspx ), which gave a number of 56 meters/second. Obviously this is going to vary a lot with the specifics of the bow, but this calculation assumed a 40 # draw, recurve, which seems reasonable for the shortbow our thief uses. 56 meters per second gives 2210 doom units / second (assuming 1 doom unit = 1 inch). This is the arrow launch velocity we're using. [EDIT: This calculation also assumed modern materials, meaning it probably over-estimated the speed a bit. Maybe the thief's bow draw is a bit higher than 40 #, but the launch speed is the same due to lower efficiency and higher arrow weight.] When we first set this up, people did in fact complain that it was too fast. In fact, there was concern that an arrow this fast would make it too easy to kill guards, and I had to argue that it wouldn't, since guards can have helmets, and you have to aim for an area that's not covered by armor. In the public response to the alpha release, we often heard "arrows seemed too fast at first, but I got used to it." These posts coming several years later are the first I've seen saying that arrows are too slow. We definitely can't please everyone.

There's some excellent gameplay in this mission! I tried to ghost it (saving/restoring when failing). I was stuck at 920 loot needing 1110. Somehow missed a lot of stuff in the loot list even though I was searching in those areas. Eventually my only save file got corrupted, so I'm done for now. .

That was a fun little mission and excellent for 2 weeks work. I did manage to get stuck on . Secrets:

This mission was a lot of fun and looked excellent! (Maybe this will finally put to rest the "TDM is too clean" naysayers) Could have used a few more readables but I understand Railgun wanted to be done with it. The AI patrols were great IMO, just the right length so it took some effort to learn them, but not overly complex. I ended up with 58:13 time, no KOs, 5 pickpockets, 2025/2260 (missed some loot apparently). I also saw those chests becoming unfrobable when closed. Mod-wise, we might have to make the door opening/closing sound have a larger falloff radius. A few times I was in a room that didn't seem that big, yet I couldn't hear the doors opening/closing at all maybe 10-15 ft away. It's nice to hear the doors, especially if you're well lit and want to hide quickly as soon as the door opens.

Wait, the md5 animations are all the same between blackjack and blackjack_view. So the good news is the modified swing should work. The bad news is we should probably get rid of one of these if we're not going to have 3rd person blackjack animations (for mirrors, etc), and the def file should probably be changed to point at blackjack_view instead of blackjack... Anyway, good enough to test for now.

Hmm, it looks like we should have used the "blackjack" folder instead of "blackjack_view", because the existing animation it's using is in the "blackjack" folder. I'm not sure how it ended up this way, I guess Domarius originally set it up? Usually one is the 3rd person animation and one is the 1st person. I thought view was 1st person, but the blackjack def has always been using animations in the blackjack directory, not blackjack_view. I'll try moving the 16 frame version to the other direction, but my guess is if it was created from blackjack_view/swing instead of blackjack/swing, it may not work and we will need a doubled-frames version of blackjack/swing.

Well, I'm sure we'll get a prefab out of it eventually. I also tried it with "real" physics using a moveable plate and a few springs and a shaft, but it was too buggy to work reliably, and I kept having problems like the plate would get jammed on one of the sides and not pop back up. D3 physics seems to cut a few too may corners to make it work reliably. (For example, contact points aren't always at the point that actually should be making contact) It's two separate collision models on the same object, if I remember right. One is used only for stim/response. It might only exist at the time the stim response test is being done, I forget.

The vehicle-related scripts can actually be adopted to make a remote-controlled rat fairly easily. The hard part is getting the camera to follow the rat, never quite got that working.

@Fidcal, that sounds like an excellent thing to have as a general prefab. As for the Indiana Jones stuff, you're correct that it all has to be faked, there is no real weight physics (and probably won't be in this engine). That doesn't mean that it can't be faked, though, like with a specific object that you want to set down, or maybe a script that adds a stim to moveables brought within the vicinity of the pressure plate (for performance reasons it would be bad to have a stim constantly running on all moveables in the map). From what you've said it sounds like you're using a normal area-based stim. I would try a collision stim in combination with a normal area stim (maybe using a hidden objective to get the conditions right). I.e, did the thing just physically hit the pressure plate, and is it still in the right area. You might also be able to get away with just a standard stim if the stim/response radii fit very tightly around the objects. You can select "use bounds" for the stim radius to make sure the stim bounds only extend out to the object bounds, and should be able to get it within about 1 inch that way.