snatcher

TDM Modpack v2.4 released in the opening post Attention! autocommands.cfg file included. Starting with TDM Modpack v2.4 the F1 and F2 keys are reserved for mods. If you have any key bound to F1 and/or F2 please use a different key. Since the number of skills keeps increasing the F1 key is now a shortcut to the" Skills" category. And since the Tools category sometimes includes useful custom items (such as the "Peculiar Lenses" in Iris) the F2 key is now a shortcut to the "Tools" category. Neither of these two categories can be set to any hotkey in-game currently, so we are using the built-in autocommands.cfg file to set up the keys. It may be the case you already make use of the autocommands.cfg file to configure other things to your needs or liking therefore consider yourself warned. The autocommands.cfg file included in the Modpack can be easily deleted by accessing the Modpack in the MODS folder. ------------------------------------------------------- What's new in TDM Modpack v2.4? Ever wanted to know what was going on on the other side of the door before attempting to intrude? The peek is a built-in feature that mappers must setup individually in every door. Unfortunately, as good as the idea is, it is put to use only on a handful of missions. The new "Peek Door" Skill allows you to virtually peek through any door (*). Just get close to a door, select the "Peek Door" Skill, and press the "use" key. (*) by "any door" we mean any standard, human-sized door. A normal door, if you like. Thanks to the invaluable help of @Dragofer the mod works extremely well but mind you, we cannot test each and every door out there and, from time to time, you will get to see a weird view. Let us know which doors don't quite work and we shall take them to the lab for further analysis. In the same line, you may stumble upon a door you think you should be able to peek through, let us also know about these cases. You can find the download in the first post. Cheers!

Dear taffers, The next version of the TDM Modpack will include (yet another) player skill. That would make it five in total. Since there can be many inventory items, and many inventory categories, I have been using locally the autocommands.cfg file to bind F1 to the "Skills" category and F2 to the "Tools" category (neither of these categories can be set to any hotkey in-game currently). I would like to offer a similar configuration right out of the box to TDM Modpack users. Before someone tells me I shouldn't toy with user configuration files please know I am fully aware of it. Regardless, and thinking of the less tech savvy users, I would like to provide a better TDM Modpack experience. I can think of two alternatives: Provide my own autocommands.cfg, which would override any custom autocommands.cfg the user may have (not good) Provide an ad-hoc autoModpackCommands.cfg (good but I don't know how to "auto run" it) Any ideas regarding the latter?

Merry Christmas Heuli and all

Want to take a peek? Are you up for some door hunting? Preferably players familiar with mods. Limited number of seats. Sing up here or privately.

Ridiculously large doors are now properly supported, thanks to @Dragofer

Both options can coexist nicely Work continues in the background and the level of support from @Dragofer with the spatial riddles, complex calculations and overall feedback is outstanding, and I am grateful. Everything is coming along better (and faster) than anticipated.

A little off-topic but not that off-topic: To control the speed with the mouse wheel. There's a proof of concept here. Mind you: setting it up for the first time is a little cumbersome but once you get it to work and get used to it it's a treat. I have been using it for months, always.

Time to re-think this point. I knew some doors didn't have (moveable) handles but I didn't recall there were so many without The peek should then work on any door - with or without handle - and that's a problem because you don't want to be able to peek through each and every large or small door / lid / cover, do you? In line with original vision of this mod I will restrict the mechanic to "human size" doors, and see how that goes...

Indeed!!!!

hmm look at these twins: Dimensions on the right: 64, -4, 0 Dimensions on the left: -64, -4 ,0

That the forward peeking point goes in one direction or the other doesn't' bother me. What bothers me is that the flame gets off center. For some reason I think the current angles of the door aren't taken into account properly.

Here is a fail (the flame gets placed in the exact same pos no matter where I look the door from): peekVector and playerViewVector almost the same? No: (1, -0, -0) vs (-0.01, -1, 0) delta and magnitude of delta almost 0? No: (0.99, -1, 0) & (1.404918) peekVector doesn't get flipped? It gets flipped Same door in the same pos but from the other side (the flame gets placed in the exact same pos no matter where I look the door from): peekVector and playerViewVector almost the same? No: (1, -0, -0) vs (0.28, 0.76, 0.59) delta and magnitude of delta almost 0? No: (1.28, 0.76, 0.59) & (1.598738) peekVector doesn't get flipped? It gets flipped

