SCP Beta 4 Issue Reporting

[67425f055e001JML]

Riiiight, <Dr. Evil air quotes>aquariums</>.

[67425f055e17evoodoo47]

maybe we could add a few sharks with lasers.

[67425f055ecbdRocketMan]

There are no smegging aquariums in SS2.

Technically there are no vagina rooms either but people in THE KNOW understand me 

[67425f055f002RocketMan]

that reminds me, I always wanted the vag room to actually pop eggs every once in the while, so players unwise enough to not hoard healing items throughout the game could farm glands as an alternative. basically, each vag (which actually is called an Egg Depositor, so the intention is fairly clear) would have an egg right under it, and spawn another after a while (and when the player is not looking) provided its original egg has been destroyed.

the room would need a slight redesign, adding a nesting place under each depositor.

Alternatively to please both sides, why not take an egg or 2 away from some other part of BOTM and have it berth from one of the orifices.  Maybe the first time somebody enters that room you could even show the leg of a corpse being sucked into one of them before an egg emerges a minute later from a totally different one.  This would be exactly as Profentaine described it and would be really creepy to watch.  Heck they do everything else already, including pulsate and you got some scream coming from that area.  Makes sense to finish the narrative.

[67425f055f2adJDoran]

There are no smegging aquariums in SS2.

Ah, a fellow Red Dwarf fan!

[67425f055f5c7ZylonBane]

Playing around with an improved shattered glass system. This required entirely too much math.

https://www.youtube.com/watch?v=dsfhUTxJdSE

https://www.youtube.com/watch?v=JXSlZ9AjqLc

Long story short, this makes three distinct improvement to the old flinder system.

• It takes advantage of NewDark's much higher onscreen object limit by vastly increasing the number of shards spawned when a window is broken. The number of shards spawned is now determined by the dimensions of the window.
• Instead of being randomly spawned around the center of the window object, the shards are all spawned within the oriented physics bounds of the window (this is where most of the math came in).
• Instead of just dropping straight down, the shards are given pushes depending on how the window was destroyed. Explosions push all shards away from the explosion center (force depending on distance). Projectiles push some shards near the point of impact in the direction of the projectile. Finally, melee hits fling all shards in the direction the player is moving. This isn't realistic, but it lets you do properly cinematic-looking mid-air smashes through windows.

[67425f055f6d5voodoo47]

not bad, especially the very last one in the second video.

also, bad room brush at 0:41 of the first video.

[67425f055f7b9JML]

Oh wow, this is really beautiful!
Well done!

[67425f055faa4ThiefsieFool]

Nice.

I wonder if you would be interested in adding the chance of several normal sized shards being replaced by one larger than normal shard, that would be enough to reduce a lot of the repetition in the visuals, which is about the only flaw remaining in this new system.

[67425f055fb84ZylonBane]

The idea was to emulate the way modern safety glass shatters into uniform-sized pieces when broken, but randomizing the shard scale is trivial, so I'll drop that in and see how it looks.

[67425f055fcc7Kolya]

Maybe also try giving the shards one white side to fake reflections.

[67425f055fdaeZylonBane]

That's what cube maps are for.

[67425f055ff4dRocketMan]

Tempered glass explodes into tiny cube-like fragments, which I'm sure is overkill to put into the system.  Glass shards are produced by the non-safety glass type unless it's laminated, which would cause the whole thing to remain stuck in 1 sheet.  The shards should be difference sizes (maybe not randomized but I understand there are limitations to what can be done). 

Basically there are 2 options:  1) Safety glass - You'd have to reduce the shard size a lot more until you almost can't see them and also make them more square or hexagonal in shape.  You could jump through this and all the properties you've applied would be fine.  2) Non-safety glass - You can keep the shard shape and size you have now but the sizes should be different (ideally getting bigger towards the periphery) and they should injure the player when he jumps through them.

IMO it would be cool to have both.  I kind of like how the original glass broke in addition to seeing the safety glass type.  Both could have momentum applied as you've done (if that's possible).

The jumping through glass effect is really cool BTW

[67425f056005cZylonBane]

Fun unintended effect: With the current code, if you melee a window while moving backward, the glass flies toward you. While moving sideways, the glass flies sideways. If I can't figure out how to special-case this effect to only when the player is moving toward the glass, I'll have to cut it. Unfortunately vector math is not my strong suit.

[67425f05601b5RocketMan]

I have no idea how you are coding this but can't you make the glass trajectory depend on the weapon instead of the player?  If the player wrenches the glass, the wrench is attached to the player and globally moves along the same vector but the localized impact is always towards the glass so the glass should never fall backward.  This would also make more sense since the glass trajectory really does depend more on the weapon than the player, unless the player's body can break the glass all by itself.

[67425f05602f3ZylonBane]

The velocity of a melee weapon's collision joint at the moment of impact is buried in the physics system, inaccessible to scripts. The melee weapon itself always reports as having zero velocity. So the easiest workaround is to use the player's velocity instead. That's why the "jumping through the glass" part looks so realistic, because it's directly copying the player's direction and velocity onto the glass shards, making it looks like the player's body is pushing them away.

[67425f056060aOlfred]

Can't you use the view camera vector as the direction for melee attacks?
It's not like you can hit behind you or something

[67425f0560736ZylonBane]

Sure, and I probably will. But that still leaves the challenge of detecting when the player is doing a dramatic smash-leap through a window. I don't want to send glass flying halfway across the room when the player breaks a window while standing still.

It's probably some trivially simple bit of code. I just need to figure out the right incantation of vector operators to throw at it.

[67425f0560be4unn_atropos]

Playing around with an improved shattered glass system. This required entirely too much math.

Looks awesome!

https://www.youtube.com/watch?v=FKLp8Y5RlQ8 

[67425f0560e85Olfred]

Sure, and I probably will. But that still leaves the challenge of detecting when the player is doing a dramatic smash-leap through a window. I don't want to send glass flying halfway across the room when the player breaks a window while standing still.

It's probably some trivially simple bit of code. I just need to figure out the right incantation of vector operators to throw at it.

So you basically want to have the direction of the view camera vector and then add the velocity of the player to a certain degree?

[67425f0560fa5ZylonBane]

Yes... when the player is moving toward what he just hit. Without that check I'd get the current behavior, where a backward-walking smash can suck debris toward the player.

[67425f056109aOlfred]

So what do you get out of the engine? Two vectors? And you give one vector to the engine and the length results in the "shattering distance"?

[67425f05611adZylonBane]

You can get an object's position and velocity as vectors. Then there are built in functions for normalizing vectors, getting the dot product, etc.

[67425f05612f9JDoran]

As far as I can remember, the glass in the windows has no affect on the players visibility to NPCs, correct? So maybe it would be nice if NPCs would take a second or two to see the player (starting from where there's a line of sight between the NPC's whatever-passes-for-eyes and the player) if there is glass between them, but (of course) this delay wouldn't happen if the glass in the window had been broken.

That way the player could quickly glance through a window (that still had it's glass intact) and then duck/move away and so not be seen if any NPCs were on the other side.