Jump to content
The Dark Mod Forums

Mines


grayman

Recommended Posts

I'm looking at the problems with the mines, with the idea of fixing them for 1.07.

 

Bugtracker issue #2478 notes three problems:

 

1 - Mines are contact-based, not proximity-based.

 

2 - Mines should be retrievable.

 

3 - Mines should land rightside-up.

 

 

My questions are:

 

1 - How close should an AI be for the mine to detonate?

 

2 - Is frobbing the mine (from a distance larger than the answer to #1) a satisfactory way of retrieving it? A more complicated lockpicking method has been suggested, but I don't know how desirable that is. I don't think it makes sense with a proximity-based mine anyway.

 

3a - To keep mines from landing upside-down, they need to adjust their pitch and roll during their final leg to the ground. A mine that heads straight for the ground will look more realistic than a mine that bounces off a ceiling, then a wall close to the floor, and hits the floor a moment later. I wouldn't want to adjust the model before the final leg, because the engine physics will make it moot if the mine hits something before landing. The code would have to predict when it's begun the final leg to begin making the adjustment.

 

3b - Another possibility would be to have an upside-down mine do a Bouncing Betty sort of thing and leap into the air a couple feet, twisting as it goes, and coming back down rightside-up.

 

3c - And one other suggestion would be to change the mine model so it's vertically symmetric, w/o a flat bottom, so it looks fine however it lands. (That's my favorite, since it means no work for me.rolleyes.gif)

 

 

So what do you think?

 

Thanks.

Link to comment
Share on other sites

  • Replies 86
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Well, I think lockpicking is fine.

 

I'm not sure it's supposed to be a 'proximity' mine in game. It just needs to account for proximity so they work better for gameplay.

Theoritically the ai is stepping on it when it triggers right? So that accounts for the player being able to get close enough to lockpick.

 

What it probably needs is 2 proximity radii, one for ai, one for player.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Here's my thoughts:

 

My questions are:

 

1 - How close should an AI be for the mine to detonate?

 

Close enough, so that the player can drop the mine to the correct position after observing the guard path once. Typical doorway is some 56 DR units. A typical narrowish corridor is 128 units. Therefore I think an optimal danger-zone would be something like 64x64 units, the mine placed at the center. A mine placed in the middle of a narrowish corridor will certainly result in a boom if someone tries to pass through.

 

2 - Is frobbing the mine (from a distance larger than the answer to #1) a satisfactory way of retrieving it? A more complicated lockpicking method has been suggested, but I don't know how desirable that is. I don't think it makes sense with a proximity-based mine anyway.

 

Frobbing is fine for me, but I don't think one can frob it from 64 units away. Could the proximity detonation be speed specific? If someone moves at a speed X in the danger-zone->BOOM. That way the player could creep close to the mine and pick it up. It could be a two frob thing: first frob disables it (cool disabling sound effect? The mine is live and the player cannot pick it up until the disabling sound ends), after that second frob picks it up.

 

The alternative disabling is lockpicking, like suggested.

 

I think the mine could have more significant gameplay effect if the disabling wasn't as trivial as picking up objects. Lockpicking could make it more hazardous and time consuming since player mistakes lengthen the process. The disable frob with a delay would make it dangerous, as the player is in the danger-zone waiting for the disable cool-off to end so he can pick the thing up or even move quickly near the mine.

 

If the mines had such disabling based gameplay effect, they would possibly be interesting obstacles in a mission: maybe insane inventor has rigged some live mines to slow down the player. It would be tense to disable mines in a well lit corridor between guard shifts... And the reward would be sweet: a handful of mines to plant. This would, of course, need the possibility for the mappers to place LIVE mines in their missions.

 

3a - To keep mines from landing upside-down, they need to adjust their pitch and roll during their final leg to the ground. A mine that heads straight for the ground will look more realistic than a mine that bounces off a ceiling, then a wall close to the floor, and hits the floor a moment later. I wouldn't want to adjust the model before the final leg, because the engine physics will make it moot if the mine hits something before landing. The code would have to predict when it's begun the final leg to begin making the adjustment.

 

3b - Another possibility would be to have an upside-down mine do a Bouncing Betty sort of thing and leap into the air a couple feet, twisting as it goes, and coming back down rightside-up.

 

3c - And one other suggestion would be to change the mine model so it's vertically symmetric, w/o a flat bottom, so it looks fine however it lands. (That's my favorite, since it means no work for me.rolleyes.gif)

 

I think if would be best if the mine simply was symmetrical, and could not fall on its short side. It is important that the mine dropping works as intuitively as possible, so that the player can place it exactly where he wants. Could the activated mine be dropped into the frobber rather than directly on the floor? If the mine was in the player's hand, he could put it accurately exactly where he wants it. It could be thrown a little bit too.

 