Ouch, of course, of course! Ok but let's, for the moment, exaggerate the effect a little for testing purposes. Here is the result (1 flame out of 6 made it home, the others landed somewhere around the surface): void playertools_compass::inventoryUse(player userEntity, entity frobbedEntity, float buttonState) { entity door = frobbedEntity; vector offset = 0.5 * (door.getMins() + door.getMaxs()); vector peekOrigin = door.getWorldOrigin() + sys.VecRotate(offset, door.getAngles()); // ------------------------------------------------------ vector dimensions = door.getMins() + door.getMaxs(); vector peekVector; if (dimensions_x < dimensions_y && dimensions_x < dimensions_z) { peekVector_x = dimensions_x; } else if (dimensions_y < dimensions_z) { peekVector_y = dimensions_y; } else { peekVector_z = dimensions_z; } peekVector = sys.VecRotate(peekVector, door.getAngles()); peekVector = sys.vecNormalize(peekVector); vector playerViewVector = sys.angToForward($player1.getViewAngles()); playerViewVector = sys.vecNormalize(playerViewVector); vector delta = playerViewVector - peekVector; float magnitude = sys.vecLength(delta); if (magnitude > 1) { peekVector = -peekVector; sys.println("inverting peekVector"); } sys.println("normalized peekVector: " + peekVector); sys.println("normalized playerViewVector: " + playerViewVector); sys.println("normalized delta: " + delta); sys.println("magnitude of delta: " + magnitude); // ------------------------------------------------------ peekOrigin += peekVector * 10; entity spawnFlame = sys.spawn("light_candleflame"); spawnFlame.setOrigin(peekOrigin); }

Aren't we missing somewhere in peekVector the current angle of the door? Vector dimensions is always the same therefore the starting values of peekVector are always the same (for a same door).

Hi wesp5, If we succeed you can adjust it to fit your needs / vision. Well, some doors don't come with a graphical keyhole but can still be locked and lockpicked...

Thanks, Dragofer. I can feel we are getting closer but something is amiss. void playertools_compass::inventoryUse(player userEntity, entity frobbedEntity, float buttonState) { entity door = frobbedEntity; vector offset = 0.5 * (door.getMins() + door.getMaxs()); vector peekOrigin = door.getWorldOrigin() + sys.VecRotate(offset, door.getAngles()); // ------------------------------------------------------ vector dimensions = door.getMins() + door.getMaxs(); vector peekVector; if (dimensions_x < dimensions_y && dimensions_x < dimensions_z) { peekVector_x = dimensions_x; } else if (dimensions_y < dimensions_z) { peekVector_y = dimensions_y; } else { peekVector_z = dimensions_z; } peekVector = sys.vecNormalize(peekVector); vector playerViewVector = sys.angToForward($player1.getViewAngles()); playerViewVector = sys.vecNormalize(playerViewVector); vector delta = playerViewVector - peekVector; float magnitude = sys.vecLength(delta); if (magnitude > 1) { peekVector = -peekVector; sys.println("inverting peekVector"); } sys.println("normalized peekVector: " + peekVector); sys.println("normalized playerViewVector: " + playerViewVector); sys.println("normalized delta: " + delta); sys.println("magnitude of delta: " + magnitude); // ------------------------------------------------------ peekOrigin += sys.angToForward(peekVector) * 10; entity spawnFlame = sys.spawn("light_candleflame"); spawnFlame.setOrigin(peekOrigin); }

@Dragofer, I am afraid I lost you here: Are you suggesting to rewrite the previous steps? vector dimensions = door.getMins() + door.getMaxs(); vector peekVector = door.getAngles(); if (dimensions_x < dimensions_y && dimensions_x < dimensions_z) { peekVector_x = dimensions_x; } else if (dimensions_y < dimensions_z) { peekVector_y = dimensions_y; } else { peekVector_z = dimensions_z; }

@Shadow The game already has a built-in peek feature mappers can make use of whenever they deem it appropriate (locked doors / unlocked doors / holes in a wall / other purposes...). This built-in feature remains untouched. As part of this initiative we will be creating an external mod that will allow players to peek (almost) every door in (almost) every mission. Players will be free to use it or not. @datiswous We will see what results testing produces.

Following your instructions literally, without me knowing why nor how, I reached a point where I just can't "compare it with the player's view direction angles": vector smallest = door.getMins() + door.getMaxs(); if (smallest_x < smallest_y && smallest_x < smallest_z) { smallest_y = 0; smallest_z = 0; } else if (smallest_y < smallest_z) { smallest_x = 0; smallest_z = 0; } else { smallest_x = 0; smallest_y = 0; } vector newVector = sys.VecRotate(smallest, door.getAngles()); newVector = sys.VecToAngles(newVector); if ((newVector - $player1.getViewAngles()) > 90) CATASTROPHIC FAILURE --- CATASTROPHIC FAILURE --- CATASTROPHIC FAILURE (fell free to humiliate)

Thank you very much. I will require multiple re-readings of your post though A last resort worth mentioning is to allow peeking only when a door is in closed position. Not only we eliminate from the equation weird player angles but it would also get rid of any potential clipping when a door, in example, is fully open but tightly close to a wall. Now that think of it the peek feature wouldn't suffer much from having this rule: peeking through a keyhole of an open door can come in handy in the game yes, but seems like a little far fetched or forced? Open a door a little and peek through? Hide behind an open door and peek through instead of leaning? Hmm...

Here comes (what I think is) the most difficult trick to pull of. I am not very good at trigonometry and the solution to the riddle requires a community effort. As explained before, I want the peek to always follow a forward direction relative to the current position of the player and the door. A perpendicular, if you like, to one of the surfaces of the door aiming into the opposite direction the player is positioned at. I strongly believe this is the best possible outcome to keep the mechanic at bay thus preventing players to "peek side-ways", spoiling the whole area ahead. Red circle: the eyes of the player Green circle: the center of the door The player can be looking into many different directions but what we know for sure is that the player is directly looking at some point in the door, otherwise the door wouldn't be highlighted. What direction should the peek aim at? The player can be on one side of the door or the other (well, the player can be at an exact point where he/she is in both sides a at the same time but let's obviate this conundrum for a moment). What if we trace a ray from the player eyes to the center of door - both points known - that way we know the peek should be aiming to some point in that direction? Does that make sense or is it pointless and we should use the player view angles as the potential orientation? Shouldn't this trace give us a normal of the door surface we can work with to calculate a perpendicular? What do you, fine and educated people, think?

