Mines

[Baddcog]

but I don't want to arbitrarily override what might be a good design decision made a while ago.

 

 

 

 

I don't think there are worries in this regard...

 

I think T2 had a light, at least a tex swap with a 'lit' version. It was like a little green or red LED, so nothing bright or really noticeable.

 

I like ticking, but don't really think it's any less 'alarming' to an ai. sound/light...either is fairly unrealistic and cause for alarm, but I think sound does fit the steampunk theme a bit better.

 

Though it needs to be quiet and would only be noticeable very close.

[Springheel]

When the mine is launched, it starts out with a small bit of pitch and roll. Does anyone know why?

 

I think greebo did that code.

[grayman]

When the mine is launched, a ratchety activation sound plays for 4 secs, after which the mine becomes armed.

 

When the flash mine is launched, the blackjack swing sound plays.

 

Shouldn't both mine types play the same sound? Same type of device, just a different action when stepped on.

 

Any reason the sounds are different?

 

I'm assuming that both mines should behave the same wrt having a looping armed sound and being able to disarm them and put them back into inventory.

[Springheel]

I can't think of any reason not to have them work the same way.

[Tels]

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.

 

If I am not mistaken, the small random pitch/roll was added by me to any object thrown by the player, because otherwise it looked quite silly with every book/candle etc. you throw landing the exact 100% same way every time - esp. noticable if you throw multiple objects of the same type one after another. It was possible to stack candles simply by throwing them If this is an issue that helps with the mine placement, then please add a bug tracker entry and assign it to me - I got quite some time over the next few weeks.

 

However, I am pretty sure that we could make the amount of random pitch/roll a spawnarg (even if it is just a boolean) and let the code query that and disable it for mines that way. (One could also experiment with the bounciness and friction of the mines, I am not sure if these values are already correct or were just set more or less randomly back then w/o anyone really trying to place mines in a level).

 

PS: @grayman: Mines do not properly place their decals when they go off - I couldn't find a bug report matching this, but you can compare a mine explosion to a fire arrow explosion and see the difference. Not sure why this is andhow to fix it, but maybe you want to have a look?

[grayman]

If I am not mistaken, the small random pitch/roll was added by me ...

 

That makes sense.

 

I was referring to this setting in mines and flashmines:

 

"angles" "-10,10,0"

 

That gives a mine a bit of pitch and roll as it comes out. I don't think it matters; I was just fishing for the reason for that setting.

 

 

Mines do not properly place their decals when they go off - I couldn't find a bug report matching this, but you can compare a mine explosion to a fire arrow explosion and see the difference. Not sure why this is andhow to fix it, but maybe you want to have a look?

 

I'll check. I set a mine off yesterday with a broadhead and there was no decal. Perhaps the impulse of the arrow hitting the mine pushed it momentarily below the floor plane and that's where the decal was painted, which made it invisible.

 

I also noticed during testing that if I pick up a corpse and toss it onto an armed mine, the mine doesn't go off. That'll need fixing too. Makes a nice way to clear a mine field.

 

 

 

[Tels]

That makes sense.

 

I was referring to this setting in mines and flashmines:

 

"angles" "-10,10,0"

 

That gives a mine a bit of pitch and roll as it comes out. I don't think it matters; I was just fishing for the reason for that setting.

 

That setting wasn't added by me, tho, I never touched the mines - just added the random roll/pitch when throwing things (and IIANM this depends on the weight of the object, too)

 

 

I'll check. I set a mine off yesterday with a broadhead and there was no decal. Perhaps the impulse of the arrow hitting the mine pushed it momentarily below the floor plane and that's where the decal was painted, which made it invisible.

 

I also noticed during testing that if I pick up a corpse and toss it onto an armed mine, the mine doesn't go off. That'll need fixing too. Makes a nice way to clear a mine field.

 

Cool, thanx!

[grayman]

You lot are EVIL!

 

The lockpicking code is like the Energizer Bunny. It just keeps going on and on and on and on ...

 

I have to keep telling the bits I've copied over to the mine, "No, this is NOT a door!".

[Springheel]

Yes, I recall greebo saying that it would not be an easy task to make the lockpicking code work with mines.

[grayman]

Yes, I recall greebo saying that it would not be an easy task to make the lockpicking code work with mines.

 

He was right.

[grayman]

Neener-neener!

 

Just unlocked (disarmed) a mine.

 

I'm going to Disney World.

[Springheel]

[Ishtvan]