Also there is the question, could the mines be placed on other surfaces than floor? Mine placed on walls? Ceilings? If the mappers had the ability to place live mines, walls and ceilings would be more difficult to spot, making things more deadly.

 

I hope these ideas help.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

In my opinion the proximity radius should be so small, that it still gives the illusion of a contact mine, so maybe a double-dourway wide. Any I was thinking that player is able to approach the mine sneaking without the risk of setting it off, but if he run towards it, it will blow up.

 

Bouncing Betty sound fun, especially if it had small lags. :D But what ever is most convenient for you...

Link to comment
Share on other sites

Sotha brings up a good point, having the dropper is something T2 didn't have.

 

So why not use that to place the mine right where you want. That always lets you throw it too in case you just want to huck it into the middle of a bunch of guards. (In which case it might need to just blow up on impact)

 

But being able to carefully place it makes it a mucher cooler tool for the stealth thief trying to guard a passage.

--------

 

Frobbing doesn't make too much sense to me whether or not it's a proximity mine or not. The thing is live and dangerous, nobody's gonna pick it up and throw it back in their pocket.

I always liked that about the T2 mines, if you threw one you always had a chance of retrieval, and it wasn't too difficult but I got hurt a few times getting to close/reckless.

 

The lockpick is a tool the player always (almost always) has and is the perfect tool for disabling it. But just a quick easy sequence. It's already dangerous, and most likely already placed in an area where ai patrol.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

I like the idea, throw it and its a bomb, drop it and its a mine but I also liked in Thief to be able to throw (slide) a mine into an area I coudn't safely go. So on balance I would keep it a mine.

 

I'm warming to lockpicking to disable them. An alternative would be a special acquire sound of a few clicks to indicate you quickly disabled it as you picked it up. But could that change itself to a normal unarmed mine with the normal acquire sound after it is picked up?

 

I like the idea of close proximity - what Stifu said roughly between a double doorway, say a radius of 50 to 75? Another possibility is 25 to 50 less than the frob_distance so the mapper could vary the distance. But that inconsistency might be annoying. The thing is, the player could always find out the distance by carefully approaching. When it highlights then he knows its proximity is set at 25-50 less than that (whatever offset is chosen.)

 

Is there some visible indication to separate an armed mine from one that is not, eg, ammo in an armory?

 

What about placing an unarmed mine, eg, in a stash somewhere. Hardly likely to be used much but might be needed. Perhaps drop doesn't arm but throw does. Is it attack that throws or use? I forget. I'm just wondering how difficult it would be if you want to place precisely.

 

Wait, how do we place it carefully at our feet if it arms itself anyway. We'd never get away unless there is a timer before it arms itself.

 

I do not think I have ever used a mine in a real FM and only a handful of times in a test map.

Link to comment
Share on other sites

I know that this won't be very popular as it would require further explanation to players, but there's always the option of using the 'dropper' method to place mines, but then requiring the 'use' key to arm the mine, either once you're happy it's been placed successfully or maybe even whilst it's still waiting to be dropped. Perhaps a subtle yellow light on the mine indicates it is currently armed.

 

I'm also pretty happy with lock picking to disable the mine. I do like the DX method of double frob to disarm and then retrieve the mine, but using lockpicks personally seems a more believable way to disarm a mine.

 

I prefer the idea of a symmetrical mine rather than one that has to perform all sorts of acrobatics or require the player to re-orient a poorly thrown mine, but bear in mind that it wouldn't make sense that a symmetric mine could be placed on a wall (DX style), so now would be the time to decide if this kind of feature is desirable. Personally, I don't think there's any great benefit to having a wall mounted mine versus a mine that can be carefully placed on the correct position on the ground.

Link to comment
Share on other sites

1 - How close should an AI be for the mine to detonate?

 

They're not proximity mines...they are supposed to go off because AI are stepping on them. The problem is that AI can literally step right over them without setting them off. The mines should be triggered by the AI's bounding box. Not sure why they didn't work that way from the start (I think it does for the player).

 