The idea that I have in mind is quite simple: the player selects a "Peek Keyhole" inventory item, places himself/herself in front of a door and presses the "use" key to peek through. No leaning forward, no accurate positioning. For as long as a door is highlighted, and the player is at a reasonable distance from the door, players can peek through it, just like using lock-picks. I have yet to decide whether the peek will have an on/off toggle or the peek will be continuously enabled for as long as the player keeps pressing the "use" key. Both options work fine in my prototype but I have yet to examine the pros and cons in detail. Opinions are welcome. Back to basis, I can think of three mandatory main rules: The door must have a handle: otherwise you can peek through other items with doors acting as lids, such as chests. The door mustn't be locked: the reason is that if a door is locked perhaps it isn't the time to know what's behind. Besides, for the peek to work it would seem we must "travel" to other side and we could accidentally trigger a goal before its time. If a door is unlocked nothing is preventing you from passing through therefore you can peek through it pretty safely. The peek POV must be static: meaning you get to see what's right ahead of the keyhole, in a forward position relative to the position of the keyhole or door. Players cannot use the mouse. Peeking through doors is quiet an advantage already and I think players shouldn't see too much of what's on the other side. Depending on the setup of the door and the area ahead sometimes you will get to see more, sometimes less. Now, how do we about it? We can use the built-in "Peek View" (fully or to an extent) or we can create our own implementation. I would like to try all options we can think of and see what works best. I have so far been tinkering with the built-in solution. It works, but there still are some big challenges ahead. I didn't want to use handles as a reference to avoid any potential clipping and thanks to @Dragofer we can now tell reliably and in in real time the exact center of a door, regardless of its position, orientation or rotation. The center of the door will be the reference point for our peek.

Yes, a handful of (great) missions make use of the built-in peek. Yes, "janky".

EDIT: This mod is now part of the TDM Modpack. --------------------------------------------------------------------- yay or nay?

99% perfection Dragofer! Let's however use getWorldOrigin() instead of getOrigin() in case the frobbed object is bind to something: vector center_offset = 0.5 * (object.getMins() + object.getMaxs()); vector center = object.getWorldOrigin() + sys.VecRotate( center_offset, object.getAngles() ); Many thanks for the help. Your solution is the absolute winner and we shall soon put it to good use.