Yay! I looked into that and gave up. Congrats on getting that working! I still want to finish tripwires some day (maybe when I have grounded outlets I can plug my desktop into). The player interface for setting them is done, but the tripwire physics themselves (go off when something touches it, or when a moveable it's stuck in gets pulled too far, etc) need to be done. Was going to make them use static physics, but there's an odd case where you might have a tripwire on a moving platform or something and it could run into something stationary; for that you'd have to give them moveable physics.

[grayman]

As mentioned above, disarming the mines is done.

 

I've corrected a problem where the AI would walk near or on top of a mine and push it into the floor, where it would explode but sometimes not be noticed because it was outside the world. This also corrected the misplaced decals.

 

AI are tripping the mines when they should now. They can either step on them or come very close to trip the mine.

 

Yet to do: Put a disarmed mine back into inventory. Let the mapper arm a mine at map start. Get mines to fall rightside-up more often.

 

A general problem still remains where AI and the player can kick or step on small items and have them disappear into the floor. I've looked at the code that causes this and have yet to come up with a solution. If you've ever walked across a coin on the floor, heard it ring, and had it disappear, this is what happens. The player and AI exert a downward force on things when they walk on them, and there's a long-standing problem in the engine code (at least as far back as Quake 2) where a check for world brushes sometimes fails. When that happens, the engine lets the item fall into the floor brush and a few frames later, the item is well outside the world. It can also happen if there's another room below. I've had chairs I've brushed against fall through the floor into the room below.

[nbohr1more]

That Falling Bug reminds me of a Gamasutra "Dirty Hack" story:

 

 

http://www.gamasutra...icks.php?page=3

 

 

 

Meet My Dog, Patches

There's an old joke that goes something like this:

 

Patient: "Doctor, it hurts when I do this."

Doctor: "Then stop doing it."

 

Funny, but are these also wise words when applied to the right situation? Consider the load of pain I found myself in when working on a conversion of a 3D third person shooter from the PC to the original PlayStation.

 

Now, the PS1 has no support for floating point numbers, so we were doing the conversion by basically recompiling the PC code and overloading all floats with fixed point. That actually worked fairly well, but were it fell apart was in collision detection.

 

The level geometry that was supplied to us worked reasonably well in the PC version of the game, but when converted to fixed point, all kinds of seams, T-Junctions and other problems were nudged into existence by the microscopic differences in values between fixed and floats. This problem would manifest itself by the main character (called "Damp") simply falling through those tiny holes, into the abyss below the level.

 

We patched the holes we found, tweaking the geometry until Damp no longer fell through. But then the game went into test at the publisher, and suddenly a flood of "falling off the world" bugs were delivered to us. Every day a fresh batch of locations were found with these little holes that Damp could slip through. We would fix that bit of geometry, then the next day they would send us ten more. This went on for several days. The publisher's test department employed one guy whose only job was to jump around the world for ten hours a day, looking for places he could fall through.

 

The problem here was that the geometry was bad. It was not tight and seamless geometry. It worked on the PC, but not on the PS1, where the fixed point math vastly magnified the problems. The ideal solution was to fix the geometry to make it seamless.

 

However, this was a vast task, impossible to do in the time available with our limited resources, so we were relying on the test department to find the problem areas for us.

 

The problem with that approach was that they never stopped finding them. Every day bought more pain. Every day new variants of the same bug. It seemed like it would never end.

 

Eventually the penny dropped. The real problem was not that the geometry had small holes in it. The problem was that Damp fell through those holes. With that in mind, I was able to code a very quick and simple fix that looked something like:

 

IF (Damp will fall through a hole()) THEN

Don't do it

 

The actual code was not really much more complex than that (see Listing 2).

 

Listing 2: Meet My Dog, Patches

 

damp_old = damp_loc;

move_damp();

if (NoCollision())

{

damp_loc = damp_old;

}

 

In one swoop a thousand bugs were fixed. Now instead of falling off the level, Damp would just shudder a bit when he walked over the holes. We found what was hurting us, and we stopped doing it. The publisher laid off their "jump around" tester, and the game shipped.

 

Well, it shipped eventually. Spurred on by the success of "if A==bad then NOT A", I used this tool to patch several more bugs -- which nearly all had to do with the collision code. Near the end of development the bugs became more and more specific, and the fixes became more and more "Don't do thispreciseandexacthing" (see Listing 3, actual shipped code).

 

Listing 3: Meet My Dog, Patches

 

if (damp_aliencoll != old_aliencoll &&

strcmpi("X4DOOR",damp_aliencoll- >enemy->ename)==0 &&

StartArena == 6 && damp_loc.y<13370)

{

damp_loc.y = damp_old.y; // don't let damp ever

touch the door.. (move away in the x and y)

damp_loc.x = damp_old.x;

damp_aliencoll = NULL; // and say thusly!!!

}

 

What does that code do? Well, basically there was a problem with Damp touching a particular type of door in a particular level in a particular location, rather than fix the root cause of the problem, I simply made it so that if Damp ever touched the door, then I'd move him away, and pretend it never happened. Problem solved.

 

Looking back I find this code quite horrifying. It was patching bugs and not fixing them. Unfortunately the real fix would have been to go and rework the entire game's geometry and collision system specifically with the PS1 fixed point limitations in mind. The schedule was initially aggressive, so we always seemed close to finishing, so the quick patch always won over the comprehensive, expensive fix.

 

But it did not go well. Hundreds of patches were needed, and then the patches themselves started causing problems, so more patches were added to turn off the patches in hyper-specific circumstances. The bugs kept coming, and I kept beating them back with patches. Eventually I won, but at a cost of shipping several months behind schedule, and working 14 hour days for all of those several months.

 

That experience soured me against "the patch." Now I always try to dig right down to the root cause of a bug, even if a simple, and seemingly safe, patch is available. I want my code to be healthy. If you go to the doctor and tell him "it hurts when I do this," then you expect him to find out why it hurts, and to fix that. Your pain and your code's bugs might be symptoms of something far more serious. The moral: Treat your code like you would want a doctor to treat you.

 

 

 

[grayman]

Good story.

 

I'm waiting for the day when the D3 engine opens up and someone of us can fix the frackin' collision problem. (And probably a gazillion other things.)

[i30817]

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.

 

 

That's interesting, you could have a ally AI trapped by a mine, begging your help to disarm it.

 

Or set a trap for one that makes him stop and interrogate him.

[Tels]

As mentioned above, disarming the mines is done.

 

I've corrected a problem where the AI would walk near or on top of a mine and push it into the floor, where it would explode but sometimes not be noticed because it was outside the world. This also corrected the misplaced decals.

 

AI are tripping the mines when they should now. They can either step on them or come very close to trip the mine.

 

Very cool!

 

Yet to do: Put a disarmed mine back into inventory. Let the mapper arm a mine at map start. Get mines to fall rightside-up more often.

 

A general problem still remains where AI and the player can kick or step on small items and have them disappear into the floor. I've looked at the code that causes this and have yet to come up with a solution. If you've ever walked across a coin on the floor, heard it ring, and had it disappear, this is what happens. The player and AI exert a downward force on things when they walk on them, and there's a long-standing problem in the engine code (at least as far back as Quake 2) where a check for world brushes sometimes fails. When that happens, the engine lets the item fall into the floor brush and a few frames later, the item is well outside the world. It can also happen if there's another room below. I've had chairs I've brushed against fall through the floor into the room below.

 

Oh, yeah, that is the most aggrevating physics bug. It was also why back then I argued against having small moveable loot (like rings), because I think there is little benefit of having them movable (some mappers decorate entire rooms into statics, but we care that a loot ring is moveable, even tho except explosions or hitting them with a broadhead there is noway the player can actually move them...), but there are huge downsides (the disappearing loot due to physics bug).

 

However, the bug is more universal (chairs often fall through the floor, too), and if you can fix this, that would be worthy of a medal! (or a crate of wine/beer if you prefer)

[nbohr1more]

Not that it's anything but peanut gallery chatter but I thought that the collision code was all in the Physics portion of the SDK but these comments seem to indicate otherwise?

 

If it is in the SDK and the code looks clean, maybe the math libraries are at fault...? stuff like Carmack's famous "Fast Square Root" hack, etc?

 

[grayman]

Not that it's anything but peanut gallery chatter but I thought that the collision code was all in the Physics portion of the SDK but these comments seem to indicate otherwise?

 

If it is in the SDK and the code looks clean, maybe the math libraries are at fault...? stuff like Carmack's famous "Fast Square Root" hack, etc?

 

The engine and the DLL work hand-in-hand to simulate movement in a real world. Sometimes the engine messes up the answer to something the DLL's asked it while setting up. This can lead to some goofy results, like coins or chairs or mines or awakening sleepers falling through the floor.

 

As to where the root cause is, that's yet to be discovered. If it's in the engine, we could try to apply a band-aid in the DLL. If it's in the DLL, then we can snuff it out for good.

 

(I found one spot in the DLL that I thought was causing a mine to fall through the floor, but when I "fixed" it, it only fixed it for one frame, and the DLL/engine axis of evil got it moving downward again in the next frame. At that point, I decided I was getting off focus, and could come back to it later. The mine would explode 7 frames after being touched, during which time it descended farther and farther into the floor. I solved the problem by blowing up the mine the same frame it was touched, and not giving the DLL/engine a chance to even begin to screw up.)

[nbohr1more]

Thanks Grayman.

 

I'd say that crate of beer\wine (etc) has already been earned

Edited June 15, 2011 by nbohr1more

[stumpy]

most contact mines in real life detonate not on contact, as thats used to arm the device, but detonate when the presure of the foot or tyre or track is removed. eg like the bouncing betty mine.

[grayman]

I noticed that we have these in Moveables/Player_tools:

 

atdm:moveable_gasmine

atdm:moveable_mine

 

and that we have these in Playertools:

 

atdm:playertools_flashmine

atdm:playertools_mine

 

Is the gasmine new? There's no code to support it. Defined like this, you can only place it in a map, where it serves no purpose other than decoration.

 

I'm not sure I understand the purpose of having things in Moveables/Player_tools.

[Springheel]

There was a mission that created gas mines as a special object to recover...I don't think we've ever had (or intended to have) one that was operational.

[Sotha]

There was a mission that created gas mines as a special object to recover...I don't think we've ever had (or intended to have) one that was operational.

 

Really? Shame..

It would be nice to have both explosive mines and gas mines. Flash mines do not sound that useful since mines are expensive and flashbombs relatively cheap.

 

Placing mines and waiting for someone to step on the trap is fun but explosive mines will seldom be used by people who avoid killing AI's. Gas mine gives these people the fun and excitement of mine placing without kills.