2 - Is frobbing the mine (from a distance larger than the answer to #1) a satisfactory way of retrieving it? A more complicated lockpicking method has been suggested, but I don't know how desirable that is. I don't think it makes sense with a proximity-based mine anyway.

 

While using the Drop key to precision-place mines is a nice idea, it runs counter to the way Drop works for every other item (Use to use, Drop to discard). With that in mind, I think it should be relatively easy for players to retrieve mines that don't land exactly where they want. Frobbing them should be fine, especially if they only go off when hit by the player's bounding box.

 

If we wanted to extend the versatility of mines a little bit without getting too complicated, we could make them go off on contact when thrown with enough velocity. So if players want to place a mine, they hold Use down for a short period of time, but they can also hold down Use, build up a lot of momentum, and fire the mine so that it explodes on contact. That infringes on the utility of fire arrows, though.

 

3a - To keep mines from landing upside-down, they need to adjust their pitch and roll during their final leg to the ground. A mine that heads straight for the ground will look

 

This is purely an aesthetic issue. As long as mines function properly, does it really matter if they occasionally land upside down? I'm not sure that's worth much effort to fix.

Link to comment
Share on other sites

They're not proximity mines...they are supposed to go off because AI are stepping on them.

 

Just to be clear, you originally wrote in bugtracker that ...

 

"I think the mine ought use a proximity test to detect if the AI is standing within a circle of x units from the mine center, rather than waiting for contact (or maybe it already does this but the radius is too small)."

What I'm inferring here is that a proximity test is needed, but it should look like the AI stepped on the mine.

As long as mines function properly, does it really matter if they occasionally land upside down? I'm not sure that's worth much effort to fix.

 

 

Also, in the issue you wrote:

 

"... the mine rotates in the air and then lands upside down. Obviously this was never a problem in Thief because it didn't do full physics simulation. Perhaps the mine could be made more bottom-heavy so this was less likely to occur."

And what I'm reading now is that you think this is no longer a problem worth fixing.

Correct?

I think I have enough comments now to write up a plan. I'll post it tomorrow.

Thanks!

Link to comment
Share on other sites

What I'm inferring here is that a proximity test is needed, but it should look like the AI stepped on the mine.

 

Yes, proximity might have been the wrong word to use, but essentially we want the mine to go off if the AI get close enough to it, whether they actually land their foot on it or not.

 

And what I'm reading now is that you think this is no longer a problem worth fixing.

 

Well, I did also say it was a "minor issue". ;) I know there are values that affect the spin of projectiles...tweaking those values was what I originally had in mind. Adding new code or redesigning the model might be overkill for a purely aesthetic issue, in my personal opinion. Maybe other people find it more of a problem...?

Link to comment
Share on other sites

Regarding the retrieval of mines, I seem to remember that the original Thief mines played a clockwork sound right before detonating. What about just copying that: When the player comes close to the mine, if starts the clockwork sound, which lasts 2-3 seconds. If the player frobs the mine during that time, he disarms it this way, if not, if will blow up in da face.

 

This would also be compatible with the AI radius thingy. AIs usually move in a certain speed. Just need to make sure that the mine is armed in a sufficiently short time after the AI's bounding box touches it, in order for the AI to get the full explosion blast.

 

Am I making sense?

 

 

My Eigenvalue is bigger than your Eigenvalue.

Link to comment
Share on other sites

Am I making sense?

 

Yep, that's the deus ex mine implementation, I think it is a nice idea among the others seen here.

 

With so many interesting ideas around, I await grayman's plan with great anticipation.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

I'm sure grayman's tweaks will be great, and finally give mines some practical use.

 

For my own 2 cents, I think that lockpicking is a cool idea, no auto-picking clicky sounds for fast recapture.

Also, I think that player proximity detection should be the same as AI proximity unless the player uses creep, in which case it becomes contact-only for the player. that might be a little bit hard to implement, though. example: creep towards mine, stand still, let go of the creep button - BOOM.

Link to comment
Share on other sites

I think the clockwork sound was just prior to arming, not detonation. If I remember correctly you could frob it before that, no hassle. After the sound which lasts about 2-3 seconds, it's armed and you have to lock pick it in order to get it back, or let it explode, or shoot an arrow at it, etc.

Link to comment
Share on other sites

The mines are really nice models.

 

I was thinking about collision model and how it could make the mine land upright always, but that still would be hard to do. Say you make a pyramid. It's more likely to land on the flat bottom, but if it doesn't it would land really weird.

 

So I wonder if it could be coded to always stay z up. Might be too much work, but might be the only way to force it to land on it's bottom.

 

T2 mines probably used (I forget exact name) something 'hat'. There were 3 choices, box, sphere and hat. Which was like a flat bottomed sphere which made things land right side up pretty accurately.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Plan

 

1 - Fix the code so a moving AI has a better chance of setting off the mine. If a mine ends up inside the bounding box of a standing AI, don’t set it off.

 

2 - Retrieve a live mine by approaching slowly and using any lockpick on it. Adjust the bounding box check to let the player get close enough. Play the lockpicking sound while lockpicking. Play a “deactivated” sound when done.

 

3 - Land rightside-up if the animation looks reasonable and it’s not a lot of work.

 

Stretch Plan

 

1 - Allow mappers to place live mines using a “live” spawnarg. A live mine should either play a ticking sound no louder than its activation sound (played when thrown), or change the dimple in the top of the mine to an indicator that’s lit when the mine is live. However, adding an indicator light is a problem if mines are allowed to end up upside-down.

 

Not Implementing

 

1 - Sticky mines to place on walls or ceilings. (Placing it on the ground next to a wall gives the same result, and how would you stick it to a ceiling? Also, since the mine is a contact mine and not a proximity mine, the chance of an AI brushing against a wall mine is low, and brushing against a ceiling mine is zero.)

 

2 - Tripwires. (Requires connecting and stringing wires.)

 

3 - Make the model symmetric. (Not necessary.)

 

4 - Explode when thrown and it hits an AI. (Too much like a grenade or fire arrow.)

 

5 - Change the way the player releases the mine. (Violates the use/drop paradigm, and giving the player the ability to retrieve mis-thrown mines reduces the need for a change.)

Link to comment
Share on other sites

Plan

 

Yep, I was certain that a reasonable plan comes out. Sounds nice and promising.

 

What I didn't understand was this:

1 - Fix the code so a moving AI has a better chance of setting off the mine. If a mine ends up inside the bounding box of a standing AI, don't set it off.

 

What was the mine's danger-zone radius or diameter gonna be? And it will be speed triggered or something else?

 

1 - Allow mappers to place live mines using a "live" spawnarg. A live mine should either play a ticking sound no louder than its activation sound (played when thrown), or change the dimple in the top of the mine to an indicator that's lit when the mine is live. However, adding an indicator light is a problem if mines are allowed to end up upside-down.

 

I'd say that a subtle noise is better than an indicator light. Someone sets up a trap for someone: the trap is certainly NOT gonna have any lights to make it easier to spot. However, the trap certainly needs a mechanism to make it work, hence the noise.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

1 - Sticky mines to place on walls or ceilings. (Placing it on the ground next to a wall gives the same result, and how would you stick it to a ceiling? Also, since the mine is a contact mine and not a proximity mine, the chance of an AI brushing against a wall mine is low, and brushing against a ceiling mine is zero.)

 

 

 

Thought the point is not for the player to do it, but for the mapper.

Link to comment
Share on other sites

What was the mine's danger-zone radius or diameter gonna be? And it will be speed triggered or something else?

 

Since these are contact and not proximity mines, standing next to one won't set it off. The mine requires two conditions to explode: 1 - is it inside the AI's bounding box (or expanded bounding box) and 2 - is the AI moving? A standing AI can pass the first check, but not the second. As soon as he moves, ka-boom! An argument could be made for how fast an AI needs to be moving, but if a minimum speed is needed to be more realistic, that can fall out of beta testing.

 

I'd say that a subtle noise is better than an indicator light. Someone sets up a trap for someone: the trap is certainly NOT gonna have any lights to make it easier to spot. However, the trap certainly needs a mechanism to make it work, hence the noise.

 

I'm leaning toward the sound as well, since it doesn't require a model change. Also, a low ratchety-ratchet sound fits a steampunk theme, evoking images of wheels and gears going around, rather than the silence of a more modern mine. I wondered, however, if folks would object to a sound, arguing that the AI would be able to hear it. But an armed mine needs something to distinguish it from an unarmed mine, so it looks like a sound is the easiest way to do that, and a sound doesn't care whether the mine is rightside-up or not.

 

 

 

Link to comment
Share on other sites

So I wonder if it could be coded to always stay z up. Might be too much work, but might be the only way to force it to land on it's bottom.

 

Right. The engine handles the physics, and I'd need to experiment with how much in-flight control I'm allowed to have. I don't recall if a mine thinks while flying; that's where a bit of z-correction could be applied.

 

When the mine is launched, it starts out with a small bit of pitch and roll. Does anyone know why? Flattening it out might help with close drops, but I don't want to arbitrarily override what might be a good design decision made a while ago.

 

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • OrbWeaver

      Finally got round to publishing a tutorial on baking normal maps in Blender, since most of the ones we have are inaccessible or years out of date.
      · 0 replies
    • nbohr1more

      The FAQ wiki is almost a proper FAQ now. Probably need to spin-off a bunch of the "remedies" for playing older TDM versions into their own article.
      · 1 reply
    • nbohr1more

      Was checking out old translation packs and decided to fire up TDM 1.07. Rightful Property with sub-20 FPS areas yay! ( same areas run at 180FPS with cranked eye candy on 2.12 )
      · 3 replies
    • taffernicus

      i am so euphoric to see new FMs keep coming out and I am keen to try it out in my leisure time, then suddenly my PC is spouting a couple of S.M.A.R.T errors...
      tbf i cannot afford myself to miss my network emulator image file&progress, important ebooks, hyper-v checkpoint & hyper-v export and the precious thief & TDM gamesaves. Don't fall yourself into & lay your hands on crappy SSD
       
      · 7 replies
    • OrbWeaver

      Does anyone actually use the Normalise button in the Surface inspector? Even after looking at the code I'm not quite sure what it's for.
      · 7 replies
×
×
  • Create New...